| 01:22 | <roc> | annevk: what codecs does Gears support? |
| 01:25 | <annevk> | for Audio? dunno |
| 01:25 | <annevk> | ah, http://code.google.com/p/gears/wiki/AudioAPI says WAV and OGG |
| 01:25 | <annevk> | and that there's no clear plan for MP3 |
| 01:38 | <annevk> | Hixie, Workers is going into HTML5? |
| 01:47 | annevk | -> bed |
| 02:04 | <roc> | er |
| 02:04 | <roc> | Ogg "pending discussion about patent and license issues" |
| 02:04 | <roc> | hahaha |
| 02:12 | <annevk> | since I'm still awake, I thought Ogg Vorbis at least was shipped with the XBox et all and therefore "safe" |
| 02:51 | <MikeSmith> | maybe it would be good to have a validator.nu mirror on html5.org .. v.html5.org |
| 03:56 | <Hixie> | annevk: either in html5 or a separate spec |
| 03:56 | <Hixie> | it isn't clear what is best for workers |
| 03:56 | <Hixie> | on the one hand, workers need to tightly integrate with much of html5, and an extra spec is a lot of overhead |
| 03:56 | <Hixie> | on the other hand, workers are a separate feature and adding making html5 bigger isn't going to be popular |
| 04:12 | <othermaciej> | my biggest worry about a separate spec is that we'd get lots of complaints (and attempted process blockage) about the inevitable HTML5 dependencies |
| 04:12 | <othermaciej> | I am ok with a separate spec if we have buy-in that such dependencies are acceptable |
| 04:14 | <Hixie> | i get the feeling this is complicated enough material that bikeshedding won't be an issue |
| 07:16 | <annevk> | I'd prefer a separate document, but I don't feel strongly about it |
| 07:21 | <MikeSmith> | I think Workers as a separate doc would make our lives easier |
| 07:22 | <MikeSmith> | And I'd certainly be willing to run cover on dealing with complaints about the HTML5 dependencies for it, and any process-blocking attempts |
| 07:24 | <MikeSmith> | as far as I can see, UA implementors seem to pretty much universally agree that having a standard workers spec would be great |
| 07:26 | <annevk> | I guess the main problem is that it bolds on top of postMessage in part, and also builds on top of Window |
| 07:27 | <MikeSmith> | yeah, but those kinds of dependencies on HTML5 are going to be true of any major feature that's introduced that has any implementation impact on UAs |
| 07:27 | <MikeSmith> | meaning pretty much everything |
| 07:27 | <Hixie> | ok |
| 07:27 | <Hixie> | so, separate doc it is |
| 07:27 | <MikeSmith> | impossible to get around that since HTML5 is defining many infrastructure details that have never been defined before |
| 07:28 | <Hixie> | how do people like "Web Threads" |
| 07:28 | <annevk> | I guess that's true, but from what I've seen of Workers it seems worse than for XMLHttpRequest, for instance |
| 07:28 | <annevk> | Hixie, hehe, fine by me :) |
| 07:30 | <MikeSmith> | Hixie: "Web Threads" seems nice and simple to me.. and consistent with current trends (Web IDL, Web Sockets) |
| 07:33 | Hixie | wonders how to set this up so he can still use his spec development toolchain |
| 07:36 | <Hixie> | i guess i don't need the stuff to handle large files |
| 07:37 | <Hixie> | nor do i need the status annotation stuff |
| 07:37 | <Hixie> | and i can use the same issues system |
| 07:38 | <othermaciej> | Hixie: I would rather it use Workers instead of Threads in the name |
| 07:39 | <othermaciej> | Hixie: since they may not be implemented as threads |
| 07:39 | <othermaciej> | and it would be bad to bias the name |
| 07:39 | <Hixie> | Web Workers? |
| 07:39 | <Hixie> | that works too |
| 07:39 | <othermaciej> | also to some people Thread may imply shared memory, while these are shared-nothing |
| 07:39 | <othermaciej> | (w/ message passing) |
| 07:39 | <othermaciej> | or just Workers, though I don't mind the Web prefix |
| 07:40 | <Hixie> | if i work on it, it has the Web prefix. :-) |
| 07:40 | MikeSmith | is less enthusiastic about "Web Workers", because of it already meaning something else |
| 07:41 | <Hixie> | Web Worker Threads? :-) |
| 07:41 | <annevk> | "web workers" only has ~52k hits on Google |
| 07:41 | <Hixie> | what does Web Workers mean? |
| 07:41 | <Dashiva> | Could always drag out SPMD or some other acronym :) |
| 07:42 | <annevk> | Hixie, it's about people making money on the Web, it seems |
| 07:42 | <MikeSmith> | here in Japan it's used a lot to describe people who do Web-related work -- Web designers and developers |
| 07:42 | <othermaciej> | Web WorkQueues? |
| 07:42 | <MikeSmith> | but then a lot of people I meet here have business cards that say "Markup Engineer" |
| 07:42 | <annevk> | Hixie, so it seems there's not much of a clash if you use it to describe a threading technology |
| 07:43 | <Hixie> | "Web Workqueue" has no hits on google |
| 07:43 | <Hixie> | but i don't know if that's better than web workers |
| 07:44 | <Dashiva> | Maybe webapp or web application instead of web? |
| 07:44 | <Hixie> | i'll just use Web Workers |
| 07:44 | <Hixie> | we can always change the exact name later |
| 07:44 | <Hixie> | doesn't matter what the directory is called really |
| 07:44 | <annevk> | (workqueue is annoying to spell) |
| 07:44 | <Hixie> | i mean html5 still says "webapps" |
| 07:45 | <Hixie> | anne: but it has the shortname "wwq" |
| 07:45 | <othermaciej> | you can be silly and call it workq |
| 07:45 | <Hixie> | ew |
| 07:45 | <othermaciej> | though that has the downside of looking like a typo |
| 07:45 | <othermaciej> | I think worker is a fine name though |
| 07:45 | <Dashiva> | Webqueues |
| 07:46 | <MikeSmith> | I think it's likely that we're going to most often keep calling them just "workers" anyway, whatever the documented name is |
| 07:46 | <Hixie> | yep |
| 07:50 | <annevk> | othermaciej, I'm pretty sure we decided against double GET on day 3 |
| 07:50 | <annevk> | othermaciej, like 99% certain |
| 07:51 | <othermaciej> | annevk: I don't think so - we agreed that would be good conditional on Microsoft committing to using the protocol profile |
| 07:51 | <othermaciej> | (and that was not even a formal RESOLUTION afaik) |
| 07:52 | <Hixie> | yet another reasons f2fs aren't any good -- you don't know what you agreed to |
| 07:52 | <othermaciej> | prior to that, we resolved to use the double-GET approach on the assumption that there was no way MS would change for IE8 |
| 07:52 | <Hixie> | s/you don't/one doesn't/ |
| 07:53 | <othermaciej> | currently we are waiting on their answer, though I believe Sunava has gone past his self-imposed deadline |
| 07:53 | <Hixie> | SHOCKING |
| 07:53 | <annevk> | othermaciej, you're indeed correct |
| 07:53 | <annevk> | per http://www.w3.org/2008/07/03-wam-minutes (W3C Member only) that is |
| 07:54 | <MikeSmith> | time for me or shepazu to ping Sunava about it, I guess |
| 07:54 | <annevk> | what's currently specified assumes a positive reply from MS; we'll see |
| 07:55 | <MikeSmith> | I thought the agreement was that we recognized we needed to move on regardless of whether we got a response from them or not |
| 07:55 | <othermaciej> | that is a generous assumption |
| 07:55 | <othermaciej> | I think our plan was not to change from the day 2 resolution until we got a response |
| 07:55 | <othermaciej> | at least that was my understanding |
| 07:55 | <MikeSmith> | OK |
| 07:55 | <Hixie> | me too |
| 07:55 | <MikeSmith> | yeah, that's what I was trying to say too |
| 07:56 | <annevk> | othermaciej, my understanding was also that I would draft the profile thing they could use before the end of this week |
| 07:56 | <othermaciej> | annevk: yeah, so maybe we need both versions drafted |
| 07:56 | <annevk> | othermaciej, and since the profile thing and not doing double GET goes hand in hand, I did that |
| 07:57 | <annevk> | othermaciej, hmm, yeah |
| 08:02 | <Hixie> | you'll likely have to write the other one anyway |
| 08:03 | <Hixie> | might as well write it and provide the two revisions as separate links to the wg |
| 08:03 | <Hixie> | it's easy to switch from one rev to another |
| 08:16 | <Hixie> | where on the mess that is dev.w3.org should this web-workers spec go? |
| 08:17 | <Hixie> | html5/web-workers? |
| 08:17 | <Hixie> | webapps/workers ? |
| 08:18 | <MikeSmith> | Hixie: either. we can move/renames it on the cvs server side later if needed |
| 08:18 | <Hixie> | k |
| 08:18 | <annevk> | (the last one makes more sense to me) |
| 08:18 | <Hixie> | html5/workers it is |
| 08:19 | <Hixie> | i'd use /webapps/ but i don't want to mint yet another root directory |
| 08:19 | <annevk> | fair enough |
| 08:19 | <Hixie> | i think i've minted two on that server already |
| 08:21 | <Hixie> | hey mike |
| 08:21 | <Hixie> | did anything ever come of that thing with rigo? |
| 08:22 | <Hixie> | i still plan to publish in august |
| 08:22 | <Hixie> | which is fast approaching |
| 08:28 | <MikeSmith> | Hixie: I've not gotten any resolution with Rigo about it |
| 08:29 | <MikeSmith> | I do realize we're going to need to before we publish the next WD |
| 08:30 | <annevk> | pointer? |
| 08:31 | <Hixie> | i don't think it was ever archived somewhere public |
| 08:31 | <annevk> | k, guess I sort of know what it is about |
| 08:31 | <Hixie> | not that anyone should take this as evidence that the w3c isn't fully open |
| 08:31 | <Hixie> | the other thing is the xhtml2wg's problem with the relationshiup to xhtml1 section |
| 08:31 | <Hixie> | which they haven't gotten back to us about |
| 08:32 | <Hixie> | i guess we just publish as is if they haven't gotten back to us |
| 08:33 | <Hixie> | maybe we should let them know that we plan to publish in august |
| 08:33 | <Hixie> | so they don't blame us for being too fast or something |
| 08:34 | <annevk> | seems they're working on something |
| 08:34 | <Hixie> | oh? |
| 08:34 | <Hixie> | i didn't see anything in the minutes |
| 08:35 | <annevk> | somewhere in the middle an action as assigned to Steven |
| 08:35 | <annevk> | there was no discussion around it |
| 08:35 | <annevk> | very weird |
| 08:35 | <Hixie> | ah, missed that |
| 08:36 | <MikeSmith> | I don't think the rationale that Roland gave (for their request to remove the offending text) will stand up to much scrutiny |
| 08:36 | <MikeSmith> | it seems like he was not questioning whether it was accurate |
| 08:36 | <Hixie> | what was the rationale? |
| 08:37 | <MikeSmith> | I think he was basically saying that it gave the appearance that the XHTML2 WG was not chartered to maintain the "XHTML family of languages" |
| 08:38 | <MikeSmith> | and I think I responded to say that was neither the intent nor the actual effect |
| 08:38 | <Hixie> | i don't really care what we say so long as it is clear, explanatory and accurate |
| 08:38 | <MikeSmith> | I think the current text qualifies as all those |
| 08:38 | <Hixie> | yes |
| 08:39 | <Hixie> | We could also add |
| 08:40 | <Hixie> | "Note that the W3C has also chartered another working group to work on the XHTML family of specifications." |
| 08:40 | <Hixie> | if they want |
| 08:40 | <annevk> | http://www.w3.org/2008/06/26-pf-minutes.html#item07 (W3C Member only) is also interesting |
| 08:40 | <MikeSmith> | Hixie: maybe that would be good. Maybe that's what they can request |
| 08:41 | <MikeSmith> | I'm not sure we should volunteer adding it unless/until they get back to us with suggested revised text |
| 08:41 | <MikeSmith> | and lacking that, I don't so that we are required to remove it simply because they've requested it |
| 08:42 | <MikeSmith> | if it were LC, it'd be a different matter, I guess |
| 08:42 | <MikeSmith> | but it's not LC |
| 08:42 | <Hixie> | well, from the point of view of working in good faith, i'm just saying we should let them know our timetable |
| 08:42 | <Hixie> | since they may not be expecting us to work punctually |
| 08:42 | <MikeSmith> | OK |
| 08:42 | <MikeSmith> | yeah, understood |
| 08:42 | <Hixie> | not rush them or anything |
| 08:45 | <gDashiva> | Speaking of xhtml2, are they exempt from heartbeat, or do all their non-xhtml2 drafts count towards it? |
| 08:45 | <annevk> | making this proposal seems like a goo thing too |
| 08:45 | <annevk> | gDashiva, heartbeat is ultimately a per-group and not a per-document requirement |
| 08:45 | <annevk> | gDashiva, and is also pretty much universally ignored |
| 08:48 | <MikeSmith> | the process doc still states clearly that groups should publish WDs of their specs every 3 months, and if they can't do that, instead publish some kind of status report at least |
| 08:50 | <Hixie> | the status document says a lot of things |
| 08:55 | <annevk> | and it continues: http://intertwingly.net/blog/2008/07/02/authoritative-true#c1215587954 |
| 09:01 | <Hixie> | i love how rob refers to hte "the W3C priority of constituencies" |
| 09:01 | <Hixie> | i wonder if he realises taht that concept was basically first pushed by the whatwg crowd |
| 09:19 | <annevk> | whatwg.org down? |
| 09:19 | <Hixie> | yeah |
| 09:19 | <Hixie> | nfs issues again |
| 09:20 | <Hixie> | sent them mail already |
| 09:50 | <zcorpan> | "Where is the HTML version of Line Rider? It is in Flash and Silverlight now. If you want to see something really interesting check out Hard Rock Cafe’s memorabilia page (Silverlight 2 required) and tell me if you’ve ever seen something like that with HTML." -- http://pseudosavant.com/blog/2008/07/08/a-proprietary-web-blame-the-w3c/ |
| 09:52 | <zcorpan> | can that be implemented with canvas? |
| 09:52 | <Philip`> | (Also http://tech.slashdot.org/article.pl?sid=08/07/08/1730231 for other comments on that) |
| 09:53 | <zcorpan> | flash line rider http://www8.agame.com/mirror/flash/l/linerider_v1_5.swf |
| 09:53 | <Philip`> | I don't see any reason why it couldn't |
| 09:58 | <zcorpan> | so who's gonna implement it in canvas? :) |
| 10:00 | <annevk> | from the comments: "If WHATWG had done its job correctly, we’d be on HTML 6 by now and nobody would be using IE7 due to it being horribly out of date." |
| 10:00 | <annevk> | also, "But it became a victim of the same process bloat that plagues the W3C, and so we’re still stuck using proprietary technologies." |
| 10:01 | <Philip`> | zcorpan: You could :-) |
| 10:02 | <zcorpan> | Philip`: gotta file more canvas bugs first :P |
| 10:02 | <zcorpan> | Philip`: if you didn't write so many test cases i'd be done by now! |
| 10:04 | <Philip`> | zcorpan: Once you've finished, writing non-trivial canvas examples is a good way to find more bugs - I don't think I've ever written anything where I haven't encountered new bugs :-) |
| 10:05 | <Philip`> | zcorpan: Blame the Opera developers for having so many bugs in their code :-p |
| 10:05 | <zcorpan> | Philip`: :) |
| 10:07 | <annevk> | Philip`, what do you think filing a bug means? :p |
| 10:07 | <Philip`> | or blame Hixie for changing the spec so that what Opera implements is now a bug |
| 10:26 | <MikeSmith> | annevk: regarding that blog posting, seems like just yet another tale "full of sound and fury" |
| 10:26 | <MikeSmith> | http://clicknotes.com/macbeth/T55.html#26 |
| 10:27 | <MikeSmith> | or yet another poor player just strutting and fretting |
| 10:29 | <gDashiva> | I wonder how many Tom Lehrer fans recognize the MacBeth quote |
| 10:35 | <annevk> | MikeSmith, he makes some valid points |
| 11:05 | <Lachy> | ah, damn. the live-dom-viewer is down. :-( |
| 11:12 | <jgraham> | The problem is that it is much easier to introduce cool new features unilaterally and ship them in the next version of your priprietry runtime than it is to take them through a standards process and then wait for your competitors to implement them before anyone is prepared to use them |
| 11:14 | <jgraham> | So even though the w3c is pretty slow it's not clear that's where the real problem lies |
| 11:14 | <Philip`> | The problem is standards, so the solution is to not do standards |
| 11:15 | <Lachy> | JohnResig, are there any Firefox builds available publicly with support for selectors api? |
| 11:17 | <jgraham> | Philip`: From the point of view of Microsoft that's really true. From the point of view of the end user it depends what your priorities are |
| 11:17 | <Philip`> | As an end user, I want cool stuff |
| 11:18 | <jgraham> | Yeah, clearly most end users are prepared to install Flash so they can watch the video at standardssuck.org and not worry about whether it is proprietry or not |
| 11:18 | <jgraham> | s/standardssuck.org/youtube/ maybe ;) |
| 11:25 | <jgraham> | I guess we're pretty lucky that Flash sucks so much at basic stuff like text form controls and bookmarkability |
| 11:25 | <roc> | Lachy: not that I know of, I think it's still in Boris' tree |
| 11:32 | <annevk> | I think with the WHATWG we're sort of getting to the state of specifying competitive features in a timely manner and getting them shipped |
| 11:34 | <annevk> | Lachy, IE throwing for |div and all is fine as IE doesn't support all of Selectors |
| 11:34 | <othermaciej> | Hixie: the Design Principles document shows the power of writing things down (and of actually having principles) |
| 11:34 | <othermaciej> | those were all things people fought about tooth and nail in the early days of the WG |
| 11:34 | <othermaciej> | now they are canon |
| 11:34 | <annevk> | that is indeed quite amazing |
| 11:37 | <annevk> | roc, fwiw, I'd be in favor of having it without prefix, there's plenty of precedent for that too (provided you're willing to make changes to details) |
| 11:37 | <roc> | yeah |
| 11:37 | <roc> | the Web isn't going to depend on it in a hurry |
| 11:38 | <annevk> | right |
| 11:39 | <Lachy> | annevk, ok. |
| 11:40 | <Lachy> | annevk, it seems IE8 makes it impossible to know what type of exception was thrown. I can't tell if it's a syntax err or namespace err |
| 11:41 | <annevk> | make sure to test it in the testsuite |
| 11:41 | <annevk> | e.code and all |
| 11:42 | <Lachy> | annevk, yeah, it will be |
| 11:43 | <Lachy> | today, I'm going through the backlog of issues and responding. |
| 11:44 | <Hixie> | othermaciej: i'm not convinced the effort required to write them down was a price worth paying to get rob to quote those principles back at me as if i wasn't following them |
| 11:45 | <annevk> | it's certainly entertaining |
| 11:46 | <Lachy> | has anyone seen any demand for a hasFeature string from implementers of other languages implementing selecotrs api? e.g. Java? |
| 11:47 | gDashiva | looks for the "Don't disrupt the WG activity for no good reason" design principle |
| 11:47 | <Lachy> | gDashiva, look up netiquette guidelines for that |
| 11:48 | <annevk> | ah, whatwg.org is back up |
| 11:48 | annevk | spots http://www.whatwg.org/specs/web-workers/current-work/ |
| 11:50 | <Hixie> | any chance we can get http://html5.org/tools/web-workers-tracker ? :-) |
| 11:50 | <Lachy> | Hixie, why is there a new spec? Is HTML5 being split up into several? |
| 11:51 | jgraham | notes that web workers seems like a very silly name |
| 11:51 | <Hixie> | people wanted workers not to be added to html5 |
| 11:51 | <jgraham> | Just becauseit sounds funny |
| 11:51 | <jgraham> | But I don't actually object :) |
| 11:52 | <jgraham> | Isn't HTML5 supposed to be in feature freeze? |
| 11:52 | <Hixie> | well, technically this wasn't added to the html5 spec, so sure :-) |
| 11:52 | <Lachy> | ok, so what's the criteria for something to be moved to that spec, or left in the existing spec? Is it just the few things mentioned in the introduction like canvas, context menus and server-sent events? |
| 11:52 | <Hixie> | but in any case, the feature freeze is intended to prevent the spec from getting too far ahead of implementations |
| 11:52 | <annevk> | Hixie, http://html5.org/tools/web-apps-tracker?source=http://svn.whatwg.org/webworkers/source works... |
| 11:53 | <annevk> | Hixie, though the links and such will be broken, so it doesn't totally work |
| 11:53 | <Hixie> | so if implementations get ahead of the spec (as they were threatening to with workers), the freeze isn't useful |
| 11:53 | <Hixie> | Lachy: nothing will be moved to web workers |
| 11:53 | <Hixie> | Lachy: it's for workers |
| 11:53 | <Hixie> | Lachy: which are new |
| 11:53 | <Lachy> | oh, ok. What is a worker? |
| 11:54 | <takkaria> | Hixie: webworkers still has <title>HTML 5</title> |
| 11:54 | <Hixie> | background thread for js |
| 11:54 | <annevk> | Lachy, the introduction is a copy from somewhere else |
| 11:54 | <Hixie> | did i forget to change the intro? |
| 11:54 | <Hixie> | oops |
| 11:54 | Hixie | goes to fix |
| 11:54 | <Lachy> | yeah, the abstract is from html5 |
| 11:54 | <Hixie> | oh the abstract |
| 11:55 | <annevk> | abstract/intro, meh |
| 11:56 | <Hixie> | fixed |
| 11:59 | <Lachy> | Hixie, also, the abstract in HTML5 is wrong. It still mentions inline popup windows, which were never included. |
| 11:59 | <gDashiva> | Lachy: Apparently certain wg participants don't feel netiquette is part of our charter :) |
| 11:59 | <Lachy> | oh, it isn't? Cool. I should participate in more flamewars then. |
| 12:00 | <takkaria> | http://www.whatwg.org/specs/web-workers/current-work/'s <title> is still HTML 5. :) |
| 12:02 | <Philip`> | I hope you don't want a multipage version of this |
| 12:03 | <Hixie> | takkaria: oops |
| 12:03 | <gDashiva> | Philip`: No, but he'll want it preprocessed using workers :P |
| 12:03 | <Hixie> | fixed. |
| 12:06 | <roc> | if flamewars aren't valid netiquette, then the spec should be changed to match reality |
| 12:07 | <annevk> | yeah, writing specs that are not implemented is no fun |
| 12:08 | <Hixie> | Lachy: updated the abstract |
| 12:12 | <annevk> | showModalDialog is sort of an inline popup |
| 12:14 | <jgraham> | Framewars should be non-conformant but have defined error handling |
| 12:14 | <jgraham> | s/Frame/Flame/ |
| 12:15 | <annevk> | <frame>wars too! |
| 12:17 | <Lachy> | yeah, there are many things in RFC 1855 that need to be updated to deal with common situations, like bikeshedding, banning HTML mail, banning the use of broken mail clients that destroy threading and quoting, etc. |
| 12:20 | <othermaciej> | Hixie: sure, he's still irritating, but accepting your principles as the ground rules makes it harder for him to argue |
| 12:20 | <othermaciej> | remember, he could be much worse |
| 12:20 | <othermaciej> | and has been! |
| 12:22 | <Hixie> | it doesn't seem to have made any difference to the quality of his arguments |
| 12:23 | <Hixie> | you know, i get mixed messages from the opera crowd |
| 12:23 | <Hixie> | or rather, i get mixed messages from chaals relative to the rest of opera. |
| 12:25 | <Hixie> | ok. i have my web workers dev environment set up. tomorrow i shall write the spec. |
| 12:25 | <Hixie> | nn |
| 12:26 | <annevk> | I think chaals was asking about major changes. I agree that those should go to public-html. |
| 12:26 | <annevk> | Actually, he didn't say that explicitly, so never mind |
| 13:54 | <JohnResig> | Lachy: no public builds, no |
| 13:54 | <JohnResig> | Lachy: you can take the patch from the bug and build your own copy |
| 13:54 | <JohnResig> | Lachy: which I might do here soon in order to finish the test suite |
| 13:55 | <Lachy> | JohnResig, assume I don't have the time or skill to work out how to build my own. |
| 13:56 | <Lachy> | if you make one for the mac, can you send me a build? |
| 13:56 | <JohnResig> | Lachy: right, yeah - it's a pain - a full build won't be around for a while |
| 13:56 | <JohnResig> | Lachy: sure, I'll see what i can do |
| 13:56 | <Lachy> | thanks |
| 13:58 | <Lachy> | oh, btw, we need to make sure the test suite handles querySelector(null);. Currently, there's no interop on that issue. But it was recently defined in the spec |
| 14:18 | <annevk> | I think treating null like "null" is more consistent with most DOM APIs, but I don't really feel strongly about this issue |
| 14:19 | <gDashiva> | I wonder what kind of apps depend on null -> "null" |
| 14:21 | <annevk> | lots of stuff that does "(" + variable + ")" or something |
| 14:22 | <Lachy> | annevk, this way the null is handled the same way in all places throughout the spec, for both NSResolver return values and parameters |
| 14:23 | <Lachy> | plus, it seems more intuitive for null to match nothing, rather than inadvertenly match an element <null> in the document |
| 14:23 | <annevk> | I think "" would be a SYNTAX_ERR |
| 14:25 | <Lachy> | annevk, yes. it is |
| 14:25 | <Lachy> | and therefore, so is null |
| 14:25 | <Lachy> | but if you still disagree, respond on the list and I'll take another look |
| 14:26 | <Lachy> | oh, looks like there's a thread from February neither I nor anyone else responded to. I'd better do that now. |
| 15:35 | <JohnResig> | Lachy: ok, I've got some interesting edge case here. Safari feels that :enabled does not include hidden input elements (Opera does). Also, no browser currently selects option[selected] when the selected is implied (e.g. selected by default) - even if you were to check .selected and see that it's true, it wouldn't match with this selector. |
| 15:47 | <Lachy> | option[selected] shouldn't match when the selection is implied, because it's an attribute selector. |
| 15:47 | <Lachy> | so the implementations are correct according to the spec |
| 15:48 | <JohnResig> | Lachy: and :enabled? |
| 15:49 | <Lachy> | Selectors states: "An element is enabled if the user can either activate it or transfer the focus to it. " |
| 15:49 | <Lachy> | since a user can't do that to a hidden input, Safari's behaviour is correct |
| 15:50 | <Lachy> | if you've got a TC, I'll file a bug with Opear |
| 15:50 | <Lachy> | Opera* |
| 15:51 | <Lachy> | does option:checked work? |
| 15:51 | <JohnResig> | Lachy: let me see |
| 15:51 | <Lachy> | hmm. probably not. I think it only applies to checkboxes and radio button |
| 15:51 | <JohnResig> | err, yeah |
| 15:52 | <Lachy> | oh, wait, yeah, selectors says it should |
| 15:52 | <Lachy> | "The :checked pseudo-class initially applies to such elements that have the HTML4 selected and checked attributes..." |
| 15:52 | <Lachy> | which includes option |
| 15:55 | <JohnResig> | Lachy: heh, the test suite crashes gogi now |
| 15:55 | <Lachy> | cool |
| 15:55 | <JohnResig> | Lachy: well, in Safari option:checked doesn't select anything |
| 15:56 | <annevk> | I'd suggest not to trust Selectors on this and instead check how Web Forms 2.0 defines the mapping |
| 15:56 | <annevk> | Web Forms 2.0 is quite detailed on the subject and arguably the more correct place than Selectors anyway |
| 15:57 | <Lachy> | annevk, ok. |
| 15:57 | <Lachy> | option:checked doesn't match for me in gogi either. |
| 15:57 | <JohnResig> | ok - so we're up to about 1500 tests: http://ejohn.org/apps/selectortest/ - I've gotta move on to the namespace stuff now |
| 15:57 | <Lachy> | ok |
| 15:58 | <annevk> | JohnResig, hey man, that's awesome |
| 15:58 | <JohnResig> | annevk: :) |
| 15:58 | <Lachy> | hmm, not working at all in gogi. I just get a blank white space where the results are supposed to be |
| 15:59 | <JohnResig> | Lachy: that's more than I got :-/ |
| 15:59 | <Lachy> | heh. Yeah, that acid 3 build probably still had a few crashers in it |
| 16:01 | <annevk> | lies, our acid3 build was perfect! |
| 16:02 | <Lachy> | annevk, of course. our developers write bug free code. :-) |
| 16:05 | <Lachy> | JohnResig, I'm dealing with the thread about adding a selector detection mechanism. http://lists.w3.org/Archives/Public/www-style/2008Apr/0113.html ... |
| 16:05 | <Lachy> | As a JS library author, would you have any need for any such mechanism that isn't covered by catching exceptions for syntax errors and unsupported selectors? |
| 16:06 | <Lachy> | the whole thread is lacking compelling use cases, so I'm likely to just respond and reject the proposal |
| 16:06 | <annevk> | we don't have supportsHTMLAnchorElementWithPingAttribute() either... |
| 16:07 | <JohnResig> | Lachy: I asked for something a little more detailed back when I gave my comments - showing which portion of a selector was valid (or "at which point a token wasn't recognized by the selector engine") - but I had trouble convincing boris that he could actually implement it |
| 16:08 | <Lachy> | oh, yeah, I remember that. |
| 16:08 | <annevk> | what is the use case for a library? |
| 16:08 | <Lachy> | http://lists.w3.org/Archives/Public/www-style/2008Apr/0160.html has an interesting solution that JS authors could use if there really is a need it. |
| 16:08 | <JohnResig> | right now all we get is "hey an error happened somewhere in this selector - good luck in figuring out what went wrong and where" |
| 16:09 | <annevk> | but do you need an error console feature or a JS API |
| 16:09 | <JohnResig> | annevk: JS API - well, more precisely, a better-detailed error message (which is what I brought up for discussion on the mailing list) |
| 16:10 | <Lachy> | what would you want to do with the information if you got it? |
| 16:11 | <annevk> | Lachy, did you define whitespace when you added that note? |
| 16:12 | <JohnResig> | we could determine that (for example) given the selector: "#foo div span select > option:selected" that it was good up until ":selected" - we'd go back and pass through all the good parts and end up with a resulting string - then do our own filtering to implement the ":selected" |
| 16:12 | <Lachy> | annevk, the one about trimming leading and trailing whitespace? |
| 16:13 | <annevk> | yes |
| 16:13 | <Lachy> | whitespace is defined in Selectors. Do you want me to add an explicit reference to its definition? |
| 16:13 | <annevk> | Lachy, maybe just a note that indicates where it comes from |
| 16:14 | <Lachy> | I'll add a link to http://www.w3.org/TR/css3-selectors/#whitespace |
| 16:15 | <annevk> | JohnResig, right... that does seem tricky and quite a bit over engineered and optimized for libraries |
| 16:16 | <JohnResig> | annevk: well - unless there's a drastic change in the flexibility of this spec - libraries are still going to be the primary consumer of this API |
| 16:28 | <zcorpan> | Philip`: in http://philip.html5.org/tests/canvas/suite/tests/2d.path.clip.winding.2.html is it intentional that the ctx.lineTo(0, 0); line (after the second beginPath()) is lineTo and not moveTo? |
| 16:44 | <zcorpan> | http://www.sitepoint.com/article/html-or-xhtml-does-it-matter hmm |
| 16:44 | <Lachy> | now I'm down to 100 more emails in my selectors-api folder to deal with. I'll try and finish those off tomorrow. |
| 16:44 | <Lachy> | (down from about 200 earlier today) |
| 16:46 | <annevk> | zcorpan, removal of alt=""? |
| 16:47 | <annevk> | headers=""? |
| 16:47 | <annevk> | when was this article written? before we introduced the <img> element? |
| 16:52 | <takkaria> | there so many uninformed opinions and bad arguments on the web, sometimes I get dizzy just thinking about it |
| 17:03 | <zcorpan> | annevk: today |
| 17:04 | <zcorpan> | brothercake wrote the article |
| 17:04 | <zcorpan> | gotta go |
| 17:37 | <Philip`> | zcorpan: Oops, that's not intentional |
| 17:38 | Philip` | fixes his local version |
| 17:51 | <JohnResig> | Lachy: "if the selectors argument is null, undefined, or omitted, the implementation must act as if the selectors argument was set to """ - is throwing a syntax_err a valid response? |
| 17:52 | <annevk> | yes, because that's what you're supposed to do for the empty string |
| 18:08 | <JohnResig> | "Note: Authors are strongly discouraged from writing an NSResolver that returns inconsistent results. " - I'm actually tempted to try and write one that does a little rand() action - or maybe throw a % 2 on the resolver results |
| 18:24 | <Lachy> | JohnResig, see if you can break Opera by doing that. It seems to resolve each prefix every time it's used, so "x|div x|span" resolves x twice |
| 18:25 | <Lachy> | I need to ask our developers why they did that, cause it seems inefficient |
| 18:25 | <JohnResig> | Lachy: ok, I'll add that in, as well |
| 18:26 | <annevk> | maybe it was easier |
| 18:26 | <annevk> | as nobody uses namespaces anyway, it would be a premature optimization if the current thing was easier |
| 18:27 | annevk | is still not really convinced Selectors API needs namespace support |
| 18:28 | <JohnResig> | it certainly ups the complexity of the spec |
| 18:28 | <Dashiva> | Has anyone asked for namespace support, or was it just implicit with css namespaces existing? |
| 18:28 | <JohnResig> | Dashiva: dunno - I assume /someone/ asked for it |
| 18:29 | <JohnResig> | it wasn't me, though, heh |
| 18:29 | <annevk> | bzbarsky was in favor iirc |
| 18:29 | <annevk> | might be that someone at Opera liked it too, dunno |
| 18:29 | <JohnResig> | k |
| 18:30 | <annevk> | seems pointless to me |
| 18:30 | <annevk> | but then I specced it initially so you can all blame me |
| 18:43 | <JohnResig> | ugh... I fear running this test suite in IE |
| 19:30 | <annevk> | hmm, maybe SSD will be able to solve the slow boot up times of computers |
| 19:30 | <annevk> | (as opposed to software) |
| 19:33 | <Dashiva> | Isn't software the reason? :) |
| 19:34 | <annevk> | I'd think so, but I don't really know |
| 19:35 | <Dashiva> | I know from experience that OS startup time increases with age, and I doubt my disks are getting slower |
| 19:39 | <Lachy> | hmm, I found this in my todo folder for selectors api. http://lists.w3.org/Archives/Public/public-webapi/2008May/0357.html Not sure how to deal with it, since I already responded to another thread on the same issue today saying the opposite |
| 19:40 | <Lachy> | JohnResig, as a JS library author, what seems most intuitive for you in regards to handling querySelector(null);? What the spec says, or what annevk is asking for (stringifying to "null")? |
| 19:40 | <JohnResig> | ew - stringifying sounds frightening |
| 19:41 | <JohnResig> | querySelector(null) finds all null elements on the page? not feeling that, heh |
| 19:41 | <JohnResig> | I'm fine with an exception |
| 19:41 | <annevk> | it accepts a DOMString after all |
| 19:41 | <annevk> | and null + "x" also gives "nullx" |
| 19:41 | <JohnResig> | sure - and if something that isn't a DOMString is passed in an exception should be thrown |
| 19:41 | <annevk> | no |
| 19:42 | <annevk> | that's not how JS works |
| 19:42 | <Lachy> | no, any object is stringified using .toString() |
| 19:42 | <Lachy> | the spec just makes an exception for null and undefined |
| 19:43 | <JohnResig> | then why are you asking me about null -> "null" - it's obviously a done deal, then? |
| 19:43 | <Lachy> | I'm asking because annevk wants the spec to change and I'm not sure if I should. |
| 19:43 | <othermaciej> | the spec is a draft |
| 19:44 | <annevk> | I don't feel strongly about this issue, as there are APIs that work either way |
| 19:44 | <othermaciej> | nothing is a done deal, yet |
| 19:44 | <annevk> | though for new specs sticking with the default behavior makes more sense to me |
| 19:44 | <Lachy> | I just want to know if null should be stringified to "null" or "" |
| 19:44 | <Lachy> | IIRC, Opera using "null", webkit uses "" |
| 19:44 | <othermaciej> | the way null and undefined convert to string in JS sucks, and it sucks more that DOM APIs are inconsistent about whether they treat null and/or undefined specially instead of using normal stringification rules |
| 19:44 | <JohnResig> | going to "" would make sense, considering that we're expecting the behavior of qSA(null) to be the same as qSA("") |
| 19:45 | <othermaciej> | it is not a big hassle either way implementation-wise, as long as it is specified |
| 19:46 | <Lachy> | othermaciej, so would you prefer to apply normal stringification rules then? |
| 19:46 | <othermaciej> | I have no real preference other a desire for closure on this issue |
| 19:47 | <othermaciej> | since it is a new API, doing whatever is less error-prone makes sense |
| 19:47 | <Lachy> | it's a bikeshed. There can be no closure :-) |
| 19:47 | <JohnResig> | null -> "", undefined -> "", (nothing) -> "" fit well with what's currently specified |
| 19:47 | <JohnResig> | and since "" throws an exception it'll be easy to handle |
| 19:48 | <Dashiva> | My paint color: If the user is going to see the result, "null" is good. If it's just a parameter, we want null to mean nothing and that puts it with "" |
| 19:49 | <Lachy> | having null result in an exception may make it easier for debugging. Consider calling querySelctor(myVar); and getting zero results returned and not understanding that myVar was accidentally left set to null. |
| 19:50 | <JohnResig> | Lachy: correct |
| 19:50 | <Lachy> | at least with an exception, it makes the error an obvious error, rather than a damn logic error that could go undetected. |
| 19:50 | <Lachy> | issue settled. Bikeshed painted a beautiful sky blue. :-) |
| 19:51 | <takkaria> | I say gray |
| 19:54 | <Lachy> | annevk, are you sure the raises thing in the IDL is optional? |
| 19:56 | <annevk> | yes |
| 19:56 | <annevk> | I'm positive it needs to be |
| 19:56 | <Lachy> | ok, in that case I'll remove it because it just makes the IDL more cluttered |
| 19:57 | <annevk> | indeed |
| 20:04 | <Lachy> | oh crap. I hate how we have a new mailing list. Now when I respond to old threads, I keep forgetting to change from public-webapi to public-webapps |
| 20:54 | <rubys> | hsivonen: html5.validator.nu appears to be down |
| 20:55 | <annevk> | yeah, has been like that for a day or so now :/ |
| 20:55 | <annevk> | seems hsivonen is not around |
| 20:56 | <rubys> | Thanks! I'm sure he'll attend to it when he gets back. |
| 21:19 | <MikeSmith> | unfortunately, building from http://svn.versiondude.net/whattf/build/trunk also appears to be broke |
| 21:19 | <MikeSmith> | in my environment at least |
| 21:30 | <JohnResig> | Lachy: hmm... no matter what I do I get NAMESPACE_ERRs from the Opera Gogi build |
| 21:30 | <JohnResig> | Lachy: I get the error if I give it an invalid namespace resolver or a valid one |
| 21:31 | <Lachy> | really? Show me a simple TC |
| 21:32 | <JohnResig> | well, let me see |
| 21:34 | <roc> | annevk: thanks man! |
| 21:35 | <JohnResig> | huh... works in my simple test case - time to work backwards |
| 21:36 | <Lachy> | ok, ping me when you work it out |
| 21:39 | <Lachy> | JohnResig, remember to test :hover as well. That one is going to be a little tricky, and will need to be interactive |
| 21:39 | gsnedders | now has a decent connection, and so shouldn't drop offline unexpectedly |
| 21:39 | <annevk> | roc, np, hopefully it kills the thread :) |
| 21:45 | <gsnedders> | annevk: The Xbox itself didn't, though many games have (Halo, anything using the Unreal Engine 2.5 and above) |
| 21:45 | <gsnedders> | annevk: (re: vorbis) |
| 21:46 | <gsnedders> | 712 unread emails. Yay. |
| 21:46 | <JohnResig> | Lachy: ok! fixed the bug and found one error - Opera doesn't throw an exception with this resolver: { lookupNamespaceURI: function(){} } |
| 21:47 | <Lachy> | while resolving the default ns or a prefix? |
| 21:48 | <Lachy> | if it's while resolving the default ns, that's fine because it's implicitly returning undefined |
| 21:48 | <JohnResig> | a prefix - it doesn't throw a NAMESPACE_ERR |
| 21:48 | <Lachy> | oh, ok. Let me see |
| 21:50 | <JohnResig> | weird, I'm having troubles with a reduction - although I'm able to get the others (return null, return "") to fail. |
| 21:50 | <MikeSmith> | Hixie: would be good to try to get the "Fetching resources" section completed before publishing the next WD |
| 21:51 | <JohnResig> | Lachy: ok, I'm still investigating - I'm not sure why this one would fail |
| 21:52 | <JohnResig> | oh! wait |
| 21:52 | <JohnResig> | Lachy: ok, nm - I was giving it a valid namespace - just one that wasn't on the page |
| 21:53 | <JohnResig> | OK! need to generate a lot more test cases, now that it appears to be working |
| 21:54 | <Lachy> | ah, ok. cool. FWIW, this worked for me: |
| 21:54 | <Lachy> | <!DOCTYPE html> |
| 21:54 | <Lachy> | <script> |
| 21:54 | <Lachy> | try { |
| 21:54 | <Lachy> | var p = document.querySelector("x|p", function(){}); |
| 21:54 | <Lachy> | } catch (e) { |
| 21:54 | <Lachy> | alert(e); |
| 21:54 | <Lachy> | } |
| 21:54 | <Lachy> | </script> |
| 21:55 | <JohnResig> | k |
| 22:07 | <Lachy> | hmm, now I'm down to the difficult issues. Dealing with NSResolver problems. I've put it off long enough, I will have to deal with it all tomorrow. |
| 22:08 | <Lachy> | only about 90 emails on the topic :-( |
| 22:09 | <JohnResig> | Lachy: ok! I think I found a legitimate bug with test case: http://ejohn.org/apps/selectortest/tmp.html it seems like this should find, at least, one svg element |
| 22:13 | <annevk> | doublec, roc, btw, the VoidCallback stuff from <video> should be just a function in ECMAScript (will be part of Web IDL or might already be, dunno) |
| 22:14 | <Lachy> | JohnResig, yep, looks like a bug to me. |
| 22:15 | <JohnResig> | Lachy: ok! I'll write a bunch of svg-in-xhtml cases (as I was going to do) - I'll just kind of have to eyeball how the results should go, since I don't have a reference at this point |
| 22:16 | <JohnResig> | Lachy: I'll leave this as a permanent URL, then: http://ejohn.org/apps/selectortest/svg-in-xhtml.html |
| 22:17 | MikeSmith | reads message from Sunava stating "IE8 will ship the updated section of Access Control that enables public data aggregation (no creds on wildcard) while setting us up on a trajectory to support more in the future (post IE8) using the API flag in an XDR level 2" |
| 22:17 | <roc> | annevk: but HTML5 doesn't say that yet, right? |
| 22:17 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0057.html |
| 22:18 | <Lachy> | JohnResig, it's not a bug |
| 22:18 | <Lachy> | it's your fault |
| 22:18 | <roc> | so they're not going to support anything in XHR, only XDR? |
| 22:19 | <Lachy> | JohnResig, the page is served as text/html. Serve it as XML and it works. |
| 22:19 | <Lachy> | since we don't yet support SVG in text/html, your test fails |
| 22:21 | <annevk> | roc, correct, twice |
| 22:23 | <roc> | that sucks, but no surprise |
| 22:24 | <annevk> | for the latter, yes |
| 22:35 | <annevk> | I'm glad I didn't specify the double GET algorithm :) |
| 22:36 | <gsnedders> | I'm glad I'm not spec'ing HTTP… |
| 22:36 | <annevk> | you stopped? |
| 22:36 | <gsnedders> | … oh, wait, I am :) |
| 22:36 | <annevk> | are you doing cookies too btw? |
| 22:37 | <gsnedders> | annevk: in the parsing spec? yeah. |
| 22:51 | <Lachy> | JohnResig, It seems Opera resolves duplicate namespace prefixes twice, but still use the first value returned. |
| 22:51 | Philip` | discovers that Dehydra is quite neat |
| 22:52 | <JohnResig> | Lachy: huh |
| 22:58 | <Hixie> | MikeSmith: what do you want that section to say? The main reason i haven't written it is i don't know what it should say, really |
| 23:01 | <MikeSmith> | Hixie: to say at least what you mention in your editorial note that it will cover |
| 23:02 | <Hixie> | do you think it should say those things? |
| 23:02 | <Hixie> | i'm undecided |
| 23:02 | <MikeSmith> | Hixie: mostly because of the x-refs to it |
| 23:03 | <Hixie> | yeah |
| 23:03 | <MikeSmith> | btw, r1857 seems to have broken styling of the editorial notes in the W3C version |
| 23:03 | <MikeSmith> | http://dev.w3.org/html5/spec/#fetching |
| 23:03 | <Hixie> | ok, i'll file a bug on myself seeing what i can do about fetching |
| 23:03 | <MikeSmith> | Hixie: cool |
| 23:03 | <Hixie> | yes, i removed the <style> block after noticing that the pubrules said i shouldn't have one |
| 23:04 | <Hixie> | is there some class i should use for notes in w3c docs? |
| 23:04 | <MikeSmith> | for the Publication Notes, I just use an embedded <style> block |
| 23:04 | <MikeSmith> | pubrules doesn't actually seem to complain about it |
| 23:04 | <annevk> | I use <style> too for a lot of specs |
| 23:05 | <MikeSmith> | and no person has |
| 23:05 | <MikeSmith> | Hixie: so I'd suggest just restoring the <style> |
| 23:05 | <annevk> | Hixie, websocket-allow-origin, meh, now it's back on my plate :p |
| 23:06 | <Hixie> | it was a pretty big <style> block |
| 23:07 | <Hixie> | i'd rather just use the classes w3c provides, i mean, it would be more in line with the intent of the pubrules |
| 23:08 | <MikeSmith> | true |
| 23:08 | <MikeSmith> | I'll look at the stock stylesheets right now and see what they provide |
| 23:08 | <Hixie> | ok |
| 23:08 | <Hixie> | i have to go to work, i'll be back in a bit |
| 23:08 | <MikeSmith> | Hixie: btw, also on my wish list is a definition for "a document's address" (XXXDOCURL flagged stuff) |
| 23:09 | <MikeSmith> | though there are not x-refs for that now, so less need |
| 23:09 | <Hixie> | yeah i've even less idea what to do about that one |
| 23:09 | <MikeSmith> | yeah, I know you mentioned that before |
| 23:09 | <MikeSmith> | anyway, ttl |
| 23:09 | <Hixie> | later |
| 23:25 | <MikeSmith> | I so far find jack in the StyleSheets/TR/ stylesheets as far as class values for marking up notes of any kind |
| 23:26 | <MikeSmith> | they really quite basic |
| 23:28 | <MikeSmith> | would that we had something like, say, and <aside> element or something |