| 04:56 | <zewt> | bleh |
| 04:56 | <zewt> | is it bad that IE has gone from "damn you for not following the spec, IE" to "damn you for following the spec, IE" |
| 04:57 | <zewt> | stop making me feel bad for IE developers |
| 04:57 | <tw2113> | just odd cause we're so used to damning them from not |
| 07:21 | <zewt> | ... anyone happen to know if the return value of IE9's dispatchEvent is broken (always returns true)? wondering if I'm just going crazy, heh |
| 07:22 | <zewt> | or maybe this is an old beta |
| 07:39 | <annevk> | oh look, WHATWG Weekly day |
| 07:43 | <zewt> | annevk: trying to figure out actual browser behavior re: resetting stop propagation/canceled flag; much headaches ensue |
| 07:44 | <zewt> | can't seem to find a way to test whether the default handler was actually run, that works in all browsers |
| 07:45 | <zewt> | the return value of dispatchEvent seems to always be true in IE9; and the return value of dispatchEvent and the value of getPreventedDefault() in FF don't always match |
| 07:46 | <annevk> | yeah |
| 07:46 | <annevk> | I had the same results |
| 07:46 | <zewt> | oh... checking for onhashchange after clicking a hash link (which I thought wasn't working in FF, but that's because FF isn't firing the default at all for synthesized clicks) |
| 07:46 | <annevk> | well, I didn't test IE |
| 07:46 | <zewt> | (that's what I was doing, then I got confused at FF's behavior) |
| 07:46 | <annevk> | but I was confused too so I thought we could go with something saner :) |
| 07:46 | <zewt> | well, it's a problem that Core and Events are mismatched on this |
| 07:47 | <annevk> | I do think now that maybe propagation flags should be cleared after dispatching and canceled before |
| 07:47 | <zewt> | right now, in all browsers (I think), you can event.stopPropagation and event.preventDefault an event before dispatching, to cause it to only fire the default or to only dispatch event handlers |
| 07:48 | <annevk> | if you call stop propagation it's never dispatched |
| 07:48 | <zewt> | but the default will still happen |
| 07:49 | <zewt> | (if it's allowed for the non-trusted event, of course) |
| 07:49 | <annevk> | I guess that is true... |
| 07:49 | <annevk> | because dispatchEvent will still return and such |
| 07:49 | <annevk> | but it's also really weird |
| 07:49 | <annevk> | so maybe clearing before is saner |
| 07:49 | <zewt> | but is it worth being mismatched with all current browsers? |
| 07:50 | <annevk> | maybe |
| 07:51 | <zewt> | by clearing after (as Events does), it matches current browsers, allows the (admittedly obscure) case of cancelling/preventDefaulting before dispatch, and brings the two specs into agreement... |
| 07:52 | <zewt> | FYI, in IE9 defaultPrevented *is* always false after dispatch completes (which is the result of clearing after)--but that may or may not be intentional (as I said, dispatchEvent's return value seems totally broken in that browser) |
| 07:52 | <annevk> | ah yeah, that's the other thing I disliked about it |
| 07:54 | <annevk> | zewt, so then we'd have to store the value of the canceled flag separately at some point so it can be cleared and then the method can be returned |
| 07:54 | <zewt> | i think that'd only be for one step during dispatch |
| 07:55 | <zewt> | eg. 9. var x = canceled flag; canceled flag = false; return x; |
| 07:55 | <annevk> | just before returning you need to store it, then unset the flag, then return the value |
| 07:55 | <annevk> | right |
| 07:55 | <zewt> | which isn't so bad since it's local to that step--hopefully wouldn't need to have a separately-defined flag bloating the flag list |
| 07:56 | <annevk> | it's a bit unfortunate that it makes defaultPrevented useless after the event is dispatched |
| 07:56 | <annevk> | there's not always a return value of dispatchEvent |
| 07:56 | <zewt> | there should be, right? |
| 07:56 | <zewt> | ignoring IE9's bug |
| 07:56 | <annevk> | not if the event was dispatched by the UA |
| 07:57 | <zewt> | hmm |
| 07:57 | <annevk> | and you store it and analyze its properties later |
| 07:57 | <zewt> | personally, I'd prefer to just never reset the flags ever |
| 07:57 | <zewt> | and don't re-dispatch events; make new ones |
| 07:57 | <zewt> | it seemed like that's what browsers (except IE) actually do--but I got sidetracked by other weirdness and need to re-test |
| 07:58 | <annevk> | that would work too |
| 07:58 | <annevk> | although maybe initEvent() should be able to revive an event |
| 07:58 | <annevk> | (it doesn't currently reset the flags, I tested) |
| 07:59 | <zewt> | i need to re-check FF in particular re: resetting flags |
| 07:59 | <zewt> | i was testing with preventDefault(), but FF apparently doesn't fire default actions on synthesized clicks at all, which may have been confusing me |
| 07:59 | <annevk> | kk |
| 07:59 | <zewt> | so i need to check with stopPropagation |
| 07:59 | <annevk> | we should probably right down the various options and ask people what they think |
| 07:59 | <annevk> | write* |
| 08:00 | <zewt> | also I hate onhashchange to death for being async |
| 08:00 | <annevk> | bah, twisted my thumb over two weeks ago with skiing and it still bloody hurts |
| 08:00 | <zewt> | (makes it a pain to misappropriate it for event testing, heh) |
| 08:01 | <annevk> | heh |
| 08:01 | <zewt> | personally I try to avoid deliberately falling down mountains |
| 08:02 | <zewt> | afk, food hunt |
| 08:02 | <annevk> | going down recklessly is a lot of fun; though I have to be careful because otherwise Lachy will reprimand me for being reckless :) |
| 08:21 | <annevk> | so should I mention developers.whatwg.org or should I leave that to a separate post? |
| 08:21 | <annevk> | I guess i'll leave it to a separate post |
| 08:27 | <zcorpan> | annevk: so who should i bug about getting rights to edit html5-differences? |
| 08:29 | <annevk> | mike probably |
| 08:29 | <annevk> | or maybe the sysreq⊙wo |
| 08:29 | <annevk> | they need your public key or some such and it should be all good |
| 08:32 | <hsivonen> | we don't want innerHTML-created style sheets to block scripts, right? |
| 08:37 | <zewt> | annevk: this is tricky enough that I wouldn't feel comfortable drawing any conclusions from it without review, but http://zewt.org/~glenn/test-event-flags |
| 08:38 | <zewt> | a little hesitant to even spend much time squinting at the results in different browsers, since any bugs in those tests could lead me squinting off on a red herring |
| 08:45 | <annevk> | zewt, looks cool |
| 08:54 | <annevk> | I was gonna something to that... |
| 08:55 | <annevk> | namely that I will hopefully look at it later today |
| 08:55 | <annevk> | trying to focus on the blog entry first |
| 08:55 | <annevk> | and then probably flush out from-origin so the draft is somewhat more complete |
| 08:55 | <annevk> | I had wanted to do most of that yesterday, but I was dead tired instead :) |
| 08:56 | <zewt> | tired of looking at events tonight, so take your time :) |
| 09:01 | hsivonen | just helped a person whose JS program failed due to Namespaces |
| 09:06 | <micheil> | hsivonen: namespaces? |
| 09:06 | <hsivonen> | micheil: the beloved Namespaces in XML |
| 09:07 | <micheil> | uhh.. okay, glad I don't need to deal with them |
| 09:10 | <jgraham> | hsivonen: What was the bug? |
| 09:11 | <hsivonen> | jgraham: svgscript.setAttribute("xlink:href", "foo.js"); |
| 09:12 | <annevk> | that would work if the element in question had a namespaced attribute named xlink:href to begin with |
| 09:12 | <hsivonen> | annevk: really? that seems super-bad design in the DOM. |
| 09:13 | <jgraham> | hsivonen: why the note of surprise? |
| 09:13 | <jgraham> | The DOM has plenty of bad design :) |
| 09:13 | <hsivonen> | jgraham: I know the DOM has plenty of bad design, but this is worse than usual |
| 09:16 | <hsivonen> | in other news, it seems that I have made a rather bad bug in Gecko's script loader |
| 09:16 | <hsivonen> | I'm shocked that I haven't noticed it before |
| 09:17 | <hsivonen> | http://hsivonen.iki.fi/test/moz/premature-script-execution/test-external.html |
| 09:20 | <zcorpan> | annevk: "If the context object does not have an Attr object whose local name is qualifiedName" ... |
| 09:21 | <jgraham> | hsivonen: The bug being that it doesn't wait for the alert? |
| 09:21 | <annevk> | zcorpan, hmm bug |
| 09:21 | <annevk> | at least, I think it is |
| 09:21 | <zewt> | is that the external script bug we were talking about the other day? |
| 09:21 | <hsivonen> | jgraham: the bug being that the inserted script runs before the inserted script finishes |
| 09:22 | <jgraham> | One day I plan to clean up Hallvord's script scheduling tests and submit them to the testsuite |
| 09:22 | <annevk> | i'd like to summarize public-html, but it's much more daunting |
| 09:22 | <annevk> | :/ |
| 09:22 | <zcorpan> | annevk: seems gecko and webkit do as you say, but opera doesn't |
| 09:23 | <jgraham> | It's quite a bit of work though as they are based on guessing desired behaviour rather than a spec |
| 09:23 | <jgraham> | and so are wrong in some cases |
| 09:23 | <zcorpan> | anyone have ie9 at hand? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/850 |
| 09:23 | <zewt> | hsivonen: i noticed that a while back, but I assumed it was known, and bugzilla is too hard to search ... sorry, heh |
| 09:23 | <hsivonen> | whoa, whoa! the script run in the right order if I use console.log. |
| 09:23 | <hsivonen> | not my bug! |
| 09:24 | <hsivonen> | bug in the new tab-model alert stuff more likely |
| 09:24 | <hsivonen> | whew. |
| 09:24 | <zewt> | yeah, that's what I thought you meant |
| 09:24 | <hsivonen> | I thought I had committed totally bogus code |
| 09:24 | <zewt> | alert() doesn't fully pause the event loop; external scripts will load during it now |
| 09:25 | <hsivonen> | zewt: I was wondering how tab modal alert was even possible with the required event loop semantics |
| 09:25 | <hsivonen> | violating the required semantics explains it |
| 09:26 | <zewt> | zcorpan: "IE has modified this page to help prevent cross-site scripting." and doesn't show anything |
| 09:26 | <zewt> | hsivonen: Opera does it correctly, IIRC |
| 09:26 | <jgraham> | Hmm, making tab modal alert possible seems important |
| 09:26 | <hsivonen> | zewt: yes, it does |
| 09:26 | <zewt> | the event loop is "paused" (no queued tasks run) |
| 09:26 | <hsivonen> | zewt: Opera's architecture is radically different |
| 09:26 | <zewt> | yeah, I'll take modal alerts no matter how many weird bugs it causes |
| 09:27 | <zcorpan> | zewt: can you disable or work around the xss protection? |
| 09:27 | <zewt> | zcorpan: it only has a "What's the risk?" link and an "X", no "no seriously, do it" button |
| 09:28 | <zcorpan> | zewt: you can disable it somewhere in prefs. to work aruond it, open the link in another browser, copy the input, paste it into ie |
| 09:28 | <zewt> | I just ran the code directly |
| 09:28 | <zewt> | x<script>document.body.setAttributeNS('x','xlink:href','1'); |
| 09:28 | <zewt> | document.body.setAttribute('xlink:href','2'); |
| 09:28 | <zewt> | alert(document.body.getAttribute('xlink:href')); |
| 09:28 | <zewt> | alerts 2 (as I'd expect) |
| 09:29 | <zewt> | why would/should that do anything else? seems the obvious behavior |
| 09:29 | <zcorpan> | thanks |
| 09:29 | <zcorpan> | seems like stupid behavior to me :) |
| 09:29 | <zewt> | ... how so? |
| 09:29 | <zcorpan> | would be much clearer if setAttribute() always set a no-namespace attribute |
| 09:29 | <hsivonen> | zcorpan: BODY xlink:href="2" |
| 09:30 | <zewt> | i'm not even sure what that is, heh |
| 09:30 | <zewt> | why should x.setAttribute(a, b); x.getAttribute(a); ever return anything other than b? |
| 09:30 | <zcorpan> | what you get if you didn't have the first line in the script |
| 09:30 | <zewt> | ah that namespace |
| 09:31 | <hsivonen> | apparently if you have disabled the XSS filter for software.hixie.ch before installing IE9 RC, you need to disable it again after installing RC for it to take effect in RC |
| 09:31 | <zewt> | i'm not familiar with those--to me "namespace" is just the "xlink:" part of the attribute name |
| 09:31 | <hsivonen> | zewt: that's how bugs emerge |
| 09:31 | <zewt> | not even sure what the point of those NS functions is; I've never seen them used so I've never felt the need to see what they're for |
| 09:32 | <hsivonen> | zewt: the short version is that if you are doing SVG stuff without *NS, you are writing broken code |
| 09:32 | <jgraham> | (or MathML) |
| 09:32 | <zewt> | sounds like ugly legacy noise |
| 09:32 | <jgraham> | Hah |
| 09:32 | <hsivonen> | zewt: YES |
| 09:33 | <zewt> | which seems to comprise a significant chunk of DOM, heh |
| 09:33 | <jgraham> | It is the glorious future, don't ya know |
| 09:33 | <zewt> | but I'm still not sure why x.setAttribute('a:b', 'c'); x.getAttribute('a:b') shouldn't return 'c' |
| 09:33 | <zcorpan> | i guess we should suck it up and change opera, since we're the odd one out |
| 09:33 | <zcorpan> | but it still sucks |
| 09:34 | <zewt> | i've used attributes like that before, though I havn't had any reason to set them; mostly to let me put custom attributes in markup |
| 09:34 | <zcorpan> | zewt: i wouldn't mind if getAttribute() also only worked for no-namespace attributes, but there may be web compat problems with changing that |
| 09:35 | <zewt> | such as a whole lot of my code :) |
| 09:35 | <jgraham> | It turns out that colons are the worst possible character for doing custom whatever |
| 09:35 | <jgraham> | because they pull in all this architecture |
| 09:35 | <zewt> | well, not a lot, but I've been using it more lately, and I've never even considered using *NS for it |
| 09:35 | <jgraham> | that you don't want |
| 09:35 | <jgraham> | hence -data-foo |
| 09:35 | <zcorpan> | it'd still work if you used non-NS methods for both and never use NS methods |
| 09:36 | <zcorpan> | and don't use <svg xlink:href> |
| 09:36 | <hsivonen> | jgraham: it's happy fun that Facebook uses colons in HTML DOMs all over |
| 09:36 | <zewt> | well, the question for my code isn't setAttribute, it's markup |
| 09:36 | <hsivonen> | jgraham: with *NS methods! |
| 09:37 | <jgraham> | hsivonen: I guess facebook has a culture of thinking they are smart enough to play with fire |
| 09:37 | <zewt> | well, if it works in every browser people test in, then people have no reason to think they're doing so |
| 09:38 | <zewt> | and if it works in every (or many) browsers, then the good old de facto standard process kicks in :| |
| 09:38 | <hsivonen> | zewt: that logic doesn't work for Facebook, since they have at least four engine-specific code paths |
| 09:38 | <zewt> | haha |
| 09:38 | <hsivonen> | zewt: so there's no guarantee that whatever happens on one of them would work cross-browser |
| 09:39 | <zewt> | i don't even use facebook, but from the times I've loaded the page, they're not doing anything fancy at all that would warrant that kind of complexity |
| 09:43 | <jgraham> | zewt: The implementation of facebook is more fancy than the content would suggest. Some of it seems a lit like unnecessary complexity, however |
| 09:44 | <zewt> | geh |
| 09:44 | <jgraham> | e.g. a great deal of content is loaded from scripts in order to reduce loading times (or something) |
| 09:44 | <zewt> | on that setAttribute case, innerHTML shows <body href="2"> |
| 09:44 | <zewt> | if I comment out the setAttributeNS, i get <body xlink:href="2> |
| 09:45 | <zewt> | in FF3 |
| 09:45 | <zewt> | "> |
| 09:45 | <zewt> | do I even want to know? heh |
| 09:56 | <annevk> | http://blog.whatwg.org/weekly-same-origin |
| 10:07 | <annevk> | when is ben usually online? |
| 10:07 | <annevk> | I suppose I can write some announcement post tomorrow if he's too busy for it |
| 10:44 | <annevk> | in ABNF |
| 10:44 | <annevk> | well, HTTP BNF |
| 10:44 | <annevk> | there's #header-value |
| 10:44 | <annevk> | what is #header-value-or-some-other-value |
| 10:44 | <annevk> | #[a|b |
| 10:44 | <annevk> | ] |
| 10:44 | <annevk> | or just #a|b ? |
| 10:50 | <kennyluck> | annevk, in http://blog.whatwg.org/weekly-same-origin , the first link in the second item (dom) links to the wrong page (bugzilla) it seems. |
| 10:51 | <annevk> | not here... |
| 10:52 | <annevk> | it seems there is some markup error though |
| 10:52 | annevk | goes to fix |
| 10:53 | <annevk> | fixed |
| 10:54 | <kennyluck> | thanks! |
| 11:30 | <annevk> | http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html#from-origin-response-header now has a processing model |
| 11:40 | <hsivonen> | annevk: the spec is completely obscure unless one remembers what prefix # means in this flavor of BNF |
| 11:41 | <hsivonen> | annevk: can the header take a list of multiple origins? |
| 11:41 | <zewt> | where's the definition of this BNF syntax? should it be referenced explicitly? |
| 11:42 | <hsivonen> | annevk: it's very sad that CORS doesn't allow multiple origins to be specified |
| 11:42 | <hsivonen> | zewt: that would help |
| 11:43 | <zewt> | i assumed the #[] meant a comma-separated list or something like that |
| 11:43 | hsivonen | doesn't know what #[] means |
| 11:44 | <hsivonen> | also, the words origin and same aren't quoted but if they are non-terminals, I don't see expansions, either |
| 11:45 | <hsivonen> | "if none of" suggests that a list is allowed |
| 11:47 | <annevk> | hsivonen, first version of CORS is not meant for static resources |
| 11:47 | <annevk> | hsivonen, that Gecko used it for fonts without prior discussion with WebApps, well, ... |
| 11:47 | <annevk> | # is some HTTPism |
| 11:48 | <annevk> | makes sense to me to define headers the same way HTTP does |
| 11:48 | <annevk> | you're right about same, I should make that an expansion and link origin to some definition in the origin concept draft |
| 11:50 | <zewt> | "same" = empty list, don't terminate in step 1 and depend on step 5 to allow same-origin only? |
| 11:51 | <annevk> | terminate means "these steps don't apply" |
| 11:51 | <annevk> | that should prolly be clarified somewhat |
| 11:51 | <zewt> | i know that |
| 11:51 | <annevk> | and "same" is a convenience keyword |
| 11:51 | <annevk> | if you can specify an empty header that should probably be allowed too |
| 11:51 | <zewt> | i mean "From-Origin: same" means #1 won't terminate and step 7 will always terminate? |
| 11:52 | <zewt> | er, abort |
| 11:52 | <annevk> | right |
| 11:52 | <annevk> | however, before step 7 it will be terminated if it's same origin |
| 11:52 | <annevk> | so that's all good |
| 11:52 | <zewt> | i figured that was the idea |
| 11:52 | <zewt> | having an empty header would be cleaner but yeah I don't remember if that's allowed, and it might be a bad idea anyway since nothing ever does that |
| 11:53 | <zewt> | probably best for empty header to be equivalent to no header |
| 11:53 | <annevk> | actually, WebDAV does that I believe |
| 11:54 | <annevk> | XHR also has a distinction between no header and empty string value |
| 11:54 | <zewt> | for example, there's no way to specify an empty header with curl |
| 11:54 | <zewt> | specifying an empty header removes it |
| 11:55 | <annevk> | anyway, currently it's not allowed |
| 11:55 | <annevk> | # means one or more |
| 11:55 | <annevk> | iirc |
| 11:55 | <hsivonen> | annevk: so is From-Origin: same, same conforming? |
| 11:55 | <zewt> | should it be #[origin | "same"]? |
| 11:56 | <hsivonen> | annevk: it would be really nice to link the word "BNF" to whatever IETF flavor of BNF this is |
| 11:56 | <zewt> | bnf-fu very rusty |
| 11:56 | <hsivonen> | annevk: also, linking the non-terminals to their expansions would be really nice |
| 11:56 | <annevk> | hsivonen, yes and yes it would; guess I'll do it now |
| 11:56 | <annevk> | zewt, no, then same would not be case-sensitive |
| 12:00 | <karlcow> | http://www.w3.org/TR/2000/REC-xml-20001006#sec-notation a link for EBNF |
| 12:00 | <zewt> | this relates not just to HTML but HTTP; should it reference HTTP for what "response header" means? not sure how explicit that's typically made |
| 12:01 | <annevk> | maybe case-insensitive is okay |
| 12:01 | <zewt> | that definition says "strings" are case-sensitive |
| 12:01 | <annevk> | lets not confuse HTTP ABNF with EBNF |
| 12:02 | <karlcow> | there is also ABNF http://tools.ietf.org/html/rfc4234 |
| 12:02 | <karlcow> | http://tools.ietf.org/html/rfc5234 |
| 12:03 | <karlcow> | geez with erratas |
| 12:04 | <hsivonen> | karlcow: XML BNF is readable. Unlike the IETF stuff. |
| 12:04 | <zewt> | 15.7.1 Denial of Service Attacks on Proxies |
| 12:04 | <zewt> | They exist. They are hard to defend against. Research continues. |
| 12:04 | <zewt> | Beware. |
| 12:04 | <zewt> | gotta love a spec that uses the single word "beware" as a sentence |
| 12:05 | <zewt> | http://tools.ietf.org/html/rfc2616#page-14 |
| 12:06 | <zewt> | ("page-14" as an anchor? really?) |
| 12:06 | <jgraham> | ietf is kinda fucked up |
| 12:06 | <zewt> | writing specs as if the expectation is that everyone's going to print them out ... that's pretty amusing even for 1999 |
| 12:07 | <jgraham> | They regard technologies that postdate the 60s with suspicion and even downright hostility |
| 12:07 | <zcorpan> | "They exist. They are hard to defend against. Research continues. Beware." seems like a good section for other stuff as well, like "Security considerations" |
| 12:09 | <zewt> | can I be happy that we're in an age where we no longer feel the need to explicitly reference the ASCII spec from HTML |
| 12:09 | <annevk> | http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html#from-origin-response-header refresh |
| 12:10 | <jgraham> | I thought we did reference the ASCII spec |
| 12:10 | <karlcow> | zewt: for http I recommend to look in the direction of httpbis |
| 12:11 | <jgraham> | They was a whole cycle of the Issue process around it, was there not? |
| 12:11 | <karlcow> | http://tools.ietf.org/wg/httpbis/ |
| 12:13 | <zewt> | annevk: perhaps explicitly say that these steps are to be performed as part of the "main step" of fetching |
| 12:13 | <zewt> | assuming that's where it goes |
| 12:14 | <zewt> | (implying that if F-O aborts the resource, cookies aren't updated, and so on) |
| 12:17 | <zcorpan> | annevk: RFC2119 ref is broken |
| 12:18 | <jre> | annevk, zevt: reusing the HTTP ABNF makes sense here. |
| 12:18 | <annevk> | thanks zewt, done |
| 12:19 | <jre> | the reference should go to http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1 |
| 12:19 | <jre> | (not that URI, but RFC 2616, Section 2.1) |
| 12:19 | <zewt> | httpbis ref is http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#page-7 but if it's the same may as well not use an in-progress reference |
| 12:19 | <jre> | you'll also need to steal the definition of OWS from HTTPbis |
| 12:19 | <zewt> | <zewt> http://tools.ietf.org/html/rfc2616#page-14 <- that's the 2616 ref |
| 12:20 | <jre> | http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-12.html#rfc.section.1.2.2 |
| 12:20 | <annevk> | I guess I'll just say that the ABNF is the same as the Web Origin Concept |
| 12:20 | <annevk> | so I can avoid dealing with HTTP references |
| 12:20 | <jre> | it may make sense to steal the details from the new cookie spec |
| 12:21 | <jre> | actually no: it uses the 5234 syntax |
| 12:21 | <annevk> | it now just references ORIGIN |
| 12:22 | <annevk> | which in turn hopefully references some correct spec, but it's no longer my problem :) |
| 12:22 | <annevk> | actually, this is not quite correct |
| 12:22 | <annevk> | bah |
| 12:24 | <zewt> | annevk: the fetch algorithm has a specifically named "main step"; i think it makes sense to refer to it by name to be precise about where in the algorithm it goes |
| 12:24 | <zewt> | (of course, it won't be when multiple addon-specs are doing that, but heh) |
| 12:24 | <annevk> | origin-list is space separated :/ |
| 12:29 | <annevk> | fixed bnf again |
| 12:29 | <annevk> | zewt, yeah, this all needs to be integrated one day |
| 12:30 | <annevk> | at some point someone might take everything network and write it all down :) |
| 12:31 | <MikeSmith> | annevk: please take a look at http://dev.w3.org/2006/webapi/WebNotifications/static.html and let me know if you see any problems |
| 12:31 | <MikeSmith> | please compare to http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html |
| 12:31 | <MikeSmith> | the main difference is where/how the Notification constructor is defined |
| 12:33 | <annevk> | MikeSmith, that is wrong |
| 12:33 | <MikeSmith> | Berjon's current JS respec does not seem to provide any way to handle the constructor differently than normal methods |
| 12:33 | <MikeSmith> | hmm |
| 12:33 | <MikeSmith> | oK |
| 12:33 | <hendry> | Philip`: hi there, can we chat about how reports are gathered with your test harness? |
| 12:33 | <annevk> | MikeSmith, now it says there's a method Notification on the Notification object |
| 12:33 | <MikeSmith> | annevk; so now I have to hack fricking respec more |
| 12:34 | <MikeSmith> | yeah, I know |
| 12:34 | <annevk> | MikeSmith, respec2 doesn't handle it either? sounds painful |
| 12:34 | <MikeSmith> | I can't imagine this is the first spec using respec that has needed to document a constructtor |
| 12:34 | <annevk> | MikeSmith, I'm fine with publishing as-is though, maybe with a note |
| 12:35 | <annevk> | or maybe berjon knows a cure |
| 12:35 | <MikeSmith> | nah, I can fix it today |
| 12:35 | <MikeSmith> | maybe |
| 12:35 | <annevk> | zewt, added main step |
| 12:35 | <annevk> | zewt, hsivonen, thanks a lot |
| 13:40 | <Philip`> | hendry: Sure |
| 13:40 | <Philip`> | hendry: (Which test harness?) |
| 13:57 | <hendry> | Philip`: w3c one, did you get my email btw? |
| 13:58 | <Philip`> | hendry: I see the email now |
| 13:59 | <Philip`> | I know nothing about the W3C test reporting system |
| 13:59 | <jgraham> | hendry: What is the question? |
| 13:59 | <Philip`> | I've heard that it's mostly manual so I haven't been inclined to have a look at it |
| 14:01 | <hendry> | jgraham: just a general enquiry to how the actual reporting is done. e.g. http://dvcs.w3.org/hg/html/file/tip/tests/submission |
| 14:01 | <hendry> | Philip`: i.e. how automation is best done :) |
| 14:02 | <jgraham> | hendry: Oh, like Philip` I haven't dared look at that too hard |
| 14:03 | <jgraham> | There is a javascript thing in the repo somewhere that opens the tests in an iframe and lets people submit the results and builds that XML or something |
| 14:03 | <hendry> | jgraham: if you find it let me know |
| 14:04 | <hendry> | jgraham, Philip` if there are reporting / automated examples I could see, I would be grateful |
| 14:04 | <Philip`> | http://test.w3.org/html/tests/harness/harness.htm |
| 14:04 | <Philip`> | You click pass/fail buttons 819 times and then click "test results" and then post it to a mailing list, I think |
| 14:04 | <hendry> | Philip`: ah .. |
| 14:05 | <jgraham> | hendry: Oh, Philip` beat me to it |
| 14:05 | <jgraham> | The whole thing is insane |
| 14:05 | <jgraham> | the most useful thing would be if people would stop spamming me with test results :( |
| 14:05 | <Philip`> | http://philip.html5.org/tests/canvas/suite/reportgenentry.html is my automated one but that's for a slightly obsolete version of the tests |
| 14:05 | <Philip`> | and also you can't submit the results anywhere |
| 14:05 | <jgraham> | But there must be something somewhere encouraging it |
| 14:06 | <jgraham> | Also, it is quite trivial to build an automated harness for the javascript tests |
| 14:06 | <jgraham> | Since it has an API specifically for that purpose |
| 14:06 | <zewt> | click a button 819 times? make a game out of it and people will pay to run your tests for you |
| 14:07 | <hendry> | jgraham: where is this API documented? |
| 14:07 | <jgraham> | hendry: http://dvcs.w3.org/hg/html/file/0be07106838c/tests/resources/testharness.js |
| 14:07 | <jgraham> | See where it says "external API" |
| 14:07 | <jgraham> | zewt: Heh |
| 14:08 | <jgraham> | We should totally do that |
| 14:08 | <jgraham> | Make people pay to buy a test autoclicker than can submit 5 results for them |
| 14:08 | <Philip`> | Make an online game like The Typing of the Dead |
| 14:09 | <jgraham> | I was totally thinking farmville |
| 14:09 | <Philip`> | where instead of showing you a word you have to type in to kill zombies, it shows a test case in an iframe and you have to select pass/fail to kill zombies |
| 14:10 | <Philip`> | The end-of-level boss can be a series of test cases submitted by Microsoft where it's really hard to figure out whether it passed or failed |
| 14:10 | <zewt> | heh typing of the dead |
| 14:10 | <zewt> | someone had me playing that years ago, except it was the japanese version on DC |
| 14:10 | <hendry> | jgraham: don't quite understand that "external API" stuff, was expecting to see a func with XMLHttpRequest post |
| 14:11 | <Philip`> | "Test passes if the text 'PASS' appears to the left and the text 'Your browser does not support media elements.' does not appear anywhere on this page." |
| 14:11 | <zewt> | not being able to read any of it made the boss battles ... a challenge |
| 14:11 | <Philip`> | That text will always appear on that page, as part of the instructions |
| 14:12 | <hendry> | jgraham: so one implements result_callback to post results or something? |
| 14:13 | <hendry> | jgraham: i need an example i think |
| 14:26 | <Workshiva> | Philip`: This test intentionally left failing |
| 14:41 | <jgraham> | Philip`: Hah |
| 14:43 | <jgraham> | hendry: If one loads the test in an iframe it will try to send the results to a function in the top-level browsing context called completion_callback |
| 14:43 | <jgraham> | It might have been neater to use postMessage… |
| 14:43 | <jgraham> | In fact it might still be possible to change |
| 14:45 | <annevk> | zcorpan, need any information on generating the spec? |
| 14:46 | <annevk> | I currently use (and change ED to WD somewhere and add -F date=2011-xx-xx when generating a copy for publication): |
| 14:46 | <annevk> | curl -u w3c-user:password -F file=@Overview.src.html -F group=none -F output=html -F method=file http://cgi.w3.org/member-bin/process.cgi -o Overview.html |
| 15:02 | <zcorpan> | annevk: thanks |
| 15:07 | <zcorpan> | where do i change ED to WD? |
| 15:12 | <zcorpan> | the current version seems to be WD |
| 15:18 | <zcorpan> | annevk: ^ |
| 15:21 | <annevk> | I guess you can keep it that way |
| 15:21 | <zcorpan> | ok |
| 15:22 | <annevk> | but if someone wants you to change it back, change WD to ED in the "This Version:" URL in http://dev.w3.org/html5/html4-differences/Overview.src.html |
| 15:22 | <annevk> | everything else should adjust automatically |
| 15:23 | <zcorpan> | ok |
| 15:23 | <annevk> | if something breaks with the generator you probably need to contact Bert Bos or switch to Anolis |
| 15:23 | <annevk> | publication related questions are probably best directed to Mike Smith |
| 15:23 | <zcorpan> | i added myself as editor to see if it'd work |
| 15:24 | <MikeSmith> | yeah, I can help with pub stuff |
| 15:24 | <zcorpan> | cool |
| 15:25 | <zcorpan> | i guess i'm all set then |
| 15:26 | <zcorpan> | annevk: one more, what do you check when you update it? just the svn log? |
| 15:26 | <annevk> | yes |
| 15:26 | <zcorpan> | ok |
| 15:26 | <annevk> | I keep track of SVN numbers in the comments |
| 15:26 | <zewt> | how did this thread about microphone devices suddenly turn towards sh? heh |
| 15:26 | <zewt> | that may be the most nonsensical suggestion I've seen on the list yet |
| 15:27 | <annevk> | if you look at the HTML5 changelogs section it should be pretty simple to figure out |
| 15:27 | <annevk> | that is, if you look at the source |
| 15:27 | <annevk> | feel free to make more ambitious changes though :) |
| 15:27 | <annevk> | such as defining the DOM HTML delta or some such |
| 15:27 | <annevk> | ;) |
| 15:28 | <zcorpan> | heh, don't worry, i won't :) |
| 15:29 | <zcorpan> | ok seeya |
| 15:30 | <annevk> | :) |
| 15:30 | <zcorpan> | btw i won't be in linköping this week |
| 15:30 | <zcorpan> | so i guess i won't seeya |
| 15:30 | <zcorpan> | anyway |
| 15:31 | <annevk> | aaah |
| 15:33 | <annevk> | Ms2ger, when you read this, jgraham has been given access to dom-core to commit some tests |
| 15:37 | <annevk> | zcorpan, you forgot "editor" under "Acknowledgments" :) |
| 16:08 | <Rik`> | "Error: Text run is not in Unicode Normalization Form C." |
| 16:08 | <Rik`> | what the hell does that mean? |
| 16:09 | <jgraham> | Dunno why it's an error |
| 16:09 | <jgraham> | But apart from that it means what it says, mostly |
| 16:09 | <Workshiva> | Because unicode is bad enough with NFC |
| 16:10 | <jgraham> | Rik`: It means that certain sequences of characters and combining characters are in docomposed form rather than single-codepoint form |
| 16:10 | <jgraham> | e.g. if you have an e character followed by an acute combining mark |
| 16:10 | <Workshiva> | If you have e.g. A followed by ring-above-symbol-whatnot instead of Å |
| 16:10 | <jgraham> | rather than an e-acute character |
| 16:11 | <Rik`> | jgraham: oh right, thanks ! |
| 16:11 | <jgraham> | Rik`: Note that NFC doesn't mean that there aren't *any* combining chracters |
| 16:11 | <jgraham> | It just means that there aren't the ones in NFC |
| 16:11 | <jgraham> | (I believe that NFD is fully decomposed, however) |
| 16:12 | <jgraham> | http://unicode.org/reports/tr15/ |
| 16:13 | <jgraham> | Also http://diveintomark.org/archives/2004/07/06/nfc seems quite relevant to your situation |
| 16:58 | <Rik`> | still experiencing funny error messages |
| 16:58 | <Rik`> | Error: Bad value UserVoice.Popin.show(uservoiceOptions); return false; for attribute onclick on element a: invalid return |
| 16:58 | <Rik`> | why is can't it "return false" ? |
| 16:58 | <zewt> | i don't even know what language that is, heh |
| 16:59 | <zewt> | of course I didn't sleep last night and I'm in zombie mode, but |
| 17:32 | <karlcow> | http://my.opera.com/core/blog/2011/02/28/webgl-and-hardware-acceleration-2 |
| 17:32 | <Rik`> | hsivonen: do you have any idea ? |
| 17:38 | <annevk> | fuck iTunes |
| 17:38 | <annevk> | bought Radiohead album in WAV because why not |
| 17:38 | <annevk> | drag into iTunes |
| 17:38 | <annevk> | iTunes does not play ball |
| 17:39 | <annevk> | after modifying song names and album information appropriately myself (because iTunes does not play ball) it does not allow me to change the frigging artwork |
| 17:39 | <annevk> | does this mean I now have to buy the MP3 version to get this to work? |
| 17:44 | <matjas> | try using iTunes to convert it to MP3 |
| 17:51 | <hsivonen> | Rik`: any idea about return false; in onclick? no, no idea |
| 17:51 | <zewt> | WAV is hard stuff |
| 17:55 | <matjas> | TabAtkins: http://asi.qfox.nl/ is pretty cool |
| 17:55 | <zewt> | annevk: the terms "type" and "name" with events are used of ambiguously in places |
| 17:56 | <Rik`> | so validator.nu says there is an error but validator.w3.org says it's ok |
| 17:56 | <zewt> | DOM Core refers to the event interface as the "type" and the event name as the "name", but the parameter to init*Event functions is "type" (refering to the name) |
| 17:57 | <zewt> | and specs seem inconsistent (in eventsource within "dispatch the event", step 3 uses "name" and step 4 uses "type" to--I think--refer to the same thing) |
| 18:03 | <zewt> | might be more consistent for DOM Core to always say "event that uses the Event interface" and never refer to that as "type" or "name" |
| 18:03 | <TabAtkins> | Yus! I missed 6 ASIs and wasted 8 unnecessary. Still pretty good! |
| 18:03 | <zewt> | (I think "type" is sort of entrenched, due to the prototypes of all of the initEvent methods) |
| 18:04 | <TabAtkins> | Most of those wasted ones were me putting them after function declarations, which the rules didn't call out explicitly. |
| 18:04 | <TabAtkins> | (It's subsumed in the "hidden rules" it mentions, I guess.) |
| 18:05 | <karlcow> | hmmmm checking http://www.w3.org/TR/DOM-Level-3-Events/ too |
| 18:07 | <zewt> | i think DOM Events always uses "type" to refer to the event name, not "name" |
| 18:08 | <zewt> | so yeah I'd also change the term "name" to "type", I think |
| 19:01 | <zewt> | aren't custom events a bit of a namespace nightmare? as soon as people start using events with arbitrary names, adding new events to anything ever will cause backwards-compat problems |
| 19:20 | <TabAtkins> | Argh, how can someone in the leadership of the accessibility group write such inaccessible emails? |
| 19:22 | <TabAtkins> | I can't figure out who is saying what in the quoted part of this top-posted email, and I'm a fully-sighted user. |
| 19:53 | <hober> | TabAtkins: srsly |
| 19:55 | <Hixie> | kennyluck: please don't cross-post messages to the whatwg list, it causes thread fragmentation when people not on the list reply to the thread |
| 20:29 | <zcorpan> | hsivonen: "There is an option to ignore the “legacy doctype” and “xml:lang” errors that Validator.nu reports for documents using an XHTML doctype" http://www.456bereastreet.com/archive/201102/html5_validator_extension_updates/ |
| 20:59 | <kennyluck> | Hixie: hmm... OK, but I was replying a mail that was cross-posted. What am I supposed to do? |
| 21:04 | <Hixie> | kennyluck: figure out the best list to reply to, i guess :-) |
| 21:04 | <Hixie> | kennyluck: are you on whatwg? |
| 21:04 | <kennyluck> | Hixie: Yeah. |
| 21:04 | <Hixie> | k |
| 21:04 | <zewt> | only replying to one list is causing thread fragmentation, not replying to all :P |
| 21:05 | <Hixie> | yeah but it just encourages others to do the same :-) |
| 21:06 | <zewt> | crossposting between relevant lists is pretty ordinary--works fine as long as lists aren't subscriber-post-only (unfortunately, some lists are) |
| 21:06 | <karlushi> | You can minimize the damage of cross-posting by stopping the thread and replying to one list and then send an email to the other list pointing to the discussion. Reply-To: might help too. Though nothing perfect, beauty of humans. |
| 21:06 | <zewt> | (like that annoying PRNG thread that people expected everyone to subscribe to es-discuss for) |
| 21:06 | <Hixie> | zewt: yeah. whatwg is, for spam control reasons |
| 21:07 | <zewt> | speaking of spam control, maybe the spec feedback form should throw away comments that begin with "Please enter your feedback" :) |
| 21:09 | <kennyluck> | Hmm... the email address I use everyday isn't the email address I use to subscribe to the whatwg list. I guess that's the reason why my letter doesn't show up on the whatwg list. |
| 21:10 | <Hixie> | zewt: is it common? |
| 21:11 | <zewt> | probably not common enough to actually spend time on it, though if I was the one who had to keep closing them I might get annoyed enough to, heh |
| 21:11 | <Hixie> | if it's happened more than twice i'm happy to add code for it, it'll take a second or two |
| 21:11 | <Hixie> | paste the urls to the cases where it happens and i'll deal with it |
| 21:12 | <zewt> | eg. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12206 |
| 21:13 | <zewt> | (i'm surprised those don't happen more often than they do) |
| 21:13 | <Hixie> | wow i wonder how _that_ happens |
| 21:14 | <AryehGregor> | Why is it so hard to traverse the DOM in tree order? |
| 21:14 | <Hixie> | six times so far |
| 21:14 | <Hixie> | crazy |
| 21:14 | <AryehGregor> | From JavaScript, I mean. |
| 21:14 | Hixie | goes to block that case |
| 21:14 | <AryehGregor> | Would Node.nextNode be too much to ask? |
| 21:14 | <zewt> | is it hard? |
| 21:14 | <Hixie> | AryehGregor: Node.nextSibling? |
| 21:14 | <AryehGregor> | Hixie, what if it's the last child? |
| 21:14 | <Hixie> | AryehGregor: oh you mean including the next node |
| 21:14 | <AryehGregor> | Or what if it has a child? |
| 21:14 | <gsnedders> | AryehGregor: walk parentNode? |
| 21:14 | <Hixie> | AryehGregor: use a node iterator |
| 21:15 | <AryehGregor> | Hmm, let me look into that. |
| 21:15 | <gsnedders> | AryehGregor: NodeIterator? |
| 21:15 | <AryehGregor> | Is that available cross-browser these days? |
| 21:16 | <gsnedders> | AryehGregor: Non-IE, at least. It's in Acid3. I think IE9 supports it. |
| 21:16 | <AryehGregor> | This seems way more complicated than I want. |
| 21:16 | AryehGregor | just does it manually |
| 21:16 | <gsnedders> | AryehGregor: If you want to do it for all documents, have fun with IE's non-tree documents. |
| 21:17 | <zewt> | write a nextNode(node) function, add it to the bag of helpers :) |
| 21:17 | <AryehGregor> | Yeah, that's what I did. |
| 21:17 | <AryehGregor> | gsnedders, well, if IE does that, it will just fail my tests, so too bad on it. |
| 21:17 | <Hixie> | make sure it fails and doesn't lock u |
| 21:17 | <Hixie> | p |
| 21:19 | <jgraham> | Locking up browsers is fun! |
| 21:19 | <jgraham> | But probably shouldn't be encouraged... |
| 21:20 | <zewt> | Hixie: maybe he's asking you to enter your feedback (to yourself) |
| 21:20 | <Hixie> | heh |
| 21:20 | <zewt> | that would be rather literal feedback |
| 21:21 | <gsnedders> | AryehGregor: Indeed, what Hixie said is the risk here. (Just following the circle.) |
| 21:22 | <AryehGregor> | Well, tests that time out fail automatically, right? |
| 21:22 | <AryehGregor> | Anyway, does IE9 in standards mode allow non-tree documents? |
| 21:22 | <AryehGregor> | Not like we're testing compatibility modes. |
| 21:22 | AryehGregor | will worry about it when he gets to it |
| 21:22 | <zewt> | better to detect an infinite loop and fail quickly instead of waiting for a timeout and making the test set take forever |
| 21:22 | <gsnedders> | AryehGregor: I think not. |
| 21:23 | <Hixie> | we'll have to test compatibility modes in due course |
| 21:23 | <AryehGregor> | I doubt it. |
| 21:23 | <jgraham> | Boy is that going to be a fun discussion |
| 21:23 | <AryehGregor> | We'll probably never test compatibility modes. |
| 21:23 | <AryehGregor> | IE's, anyway. |
| 21:23 | <jgraham> | We should test doctype/no doctype at least |
| 21:23 | <AryehGregor> | Nobody has any real reason to want to emulate them. |
| 21:23 | <AryehGregor> | Well, maybe someday. |
| 21:24 | <Hixie> | the spec doesn't have compatibility modes, it just has one set of rules that include some differences based on the doctype |
| 21:24 | <Hixie> | so... |
| 21:24 | <zewt> | it's annoying that apparently only IE9 changes modes significantly with no doctype |
| 21:24 | <gsnedders> | Yeah, we should test standards/quirks. |
| 21:24 | <gsnedders> | But that's going to be painful enough. |
| 21:25 | <jgraham> | I'm not sure that intentionally putting IE in a compat mode to show that it doesn't follow standards in that mode really helps anyone |
| 21:25 | <Hixie> | i don't really care about IE |
| 21:25 | <Hixie> | it's not an IE issue |
| 21:25 | <jgraham> | But showing that it fails to follow ordinary quirks mode is fine |
| 21:25 | <zewt> | (every time I make a quick test HTML and I'm lazy and don't put a doctype, everything works fine in every browser ... except IE9, which falls to quirksmode) |
| 21:25 | <Hixie> | since they refuse to follow the spec for this anyway |
| 21:25 | <Hixie> | we still need to make sure the spec is useful for the browsers who _do_ want to follow it |
| 21:26 | <gsnedders> | Hixie: Then what is gained by testing it? |
| 21:26 | <Hixie> | IE isn't the only browser? |
| 21:26 | <jgraham> | Right, but it is reasonable to assume that <meta content=what-ever-the-magic-is> won't dpo anything magic in non-IE browsers |
| 21:26 | <Hixie> | zewt: i tried to add somethin to prevent the case you mentioned earlier |
| 21:26 | <gsnedders> | Hixie: But how likely are they to end up on the wrong code-path because of x-ua-compatible? |
| 21:27 | <gsnedders> | Hixie: cost/benefit doesn't seem to make it seem worthwhile, because the meta does nothing. |
| 21:27 | <Hixie> | jgraham: oh i wasn't suggesting having tests that check the IE thing |
| 21:27 | <zewt> | i don't expect other browsers to deliberately break when there's no doctype, but it'd be nice if there was *some* indication, so the problem doesn't lurk |
| 21:27 | <Hixie> | didn't mean to imply anything about X-UA-Compatible |
| 21:27 | <jgraham> | Hixie: It sounded like you were :) |
| 21:27 | <gsnedders> | Indeed. :) |
| 21:27 | <Hixie> | what did i say that sounded like that? |
| 21:27 | Hixie | is confoosed |
| 21:27 | <jgraham> | 15:26 < Hixie> we'll have to test compatibility modes in due course |
| 21:27 | <gsnedders> | We should test everything in at least quirks/non-quirks. Dunno if we sohuld test everything in limit-quirked. |
| 21:28 | <gsnedders> | Hixie: "compatibility modes" is something I only ever hear wrt IE's modes |
| 21:28 | <jgraham> | "compatibility modes" in context sounds like the IEism |
| 21:28 | <Hixie> | jgraham: i meant the quirks mode thing, sorry |
| 21:28 | <jgraham> | not the spec thing |
| 21:28 | <jgraham> | Hixie: np |
| 21:28 | jgraham | is less ambitious than gsnedders |
| 21:29 | <Hixie> | back in a bit, unch |
| 21:29 | <gsnedders> | jgraham: I think we want to check for everything that behaviour isn't changed by being in quirks |
| 21:29 | jgraham | would settle for tests that just cover the areas where they should be the same |
| 21:29 | <gsnedders> | To avoid browsers changing too much in quirks |
| 21:29 | <jgraham> | er |
| 21:29 | <jgraham> | s/same/different/ |
| 21:29 | <jgraham> | gsnedders: We can do that ofc |
| 21:29 | <jgraham> | But it seems like a lot of effort for not much gain |
| 21:30 | <jgraham> | (like: it won't just be a case of adding or removing <!doctype html> from the top of each html file) |
| 21:30 | <gsnedders> | I know. |
| 21:31 | <gsnedders> | It should be for a lot, though. |
| 21:31 | <gsnedders> | Very little changes per spec for quirks mode. |
| 21:31 | <gsnedders> | CSS would be a huge amount of work, but HTML5 wouldn't be. |
| 21:31 | <jgraham> | Lots of tests will do thjings like load documents in iframes |
| 21:31 | <jgraham> | Do you need to change the document in the iframe |
| 21:31 | <jgraham> | *So |
| 21:32 | <jgraham> | Which could be a data: uri |
| 21:32 | <jgraham> | So there is no automated approach that will be reliable |
| 21:32 | <jgraham> | So it will mean going through all submissions by hand |
| 21:32 | <jgraham> | Which is possible ofc |
| 21:33 | <jgraham> | It's not like it will be an impossible amount of work |
| 21:33 | <TabAtkins> | Hixie: While you're changing the comment verifier code, could you reject any feedback starting with a doctype too? For reasons unknown to me a lot of the spam is people just putting source-code for pages into the comment box, and I haven't seen a single bug legitimately start with a doctype. |
| 21:33 | <gsnedders> | jgraham: I would much rather do that, FWIW. |
| 21:33 | <gsnedders> | jgraham: Than having separate tests. |
| 21:33 | <jgraham> | gsnedders: Do what? |
| 21:33 | <TabAtkins> | Hixie: (You could probably get away with just rejecting anything starting with "<", possibly preceded by whitespace.) |
| 21:34 | <gsnedders> | jgraham: Having the same testsuite for both, pretty much. |
| 21:34 | <jgraham> | TabAtkins: <html> might be a better be |
| 21:34 | <jgraham> | gsnedders: If you can convince someone to pay for it, sure |
| 21:34 | <jgraham> | *bet |
| 21:34 | <jgraham> | At the moment we don't even have an automated harness |
| 21:34 | <TabAtkins> | jgraham: That wouldn't work - a good chunk of the relevant spam starts witha doctype, not <html>. |
| 21:34 | <jgraham> | So some proverb involving beggars and choosers comes to mind |
| 21:34 | <gsnedders> | jgraham: But an automated harness is needed by no browser vendor, so… |
| 21:35 | <zewt> | relevant spam - an uncommon sequence of words |
| 21:35 | <gsnedders> | jgraham: Whereas more tests benefit browser vendors. |
| 21:35 | <TabAtkins> | zewt: Meaning "the spam under discussion", of coruse. |
| 21:35 | <zewt> | i know, heh |
| 21:35 | <jgraham> | TabAtkins: I think I meant <!DOCTYPE | <html> |
| 21:35 | <TabAtkins> | jgraham: Oh, okay. Yeah, I suspect that would catch most of them. Though I don't think I've ever seen a legitimate bug starting with <, either. |
| 21:36 | <jgraham> | gsnedders: Doubling the number of tests just to test the same codepath twice in most cases doesn't sound that appealing to vendors |
| 21:36 | <TabAtkins> | Best, of course, would be setting up an approval queue that a few of us can hit and accept/reject things quickly and easily before hitting the bugzilla. |
| 21:37 | <jgraham> | It makes test runs take twice as long, doubles the number of regressions to investigate per bug, and takes time to implement |
| 21:37 | gsnedders | doesn't feel like debating it now |
| 21:37 | <jgraham> | gsnedders: Clearly it is an axis along which browser behaviour can vary. But one presumes that in a sane browser the mode doesn't propogate everywhere |
| 21:38 | <jgraham> | So it doesn't seem more valuable then, say, making sure all tests pass if there is at least one script in the DOM |
| 21:38 | <gsnedders> | jgraham: We need some tests for things that quirks mode might obviously change, at the very least. And things it does change in any browsers in the past few years. |
| 21:38 | <jgraham> | gsnedders: Agreed entirely |
| 21:39 | <gsnedders> | How far we go is a question we'll need to discuss, though |
| 21:39 | <AryehGregor> | Okay, testing deleteContents() is kind of annoying. |
| 21:39 | <AryehGregor> | Because it's a real pain to reset between tests . . . |
| 21:39 | <AryehGregor> | Especially since cloneNode() doesn't work on Documents for some obnoxious reason. |
| 21:39 | <zewt> | this is bugging me--aren't custom event names (with no requirement of any sane namespacing) going to cause backwards-compat issues in the future, because people will be using every conceivable verb as an event name? |
| 21:39 | <jgraham> | AryehGregor: Can you use try/catch/finally? |
| 21:40 | <gsnedders> | zewt: No moreso than creating new HTML elements. |
| 21:40 | <AryehGregor> | jgraham, how does that help when it successfully deletes a chunk of the document? I have to restore the document to its previous state somehow. |
| 21:40 | <jgraham> | try {/*do the test*/} catch(e) {throw e} finally {/*reset*/} |
| 21:40 | <zewt> | people aren't exactly encouraged to use arbitrary strings as HTML elements |
| 21:40 | <zewt> | (rather, they're strongly discouraged from it) |
| 21:40 | <AryehGregor> | That's not the issue, the issue is I have to actually reset the document. |
| 21:40 | <hober> | name collisions just aren't that big of a deal in practice |
| 21:40 | <gsnedders> | zewt: Go read the IE blog :P |
| 21:41 | <jgraham> | AryehGregor: Well yes, I am somewhat assuming you have a way to create the initial state |
| 21:41 | <jgraham> | I recommend recreating all state from scratch between tests |
| 21:41 | <zewt> | also, one set of horrible backwards-compatibility black holes doesn't justify another :P |
| 21:41 | <AryehGregor> | That's what I'll have to do here, yes. |
| 21:41 | <AryehGregor> | For things that don't mutate the DOM, it's not really necessary. |
| 21:41 | <jgraham> | Right |
| 21:42 | <jgraham> | But in general it is good if errors from one test don't propogate into others |
| 21:42 | <zewt> | it's not a problem if people use event names with any sensible namespacing scheme, but there's no convention in place or anything |
| 21:42 | <jgraham> | (for some reason, I seem to recall that javascript libraries love making tests like that) |
| 21:42 | <AryehGregor> | I generally adopt the philosophy that if there are test failures, I'll look into them then. |
| 21:42 | AryehGregor | realizes he can just use innerHTML to reset, nice |
| 21:44 | <AryehGregor> | (assuming my DOM is nice enough that it will round-trip, but if not, oh well) |
| 21:44 | <jgraham> | AryehGregor: Bear in mind that you are (hopefully) not the only consumer of your tests |
| 21:44 | <AryehGregor> | I'm testing all the consumers of my tests. |
| 21:44 | <hober> | zewt: if you don't want your names to collide, pick sufficiently interesting names. |
| 21:45 | <zewt> | but web specs generally don't make changes under the notion of "it's okay to break web pages if the developer was incompetent" |
| 21:47 | <jgraham> | AryehGregor: Right, but the ultimate consumer is some developer who gets a regression report telling them that a whole bunch of contentEditable tests failed with the changes they made |
| 21:47 | <AryehGregor> | I'm aware of that. |
| 21:50 | <AryehGregor> | Ugh, why can't Documents be cloned? |
| 21:53 | <TabAtkins> | AryehGregor: Because cloning is an abomination. |
| 21:53 | <AryehGregor> | Why? |
| 21:53 | <TabAtkins> | I should have added "...unto God." |
| 21:54 | <AryehGregor> | Why? |
| 21:54 | <TabAtkins> | I dunno, go ask the Bible. |
| 21:54 | <TabAtkins> | I didn't make the rules here. |
| 21:55 | <AryehGregor> | . . . |
| 21:57 | <AryehGregor> | You know, I just realized that restoring the document by overwriting the contents of the log isn't really that useful for testing purposes. |
| 21:57 | <AryehGregor> | I think I'm going to use an iframe. |
| 21:57 | <AryehGregor> | That seems a lot saner. |
| 21:57 | AryehGregor | now has to figure out how iframes work, exactly, but that shouldn't be too hard |
| 21:58 | <jgraham> | As long as you remember that the load is async, all is good |
| 22:00 | <jgraham> | (which is pretty straightforward) |
| 22:04 | <Hixie> | TabAtkins: sure |
| 22:05 | <Hixie> | TabAtkins: on it |
| 22:09 | <TabAtkins> | Hixie: Either my suggestion (reject if it starts with "<") or jgraham's (reject if it starts with "<!doctype" or "<html") would work. |
| 22:10 | <AryehGregor> | Reject if it starts with "<" sounds too broad. |
| 22:10 | <TabAtkins> | AryehGregor: I don't recall ever seeing a legitimate bug that started with "<". |
| 22:11 | <Hixie> | i rejected with a <, it'll only affect ms2ger |
| 22:11 | <TabAtkins> | Haha. |
| 22:11 | <TabAtkins> | I suppose starting a bug with a chat transcript may cause a problem. |
| 22:11 | <Hixie> | people should give context anyway |
| 22:12 | <Hixie> | i hate reading these bugs that just start without context so i've no idea wtf y'all are talking about until i'm half-way through |
| 22:12 | <Hixie> | then i have to reread it with context :-P |
| 22:12 | <AryehGregor> | TabAtkins, http://bit.ly/eAdCP7 |
| 22:12 | <Hixie> | i've also updated the bug report form so it logs the user agent, hopefully we'll be able to see if there's any patterns there |
| 22:12 | <TabAtkins> | Hixie: That reminds me, I have a five-page paper expounding on the changes you should make to HTML. |
| 22:13 | <Hixie> | cool, mail it in |
| 22:13 | <AryehGregor> | E.g.: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7746 |
| 22:13 | <Hixie> | i'll stick it on top of the other 1600 pages :-P |
| 22:13 | <othermaciej> | Hixie: 118 decision just posted |
| 22:13 | <TabAtkins> | Hixie: I was, um, joking about rambling context-less bugs. ^_^ |
| 22:13 | <othermaciej> | Hixie: will 3 weeks extra time to draft a 119 counter-proposal be sufficient? |
| 22:13 | <Hixie> | TabAtkins: :-P |
| 22:14 | <TabAtkins> | AryehGregor: Okay, point taken. Shrug. They can start their bug with something else, or file it via bugzilla. |
| 22:14 | <Hixie> | othermaciej: one sec |
| 22:14 | <AryehGregor> | Is there a spec for how encoding names are supposed to be processed? (Apropos: http://blogs.msdn.com/b/ieinternals/archive/2011/02/28/script-error-c00ce56e-means-you-have-specified-an-invalid-charset-utf8-is-not-utf-8.aspx) |
| 22:15 | <Hixie> | othermaciej: doesn't that decision supercede issue 119 altogether? |
| 22:15 | <Hixie> | othermaciej: (awesome decision, btw) |
| 22:15 | <Hixie> | othermaciej: (didn't expect that to go that way at all) |
| 22:15 | <othermaciej> | Hixie: I have no idea, I don't remember what 119 is about |
| 22:16 | <othermaciej> | Hixie: did the relations with special meaning when repeated all get dropped? |
| 22:16 | <Hixie> | othermaciej: yes |
| 22:16 | <othermaciej> | it's just about "up"? |
| 22:17 | <othermaciej> | ok |
| 22:17 | <Hixie> | othermaciej: 118 drops index, up, first, and last. 119 is about up. |
| 22:17 | <Hixie> | othermaciej: allow me to make this easier on you. I retract any intent to object to 119. :-) |
| 22:18 | <othermaciej> | then I guess I should just post a call for consensus to close 119 by amicable resolution |
| 22:21 | <Hixie> | sounds good |
| 23:26 | <TabAtkins> | Ah, extracting a common algorithm is always satisfying, especially in specs. ^_^ |
| 23:28 | <Hixie> | yeah |
| 23:29 | <Hixie> | not quite as satisfying as deleting a bunch of text! |
| 23:30 | <TabAtkins> | Does it count if you're deleting the text that was previously duplicating the common algo? |
| 23:30 | <Hixie> | that's extracting a common algorithm |
| 23:30 | <TabAtkins> | Damn. |
| 23:30 | <Hixie> | i mean deleting text without replacing it with anything :-) |