| 00:12 | <annevk3> | Hixie, arguably the twitter message should be prefixed with the actual spec it affects, not "HTML5" for all |
| 00:27 | <Hixie> | annevk3: my script doesn't know which spec it affects |
| 03:05 | <heycam> | Hixie, i don't think i'll get a chance to work on Web IDL this month, as i indicated earlier, so please adjust your expectations accordingly :) |
| 03:05 | <heycam> | (higher priority things have been taking up my time) |
| 03:06 | <Hixie> | k |
| 03:06 | <Hixie> | any idea what a more realistic ETA would be? (i prefer a pessimistic ETA, so that there is little chance of the timetable being wrong) |
| 03:08 | <heycam> | pessimistically, maybe july? i'd hope to get some time to allocate to it before then though. |
| 03:08 | <Hixie> | k |
| 03:09 | Hixie | updates his timetable |
| 03:10 | <Hixie> | what's your job situation these days? still doing your PhD? |
| 03:10 | <heycam> | that's right |
| 03:11 | <heycam> | working hard to get the "work" done so i can concentrate on writing up |
| 03:11 | <Hixie> | cool |
| 03:12 | <heycam> | speaking of which, better get back to it, spent too much of this morning replying to emails and so on already :) |
| 03:12 | <Hixie> | re the whitelisting thing, btw, contradicting other specs has never stopped the SVGWG before, so i don't know why it would start being an issue now :-) |
| 03:13 | <Hixie> | (q.v. xlink, css, etc) |
| 03:13 | <heycam> | different constituency, for one |
| 03:13 | <Hixie> | and re your other point, namely that html5 shouldn't set itself up to be contradicted -- i expect by the time html5 is rec, it'll be obsolete |
| 03:14 | <heycam> | seems like a very zen approach to standards work, or something :) |
| 03:14 | <Hixie> | the goal isn't standards |
| 03:14 | <Hixie> | standards are just the tool |
| 03:15 | <heycam> | sure |
| 03:16 | <heycam> | perhaps that points to issues with the W3C rec track process? or problems with interpretation about what getting rec means. |
| 03:16 | <heycam> | hmm, i keep typing "rect" instead of "rec". too much svg i guess. :) |
| 03:16 | <Hixie> | the w3c rec track process has many, many issues |
| 03:16 | <heycam> | *getting to rec |
| 03:16 | <Hixie> | i'm not really interested in trying to fix them at this point |
| 03:16 | <Hixie> | too many people are too invested in the process |
| 03:17 | <Hixie> | (e.g. i don't think we should have per-document maturity, i don't think it makes sense to have a spec that has no maintenance effort yet is still in use, i don't think versioning specs makes sense...) |
| 03:18 | <Hixie> | (people exit CR with test suites that are frankly laughable, e.g. SVG Tiny 1.2; other specs have laughably few implementation requirements, e.g. HTML4) |
| 03:19 | <Hixie> | anyway |
| 03:19 | <Hixie> | bbiab, gotta cycle home |
| 03:19 | <heycam> | later |
| 04:20 | <shepazutoo> | wow, Hixie, "contradicting other specs has never stopped the SVGWG before" (q.v. xlink, css, etc)... first, those were almost certainly mistakes rather than purposeful contradictions, and second, you're acting like the current SVG WG is the same set of companies and individuals that wrote the SVG 1.1 spec, which you know to be false... can you please drop the political histrionics? |
| 04:22 | <shepazutoo> | we're acting in good faith to correct some past errors, and to work with other WGs and with browser vendors to make all the specs align usefully |
| 04:26 | <Hixie> | i think you may have missed the smiley |
| 04:27 | <roc> | a smiley is not a "get out of jail free card" to be annoying |
| 05:09 | <MikeSmith> | we need an ascii symbol for flipping somebody the bird |
| 05:10 | <MikeSmith> | .!. |
| 05:11 | <shepazu> | ..|., |
| 05:13 | <shepazu> | maybe that's too literalist |
| 07:09 | <Hixie> | huh |
| 07:09 | <Hixie> | it turns out there can only be one mutex for localStorage and cookie handling for an entire browser |
| 07:09 | <Hixie> | you can't do it on a per-origin basis |
| 07:14 | <Hixie> | because different origins can be running on the same event loop, and so that would lead to deadlock situations |
| 07:14 | <Hixie> | and you cant do it on the transitive closure of origin and unit of related browsing contexts |
| 07:14 | <Hixie> | because while one group is locked, another could join it |
| 07:17 | <hsivonen> | Hixie: so should a browser lock both cookies and localStorage until script completion when a script first accesses either? |
| 07:17 | <Hixie> | that appears to be the only way to solve the problem, at least for cookie |
| 07:17 | <hsivonen> | Hixie: is it OK to release the lock between two scripts in one browsing context? |
| 07:18 | <hsivonen> | Hixie: or between intervals in one document? |
| 07:18 | <Hixie> | i think the lock would be released at the end of each task |
| 07:18 | <hsivonen> | Hixie: presumably even in single-threaded browsers the values can change in those spots |
| 07:19 | <hsivonen> | aside: I've got the execution order right in http://hixie.ch/tests/adhoc/dom/level0/write/003.html but the test fails because later scripts fail to update the variable |
| 07:19 | <hsivonen> | I'm puzzled |
| 07:20 | <Hixie> | the test might be wrong |
| 07:20 | <hsivonen> | I checked in a debugger that all scripts see the same global scope object |
| 07:20 | <hsivonen> | I'm puzzled |
| 07:20 | <hsivonen> | I wonder if a security check fails somewhere for some reason even if the global scope is the same |
| 07:21 | <hsivonen> | Hixie: well, obviously, my impl is wrong if shipped browsers update the variable for all scripts |
| 07:22 | <Hixie> | ah, yes, if other browsers pass the test it is likely right |
| 07:23 | hsivonen | has still 17 unit tests to go with fixing namespaceURI, localName and getElementsByTagNameNS for HTML nodes |
| 07:28 | <hsivonen> | hrm. still failed to deploy Mike's formmethod etc. patch :-( |
| 07:28 | <MikeSmith> | hsivonen: some problem with it? or you mean you just haven't had time yet? |
| 07:28 | <hsivonen> | MikeSmith: after the deployment process, the servers still run the wrong code |
| 07:29 | <MikeSmith> | whacky |
| 07:31 | <hsivonen> | MikeSmith: oops. sorry. my test was wrong. and was wrong yesterday, too. the code is now deployed. Thanks! |
| 07:31 | <MikeSmith> | ah cool |
| 07:31 | <hsivonen> | now I should also update the spec snapshot, but that tends to be tricky, because the spec changes in unexpected ways |
| 07:32 | <MikeSmith> | which spec snapshot? |
| 07:32 | <hsivonen> | MikeSmith: the one that is mined for UI strings |
| 07:32 | <MikeSmith> | ah |
| 07:33 | <MikeSmith> | yeah, that seems like it might be a bit fragile |
| 07:33 | <MikeSmith> | or could be, I mean |
| 07:56 | <hsivonen> | Hixie: is there a reason why the spec doesn't say that getAttributeNode lower-cases the argument |
| 07:56 | <hsivonen> | Hixie: failing to do so seems to fail Acid3 |
| 07:56 | <Hixie> | really? |
| 07:56 | <Hixie> | i'm hoping Attribute nodes get removed altogether |
| 07:56 | <Hixie> | (which is allowed in acid3) |
| 07:56 | <hsivonen> | Hixie: well, at least I'm reading a test case that claims to copy Acid3 |
| 07:57 | <hsivonen> | Hixie: http://mxr.mozilla.org/mozilla-central/source/content/base/test/test_bug199959.html |
| 07:58 | <hsivonen> | Hixie: getAttributeNode should lower-case, right? |
| 07:58 | <Hixie> | i have no idea off hand |
| 07:59 | <Hixie> | i thought it was the setters that lowercased |
| 07:59 | <Hixie> | i don't think much content cares about Attribute nodes |
| 07:59 | <zcorpan> | hsivonen: acid3 doesn't seem to test mixed case with getAttributeNode |
| 07:59 | <hsivonen> | I don't even understand what I did to make that test fail |
| 08:00 | <hsivonen> | zcorpan: ok |
| 08:00 | <hsivonen> | I guess I should test what other browsers do |
| 08:02 | <zcorpan> | hmm weird... opera seems to change the case of the attribute upon getAttributeNode |
| 08:03 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/42 |
| 08:04 | <hsivonen> | http://hsivonen.iki.fi/test/moz/getAttributeNode.html |
| 08:05 | <hsivonen> | alerts [object Attr] in Firefox 3, Opera 10 and WebKit trunk |
| 08:05 | <zcorpan> | hsivonen: inspect the attribute's local name before and after getAttributeNode |
| 08:06 | <zcorpan> | hsivonen: in opera it's "foo" before and "Foo" after |
| 08:06 | <hsivonen> | that seems bad |
| 08:06 | <zcorpan> | yes |
| 08:06 | <hsivonen> | zcorpan: what do you use to check? |
| 08:07 | <zcorpan> | nodeName |
| 08:07 | <zcorpan> | actually just the live dom viewer :) |
| 08:07 | <zcorpan> | see above |
| 08:07 | <jgraham> | MikeSmith: You seen http://www.youtube.com/watch?v=6vgmp4MmfG0 ? |
| 08:08 | <hsivonen> | zcorpan: WebKit and Gecko seem sane here :-) |
| 08:09 | <zcorpan> | hsivonen: what do they do? |
| 08:09 | <hsivonen> | zcorpan: they return the attribute node without mutating it, so presumably they lower-case the getter argument |
| 08:10 | <zcorpan> | try with a mixed case attribute (using setAttributeNS) |
| 08:10 | <hsivonen> | actually, WebKit seems to do a case-insensitive compare |
| 08:10 | <hsivonen> | sigh |
| 08:10 | <hsivonen> | Gecko seems to lower case |
| 08:11 | <hsivonen> | whoa! IE8 has the same craziness as Opera |
| 08:11 | <zcorpan> | ie8 supports getAttributeNode? |
| 08:11 | <hsivonen> | zcorpan: seems so |
| 08:12 | <hsivonen> | I wonder if they create attribute nodes lazily and take the node name from the getter argument |
| 08:12 | <zcorpan> | hsivonen: my copy of webkit seems to lowercase |
| 08:13 | <zcorpan> | yeah that might be what we do |
| 08:13 | <hsivonen> | zcorpan: oh? what's your copy of WebKit? |
| 08:13 | <zcorpan> | the one that came with safari 4 beta |
| 08:13 | <zcorpan> | no wait |
| 08:13 | <hsivonen> | zcorpan: I'm trying http://software.hixie.ch/utilities/js/live-dom-viewer/saved/42 in a nightly from yesterday or so |
| 08:14 | <zcorpan> | the one that came with safari 3.2.1 |
| 08:14 | <zcorpan> | ok |
| 08:14 | <hsivonen> | zcorpan: with which test case? |
| 08:14 | <zcorpan> | same |
| 08:15 | <zcorpan> | i get null |
| 08:15 | <hsivonen> | ok. I wonder why they changed it. |
| 08:15 | <zcorpan> | maybe just to align with moz |
| 08:16 | <hsivonen> | zcorpan: but moz seems to lower case! |
| 08:16 | <MikeSmith> | jgraham: we could use the Flight of the Conchords guys in some standards discussions |
| 08:16 | <zcorpan> | uh right |
| 08:18 | <zcorpan> | hsivonen: what does getAttribute() do? case-insensitive or lower case? |
| 08:19 | <zcorpan> | hsivonen: i guess it'd be nice if it worked with <svg viewBox> |
| 08:19 | <hsivonen> | zcorpan: we definitely need to push this stuff down to HTMLElement instead of Element |
| 08:20 | <zcorpan> | ah |
| 08:20 | <zcorpan> | and also check the htmlness of the document? |
| 08:20 | <hsivonen> | zcorpan: reading Gecko's code without testing, it lower cases |
| 08:20 | <hsivonen> | zcorpan: that, too |
| 08:20 | <jgraham> | MikeSmith: Heh |
| 08:20 | <zcorpan> | yep lowercases in my safari too |
| 08:21 | <hsivonen> | zcorpan: createAttributeNode without NS will have to suck for SVG in HTML docs :-( |
| 08:22 | <Hixie> | createAttributeNode sucks regardless of namespace :-) |
| 08:23 | <Hixie> | zcorpan: you should just drop Attribute nodes altogether |
| 08:23 | <zcorpan> | yeah i've commented out createAttributeNode in web dom |
| 08:23 | <zcorpan> | i don't know how to deal with .attributes, though |
| 08:23 | <zcorpan> | and attributes in general |
| 08:23 | <zcorpan> | they're such a pita |
| 08:24 | <Hixie> | what's the problem? |
| 08:24 | <zcorpan> | maybe that i haven't wrapped my head around them yet |
| 08:25 | <Hixie> | i'd remove all the methods with Attr in their name that take Node objects |
| 08:26 | <Hixie> | and change .attributes to just return a DOMStringList or a list of objects that barely look like Node objects or something |
| 08:26 | <Hixie> | might be tough if content relies on any of this though |
| 08:27 | <Hixie> | ask bloo for stats :-) |
| 08:28 | <zcorpan> | Hixie: i've removed all such methods already, it seems |
| 08:28 | <Hixie> | cool |
| 08:28 | <zcorpan> | bloo? |
| 08:28 | <virtuelv> | zcorpan: brian wilson |
| 08:29 | <virtuelv> | he's one of your coworkers :D |
| 08:29 | <Philip`> | http://www.mtq.gouv.qc.ca/ - anchors[0].getAttributeNode("href").value.toLowerCase() |
| 08:30 | <Philip`> | http://www.corestyle-ent.de/ - $('commentFunc').setAttributeNode(href) |
| 08:31 | <Philip`> | plus a handful of others |
| 08:31 | <zcorpan> | :( |
| 08:32 | <Hixie> | you might be able to get away with just getAttributeNode and setAttributeNode and .attributes, with some very bare bones objects |
| 08:32 | <Hixie> | (Attr objects with just nodeName and value, maybe; i haven't checked what would be needed) |
| 08:33 | <Philip`> | You'd need createAttribute too |
| 08:36 | <Hixie> | really? people use that? i hate the web. |
| 08:37 | <Philip`> | http://www.corestyle-ent.de/ - document.createAttribute("href") |
| 08:37 | <olliej> | Hixie: heh, i was thinking that just the other day |
| 08:37 | <zcorpan> | hsivonen: i think i'll specify getAttributeNS to return null instead of empty string in case of absent attribute, just like getAttribute |
| 08:39 | <hsivonen> | zcorpan: Is that what browsers already do except for Gecko for XUL? |
| 08:39 | <zcorpan> | hsivonen: it's what opera does last i checked. i remember webkit returning the empty string last i checked |
| 08:39 | <zcorpan> | (which was some time ago) |
| 08:40 | <annevk3> | Hixie, the <dfn>obtain the storage mutex</dfn> sentences you added are not class=impl |
| 08:40 | <Hixie> | oops |
| 08:41 | jgraham | finds it mildly amusing that Hixie is still surprised by the web |
| 08:42 | <Hixie> | annevk3: you sure? |
| 08:42 | <annevk3> | Hixie, if it is in fact wrapped in a <div> the preceding paragraph can have its class attribute removed |
| 08:43 | <annevk3> | (it looks like it is wrapped in a <div>) |
| 08:43 | <Hixie> | oh, yeah, i forgot to remove that class when i moved the pause paragraph |
| 08:43 | <Hixie> | thanks |
| 08:48 | <zcorpan> | Hixie: btw, the dom-intro boxes are very useful. now i can actually use html5 as a reference when wanting to look up how something works :) |
| 08:48 | <Hixie> | cool |
| 08:50 | <zcorpan> | Hixie: s/title="impl"/class="impl"/g |
| 08:52 | <Hixie> | thanks fixed |
| 08:57 | <Hixie> | hmm |
| 08:57 | <Hixie> | maybe you can have one lock per origin |
| 08:57 | <Hixie> | since there's no way for one origin to synchronously do anything to another origin... |
| 08:57 | <Hixie> | or is there... |
| 08:58 | <annevk3> | I thought focus() was one of those things last we checked. |
| 08:58 | <Hixie> | does that really need to synchronously fire the focus event though? |
| 08:59 | <annevk3> | I'll bow out here :) |
| 09:00 | <zcorpan> | Hixie: things like "s[pos+1]" have a green underline |
| 09:03 | <Hixie> | reload |
| 09:08 | <Hixie> | ok nn |
| 09:08 | <annevk3> | nn |
| 09:08 | <zcorpan> | http://forums.whatwg.org/viewtopic.php?t=4065 |
| 09:32 | <jgraham> | That forum post seems to raise a reasonable point |
| 09:33 | <zcorpan> | can't web workers just assume the latest and greatest? |
| 09:33 | <zcorpan> | actually i'd like all scripts to assume the latest and greatest |
| 09:33 | <annevk3> | what if something new is introduced beyond that? |
| 09:34 | <annevk3> | I do agree though |
| 09:35 | <Philip`> | zcorpan: If they assume JS 1.7, what happens when a future JS 1.x adds some more slightly-backwards-incompatible syntax? |
| 09:35 | <Philip`> | (You could assume 1.7 for workers because there's no legacy yet, but there will be some soon) |
| 09:35 | <zcorpan> | Philip`: same as what we do with html and css |
| 09:36 | <Philip`> | zcorpan: That only works because HTML and CSS ignore unknown syntax extensions, and JS doesn't |
| 09:36 | <jgraham> | The problem is that JS n+1 has different semantics to JS n |
| 09:37 | <jgraham> | This is not an ideal situation, but I don't think we can "fix" it this way |
| 09:38 | <Philip`> | More specifically, the problem is it has different semantics for code which compiles |
| 09:38 | <Philip`> | (Nobody seems to mind changing "fun(x) x+1" from a syntax error into a function - it's still a change in the semantics of that string, but not one that's going to break anything in practice) |
| 09:39 | <zcorpan> | i guess this was a problem also when going from js1.1...1.6 |
| 09:39 | <zcorpan> | but we don't require a version flag to indicate 1.6 |
| 09:39 | <Philip`> | They didn't introduce any new syntax |
| 09:39 | <Philip`> | (I think) |
| 09:41 | <Philip`> | (And you don't need a version flag to indicate all of 1.7's features, nor even for some of its syntax; only its backward-incompatible syntax, like new keywords) |
| 09:41 | <jgraham> | Yeah, things like yield |
| 09:41 | <jgraham> | and let |
| 09:41 | <Philip`> | (so it's not really any different to the previous versions) |
| 09:42 | <Philip`> | (except that the backward-incompatible syntax in previous versions was an empty set, and so the whole version string got optimised away into non-existence) |
| 09:43 | <zcorpan> | i guess there are some options: |
| 09:43 | <jgraham> | (you could always have in-band metadata to indcate the language version which would be a more flexile and better solution but it's not clear that we should try and force the issue by having odd requirements for workers) |
| 09:44 | <zcorpan> | (1) out of band version flag (currently in mozilla) |
| 09:44 | <zcorpan> | (2) in-band version flag |
| 09:44 | <Philip`> | (In-band metadata still doesn't survive copy-and-paste so it's not great) |
| 09:44 | <zcorpan> | (3) let 'yield' etc be overwritable (ugly but might work) |
| 09:44 | <Philip`> | (It's not a problem in practice yet because nobody uses JS 1.7, but it would matter if we started expecting everybody to use it, like how we expect everyone to use standards-mode doctypes) |
| 09:44 | <zcorpan> | (4) let things break |
| 09:45 | <jgraham> | (people use JS 1.7 but not really on the web) |
| 09:45 | <jgraham> | (just for things like Mozilla extensions) |
| 09:46 | <zcorpan> | on the web, how bad would (4) be? |
| 09:46 | <Philip`> | zcorpan: function f() { if (Math.random() < 0.5) eval("var yield = 1"); yield; } -- how would that work in your (3)? |
| 09:46 | <jgraham> | 4) is a non option, 3) I don't really understand, 2) seems reasonable but won't pass with TC39 and 1) will happen regardless of what HTML 5 says (I guess) |
| 09:46 | <zcorpan> | Philip`: dunno |
| 09:47 | <Philip`> | You need to know at compile-time whether it's a keyword or an identifier |
| 09:48 | <zcorpan> | then i guess (3) doesn't work |
| 09:48 | <zcorpan> | jgraham: why is (4) not an option? |
| 09:48 | <Philip`> | I suppose you could make window.yield be a function, so you'd write yield(42) and could override it with var, so you wouldn't have any new keywords, but that wouldn't help with let |
| 09:48 | <jgraham> | zcorpan: You can't really let deployed scripts break and expect implementors to implement |
| 09:49 | <jgraham> | e.g. Mozilla have already shown that they are not prepared to do that |
| 09:49 | <Philip`> | http://google.com/codesearch/p?hl=en#PSg8XFiA2K0/plugins/letters/letters.js&q=%22var%20let%22%20lang:javascript |
| 09:49 | <Philip`> | http://google.com/codesearch/p?hl=en#1WvUcq2GgMs/mozilla/cmd/dialup/tools/cg/docs/ias/sltab.js&q=%22var%20let%22%20lang:javascript |
| 09:49 | <Philip`> | People use 'var let = ...' quite a bit for letters |
| 09:50 | <Philip`> | Actually just look at http://google.com/codesearch?q=%22var+let%22+lang:javascript , that's much easier |
| 09:51 | <Philip`> | or http://google.com/codesearch?q=var%5Cs%2Blet%5Cb+lang%3Ajavascript |
| 09:51 | <jgraham> | It is telling that the first result is a mozsilla regression test suite |
| 09:51 | <jgraham> | *mozilla |
| 09:51 | <Philip`> | I'm not sure what that's telling of |
| 09:52 | <Philip`> | particularly since all the rest look like real code in the wild |
| 09:52 | <jgraham> | It's telling of the fact that they have had bugs with breaking that case |
| 09:52 | <jgraham> | And can't afford to again |
| 09:53 | <jgraham> | Which backs up my statement that 4) is a non-option |
| 09:53 | <Philip`> | https://bugzilla.mozilla.org/show_bug.cgi?id=351515 - "yield" can no longer be used as an argument name (Mercury News page not rendered properly for FF2) |
| 09:53 | <zcorpan> | ok, so maybe enough would break for 'let' and 'yield'... that still leaves the options of in-band flag and renaming 'let' and 'yield' to something else that doesn't break as much (also ugly though) |
| 09:54 | <Philip`> | Take the C99 approach, and call them __let and __yield |
| 09:54 | <jgraham> | No |
| 09:54 | <Philip`> | Good |
| 09:54 | <jgraham> | Ther are limits |
| 09:55 | <roc> | I'm sure there are some free Unicode characters we could use |
| 09:55 | <roc> | the Perl6 approach |
| 09:57 | <Philip`> | U+22A2 RIGHT TACK (turnstile; proves, implies, yields; reducible) |
| 09:59 | jgraham | wants U+1D4F5 U+1D4EE U+1D4FD |
| 09:59 | <Philip`> | 𝓵𝓮𝓽? |
| 10:00 | jgraham | just sees replacement characters for that in irssi sadly |
| 10:00 | Philip` | too |
| 10:00 | <Philip`> | and on krijnh's logs |
| 10:00 | <Philip`> | Oh wait, no, it eventually loaded the right font for the logs |
| 10:01 | zcorpan | doesn't seem to have fonts for those glyphs |
| 10:01 | <Philip`> | jgraham: I like your idea - it would be a good way to shake out bugs in code that relies on UCS-2 |
| 10:01 | <jgraham> | zcorpan: Try Code2001 |
| 10:02 | <Philip`> | zcorpan: Try Arial Unicode MS |
| 10:02 | <jgraham> | Philip`: Sadly ES3.1 only requires Unicode 3.0 |
| 10:02 | jgraham | isn't actually sure which font he is seeing |
| 10:02 | <Philip`> | jgraham: But our new version can require whatever it wants |
| 10:03 | <jgraham> | Philip`: True. |
| 12:01 | <Dashiva> | One thing I wonder about lastweek. Does he actually care about web development, or are we just the canvas for his latest masterpiece? |
| 12:34 | hsivonen | wonders if there's a logical reason why the window.frames is on window instead of being document.frames |
| 12:35 | <annevk3> | it returns window objects |
| 12:35 | <hsivonen> | ah |
| 12:35 | <annevk3> | except that it doesn't, it's just a synonym for window nowadays |
| 12:36 | <annevk3> | (except in Opera, where it still returns a list of window objects, for some versions) |
| 12:40 | <MikeSmith> | hsivonen: I notice that the whattf assertions.sch file is using the XPath id() function. But is id() ever actually going to work? Doesn't id() depend on either access to a DTD that declares what attributes are IDs, or xml:id? |
| 12:44 | <hsivonen> | MikeSmith: the HTML5 parser assigns IDness to id. for XML, there's an 'XHTML id processor' that assigns IDness to id |
| 12:50 | <MikeSmith> | hsivonen: I see. I ask in the context of trying to test the assertions.sch file just with jing |
| 12:50 | <MikeSmith> | I can't see any way in that case for jing to know that @id is an ID |
| 12:50 | <MikeSmith> | right? |
| 12:51 | <hsivonen> | MikeSmith: not without adding a SAX filter between the XML parser and Jing |
| 12:55 | <MikeSmith> | hsivonen: OK. well, I'm in the midst of adding rules for additional constraints on the content model of the label element |
| 12:55 | <MikeSmith> | and for checking labelable elements |
| 12:55 | <MikeSmith> | e.g., I have this test for the input element: |
| 12:56 | <MikeSmith> | ancestor::h:label[@for] and not(id(ancestor::h:label/@for)) |
| 12:56 | <MikeSmith> | whoops |
| 12:56 | <MikeSmith> | no, not that |
| 12:58 | <MikeSmith> | this: |
| 12:58 | <MikeSmith> | ancestor::h:label[@for] and not(@id = ancestor::h:label/@for) |
| 12:58 | annevk3 | thought Schematron was going away |
| 12:58 | <MikeSmith> | annevk3: it is already gone, actually |
| 12:59 | <MikeSmith> | as far as what v.nu is actually using |
| 12:59 | <MikeSmith> | hsivonen moved the assertions logic to Java |
| 13:00 | <MikeSmith> | but it seems worthwhile to try to keep the schematron stuff (assertions.sch file) synced up |
| 13:00 | <MikeSmith> | hsivonen: anyway, what I'm wondering is, should that test check both for the @id and @xml:id |
| 13:00 | <MikeSmith> | or should I change it to use id() instead |
| 13:03 | <hsivonen> | MikeSmith: IIRC, I assign IDness to xml:id, but I've considered removing xml:id support, since it complicates code more that it first appears |
| 13:03 | hsivonen | looks |
| 13:04 | <MikeSmith> | hsivonen: I'm personally happy to ignore xml:id if you are |
| 13:04 | <hsivonen> | MikeSmith: it seems my 'XHTML id processor' is also an 'xml:id processor' |
| 13:05 | <MikeSmith> | hsivonen: OK |
| 13:05 | <hsivonen> | MikeSmith: if you use id(), things should Just Work |
| 13:06 | <hsivonen> | MikeSmith: the filter is called nu.validator.xml.IdFilter in the util svn repo |
| 13:06 | <MikeSmith> | thanks |
| 13:19 | <jgraham> | Oh joy the blizzard has started again |
| 13:47 | <MikeSmith> | hsivonen: do you know if schematron supports generate-id() ? |
| 13:49 | <hsivonen> | MikeSmith: I have no idea. I don't even know what generate-id() is. |
| 13:49 | <MikeSmith> | OK |
| 13:49 | <MikeSmith> | wondering how to compare two nodes in schematron to test whether they are the same |
| 13:50 | <MikeSmith> | because id() returns a nodeset |
| 13:50 | <hsivonen> | MikeSmith: Schematron is hard for anything but the most trivial use cases... :-( |
| 13:51 | <MikeSmith> | yeah |
| 14:01 | <itpastorn1> | #Brucespringsteen Queen of the Supermarket - a banality with charm and really suggestive crescendo. What Love can do - not one I'll be wishing for in concert. |
| 14:38 | <annevk3> | whoa WebKit normalizes URLs |
| 14:40 | <annevk3> | but it does not conform to RFC 3987 either because it also does it for UTF-8 |
| 14:40 | <annevk3> | Firefox and Opera both have HTML5 URL handling for CSS |
| 14:43 | <annevk3> | IE6 (all I have) does the path per HTML5 URL handling and for the query component it seems to transmit raw UTF-8 bytes rather than percent escaping them |
| 14:43 | <annevk3> | nevertheless, it does not normalize either |
| 14:46 | <zcorpan> | annevk3: http://www.xenocode.com/browsers/ |
| 14:49 | <annevk3> | zcorpan, how do I use it? |
| 14:55 | <annevk3> | I should note that all browsers force the URL encoding flag to be UTF-8 |
| 14:55 | <annevk3> | for CSS |
| 14:59 | <hsivonen> | zcorpan: "This service is unavailable on your device." |
| 15:01 | <annevk3> | (IE is actually sending raw UTF-8 bytes over HTTP. Can we simply upgrade HTTP to be UTF-8 without major cost?) |
| 15:04 | <hsivonen> | annevk3: next servers will have to compare HTTP method literals for canonical equivalence |
| 15:07 | <annevk3> | yeah, and headers in your native language! |
| 15:07 | <annevk3> | Japan is jumping up and down for that one, for sure |
| 15:08 | <Philip`> | X-UA-矛盾しない: IE=9 |
| 15:08 | <Philip`> | What's the Japanese for "X" and for "UA"? |
| 15:09 | <Dashiva> | What does the X mean, semantically? |
| 15:09 | <annevk3> | Philip`, the halfwidth equivalents |
| 15:10 | <annevk3> | Dashiva, "should not be used" |
| 15:10 | <jcranmer> | yes, that would be the best way |
| 15:10 | <jcranmer> | (I think X is for eXtension) |
| 15:10 | <Dashiva> | I would cook up 利機 for UA |
| 15:10 | annevk3 | is amazed how bz keeps replying |
| 15:10 | <Dashiva> | (Two-part shortening of the full "User Agent") |
| 15:11 | <hsivonen> | I wonder if there's a way to tell MacPorts not to use FTP mirrors |
| 15:11 | <Philip`> | Dashiva: What's the Japanese for "the X factor"? |
| 15:11 | <Dashiva> | I don't know, my vocabulary is kinda weak |
| 15:11 | <jcranmer> | 張 is probably the closest to X |
| 15:12 | <jcranmer> | since 拡張子 is extension |
| 15:13 | <jcranmer> | 子 might be good as well (it means child by itself) |
| 15:13 | <Dashiva> | I don't think that's the right kind of extension |
| 15:13 | <jcranmer> | 拡張, then? |
| 15:14 | <jcranmer> | I'm relying on google's translate here |
| 15:14 | <Dashiva> | Well, there are some people who actually know Japanese in these circles |
| 15:14 | <Dashiva> | We could ask them :P |
| 16:39 | <gsnedders> | The PHP tokenizer is slow… |
| 16:41 | <jgraham> | gsnedders: Slow in a "this is written in PHP" way or slow in a "this is really slow PHP" way? |
| 16:41 | <gsnedders> | jgraham: Mainly the former |
| 16:41 | jgraham | doesn't really know why he is asking since he cares so little about PHP |
| 16:42 | gsnedders | cares more than he'd like to |
| 16:42 | <gsnedders> | Also: Kcachegrind is really slow with 450MB files |
| 16:47 | <Philip`> | gsnedders: The idea is to run it on a small representative data set, so you don't end up with pointlessly huge amounts of data to analyse :-p |
| 16:47 | <gsnedders> | Philip`: This is running it on the spec :P |
| 16:47 | <gsnedders> | Philip`: Which, as I'm sure you'd agree, is the only HTML document that actually matters in terms of how long it takes to parse :P |
| 16:48 | <Philip`> | gsnedders: The spec is very uniform, so you could run it on e.g. the first 100KB and the data would be just as good |
| 16:48 | <gsnedders> | Philip`: That's boring. |
| 16:50 | <Philip`> | gsnedders: It's not my fault that your problem has a perfectly adequate but boring solution |
| 16:51 | <Philip`> | Is the Internet/Trusted zone <input type=file> discussion the list really about Internet/Trusted, or is it about IE8-mode/IE7-mode? |
| 16:54 | <hsivonen> | it would be silly for the IE7 mode to be less secure |
| 16:54 | <Philip`> | And IE would never do anything silly? |
| 16:55 | <Philip`> | http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx - "we changed from ALLOW to DENY for the Internet Zone “Include local directory path when uploading files” security setting" |
| 16:55 | <Philip`> | so it does sound like a zone-related thing |
| 16:56 | <hsivonen> | ooh. the twitter FAIL WHALE is back |
| 16:56 | annevk3 | wonders when the rest of the WHATWG cabal joins twitter |
| 16:57 | Philip` | hasn't even joined the blogosphere |
| 16:57 | <gsnedders> | So, I'm down to just over two minutes to tokenize the spec. |
| 16:57 | <annevk3> | two minutes?! |
| 16:58 | <annevk3> | wow, I thought the Python impl was slow |
| 16:58 | <hsivonen> | http://stackoverflow.com/questions/674184/why-is-xhtml-1-0-transitional-so-popular |
| 16:59 | <mpilgrim> | must. resist. fist of death. |
| 16:59 | <gsnedders> | annevk3: CPython is far quicker than the PHP interpreter |
| 16:59 | <Philip`> | gsnedders: What's the bottleneck in the PHP tokeniser? |
| 16:59 | <gsnedders> | annevk3: Also, this is me having only just started optimizing it |
| 17:04 | <gsnedders> | Philip`: Oh, just the design of parts of it in general :P |
| 17:04 | <gsnedders> | (I halved the time by going from treating it as UTF-8 to US-ASCII-with-random-bytes-above-7F) |
| 17:07 | <jgraham> | gsnedders: Who is going to use the PHP implementation? |
| 17:07 | <jgraham> | Or rather, how fast would it have to be for people to use the PHP implementation? |
| 17:07 | <jgraham> | And is that possible? |
| 17:08 | <gsnedders> | jgraham: Oh, it's probably quick enough already :P |
| 17:08 | <Philip`> | It can never be quick enough! |
| 17:08 | <gsnedders> | jgraham: Probably mainly sanitizing fragments |
| 17:09 | <jgraham> | gsnedders: It sounds pretty slow. I know the HTML5 spec is longer than most user entered content but you would still want pretty reasonable performance in a sanitizer |
| 17:10 | <gsnedders> | jgraham: If you really want perf., you don't use PHP. |
| 17:10 | <jgraham> | Like the python implementation seems barely fast enough |
| 17:10 | <jgraham> | gsnedders: I thought some large sites used PHP |
| 17:11 | <gsnedders> | jgraham: Plenty do. |
| 17:11 | <gsnedders> | jgraham: Plenty use Ruby, and that's slower. |
| 17:11 | <jgraham> | gsnedders: Is ruby really slower? |
| 17:11 | <jgraham> | (is ruby html5lib slower than PHP html5lib?) |
| 17:11 | <gsnedders> | jgraham: I think now it isn't, but when Rails really started to gain traction is was |
| 17:13 | <Philip`> | Nobody cares about performance - they start with ten visitors a day and there's no problem, and then they explode and have a million users a day and just buy a load of hardware because they haven't got time to rewrite their code, and it works perfectly well |
| 17:14 | jgraham | has never had a site explode |
| 17:14 | <jgraham> | But then I've never had 10 visitors a day either |
| 17:15 | <MikeSmith> | hsivonen: http://pastebin.com/m5e69774f |
| 17:15 | <MikeSmith> | hsivonen: patch to assertions.sch to capture additional contraints on <label> and descendants |
| 17:16 | <Philip`> | Performance matters if you've got some long-term stable service and it's worth spending time on optimisation, but in those cases you're probably working in an enterprise and therefore writing in Java, rather than using anything fun like Ruby or Python |
| 17:18 | <MikeSmith> | hsivonen: includes tests to check the id values of labelable descendants of a <label> that has a 'for' attribute |
| 17:20 | <jgraham> | Philip`: I'm not sure that's true |
| 17:20 | <MikeSmith> | hsivonen: tests by comparing to union of node sets. I don't know any other way to do it in XPath if the test needs to use id() rather than checking for explicit @id or @xml:id |
| 17:20 | <jgraham> | Depending on what you mean by "long term" and "stable" |
| 17:21 | <jgraham> | e.g. is Amazon a "long term stable service"? |
| 17:21 | <Philip`> | jgraham: I'm sure it's not true |
| 17:29 | <MikeSmith> | hsivonen: and did it that test to begin with because the spec seems to allow, e.g., <label for=foo>bar <input id=foo> </label> |
| 17:31 | <MikeSmith> | though i don't knwo why anybody would want to do that instead of just omitting that id on input entirely |
| 17:31 | <Hixie> | apparently for compatibility with IE |
| 17:36 | <MikeSmith> | Hixie: IE requires an explicit ID reference? |
| 17:36 | <Hixie> | iirc |
| 17:36 | <annevk3> | it does |
| 17:36 | <MikeSmith> | geez |
| 17:36 | <annevk3> | (might have been fixed in IE8?) |
| 17:37 | <MikeSmith> | hope so |
| 17:40 | <zcorpan> | wasn't it fixed in ie7 already? |
| 17:40 | <zcorpan> | anyway i think some screen readers might require it, too |
| 17:40 | <MikeSmith> | ah |
| 17:41 | <zcorpan> | MikeSmith: http://simon.html5.org/test/validator/content-model/label/ |
| 17:42 | <MikeSmith> | zcorpan: thanks |
| 17:42 | MikeSmith | looks now |
| 17:43 | myakura | thinks that's fixed in IE7 |
| 17:53 | <annevk3> | cool |
| 17:53 | annevk3 | hardly ever needs to make sites that function properly in IE anymore |
| 17:59 | <MikeSmith> | annevk3: well, if MS is really going to be shipping IE6 with Windows Mobile, I guess it's going to remain a problem for a lot longer |
| 18:00 | <MikeSmith> | assuming anybody actually browses from Windows Mobile devices with IE |
| 18:00 | <annevk3> | and assuming anyone actually tests their site |
| 18:00 | <annevk3> | or cares |
| 18:01 | <Hixie> | or uses windows mobile |
| 18:01 | <Hixie> | well wonderful |
| 18:01 | <Hixie> | i ask chrome and webkit to comment on the fakepath issue |
| 18:01 | <annevk3> | and uses windows mobile with IE |
| 18:01 | <Hixie> | hoping they'd both weight on one side and so breaks the deadlock |
| 18:01 | <Hixie> | but nooo |
| 18:02 | <Hixie> | apple don't want fakepath, and chrome do. :-P |
| 18:02 | <MikeSmith> | heh |
| 18:02 | <annevk3> | arguably that makes 2.5 to 1.5 |
| 18:02 | <annevk3> | counting each WebKit impl as .5 (with apologies to olliej) |
| 18:03 | <Hixie> | which side is opera on again? :-) |
| 18:03 | <Hixie> | and i was counting the author complaints as a +1 to the filename-only side |
| 18:10 | <annevk3> | Hixie, I believe we rather avoid yet another change |
| 18:10 | <annevk3> | s/I believe// |
| 18:11 | <Hixie> | the argument against c:\fakepath\ seems weaker to me |
| 18:12 | <annevk3> | there's two arguments I believe 1) consistency and 2) ugly |
| 18:13 | <annevk3> | both are true but mostly go away once we have the better File API on <input> afaict |
| 18:14 | <Philip`> | Adding new different APIs makes things more inconsistent, not less |
| 18:26 | <annevk3> | Philip`, we need the new API anyway and it will be consistent with HTTP |
| 18:39 | <roc> | we'd rather avoid yet another change too |
| 18:41 | <Hixie> | well someone will have to change :-) |
| 18:41 | <roc> | really? |
| 18:42 | <Hixie> | if we want browsers doing the same thing, yes |
| 18:42 | <Hixie> | since they don't do the same thing yet |
| 18:43 | <itpastorn> | How can I make PDT Eclipse HTML 5 and CSS 3 aware in its error reporting? |
| 18:44 | <jwalden> | http://www.khronos.org/news/press/releases/khronos-launches-initiative-for-free-standard-for-accelerated-3d-on-web/ |
| 18:50 | <roc> | Hixie: I don't see any email from a Chrome person in that thread |
| 18:50 | <roc> | about fakepath |
| 18:55 | <jgraham> | jwalden: On an entirely different topic, in your example, even Haskell is easier to read than scheme (and, at least I, find Haskell is often quite hard to grasp, although I admit I have had almost no experience) |
| 18:56 | <jwalden> | true enough |
| 18:56 | <jwalden> | I wasn't a fan of the parens because they nearly require you to use a code editor to write the stuff |
| 18:56 | <jwalden> | unless you use the indent style I did in the one example |
| 18:56 | <jwalden> | a closing line with seven or eight ) is just not easy to read at all |
| 18:57 | <jwalden> | I touched haskell a little in cs152 but not much; most was sml |
| 19:09 | <Philip`> | jwalden: Nice that they're doing it in a group that only costs $7500/year to join as a contributor |
| 19:16 | <annevk3> | http://www.khronos.org/news/press/releases/khronos-launches-initiative-for-free-standard-for-accelerated-3d-on-web/ |
| 19:16 | <Philip`> | annevk3: Old news :-p |
| 19:17 | <Philip`> | http://krijnhoetmer.nl/irc-logs/whatwg/20090324#l-737 |
| 19:21 | <annevk3> | oh wow |
| 19:21 | <annevk3> | my bad |
| 19:49 | <Hixie> | roc: they didn't send mail, i spoke to them in #chromium |
| 21:04 | <roc> | comment on Canvas 3D: "nothing new here. VRML did it all ten years ago" |
| 21:07 | <annevk3> | I'm assuming that's not a personal comment? |
| 21:08 | <annevk3> | Kind of sucks btw that Khronos requires yet another set of fees to be paid... |
| 21:09 | <roc> | it's not my comment, no :-) |
| 21:21 | <Philip`> | It'd be better to compare it to X3D rather than VRML |
| 21:23 | <Philip`> | http://www.web3d.org/x3d/publiclists/x3dpublic_list_archives/0712/msg00127.html is my ramblings on X3D vs C3D from a while ago |
| 21:34 | <Hixie> | shepazu: do you know off-hand where i should point to in the SVG specs for the requirements on how to execute scripts? |
| 21:34 | <ojan> | Hixie: dhyatt had a bunch of feedback on #webkit wrt to menu. are his comments there sufficient? or should i bug him to write his thoughts to whatwg more formally? |
| 21:35 | <Hixie> | shepazu: like, downloading the file, how to determine the character encoding, how to bind the global object, etc? |
| 21:35 | <Hixie> | ojan: i don't track irc feedback, so e-mail or bugs would be very useful |
| 21:37 | <Hixie> | shepazu: i'm guessing http://www.w3.org/TR/SVGMobile12/script.html#ScriptContentProcessing ? |
| 21:43 | <Hixie> | gah, how do i define what happens if a <script> in SVG document.write()s a <script> in HTML that then document.write()s a <script> in SVG... |
| 21:43 | <Philip`> | Fatal error; abort processing |
| 21:49 | <Hixie> | woah, svg has more serious blocking behavior than html |
| 21:49 | <Hixie> | if you insert a <script xlink:href="x"/> into a document, it does a sync network load?! |
| 21:49 | <Hixie> | that can't be right |
| 21:50 | <annevk3> | How does an SVG <script> document.write() an HTML <script>? |
| 21:50 | <annevk3> | document.write("<img><script>") or something? |
| 21:50 | <annevk3> | (or something else than <img> that is on the escape <svg> tree list) |
| 21:50 | <Hixie> | <svg><script>document.write('<foreignContent><div><script>...</script></div></foreignContent>')</script></svg> |
| 21:51 | <Hixie> | shepazu: yt? |
| 21:51 | <Hixie> | or anyone from the svgwg? |
| 21:51 | Hixie | looks around for an #svg chanel |
| 21:52 | <annevk3> | there is one on irc.w3.org at least |
| 21:54 | <Hixie> | <html><svg><script>document.write('<foreignContent><div><script src="x"></script>[2. parser stops here until script is available]</div></foreignContent>')</script>[1: parser stops here to execute previous script and then continues stopped here waiting for the d.w() text to be parsed]</svg> |
| 21:56 | <Hixie> | i guess the blocking really is for everything |
| 21:56 | <Hixie> | wow |
| 21:58 | <annevk3> | it may not be intentional ;) |
| 21:58 | <Hixie> | ooh, i know what i can do |
| 21:58 | <Hixie> | just set the parser pause flag to true before processing the script element |
| 21:58 | <Hixie> | that way document.write() is never synchronous for SVG |
| 21:59 | <annevk3> | what is the problem with document.write being synchronous? |
| 21:59 | <annevk3> | I mean, why can't it work the same for SVG? |
| 22:00 | <Hixie> | because that would require getting the svg spec rewritten in terms of the html spec's various lists of pending scripts |
| 22:00 | <Hixie> | and i doubt they want to be dependent on html |
| 22:01 | <annevk3> | since when can specs trump impl/authors/etc. |
| 22:01 | <Hixie> | well in this particular case it makes everything simpler |
| 22:01 | <Hixie> | which i think is probably a win for all of those too |
| 22:02 | <Hixie> | but if you want to try getting svg and html5 to use the same terminology and processing model here, please, be my gues |
| 22:02 | <Hixie> | t |
| 22:02 | <Hixie> | you have until october :-) |
| 22:05 | <annevk3> | meh, not impressed :p |
| 22:06 | <annevk3> | until things are actually shipping in several browsers it seems there is all the chance in the world that things will change |
| 22:06 | <annevk3> | actually, even after that point details can still change |
| 22:07 | <Hixie> | i am happy to spec whatever the browsers do, but historically every time i have done this in a manner that involves other working group's technologies, there has been an uproar |
| 22:07 | <Hixie> | and i am not interested in getting involved in another process war with no technical content |
| 22:08 | <gsnedders> | Why not? |
| 22:08 | <Hixie> | annevk3: so if you can get the specs made consistent and well-defined in a way that matches what the browsers want to do, then i'll be happy to coordinate with you |
| 22:08 | <Hixie> | annevk3: but i'm not interested in trying to convince them myself when a simpler set of requirements can be achieved easily. |
| 22:11 | <annevk3> | I can sympathize with that, though it's noteworthy that the SVG crowd has (repeatedly) stated interest in a) aligning more with HTML and b) listening more to browser vendors. |
| 22:11 | <Hixie> | i will be very happy to work with both them and you if you are willing to take the lead on this |
| 22:15 | <gsnedders> | Hixie, annevk3: Can at least one of you reply to my email? |
| 22:15 | <Hixie> | i haven't had the time to actually test it |
| 22:15 | <Hixie> | i was going to mail you to say it'd be nice if it accepted <a href="#refsFOO">[FOO]</a> as well as [[FOO]], but then i thought about it more and decided that was dumb |
| 22:16 | <gsnedders> | The deadline isn't as soon as I thought, so I can have a day or two more, but I really need to get my computing project finished so I can get my English dissertation really underway |
| 22:16 | <Hixie> | basically i'm not sure what the point of a bibliography system is, given the desire i have of keeping the references maintained manually |
| 22:17 | <gsnedders> | Talking to you when I need to write a brief outline of the context and purpose of the project probably isn't a good idea :) |
| 22:17 | <gsnedders> | (This is the sort of introduction thing I hate writing, and have thus far avoided writing) |
| 22:18 | <Hixie> | i guess if the bibliography was in the form of <dd> blocks exactly as seen in the output |
| 22:18 | <Hixie> | and if the <dd> blocks could be placed in the file itself |
| 22:18 | <Hixie> | such that the system _removed_ references that weren't referenced |
| 22:18 | <Hixie> | and set up the cross-references (or indeed supported the aforementioned <a href=... syntax) |
| 22:18 | <Hixie> | then that would be cool |
| 22:19 | <gsnedders> | "Otherwise, is sucks." |
| 22:19 | <gsnedders> | :P |
| 22:19 | <Hixie> | since it would make the references for the various specs automatically come out as needed |
| 22:19 | <Hixie> | without needing an external, perpetually out-of-date, bibliography |
| 22:19 | <Hixie> | in a hard-to-maintain syntax that can't be made to do what i want to see |
| 22:21 | <gsnedders> | still, if you could email me sometime saying it sucks, do so. |
| 22:22 | gsnedders | gave up trying to keep you happy with this module a long time ago |
| 22:22 | <Hixie> | i don't know if it sucks, i haven't tested it :-) |
| 22:22 | <gsnedders> | Well, it doesn't do what you want it to do, hence it sucks |
| 22:22 | <Hixie> | it does what i want it to do if i don't use it :-) |
| 22:23 | <Hixie> | so actually it does what i want quite a lot of the time |
| 22:23 | <gsnedders> | :) |
| 22:25 | <gsnedders> | My next commit message on my project, on a commit just be changing the write-up, will be, "I really can't spell." |
| 22:25 | <annevk3> | I still haven't switched to Anolis |
| 22:25 | <gsnedders> | annevk3: Traitor! |
| 22:25 | <Hixie> | dude |
| 22:25 | <Hixie> | anolis rocks |
| 22:25 | <Hixie> | you should switch! |
| 22:25 | <annevk3> | I'm told. But it got the DOCTYPE wrong and the output looks less neat overall (apart from the IDs, which are better). |
| 22:25 | <Hixie> | i think i invoke it 7 or 8 times every time i make a change now, given how many specs i update at a time |
| 22:26 | <Hixie> | why does the output whitespace matter? |
| 22:26 | <Hixie> | and how is the doctype wrong? |
| 22:26 | <gsnedders> | It always gives the HTML 5 DOCTYPE |
| 22:27 | <annevk3> | The thing with the output whitespace is that I personally always read the diff of the output document to ensure everything that is linkified does so correctly. |
| 22:28 | <annevk3> | I suppose I can change that, but my specs don't have a couple of people reading the diffs every time I make a change... :) |
| 22:30 | <annevk3> | Anyway, I guess I should give it another chance and write a small script to do all the CVS stuff and some post-processing on the DOCTYPE... |
| 22:48 | <shepazu> | sorry, Hixie, was eating dinner |
| 22:50 | <Hixie> | np |
| 22:50 | shepazu | reads backscroll |
| 22:57 | heycam | wonders why he was CCed on the "localStorage and IE8" thread |
| 22:59 | gsnedders | asks "Why not?" |
| 23:00 | <heycam> | i really need to sort out my .procmailrc so that multiple copies of the same mail get put in different maildirs for the appropriate mailing lists |
| 23:00 | <heycam> | on that mail, all three copies (via public-html, via public-webapps, and the CCed one) just get dumped in my public-html maildir :/ |
| 23:01 | <shepazu> | Hixie: I'm not gainsaying what SVG Tiny 1.2 says, but note that that is much more specific than SVG 1.1, and the SVG WG might be willing to adopt a different script processing model for SVG-in-text/html and SVG 2.0 than in SVG Tiny 1.2 |
| 23:03 | <shepazu> | the goal for script processing in SVGT1.2 was to make it simpler and clearer, and I believe Opera had quite a lot of input there |
| 23:03 | <heycam> | and also to do effectively the same thing as html |
| 23:03 | <shepazu> | but if that causes problems for SVG-in-text/html, please feel free to make a proposal, and we will review it |
| 23:03 | <heycam> | if something's wrong there, i think we'd be pretty open to making an erratum for it |
| 23:04 | <shepazu> | yeah, I can't speak for everyone, but I'd tend to agree |
| 23:04 | <heycam> | Hixie, can you explain how the script blocking in HTML differs from that in SVG? |
| 23:04 | <Hixie> | shepazu: i don't think it causes any problems unless we actually want to support synchronous document.write() |
| 23:05 | <Hixie> | heycam: you were cc'ed because you contributed to some thread on the same topic over on the whatwg list |
| 23:05 | <heycam> | don't even remember saying anything about localStorage :) |
| 23:05 | <heycam> | Hixie, so SVG's script handling is not reentrant or something? |
| 23:05 | <Hixie> | let's see if i can construct an example |
| 23:05 | <shepazu> | this might be a relatively painless change, since there is unlikely to be content that relies heavily on the script processing model, and since browsers are really getting clearer on that, it would be a big win for SVG to align here |
| 23:06 | <Hixie> | (i can guarantee that this won't be painless, the text/html model is unbelievably complicated and brittle) |
| 23:06 | <shepazu> | oh, all the better |
| 23:06 | <Hixie> | imagine you have the following document: |
| 23:07 | <Hixie> | <html><script>A</script></html> |
| 23:07 | <Hixie> | and imagine the script A does the following: |
| 23:07 | <Hixie> | 1. document.write an external <script src="1"></script> block followed by an inline <script>2</script> block |
| 23:07 | <Hixie> | 2. document.append()s an inline <script>3</script> block |
| 23:08 | <Hixie> | the execution order will be, iirc, A, then 3, then 1, then 2 |
| 23:08 | <heycam> | oh |
| 23:08 | <Hixie> | and in the DOM, the script nodes will be in the order 1, 3, 2 |
| 23:08 | <heycam> | that is different from SVG then |
| 23:09 | <shepazu> | hmmm, well... at least this way, we'll be so numb with pain that we won't notice the order of processing |
| 23:10 | <Hixie> | if we do as i propose, namely say that document.write() is not synchronous from an SVG script block, then if you replace <html> with <svg> in the text/html snippet above, the execution order would be A, 3, 1, 2 |
| 23:10 | <Hixie> | and the DOM order will also be A, 3, 1, 2 |
| 23:11 | <heycam> | if it's not synchronous, would it still be defined the order things get inserted/run? (a queue of them is maintained or something?) |
| 23:11 | <Hixie> | if you switch 1 and 2 around so that 1 is inline and 2 is external instead, then in HTML, the execution order, iirc, becomes A, 1, 3, 2 and the DOM order becomes A, 1, 2, 3 |
| 23:11 | <Hixie> | but along my proposed model, in SVG it would still be A, 3, 1, 2 both in execution and DOM |
| 23:11 | <shepazu> | so, this sucks... honestly, I think the latter way is cleaner and more predictable, but paradoxically unintuitive because HTML does it the other way... |
| 23:12 | <heycam> | Hixie, does script processing differ in XHTML? |
| 23:12 | <shepazu> | then again, I don't know how much authors rely on execution order... any data? |
| 23:12 | <Hixie> | heycam: yeah, it's still all well-defined; you just end up parsing/executing all the document.written() stuff after the script ends |
| 23:12 | <Hixie> | heycam: in XHTML, document.write() throws. |
| 23:12 | <heycam> | awesome |
| 23:12 | <heycam> | :) |
| 23:12 | <Hixie> | yes. |
| 23:13 | <shepazu> | Hixie: can't you apply the same rules as you apply for SVG to XHTML? |
| 23:13 | <Hixie> | SVG in text/html? |
| 23:13 | <shepazu> | sorry, yes. |
| 23:13 | <shepazu> | (whichever those rules end up being) |
| 23:14 | Philip` | isn't sure it's worth adding support for XHTML in text/html |
| 23:14 | <Hixie> | not really, because an SVG <script> block could just invoke an HTML <script> block and then we'd be back in the same world |
| 23:15 | shepazu | is going to suggest a silly suggestion he will be crucified for: how about a new method, similar to .write(), that works async in all languages? |
| 23:15 | <Hixie> | we have that |
| 23:15 | <Hixie> | it's called document.appendChild() |
| 23:15 | <Hixie> | :-) |
| 23:15 | <shepazu> | oh. |
| 23:15 | <shepazu> | lol |
| 23:15 | <shepazu> | ok |
| 23:15 | <heycam> | given that the SVG spec only deals with SVG/XML, i wonder what the best way to define SVG script processing in text/html is -- i.e., in the SVG spec? or only in the HTML spec? |
| 23:15 | <heycam> | what changes would you need from the SVG spec for this? |
| 23:15 | <Hixie> | none |
| 23:16 | <Hixie> | if we want to just make document.write() async in SVG <script> |
| 23:16 | <heycam> | ok a secondary question then: does script processing in SVG/XML different from script processing in XHTML? |
| 23:16 | <heycam> | (my guess is yes?) |
| 23:16 | <Hixie> | if we want to make SVG use the same crazy-ass stuff HTML does, which we presumably would one if we ever want to support async="" or defer="" in SVG, then, uh, a lot. i dunno. see the <script> element definition in HTML5. |
| 23:16 | <shepazu> | sorry to stray here, but what about .innnerHTML()? |
| 23:17 | <Hixie> | innerHTML conveniently disables script execution. |
| 23:17 | <shepazu> | Hixie: we've already planned to add @async and @defer |
| 23:17 | <Hixie> | heycam: yes, though not in any particularly painful way other than SVG requiring sync I/O on the UI thread |
| 23:17 | <Hixie> | shepazu: oh. |
| 23:17 | <Hixie> | well that ought to be fun. |
| 23:18 | <heycam> | Hixie, could you explain why sync I/O on the UI thread follows from the current script processing definitions in SVG? |
| 23:18 | <Hixie> | shepazu: in that case we really should just have svg and html use the same mechanism with the event loop and everything |
| 23:18 | <shepazu> | just so authors are dealing with the same platform |
| 23:18 | <heycam> | what i would like is for scripts in SVG/XML to act the same as those in XHTML |
| 23:19 | <shepazu> | I think it would be useful to summarize this in an email, if you don't mind... |
| 23:19 | <Hixie> | heycam: well, parsing and script execution block, and parsing happens as part of processing a task on the event loop. |
| 23:19 | <heycam> | perhaps then it is just a matter of poor wording on my part then in that script processing section |
| 23:20 | <Hixie> | shepazu: summarise what? |
| 23:20 | <heycam> | it should just block the parser, no? |
| 23:20 | <Hixie> | heycam: the parser is on the ui thread (well, on the event loop) |
| 23:20 | <Hixie> | heycam: put it this way: |
| 23:21 | <Hixie> | heycam: what happens if an external SVG <script> is inserted, does the appendChild() call return before or after the script runs? |
| 23:22 | <heycam> | by the current text, i think it is after |
| 23:22 | <Hixie> | oh. that's different than html. |
| 23:22 | <heycam> | ok |
| 23:22 | <Hixie> | so if i appendChild() two <Script> blocks back to back |
| 23:22 | <Hixie> | the second will be inserted before the first executes? |
| 23:22 | <Hixie> | when will it execute? |
| 23:22 | <Hixie> | i don't understand the model anymore. :-/ |
| 23:24 | heycam | brb |
| 23:41 | <heycam> | i think my intention was for the first to be inserted, then executed, then the second is inserted, then executed |
| 23:42 | <heycam> | if you want to mail www-svg with suggestions on making it saner / more compatible with XHTML, that'd be appreciated |
| 23:43 | <Hixie> | i don't really know what to suggest, short of just referencing html5's processing model and defining everything either in terms of tasks and event loops or the scripting lists |
| 23:43 | <heycam> | :) |
| 23:43 | <Hixie> | but i don't see much point in saying that in e-mail |
| 23:44 | <heycam> | maybe i need to take a closer read of the html5 model |
| 23:44 | <Hixie> | ("hi please depend on my spec that i've said isn't going to be ready for a decade k thx bye" isn't likely to go down well) |
| 23:44 | <heycam> | ha |
| 23:44 | <heycam> | anyway, for the svg script in text/html case, i think you can just do whatever is sensible |
| 23:45 | <Hixie> | (to be honest though i think long term we probably will have to use a common event loops model) |
| 23:45 | <heycam> | sounds sensible |
| 23:46 | <heycam> | that'd be one of those things that would go into a split out "Web platform" spec (with things like Window, etc.) |
| 23:46 | <annevk3> | If I define XMLHttpRequest in terms of event loops SVG would need to be defined in it too for it to work "right"... In theory anyway. |
| 23:46 | <Hixie> | heycam: yeah... let me know when you find someone to do that! :-) |
| 23:46 | <heycam> | :) |
| 23:47 | <Hixie> | i know it wouldn't be a popular suggestion but i'm somewhat of the opinion that at this point html and the core dom stuff are so tightly bound together that we should just keep them in one spec and have everything depend on html |
| 23:47 | <Hixie> | but i know that would offend the purists |
| 23:47 | <heycam> | indeed i think it wouldn't be a popular suggestion :) |
| 23:48 | <Hixie> | so right now the web sockets, web storage, web workers, html5, and event source specs are all generated from one source document |
| 23:49 | <heycam> | those other things seem much more easily separable than "web platform" stuff though |
| 23:49 | <Hixie> | yes, absolutely |
| 23:49 | <heycam> | at least from a single-source-document-generating-them PoV |
| 23:49 | <Hixie> | if it wasn't for hte obvious process issues with it, and the difficulty of coordinating work, it would be interesting to consider putting svg, dom core and dom events, http, and pretty much everything else into that same document |
| 23:50 | <heycam> | it might make certain things easier (cross references e.g.) |
| 23:50 | <Hixie> | i'm considering hosting a spec on the whatwg site that is web sockets, web storage, web workers, html5, and event source in one doc |
| 23:50 | <Hixie> | heycam: yeah, exactly |
| 23:50 | <Hixie> | anyway realistically this has zero chance of happening |
| 23:50 | <annevk3> | it's also an awful lot of work |
| 23:51 | <Hixie> | yeah |
| 23:51 | <Hixie> | thing is |
| 23:51 | <Hixie> | we already have to do that work |
| 23:51 | <Hixie> | zcorpan is rewriting dom core |
| 23:51 | <annevk3> | i.e. I can't even begin to imagine rewriting CSS the HTML5 way though I think it should be done :) |
| 23:51 | <Hixie> | dom events is probably going to need a rewrite at some point |
| 23:51 | <Hixie> | css needs a rewrite now that 2.1 has nailed down the behavior, so that it actually is defined in a sane way |
| 23:52 | <heycam> | dom 3 events is being worked on at the moment. maybe you can comment on it? |
| 23:52 | <Hixie> | range and traversal desperately need rewrites |
| 23:52 | <Hixie> | svg is pretty vague, as noted by the questions we just had about <script> behavior |
| 23:52 | <Hixie> | etc |
| 23:52 | <annevk3> | and everyone is inventing new features on top of the undefined stuff |
| 23:52 | <annevk3> | yay |
| 23:54 | <Hixie> | heycam: my comments on dom3 events would be along the same lines as my comments on svg |
| 23:54 | <Hixie> | heycam: and thus likely just as unpopular |
| 23:54 | <annevk3> | and in ten years we'll prolly discuss mistakes similar to cross-origin <script>, global object mess, etc. |
| 23:54 | <heycam> | "whine whine this isn't defined well enough blah blah" :) |
| 23:54 | <annevk3> | "and please drop the namespace crap" |
| 23:55 | <Hixie> | heycam: (i'd recommend splitting out the events into a separate doc that actually defines when they fire, i'd recommend rewriting all the dom api definitions to actually be phrased as requirements not descriptions, and i'd suggest making everything be defined in terms of the event loop mechanism) |
| 23:56 | <heycam> | shepazu, ↑ |
| 23:56 | <Hixie> | heh |
| 23:56 | <Hixie> | i'm sure i've discussed this with him before :-) |
| 23:56 | <heycam> | ok |
| 23:56 | <Hixie> | i had similar comments on the progress spec with chaals |
| 23:57 | <Hixie> | e.g. the dom apis are vague, the spec has far too many redundant or untestable requirements, the spec shouldn't have conforming requirements defined for author scripts, and there are no or few hooks defined for specs using the technology |
| 23:57 | <Hixie> | chaals disagrees :-) |
| 23:57 | <Hixie> | and who's to say he's not right and i'm not wrong |
| 23:58 | <annevk3> | I'd say he's wrong, but I'm biased |
| 23:59 | <heycam> | biased against him because he's your boss? :) |
| 23:59 | <Hixie> | i'd say if you had a bias you'd be biased in his favour but ok :-) |