| 00:49 | <bencc> | can a web worker script be loaded from a different domain? |
| 01:56 | <padenot> | what should I do if I found a typo in the html spec ? send a email to whatwg⊙lwo ? |
| 02:33 | <Hixie> | padenot: mention it in the box at the bottom left of the spec and hit the button there |
| 02:38 | <padenot> | Hixie: done, thank you. |
| 02:39 | <Hixie> | padenot: thank _you_! |
| 02:39 | <Hixie> | padenot: if you want to be acknowledged in the spec, mention your name in the bug, too |
| 05:14 | <AryehGregor> | annevk, I only asked because smaug pinged me about it. I'm okay with no spec change yet -- the relevant implementers are aware of it (at least Gecko/WebKit). |
| 05:16 | <annevk> | Opera/IE too if they follow bug files against DOM which they should |
| 05:16 | <annevk> | goes for every vendor really |
| 05:16 | <AryehGregor> | Hixie, MediaWiki uses the user id as the salt. As Philip` points out, the username doesn't work, unless either a) the username never changes, or b) the user is required to enter their password before the username change takes effect (bad if you want admins to be able to unilaterally change names), or . . . there are probably other things you could do. |
| 05:17 | <AryehGregor> | Also, it would be a problem if the username is not bit-for-bit what the user entered -- e.g., if whitespace is trimmed, or it's case-insensitive, etc. |
| 05:17 | <AryehGregor> | Applications tend to do various sorts of application-specific username normalization. |
| 05:19 | <AryehGregor> | Using user id as the salt only has the problem that they don't vary as much as a smallish random ASCII string -- there's probably a user 1, user 2, etc. -- so it doesn't provide as much protection as you'd want against dictionary attacks. |
| 05:20 | <AryehGregor> | Ideally you'd probably want to use a salt that's itself longer than any feasible dictionary, so that attackers can't use a dictionary to recognize the hash of even an empty-string password. |
| 05:20 | <AryehGregor> | (by "itself longer than any feasible dictionary" I of course mean "longer than could be cracked by any feasible dictionary even before you add the password") |
| 05:22 | <AryehGregor> | The latter isn't an issue for MediaWiki, though, because it uses md5(id + '-' + md5(password)), so the thing you're hashing is always long. There's not much likelihood of being able to save anything over using brute force here. |
| 09:19 | <rafaelw_> | hsivonen: ping. |
| 14:22 | <jgraham> | Hmm, browsers seem intent on defying me |
| 14:23 | <jgraham> | If I add an async script (e.g. through DOM methods), then stop sending data for the main document for a bit (e.g. by doing ob_flush(); flush(); sleep() in PHP) then I would expect the (fast-loading) async script to have run before parsing resumes |
| 14:24 | <jgraham> | But either I am doing it wrong or that isn't happening |
| 14:24 | <jgraham> | *sleep(10) |
| 14:24 | <annevk> | do you get a load event for the script? |
| 14:25 | <jgraham> | The async script? |
| 14:26 | <annevk> | yeah |
| 14:26 | <jgraham> | Yeah. |
| 14:27 | <jgraham> | Well actually in gecko it seems OK now |
| 14:27 | <jgraham> | Dunno if I changed something significant |
| 14:28 | <jgraham> | Chrome still fails |
| 14:28 | <jgraham> | And Opera is just weird |
| 14:32 | <Ms2ger> | Opera was weird first? |
| 14:34 | <zewt_> | jgraham: i wouldn't be surprised if browsers treated async scripts as if they happen to load after the page finishes loading, to reduce racy site bugs |
| 14:36 | <jgraham> | That could be what webkit's doing I guess |
| 14:36 | <jgraham> | But then the spec is a lie |
| 14:37 | <zewt> | well, if the behavior is indistinguishable to scripts, it's not really |
| 14:37 | <annevk> | that's defer... |
| 14:37 | <zewt> | eg. if conceptually the script is stuck in a TCP receive buffer and hasn't been received by the browser until the page happened to finish loading |
| 14:38 | <zewt> | well, defer does a bit more, iirc (guarantees order, and iirc guarantees scripts happen before load? not sure offhand) |
| 14:38 | <jgraham> | Right defer is different |
| 14:46 | <zewt> | i'm surprised anyone supports async, since it seems like an interop nightmare |
| 14:46 | <zewt> | (at least as it's described above--been a while since I've really squinted how it works) |
| 16:31 | <dglazkov> | good morning, Whatwg! |
| 16:31 | <charlvn> | good evening dglazkov |
| 17:18 | <gsnedders> | Anyone got any experience of dealing with online stalkers? |
| 17:20 | <tantek> | gsnedders - nothing for stalkers in particular, but perhaps you can find something you can re-use from the Troll Taxonomy: tantek.com/w/TrollTaxonomy |
| 17:22 | <gsnedders> | (If anyone wants to actually have any discussion about that with me, PM.) |
| 17:22 | <gsnedders> | (Logged channel, etc.) |
| 17:49 | <annevk> | hmm http://lists.w3.org/Archives/Public/public-whatwg/2012May/0015.html |
| 17:49 | <annevk> | we should get this mailing list mess sorted |
| 17:50 | <Hixie> | yeah, mike is on it |
| 17:51 | <MikeSmith> | Hixie: strawman proposal: make public-whatwg⊙wo the actual list, move existing whatwg⊙wo subscribers over to that |
| 17:51 | <Hixie> | not happening |
| 17:51 | <MikeSmith> | OK |
| 17:51 | <Hixie> | :-) |
| 17:51 | <MikeSmith> | I had to ask |
| 17:51 | <Hixie> | we have way too much stuff pointing to whatwg@ already |
| 17:51 | <MikeSmith> | ok |
| 17:51 | <Hixie> | (and i'd have to have admin rights to public-whatwg to be able to ban people, etc, which the cg rules say i can't have) |
| 17:52 | <hober> | public-whatwg⊙wo shouldn't even exist if you ask me [which you didn't :)] |
| 17:52 | <Hixie> | this isn't a problem limited to the whatwg cg list, anyway. the editing cg has the same problem, for instance |
| 17:53 | <Hixie> | hober: agreed |
| 17:53 | <hober> | right. all cgs which use pre-existing infrastructure |
| 17:53 | <Hixie> | right |
| 17:56 | <MikeSmith> | yeah, I have pointed out to others on the team that this should be configurable |
| 17:56 | <MikeSmith> | unfortunately it is currently not configurable |
| 17:56 | <othermaciej> | MikeSmith, Hixie: would it be feasible to, for example, subscribe public-whatwg⊙wo to whatwg⊙wo, so joining the CG puts you on the right list? |
| 17:56 | <MikeSmith> | othermaciej: done that |
| 17:56 | <MikeSmith> | we had to revert it |
| 17:56 | <othermaciej> | oh? |
| 17:56 | <MikeSmith> | people then get duplicate messages |
| 17:57 | <MikeSmith> | and really we don't need a new mailing list |
| 17:57 | <MikeSmith> | we have a perfectly good mailing list already |
| 17:57 | <Hixie> | othermaciej: the other worry is people posting to public-whatwg |
| 17:57 | <MikeSmith> | right |
| 17:57 | <Hixie> | othermaciej: and their messages being lost in the ether |
| 17:57 | <othermaciej> | hmm, good point |
| 17:57 | <Hixie> | as just happened with dougt's message |
| 17:57 | <MikeSmith> | yeah |
| 17:57 | <Hixie> | (i told dougt to repost to whatwg) |
| 17:57 | <Hixie> | (though thanks to annevk for pointing it out because looks like i never got that mail) |
| 17:58 | <Hixie> | (dunno why) |
| 17:58 | <othermaciej> | I guess to really make use of the pre-existing list, joining the CG should automatically add you to the right list, and the public-whatwg@ list should not even be in the picture |
| 17:58 | <Hixie> | there's really no reason for anyone to be joining the CG unless they have specific patents they want to grant |
| 17:59 | <Hixie> | and even then -- i don't know that the FSA requires membership |
| 17:59 | <Hixie> | the exception would be someone like anne who wants to contribute actual text (as with his specs that he submitted recently) |
| 18:08 | <MikeSmith> | talking with systems team about it now |
| 18:18 | <MikeSmith> | will create public-whatwg-archive⊙wo for the archive mirror |
| 18:18 | <Hixie> | nice |
| 18:18 | <MikeSmith> | and close public-whatwg⊙wo to postings |
| 18:18 | <Hixie> | yay |
| 18:18 | <Hixie> | +1 to systeam |
| 18:21 | <hober> | whooo! |
| 18:31 | <annevk> | MikeSmith: public-whatwg-archive also being closed for postings right? |
| 18:33 | <MikeSmith> | annevk: yeah, but that part I need to figure out |
| 18:33 | <MikeSmith> | because it does actually have to accept some postings |
| 18:33 | <MikeSmith> | that is, the stuff that's posted to whatwg⊙wo |
| 18:33 | <MikeSmith> | which is from various addresses of course |
| 18:34 | <Hixie> | well all the e-mails will look like they're coming from the whatwg list, right? |
| 18:34 | <Hixie> | can you just mark it moderated except for the whatwg list? |
| 18:35 | <annevk> | MikeSmith: ah okay |
| 18:36 | <MikeSmith> | Hixie: yeah, I'm sure it's doable. Just need to get the attention of our mailing-list guru on the systems team |
| 18:36 | <annevk> | MikeSmith: it seems it should be possible to only accept the messages that come back from whatwg⊙wo |
| 18:36 | <MikeSmith> | right |
| 18:48 | Hixie | finds himself replying to his own feedback on whatwg@ |
| 18:48 | <Hixie> | (and rejecting it) |
| 18:49 | <annevk> | hey past-Hixie, you were wrong. sincerely, today-Hixie |
| 18:50 | <Hixie> | i didn't even realise that i was the one who wrote it until i noticed someone else replying to that e-mail saying i'd written it, because i don't pay any attention to who writes the feedback when replying |
| 18:56 | <jwalden> | what happened to the ability to mark log lines as important in the logs? |
| 18:57 | <annevk> | bit late, but thanks to hober we now have http://w3cmemes.tumblr.com/post/22393119375 |
| 18:57 | <MikeSmith> | heh |
| 18:58 | <annevk> | need to get a bit more creative |
| 19:01 | <hober> | http://w3cmemes.tumblr.com/post/22393334041 |
| 19:02 | <Hixie> | http://imgflip.com/i/1avf |
| 19:03 | <annevk> | hehe, I'll submit that |
| 19:14 | <Hixie> | http://w3cmemes.tumblr.com/post/22393866467 |
| 19:14 | <Hixie> | ok i'll stop being a troll now |
| 19:38 | <smaug____> | has something changed in freenode? it started to require sasl here |
| 19:38 | smaug____ | has no idea what sasl is |
| 20:05 | <annevk> | Hixie: hahahaha |
| 20:07 | <Velmont> | smaug____: sasl is the ssl email auth thing? Seem to remember something like that when I set up email server. |
| 20:11 | <smaug____> | Velmont: not ssl |
| 20:11 | <smaug____> | Velmont: I do use ssl connection to irc.mozilla.org for example |
| 20:11 | <smaug____> | freenode started to require sasl for me |
| 20:11 | <smaug____> | (using a different connection than usually) |
| 20:12 | <smaug____> | so, I had to install sasl plugin to Chatzilla |
| 20:13 | <miketaylr> | i've had that message when tethering before |
| 20:23 | <dglazkov> | smaug____: use irccloud.com |
| 20:24 | <Ms2ger> | dglazkov, do you know how badly that leaks? ;) |
| 20:24 | <smaug____> | and irccloud is pretty horrible webapp anyway |
| 20:24 | <dglazkov> | Ms2ger: leaks what |
| 20:25 | <Ms2ger> | All the objects |
| 20:25 | <smaug____> | dglazkov: it kills all the known browsers |
| 20:25 | <dglazkov> | smaug____: works great on Chrome? |
| 20:25 | <smaug____> | well, in chrome is kills only the tab I think |
| 20:25 | <smaug____> | dglazkov: have you kept it open for a long time? |
| 20:25 | <dglazkov> | um... you're talking with someone who's been using it for a fairly long time. |
| 20:26 | <smaug____> | dglazkov: you keep it open for weeks? |
| 20:26 | <dglazkov> | no, why do I need to? |
| 20:26 | <smaug____> | well, to have IRC open all the time |
| 20:27 | <smaug____> | I know it keeps the connection open in the background sure. |
| 20:27 | <dglazkov> | irccloud makes you always online. You don't have to have the tab open |
| 20:27 | <smaug____> | but if you actually *use* irc all the time |
| 20:27 | <dglazkov> | I keep it open when I use it, sure. |
| 20:28 | <smaug____> | anyhow, I prefer Chatzilla :) |
| 20:28 | <smaug____> | it doesn't leak |
| 20:28 | <dglazkov> | smaug____: that's fine :) I was just trying to be helpful. |
| 20:28 | smaug____ | should continue investigating leak logs from Google Reader. |
| 20:29 | <smaug____> | I wonder if anyone from chrome team looks at leaky web sites |
| 20:29 | <smaug____> | s/looks/investigates/ |
| 20:30 | <jgraham> | You should all be using irssi anyway |
| 20:30 | <Hixie> | annevk: http://w3cmemes.tumblr.com/post/22398040394 :-P |
| 20:30 | <smaug____> | jgraham: yeah, irssi is an option |
| 20:30 | <smaug____> | but don't like its UI |
| 20:30 | <smaug____> | I use irssi on my N9 |
| 20:30 | <dglazkov> | smaug____: yep. ask simonjam, anniesullivan, or tonyg on #webkit |
| 20:31 | <dglazkov> | smaug____: for some reason they are all offline atm |
| 20:31 | <jgraham> | dglazkov: Maybe their irccloud tabs died :p |
| 20:31 | <smaug____> | dglazkov: just wondering if you see Google Reader to leak in Chrome too |
| 20:32 | <smaug____> | but I'll ask them later |
| 20:32 | <dglazkov> | smaug____: no clue. I've been spec-writing for the last 4 months, so I don't know what is real or not anymore. |
| 20:32 | <jgraham> | http://lists.w3.org/Archives/Public/www-style/2012May/0125.html |
| 20:32 | <smaug____> | heh |
| 20:33 | <jgraham> | Pretty disappointing responses so far. bz seems convinced that prefixes are needed despite the fact that they are presumably screwing over Mozilla hard on mobile |
| 20:33 | <jgraham> | Although his points are not unreasonable |
| 20:34 | <smaug____> | bz's points rarely are unreasonable |
| 20:35 | <Hixie> | too true |
| 20:37 | <annevk> | you can usually make changes if only one browser supports it |
| 20:37 | <othermaciej> | jgraham: needed ever, or needed for the same extent they are applied currently (til CR) |
| 20:37 | <annevk> | if you wait five years though and everyone else supports the features too with prefixes |
| 20:38 | <annevk> | well then you're fucked |
| 20:38 | <jgraham> | othermaciej: Closer to "needed ever" |
| 20:38 | <othermaciej> | I have only read fragments of that thread but I think I might sort of agree with his position |
| 20:39 | <annevk> | Hixie: guess I did troll, my point took about 25min to sink in |
| 20:39 | <othermaciej> | I would say properties should be prefixed until a condition is met such as: (a) spec taken up as work item by the WG; (b) there are at least two implementations |
| 20:39 | <othermaciej> | (not necessarily complete ones) |
| 20:40 | <othermaciej> | maybe even only (a) |
| 20:40 | <jgraham> | That is still going to leave us with content that will only work in a single implementation even when other implementations have the feature |
| 20:40 | <jgraham> | Although possibly less of it |
| 20:41 | <Hixie> | i like how the htmlwg is now talking about how they are the group that "owns" stuff |
| 20:41 | <Hixie> | as if that was how it worked :-) |
| 20:42 | <Velmont> | :P |
| 20:42 | <annevk> | don't tell glazman |
| 20:45 | <jgraham> | (it will also leave authors writing content that will break if changes are made to the unprefixed semantics because they will include both and put the unprefixed version last) |
| 20:46 | <Ms2ger> | New bug: "I don't like public data" |
| 20:46 | <Ms2ger> | Hah |
| 20:53 | <annevk> | i need images for |
| 20:54 | <annevk> | "chair did not know HTML5 includes XML syntax" |
| 20:54 | <annevk> | and |
| 20:54 | <annevk> | "going through the charter line by line; because that's how we look productive" |
| 20:59 | <annevk> | tantek: is the neato from you? |
| 20:59 | <Velmont> | Soo funny :D |
| 21:00 | <Ms2ger> | Condescending Wonka++ |
| 21:05 | <Hixie> | anne: http://w3cmemes.tumblr.com/post/22400217421 |
| 21:05 | <Hixie> | :-P |
| 21:05 | <Ms2ger> | Don't you all have work to do? Reviewing charters? :) |
| 21:07 | <dglazkov> | there's enough acidity in these memes to burn holes through steel. |
| 21:07 | <dglazkov> | I have another idea: "working on clever memes? don't you have work to do?" :P |
| 21:07 | <annevk> | Hixie: oh god |
| 21:08 | <Ms2ger> | dglazkov, Web Components? [Condescending Wonka] Yeah, that will go well |
| 21:08 | <Velmont> | Anne laughed out loud :| doesn't fit with the meeting, hard to hold it. |
| 21:09 | <dglazkov> | Ms2ger: heey. |
| 21:09 | dglazkov | gives Ms2ger a hurt look |
| 21:09 | Ms2ger | pats dglazkov on the back |
| 21:09 | <dglazkov> | :) |
| 21:09 | <Ms2ger> | We all have silly ideas at some point ;) |
| 21:10 | <hober> | one of the recent memes forced me to leave the room for a laugh break. i'm not saying which one. |
| 21:19 | <MikeSmith> | the meme meeting backchannel .. breaking new ground |
| 21:20 | <bencc> | do web workers support CORS? |
| 21:21 | <dglazkov> | MikeSmith: that's the only thing that tells me that there's a meeting. |
| 21:21 | <dglazkov> | MikeSmith: I had completely blown off htmlwg meet. I was worried for my health. |
| 21:22 | <Hixie> | bencc: not yet |
| 21:22 | <Hixie> | bencc: but it is on the cards |
| 21:22 | <dglazkov> | besides, isn't HTML5 done already? What's there to meet about. |
| 21:22 | <Hixie> | bencc: though actually the alternative suggestion is just to run the script in the other origin |
| 21:22 | <Hixie> | bencc: i haven't added this to the spec yet mostly because i'm not sure whether doing so would cause the w3c trouble (they're trying to publish a snapshot) |
| 21:23 | <Hixie> | bencc: and i'm not sure whether to just stop updating the w3c copy or wait or slow down the w3c process |
| 21:23 | <bencc> | Hixie: how can I run the script in the other origin? |
| 21:23 | <Hixie> | bencc: right now you can't, but the idea would be that you can launch a worker and it runs in the worker's script's origin, if it opts in to doing so |
| 21:23 | <bencc> | Hixie: agreed. cors support for webworkers will be the last update though :) |
| 21:23 | <Hixie> | there are other things suggested also |
| 21:24 | <Hixie> | e.g. spawning a thread from a data: url or text string of code |
| 21:24 | <Hixie> | or using workers in appcache |
| 21:24 | <jgraham> | dglazkov: In the absence of anything technical, one can always talk Process |
| 21:25 | <bencc> | Hixie: all suggestions will be very wellcome |
| 21:25 | <dglazkov> | jgraham: true. |
| 21:26 | <othermaciej> | dglazkov: we did actually get people to agree on some of the open issues |
| 21:26 | <othermaciej> | at least, the set of people here |
| 21:27 | <dglazkov> | othermaciej: that's great to hear |
| 21:27 | <othermaciej> | for example, it was generally agreed that replicating the ARIA syntax requirements for every ARIA attribute in the HTML5 spec was not a good idea |
| 21:28 | <Ms2ger> | Ohrly |
| 21:36 | <Hixie> | othermaciej: http://w3cmemes.tumblr.com/post/22402024765 ! |
| 21:37 | <othermaciej> | :-p |
| 21:37 | <Ms2ger> | It's funny, because it's eating your soul |
| 21:46 | <annevk> | Hixie: http://w3cmemes.tumblr.com/post/22402668355 |
| 22:08 | <annevk> | suddenly lots of longdesc memes |
| 22:09 | <Velmont> | longdesc the new black |
| 22:09 | <annevk> | hmm continued forking of addEventListener by Mozilla |
| 22:09 | <annevk> | meh |
| 22:09 | <annevk> | well dougt |
| 22:10 | <Hixie> | wow who did http://w3cmemes.tumblr.com/post/22404077991? that's an elaborate meme! |
| 22:10 | <Hixie> | annevk: hm? |
| 22:11 | <annevk> | Hixie: creating more events that when registered using addEventListener will cause them to be dispatched |
| 22:11 | <annevk> | Hixie: see WHATWG thread on proximity and such |
| 22:12 | <Hixie> | the ones i saw are just dispatched always |
| 22:12 | <Hixie> | at least in principle |
| 22:12 | <Hixie> | it's just a UA optimisation that they aren't using battery life when there's no listener |
| 22:12 | <Hixie> | not the same as orientation where adding the listener causes an event to be fired that wouldn't normally be fired |
| 22:13 | <annevk> | the meeting now is hilarious |
| 22:13 | <annevk> | for about thirty minutes there's some discussion about whether or not the spec should suggest that authors should not or must not do something |
| 22:13 | <annevk> | or whether maybe UAs should be forbidden to implement something useful because not everyone supports it |
| 22:14 | <annevk> | especially the emphasis that is put on how these statements in the spec are actually going to matter in reality |
| 22:14 | <annevk> | like authors would read that and like, oh "i should not" better think about this again |
| 22:15 | Velmont | brought the popcorn |
| 22:15 | <annevk> | more like forty minutes |
| 22:15 | <annevk> | AND ONGOING |
| 22:17 | <annevk> | Hixie: the moment the pattern exists it's likely to be reused though elsewhere |
| 22:18 | <annevk> | Hixie: but mkay |
| 22:19 | <Hixie> | what pattern? |
| 22:19 | <Velmont> | *So* much talk and so little action. |
| 22:19 | <annevk> | register for weird event |
| 22:19 | <annevk> | event dispatches |
| 22:19 | <annevk> | from now on i'll communicate |
| 22:19 | <Hixie> | that isn't what dougt proposed here |
| 22:19 | <annevk> | in memeable lines |
| 22:20 | <Velmont> | Hixie: I made it. Not really elaborate, just different. |
| 22:20 | <Hixie> | Velmont: it's like three memes in one! |
| 22:20 | <Hixie> | Velmont: or did you find an existing template? |
| 22:20 | <annevk> | Hixie: http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ seems like it is? |
| 22:21 | <Velmont> | Hixie: No, just threw it into Gimp. |
| 22:21 | <Hixie> | Velmont: i go back to elaborate! |
| 22:21 | <Hixie> | annevk: that is black-box indistinguishable from just saying that "a deviceproximity event fires whenever the proximity changes" |
| 22:22 | <Hixie> | annevk: note in particular that he doesn't say that a new event should fire when you listen, even if the proximity doesn't change |
| 22:23 | <annevk> | <- skeptic |
| 22:27 | <rniwa> | Hixie: in your response to the template element parse thread |
| 22:27 | <rniwa> | Hixie: you gave two examples where the result will differ |
| 22:27 | <Hixie> | annevk: send feedback on the list to make sure he doesn't mean to fire an event when you attach |
| 22:28 | <rniwa> | Hixie: are you saying that it's weird because the resulting fragments are very different due to the first element being parsed? |
| 22:29 | <rniwa> | Hixie: but isn't typical in the html parser? as in depending on what element we encounter, we'll drop some nodes or insert elements automatically |
| 22:29 | <MikeSmith> | arv: http://dvcs.w3.org/hg/url/rev/93306cbfbc62#l1.95 0_0 |
| 22:30 | <MikeSmith> | <h3 U0003Ccode="" |
| 22:31 | <tantek> | http://instagr.am/p/KOLQO0g9Vd/ |
| 22:32 | <arv> | MikeSmith: fixing |
| 22:32 | <annevk> | MikeSmith: looks like HTML XML-serializing |
| 22:33 | <MikeSmith> | anolis bug? |
| 22:33 | <Hixie> | rniwa: not nodes that came before, usually |
| 22:33 | <rniwa> | Hixie: oh I see what you're saying |
| 22:34 | <Hixie> | rniwa: and the few cases where we do mess with nodes that came before, we do it only because the input was seriously broken and we do it only because we were forced to for web compat |
| 22:35 | <rniwa> | Hixie: yeah. did you see annevk's response on 4/16 though? |
| 22:36 | <Hixie> | give me some text to search for? |
| 22:36 | <rniwa> | "You cannot look at various elements and make a decision" |
| 22:36 | <rniwa> | "E.g. if your first element is <plaintext> there will not be any other elements." |
| 22:36 | <rniwa> | and |
| 22:36 | <rniwa> | "Defining a new top-level insertion mode while retaining compatible behavior might be an interesting exercise in parser complexity, but it's not clear there is a benefit (use cases?) and feasibility has not been demonstrated (consider handling <p><td><p>, <tr><p><td>, ...). The more we can define in terms of the existing parser, the better it is for developers. The behavior will be more predictable and there will be less quirks t |
| 22:36 | <rniwa> | learn." |
| 22:36 | <Hixie> | the first was sufficient :-) |
| 22:37 | <rniwa> | Hixie: that argument convinced me that the proposed approach is better than allowing any elements to appear |
| 22:37 | <Hixie> | it's hard for me to evaluate without knowing what cases we're trying to handle, really |
| 22:37 | <rniwa> | Hixie: but you made a really good point as well. |
| 22:37 | <Hixie> | but i'm pretty sure we never want to change the result of earlier parsing based on later characters |
| 22:38 | <rniwa> | Hixie: rafael listed all cases in one of his emals |
| 22:38 | <rniwa> | Hixie: see his point on 4/25 |
| 22:38 | <Hixie> | same thread? |
| 22:38 | <rniwa> | Hixie: search with "rp, rt => HTMLRubyElement" |
| 22:38 | <rniwa> | Hixie: yup |
| 22:38 | <rniwa> | Hixie: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html |
| 22:38 | <Hixie> | that doesn't list the actual use cases we want to parse |
| 22:39 | <Hixie> | just gives some examples of the results |
| 22:39 | <rniwa> | Hixie: ah i see |
| 22:39 | <Hixie> | (for example, i assume anything to do with <frameset> we don't really care about the result) |
| 22:39 | <rniwa> | Hixie: he does list some cases at the end |
| 22:39 | <rniwa> | Hixie: but i suppose you're looking for more comprehensive list? |
| 22:40 | <Hixie> | the ones he lists at the end include something to do with <frameset>, so i assume they're just examples of the results of the proposal and not use cases |
| 22:40 | <Hixie> | i could be wrong :-) |
| 22:40 | <Hixie> | but i'd be surprised if one of the use cases involves framesets! |
| 22:44 | <Hixie> | must. not. use. tantek's photo. for a meme. |
| 23:57 | <annevk> | http://www.netmagazine.com/news/call-greater-diversity-web-industry-121948 |