| 00:03 | <erlehmann> | Will HTML6 be developed over google wave ? |
| 00:04 | <erlehmann> | instead of mailing lists, that is |
| 00:04 | <Dashiva> | I was hoping we'd have collective consciousness by then |
| 00:05 | <Philip`> | On the subject of versioning: I submitted a test case for the RDFa test suite that includes a character that's valid in XML5e but not in XML4e |
| 00:05 | <jcranmer> | HTML 6 will probably move to newsgroups :-) |
| 00:05 | <Philip`> | I wonder what will happen with that... |
| 00:08 | <Philip`> | erlehmann: You may be underestimating people's attachment to legacy technologies |
| 00:09 | <Philip`> | When someone's spent fifteen years setting up their email client to perfection, they're not going to want to change for another fifteen years |
| 00:10 | <erlehmann> | i get it. people still use IRC for despite jabber being better in virtually all low-attendance scenarios. |
| 00:12 | <Philip`> | Jabber is great, you can DOS a whole multi-user room by sending ill-formed XML |
| 00:12 | <Hixie> | it's only been 14 years |
| 00:12 | <Hixie> | :-P |
| 00:17 | <Philip`> | (Actually you can DOS it by sending perfectly well-formed (but unusual) XML that the server mangles into ill-formed XML) |
| 00:18 | <Philip`> | s/(\S*-formed)/namespace-$1/ |
| 00:20 | <othermaciej> | what would CORS applied to <img> do? |
| 00:21 | <othermaciej> | is there a draft for Sec-From as renamed to Origin? |
| 00:24 | <Hixie> | http://tools.ietf.org/html/draft-abarth-origin |
| 00:24 | <Hixie> | CORS on <img> would be useful for <canvas> |
| 00:27 | <othermaciej> | neat |
| 00:27 | <othermaciej> | whats the goal for this draft? publish as an individual submssion RFC, or form an IETF Working Group? |
| 00:28 | <othermaciej> | and can an individual submission RFC be on the IETF standards track? (the header on this one doesn't request standards track status) |
| 00:28 | <othermaciej> | (perhaps aarth could better answer these questions if he were here) |
| 00:28 | <othermaciej> | er, abarth |
| 00:29 | <Hixie> | well it's a standard |
| 00:29 | <Hixie> | whether the ietf deign to give it that label or not is probably up to them |
| 00:35 | <Hixie> | othermaciej: ok, as far as i know, Origin-related feedback is addressed. |
| 00:37 | <othermaciej> | Hixie: I'm not sure if it's ok per W3C rules to normatively reference a non-standards-track RFC, so it does matter procedurally, even if not substantively |
| 00:37 | <othermaciej> | Hixie: I guess I should ask abarth about this stuff |
| 00:38 | <Hixie> | my goals are varied, such as to get specifications that implementors can follow without having to do reverse engineering, having specs that when followed to the letter reliably lead to interop, having specs that UAs are willing to implement, etc |
| 00:38 | <Hixie> | but i have to say, none of my goals involve anything to do with a particular process or other |
| 00:39 | <Hixie> | it saddens me that yours do now :-) |
| 00:39 | <Hixie> | (process is supposed to help, not hinder, ) |
| 00:39 | <Hixie> | s/, // |
| 00:49 | <TabAtkins> | Lachy, sorry for being difficult in the Selectors API thread. I didn't like the design of querySelector when it first created, and I don't like it now. >_< |
| 00:50 | <TabAtkins> | Also, how often in practice do you know you only want the first result of a selector match? |
| 00:51 | <takkaria> | when selecting by id? |
| 00:51 | <TabAtkins> | I guess it might be common when you know you're searching for only a single thing, so the implementation can stop searching after it finds the first. |
| 00:51 | <TabAtkins> | That doesn't seem to have bothered Resig enough to optimize for it in jQuery, though. |
| 00:51 | <takkaria> | though I guess there's getElementById() for that |
| 00:54 | <TabAtkins> | takkaria: Yeah, by id is certainly the primary case of "I know there's only one here". Though an HTML implementation can make that optimization all by itself (I'm pretty certain that Sizzle recognized the "#foo" case and just uses getElementById). |
| 00:54 | <TabAtkins> | s/recognized/recognizes/ |
| 01:02 | <Lachy> | TabAtkins, it's quite common to see stuff like getElementsByTagName("...")[0]. The point of querySelector() returning a single result is to address the analogous cases where that's done with selectors |
| 01:03 | <TabAtkins> | That makes sense, but like I said, it doesn't appear to be enough of a problem in practice for Sizzle to optimize for it. |
| 01:04 | <TabAtkins> | And Sizzle, obviously, runs slower than an equivalent native selector engine. |
| 01:04 | <Lachy> | it may have been that detecting when an author only wants a single result vs. all results when using the JQuery API proved difficult or impossible. But JS libraries aren't the only use case. |
| 01:05 | <TabAtkins> | Well, of course. But I don't believe that *any* of the major selector engines optimized for that. |
| 01:05 | <Lachy> | so? |
| 01:06 | <TabAtkins> | So, that brings up the possibility that you're solving something that isn't a problem. |
| 01:07 | <othermaciej> | Hixie: the W3C rule about maturity level of your normative references is supposed to prevent specs from moving forward as supposedly complete when they actually depend on something unstable |
| 01:07 | <TabAtkins> | And when the solution itself causes problems (such as requiring any new method to be accompanied by a twin version, making it more painful to introduce new methods), that can be an issue. |
| 01:07 | <Lachy> | as I said, JS libraries can't readily detect when an author wants only a single result, so it isn't at all surprising that they can't optimise for it. That doesn't mean they wouldn't if they couldn't, or that it's not worth it for people who don't use JS libraries |
| 01:08 | <othermaciej> | Hixie: that seems like a helpful rule to me, otherwise the meaning of maturity levels is undermined |
| 01:08 | <othermaciej> | Hixie: in any case, the W3C has to follow the W3C process, so my personal preferences don't enter into it |
| 01:08 | <TabAtkins> | I'm not talking about detecting intent. querySelector doesn't detect intent, it allows the author to explicitly say what they want. But I don't believe any js library has found it to be worthwhile to allow their users to do that. |
| 01:09 | <Lachy> | right. But there is no way, using a JS library API like JQuery, to say they only want one result before the query is executed |
| 01:09 | <TabAtkins> | After all, would it really be that difficult for jquery to have both $() and $1()? |
| 01:10 | <Lachy> | probably not, but anyway, this issue has been resolved and closed for over a year now, and is impossible to change. Arguing is beyond pointless |
| 01:11 | <Hixie> | othermaciej: oh well html5 isn't going to be stable for eons. we don't even have the beginnings of a test suite yet. |
| 01:11 | <Hixie> | othermaciej: so we're far from that problem. |
| 01:11 | <Lachy> | I'd rather focus on the issues I'm trying to solve, rather than ancillary issues |
| 01:12 | <Hixie> | othermaciej: i agree that we shouldn't refer to unstable drafts when we're claiming to be done, but that's a matter of how stable the specs are, not what labels the IETF or W3C put on them. |
| 01:12 | <othermaciej> | Hixie: sure, and at Last Call time you can presumably reference absolutely anything, but it would be wise to reference something that can plausibly advance enough that it won't block PR by the time that rolls around |
| 01:12 | <TabAtkins> | Yeah, I'm not arguing to change querySelector. That's done and over with. But it brings up the possibility that we wouldn't need both a scopedSelector and scopedSelectorAll. |
| 01:12 | <Hixie> | othermaciej: we're like a decade or more away from that problem |
| 01:13 | <Lachy> | I'm confused. What are you suggesting we have |
| 01:14 | <TabAtkins> | Like I said in the email, my preferred solution is a function that scopes by default (or, more precisely, a function that works like jQuery's $.find()). |
| 01:14 | <othermaciej> | Hixie: I'll think I'll ask Adam about it, since you don't seem to have information on how this spec will progress on the IETF standards track |
| 01:14 | <Lachy> | that's what queryScopedSelectorAll() would do. You're being inconsistent |
| 01:15 | <TabAtkins> | I agree that's what queryScopedSelectorAll would do. But you don't like that solution because it apparently necessitates queryScopedSelector, which may double into queryScopedSelectorNS in the future. |
| 01:16 | <Lachy> | would you state very clearly what you are suggesting? |
| 01:16 | <Lachy> | are you suggesting we just introduce one for selecting all? |
| 01:16 | <TabAtkins> | Yes. |
| 01:16 | <Lachy> | right. Why didn't you just say so? |
| 01:16 | <TabAtkins> | >_< I did. Roundabout, I guess, but still. |
| 01:17 | <Lachy> | you required me to read between the lines, which I try to avoid doing as it can lead to misunderstandings |
| 01:18 | <Lachy> | anyway, that would make the API inconsistent, which would suck |
| 01:18 | <TabAtkins> | Well, if we go with additional methods, it'll either be inconsistent or bloated. |
| 01:19 | <Lachy> | also, I can probably avoid introducing the NS methods by either not supporting namespaces, or finding an alternative solution that doesn't introduce new methods |
| 01:19 | <TabAtkins> | So would 2 new methods be "too much"? |
| 01:19 | <TabAtkins> | (queryscopedSelector and $1All) |
| 01:21 | <Lachy> | by themselves, they wouldn't. But we'd need to be careful about what else they could lead to the introduction of. It's about thinking ahead and avoiding unnecessary complexity |
| 01:22 | <Lachy> | and to be honest, they are they 2nd best of the 4 available options, IMHO |
| 01:24 | <TabAtkins> | I don't think there are any other direct variations of querySelector that can possibly exist, outside of the NS versions. |
| 01:24 | <Lachy> | I suppose they would also only need to be supported on Element nodes, not Document or DocumentFragment |
| 01:24 | <TabAtkins> | Plus NodeLists. |
| 01:25 | <Lachy> | no |
| 01:26 | <Lachy> | NodeLists don't need to support the methods. That use case has been addressed differently |
| 01:26 | <Lachy> | document.querySelectorAll(":reference>p", list); |
| 01:26 | <TabAtkins> | Ah, k. |
| 01:27 | <Lachy> | hmm. maybe that does mean we'd need the scoped methods on Document and DocumentFragment |
| 01:27 | <Lachy> | to do this |
| 01:27 | <Lachy> | document.queryScopedSelectorAll(">p", list) |
| 01:30 | <TabAtkins> | Yeah, if you want the shortened form to be ubiquitous. |
| 01:30 | <TabAtkins> | But then what would document.queryScopedSelectorAll(">p") mean? What's the scope? |
| 01:31 | <TabAtkins> | Gah, all that typing is why I hate ordinary js, though. >_< |
| 01:36 | <TabAtkins> | Lachy: is it intended that :reference ever be usable outside of a scoped selector? |
| 01:39 | <Hixie> | whoever was asking me about rendering <details> -- i changed the spec so that it's easier to do from script |
| 01:43 | <TabAtkins> | I like the stricter definition, Hixie. |
| 01:43 | <Hixie> | how do you mean, "stricter"? |
| 01:43 | <TabAtkins> | Previously I thought it was probably going to become common to just put a <dt> without a <dd>. |
| 01:44 | <Hixie> | ah |
| 01:46 | <TabAtkins> | So I guess you're keeping <dt>/<dd> for <figure> and <details>, now that Leif found a talisman that makes IE6 and IE7 build a proper tree? |
| 01:49 | <Hixie> | i'm just going through the bugs, so if nobody filed a bug asking for them to be removed, they're not changing, and if someone did, they i'll look at their arguments and see if they are compelling. |
| 01:51 | TabAtkins | goes to file a bug. He's not sure it's compelling, but thinks it should be considered. |
| 01:52 | <Hixie> | do you think it should be considered more than it was when we first used <dt>? |
| 01:52 | <Hixie> | i mean, that took about a year of consideration |
| 01:53 | <Hixie> | btw, thanks to the various people who occasionally go and resolve bugs that are invalid or duplicate or whatever |
| 01:53 | <Hixie> | it's much appreciated |
| 01:53 | <Hixie> | everyone should feel free to go ahead and close bugs that are based on misunderstandings or that can't be changed for whatever reason |
| 02:05 | <TabAtkins> | Hixie: From IRC chatter, no one realized that IE6 and IE7 were generating non-tree DOMs when <dt> or <dd> were used outside of <dl>. So yeah, some more consideration seems warranted, given the apparently new information. |
| 02:06 | <Hixie> | IE6 and IE7 do all kinds of random stuff |
| 02:06 | <Hixie> | you need basic scripts just to include a new element |
| 02:09 | <TabAtkins> | Yeah, but that basic script (just 200 bytes or so) makes them work great, and the code itself is understandable, even if the reasoning behind it is crazy. |
| 02:10 | <TabAtkins> | On the other hand, the talisman to make IE6 and 7 generate tree DOMs when <dt> is thrown around is completely psycho and makes no sense whatsoever. It just trips some mysterious parse flag somewhere in the browser, and we hope that it doesn't cause any ill effects. |
| 02:11 | Hixie | shrugs |
| 02:12 | <Hixie> | given that i wasn't expecting this element to be useful for years, that there is a problem using the element in the obsolete 25% of the market doesn't really worry me that much |
| 02:15 | <TabAtkins> | I expect <details> to be js-usable immediately (with a little elem.open feature test to allow browsers to slide in native functionality seamlessly), so that does still worry me. |
| 02:16 | <TabAtkins> | And IE6 is 20-25%, but IE7 is 25-30% (at least according to my company's website, which receives mostly nontechnical visitors), so that's a good half of the web that we're excluding. |
| 02:20 | <Hixie> | you have IE6 at 25%?! |
| 02:20 | <Hixie> | what kind of site are you running? |
| 02:20 | <TabAtkins> | www.igofigure.com |
| 02:20 | <TabAtkins> | We sell membership management software for small fitness clubs. |
| 02:21 | <Hixie> | i guess fitness clubs have poor IT staff! :-) |
| 02:21 | <TabAtkins> | Like you wouldn't believe. |
| 02:21 | <Hixie> | that's way higher than average for IE6 |
| 02:21 | <Hixie> | how depressing |
| 02:21 | TabAtkins | was tech support for his company before he became webmaster. |
| 02:31 | TabAtkins | found a bug from Shelley that he could comment on. |
| 02:32 | <TabAtkins> | Luckily I don't actually care about IE6, and encourage visitors to upgrade. But still, IE7's going to be an issue for a while yet. |
| 02:33 | <TabAtkins> | Also luckily, some of my intranet apps are purposely not being made compatible with IE7, so I can force everyone in the company to upgrade. Less people using IE7 = less people realizing that something doesn't look right in IE7, and complaining to me. |
| 02:34 | <TabAtkins> | (Well, let me rephrase that. I'm not going out of my way to make them incompatible. I'm simply not caring when I use good markup that they don't understand.) |
| 03:02 | <Hixie> | TabAtkins: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7657 |
| 03:02 | <Hixie> | TabAtkins: apparently you were ahead of yourself |
| 03:03 | <Hixie> | :-) |
| 03:03 | <TabAtkins> | Hmm? I just did that half an hour ago or so. |
| 03:03 | <Hixie> | oh, i see |
| 03:03 | <Hixie> | sorry, missed that the last comment was recent |
| 03:03 | <TabAtkins> | Hehe. |
| 03:04 | <Hixie> | i really don't understand why <div> isn't suitable for the short term |
| 03:09 | <TabAtkins> | 'cause we like being fancy, obviously. And using HTML5 to the fullest is fancy. |
| 03:11 | <othermaciej> | TabAtkins: it might be a good idea to have a bug for the IE6/IE7 parsing issue that is separate from Shelley's bug about her broad philosophical concerns about element semantics being redefined |
| 03:12 | <gsnedders> | hmm, keyboard backlight won't come on. |
| 03:12 | <othermaciej> | TabAtkins: the conditional <object> hack seems less severe to me than the issues with <legend> at least |
| 03:13 | <TabAtkins> | othermaciej: Agreed that it's lesser. But it's worse than the createElement hack. |
| 03:13 | <othermaciej> | TabAtkins: to me it would probably outweigh reluctance to add elements, but I can see that either view is reasonable |
| 03:13 | <othermaciej> | TabAtkins: sure, something you have to add at every use is worse than a one-time script |
| 03:14 | <TabAtkins> | Well, you don't have to add it at every use. It's a once-per-page think, just like the createElement hack. But it's one that can't be externalized to a <script>, which is really annoying. |
| 03:16 | <TabAtkins> | Hixie: Should I reopen the bug/create a new bug to introduce the fourth option to deal with compat issues (a @caption attribute to identify the <legend>/<details> caption)? |
| 03:16 | <othermaciej> | TabAtkins: once-per-page? |
| 03:16 | <TabAtkins> | Or should I take your response literally and decide if I want to escalate this to the chairs? |
| 03:16 | <othermaciej> | TabAtkins: anywhere in the page? |
| 03:17 | <TabAtkins> | othermaciej: Nah, somewhere in the head. Probably at the bottom of the head, but I'm not sure - I haven't done extensive testing with it. |
| 03:17 | <othermaciej> | TabAtkins: you can't document.write() it from a <script? |
| 03:17 | <othermaciej> | er, <script>? |
| 03:17 | <TabAtkins> | Oh, hm... |
| 03:17 | <TabAtkins> | Let me try. |
| 03:17 | <Hixie> | TabAtkins: per the comment i added on the other bug, if you think this should change, please escalate it to the chairs (unless of course you have new information that would affect my conclusions here) |
| 03:17 | <othermaciej> | TabAtkins: if you can, would that remove your objection, since it's no worse than the createElement() hack? |
| 03:17 | <TabAtkins> | Yes it would. |
| 03:18 | <Hixie> | as i said before, personally, i think it's fine to just use <div>s for the next few years just like the past few |
| 03:18 | <TabAtkins> | Any js-based hack that I can bundle up together into a single file is acceptable to me, as long as the perf hit is low. |
| 03:19 | <TabAtkins> | othermaciej: Any idea if you can document.write() a conditional comment? |
| 03:19 | TabAtkins | will test, but if he needs to go ahead and use a different approach already, he might as well know. |
| 03:19 | <othermaciej> | TabAtkins: I don't know, but is the conditional comment essential? couldn't the document.write be conditional based on running in old IE? |
| 03:20 | <othermaciej> | TabAtkins: I bet it would work, but you may have to split the tokens of the conditional comment into separate strings to stop IE from recognizing it as such |
| 03:20 | <TabAtkins> | Yeah it can be, but the hacks to reliably detect IE6 and 7 are sorta weird. I guess Dean Edwards's stuff works pretty well. |
| 03:20 | <othermaciej> | (same way you need to document.write "</scr" + "ipt>" |
| 03:21 | <othermaciej> | actually, in an external script it might not matter |
| 03:21 | <othermaciej> | anyway I am curious about the results |
| 03:25 | <miketaylr> | TabAtkins: do you have a link for this comment hack? haven't seen/heard of this before. |
| 03:25 | <miketaylr> | might be nice to add to Modernizr |
| 03:25 | <TabAtkins> | miketaylr: Trying to find it in the archives. One moment. |
| 03:25 | <miketaylr> | TabAtkins: ty |
| 03:28 | <TabAtkins> | miketaylr: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html |
| 03:28 | <miketaylr> | thanks, sir. |
| 03:38 | <TabAtkins> | Success! |
| 03:38 | <TabAtkins> | Conditional comments can be added via document.write(), and it does trigger the appropriate parser behavior. |
| 03:39 | <miketaylr> | nice. |
| 03:40 | <TabAtkins> | Now, the only question is if the fact that it writes a "</head>" into the document causes problems with in-head content that comes after it. |
| 03:41 | <TabAtkins> | Hmm, yes, it seems to drop <link>s on the floor that come after the script has run. |
| 03:41 | <TabAtkins> | So this has to be run as the last element in <head>. |
| 03:49 | <TabAtkins> | Well, actually, you can omit the "</head>" from the write, if you avoid putting <head> in your document at the normal place. |
| 03:50 | <TabAtkins> | Though it still drops <link>s on the floor that come after it, so there's not much of a difference I suppose. |
| 06:30 | <mpilgrim> | fun fact of the day: when served as "text/html", IE will treat the following markup as a feed: |
| 06:30 | <mpilgrim> | <!-- <rdf:RDF --> <!-- http://www.w3.org/1999/02/22-rdf-syntax-ns# --> <!-- http://purl.org/rss/1.0/ --> |
| 06:40 | Hixie | checks in an example that uses syntax that is the least pretty syntax of all the examples checked in so far |
| 06:40 | <Hixie> | othermaciej: 5c in the e-mail you sent me refers to 5c where i think it means 5d |
| 06:41 | <othermaciej> | Hixie: you are right |
| 06:43 | <Hixie> | for step 9a, it would be good if there was some way for us to record that in some way that can be easily found |
| 06:43 | <Hixie> | e.g. a keyword in the bug |
| 06:44 | <Hixie> | for 10 i don't think a keyword is needed, since i just always look at the comments from the last one i wrote to the end if a bug is open |
| 06:45 | <Hixie> | for 5c, btw, i think people might need to be given privs to do that, so maybe we should also have people checking the comments for people writing comments on resolved bugs to make sure they get reopened |
| 06:45 | <Hixie> | i've missed a few in the past that i found by luck |
| 06:45 | <othermaciej> | keyword for 9a seems good |
| 06:45 | <Hixie> | i've tried to change my filters to make sure i find more, but i might still miss some if there's no systematic solution |
| 06:45 | <Hixie> | other than that, looks good |
| 06:45 | <Hixie> | do you want e-mail reply? |
| 06:46 | <othermaciej> | for 10 I'd rather keep the keyword for WG tracking purposes, even if you can do without it |
| 06:46 | <Hixie> | k |
| 06:46 | <othermaciej> | email reply would be handy so I don't forget |
| 06:46 | <othermaciej> | since I'm about to head home |
| 06:46 | <othermaciej> | (forced myself to stay at work while I wrote this) |
| 06:48 | <Hixie> | SENT |
| 06:48 | <Hixie> | ER |
| 06:48 | <Hixie> | sent |
| 06:50 | <mpilgrim> | http://wearehugh.com/public/2009/09/rss10-sniffing.txt |
| 07:17 | <hsivonen> | what's the conflict between CORS Origin and Sec-From (if Sec-From were named Origin)? |
| 07:20 | <othermaciej> | Sec-From is now named Origin |
| 07:21 | <hsivonen> | oh |
| 07:21 | <hsivonen> | I guess the Mozilla wiki is out of date then |
| 07:22 | <othermaciej> | this is a recent occurrence |
| 07:22 | <hsivonen> | which vendors are on board? |
| 07:27 | <othermaciej> | that I don't know - I did not follow the recent discussion closely |
| 07:30 | <othermaciej> | there was a thread on public-webapps and ietf-http-wg |
| 08:30 | <mpilgrim> | http://code.google.com/p/mimesniff/ |
| 09:24 | <Hixie> | annevk2: when does 'abort' fire? |
| 09:24 | <zcorpan_> | what does opera 9.x do with <div><video style=color:red><source></video></div><p>test |
| 09:33 | <zcorpan_> | hmm no difference |
| 09:33 | <hsivonen> | hmm. why does Opera on Mac load /System/Library/TextEncodings/Unicode Encodings.bundle/Contents/MacOS/Unicode Encodings |
| 09:33 | <hsivonen> | isn't Opera supposed to have its own decoders like Firefox? |
| 09:40 | <Philip`> | mpilgrim: The project really needs a logo of a mime being sniffed |
| 09:40 | <hsivonen> | sigh. -bash: fork: Resource temporarily unavailable |
| 09:40 | <hsivonen> | I guess the OS is close to being horked |
| 09:41 | <hsivonen> | I don't even have a large number of processes |
| 09:41 | <Hixie> | do you have some process not reaping its children or something? |
| 09:41 | <zcorpan_> | dean can put the video in a <table> or a <button> for opera 9.x compat |
| 09:42 | <hsivonen> | Hixie: not as far as I can tell from the process list |
| 09:42 | <Hixie> | weird |
| 09:42 | <hsivonen> | Hixie: but Opera got horked and bounced like crazy back and forth in the Dock |
| 09:42 | <Philip`> | mpilgrim: Isn't the <BODY test entirely redundant with <B and therefore unnecessary and wasteful? |
| 09:42 | <hsivonen> | so maybe it used up a zillion pids |
| 09:42 | <hsivonen> | dunno |
| 09:43 | hsivonen | reboots |
| 09:43 | <Hixie> | Philip`: abarth is going to be changing that |
| 09:44 | <Hixie> | to look for <BODY and <B followed by a space or a > |
| 09:44 | <Hixie> | (for some definition of "space") |
| 09:44 | <Philip`> | Oh |
| 09:46 | <annevk2> | Hixie, when the user stops the loading of something I believe |
| 09:46 | <Hixie> | that's basically as vague as i got |
| 09:50 | <hsivonen> | the only part I care about is that abort doesn't emit the EOF token |
| 09:51 | <Hixie> | does not and should, or should not and does? |
| 09:51 | <hsivonen> | should not and probably does not |
| 09:52 | <Hixie> | i doubt it's especially well-defined at this point frankly |
| 09:53 | <annevk2> | in theory it can dispatch everywhere were load/error is dispatched |
| 09:53 | <hsivonen> | It just occurred to me that I've forgotten to mark scripts malformed if they are on the tree builder stack when an abort happens |
| 09:53 | <hsivonen> | in fact, now that I think about it, I have no mechanism capable of doing that sort of thing after abort |
| 09:54 | <hsivonen> | I wonder if it's possible for an onabort script to do evil things with parser-inserted but unexecuted partial script elements |
| 09:55 | <Hixie> | frankly interop for 'abort' seems not very important |
| 09:55 | <hsivonen> | I was thinking about security |
| 09:56 | <hsivonen> | but the kind of foot shooting I can imagine arising from this could be achieved by other more direct foot shooting activities |
| 09:59 | hsivonen | wonders if XCode and Terminal.app still go crazy under Snow Leopard when an app being debugged in gdb crashes |
| 10:44 | <othermaciej> | hi everyone |
| 10:45 | <Hixie> | hey |
| 10:46 | <othermaciej> | I think I need to duck out of the "resource" discussion, because the more I participate, the more confused I get about what is what |
| 10:47 | jgraham | thought he was the only one |
| 10:49 | <Hixie> | my main confusion is over what the problem is |
| 10:49 | <Hixie> | as in, what needs fixing in the spec |
| 10:51 | <zcorpan_> | Hixie: try removing some text, so that it just says "A URL is a string." |
| 10:52 | <Hixie> | i don't think that would help most authors |
| 10:53 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7726 - are we seriously considering adding a whole tokeniser state for this? |
| 10:53 | <Hixie> | two states, in fact, one for public and one for private |
| 10:54 | <Hixie> | er, system, not private |
| 10:59 | <jgraham> | Hixie: It doesn't seem like too big a deal to me |
| 11:00 | <jgraham> | To add the extra states |
| 11:00 | <Philip`> | States are cheap |
| 11:01 | <annevk2> | seems pointless to me |
| 11:02 | <annevk2> | Hixie, elemement |
| 11:02 | <annevk2> | oh, and "publicate date" |
| 11:02 | <annevk2> | time to sleep? :) |
| 11:03 | <Hixie> | noooo |
| 11:04 | <othermaciej> | Hixie: I think the spec should just make all doctypes that trigger standards mode conforming |
| 11:04 | <Hixie> | that's all unknown doctypes |
| 11:05 | <jgraham> | On an unrelated topic did I ever say that someone should implment mailing list software that limits the rate at which it accepts replies? |
| 11:05 | <Hixie> | othermaciej: you want <!DOCTYPE HTML PUBLIC "SVG"> to be conforming? |
| 11:06 | <othermaciej> | Hixie: are there any bogus doctypes that are likely to indicate an actual error by the author? |
| 11:07 | <Hixie> | define "error" |
| 11:07 | <othermaciej> | likely to indicate a typo that would affect the content in some bad or unintended way |
| 11:07 | <annevk2> | othermaciej, I think "minted" DOCTYPEs that trigger standards mode would be more slightly better |
| 11:07 | <annevk2> | s/more// |
| 11:08 | <othermaciej> | annevk2: you mean any that have ever been officially specified? |
| 11:08 | <annevk2> | yeah |
| 11:08 | <Hixie> | i don't really see any point allowing anything other than <!DOCTYPE HTML> personally |
| 11:08 | <othermaciej> | that's reasonable too |
| 11:08 | <othermaciej> | I just don't see the point in disallowing other things |
| 11:09 | <annevk2> | it makes the point that HTML is versionless stronger I think |
| 11:09 | <othermaciej> | its highly likely new content will use <!DOCTYPE html> cause it is short and memorable, and part of HTML5's branding |
| 11:09 | <annevk2> | and makes using new features in old templating systems easier |
| 11:09 | <othermaciej> | so its not like it's a huge aid to authors |
| 11:09 | <annevk2> | (while remaining conforming) |
| 11:21 | <zcorpan_> | some of the longer doctypes trigger quirks mode or limited-quirks mode, and it's non-obvious why <!doctype html public "" "" xyz> is allowed but <!doctype html public "" xyz> is not |
| 11:21 | <zcorpan_> | if all doctypes that trigger standards mode were to be allowed |
| 11:26 | <othermaciej> | ok, I see how that might be confusing |
| 11:26 | jgraham | thinks the current doctype situation is fine and far from important enough to spend more time changing |
| 11:27 | <hsivonen> | I don't like new states but we are so deep into the abyss exceeding 8000 bytecodes that I stopped caring much |
| 11:28 | <hsivonen> | besides, the solution for <!-- in JS string literal will translate to a bunch of states anyway |
| 11:28 | <Hixie> | ok i can make <!DOCTYPE HTML PUBLIC""> and <@DOCTYPE HTML SYSTEM""> trigger additional parse errors; do we also want a state to pointlessly catch the <!DOCTYPE HTML PUBLIC """"> case? |
| 11:28 | <jgraham> | I don't have a strong opinion |
| 11:29 | <hsivonen> | Hixie: were these all valid in SGML/ |
| 11:29 | <hsivonen> | ? |
| 11:29 | <hsivonen> | if they were, why do we care about XML? |
| 11:29 | <Hixie> | hsivonen: seems like you could stick the doctype parser into a separate method to avoid the 8000 byte limit, since a ton of these states are just there |
| 11:29 | <Hixie> | no idea what SGML says |
| 11:29 | <Hixie> | i don't have a copy |
| 11:30 | <hsivonen> | Hixie: anyway, if you require a space between SYSTEM and "", I think it's logical to require a space between "" and "" |
| 11:31 | <hsivonen> | notes that the Super Friends didn't notice the permitted 'sloppiness' here |
| 11:31 | zcorpan_ | thinks the Super Friends didn't read the parsing section |
| 11:32 | <Hixie> | i wonder if they'll ever send their feedback |
| 11:33 | <Hixie> | oh hey i can do the """" without a new state |
| 11:33 | <zcorpan_> | yay |
| 11:33 | <hsivonen> | Hixie: I'm planning on writing a Python or Perl munger that sticks all the doctype states in a separate method |
| 11:33 | <Hixie> | cool |
| 11:34 | <zcorpan_> | hsivonen: or you could move the doctype tokenization into the tree builder |
| 11:34 | <zcorpan_> | and have the tokenizer just act on "<!doctype", eat everything until the next ">" |
| 11:35 | <hsivonen> | zcorpan_: I'd rather not go there |
| 11:35 | <zcorpan_> | ok |
| 11:35 | <Hixie> | aw, crap, i can't after all |
| 11:36 | <Hixie> | it would make <!DOCTYPE HTML PUBLIC "" > a parse error because of the space |
| 11:36 | <hsivonen> | aside, for the tokenizer loop it would nice to have some kind of compiler pragmas that allowed me to mark sections of one huge method in a Shark-sensitive way |
| 11:36 | <hsivonen> | so that I could have distinct Shark symbols for each tokenizer state even if they are all in one method |
| 11:36 | <hsivonen> | now the tokenizer loop is just one huge black box in Shark |
| 11:37 | <hsivonen> | but then even if I discovered that a state is slow, there aren't many degrees of freedom to do anything about it |
| 11:38 | <Philip`> | Can't you get a profile showing time spent in individual lines of code? |
| 11:39 | <Philip`> | (and then write a script to sum the values within arbitrary regions) |
| 11:39 | <hsivonen> | dunno |
| 11:39 | <hsivonen> | the point is getting nice trees in Shark |
| 11:39 | <hsivonen> | not writing post-processing scripts myself |
| 11:54 | <zcorpan_> | hmm, when canvas support is disabled, should getContext('2d') throw? |
| 11:55 | <hsivonen> | zcorpan_: when would canvas support be disabled? |
| 11:55 | <Hixie> | no |
| 11:55 | <Hixie> | nobody would test for that |
| 11:55 | <zcorpan_> | hsivonen: the spec now allows it to be disabled |
| 11:55 | <annevk2> | hsivonen, when images are disabled |
| 11:55 | <hsivonen> | what's the point? |
| 11:55 | <annevk2> | at least, that'd make the most sense to me |
| 11:55 | <Hixie> | hsivonen: no idea, but opera people apparently want it |
| 11:55 | <Hixie> | and it costs us nothing |
| 11:55 | <hsivonen> | Hixie: hmmkay... |
| 11:55 | <hsivonen> | Hixie: well, it cost other browsers something if there's code to write |
| 11:56 | <zcorpan_> | i guess if people start using canvas for ads... |
| 11:56 | <Hixie> | there's no code to write |
| 11:56 | <annevk2> | hsivonen, such disabling features are not required |
| 11:58 | zcorpan_ | wonders whether Hixie detects opera people from their IP in the bugs |
| 11:59 | <hsivonen> | zcorpan_: you should use Tor to file bugs :-) |
| 12:00 | <Hixie> | i detect them by their suggesting of features that would only make sense if the UA had poor UI :-P |
| 12:01 | <hsivonen> | I guess disabling <canvas> rendering makes some sense in the VoiceOver world where you'd want low-vision users (or sighted people assisting a blind user) see the VO focus |
| 12:01 | <zcorpan_> | hsivonen: i didn't file the bug |
| 12:02 | <zcorpan_> | i wonder why Julian reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=7726 |
| 12:02 | <hsivonen> | in the world where canvas descendants are the AT-exposed alternative |
| 12:07 | <Hixie> | woo, Zarro Boogs |
| 12:07 | <hsivonen> | excellent! |
| 12:08 | <Hixie> | now if i can keep it below 10 for another 3 days, that's a 1.0 on my "get bugs below 10" OKR |
| 12:08 | <hsivonen> | OKR? |
| 12:08 | <Hixie> | Objective and Key Result |
| 12:08 | <Hixie> | how google does quarterly goals |
| 12:09 | zcorpan_ | plans to file 10 bugs while Hixie is asleep |
| 12:09 | <jgraham> | zcorpan_: Only do that if you want a new status "resolved: Invalid (filed by opera employee)" |
| 12:09 | <Hixie> | hah |
| 12:10 | <zcorpan_> | heh |
| 12:11 | <hsivonen> | speaking of quarterly goals, I can has off-the-main-thread parsing! |
| 12:11 | <hsivonen> | woohoo! |
| 12:11 | <hsivonen> | cnn.com broken but simpler pages work |
| 12:20 | <othermaciej> | I'm glad I don't have a quarterly goal to get the issue count below any particular number |
| 12:20 | <othermaciej> | (other than of the purely personal sort) |
| 12:22 | <Hixie> | i set this goal myself :-) |
| 12:22 | <Hixie> | okrs are self-assigned |
| 12:24 | <Hixie> | anyone know how <applet> works? |
| 12:25 | <zcorpan_> | i know that <applet> is annoying |
| 12:26 | <annevk2> | I once had the noble idea of finding out but then couldn't find the Java stuff I needed and dropped the idea |
| 12:26 | <zcorpan_> | it always instantiates the java plugin, but i guess that could be optimized away if there's no code="" and no <param>s or something |
| 12:27 | <Hixie> | any idea what it does after instantiating java? |
| 12:28 | <othermaciej> | runs the specified applet |
| 12:28 | <zcorpan_> | i think it's pretty much the same as <object type=application/x-java-applet>, except it doesn't fall back |
| 12:29 | <zcorpan_> | but i haven't tested it much |
| 12:29 | <Hixie> | does codebase="" actually work with it? |
| 12:29 | <othermaciej> | and passes the param values to the applet |
| 12:30 | <zcorpan_> | i think codebase="" and <param name=codebase> might be the same |
| 12:30 | <zcorpan_> | but haven't tested! |
| 12:30 | <zcorpan_> | or i have but don't remember |
| 12:33 | <Hixie> | does the browser do any fetching of any kind? |
| 12:33 | <Hixie> | for applets? |
| 12:34 | <othermaciej> | by "the browser" do you mean as distinct from the Java plugin doing it? |
| 12:34 | <othermaciej> | cause obviously someone is loading the applet at some point |
| 12:34 | <Hixie> | yes |
| 12:34 | <Hixie> | my real question is, do the browsers get to add the Origin header, or does Sun |
| 12:36 | <othermaciej> | I don't think all browsers interface <applet> to a Java implementation in the same way, so I am not sure if there is a single answer |
| 12:37 | <Hixie> | k |
| 12:37 | <Hixie> | hm, crap |
| 12:37 | <Hixie> | next thing on my list is the indexes |
| 12:37 | <Hixie> | i was hoping those would do themselves somehow |
| 12:38 | <annevk2> | I looked into it but it wasn't that simple |
| 12:38 | <annevk2> | it's not even easy to get a single list of elements extracted from the spec |
| 12:38 | <Hixie> | yeah |
| 12:38 | <annevk2> | let alone also getting their metadata |
| 12:38 | <annevk2> | you should add some annotations maybe |
| 12:38 | <zcorpan_> | you should use microdata |
| 12:38 | <Hixie> | i guess i'll spec microdata then use that, yeah |
| 12:39 | <jgraham> | Hmm isn't the spec supposed to be valid HTML4? |
| 12:39 | <jgraham> | Or did W3C see sense? |
| 12:39 | <Hixie> | only for w3c |
| 12:39 | <Hixie> | i can strip all this stuff out before it goes to w3c |
| 12:39 | <jgraham> | Cunning |
| 12:39 | <zcorpan_> | or you can convert it into valid HTML4+RDFa for w3c |
| 12:40 | <Hixie> | i don't think that passes their pubrules either |
| 12:41 | <zcorpan_> | snap |
| 12:42 | <annevk2> | hmm yeah, what is itemtype Hixie? |
| 12:43 | <Hixie> | same as item="" today |
| 12:43 | <Hixie> | http://damowmow.com/playground/microdata/004/introduction |
| 12:43 | <annevk2> | oh, I thought that turned into itemscope |
| 12:47 | <Hixie> | it also did |
| 12:47 | <Hixie> | it got split in two |
| 12:47 | <Hixie> | value goes into itemtype="" |
| 12:47 | <Hixie> | ok i really should go to sleep |
| 12:47 | <Hixie> | nn |
| 12:48 | jgraham | discovers someone who has wrapped almost their entire ecmascript game in a "with" block |
| 12:49 | <annevk2> | Hixie, nn, and also, weak |
| 12:49 | <annevk2> | jgraham, don't let TC39 hear it |
| 12:51 | <jgraham> | annevk2: It is almost enough to make *me* cry. I hate to think how TC39 would react... |
| 12:52 | <othermaciej> | that's a great way to make the whole thing run very slowly |
| 12:52 | <hsivonen> | is 'with' JIT poison? |
| 12:52 | <othermaciej> | worse than that |
| 12:53 | <othermaciej> | actually wrapping all the code with a "with" might be less bad than using "with" in an inner loop |
| 12:53 | <othermaciej> | it prevents mapping identifiers to variable slots at "compile" time (where "compile" might mean just to bytecode) |
| 12:54 | <mpilgrim_> | Philip`: possibly (<body vs <b). i think there was discussion of removing the <b test in draft-02 |
| 12:57 | <mpilgrim> | oh look, draft-02 is already out |
| 12:57 | <mpilgrim> | i guess i mean draft-03 then |
| 12:59 | <annevk2> | I guess I should review abarth's drafts |
| 13:00 | <annevk2> | there's a mime-sniff 3? |
| 13:00 | <annevk2> | annoying that tools.ietf.org always lags a bit behind |
| 13:00 | <annevk2> | it's by far the most useful interface for IETF stuff |
| 13:02 | <annevk2> | Adam has like 6 different email addresses |
| 13:10 | <mpilgrim> | he just published draft-02 today |
| 13:10 | <mpilgrim> | but it doesn't include the new algorithm i wrote to detect RSS1.0-served-as-text/html |
| 13:11 | <mpilgrim> | and it doesn't change the sniffing of "<b", which he was discussing with me off-list |
| 13:14 | <annevk2> | it would be nice if the IETF switched to something like dev.w3.org instead of this versioned drafts stuff |
| 13:15 | <annevk2> | especially when in development this is really cumbersome model |
| 13:16 | <mpilgrim> | that, and upgrading to UTF-8, and they'd be all set to enter the 1990s |
| 13:20 | <annevk2> | yeah, tools.ietf.org makes the text-only crap somewhat more acceptable, though it's not great (but a lot better than the default HTML some people generate themselves (presumably with XSLT or some such from the source XML) |
| 13:38 | <zcorpan_> | actually, importScripts() already ignores the specified encoding if i'm reading the spec correctly |
| 13:39 | <zcorpan_> | it uses the same encoding as the worker |
| 13:43 | annevk2 | looks |
| 13:44 | <annevk2> | I think you found a spec bug |
| 13:44 | <annevk2> | cause step 1 and 2 there are contradictory |
| 13:44 | <annevk2> | actually |
| 13:44 | <annevk2> | maybe not |
| 13:45 | <zcorpan_> | oh does step 2 refer to URL character encoding? |
| 13:45 | <annevk2> | I think so |
| 13:46 | <annevk2> | yes, see 6.5.3.3 |
| 13:46 | <annevk2> | could be clearer though |
| 14:28 | <jgraham> | Lachy: Selectors v2 is much clearer now, thanks |
| 14:28 | <Lachy> | :-) |
| 14:43 | <zcorpan_> | Lachy: isn't 'module dom' implied? |
| 14:45 | <Lachy> | maybe it is now. It wasn't at the time they were added to the spec. |
| 14:45 | <Lachy> | I was meaning to check on that |
| 14:48 | <annevk2> | Lachy, your use of Supplemental seems wrong |
| 14:48 | <annevk2> | for the first interface |
| 14:54 | <Lachy> | annevk2, no it's not. It's the same way that HTML5 uses it in many cases |
| 14:57 | <zcorpan_> | i don't understand what the difference is between [Supplemental, NoInterfaceObject] interface A { a } B implements A; and [NoInterfaceObject] interface A { a } B implements A; |
| 14:57 | <zcorpan_> | is B.prototype different for the two cases? |
| 14:59 | <annevk2> | Lachy, how? |
| 14:59 | <annevk2> | Lachy, Supplemental means the interface is defined somewhere else and you define some additions |
| 14:59 | <annevk2> | Lachy, for NodeSelector at least you are defining the interface right there |
| 15:00 | <zcorpan_> | annevk2: Supplemental can be used in three different ways apparently |
| 15:00 | <annevk2> | for Element it does seem appropriate |
| 15:01 | <annevk2> | zcorpan_, I only know about splitting interfaces |
| 15:01 | <annevk2> | zcorpan_, and that is not what is happening here |
| 15:01 | <annevk2> | (per http://dev.w3.org/2006/webapi/WebIDL/#es-extended-attributes ) |
| 15:02 | <Lachy> | annevk2, Hixie explained it to me a few days ago. I'll see if I can find the link... |
| 15:03 | <zcorpan_> | web workers uses supplemental the same way as nodeselector |
| 15:04 | <Lachy> | http://krijnhoetmer.nl/irc-logs/whatwg/20090925#l-110 |
| 15:07 | zcorpan_ | is still slightly confoosed |
| 15:08 | <zcorpan_> | A.b doesn't exist? |
| 15:08 | <zcorpan_> | objects implementing A will have b, right? |
| 15:09 | <zcorpan_> | but A.prototype.b is undefined? |
| 15:09 | <Lachy> | yes |
| 15:10 | <zcorpan_> | ok |
| 15:10 | <zcorpan_> | i guess i should test that the prototypes have the right things for workers |
| 15:12 | <annevk2> | wtf |
| 15:14 | <annevk2> | that's very confusing stuff |
| 15:15 | <zcorpan_> | indeed |
| 15:16 | <annevk2> | I don't quite understand why implements does not put it on the prototype chain but I guess it makes sense somehow |
| 15:17 | jgraham | wonders how much the prototype stuff matches reality |
| 16:08 | <heycam> | jgraham, the prototype stuff doesn't really match reality |
| 16:08 | <heycam> | better solutions welcome |
| 16:08 | <heycam> | i suspect the TC 39 people will have opinions on the best way to map mixins/multiple inheritance to the single inheritance prototype chain |
| 16:08 | <heycam> | also, [Supplemental] isn't defined in web idl (yet) |
| 16:09 | <heycam> | i'm still not sure i like its intended use (basically like partial classes in c# or something, i think) |
| 16:20 | annevk2 | is on his way to file 10 new bugs |
| 16:20 | <annevk2> | all legit though :) |
| 16:27 | annodomini | didn't realize that Anne was a he |
| 16:29 | <annevk2> | heh, you're not the first :) |
| 16:29 | <annodomini> | I guess that's what I get for assuming gender based on someone's name across cultures. |
| 16:30 | <jgraham> | annodomini: To be fair it works most of the time |
| 16:31 | <annodomini> | True. Though I should do better about it, as I am dating a woman named Kevan. |
| 16:31 | <Lachy> | annevk2, would you find it more acceptable if I removed step 4 from this http://dev.w3.org/2006/webapi/selectors-api2/#parsing-a-scoped-selector |
| 16:31 | <jgraham> | Obviously Anne just needs to be more aggressive and macho in public to assert his masculinity |
| 16:31 | <jgraham> | ;) |
| 16:32 | <Lachy> | so that authors can still do queryScopedSelector("div div") and have it be equivalent to :reference div div, but then have to do queryScopedSelector(":reference+p") or equivalent to use any other combinator? |
| 16:33 | <Lachy> | though, that wouldn't be ideal since it would significantly, though not entirely, decrease the value of having the new methods |
| 16:33 | <annevk2> | somewhat, though I don't really like the idea of having additional methods to start with |
| 16:34 | <Lachy> | that's why I tried to find a solution without new methods before. But then people bitched about adding a flag and special selector parsing, which I still think are bogus arguments |
| 16:34 | <TabAtkins> | No, we bitched about having a special flag that you only needed in a single instance, and that would often still return the right results when you omitted it in test cases. |
| 16:35 | <TabAtkins> | I'm still generally okay with the flag. (Also, I think you pitched it as "here's a special form of the descendant combinator", when really it's "here's a flag you need to use if your first selector opens with the descendant combinator"). |
| 16:35 | <TabAtkins> | (Which seems to have annoyed fantasai.) |
| 16:35 | <Lachy> | TabAtkins, you said you would have preferred to always require the syntactic flag to be used for scoped selectors, but still preferred new methods over that. Other people, including annevk2, are bitching about messing with the selector parsing |
| 16:35 | annevk2 | starts to wonder how other people implemented appcache |
| 16:35 | <annevk2> | it's full of holes |
| 16:36 | <Lachy> | I didn't intend to pitch it as a special descendant combinator. It was always a global flag that could be used for any scoped selector, but could be omitted when it was redundant |
| 16:36 | <TabAtkins> | Lachy: Hmm, why is :reference needed at all if you're doing a special method? |
| 16:37 | <TabAtkins> | Lachy: Yeah, I get that, but it *really* looked like you were intending it as a special descendant combinator in your original email. |
| 16:37 | <Lachy> | what do you mean? |
| 16:37 | <TabAtkins> | Lachy: In what circumstances is :reference ever needed if you have queryScopedSelector()? |
| 16:37 | jgraham | officially has no opinion on Selectors but wonders why querySelectorAll(selector, {"scope":true, "namespaces":{/*some namespace map*/}) wouldn't be a good API |
| 16:37 | <jgraham> | +} |
| 16:39 | <hsivonen> | jgraham: if the map can have arbitrary JS getters, it would have all the same problems as XPath NSResolver |
| 16:39 | <annevk2> | jgraham, namespaces are evil? |
| 16:39 | <Lachy> | in many cases, like document.querySelectorAll(".foo:reference", list) to filter a node list, or document.querySelectorAll("h1+p:reference>span", list), which is equivalent to running elm.querySelectorAll("h1+p:reference>span") on each element in the list. |
| 16:39 | <annevk2> | jgraham, also, no other API is like that |
| 16:39 | <hsivonen> | jgraham: in terms of protecting engine state from JS-caused changes |
| 16:39 | <jgraham> | hsivonen: You could define it to run all the getters once at the start |
| 16:39 | <jgraham> | or, as Hixie put it "structured clone" |
| 16:40 | <Lachy> | the latter basically does filtering and node list selection in one go |
| 16:40 | <jgraham> | (or .toJSON I guess) |
| 16:40 | <jgraham> | annevk2: I was assuming namespaces as a requirement not supporting them philosophically |
| 16:40 | <TabAtkins> | Lachy: Okay, I see its use in the latter case, though question if it might not be easier to run simply by speccing an appropriate behavior on NodeLists. The former, though, seems like a hack for filterSelector. |
| 16:40 | <jgraham> | I agree that no other API is like that |
| 16:41 | <jgraham> | It's a pity becuase it is the obvious way to define extensible APIs in javascript |
| 16:41 | <Lachy> | jgraham, using {"scope":true, ...} wouldn't work because it provides absolutely no detectable way for scripts to know if it's supported or not. |
| 16:41 | <jgraham> | (insofar as javascrip has an obvious way to do that) |
| 16:41 | hsivonen | mumbles about hard-wiring svg:, html:, math: and xbl: |
| 16:42 | <Lachy> | TabAtkins, it saves introducing a new method just for filtering, which would be completely redundant |
| 16:43 | <TabAtkins> | I think that's a worthwhile method to add. |
| 16:43 | <Lachy> | why? |
| 16:43 | <jgraham> | Lachy: Hmm. querySelectorAll.hasFeature("scope")? |
| 16:43 | jgraham | jokes |
| 16:43 | <Lachy> | haha |
| 16:43 | <TabAtkins> | Because it's better to be explicit about "I need to filter this list of nodes according to this selector" rather than having to remember the idiom for using querySelectorAll to do the same. |
| 16:44 | TabAtkins | comes from a programming tradition that always emphasizes new functions over overloading via idiom. |
| 16:45 | <Lachy> | TabAtkins, there weren't really any significant use cases for filtering provided anyway. That basically came as a freebie when i addressed the other use cases for querySelector on node lists. |
| 16:45 | <TabAtkins> | Hmm? No significant uses? Every use of $().filter() in jQuery is a use-case. |
| 16:46 | jgraham | tends to agree that filtering a NodeList of selectors seems nicest by using a method on NodeList |
| 16:46 | <TabAtkins> | Sorry if it sounds like I'm advocating "just dump jQuery into js". ^_^ |
| 16:46 | <jgraham> | s/of selectos/of Nodes/ |
| 16:46 | <Lachy> | TabAtkins, they weren't provided |
| 16:47 | <Lachy> | also NodeList.filterSelector() doesn't address the use cases where all you have is an Array |
| 16:47 | <TabAtkins> | Lachy: I don't particularly think they'd've had to be, but okay. Notice, though, that your use of :reference is requiring hacks around it. |
| 16:48 | <TabAtkins> | Lachy: Yeah, but there are other ways to address mapping a function over an Array. |
| 16:48 | <Lachy> | with the :reference technique, it doesn't matter what format your collection is in. Just pass it as the refNodes parameter to querySelectorAll() and it will work. |
| 16:49 | <TabAtkins> | Well, assuming that querySelectorAll recognizes your format. |
| 16:49 | <jgraham> | I guess Array.prototype.filter.call(ArrayLike, function(e) {return e.matchesSelector(s)}) will always work |
| 16:49 | <jgraham> | for filtering |
| 16:50 | TabAtkins | thinks that this might be the wrong place to solve the "JS has too many types of collections" problem. |
| 16:50 | <Lachy> | I defined it to recognise NodeList, HTMLCollection, Array and objects with indexable properties (though I think I may need to clarify the latter somehow). Basically, any object that can be enumerated to obtain Element nodes from |
| 16:51 | <jgraham> | But not for getting the tree-ordered-union of the matches to a selector using each element in ArrayLike as the contextNode |
| 16:51 | <TabAtkins> | jgraham: Yeah, but converting Array->NodeList would be fine there. |
| 16:51 | <Lachy> | jgraham, yeah, the :reference technique also gives you the tree ordered result set as a bonus |
| 16:52 | <Lachy> | TabAtkins, converting Array to NodeList is out of scope of Selectors API, and the use cases have been addressed much more elegantly already anyway |
| 16:52 | <jgraham> | TabAtkins: Is it possible to convert Array->NodeList? |
| 16:52 | <jgraham> | Also, where is "there"? |
| 16:53 | <Lachy> | jgraham, not yet. The functionality was requested in selectors api discussions |
| 16:53 | <TabAtkins> | Lachy: Grah, I know. This is one of those forest-for-the-trees things, though. You're solving the problem of "JS has too many collections" yourself, but your solution isn't ideal, and everyone else still has to solve the same problem over again later. It makes me sad. |
| 16:53 | <jgraham> | Why? |
| 16:54 | jgraham | tends to agree with TabAtkins |
| 16:54 | <jgraham> | (the why> was aimed at Lachy) |
| 16:54 | <Lachy> | jgraham, do you mean why is converting Array to NodeList out of scope? |
| 16:55 | <Lachy> | or something else? |
| 16:55 | <jgraham> | (and it's more like "DOM has too many collections and JS has no way of treating them all equally) |
| 16:55 | <zcorpan_> | Lachy: time for food btw? |
| 16:55 | <Lachy> | zcorpan_, sure |
| 16:55 | <zcorpan_> | Lachy: my card is working now |
| 16:55 | <jgraham> | Lachy: No, why do people want it? |
| 16:55 | <Lachy> | cool |
| 16:55 | <zcorpan_> | or it should be |
| 16:55 | <zcorpan_> | Lachy: you're still at the office? |
| 16:55 | <TabAtkins> | jgraham: Apparently, so we can coerce things into a single reasonable collection type and just deal with that. |
| 16:56 | <jgraham> | Oh, but NodeLists are the most unreasonable collection type... |
| 16:56 | <TabAtkins> | Then do NodeList->Array, and define it over Arrays. Same diff. |
| 16:56 | <jgraham> | (or Array-like type anyway) |
| 16:56 | <Lachy> | oh, they wanted it to address this case, so they could have NodeList.filterSelector() and have an easy way to make a NodeList out of any collection, since JS libraries tend to store things as arrays |
| 16:57 | <jgraham> | I think people should carefully consider the effect of ES5 array extras before deciding that it is necessary to do explicit conversions to NodeLists all the time |
| 16:57 | <Lachy> | it would have signicantly improved the situation if NodeList was binded to Array in JS, which would have worked if only NodeLists were static from the start |
| 16:59 | <Lachy> | personally, I think it's much more useful to define NodeList.toArray() natively, so authors don't have to deal with liveness issues and the inflexibility of NodeLists for pretty much anything |
| 16:59 | <jgraham> | That seems reasonable. |
| 16:59 | <TabAtkins> | Can we do that? That would be great. |
| 17:00 | <jgraham> | Seems like it should be Web DOM Core rather than Selectors API that does it though |
| 17:01 | <jgraham> | (not that we should block progress on that) |
| 17:01 | <TabAtkins> | So lets get it going. Today. Right now. |
| 17:01 | <Dashiva> | Don't we have the equivalent already? |
| 17:02 | <Lachy> | TabAtkins, yeah, that functinality has been floating around for going into Web DOM Core for a while. If I'm not mistaken, I think gsnedders is editing that spec now, who took over from zcorpan_ |
| 17:03 | <jgraham> | Lachy: You might be mistaken, I don't think he has committed to it |
| 17:03 | <jgraham> | Danm |
| 17:03 | <jgraham> | Or some transposition of that anyway |
| 17:03 | <Dashiva> | Array.prototype.slice.call(nodelist, 0) or some similar invocation |
| 17:04 | <jgraham> | Dashiva: Yead that would work |
| 17:04 | <TabAtkins> | Now just make it non-sucky in syntax. |
| 17:04 | <Dashiva> | Well, it seems like an even more general solution would be to create an Array method that takes an Array-like and gives out an Array |
| 17:05 | <TabAtkins> | Yup. Anything with a .length and is indexable should work. |
| 17:05 | <Dashiva> | Which is really what all these do |
| 17:06 | <jgraham> | Array.toArray(object) would be kind of odd |
| 17:06 | <hsivonen> | is new Array(indexable) already reserved for something else? |
| 17:06 | <TabAtkins> | Array.fromArraylike(object) |
| 17:07 | TabAtkins | suspects that his text editor is adding BOMs to his UTF8 files now. |
| 17:07 | <Dashiva> | hsivonen: new Array(object) is already used |
| 17:07 | <jgraham> | hsivonen: It might work as long as indexable doesn't have a valueOf or toString that can be converted to a number iirc |
| 17:08 | <Dashiva> | It's identical to [object] |
| 17:08 | <Dashiva> | Unless the object is a number, in which case it's [] with length=the number |
| 17:08 | <hsivonen> | Dashiva: :-( |
| 17:09 | <jgraham> | Oh, yeah it seems my memory was wrong |
| 17:13 | <TabAtkins> | Hrm. What sort of craziness would justify having EF+BB+BF at the start of a file? |
| 17:14 | <Philip`> | Sounds quite like a BOM |
| 17:15 | <TabAtkins> | Yeah, it's some kind of BOM. But it's not EF+FF, like I would expect. |
| 17:15 | <Philip`> | Sounds quite like a UTF-8 BOM |
| 17:15 | TabAtkins | should remember that UTF-8 is gloriously crazy in how it encodes things. |
| 17:15 | <TabAtkins> | kk, time to change the preferences of my text editor then. |
| 17:16 | <TabAtkins> | Ah, there's the offending setting. |
| 17:16 | <Philip`> | TabAtkins: Try something like http://rishida.net/scripts/uniview/conversion to convert U+FEFF into UTF-8 code units or vice versa |
| 17:17 | <TabAtkins> | I'm good now, Philip`. |
| 17:18 | <Philip`> | If you expected it to be something like FE+FF, how would you expect UTF-8 to be distinguished from UTF-16BE? |
| 17:18 | <Philip`> | Oh, you said EF+FF instead |
| 17:18 | <Philip`> | I have no idea how you'd expect that :-p |
| 17:18 | <TabAtkins> | Man, I dunno. |
| 22:34 | <Dashiva> | I feel it's time for another complaint about the lack of awesome lastweek posts |
| 22:35 | <jgraham> | You just want to be featured more |
| 22:35 | <Dashiva> | I have lots of features, thankyouverymuch |
| 22:45 | <TabAtkins> | Dashiva, who are you on the lists? |
| 22:48 | <Dashiva> | I rarely post nowadays |
| 23:27 | <Dashiva> | Reading public-html brings back memories of my own back-and-forth with Roy about apache content types. |
| 23:34 | <hober> | I think it's very much worth reclaiming "URL," so I'm all for that part of the argument, but I could care less about "resource v. representation" |
| 23:34 | <TabAtkins> | Agreed exactly. |
| 23:36 | <TabAtkins> | (which is why I got into it over URLs, but have ignored the main resource discussion) |
| 23:54 | <Hixie> | i am definitely not getting all my e-mails |
| 23:54 | <Hixie> | i keep finding e-mails that get lost between gmail's forwarding it to me and my receiving it at dreamhost |
| 23:55 | <a-ja> | ixie: minor typo in chg 4041....says publicate instead of publication |
| 23:56 | <a-ja> | Hixie: minor typo in chg 4041....says publicate instead of publication |
| 23:56 | <Hixie> | already fixed |
| 23:56 | <a-ja> | cool |
| 23:58 | <a-ja> | are details/figure dt/dd stuff headed for w3c validator soonish? |
| 23:58 | <Hixie> | dunno, you'd have to ask the w3c |
| 23:58 | <Hixie> | validator.nu will probably have them sooner, if not already |