| 02:26 | <jruderman> | Hixie: is http://dev.w3.org/html5/spec/Overview.html#dom-window-close intended to be vague on what browsers are allowed to do in non-auxilary cases? |
| 02:26 | <jruderman> | (e.g. show a dialog, or employ heuristics mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=190515#c70) |
| 03:38 | <MikeSmith> | sayrer: you around? |
| 03:38 | <sayrer> | MikeSmith: hi |
| 03:38 | <MikeSmith> | hey man |
| 03:39 | <MikeSmith> | about your message http://www.w3.org/mid/4A3AF8B9.8040700⊙mc |
| 03:39 | <sayrer> | ah, yes |
| 03:39 | <MikeSmith> | you are encouraged to open bugs in the W3C bugzilla |
| 03:39 | <sayrer> | but not reopen them? |
| 03:39 | <MikeSmith> | there is intentionally no process for it |
| 03:39 | <MikeSmith> | no, you can reopen them too |
| 03:40 | <sayrer> | oh, I wonder if I just missed the button |
| 03:40 | <MikeSmith> | it is intended to be a relative free-for-all in that regard |
| 03:40 | <MikeSmith> | intended by me, I mean, when I set it up for the group |
| 03:40 | <sayrer> | mmm, no, I can't reopen things |
| 03:41 | <sayrer> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034 |
| 03:41 | <sayrer> | no buttons to do so |
| 03:41 | <MikeSmith> | hmm, OK |
| 03:41 | <MikeSmith> | hang on for a couple minutes, I will take a look at it |
| 03:41 | <sayrer> | I can file things |
| 03:41 | <MikeSmith> | I am pretty sure I can change your individual perms |
| 03:42 | <sayrer> | hope this HTML WG is the right HTML WG |
| 03:42 | <sayrer> | :) |
| 03:42 | <MikeSmith> | heh |
| 03:42 | <MikeSmith> | I think we are just using the default bugzilla perms, but anyway, lemme take a look |
| 03:43 | <MikeSmith> | sayrer: so, to be clear, when you are logged in an go to http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034 |
| 03:44 | <MikeSmith> | there is no "Reopen bug" radio button |
| 03:44 | <MikeSmith> | under the Additional Comments textarea? |
| 03:44 | <sayrer> | where should I look? |
| 03:44 | <sayrer> | nope |
| 03:44 | <sayrer> | not there |
| 03:45 | <MikeSmith> | OK |
| 03:48 | <MikeSmith> | sayrer: please try again now |
| 03:48 | <sayrer> | tada |
| 03:50 | <MikeSmith> | I just gave you bugzilla "editbugs" perms. which I guess in bugzilla terms adds you to the editbugs "group" |
| 03:50 | <MikeSmith> | = "Can edit all aspects of any bug." |
| 03:50 | <MikeSmith> | now, what I would like to do is have that be the default for all users of our bugzilla |
| 03:52 | <MikeSmith> | but unfortunately, I reckon that trying to make it so would involve a relatively time-consuming discussion with the powers that be |
| 03:52 | <MikeSmith> | so I guess for now I will just deal with it case by case |
| 03:52 | <MikeSmith> | I wish bugzilla allowed those perms to be set per-Product |
| 03:54 | <MikeSmith> | sayrer: anyway, if you run into w3c bugzilla problems or have questions about our specific instance of it, please feel free to ping me directly and I'll check asap |
| 03:54 | <MikeSmith> | rather than on public-html, I mean |
| 03:55 | <sayrer> | oh, I wouldn't mail /only/ about bugzilla problems |
| 03:55 | <sayrer> | issue seemed worth raising on the list anyway |
| 03:55 | <MikeSmith> | yeah, the issue does |
| 03:56 | <MikeSmith> | I just mean not administrivia-like stuff on public-html |
| 03:56 | <sayrer> | ok |
| 03:56 | <MikeSmith> | just in the interest of trying to keep traffic volume down on the list |
| 03:57 | <MikeSmith> | so, about your actual statement in that message, regarding the topic of "content model" |
| 03:57 | <sayrer> | yeah |
| 03:57 | <MikeSmith> | "I can see why this might be tempting to specify for theoretical reasons, but I can't think of a use case." |
| 03:58 | <sayrer> | http://www.whatwg.org/specs/web-apps/current-work/images/content-venn.svg |
| 03:58 | <sayrer> | why does that exist? |
| 03:58 | <MikeSmith> | oh, that |
| 03:58 | <sayrer> | there's also this business of forming outlines |
| 03:58 | <MikeSmith> | it's not clear from you message that that's what you meant |
| 03:59 | <sayrer> | that is the first illustration under "3.4 Content models" |
| 03:59 | <sayrer> | "There are also certain elements that are sectioning roots. These are distinct from sectioning content, but they can also have an outline." |
| 03:59 | <MikeSmith> | yeah, I thought you had brought that up before -- the question of the appropriateness of the outline algorithm, I mean |
| 03:59 | <sayrer> | like... what is this... |
| 04:00 | <sayrer> | well, I'm sure whoever answered it thought they did a good job addressing the issue |
| 04:00 | <sayrer> | I should pay more attention |
| 04:01 | <MikeSmith> | sayrer: I think the term "sectioning roots" is Hixie coining a language primitives that he needs to reference in multiple definitions elsewhere |
| 04:02 | <MikeSmith> | I think "sectioning content" is fairly unambiguous |
| 04:02 | <MikeSmith> | or at least a familiar concept |
| 04:03 | <MikeSmith> | sayrer: anyway, I would personally advise/prefer that you raise those kinds of questions individual bugzilla issues -- if/when you have time |
| 04:04 | <sayrer> | hmm yeah |
| 04:05 | <MikeSmith> | in some cases it might be useful to post them directly to public-html too, but I have the bugzilla set up so that an automated notification gets sent to the list each time any bug is first opened or resolved |
| 04:06 | <MikeSmith> | so that way, people who are actually interested enough to want to take time to follow the discussion further can take time to cc themselves to the bugzilla issue |
| 04:07 | <sayrer> | gtg |
| 04:37 | <zcorpan_> | "Font family names containing more than one word should be quoted." - i've never understood why it should be quoted |
| 04:37 | <zcorpan_> | http://www.w3.org/TR/2009/WD-css3-fonts-20090618/ |
| 04:57 | <othermaciej> | MikeSmith: I have sympathy with sayrer's position (I am not sure authoring conformance requirements are actually useful) but I think his bug report is ridiculous and insulting |
| 04:57 | <othermaciej> | MikeSmith: and should be closed |
| 04:57 | <othermaciej> | MikeSmith: snark and sarcasm are not appropriate ways to express differences of opinion in a bug tracker |
| 04:58 | <MikeSmith> | othermaciej: well, I'm the one who raised it initially, with that summary (though in jest) |
| 04:58 | <MikeSmith> | I have learned my lesson |
| 04:59 | <othermaciej> | MikeSmith: in that case - I think your bug report is not an appropriate way to raise an issue |
| 04:59 | <zcorpan_> | gsnedders: http://krijnhoetmer.nl/irc-logs/whatwg/20090618#l-356 |
| 04:59 | <othermaciej> | MikeSmith: I think it should be closed and you and/or Rob should raise sincere issues |
| 04:59 | <othermaciej> | such as "HTML5 should have no authoring conformance requirements" |
| 05:00 | <othermaciej> | or suggesting specific changes to the authoring conformance requirements |
| 05:00 | <othermaciej> | it's not clear to me which the bug is really asking for - I think it's obvious that literally replacing the text "conformance checker" with "loyalty checker" everywhere is not something anyone sincerely wants |
| 05:00 | <zcorpan_> | i think the requirements are very useful for authors |
| 05:00 | <MikeSmith> | othermaciej: yeah, of course |
| 05:00 | <MikeSmith> | othermaciej: but I will let Rob do what he wants we the issue, and let anybody else who uses bugzilla do anything they want with it |
| 05:01 | <othermaciej> | since I haven't used the bug tracker much, I don't feel it's my place to close it |
| 05:01 | <MikeSmith> | I am not going to let that bugzilla become yet another place where we get mired in discussions about what's appropriate and what the process should be |
| 05:01 | <zcorpan_> | isn't the bug closed already? |
| 05:01 | <othermaciej> | but if someone filed a bug like that in WebKit bugzilla, it would be INVALID city, and if people tried to reopen it, they would get a talking to about responsible use of bugzilla |
| 05:02 | <MikeSmith> | zcorpan_: I closed it, but Rob said he wanted to reopen it, and I said, go ahead |
| 05:02 | <MikeSmith> | othermaciej: our bugzilla is relatively lightly used now -- nothing on the scale of Webkit bugzilla -- and we do not have a general problem |
| 05:03 | <MikeSmith> | if this develops in a bigger problem, then I will do something about it |
| 05:03 | <othermaciej> | sure, but filing sarcastic bug reports and reopening them are still abusive things to do |
| 05:03 | <othermaciej> | you in particular should set a better example |
| 05:03 | <MikeSmith> | othermaciej: add it to the list of many other things in the group that are considered abusive by some members of the group |
| 05:04 | <MikeSmith> | othermaciej: christ |
| 05:04 | <MikeSmith> | I hope you mean that "you in particular should set a better example" sarcastically |
| 05:04 | <MikeSmith> | I can't tell |
| 05:04 | <othermaciej> | fine, I don't want to get mired in a postmodern discussion of whether courtesy is an illusion |
| 05:05 | <MikeSmith> | good |
| 05:05 | <MikeSmith> | I don't want to either |
| 05:06 | <MikeSmith> | but please, seriously, don't schoolmarm me with "you in particular should set a better example" nonsense |
| 05:06 | <MikeSmith> | I get plenty enough of that already |
| 05:06 | <MikeSmith> | believe me |
| 05:09 | <zcorpan_> | i wonder why jd doesn't put quotes around ECMAScript 4 |
| 05:11 | <MikeSmith> | zcorpan_: because he's not afraid of ECMAScript 4 |
| 05:11 | <MikeSmith> | he only uses scare quotes to indicate stuff that he's afraid of |
| 05:13 | <othermaciej> | they were scare quotes of disdain |
| 05:14 | <othermaciej> | ECMAScript 4 was based on ActionScript so it would be hard for him to consistently disdain it |
| 05:14 | <othermaciej> | (ES4 also had a lot more hype than reality, somewhat undermining his point...) |
| 05:19 | <othermaciej> | the comments here are entertaining: http://news.ycombinator.com/item?id=662620 |
| 05:50 | <sayrer> | entertaining, or insulting? |
| 05:50 | <othermaciej> | both! |
| 05:50 | <sayrer> | regarding the bug report: I did not file it, but I do think it raises a real issue |
| 05:51 | <sayrer> | and the title is only insulting to the extent that it is poignant |
| 05:51 | <othermaciej> | sayrer: I think a sincere bug that suggests removing conformance requirements would be useful |
| 05:51 | <sayrer> | there is no swearing or personal attacks |
| 05:51 | <othermaciej> | or a bug that suggested specific changes to removing conformance requirements |
| 05:52 | <sayrer> | so I think politeness police kind of stuff is bikeshedding |
| 05:52 | <othermaciej> | I think sarcastically requesting a change that is not what is actually desired, without making it clear what is desired, is a bad use of the bug tracker |
| 05:52 | <othermaciej> | filing the bug in the first place could be seen as comedy, reopening it is abusive |
| 05:52 | <sayrer> | yes, I think your point, while possibly valid, is unimportant |
| 05:52 | <sayrer> | reopening the bug is not abusive |
| 05:53 | <MikeSmith> | sayrer: I agree with othermaciej that we would be better off if you changed the title of the bug |
| 05:53 | <sayrer> | I went and asked for permision to reopen it from the person who filed it |
| 05:53 | <othermaciej> | chain reopening sarcastic bugs is a waste of people's time, and not likely to lead to any productive outcome |
| 05:53 | <MikeSmith> | sayrer: I mean better off in that if you actually want people to take the issue seriously |
| 05:53 | <sayrer> | Larry and Maciej seem to want to change the title... I don't care what it is |
| 05:54 | <MikeSmith> | sayrer: if you don't care what it is, I will go ahead and change it |
| 05:54 | <sayrer> | go for it |
| 05:54 | <sayrer> | of course, now it's been defaced by maciej lecturing :) |
| 05:56 | <othermaciej> | I think my point was valid, and if it was unimportant, then surely debating its unimportance is an even greater waste of time |
| 06:02 | <MikeSmith> | I have re-learnedd the lesson that attempts at humor are most successful among a group of people who are reasonably familiar with each, but less successful in a group a people who have a tendency to be distrustful of each others and who are prone to suspect (or even openly accuse) each other of having ulterior motives |
| 06:02 | <MikeSmith> | (reasonably familiar with each other) |
| 06:21 | <othermaciej> | MikeSmith: I get that you were trying to be funny, and I don't want to say humor in a bug tracker is always wrong, it's just that mixing it up with a substantive issue of controversy and combined with reopening it starts to be less funny |
| 06:22 | <MikeSmith> | yep, point taken |
| 06:22 | <othermaciej> | I regret being heavy-handed in my complaining about it |
| 06:23 | <MikeSmith> | othermaciej: np. I regret having filed it as bug to begin with |
| 06:41 | zcorpan_ | wonders why http://www.w3.org/TR/2009/WD-css3-fonts-20090618/ refers to "XHTML headings" rather than "HTML headings" |
| 06:56 | <Hixie> | jruderman: send mail, sorry can't reply right now |
| 06:57 | <zcorpan_> | i wonder if 'unicode-range' is a good feature to have |
| 06:57 | <zcorpan_> | does anyone implement it? |
| 06:59 | <zcorpan_> | if an author wants to optimize bandwidth, it seems Philip`'s approach is more effective |
| 07:00 | <zcorpan_> | i mean, in the example, a 4.5 MB font is downloaded just to render an arrow |
| 07:21 | <zcorpan_> | "Matching occurs in a well-defined order to insure ..." |
| 07:39 | <heycam> | Hixie, are you happy with the statement in html5 about document.all booleanifying to false remaining there? or do you think it needs to web idl? |
| 07:39 | <heycam> | i suppose whatever spec defines style.filter needs it |
| 07:40 | <heycam> | then again, it's just one sentence of prose, so it's not that much of a burden to really need an [Undetectable] in web idl |
| 07:48 | zcorpan_ | updates https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox to use <object> instead of <applet> |
| 07:49 | <zcorpan_> | heycam: typeof document.all should return 'undefined', iirc |
| 07:49 | <heycam> | zcorpan_, ah. at least that's within the realms of conformance to the ecmascript spec. |
| 07:50 | <heycam> | i suppose Hixie should add that then (as long as [Undetectable] isn't in web idl) |
| 07:50 | <Hixie> | heycam: i've no idea. i couldn't get browser vendors to tell me anything useful. |
| 07:52 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/146 |
| 07:54 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/147 - firefox false, webkit and opera true |
| 07:54 | <zcorpan_> | do instanceof doesn't seem to need anything special |
| 07:54 | <zcorpan_> | but typeof does |
| 07:56 | <zcorpan_> | firefox stringifies to 'undefined' too, but opera and webkit don't |
| 08:01 | <zcorpan_> | it seems firefox tries to make it as undetectable as possible, while opera and webkit try to do as little as necessary to be compatible with web content |
| 08:22 | <othermaciej> | I can tell you guys what we do to make document.all undetectable |
| 08:23 | <othermaciej> | it's more than just the typeof thing |
| 08:23 | <othermaciej> | does HTML5 intend to spec document.all? |
| 08:23 | <othermaciej> | (I couldn't find it in the IDL but maybe it's spec'd elsewhere?) |
| 08:23 | <Hixie> | it does spec it already |
| 08:23 | <zcorpan_> | othermaciej: you can reply to my email on public-html :) |
| 08:24 | <Hixie> | zcorpan_: i did the reverse engineering; the question was what was actually needed and what were browser vendors willing to change to doing |
| 08:24 | <othermaciej> | the HTMLDocument interface definition doesn't seem to list an "all" property |
| 08:25 | <othermaciej> | where is it spec'd? |
| 08:25 | <zcorpan_> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#dom-document-all |
| 08:26 | <zcorpan_> | Hixie: someone at opera said typeof was required for web compat |
| 08:26 | <othermaciej> | I see |
| 08:27 | <othermaciej> | splitting the interfaces is a bit unwieldy |
| 08:27 | <othermaciej> | though I can understand it as a way to hide the bad stuff |
| 08:28 | <zcorpan_> | Hixie: maybe you should include the obsolete stuff together with the other things but hide it behind class=impl (and have // obsolete in the IDL)? |
| 08:28 | <zcorpan_> | although i guess having it in a separate section is better for authors and implementors will see the obsolete section anyway |
| 08:28 | <Philip`> | zcorpan_: It'd be great if someone made a font format that could just download the glyphs that were needed on demand, so you wouldn't have to download the entire font or subset it in advance |
| 08:29 | <zcorpan_> | Philip`: indeed |
| 08:29 | <Philip`> | but it seems everyone wants to invent new formats to add DRM capabilities, not to add any actually useful features |
| 08:29 | <heycam> | Hixie, did you in the end need something from Web IDL for the split window "this" issue? |
| 08:29 | <zcorpan_> | Philip`: still, 'unicode-range' is not it |
| 08:29 | <heycam> | i.e. where "this" means the WindowProxy instead of the Window? |
| 08:29 | <Hixie> | heycam: no |
| 08:29 | <heycam> | ok cool |
| 08:29 | heycam | is going through some old notes |
| 08:29 | <Hixie> | heycam: search HTML5 for WindowProxy if you want to see how i ended up doing it |
| 08:32 | zcorpan_ | should get better at quoting the spec in his spec feedback emails |
| 08:34 | <othermaciej> | I sent what I think is an exhaustive list of what we do |
| 08:34 | <othermaciej> | zcorpan_: I'm an implementor and I didn't see it til it was pointed out |
| 08:34 | <othermaciej> | though I guess I will know to look for them now |
| 08:34 | <zcorpan_> | Hixie: maybe you should have <span class=impl>// further members are specified <span>xref</span></span> in the main IDL |
| 08:35 | <Hixie> | zcorpan_: that's a good idea; file a bug for me? |
| 08:35 | <othermaciej> | basically what we do is make sure document.all compares as false in boolean comparisons, has a type of "undefined", and compares equal to undefined, null and false |
| 08:35 | <othermaciej> | (bot not strict equal) |
| 08:35 | <Hixie> | othermaciej: i saw all kinds of weird per-op-code behaviour when i was looking at jsc |
| 08:36 | <othermaciej> | Hixie: I believe all of that behavior implements what I described above and nothing more |
| 08:36 | <othermaciej> | I may have missed a spot |
| 08:36 | <othermaciej> | but I don't think so |
| 08:36 | <Hixie> | cool |
| 08:37 | <zcorpan_> | opera doesn't do the equals thing it seems |
| 08:37 | <othermaciej> | I believe we apply the exact same set of hacks to style.filter |
| 08:37 | <heycam> | Hixie, at one point you asked about an open issues list for Web IDL. That list should just be the red notes in the spec, now. |
| 08:38 | <Hixie> | heycam: cool |
| 08:38 | <Hixie> | heycam: good to know |
| 08:38 | <heycam> | so if there is something you requested that hasn't been handled but doesn't have a red note, let me know |
| 08:38 | <Hixie> | roger |
| 08:38 | <othermaciej> | (btw I should note that, at least for us, undetectability belongs to the object implementing document.all, not to the property) |
| 08:38 | <othermaciej> | (so if you do var failAPI = document.all, then failAPI will have all the same forms of undetectability) |
| 08:40 | <zcorpan_> | that's the same in opera i think |
| 08:40 | <othermaciej> | I think Mozilla does something elaborate and weird that may be specific to the context of an if statement |
| 08:41 | <Hixie> | not sure how to define that things are == null and == undefined |
| 08:41 | <Hixie> | but i'm sure i'll figure out a way |
| 08:42 | <othermaciej> | what's hard about it? |
| 08:42 | <zcorpan_> | Hixie: opera doesn't do that, so it might not be needed for compat |
| 08:42 | <othermaciej> | can't you just literally list some of the ECMAScript expressions that MUST evaluate to certain values, despite what the ES spec says for normal objects? |
| 08:43 | <Hixie> | i don't know |
| 08:43 | <Hixie> | i'm not really sure how to define the expression |
| 08:43 | <othermaciej> | I can't remember if we did it for consistency or because we thought some sites really check that way |
| 08:43 | <Hixie> | is |document.all == foo| true if |foo === null|? |
| 08:44 | <othermaciej> | if (document.all != undefined) seems like a plausible check |
| 08:44 | <othermaciej> | that's the case in WebKit |
| 08:44 | <Hixie> | what about things like isNaN, and |'all' in document|, and so on? |
| 08:44 | <othermaciej> | it does it based on the value being null, the expression doesn't have to contain the null literall |
| 08:45 | <Hixie> | so is it a property of the == operator or of the document.all object? |
| 08:45 | <Hixie> | or both? |
| 08:45 | <Hixie> | or something else? |
| 08:45 | <Hixie> | anyway like i said i'm sure i'll find a way to express it |
| 08:45 | <othermaciej> | alert('all' in document) reports true in Safari |
| 08:45 | <Hixie> | i just haven't look at it in detail yet |
| 08:45 | <othermaciej> | it's a property of the combination of the object and the == operator |
| 08:46 | <Hixie> | so if there is some other language mechanism to do comparisons, then it isn't affected by this magic? |
| 08:46 | <Hixie> | and if, say, JS added operator overloading, an overloaded '==' wouldn't see magic? |
| 08:46 | <othermaciej> | there is the === operator |
| 08:46 | <othermaciej> | which is not affected |
| 08:47 | <Hixie> | basically my point is just that the wording has to be very carefully thought out; i don't think it'll be especially hard or anything |
| 08:47 | <othermaciej> | I can't predict how it would interact with hypothetical future features |
| 08:47 | <zcorpan_> | if (document.all === undefined) seems like an equally plausible check as if (document.all == undefined), although i guess would be a lot less common |
| 08:47 | <Hixie> | ideally if we define it clearly (i.e. not by example), it will be well-defined |
| 08:49 | <othermaciej> | hmmm |
| 08:49 | <othermaciej> | I can't find signs of document.all existing at all in Firefox |
| 08:49 | <zcorpan_> | othermaciej: try quirks mode |
| 08:49 | <othermaciej> | does the page need to have some special property for document.all to appear even in hidden form? |
| 08:49 | <Hixie> | has to be in quirks mode in firefox |
| 08:49 | <othermaciej> | oh hey, google.com has a docype now |
| 08:50 | <Hixie> | i'm trying :-) |
| 08:50 | <othermaciej> | there goes my favorite quirks mode test page! |
| 08:50 | <Hixie> | my influence is slow, but non-zero :-) |
| 08:50 | <Hixie> | jens meiert has been helping a lot too |
| 08:50 | <Hixie> | he even set up an internal instance of henri's validator |
| 08:50 | <zcorpan_> | doesn't validate though :( |
| 08:51 | <Hixie> | not yet :-) |
| 08:51 | <Hixie> | google.com is an impressively deceptive page in that while it looks simple, it is insanely complicated |
| 08:51 | <othermaciej> | Firefox makes document.all == to undefined and null |
| 08:51 | <othermaciej> | which is probably why we did that |
| 08:51 | <Hixie> | so many domains, so many languages, so many locales, so many things to expose differently in different countries... |
| 08:52 | zcorpan_ | is waiting for Hixie to respond to emails from 2005 where people ask Hixie to make google.com front page validate |
| 08:52 | <Hixie> | i doubt i have those around still |
| 08:52 | <Hixie> | oh did i mention that the web elements guys fixed the problems ou raised? |
| 08:52 | <Hixie> | or were going to, anyway? |
| 08:53 | <Hixie> | dunno if they actually did |
| 08:53 | <Hixie> | let me know in a few months if you still find them broken |
| 08:53 | <zcorpan_> | cool |
| 08:53 | <Hixie> | they apparently were already intending to do it |
| 08:53 | <Hixie> | and had introduced a bunch of errors at the last minute trying to fix things up in other browsers |
| 09:31 | <Philip`> | Woah, Chrome can run Canvex almost full-screen with almost acceptable performance :-o |
| 09:31 | <Philip`> | (Maybe other modern browsers can too, but I've not tried them) |
| 09:31 | <Philip`> | I need to work on it again to make it slower |
| 09:51 | <gsnedders> | zcorpan_: Send email. I probably won't get around to doing anything about it till in Sweden anyway though. :) |
| 09:52 | <gsnedders> | zcorpan_: What's wrong about the output? |
| 10:24 | <Lachy> | JohnResig, yt? |
| 10:25 | <Lachy> | JohnResig, I wanted to discuss getting the selectors api test suite completed, as mentioned in my last mail to public-webapps |
| 10:33 | <zcorpan_> | gsnedders: the h2s should be sub sections of the h1 |
| 10:37 | gsnedders | remembers the header/hgroup change. that's the bug :P |
| 10:45 | <Philip`> | http://www.guardian.co.uk/politics/gallery/2009/jun/18/mps-expenses-houseofcommons?picture=349036998 - noooo! Comic Sans :-( |
| 12:03 | <roc> | Philip`: download glyphs on demand? that's crazy talk |
| 12:03 | <roc> | hmm |
| 12:03 | <roc> | why is jd proud of the fact that Flash only checks for updates once a month? |
| 12:05 | annevk5 | thinks jd is best ignored at this point |
| 12:19 | <Lachy> | who's jd? |
| 12:27 | <roc> | http://blogs.adobe.com/jd/ |
| 12:34 | <JohnResig> | Lachy: "IE lacks support for many of the CSS3 selectors tested in the test suite, but to be fair, these failure should be ignored. |
| 12:35 | <JohnResig> | that's bullshit :-( |
| 12:35 | <JohnResig> | do we really have to remove those tests? |
| 12:35 | <JohnResig> | ok, hang on, I should probably keep reading |
| 12:35 | <gsnedders> | JohnResig: Is CSS 3 selectors really need to be a prerequisite for the selectors test suite, though? |
| 12:36 | <JohnResig> | gsnedders: for a fully interoperable implementation, yep! |
| 12:36 | <gsnedders> | JohnResig: How so? What in selectors requires CSS 3 selectors to be tested? |
| 12:38 | <JohnResig> | gsnedders: I'm saying that if we care about having interoperability - and making sure that all of the possible selectors work correctly - we need to test the full gamut of CSS selectors. A number of bugs were caught in the implementations of WebKit, Firefox and Opera since these tests existed - stripping them out will mean 1) There will be regressions 2) That IE will implement more bugs in their implementation and 3) That the implementations will be more li |
| 12:39 | <gsnedders> | JohnResig: Is that not an issue for the CSS 3 selectors test suite, though? |
| 12:39 | <JohnResig> | gsnedders: no - it's simply assumed that ass CSS selectors work identically as they do in the browser - it's very likely that they don't |
| 12:39 | <annevk5> | gsnedders, that test suite does not test them in the context of the Selectors API |
| 12:40 | <JohnResig> | there were a number of selectors that failed in the suite but "passed" in the official CSS selector test suite |
| 12:42 | <Lachy> | JohnResig, no, I didn't say we should remove them. |
| 12:42 | <JohnResig> | Lachy: heh, ok, I'm still reading |
| 12:42 | <JohnResig> | Lachy: just got a little flustered ;) |
| 12:43 | <Lachy> | Just that counting them when working out IE's level of conformance isn't really fair, because not supporting CSS3 doesn't affect their conformance with the requirements in Selectors API |
| 12:43 | gsnedders | would nevertheless argue that unless the Selectors API requires support for CSS 3 Selectors (normatively) its test suite should just check against CSS 2.1, and optionally CSS 3 Selectors |
| 12:44 | <JohnResig> | Lachy: I see, yeah - and the fact that there's been 3 nearly-conformant implementations (as you pointed out) kind of removes the need for IE to be fully conformant |
| 12:44 | <JohnResig> | regardless |
| 12:45 | <JohnResig> | Lachy: I'm reading over the list on the bottom now |
| 12:45 | <Philip`> | roc: Why so crazy? It's just like downloading seekable media resources, except with lots more seeking, so you could add some kind of batching, and then it'd be trivial! :-) |
| 12:45 | <JohnResig> | Lachy: the test suite was actually, originally, xhtml - and included SVG inside of it |
| 12:45 | <JohnResig> | Lachy: I removed it because it broke in IE and we wanted the suite to run in IE :-/ |
| 12:46 | <Lachy> | as far as selectors api conformance is concerned, for interoperability, we only need to ensure that the selectors that the implementations do support work correctly in the API. Requiring that they also work with Selectors that the implementation don't even claim support is silly |
| 12:47 | <Lachy> | ok. In that case, it's probably easiest to just make a new version that tests XHTML/SVG specific stuff |
| 12:48 | <JohnResig> | the first batch of hixie tests are pretty painless |
| 12:50 | <JohnResig> | woah, Hixie's 002-001 test is pretty nuts |
| 12:52 | <Lachy> | do you mean checking for "[object NodeList]" |
| 12:52 | <Lachy> | ? |
| 12:52 | <JohnResig> | Lachy: yeah - checking that the resulting NodeList is == to "[object NodeList]" |
| 12:52 | <Lachy> | I'm fine wil leaving the whole of Hixie's 002 tests out |
| 12:53 | <JohnResig> | Lachy: we already test for 002-003 |
| 12:53 | <JohnResig> | and isn't 002-002 part of a different spec? |
| 12:53 | <JohnResig> | ok, anyway, I'll merge in 001 |
| 12:53 | <Lachy> | well, the IDL says NoInterfaceObject |
| 12:54 | <Lachy> | so technically, 002-002 is testing a selectors api requirement, though it depends on a relatively unstable spec |
