| 16:25 | <zewt> | dreaming of a world where dom events never had the bubbles and cancelable flags |
| 19:44 | <Hixie> | zewt: the cancelable flag is a particularly useless one |
| 19:51 | <Ms2ger> | Pff |
| 19:51 | <Ms2ger> | Half the web is useless |
| 19:59 | <Hixie> | i dunno about _that_ |
| 20:02 | <zewt> | cancelable should be relegated to web-compatibility only and otherwise never even mentioned in specs |
| 20:02 | <zewt> | all events should be cancelable unless there's some weird web-compat reason otherwise |
| 20:17 | <Hixie> | zewt: it's less work for me to keep just speccing it as is (cancelable if canceling has an effect, not otherwise) than it would be to go through and change everything... |
| 20:17 | <zewt> | well, changing the ones that are implemented already is probably not worth it, but new events should just always be cancelable |
| 20:18 | <Hixie> | i think it'd be worse for half the events to make sense and the other half to be always cancelable than for us to continue to just do it |
| 20:21 | <zewt> | but always being cancelable makes more sense, since the whole concept of uncancellable events doesn't make sense :) |
| 21:04 | <Hixie> | zewt: sure it does |
| 21:04 | <Hixie> | zewt: i mean, it's not useful, but it makes sense |
| 21:04 | <Hixie> | zewt: it just means that the code that invoked the event will not check whether the event was canceled or nat |
| 21:21 | <gsnedders> | hsivonen, jgraham, abarth: do we really want tests for <main> in html5lib when it's not in the spec |
| 21:31 | <gsnedders> | Also, wow, nice. We now have the tokenizer depending on the parser. Yay. |
| 21:32 | <Hixie> | for what? |
| 21:33 | <gsnedders> | In html5lib. For the CDATA state. |
| 21:33 | <Hixie> | is that all? |
| 21:33 | <Hixie> | i thought the parser could switch the tokeniser state for other things too |
| 21:33 | <gsnedders> | Yeah, otherwise the parser just manipulates the tokenizer state. |
| 21:33 | <Hixie> | e.g. <plaintext> |
| 21:33 | <Hixie> | ah |
| 21:34 | <Hixie> | what's the difference here? |
| 21:34 | <gsnedders> | Tokenizer looking at the parser, not parser mutating tokenizer. |
| 21:35 | <Hixie> | ah, k. i guess i forget what's special about cdata. |
| 21:35 | <Hixie> | it's been a whiel. |
| 21:35 | <Hixie> | while. |
| 21:35 | <gsnedders> | Foreign content is top of the stack. |
| 21:35 | <Hixie> | ah, right |
| 21:35 | <Hixie> | could probably be implemented as state the other way too |
| 21:35 | <gsnedders> | Or bottom of the stack, depending on who's listening. |
| 21:35 | <Hixie> | oh man, that's something i should have listed as one of my biggest mistakes |
| 21:36 | <Hixie> | what a mess |
| 21:37 | <abarth> | gsnedders: The <main> thing seems like a tempest in a teapot |
| 21:38 | <abarth> | gsnedders: I'm just ignoring it figuring that it doesn't matter |
| 21:40 | <gsnedders> | abarth: I'm just somewhat irked by the tests failing :P |
| 21:41 | <abarth> | can we move them to a "proposed" directory or something? |
| 21:42 | <gsnedders> | Not really. html5lib just names tests *.dat, and there's little attention paid to file names in most runners, AFAIK. |
| 21:45 | <abarth> | I mean that we could move the "dat" file to a different directory |
| 21:45 | <abarth> | so that it's not run until the behavior it is tested is "accepted" in some sense |
| 21:46 | <gsnedders> | Yeah, I guess. hsivonen: you care if we move the main tests to a separate file in a proposed folder? |
| 22:10 | <Hixie> | do browsers not implement Element.querySelector()? |
| 22:12 | <Hixie> | nevermind, i'm a tool |