| 00:00 | <TabAtkins> | I need those soundtracks. MGS music is awesome. |
| 02:38 | <Dashiva> | othermaciej: "We will not do any numerical counting all the votes." ... "To the extent we apply any numerical analysis to the results" |
| 02:40 | <othermaciej> | Dashiva: belt and suspenders! |
| 02:40 | <othermaciej> | or were you pointing out my typo? |
| 02:40 | <Dashiva> | No, just wondering which one is closer to reality :) |
| 02:41 | <othermaciej> | the former |
| 02:42 | <othermaciej> | the latter I stated in case anyone gets worked up about, say, all 10 of the opera reps responding |
| 02:43 | <Dashiva> | The vast Opera-wing conspiracy |
| 02:44 | <Dashiva> | But okay, answer accepted |
| 04:42 | <erlehmann> | tach |
| 05:54 | <bfulgham_> | Does anyone know if there is a proposal for animating transitions on visibility so that 'hidden' could accordion the surround blocks? |
| 05:55 | <bfulgham_> | Or rather, animating on "display" to allow accordion or other effects? |
| 06:08 | <smaug> | bfulgham_: you're talking about css transitions? That discussion should happen on www-style⊙wo |
| 06:08 | <bfulgham_> | smaug: thanks |
| 08:55 | <Philip`> | http://software.intel.com/en-us/articles/xml-parsing-accelerator-with-intel-streaming-simd-extensions-4-intel-sse4/ - intriguing |
| 08:55 | <Philip`> | html5lib would be much faster if it was rewritten to use SSE assembly instead of Python |
| 08:57 | <annevk2> | do it! |
| 08:57 | <annevk2> | the problem is of course that the code will only run on a proprietary processor |
| 08:58 | Philip` | wonders what a non-proprietary processor would be |
| 08:59 | <annevk2> | one with a standardized programming API? |
| 08:59 | <annevk2> | I suppose it might still be proprietary in that case |
| 09:00 | <Philip`> | Is there such a thing that exists today and is used? |
| 09:01 | <Philip`> | Everyone just uses x86 and copies Intel (except occasionally when Intel copies AMD) so it seems the closest thing to a standard :-) |
| 09:15 | <Hixie> | http://www.google.com/search?hl=en&safe=off&esrch=RTSearch&gl=us&tbo=1&tbs=mbl:1&q=html5&aq=f&oq=&aqi=g10 |
| 09:15 | <Hixie> | woo |
| 10:44 | <annevk2> | Hixie, so you wanna combine the UI for streaming video/audio with geolocation, etc.? |
| 10:44 | <annevk2> | and most other things pages can ask for going forward, such as e.g. digital camera harddrive |
| 10:44 | <Hixie> | only if that is the best solution |
| 10:45 | <Hixie> | i don't know what the best solution is |
| 10:45 | <annevk2> | how would you combine that with the existing API? |
| 10:45 | <annevk2> | yeah I guess |
| 10:45 | <annevk2> | meh |
| 10:45 | <Hixie> | i wasn't really thinking of geolocation |
| 10:45 | <Hixie> | did tab update his proposal? |
| 10:46 | <annevk2> | for microdata? haven't seen anything |
| 10:48 | <nessy> | ohh! microdata! I wonder how that combines with video metadata |
| 11:45 | <Hixie> | what time is the htmlwg telecon these days? |
| 11:47 | <AryehGregor> | How is the telecon conducted? IRC? |
| 11:47 | <jgraham> | Telephone |
| 11:47 | <AryehGregor> | Amazing. |
| 11:47 | <jgraham> | Hence the "tele" |
| 11:47 | <AryehGregor> | "tele" means "distant". |
| 11:47 | <AryehGregor> | You know, like "telecommunications", and "teleport". |
| 11:47 | <jgraham> | Only in greek (or something) |
| 11:48 | <AryehGregor> | Okay, anyway. I guess Hixie will have to borrow someone's phone. :) |
| 11:48 | <gsnedders> | television is vision over telephone? |
| 11:48 | <jgraham> | Gah |
| 11:48 | <jgraham> | Hixie: 6pm CET on a Thursday |
| 11:48 | <AryehGregor> | Telepathy is detecting thoughts via telephone. |
| 11:48 | <Hixie> | jgraham: thanks |
| 11:48 | Hixie | changes to CET |
| 11:49 | jgraham | has never heard of a telecon that was not conducted by telephone |
| 11:49 | Hixie | changes back to PDT |
| 11:50 | <Philip`> | It's 1700Z according to two out of three repetitions of the time in the last reminder email |
| 11:51 | <Hixie> | figured i should at least be aware that i'm missing it this week since it's plausible i'll be awake at that time |
| 11:51 | <Hixie> | (though not near a phone unless i get some meeting room booked) |
| 11:52 | <AryehGregor> | Teleconferences can also be by video. |
| 11:53 | <Hixie> | we call those video conferences |
| 11:53 | <Hixie> | and they're much better than telecons though still almost as much of a waste of time |
| 11:56 | <AryehGregor> | What's wrong with IRC? |
| 11:57 | <Hixie> | or e-mail? |
| 11:57 | <Hixie> | beats me |
| 11:57 | <AryehGregor> | E-mail is a lot slower, it has definite disadvantages. |
| 11:57 | <AryehGregor> | Although also advantages. |
| 11:57 | <Hixie> | e-mail is far faster at making progress than telecons |
| 11:57 | <Hixie> | than scheduled telecons, i should say |
| 11:58 | <Hixie> | scheduled telecons cause working groups to only work immediately before and during a telecon |
| 11:58 | <Hixie> | so it becomes impossible for the group to make decisions except during the meeting |
| 11:58 | <Hixie> | which is ridiculous |
| 11:58 | <Hixie> | you can see this e.g. from the way the chairs of the htmlwg are only able to make decisions on tuesdays |
| 11:58 | <Hixie> | scheduled irc meetings would have the same problem |
| 11:59 | <AryehGregor> | Isn't it an HTMLWG policy that decisions are only made by e-mail and such? There's something about allowing asynchronous communication. |
| 11:59 | <Hixie> | yes, but subgroups (like the chairs) can arrange for their own decisions to be synchronous if they want |
| 12:00 | <Hixie> | so long as membership in the group isn't a requirement to influence decisions |
| 12:02 | AryehGregor | is glad to see that there will be no actual votes, just decisions by a cabal of three chairs instead of one editor |
| 12:03 | <AryehGregor> | Although theoretically the decision will be what causes the least strong objections instead of the one they think is technically best, so it's somewhat different. |
| 12:05 | <Philip`> | I guess "least strong objections" means you should threaten to shout loudly and file FOs etc if you don't get your way, so that your objections carry more weight |
| 12:06 | <Hixie> | yeah i'm curious to know how they intend to weigh rationales if not in the same way that i did when examining the issue as the editor |
| 12:06 | <AryehGregor> | Yes, that sounds like the strategically appropriate response to such a policy. |
| 12:06 | <AryehGregor> | Presumably they're allowed to ignore you if they think you're faking, though. |
| 12:07 | <jgraham> | Hixie: It is not impossible that they will weight rationales in the same way that you did but come to a different conclusion |
| 12:07 | <AryehGregor> | Honestly, no one can really fault them too much no matter what decision they make on something like microdata, since obviously they can't please everyone. |
| 12:07 | <jgraham> | But I agree that is not what they have stated they will do |
| 12:08 | <Hixie> | surely if they get a different conclusion then by definition they've used a different method of weighing arguments :-) |
| 12:08 | <Hixie> | i'm not saying there's anything wrong with that |
| 12:08 | <Hixie> | i'm just wondering what their method will be |
| 12:08 | <AryehGregor> | Even if they secretly just pick whatever solution they like, people will probably still end up being more satisfied because they were told it's a compromise rather than "I think you're wrong, too bad". |
| 12:09 | <Hixie> | (in fact i'd say that they _should_ use a different method, since otherwise the whole escalation process is pointless since they'd always agree with me) |
| 12:09 | <AryehGregor> | It wouldn't be pointless politically even if they always agreed with you, only technically. |
| 12:10 | <Hixie> | technically is what i care about |
| 12:10 | <AryehGregor> | Then why are you having anything to do with the W3C? :) |
| 12:10 | <jgraham> | Hixie: Well they can use the same _method_ but get different results due to different inputs |
| 12:10 | <Hixie> | AryehGregor: patent policy and to get microsoft's feedback |
| 12:10 | <Hixie> | AryehGregor: in retrospect, as i've said before, i think we would have been better off just getting our own patent policy |
| 12:11 | <jgraham> | e.g. you might tend to weigh arguments that correspond with your own experience more highly |
| 12:11 | <AryehGregor> | Well, but that's basically political. |
| 12:11 | <AryehGregor> | I'd think the WHATWG with its own patent policy would be at a significant disadvantage without Microsoft on board. |
| 12:11 | <Philip`> | The three chairs should meet on a wind-swept heath and drop the arguments into a cauldron and then dance around it until a conclusion reveals itself to them |
| 12:12 | <Hixie> | jgraham: i guess if you don't consider the weighing function part of the weighing function... :-) |
| 12:12 | <Hixie> | AryehGregor: in practice we've gotten very little useful input (or indeed any input) from microsoft |
| 12:12 | <AryehGregor> | Yes, but they at least claim they'll implement HTML5 at some point, which is something. |
| 12:13 | <AryehGregor> | I really meant from an implementation perspective, not feedback. |
| 12:13 | <AryehGregor> | It's not much good if Microsoft doesn't implement it. |
| 12:13 | <Hixie> | i don't think the w3c affected that really |
| 12:13 | <AryehGregor> | Maybe not. Too late now, I guess. |
| 12:14 | <AryehGregor> | Hixie, please tell your superiors at Google that they need to kill Microsoft faster, thanks. |
| 12:14 | <jgraham> | Hixie: The exact weighing function isn't exactly part of the "method" |
| 12:14 | <Hixie> | google has no intention of killing microsoft, we actually wish microsoft would compete better to give us more of a run for our money |
| 12:14 | <Hixie> | but that's another story |
| 12:15 | <Hixie> | jgraham: fair enough |
| 12:15 | Philip` | imagines a Google monopoly would be about as bad as a Microsoft monopoly |
| 12:15 | <gsnedders> | But they "do no evil"! :P |
| 12:15 | <AryehGregor> | Philip`, you mean like all the terrible effects we've been seeing from their monopoly on search? |
| 12:16 | <jgraham> | Google monopoly? Do you go round a little board and buy up different websites and build adverts on them to collect money? |
| 12:16 | <AryehGregor> | Slightly lower market share than MS in the OS market, but still. |
| 12:16 | <Hixie> | AryehGregor: google has nowhere near a monopoly on search |
| 12:17 | <Philip`> | Google doesn't seem to have shown any reluctance to develop and deploy their own private web technologies that are largely focused on the needs of other parts of Google, without much input from other vendors |
| 12:18 | <AryehGregor> | Well, that's called "not being a bunch of hippie open-source freaks", not "being monopolistic". :) |
| 12:19 | <AryehGregor> | As long as they don't try to lock you in to anything. |
| 12:19 | <AryehGregor> | Which generally they don't. |
| 12:19 | <AryehGregor> | There's some tie-in between their services, but usually pretty weak. |
| 12:19 | <AryehGregor> | Okay, I was supposed to leave ten minutes ago, bye. |
| 12:19 | <Hixie> | later |
| 12:40 | <boblet> | interesting—HTML5-style charset declaration isn’t stronger than user-declared character encoding in FF3.5.5, but http-equiv style one is |
| 12:41 | <Hixie> | yeah okcool.de has a comment to that effect |
| 12:42 | <Hixie> | i haven't been able to get more info on it -- do you have test cases showing this? |
| 12:43 | <boblet> | Hixie: is that to me? I’ll up one… |
| 12:43 | <Hixie> | yes :-) |
| 13:19 | <boblet> | Hixie: crap—testing methodology fail. Sorry. Here’s the question that made me check it: http://doctype.com/doesnt-html-5-meta-charset-tag-work |
| 13:19 | <boblet> | Hixie: I couldn’t reproduce the error |
| 13:29 | <boblet> | Can <nav> be used for site search or pre/next page links? I think no, but heard yes for search… |
| 13:31 | <boblet> | (I’ve also seen “read more…” links marked as <nav> btw ;-) |
| 13:32 | <daedb> | I can see <nav> being used for prev/next page links, but I wouldn't use it for search or read more links... |
| 13:53 | <Philip`> | boblet: Seems odd |
| 13:53 | <Philip`> | Could be his HTML/text editor detects the meta http-equiv and saves as UTF-8 in that case, and ISO-8859-1 otherwise, or something |
| 13:54 | Philip` | doesn't know what else it would be, especially since he says he's setting the HTTP Content-Type charset too |
| 13:56 | <Philip`> | boblet: I hope <nav> is okay for next/previous, since the multipage HTML5 spec uses it for that |
| 14:12 | <boblet> | Philip`: yeah that Doctype.com q is peculiar. hopefully I’ll hear back |
| 14:16 | <boblet> | Philip`: Looking at the HTML5 multipage spec, next/prev page links are part of a larger nav block. Do you think it’d apply on eg the meter/noscript links on http://dev.w3.org/html5/markup/nav.html ? |
| 14:17 | <boblet> | Philip`: Mike’s used div.nav span.nav-prev and span.nav-next |
| 14:19 | <daedb> | boblet: I'd probably use <nav> for those links... |
| 14:20 | <Hixie> | boblet: weird. there's a comment in the source of okcool.de that talks about this also, and i can't get anyone to explain to me why. |
| 14:21 | <Philip`> | boblet: I imagine he used that because the W3C pubrules don't like HTML5 markup |
| 14:23 | <Hixie> | who's doing webidl these days? |
| 14:37 | <Hixie> | indeed, is there a bug tracker for webidl? |
| 14:37 | <boblet> | Hixie: re: charset, maybe it’s just a problem somewhere else (server header, tools…) |
| 14:37 | <Hixie> | maybe... |
| 14:38 | <boblet> | Philip`: ok that makes sense |
| 14:38 | <Hixie> | hmm, webidl has a bug component in bugzilla, but not bugs |
| 14:38 | <boblet> | I’m surprised that <nav> applies to prev/next links, as they’re often just a single link (not a block), and there’s already rel="next/prev" |
| 14:39 | <Philip`> | Judging by the relevant code (around http://mxr.mozilla.org/mozilla1.9.1/source/intl/chardet/src/nsMetaCharsetObserver.cpp#319 (for Firefox 3.5)), it looks like http-equiv charset and meta charset are reported indistinguishably, so it shouldn't be possible for one to work and not the other |
| 14:39 | <boblet> | Hixie: would you use <nav> for site search form? |
| 14:40 | <Hixie> | would you have a "skip navigation" link for a site search form? |
| 14:40 | <Hixie> | Philip`: yeah, i never found any distinctions when doing the testing way back when |
| 14:41 | <Philip`> | (That does indicate <meta charset=utf8 foo=bar won't work, though) |
| 14:41 | <Philip`> | Uh, <meta charset=utf8 foo=bar> |
| 14:45 | <Hixie> | oh? |
| 14:46 | <Philip`> | Hmm, but that's not what happens in practice |
| 14:47 | <Philip`> | (The GetCharsetFromCompatibilityTag is only in the 'else' of a thing that checks for the number of attributes) |
| 14:51 | <Philip`> | Maybe that's not the code that's actually used |
| 14:51 | <boblet> | Hixie: I wouldn’t, but I can see some would. Yeah, that’s the nub |
| 14:52 | <Hixie> | boblet: i think it'd be fine to use <nav> for that, but also fine not to |
| 14:53 | <Hixie> | basically, don't use <nav> unless you think <section> would also be appropriate, with an <h1>Navigation</h1>. |
| 14:53 | <boblet> | Hixie: I really love that a lot of the structural element usage is almost up to authors. That’s what most people hate, of course, but still :) |
| 14:53 | <Hixie> | it'd be extremely difficult, and only mildly useful, to be more specific than we already are |
| 14:53 | <Philip`> | Whatever code Firefox 3.5 is using, it also accepts things like <meta notcharset="utf-8"> |
| 14:53 | <Hixie> | and we're already waaaay more specific than html4 ever was |
| 14:54 | <Philip`> | so it can't just be the attribute-based extracter |
| 14:54 | <boblet> | makes it harder to write best practice info, but it’s much more interesting |
| 14:55 | <Hixie> | best practice is "don't use <div> and don't use class=''", basically |
| 14:55 | <Hixie> | but often you have to use one or the other |
| 14:55 | <Hixie> | since html isn't _that_ expressive, even with all the new stuff |
| 14:56 | <boblet> | Hixie: why not class? that seems to becoming a best practice with eg @stubbornella’s CSS performance info |
| 14:58 | <boblet> | I’ve actually started using her “h2 .h2 {}” style classes, then in html <section><h1 class="h2"> |
| 14:59 | <Hixie> | o_O |
| 14:59 | <Hixie> | why would you do that |
| 15:00 | <boblet> | not as pure HTML but better than “section section h1, article section h1 {}” |
| 15:00 | <Hixie> | oh well, yes, we need to figure out a better css selector solution for nested section headers |
| 15:00 | <Philip`> | boblet: Why not use <h2>? |
| 15:00 | <Hixie> | i meant theoretical best practice in the future, not best practice now |
| 15:01 | <boblet> | also I think class="h2" has semantic meaning |
| 15:01 | Hixie | wonders when breakfast service is _supposed_ to start at his cafe |
| 15:01 | <boblet> | Philip`: HTML5-style headings—reset to <h1> with each section |
| 15:01 | <Hixie> | no, you can use whatever level you want |
| 15:01 | <Hixie> | <section><h2></h2></section> and <section><h1></h1></section> mean the same thing |
| 15:02 | <boblet> | well, I think it was maintain correct heading levels taking nesting into account, or reset to <h1> each time you start a new section, no? |
| 15:02 | <Hixie> | aha, 8am |
| 15:02 | <Hixie> | another hour |
| 15:02 | <Hixie> | no, it resets inside each <section> |
| 15:03 | <Hixie> | the highest <hx> within each section (er, lowest, i guess, closest to <h1>) is the heading |
| 15:03 | <boblet> | but not to <h1>? interesting |
| 15:03 | <Hixie> | well the best practice is you should have only one <hx> per <Section> |
| 15:03 | <Hixie> | so it doesn't make any difference |
| 15:03 | <boblet> | so you could skip levels, eg <h1></h1> <section><h3></h3>… |
| 15:04 | <Hixie> | you can use <body><h6></h6><section><h3></h3><nav><h1></h1></nav></section></body> means the same as <body><h2></h2><section><h4></h4><nav><h6></h6></nav></section></body> |
| 15:04 | <Hixie> | ...which means the same as <body><h1></h1><section><h1></h1><nav><h1></h1></nav></section></body> |
| 15:04 | <Hixie> | each section does its own heading hierarchy |
| 15:05 | <boblet> | but wouldn’t that mean that it’s easier to just start at <h1> for each new section? |
| 15:05 | <boblet> | assuming you’re doing crazy stuff like applying styles via classes? :) |
| 15:05 | <Hixie> | apparently not, since you use classes :-) |
| 15:05 | <boblet> | haha |
| 15:05 | <Hixie> | <h1 class="h2"> is not as easy as <h2> :-) |
| 15:06 | <boblet> | hrm… I must ponder this more :) at this rate I’ll never release this site |
| 15:07 | <workmad3> | and even though <body><h1></h1><section><h2></h2></section></body> means the same thing no matter what level of heading you use to a machine, there are still ways of doing it that are clearer to people :) |
| 15:07 | <Hixie> | indeed |
| 15:08 | <workmad3> | and clearest to a human is probably either <h1> all the time or <hx> appropriate to the sectioning level... |
| 15:08 | <Hixie> | agreed |
| 15:08 | <workmad3> | (which I believe are the two examples given in the spec :) ) |
| 15:09 | <boblet> | You might want to check out http://j.mp/6FMCDi — @stubbornella’s OOCSS presentation |
| 15:10 | <Hixie> | will do |
| 15:10 | <boblet> | it’s quite a different way to approach things. It’s definitely changed some of my perceptions |
| 15:11 | <boblet> | workmad3: I guess <h1 class="h2"> is just the first one with a cop-out for easier CSS selector writing |
| 15:11 | <boblet> | (at least, that’s what I thought) |
| 15:11 | <workmad3> | boblet: I personally see that as an abomination :) |
| 15:12 | <boblet> | hahaha |
| 15:12 | <workmad3> | and besides, why use a <h1> there... it's *much* simpler to use a <div>... so then you have <div class="h1">, <div class="em">, <div class="font">... |
| 15:13 | <boblet> | I can definitely see how on a large popular site writing long CSS selector chains would gradually kill you tho |
| 15:13 | <Hixie> | woah, that suggestion on slide 68 (the <h1 class="h2"> thing) is crazy |
| 15:13 | <Hixie> | if you're finding that you're applying h2 styles to an h3, then your semantics are wrong |
| 15:13 | <boblet> | Hixie: you’re killing me here |
| 15:13 | <boblet> | :D |
| 15:13 | <Hixie> | the rest of it so far is good |
| 15:14 | <Hixie> | i also disagree with slide 92 |
| 15:14 | <boblet> | I think it‘s to address the ballooning of selectors problem; like specifying each case of clearfix rather than applying a .clearfix or .group style |
| 15:15 | <Hixie> | i think styling elements is the way to go, and styling classes should be the exception |
| 15:15 | <Hixie> | but that might just be that i think you should define defaults first, which seems to be the same, but said differently |
| 15:15 | <boblet> | well, she does say “(unless defining defaults)” |
| 15:17 | <Hixie> | yeah |
| 15:17 | <Hixie> | i strongly agree with what she says at the end |
| 15:17 | <Hixie> | i don't understand why we don't have better tools |
| 15:18 | <boblet> | @stubbornella addresses that too http://j.mp/7i7Dfe — CSS Wish List |
| 15:19 | <boblet> | adding programatic concepts like mixins to CSS |
| 15:19 | <workmad3> | boblet: check out sass :) |
| 15:20 | <boblet> | haha—planning to do so for this site (have it open in a tab somewhere here) |
| 15:20 | <workmad3> | sass does have mixins... and the ability to do maths, etc. in css files |
| 15:21 | <workmad3> | and it gets compiled down to normal CSS and can even be minimised, etc. :) |
| 15:22 | <boblet> | workmad3: yeah I’m looking forward to checking out stylesheet size differences (why I didn’t start with it) |
| 15:22 | <boblet> | ok thanks for the food for thought all. Bed calls |
| 15:22 | <workmad3> | I need chocolate and coffee myself |
| 15:22 | <workmad3> | but then it's only 3:30 p.m. for me :) |
| 15:23 | <boblet> | Will hopefully have an HTML5 site with the HTML5 articles I’ve written so far on it tomorrow to announce |
| 15:23 | <boblet> | later |
| 15:26 | <ray> | h1 class="h2"? |
| 15:30 | <miketaylr> | <div class="span"> |
| 15:30 | <ray> | html5 has a way to set the charset besides meta http-equiv? |
| 15:31 | <Hixie> | you can just say <meta charset="..."> |
| 15:31 | <Hixie> | (or use HTTP headers) |
| 15:33 | <ray> | that's nice |
| 15:33 | <Hixie> | it even works in existing browsers |
| 15:33 | <ray> | meta http-equiv=blahblahblah was the only thing i couldn't type from memory |
| 15:34 | <Hixie> | you could type the DOCTYPE from memory? :-) |
| 15:34 | <ray> | :) |
| 15:34 | <Hixie> | i'm impressed :-) |
| 15:37 | <Hixie> | on an unrelated note, i'm amazed that my last e-mail to shelley actually convinced her |
| 15:38 | <Hixie> | i guess it pays to be thorough with each e-mail and to show how one is contradicting oneself rather than just replying to the latest comment each time, ignoring earlier ones |
| 15:43 | jgraham | would like to dispell the notion that only people who don't think the use cases should be addressed support microdata |
| 15:43 | Philip` | wonders where Shelley said she was convinced |
| 15:44 | <Hixie> | Philip`: she didn't, but she didn't reply to my e-mail, which is the only sign i've ever seen of her admitting she was wrong on anything |
| 15:44 | <Philip`> | It seems an equally likely hypothesis is that she had already made all the points she wanted to make and was fed up with going in circles and therefore stopped |
| 15:46 | <Hixie> | that'd be a first, if so |
| 15:46 | <Philip`> | jgraham: If you do that, you could also dispel the notion that the use cases are synonymous with the Semantic Web community |
| 15:47 | <Hixie> | anyone got a suggestion for a good e-mail that summarises the storage mutex issues? |
| 15:48 | Philip` | doesn't care about Semantic Webs or Linked Data or RDF or anything, but still thinks it's probably useful to have a way to easily encode structured data in a web page so screen-scrapers are easier to write |
| 15:49 | <Hixie> | that's basically google's position too |
| 15:50 | <jgraham> | Philip`: I habe a draft of an email that says more or less that that (I wrote it before complaining on IRC even) but I am never convinced that actually sending email is a good idea |
| 15:50 | <jgraham> | *have |
| 15:53 | gsnedders | grumbles about not having a clearly defined difference between es-discuss (where discussion is most about ES5) and es5-discuss (where discussion is mostly about ES5) |
| 15:53 | <Philip`> | gsnedders: Kind of like public-html and whatwg? |
| 15:53 | <Philip`> | (on good days) |
| 15:53 | <gsnedders> | But both mailing lists are on the same server. |
| 15:53 | <Philip`> | (where public-html discussion is mostly about HTML5 and not about HTML WG processes) |
| 15:54 | <Philip`> | s/good/rare/ perhaps |
| 15:55 | <jgraham> | gsnedders: Well es-discuss is mostly about es.next these days |
| 15:55 | <jgraham> | But I think there are too many mailing lists |
| 15:55 | <Hixie> | woo, breakfast time |
| 15:55 | <Hixie> | bbl |
| 16:59 | Philip` | thinks the HTML WG should have a poll to determine what poll options to provide in a second poll |
| 16:59 | <TabAtkins> | Philip`: I'm not sure that's a good idea. Can we have a poll about it? |
| 17:00 | <gsnedders> | TabAtkins: I don't think a poll for that is worthwhile. Poll? |
| 17:02 | <TabAtkins> | Poll? Poll poll poll-poll. |
| 17:50 | <jgraham> | othermaciej: It would be nice if the issues list had the name or shortname of each issue somewhere |
| 17:50 | <othermaciej> | jgraham: good point |
| 17:51 | <othermaciej> | jgraham: I'll look into that when I get into the office |
| 17:51 | <jgraham> | othermaciej: Thanks |
| 17:52 | <gsnedders> | othermaciej: For the poll on microdata, is it one vote per W3C Member or one vote per WG representive |
| 17:53 | <jgraham> | gsnedders: It is not a poll |
| 17:53 | <othermaciej> | gsnedders: I have a three-part answer for that |
| 17:53 | <othermaciej> | 1) it's not a vote |
| 17:54 | <othermaciej> | 2) multiple representatives of an organization are free to each state their response |
| 17:54 | <othermaciej> | 3) if we *do* somehow count (which we don't intend to), we will weight all responses from a single organization as one vote |
| 17:54 | gsnedders | had the understanding of the W3C process that it didn't matter how the outcome of the poll was judged, just whether it was a formal WG vote or not, jgraham |
| 17:55 | <othermaciej> | it is not a formal Vote |
| 17:55 | jgraham | wonders how that works if different respondents from the same organisation say different things |
| 17:55 | <othermaciej> | jgraham: might end up counting as 0.5 in favor of each option - but it likely won't come up, since we don't plan to count |
| 17:56 | <jgraham> | othermaciej: Sure :) |
| 17:56 | <othermaciej> | we just don't want people to complain or be suspicious if there are, say, 7 Apple responses or 10 Opera responses |
| 18:11 | <Philip`> | Ooh, impressive, 3 out of 3 of the times listed in the new telecon reminder email are correct and consistent |
| 18:11 | <Philip`> | (Too bad the date in the subject is wrong) |
| 20:49 | <MattCampbell> | Which html5lib tree implementation is best for round-tripping HTML? That is, I want to parse some HTML, possibly do some manipulations, and then serialize the tree back to HTML. |
| 20:50 | <MattCampbell> | I'm talking about the Python implementation. |
| 20:55 | <gauthierm> | if an autoplaying video is removed from the document using removeChild(), should it keep playing? |
| 21:07 | <kinetik> | gauthierm: yes |
| 21:08 | <gauthierm> | kinetik: thanks. Bug in FF 3.5 then. |
| 21:08 | <kinetik> | gauthierm: "Media elements must not stop playing just because all references to them have been removed; only once a media element to which no references exist has reached a point where no further audio remains to be played for that element (e.g. because the element is paused, or because the end of the clip has been reached, or because its playbackRate is 0.0) may the element be garbage collected." |
| 21:08 | <gauthierm> | ah sorry, I meant NOT a bug in FF 3.5 |
| 21:09 | <kinetik> | i think there actually is a bug where the media is stopped early in some cases |
| 21:09 | <kinetik> | which should be fixed in 3.6 |
| 21:09 | <gauthierm> | it is a bit weird that audio can keep playing with no way for the user to stop it |
| 21:12 | <Philip`> | I guess it helps if you want to write a page that has sound effects, since you don't need to manually keep all the audio elements in the page and then clean them up once they've finished playing |
| 21:13 | <gauthierm> | kinetik: is the bug you're referring to triggered when removing a media element that is currently playing? |
| 21:14 | <gauthierm> | FF seems to only continue playing if the media is set to autoplay and the element is removed before it starts playing. |
| 21:14 | <gauthierm> | WebKit stops when the element is removed in both cases. |
| 21:22 | <jgraham> | MattCampbell: It shouldn't matter in theory |
| 21:22 | <kinetik> | gauthierm: there was no self-reference to the media when playing, so it'd die at some random point after it was removed from the document and no longer referenced |
| 21:22 | <kinetik> | gauthierm: https://bugzilla.mozilla.org/show_bug.cgi?id=518659#c6 |
| 21:23 | <jgraham> | I always use lxml although there are some bugs with that in corner cases (some of the XMLness checking code is known-wrong, it can't represent all doctypes, etc.) |
| 21:24 | <jgraham> | but it is the best tested |
| 21:24 | <MattCampbell> | If lxml is the best tested, then I'll use that. |
| 21:24 | <jgraham> | beautifulsoup should be avoided |
| 21:28 | <gauthierm> | kinetik: I'm a bit confused. Here is my test case: http://labs.silverorange.com/files/mozilla/video-testcase/test-case.html When the video starts playing and you click remove, audio stops instantly. If you click remove before the video loads (still a black box) it continues buffering and then starts playing in the background. |
| 21:29 | <MattCampbell> | How tolerant is html5lib's parser with regard to malformed markup? Can it handle any markup that a current browser can? |
| 21:31 | <Philip`> | MattCampbell: It will parse any sequence of bytes and never stop with a fatal error (excepting some of the bugs with lxml etc) |
| 21:32 | <Philip`> | and will recover from errors in a way that should be sufficiently compatible with current browsers that future browsers will be happy to adopt the same parsing algorithm |
| 21:32 | <kinetik> | gauthierm: that's because removing an active media element causes it to pause |
| 21:35 | <kinetik> | er, so, my original answer was incorrect, sorry |
| 21:35 | <MattCampbell> | jgraham: Mainly out of curiosity, why should BeautifulSoup be avoided? |
| 21:36 | <Philip`> | MattCampbell: It lacks features (like namespace support) and has quite a few bugs that we don't how to work around, if I remember correctly |
| 21:38 | <MattCampbell> | So it seems that html5lib + lxml.etree might be suitable for screen-scraping apps, which is what BeautifulSoup was intended for. |
| 21:41 | <Philip`> | It ought to work for that |
| 21:41 | <Philip`> | If not, please file bugs :-) |
| 21:42 | <Philip`> | (A while ago the BeautifulSoup author sounded interested in replacing its parser with html5lib, which would be good if you prefer that API, but I don't know if anything's happened with that) |
| 21:43 | <MattCampbell> | I have no particular API preference; since lxml seems to be the most tested, I'll use that. |
| 21:46 | <Philip`> | Some of the bugs with lxml may cause fatal errors if you try parsing lots of random real pages, but the bugs ought to be easy to fix and then it'll be robust |
| 21:47 | <gauthierm> | kinetik: ah, that makes more sense :) There is a bug in FF then because the networkState is NETWORK_LOADING when the element is removed but FF is NOT acting as if the pause() method was called. I will file on bugzilla. |
| 21:47 | <kinetik> | gauthierm: great, thank you |
| 22:20 | <Hixie> | TabAtkins: man, i hope you're able to keep track of all the change proposal changes in doing your updates |
| 22:20 | <Hixie> | i can barely work out what the proposal is anymore |
| 22:21 | <TabAtkins> | It's, well… It's a good thing I procrastinate. |
| 22:22 | <Hixie> | heh |
| 22:22 | <Hixie> | you have just a few more hours, i guess :-) |
| 22:28 | <othermaciej> | you have until 9 AM Pacific Time tomorrow, basically (i.e. the time of the telecon) |
| 22:29 | <TabAtkins> | The hope is that from the time I start to the time I turn it in, no more change proposals. |
| 22:31 | <hober> | TabAtkins: some feedback on your counter proposal |
| 22:31 | <hober> | TabAtkins: for what it's worth, here's what I think is one of the more compelling reasons for having features in HTML like <time>, the microdata attributes, etc. |
| 22:32 | <hober> | TabAtkins: HTML's existing extensibility mechanisms (class="" etc.) are pretty good, but could use some enhancing to better support groups like the Microformats community (who build on top of HTML.) |
| 22:32 | <hober> | TabAtkins: <time>, microdata, etc. simply are that enhancing of HTML's extenisbility mechanisms over what is in HTML4. |
| 22:32 | hober | didn't even mention RDFa |
| 22:32 | <hober> | :) |
| 22:33 | <TabAtkins> | Heh, but it's sort of dishonest then. RDFa could also be used to do that. Microdata just does it better and more easily. |
| 22:33 | <hober> | ... which is why we should incorporate Microdata into HTML5 and not RDFa, no? :) |
| 22:34 | <TabAtkins> | It's why we should *support* Microdata. It doesn't, by itself, mean we should keep it in HTML5. |
| 22:34 | <TabAtkins> | But it is a good support for the actual reasons. |
| 22:35 | <hober> | Hmm. No, I think the point I'm trying to make *does* support "keeping microdata in HTML5", in much the same way that my argument supports "keeping class='' in HTML5" |
| 22:36 | <TabAtkins> | Not if there was compelling evidence that Microdata could serve the same noble purpose in its own separate spec. |
| 22:37 | <hober> | I have an insufficiently powerful imagination, I guess: I can't see the difference between Microdata and the other extensibility points of HTML. No one actually wants class='' to be in a different spec, right? |
| 22:38 | hober | studiously ignores the XHTML Role Attribute Module (because what is role='' if not "class='' 2: class harder"?) |
| 22:40 | <TabAtkins> | Oh, don't worry. I don't see a difference either. I'm just saying. |
| 23:15 | <Hixie> | i really don't understand why we would keep class="" in html5 if we didn't keep microdata, personally |