| 02:54 | <Hixie> | ok. The green line is at 0. (Well, it's at 1, but that 1 issue is "define SQL" which isn't a blocker for any spec but WebDB.) |
| 02:54 | <Hixie> | food now. |
| 05:10 | <Hixie> | sicking: i'm looking at async="" |
| 05:11 | <Hixie> | and your e-mail |
| 05:11 | <Hixie> | hsivonen: i'm lookin at async="" |
| 05:11 | <Hixie> | and your bug |
| 05:11 | <Hixie> | i wonder if i should make async="" and defer="" just be ignored for anything but parser-inserted elements |
| 05:12 | <Hixie> | sicking's suggestion to make async scripts work just like appendChild()ed scripts makes sense |
| 05:13 | <Hixie> | but it means async="" only has an effect when parsing |
| 05:13 | <Hixie> | should we make defer="" consistent with that? |
| 05:13 | <Hixie> | or should it still have an effect (when async="" isn't also present) |
| 05:13 | <Hixie> | it seems weird that right now you cannot appendChild() in a way that blocks, but you can appendChild() with defer and it'll execute later than it otherwise could |
| 05:14 | <Hixie> | whereas in the markup you have to go out of your way to get that effect |
| 05:30 | <othermaciej> | Hixie: WebKit makes all programmatically inserted scripts act effectively like async="" |
| 05:30 | <Hixie> | the spec does too now |
| 05:30 | <othermaciej> | (we don't have the async attribute, but appendChild()ing a script won't block and there is no order guarantee) |
| 05:31 | <othermaciej> | well, it won't block on I/O, could block if it's a long-running inline script of course |
| 05:34 | <Hixie> | i wonder what zcorpan wants me to call the uberdocument he wants the whatwg to host |
| 05:34 | <Hixie> | containing all of html5, eventsource, localstorage, webdb, websockets api and protocol, vocabs, etc |
| 05:35 | <othermaciej> | I dunno |
| 05:36 | <Hixie> | i could call it Web Applications 1.0 |
| 05:36 | <othermaciej> | the uberdocument does not sound very useful to me; his explanation (broken cross-references) sounds like a reason to keep them separate so people notice and point it out |
| 05:36 | <othermaciej> | that being said, having information in more forms is in general a good thing |
| 05:37 | <Hixie> | the broken cross-references are only broken because the documents are split |
| 05:37 | <Hixie> | and gsnedders' script doesn't do cross-doc references |
| 05:38 | <othermaciej> | if it will be fixed by a tool change then I guess it's less important to make every instance obvious |
| 05:38 | <Hixie> | the instances are already obvious |
| 05:38 | <GPHemsley> | Hixie: Have you seen the latest <cite> discussion? |
| 05:38 | <Hixie> | they have thick blue or green underline |
| 05:38 | <Hixie> | GPHemsley: haven't read it yet, no |
| 05:38 | <GPHemsley> | k |
| 05:45 | <GPHemsley> | Is anyone else having trouble connecting to the Mozilla IRC server? |
| 05:45 | <Hixie> | wfm |
| 05:45 | <GPHemsley> | Most of my connection attempts time out, and when I do get through, I get Z-lined as a dronebot, for some reason. |
| 05:46 | <Hixie> | weird |
| 06:27 | <sicking> | Hixie: still there? |
| 06:27 | <Hixie> | hey |
| 06:28 | <sicking> | so I think async should have meaning always |
| 06:28 | <sicking> | *but* |
| 06:28 | <sicking> | that always makes sense if I get my other suggestion, that i haven't sent to the list yet, goes through |
| 06:28 | <sicking> | so Gecko today always executs scripts in the order they were inserted into the DOM |
| 06:29 | <sicking> | in order to not have interdependency issues |
| 06:29 | <sicking> | i'm told webkit doesn't do that |
| 06:29 | <Hixie> | nor does html5 now |
| 06:29 | <sicking> | i know |
| 06:29 | <Hixie> | as you suggested :-) |
| 06:29 | <sicking> | well, i just suggested to change async, so far |
| 06:30 | <sicking> | i'm curious what IE does |
| 06:30 | <sicking> | i'm sort of worried about changing geckos behavior, that dynamically created scripts are essentially always async |
| 06:31 | <sicking> | s/that/so that/ |
| 06:32 | <sicking> | i totally think that async should always execute as-soon-as-possible-order-doesn't-matter |
| 06:33 | <othermaciej> | we don't seem to have problems with programatically added scripts executing async, but it's entirely possible that it causes subtle compat issues that we just haven't diagnosed yet |
| 06:33 | <othermaciej> | though I tend to suspect not |
| 06:33 | <sicking> | yeah, i'm of split mind, which is why i want to test in IE |
| 06:34 | <othermaciej> | but obviously it's hard to tell how some of these edge case behavior differences impact the long tail of the Web |
| 06:34 | <sicking> | right |
| 06:34 | <othermaciej> | we did have some kind of bug reports on dynamically inserted scripts (can't remember if it didn't work at all or something...) |
| 06:34 | <othermaciej> | lemme search the ChangeLogs |
| 06:36 | <othermaciej> | we had a bug where a dynamically insered script that removed itself would cause a crash |
| 06:37 | <othermaciej> | (so we've seen at least some examples of people doing strange things) |
| 06:38 | <Hixie> | on the web? people doing strange things? surely you jest |
| 06:38 | <Hixie> | surely, sir |
| 06:38 | <Hixie> | that seems highly unlikely |
| 06:38 | <othermaciej> | hmm, speaking of <script>, one thing we recently did is stop executing scripts with a "for" attribute |
| 06:39 | <othermaciej> | https://bugs.webkit.org/show_bug.cgi?id=21193 |
| 06:39 | <sicking> | othermaciej: ouch |
| 06:40 | <sicking> | othermaciej: i know we ended up with some hacks for that |
| 06:40 | <sicking> | othermaciej: back in the day gecko actually supported the "for" and "event" attributes. But only in embedded environments i think |
| 06:40 | <othermaciej> | I'm not sure we want to actually implement <script for>, but since it doesn't seem viable to completely ignore it, it would be good to agree on some interoperable behavior |
| 06:41 | <sicking> | othermaciej: ugh, i should have removed that from gecko a long time ago |
| 06:41 | <Hixie> | well i'm happy to just say "if there's a for attribute, abort these steps" somewhere |
| 06:41 | <sicking> | othermaciej: yeah, i definitely don't want to implement for fully |
| 06:41 | <Hixie> | file a bug :-) |
| 06:42 | <sicking> | othermaciej: lemme check what gecko does |
| 06:42 | <othermaciej> | sicking: ok |
| 06:42 | <othermaciej> | Hixie: will do once we figure out what should happen |
| 06:42 | <Hixie> | k thanks |
| 06:43 | <sicking> | this stuff is nasty |
| 06:43 | <sicking> | so |
| 06:44 | <sicking> | if "for" or "event" is missing, process as normal |
| 06:44 | <sicking> | if "for" is something other than "window", don't process |
| 06:46 | <sicking> | if "event" starts with "onload " or "onload(" (case insensitive compare) then don't process |
| 06:46 | <sicking> | otherwise process as normal |
| 06:46 | <othermaciej> | wild |
| 06:46 | <sicking> | oh yeah |
| 06:46 | <othermaciej> | wait |
| 06:46 | <sicking> | so i think the situation was this |
| 06:47 | <othermaciej> | so if "for" is "window" and "event" does *not* start with "onload" you run the script? |
| 06:47 | <sicking> | at the dawn of time we ignored 'for' and 'event' |
| 06:47 | <othermaciej> | so <script for="window" event="onclick"> would run immediately? |
| 06:48 | <Hixie> | that's pretty special |
| 06:48 | <Hixie> | even for the web :-P |
| 06:48 | <sicking> | sorry |
| 06:48 | <sicking> | arg, so many negatives |
| 06:49 | <sicking> | so if it starts with "onload " or "onload(", then run as normal |
| 06:49 | <sicking> | otherwise don't process |
| 06:49 | <othermaciej> | that makes more sense |
| 06:49 | <sicking> | but only by a smidgen |
| 06:50 | <othermaciej> | so let me try to restate it to make sure I understand |
| 06:50 | <sicking> | i'd really hate to put this in the spec though |
| 06:50 | <sicking> | i've been meaning to nuke all of this crap for ages, never got around to it |
| 06:50 | <sicking> | basically, if it has "for" *and* "event", then don't process |
| 06:51 | <sicking> | *except* |
| 06:51 | <othermaciej> | well, maybe WebKit's recent behavior is good enough - I dunno |
| 06:51 | <othermaciej> | we just refuse to run anything with a "for" attribute |
| 06:51 | <sicking> | if it's for="window" event="onload(..." |
| 06:51 | <sicking> | or for="window" event="onload ..." |
| 06:51 | <othermaciej> | ok |
| 06:52 | <othermaciej> | what if it's just event="onload" with no paren or space? |
| 06:52 | <Hixie> | event="" in IE can have ()s? o_O |
| 06:53 | <othermaciej> | getting back to dynamically inserted scripts - here is where we added support: http://trac.webkit.org/changeset/9105 |
| 06:54 | <othermaciej> | the bug is sadly internal bug we had numerous separate reports and developer requests |
| 06:54 | <othermaciej> | since 2005, we have not had a bug that we diagnosed as being due to lack of order guarantee |
| 06:56 | <othermaciej> | we later added load events for script elements: http://bugzilla.opendarwin.org/show_bug.cgi?id=5812 |
| 06:56 | <othermaciej> | sorry, antique URL, you want https://bugs.webkit.org/show_bug.cgi?id=5812 |
| 13:01 | <smaug> | now Chrome went to some strange state where it loads wrong url to iframe, even if script explicitly says something else :/ |
| 13:01 | smaug | needs to try trunk Chrome |
| 13:06 | <Philip`> | "< hsivonen> multiple instances of one image can't be totally rare" - <img src=blank.gif><img src=blank.gif><img src=blank.gif>... |
| 13:08 | <hsivonen> | the Web should pin blank.gif to cache |
| 13:08 | <Philip`> | Lots of sites have hundreds like that |
| 13:09 | <Philip`> | One page had the same <script src> 1001 times |
| 13:10 | <Philip`> | Zillions of pages have half a dozen identical ad-insertion scripts |
| 13:10 | <hsivonen> | ouch. I hope these aren't the top sites whose perf makes or breaks the perception of the perf of a browser |
| 13:11 | <Philip`> | (The 1001 is probably a weird anomaly and the page doesn't exist now anyway) |
| 13:12 | <Philip`> | The ad-insertion scripts are on lots of sensible legitimate-looking sites |
| 13:12 | <remysharp> | hi - couple of things - the multipage HTML5 spec is broken again (I thought it was fixed) :-( |
| 13:12 | <smaug> | Hixie: with the latest nightly chromium I do get the same "TopLevelA", but "replaced iframe" problem |
| 13:13 | <Philip`> | remysharp: It was fixed :-) |
| 13:13 | <remysharp> | Philip`: it broke again |
| 13:13 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/stderr.txt |
| 13:13 | <smaug> | does nightly chromium use latest webkit trunk? |
| 13:13 | <Philip`> | Hixie: lxml doesn't like HTML5 elements :-( |
| 13:15 | <remysharp> | section doesn't allow aria roles according to the validator, but I couldn't see that restriction on the section element |
| 13:15 | <remysharp> | as robert__ is about to say! |
| 13:16 | <robert__> | Ok, I just bother people and then they go here... :-) |
| 13:16 | gsnedders | grumbles something about the complexity of configuring mice in Ubuntu |
| 13:16 | <robert__> | But yes, the spec claims the role="main" is allowed on the section element, but any HTML5 validator claims it isn't |
| 13:17 | <gsnedders> | Then I guess the validator is wrong :) |
| 13:17 | <robert__> | Yeah, me too |
| 13:17 | <robert__> | Just wanted some confirmation wheter that is the case |
| 13:17 | <Philip`> | gsnedders: What do you expect when you're configuring protrusions into our dimension of hyper-intellegent pan-dimensional beings? |
| 13:17 | <remysharp> | gsnedders: is there a way to bug report on the validator? |
| 13:18 | <hsivonen> | remysharp: bugzilla.validator.nu |
| 13:18 | <gsnedders> | Philip`: Magic. |
| 13:18 | <remysharp> | hsivonen: wholesome :) cheers |
| 13:19 | <Philip`> | http://www.gansudaily.com.cn/20040715/802/default.htm has 691 instances of the same script src |
| 13:20 | hsivonen | wonders what the purpose of those scripts is |
| 13:21 | <hsivonen> | I also wonder what the median number of scripts, sheets and images on a page is |
| 13:23 | <Philip`> | http://www.alhadath.info/akhbar/2/197.php has awesome markup |
| 13:23 | <Philip`> | include 62 of the same stylesheet |
| 13:23 | <Philip`> | *including |
| 13:23 | <Philip`> | Seems like only a few pages have more than a dozen, but a lot have a handful of the same <link href> |
| 13:24 | hsivonen | wonders what post processing has happened after that markup left FrontPage |
| 13:24 | Philip` | has no data for medians |
| 13:26 | <Philip`> | hsivonen: Do you care about more detailed data on repeated <script src>/<link href> values? |
| 13:27 | <hsivonen> | I just care about a ballpark size for the size of the map holding the URLs |
| 13:27 | <Philip`> | Ah |
| 13:28 | <hsivonen> | I guessed 127 |
| 13:30 | <Philip`> | The mean number of elements per page on dmoz.org was 18 <img>, 1.2 <link>, 3.8 <script> |
| 13:31 | <hsivonen> | thanks |
| 13:31 | <Philip`> | I would guess the curves are such that median would be lower than mean |
| 13:31 | hsivonen | lowers the guess to 23 |
| 13:32 | <Philip`> | (since there'll be a few pages with abnormally many elements, and none with abnormally few (because even 0 wouldn't be abnormal)) |
| 13:33 | <Philip`> | Do you really want an average estimate? I'd have thought you'd care more about optimising slow pages, i.e. abnormally complex pages |
| 13:34 | <Philip`> | (Those means come from http://philip.html5.org/data/tag-count-total.txt) |
| 13:34 | <hsivonen> | the hash wants me to pick a number |
| 13:35 | <Philip`> | Pick 1 |
| 13:35 | <hsivonen> | presumably picking a big number wastes memory, presumably picking a small number makes things slighly slower |
| 13:35 | <hsivonen> | probably I don't have the right data to decide anyway |
| 13:35 | <hsivonen> | and I'd be better off if the hash creator had picked something at random |
| 13:36 | Philip` | presumes picking 0 is not possible, and so 1 has the justification that it's the first possible number, which is less arbitrary than 23 :-) |
| 13:36 | <hsivonen> | Philip`: thanks. I think I'm going to stick to 23 |
| 13:37 | <robert__> | Ok, sorry for stupid question, but at http://bugzilla.validator.nu, is there any way to turn off the display of my e-mail address? Couldn't find anything in the Preferences... |
| 13:38 | <hsivonen> | robert__: nope. it's a vanilla bugzilla |
| 13:38 | <robert__> | Ok... Sorry to hear that, but thanks for the reply! |
| 13:40 | <smaug> | Hixie: I can't reproduce the toplevelA/replaced-iframe problem on nightly webkit, but that build seems to have pretty broken cache/unload handling. (unload doesn't fire always) |
| 13:40 | <Philip`> | So, um, does anyone know how to fix http://www.whatwg.org/specs/web-apps/current-work/multipage/stderr.txt trivially? |
| 13:41 | <Philip`> | (without using a parser that is incredibly slow (i.e. html5lib)) |
| 13:45 | hsivonen | fails miserably at guessing which chapter of SVG 1.2 Tiny deals with bitmaps |
| 13:45 | hsivonen | loads the PDF |
| 13:45 | <gsnedders> | Philip`: Rewrite html5lib in C. |
| 13:46 | <hsivonen> | whoa. there's a single-page version. yay |
| 13:46 | <Philip`> | gsnedders: No thanks |
| 13:47 | <Philip`> | I wonder if http://intertwingly.net/blog/2009/06/12/Validator-Nu-on-GCJ still works... |
| 13:47 | <gsnedders> | html2xml + xml parser support in Anolis? |
| 13:47 | <gsnedders> | :P |
| 13:50 | <Philip`> | I don't care about Anolis at all |
| 13:50 | <Philip`> | I just want the spec-splitter to work with the current input document |
| 13:57 | <smaug> | Hixie: ah, webkit nightlies have some experimental "break unload" feature set on. That breaks my testing |
| 14:09 | <smaug> | Hixie: a build just before that change has the same "feature" as IE and gecko. |
| 14:19 | <Philip`> | Hmm, turns out the gcj version is half the speed as the plain java version, and uses about the same amount of memory |
| 14:20 | <hsivonen> | radically traditional compilation FTW! |
| 14:21 | <Philip`> | gcj has much better startup time, though |
| 14:22 | <Philip`> | echo hello|HTML2XML takes about 0.9s with java, 0.2s with gcj |
| 14:23 | <Philip`> | (java catches up when tokenising the HTML5 spec) |
| 14:28 | <Philip`> | (Also, ~60MB just to stream some HTML to XML seems silly in any case) |
| 14:35 | <Philip`> | Dijkstra ought to have had a name that's easier to spell |
| 14:36 | <hsivonen> | is there any difference between absent type or charset attribute on <script> or having them set to the empty string? |
| 14:38 | <hsivonen> | apparently no difference for type |
| 14:46 | hsivonen | wishes he didn't have to search a space-separated list of tokens to discover stylesheet but not alternate stylesheet links |
| 14:47 | <Philip`> | (If anyone comes here and complains about the multipage spec, let them know I'll fix it later tonight) |
| 14:47 | <Philip`> | (Also, tell them it's all Hixie's fault) |
| 14:47 | Philip` | goes away |
| 14:49 | <hsivonen> | hmm. apparently the old parser only speculatively loads style sheets if the value of rel is exactly "stylesheet" in lower case |
| 14:49 | <hsivonen> | I guess I'll cut corners likewise |
| 14:54 | <hsivonen> | the worst that can happen is Hixie's sites loading a bit more slowly :-) |
| 14:57 | <Philip`> | http://philip.html5.org/data/link-rel-rev.txt |
| 14:57 | <Philip`> | Non-lowercase is quite common |
| 14:57 | Philip` | goes away for real (almost) |
| 14:58 | <hsivonen> | Philip`: I made an ASCII-case-insensitive check |
| 15:09 | <zcorpan_> | <link rel="stylesheet.off" ...> |
| 15:09 | <zcorpan_> | <link rel=" stylesheet" ...> |
| 15:10 | <zcorpan_> | (just 1 out of 127249) |
| 16:51 | <hsivonen> | how. MIME types are being registered for MathML |
| 16:51 | <hsivonen> | only a decade late |
| 16:51 | <hsivonen> | MIME types FTW! |
| 19:52 | <AryehGregor> | "You are arguing for imposing one way of doing things. Ugh." |
| 19:52 | <AryehGregor> | That's a great quote from someone posting on a standards list. |
| 19:57 | <AryehGregor> | Is this broken? http://www.whatwg.org/specs/web-apps/current-work/multipage/ |
| 19:57 | <AryehGregor> | I'm getting an index page. |
| 20:17 | <Philip`> | AryehGregor: Yes, it's broken |
| 20:18 | <Philip`> | AryehGregor: Blame Hixie |
| 20:18 | <Philip`> | He's doing crazy things like trying to use HTML5 in HTML5 |
| 20:18 | AryehGregor | dutifully blames Hixie |
| 22:00 | <Philip`> | Oh, I'm stupid |
| 22:01 | <Philip`> | The gcj version of the parser had no optimisation enabled |
| 22:01 | <Philip`> | so it ended up taking twice as long to parse the spec as the java version |
| 22:01 | <Philip`> | If I compile with -O1, then the gcj parser takes about 40% of the time it used to |
| 22:02 | <Philip`> | hsivonen: ^ gcj isn't so useless after all :-) |
| 22:03 | <Philip`> | Only problem is it takes ~0.5GB RAM to compile, and my server barely has that much, and my desktop machine is 64-bit and can't make 32-bit binaries with gcj, and the server is 32-bit, so I can't actually run it on there :-/ |
| 22:15 | <Dashiva> | Is there a word for "quick to take offense"? |
| 22:16 | <gratz|home> | sensitive? |
| 22:16 | <gratz|home> | lol |
| 22:23 | <AryehGregor> | Quick-tempered? Touchy? |
| 22:48 | <deltab> | Dashiva: thin-skinned |
| 23:07 | <jgraham> | Philip`: gcj can't cross compile? |
| 23:08 | <Philip`> | jgraham: It can, but it fails when linking with -lgcj because it can only find 64-bit libraries |
| 23:08 | <Philip`> | (because I don't have 32-bit ones installed) |
| 23:08 | <jgraham> | Couldn't you install the 32bit ones? |
| 23:09 | <Philip`> | No |
| 23:09 | <Philip`> | I just do "emerge gcc" and it does whatever it wants, which seemingly doesn't involve installing 32-bit gcj libraries |
| 23:09 | <Philip`> | and I don't fancy doing anything more complex than that |
| 23:38 | <Philip`> | Why does lxml's XMLParser seem to think the document consists solely of the <head> element? |
| 23:39 | <Dashiva> | Is there a <html> element? |
| 23:39 | <Philip`> | Yes |
| 23:39 | <Philip`> | There's a <body> element too |
| 23:39 | <Philip`> | but doc.find('body') returns None |
| 23:40 | Philip` | gives up trying to fix the spec-splitter properly, and just uses lxml's HTMLParser with recover=True and hopes it doesn't misparse anything seriously |