| 00:22 | <TabAtkins> | othermaciej: Sorry for the curtness on the lists. >_< Really didn't intend to be rude; I just shouldn't have responded at all. It was an obviously provocative statement that didn't deserve a response. |
| 00:25 | <othermaciej> | TabAtkins: just do your best to be courteous, please, even if you feel provoked for whatever reason |
| 00:26 | <TabAtkins> | Yeah, I know. I'm sorry I let myself go. I'll watch myself more in the future.e |
| 00:29 | <mpilgrim> | png optimization baffles me |
| 00:30 | <TabAtkins> | That it works? |
| 00:35 | <mpilgrim> | that i've optimized the same images with about six different tools, and each one seems to find a way to make each image slightly smaller than that last round |
| 00:35 | <TabAtkins> | You've discovered a perfect compressor. |
| 00:35 | <TabAtkins> | Keep going until the file is just 1 bit. |
| 00:36 | <mpilgrim> | apparently there's an element of randomness to it as well |
| 00:37 | <mpilgrim> | there are far too many ways to express the same image to try them all |
| 00:37 | <mpilgrim> | so it's a sort of monte carlo method |
| 00:38 | <mpilgrim> | which is quite maddening for those of us who are obsessive about making our sites load more quickly |
| 00:38 | <mpilgrim> | because, you know, you could always run it again, and maybe it'll be smaller |
| 00:38 | <mpilgrim> | you can't ever be sure that you're done |
| 00:39 | <Rik`_> | mpilgrim: do you know about http://imageoptim.pornel.net/ ? |
| 00:39 | <Rik`_> | it will take try several tools and pick the best |
| 01:32 | <mpilgrim> | Rik`: oh goodie, another tool to try |
| 01:32 | <mpilgrim> | you're not helping my neuroses |
| 01:33 | <Rik`> | mpilgrim: hopefully, this will be the last one |
| 01:46 | <erlehmann> | without dialog, what sensible markup options for an interview are there ? |
| 02:09 | <Hixie> | it has been brought to my attention that i was incorrect yesterday in saying RDFa was the work of the XHTML2 WG |
| 02:09 | <Hixie> | it was actually a joint project of the XHTML2 WG and the Semantic Web Deployment Working Group |
| 02:09 | <Hixie> | (I'd never heard of the Semantic Web Deployment Working Group before) |
| 02:28 | <TabAtkins> | erlehmann: There are many sensible options. The spec's suggest <p> and <b> method would work just fine. Ideally I might mark up the speaker with a <hx> and give it display:run-in. |
| 09:54 | <Lachy> | I don't get how Shelley can complain about the size of the spec being too large, and yet get all worked up about people suggesting that some features will end up being deferred to a future revision of HTML. |
| 10:15 | <Hixie> | it's probably similar to how she thinks that the "most compelling" argument for something she agrees with is my opinion, but that if she disagrees with something, that my opinion is worthless |
| 10:52 | <Hixie> | sorry, "a compelling", not necessarily the "most compelling" |
| 10:53 | <jgraham> | I don't get why people are so happy to let her dictate the terms of all discussion |
| 11:00 | <roc> | Hixie: isn't that common? If my enemy agrees with me *even though* he is evil, that is clearly strong evidence of the universal appeal of my position. On other hand, if my enemy disagrees with me, then that is only because he is evil. |
| 11:01 | <Hixie> | roc: I didn't say it was uncommon, but that doesn't make it acceptable |
| 15:50 | <mpilgrim> | i wonder if julian realizes he just walked into a trap |
| 15:50 | <mpilgrim> | probably not, since that's why they call them "traps" |
| 15:51 | <mpilgrim> | IMG isn't controversial *now*, but it was most certainly controversial when it was introduced (by a browser vendor, against the working group's wishes) |
| 15:52 | <mpilgrim> | it also wasn't in the first several drafts of XHTML 2, probably because XHTML 2 was TBL's recreation of what he thought HTML always should have been |
| 15:52 | <annevk2> | back back |
| 15:52 | <annevk2> | discussions on public-html are still somewhat painful to read |
| 15:53 | <mpilgrim> | references: http://lists.w3.org/Archives/Public/public-html/2009Dec/0173.html and http://lists.w3.org/Archives/Public/public-html/2009Dec/0174.html |
| 15:54 | <mpilgrim> | and TBL never wanted an IMG element |
| 15:54 | <annevk2> | I'm guessing some of the participants are not very happy with life |
| 15:56 | mpilgrim | is very happy with life, but finds that reading public-html distracts him from getting real work done |
| 15:56 | <mpilgrim> | like writing a book |
| 15:56 | <mpilgrim> | unlike irc, which isn't distracting at all :) |
| 15:57 | <annevk2> | IRC is nice |
| 15:58 | <annevk2> | I've never really seen significant process made on public-html discussions involving "two camps" with mutually incompatible goals |
| 15:58 | <annevk2> | I stopped participating in them, mostly |
| 16:00 | <annevk2> | The other reason is that most discussions feel like damage control, which I also tried to do in the CDF WG, and was no fun at all and mostly pointless in the end anyway |
| 16:01 | <annevk2> | Maybe we should just split the group and have two editions of HTML5. After a decade we can study the then contemporary practices and go to REC |
| 16:02 | <mpilgrim> | i'm pretty sure that's inevitable anyway |
| 16:02 | <mpilgrim> | maybe shelley et. al. could call their version "HTML5 Plus" |
| 16:03 | <annevk2> | sounds fine to me |
| 16:03 | <annevk2> | hopefully then everyone can be somewhat more happy instead of all this hostile crap |
| 16:04 | <mpilgrim> | i miss XHTML 2 |
| 16:04 | <mpilgrim> | it provided a nice safe playground where all these like-minded people could play without hurting anyone |
| 16:04 | <timz> | mpilgrim: they'd better call it HTML5less |
| 16:05 | mpilgrim | wonders if timz knows the history of "HTML Plus" |
| 16:05 | <timz> | hehe no :-) |
| 16:05 | <timz> | i'm having a look |
| 16:06 | <daedb> | this http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html ? |
| 16:08 | <timz> | haha, yes that would probably fit her/their ideas of what HTML5 should be |
| 16:09 | <mpilgrim> | the W3C has a long history of fucking up HTML by going off into la-la land for a few years while the world evolves without them |
| 16:09 | daedb | has never heard of HTML Plus before... |
| 16:09 | <mpilgrim> | HTML+ was one such effort (between HTML 1.0 and HTML 2.0) |
| 16:09 | <mpilgrim> | HTML 2.0 was basically "hey, let's see what browsers have actually implemented while we weren't looking" |
| 16:09 | <mpilgrim> | then they made HTML 3.0, which was similarly delusional |
| 16:10 | <mpilgrim> | then they threw that away and made HTML 3.2, which was basically "hey, let's see what else browsers have actually implmeented while we were busy masturbating" |
| 16:10 | <timz> | haha |
| 16:11 | <mpilgrim> | then they made HTML 4.0, which shockingly wasn't completely horrible (though it was horribly underspecified) |
| 16:11 | <timz> | you've been around all of those discussions or you just red the "history of html, a different perspective" |
| 16:11 | <mpilgrim> | then they gave up on HTML altogether, to the point of ignoring all W3C process and refusing to issue errata or integrate existing errata into point releases |
| 16:12 | <mpilgrim> | and started whole hog on XHTML |
| 16:12 | <mpilgrim> | XHTML 1.0 is literally HTML 4 + a few useless slashes |
| 16:13 | <mpilgrim> | oh, and a new MIME type and draconian error handling, which nobody uses (hi Sam) |
| 16:13 | <mpilgrim> | then XHTML 1.1, which nobody uses |
| 16:13 | <timz> | so is HTML5 a w3c idea or a community (vendors) idea ? |
| 16:13 | <mpilgrim> | then XHTML 2, which they spent almost a decade on and finally put out to pasture this year |
| 16:14 | <mpilgrim> | HTML5 was a community-led effort of browser vendors, standards wonks (like Hixie), and other interested parties |
| 16:14 | <mpilgrim> | all formerly quite active within the W3C |
| 16:14 | <mpilgrim> | they begged and pleaded with the W3C to let them work on HTML5 (or 4.1, or whatever, anything but XHTML 2) |
| 16:14 | <mpilgrim> | the W3C said no |
| 16:15 | <mpilgrim> | so they formed their own working group (WHATWG) |
| 16:15 | <mpilgrim> | and started from scratch (since the license of the HTML 4 specification forbids derivative works by non-W3C organizations) |
| 16:16 | <Lachy> | so then it seems this HTML+RDFa effort may just be the next round of crap to be attempted during the overall development of HTML, that will likely eventually die out like the rest. |
| 16:16 | <mpilgrim> | HTML+RDFa doesn't appear to have any chance at all of being a good spec until they redefine RDFa in terms of the DOM |
| 16:16 | <mpilgrim> | anything else is simply insane |
| 16:17 | <mpilgrim> | that's not to say people won't use it |
| 16:17 | <mpilgrim> | google rich snippets, etc. |
| 16:17 | <timz> | with limited vocabs that is |
| 16:17 | <mpilgrim> | but defining a new syntax "on top of" HTML in terms of a byte stream is just insane |
| 16:19 | <daedb> | heh, HTML+ had a <person> element :) |
| 16:20 | <mpilgrim> | http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element is fun related reading on the history of HTML |
| 16:20 | <Dashiva> | RDFa being based on the source text kinda makes me think of people parsing HTML with regex |
| 16:20 | <mpilgrim> | it (and the rest of this stuff) will form the basis of the introductory chapter of http://diveintohtml5.org/ |
| 16:20 | <Dashiva> | It seems to work until you start using it for anything significant |
| 16:21 | <mpilgrim> | indeed |
| 16:21 | <daedb> | <RENDER TAG="PROPNAME" STYLE="I">... that's... interesting :O |
| 16:22 | <timz> | mpilgrim: "but defining a new syntax "on top of" HTML", you are referring to RDFa ? |
| 16:22 | <mpilgrim> | yes |
| 16:23 | <mpilgrim> | it would appear that the current HTML+RDFa effort has zero chance of producing a good specification |
| 16:23 | <mpilgrim> | and if RDFa sees enough implementation, we'll need to do an RDFa5 retro-spec in a few years |
| 16:23 | <timz> | because it so explicitly bound to xml and rdf ? |
| 16:24 | <mpilgrim> | which will consist of reverse engineering google's implementation (or whoever ends up being the dominant consumer of RDFa on the public web) |
| 16:24 | <timz> | hmm, sounds like a good argument for keeping microdata |
| 16:24 | <Dashiva> | Hmm, yeah |
| 16:24 | <mpilgrim> | i'm not a fan of microdata either |
| 16:25 | <mpilgrim> | it's a decent enough solution to the stated problem |
| 16:25 | <Lachy> | mpilgrim, that's not surprising. I read the HTML+RDFa spec, and it's clearly been written by people with little clue about how to actually write specifications |
| 16:25 | <mpilgrim> | i'm just not a fan of the stated problem |
| 16:25 | <timz> | hehehe |
| 16:25 | <Dashiva> | I'm sure there will be a decent amount of complaints that Google is wilfully sabotaging RDFa by having a non-perfect implementation |
| 16:25 | <mpilgrim> | when people say "i want to extend HTML in arbitrary, private, and probably proprietary ways," the appropriate answer is "fuck you" |
| 16:27 | <Dashiva> | Extensibility has become one of those words that doesn't mean anything anymore |
| 16:28 | <Dashiva> | Like when the topic was making sure HTML5 was easily extensible by HTML6, it turned into a complaint about lack of DE |
| 16:28 | <Lachy> | mpilgrim, if their intention is for those extensions to appear on the public web and have 3rd party implmentations and websites using them, then that sure is the right answer |
| 16:29 | <Lachy> | Dashiva, even the concept of distributed extensibility doesn't mean much in practice. It's basically become an alias for full namespace support and RDFa |
| 16:30 | <Lachy> | and that's despite all the extension points already in HTML5 that allow 3rd party extensions, without using either namespaces or RDFa |
| 16:31 | <mpilgrim> | Lachy: haven't you heard? those aren't "real" extensibility points |
| 16:31 | <mpilgrim> | Paging True Scotsman, party of 1... True Scotsman, party of 1 |
| 16:31 | <Lachy> | the problem seems to be that proponents believe those to be the ultimate solution and are unwilling to accept any alternative solution, regardless of any evidence presented, nor evaluation of them against the use cases and problems they solve |
| 16:36 | <timz> | http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element <-- good read mpilgrim :-) |
| 16:37 | <mpilgrim> | 'twas fun to research and write, too |
| 16:39 | <Dashiva> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Dec/0022.html |
| 16:39 | <Dashiva> | Validation is overrated, I guess |
| 16:42 | <annevk2> | Removing the test seems like a very poor solution to the problem... |
| 16:43 | <daedb> | http://www.w3.org/MarkUp/HTMLPlus/htmlplus_21.html Wow, HTML+ has both <img> and <image>... did the alt attribute not exist when that was written? |
| 16:44 | <annevk2> | alt was invented for lynx at some point, not sure when |
| 16:44 | <mpilgrim> | the alt attribute was first added in HTML 4.0 |
| 16:45 | <mpilgrim> | lol |
| 16:45 | <mpilgrim> | i'd forgotten this salient little detail: |
| 16:45 | <mpilgrim> | when the XHTML 2 WG did finally re-introduce the <img> element, |
| 16:45 | <mpilgrim> | they gave it a different content type than <img> in XHTML 1 and HTML 4 |
| 16:46 | <mpilgrim> | they made it a non-void element |
| 16:46 | <mpilgrim> | the child content was the fallback content |
| 16:47 | <mpilgrim> | which is actually a great idea, but (i'm told) it royally breaks existing web content |
| 16:47 | <annevk2> | yeah, it seems they admitted compat was needed, but then at the same time did not |
| 16:47 | <annevk2> | or something |
| 16:47 | <mpilgrim> | "Also, <img> was reintroduced to XHTML 2, no doubt after a vigorous and healthy debate in which all parties treated each other with mutual respect. But now it has a different content model than <img> in XHTML 1 and HTML 4, which just goes to show that mutual respect is for chumps." |
| 16:47 | <mpilgrim> | http://microformats.org/discuss/mail/microformats-discuss/2005-October/001783.html |
| 16:56 | <daedb> | Cool, HTML+ had an element for figures :) |
| 17:27 | <Lachy> | daedb, so did HTML3 |
| 17:40 | <daedb> | Lachy: Hopefully it will stay this time. |
| 17:41 | <Lachy> | daedb, it might get dropped again, since we still can't resolve the caption element issue, and the current dt/dd model sucks |
| 17:53 | <timz> | what's the primary argument for not using caption ? |
| 17:53 | <timz> | in figure |
| 17:54 | <Lachy> | timz, compatibility with legacy parsing issues |
| 17:55 | <timz> | okay, so html5 documents have to be compatible with older parsers ? |
| 17:56 | <Dashiva> | No, html5 parsers have to be compatible with older documents |
| 17:56 | <Dashiva> | But the reverse is of course desirable |
| 18:07 | <daedb> | Lachy: I really hope not, it's one of my favourite new elements. |
| 21:32 | <zcorpan_> | http://www.w3.org/XML/2009/12/xml-stylesheet/ |
| 22:40 | <AryehGregor> | jgraham, given the choice between using RDFa and using nothing, many people would use nothing. Except when RDFa is the only thing that works with CC license readers, or Rich Snippets, or . . . |
| 22:41 | <AryehGregor> | I'm not worried about individual authors saying "Let's use RDFa, that sounds great!" I'm worried about organizations with some clout basing new de facto standards on it. |
| 22:41 | <AryehGregor> | Thus forcing everyone to use it. |
| 22:41 | <AryehGregor> | That's how it's worked its way into MediaWiki. |
| 22:42 | <AryehGregor> | I couldn't really argue with "But you have CC license-scraping bots and this would be great for Commons." |
| 22:42 | <AryehGregor> | (Wikimedia Commons, that is) |
| 22:42 | <AryehGregor> | RDFa is the only Creative Commons-approved way to embed license metadata, AFAIK. |
| 22:45 | <hsivonen> | AryehGregor: FWIW, I think committees don't get to vote to kill specs. they only get to vote on whether they allocate their resources to developing a given technology |
| 22:46 | <hsivonen> | for example, OASIS doesn't get to vote OOXML out of existence |
| 22:46 | <AryehGregor> | Well, the W3C could still endorse one or the other exclusively. |
| 22:46 | <hsivonen> | and the W3C didn't successfully vote HTML out of existence |
| 22:46 | <hsivonen> | AryehGregor: sure |
| 22:46 | <AryehGregor> | So could the HTMLWG. |
| 22:46 | <hsivonen> | yes |
| 22:46 | <AryehGregor> | That would have an impact. |
| 22:47 | <AryehGregor> | Just like disbanding the XHTMLWG had an impact. We get to say "No, don't use that, it's obsolescent." |
| 22:47 | <AryehGregor> | I doubt it will happen, though. |
| 22:47 | AryehGregor | shakes fist dramatically at the W3C |
| 22:47 | <hsivonen> | it had a publicity impact |
| 22:47 | <hsivonen> | but XHTML2 was already dead |
| 22:47 | <AryehGregor> | Yes, that's my point. |
| 22:47 | <hsivonen> | or s still very much alive depending on point of view |
| 22:48 | <AryehGregor> | If the W3C said "Hey, we decided RDFa is a bad idea, use microdata instead", then we could say to Creative Commons "Hey, why don't you encourage people to use microdata instead of RDFa? The W3C says so!" |
| 22:48 | <hsivonen> | AryehGregor: I observe that the W3C didn't stop work on XForms when it invited HTML5 (incl. Web Forms 2.0) in |
| 22:49 | <AryehGregor> | And I think that's silly too. :) |
| 22:49 | <AryehGregor> | (plus, I'm sure that will die soon enough, unless it has significant non-HTML users) |
| 22:51 | <hsivonen> | XForms got baked into ODF 1.0 |
| 22:51 | <hsivonen> | some approximation of RDFa got baked into ODF 1.1, according to rumors |
| 22:52 | <AryehGregor> | Yay. |
| 22:53 | <AryehGregor> | Oh well, none of this can possibly be more horrible than all the legacy HTML currently has to deal with. |
| 22:53 | jgraham | wouldn't put money on that |
| 22:54 | <jgraham> | (I am about to go sleep otherwise I might try to say something more useful) |
| 22:57 | <AryehGregor> | It's okay, it's unlikely there's anything useful to say in this discussion, except "Leave them alone for now and let God sort it out." |
| 23:05 | <Philip`> | Seems unfair to leave our mess for Him to clean up |
| 23:07 | <AryehGregor> | Well, it's really His mess, since He's the owner of the entire universe, after all. |
| 23:07 | <AryehGregor> | So everything is His. |
| 23:07 | <AryehGregor> | Also, it's His fault for telling us we can't murder people for promoting bad standards. |
| 23:11 | <Philip`> | That seems a little extremist |
| 23:11 | <AryehGregor> | Yes, I agree, it's just as likely they'd have murdered us, so we can't really blame Him on that score. |
| 23:12 | <AryehGregor> | We can blame the people responsible for the other standards, though. :) |
| 23:12 | <Philip`> | I don't think people who promote what you consider bad standards are that extremist either :-p |
| 23:19 | <zcorpan_> | "Sure; but if I've scheduled for it, I can deal with a hundred comments in |
| 23:19 | <zcorpan_> | a day -- that's not a problem." -- http://www.w3.org/mid/Pine.LNX.4.62.0912050854010.5629⊙hdc |
| 23:22 | <zcorpan_> | re rjavascript, i guess it would be useful with a linter for js performance pitfalls in modern implementations |
| 23:22 | <AryehGregor> | Haha, Google Site Performance is telling me my page is performing poorly because I don't have gzip compression enabled for http://www.google-analytics.com/urchin.js. |
| 23:22 | <AryehGregor> | \o/ |
| 23:22 | <jgraham> | Die with die |
| 23:23 | jgraham | obviously got distracted from going to bed |
| 23:23 | <zcorpan_> | or maybe browsers should have a way to log in the error console when the js engine has to do something expensive |
| 23:23 | jgraham | was talking about the "with" statement in case it wasn't obvious |
| 23:24 | <jgraham> | zcorpan_: It seems like something Dragonfly et. al. could tell you (depending on how much attaching a debugger affects the actual code) |
| 23:25 | <jgraham> | (But it would be nice if they could do per-call profiling with big warnings for things that hit slow paths) |
| 23:26 | <Philip`> | "slow paths" include falling off the JIT, which might be really quite difficult to explain to an average script developer |
| 23:26 | <Dashiva> | I'm a bit rusty on the edges, but isn't there some overlap between rjavascript and stuff like caja? |
| 23:27 | <zcorpan_> | Philip`: no need to explain why it's slow, just state that it's slow and suggest fast alternatives |
| 23:27 | <Philip`> | (There's a thing that gives JIT profiling information for code in SpiderMonkey but it's not the most user-friendly thing imaginable, by necessity) |
| 23:28 | <jgraham> | Philip`: That was basically what I had in mind hen I said "slow paths". I'm not sure why it would be hard to explain to people sufficiently motivated to profile their code |
| 23:30 | jgraham | really is going to bed now |
| 23:32 | <Philip`> | jgraham: It seems hard because they'd first need to understand what a tracing JIT is and how it works |
| 23:33 | <Philip`> | http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/ |
| 23:37 | <Philip`> | It's easy to suggest "don't use with" and "don't use eval", but I don't really see how you could automatically give suggestions for the more complex problems that occur |
| 23:40 | <Philip`> | (It would still be nice, just maybe not possible) |
| 23:56 | AryehGregor | hasn't figured out what "with" actually does yet, but gets the impression that it's cool and trendy and is vaguely disappointed if he shouldn't use it in JS for performance reasons |
| 23:56 | <Dashiva> | It's horrible and evil |
| 23:56 | <AryehGregor> | But also cool and trendy? |
| 23:56 | <Dashiva> | No |
| 23:57 | <Dashiva> | It was cool and trendy a few years ago, when having the shortest bookmarklets possible was a goal |
| 23:57 | <Dashiva> | And it sometimes appears in golfing, I suppose? |