| 06:30 | <Hixie> | man, people have go to start realising that when an implementor says he's not doing something, arguing with him is a bad idea |
| 06:54 | <aroben> | Hixie: do you know of any doctype parsing tests? |
| 07:55 | <Lachy> | Hixie, which issue are you referring to, and who's arguing with them? |
| 07:56 | <annevk> | appformats list |
| 07:56 | <annevk> | or maybe webapi |
| 07:59 | <Lachy> | haven't read appformats in a while, not too sure what's going on there |
| 08:01 | <annevk> | wow, another ala on version targeting |
| 08:01 | <Lachy> | I uploaded my disposistion of comments last night http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments |
| 08:01 | <krijnh> | Yeah :/ |
| 08:03 | <annevk> | oh well, ala hasn't been interesting for a long time now |
| 08:03 | <hsivonen> | aroben: I'm known to have http://hsivonen.iki.fi/doctype/ but not test cases for parsing broken doctypes |
| 08:03 | <aroben> | hsivonen: ah, thanks |
| 08:04 | <annevk> | I think html5lib might have some |
| 08:04 | <Lachy> | hmm. I still never wrote anything about the version thingy this time round. maybe I should, if this ALA article says nothing but misinformation about it (again) |
| 08:05 | <aroben> | annevk: will look |
| 08:05 | <annevk> | aroben, http://html5lib.googlecode.com/svn/trunk/testdata/tokenizer/test3.test |
| 08:05 | <annevk> | http://html5lib.googlecode.com/svn/trunk/testdata/tokenizer/test2.test |
| 08:06 | <annevk> | http://html5lib.googlecode.com/svn/trunk/testdata/tokenizer/test4.test |
| 08:06 | <annevk> | http://html5lib.googlecode.com/svn/trunk/testdata/tokenizer/test1.test |
| 08:06 | <annevk> | unfortunately not grouped |
| 08:06 | <aroben> | annevk: still very helpful |
| 08:10 | <hsivonen> | annevk: are the html5lib tests up to date with the recent change regarding '>'? |
| 08:10 | <annevk> | no :( |
| 08:15 | <annevk> | at least, not as far as I know |
| 08:17 | <annevk> | actually, yes, the tests are up to date thanks to Philip` it seems |
| 08:28 | <krijnh> | annevk: no new stuff in the new ALA |
| 08:29 | <annevk> | boring |
| 08:30 | <annevk> | can someone tell me the result of http://tc.labs.opera.com/css/namespaces/ 002 and 003 in Safari? |
| 08:31 | <aroben> | annevk: in a recent nightly both of them have a green background |
| 08:32 | <annevk> | thanks |
| 08:32 | <krijnh> | In 3.0.4 as well |
| 08:32 | <annevk> | does Safari pass 001? |
| 08:32 | <krijnh> | Yes |
| 08:52 | <Lachy> | I don't really understand Boris' last comment: "but it wouldn't address the issue of what implementations are allowed to actually do to stop misbehaving NSResolvers" |
| 08:53 | <annevk> | yeah, what's a misbehaving nsresolver? |
| 08:53 | <annevk> | i mean, you could of course do all kinds of quirky things in script, but that's not restricted to NSResolver |
| 08:53 | <Lachy> | how does resolving all namespaces prior to traversing the DOM, thus letting the NSResolver do anything it likes beforehand, get in the way of actually finding matches afterwards? |
| 08:54 | Lachy | will respond |
| 09:00 | <krijnh> | "Invited Expert will participate in the W3C Group in a decent way." |
| 09:04 | <krijnh> | A year by already |
| 09:08 | <annevk> | oh |
| 09:08 | annevk | thought the HTML WG started in March |
| 09:09 | <krijnh> | A year minus 1 month then :) |
| 09:09 | <krijnh> | Have to reinvite myself as an expert.. |
| 09:11 | <annevk> | i wonder how many people won't do that |
| 09:13 | <krijnh> | I think you get bugged with a mail each week, until you say yes or no |
| 09:14 | <krijnh> | Pretty irritating, so saying "yes, I'm still teh expert you need!11" does the trick :) |
| 09:15 | <hsivonen> | krijnh: do (public) Invited Experts have to renew their participation annually or what is this about? |
| 09:15 | <krijnh> | Yeah, I guess so |
| 09:15 | <krijnh> | And there's a new EULA or something |
| 09:16 | <hsivonen> | krijnh: what's the diff in the "EULA"? |
| 09:16 | <krijnh> | http://www.w3.org/Consortium/Legal/2007/06-invited-expert.html |
| 09:16 | <krijnh> | No idea, I'm not an invited expert on EULAs :p |
| 09:17 | <krijnh> | Prolly just a clarification for the 2002 version |
| 09:17 | <krijnh> | With new elements and a new API |
| 09:18 | <krijnh> | Can't they just create a new group for this? Invited Wannabe Experts or something.. |
| 09:18 | <hsivonen> | hmm. I don't like it that the W3C wants to use copyright to prevent spec branching |
| 09:20 | <annevk> | me neither |
| 09:20 | <annevk> | or for test suite branching for that matter |
| 09:20 | <annevk> | it's silly |
| 09:20 | <hsivonen> | the freedom to fork a Free Software project is an important deterrent against the main project going crazy |
| 09:20 | <hsivonen> | should be likewise for specs |
| 09:21 | <Lachy> | I'm glad that's the case for the WHATWG's HTML5 spec |
| 09:21 | <annevk> | maybe they realize they're going crazy in some twisted way |
| 09:43 | <Lachy> | Hixie, how do you suggest resolving the hostile-NSResovler issue, if Anne's suggestion is no good? |
| 09:49 | <hsivonen> | Lachy: I'm not Hixie, but it seems to me that the way to deal with NSResolver side effects in an interoperable way is to spec when exactly NSResolver is called into |
| 09:50 | <annevk> | no, we don't want to go there |
| 09:51 | <annevk> | that would not allow optimizations |
| 09:51 | <hsivonen> | hmm. how about requiring the script to push a mapping hash table to the browser ahead of time so that no NSResolver is needed? |
| 09:51 | <annevk> | *[foo|x]:not([foo|x]) for instance |
| 09:52 | <hsivonen> | annevk: you could put the optimization into the spec itself |
| 09:52 | <Lachy> | that's difficult |
| 09:52 | <Lachy> | what if someone finds an even better optimisation later, and the spec would then prevent them from implementing it |
| 09:53 | <annevk> | it would constrain implementations and makes it harder to introduce new selectors |
| 09:53 | <hsivonen> | is there a reason why prefix resolution needs to be dynamic instead of a static mapping that is given the the browser at the time of the API call? |
| 09:54 | <Lachy> | hsivonen, I think it was because the resolver was based upon the design of the XPathNSResolver |
| 09:55 | <hsivonen> | annevk: would implementation be constrained too much if implementation were required to |
| 09:55 | <hsivonen> | 1) parse the selector |
| 09:55 | <Lachy> | crap. meeting time :-( |
| 09:55 | <hsivonen> | 2) resolve each prefix from left to right exactly once |
| 09:55 | <hsivonen> | 3) run the selector |
| 09:55 | <hsivonen> | ? |
| 09:56 | <annevk> | for the case I gave above you don't need to resolve the prefix in theory |
| 09:56 | <hsivonen> | annevk: ah right. but are such pathological edge cases worth optimizing |
| 09:57 | <hsivonen> | annevk: they don't serve a useful purpose for authors |
| 09:57 | <annevk> | people say yes |
| 09:57 | <annevk> | i'm not sure |
| 09:57 | <annevk> | (people being bjoern and hixie, so maybe...) |
| 09:57 | <Philip`> | :somenewfeature(foo|x) /* CSS4 browsers need to resolve this prefix, but CSS3 browsers can't know they're meant to */ |
| 09:57 | <annevk> | that would not parse Philip` |
| 09:58 | <annevk> | and throw a SYNTAX_ERR |
| 09:58 | <Philip`> | Ah |
| 10:02 | <hsivonen> | as far as I can tell, this problem is mostly the same problem that was pointed out when Dave Raggett's XForms Transitional was discussed. |
| 10:03 | <hsivonen> | and really the way to make sure that the side effects are the same in all browsers is to clamp down what the calls to the code with the potential side effects are |
| 10:03 | <annevk> | no |
| 10:04 | <hsivonen> | no? |
| 10:04 | <annevk> | the issues is not about all browsers doing the same |
| 10:04 | <annevk> | it doesn't have to be fully deterministic |
| 10:04 | <hsivonen> | oh. what is it then? |
| 10:04 | <annevk> | the issue is more what to do in the case that the authors makes a NSResolver that halts the browser in some way |
| 10:05 | <hsivonen> | how has that issue been solved for treewalker node filters? |
| 10:05 | <annevk> | i don't think it has been |
| 10:06 | <Dashiva> | Well, how would halting the browser in a NSResolver be any different from halting the browser otherwise? |
| 10:06 | <hsivonen> | Gecko running scripts in the UI thread is an issue |
| 10:06 | <Lachy> | for the case of a hanging NSResolver, I assumed that would be dealt with the same way all hanging scripts in the browser, by eventually timing out and halting execution completely |
| 10:07 | <hsivonen> | bad scripts would be less harmful if each browsing context ran its layout and scripts on a private thread |
| 10:08 | <annevk> | you don't need threading for that |
| 10:09 | Philip` | wonders what happens if you use "yield" in an NSResolver |
| 10:09 | <hsivonen> | annevk: without threading you need code to reach a timeout checkpoint often enough |
| 10:09 | <Lachy> | what does yield do? |
| 10:10 | <Philip`> | Oh, actually, I suppose it wouldn't do anything very interesting at all |
| 10:10 | <Dashiva> | It returns, but preserves internal state for the next call |
| 10:10 | <Philip`> | Lachy: http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7#Generators_and_iterators |
| 10:13 | <Philip`> | I was thinking of something that preserves more than one stack frame, but that doesn't exist in JS so that's okay |
| 10:13 | <annevk> | hsivonen, code gets icky, yeah |
| 10:17 | <Philip`> | Even if you run code in separate threads, you need a way to cleanly terminate a thread when the user's bored with it sitting at 100% CPU, which makes code a bit icky too |
| 10:18 | <Philip`> | Except actually that's maybe only a tiny bit and you wouldn't even notice it |
| 10:24 | <hsivonen> | Philip`: well, yeah, you'd need a mechanism that makes sure that the killed thread isn't holding any monitors/semaphores/etc. that would be left in an inconsistent state |
| 10:24 | <annevk> | grmbl, my "we can't" argument is a real argument why we can't do </br> magic, but the overall reason is of course that it's silly and would be quite difficult, performance hit, etc. |
| 10:25 | <hsivonen> | Philip`: which isn't exactly trivial unless there are only a couple well-defined places where locking can happen |
| 10:26 | <hsivonen> | (BTW, this is the reason I haven't implemented Hixie's suggestion to limit the time a validation transaction is allowed to take instead of limiting the number of bytes Validator.nu is willing to ingest) |
| 10:46 | <Lachy> | Hmm. Jonas' suggestion to mention the hanging nsresolver case in the security section is a good idea... Oh, wait. It already is! |
| 12:17 | <hsivonen> | fwiw, in case anyone cares about arguing against a new HTTP verb for the ping feature: AJP 1.3 seems to assume a closed list of HTTP verbs, so minting a new one would have a non-trivial cost |
| 12:19 | <Lachy> | what's AJP? |
| 12:20 | <hsivonen> | Lachy: it's a protocol that Apache speaks with Java servlet containers |
| 12:21 | <Lachy> | ok, so it's something that would potentially be used on a server for dealing with pings. |
| 12:22 | <Lachy> | however, if you consider that adding a new HTTP verb can't be that much effort, and that any system to be set up for handling pings in the future could easily upgrade. It doesn't require all servers to be upgraded. |
| 12:22 | <Lachy> | the bigger problem with ping is getting client support |
| 12:23 | <hsivonen> | Lachy: unless I'm misreading the source of an AJP 1.3 implementation, it seems to me that AJP 1.3 communicates the HTTP verb as a single byte whose meaning has to be agreed to by both ends of the AJP pipe |
| 12:23 | <Lachy> | oh, in that case, it might be a little more difficult |
| 12:24 | <Philip`> | It just needs a single centralised service which understands the PING requests, and then every web developer can make use of that service to collect data and to retrieve summaries and reports |
| 12:24 | <hsivonen> | Lachy: I'm not saying it is good design. I'm just saying that there's a common deployment setup with which going beyond the WebDAV set of verbs is going to be expensive |
| 12:24 | <Philip`> | It's pointless for people to run the ping-processing software on their own servers |
| 12:27 | <Lachy> | Philip`, I don't think it's entirely pointless, but having a single centralised service might work for some system |
| 12:28 | <Lachy> | e.g. google analytics, which currently uses JS to notify the google server of certain events, could make use of ping in that way |
| 12:30 | <hsivonen> | http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html#method |
| 12:31 | <annevk> | given that webdav is still expanding i assume they'll eventually reconsider their api |
| 12:31 | <hsivonen> | note that is says "Later version of ajp13, when used with mod_jk2, will transport additional methods, even if they are not in this list." but mod_jk2 is dead and mod_jk is what people are supposed to be using again |
| 12:33 | <hsivonen> | annevk: perhaps. I'm just pointing out that considering the requirements Hixie had for the access-control implementability, a new HTTP verb is on a new level of difficulty |
| 12:34 | <hsivonen> | fwiw, the mechanism for encoding headers in AJP13 (I guess it's really 13 and not 1.3) is extensible |
| 12:34 | <hsivonen> | I think the failure to use the same mechanism for the verb is a design bug, but software has shipped |
| 13:25 | <annevk> | when do we get the ALA article about version targeting being all wrong? |
| 13:25 | <annevk> | or is it supposed to be one-sided? |
| 13:30 | <itpastorn> | How would you go about changing jeffrey Z's mind? |
| 13:31 | <Philip`> | annevk: http://www.alistapart.com/articles/theyshootbrowsers sounds non-positive about it |
| 13:32 | <annevk> | itpastorn, i'd put him on the QA team of non-IE browser for a year or two |
| 13:32 | <annevk> | Philip`, I was going by the summary on zeldman.com |
| 13:32 | <Philip`> | itpastorn: Hypnosis |
| 13:32 | <Philip`> | (since that requires less effort than thinking of logical arguments) |
| 13:37 | <itpastorn> | OK, so maybe we will get JZ and Eric Meyer to change their minds. Now, how would we get the MSIE team onboard? I seriously can't think of any way to change their minds. |
| 13:38 | <itpastorn> | As I see it now it is an issue of damage control |
| 13:38 | <Philip`> | Change their minds before releasing IE8? |
| 13:39 | <Philip`> | (Perhaps it's more possible to make their IE8 experience cause them to reconsider for IE9) |
| 13:39 | <Philip`> | ((like how IE7 made them reconsider IE8)) |
| 13:40 | <itpastorn> | Yes, the ball-and-chain effect of supporting multiple rendering modes will sooner or later take its toll |
| 14:27 | <hsivonen> | annevk: presumable setting a header ahead of GET could be specified to trigger pre-flight? |
| 14:27 | <hsivonen> | s/ble/bly/ |
| 14:39 | <annevk> | hsivonen, that's quite a neat idea |
| 14:52 | <annevk> | hsivonen, I put it on the list |
| 15:17 | <zcorpan> | annevk: do you know if there are any test cases for cssom .styleSheets in combination with @import? |
| 15:18 | <annevk> | i thought .styleSheets was not supposed to be populated with that |
| 15:21 | <annevk> | zcorpan, I don't really understand what you're asking for |
| 15:23 | <zcorpan> | sorry, i meant .styleSheet (on CSSImportRule) |
| 15:24 | <annevk> | no, feel free to add to http://tc.labs.opera.com/apis/cssom/ |
| 15:24 | <zcorpan> | ok |
| 15:28 | <zcorpan> | no directory structure? |
| 15:28 | <annevk> | feel free to do that for your tests |
| 15:29 | <annevk> | i was making tests to see how I should spec stuff and needed a place to dump them |
| 15:35 | <zcorpan> | ok |
| 15:35 | <annevk> | i'm not sure if it was the right approach |
| 16:11 | <zcorpan> | annevk: is .ownerNode null for imported style sheets? |
| 16:25 | <annevk> | yes |
| 16:31 | <zcorpan> | thanks |
| 16:31 | <zcorpan> | (that was not super clear to me reading the spec) |
| 16:34 | <annevk> | suggestions welcome |
| 16:34 | <annevk> | i'm not really sure how to phrase the conformance stuff for all that yet |
| 16:45 | <zcorpan> | can it be null in other cases? |
| 16:56 | <annevk> | HTTP Link: |
| 16:56 | <annevk> | <meta http-equiv=link> if we're keeping that |
| 16:57 | <annevk> | sorry |
| 16:57 | <annevk> | in the <meta> case it would not be null, duh |
| 16:58 | <Philip`> | It wouldn't be especially equiv to HTTP if it differed in that way |
| 16:59 | <annevk> | it's just a name |
| 18:36 | <Hixie> | i tried getting an account and it failed |
| 18:36 | <Hixie> | if anyone has a wordpress.com account |
| 18:36 | <Hixie> | it would be cool to ask this guy what it is he would actually like: |
| 18:36 | <Hixie> | http://mrpointy.wordpress.com/2008/02/19/ding-dong-the-frame-is-dead/ |
| 18:47 | <gsnedders> | wow. I can actually remember my user/pass combo. on just the second attempt |
| 18:48 | <gsnedders> | Hixie: + normal invitation to participate? :P |
| 18:51 | <gsnedders> | comment in moderation queue |
| 19:00 | <Hixie> | gsnedders: sure |
| 19:01 | <gsnedders> | dbaron: is there anything anywhere online about your table/desk based implementation of HTML? |
| 19:01 | <gsnedders> | I couldn't find anything googling for it |
| 19:01 | <dbaron> | no |
| 19:01 | <dbaron> | not that I know of, anyway |
| 19:02 | <gsnedders> | well, there are logs of here, but that isn't an overly convincing place to cite :) |
| 19:48 | <gsnedders> | Hixie: is there anything in acid3 that assures a tree DOM is being used, and not something like IE's? |
| 19:50 | <Hixie> | no, because html4 doesn't define how you handle the parse errors that get you a non-tree DOM |
| 19:53 | <gsnedders> | ergh. |
| 20:33 | gsnedders | looks through the X-UA-Compatible comments and sighs |
| 20:33 | <gsnedders> | "I code all my sites to be xhtml strict and I expect a browser to render them that way" — yes, because "xhtml strict" specifies rendering |
| 20:48 | <Hixie> | such comments indicate an incomplete understanding of the web, but their sentiment is well placed and i agree with it |
| 20:54 | <hsivonen> | Hixie: btw, did you see my results from validating the Happy Cog portfolio? |
| 20:55 | <Hixie> | yeah, briefly. it ended up in one of my folders. |
| 20:56 | <hsivonen> | ok |
| 22:30 | <Hixie> | Philip`: do you have any useful information on the cite="" attribute of q and blockquote elements? |
| 22:37 | <Philip`> | Hixie: Only that it's quite rare |
| 22:37 | <Philip`> | In 16K pages, I found it only on http://www.kentuckyinjurylawblog.com |
| 22:38 | <Philip`> | and on another 8K (at http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/attr/cite ) I didn't find it at all |
| 22:39 | <Philip`> | http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/tag/q - hmm, nobody uses <q> anyway |
| 22:39 | <Hixie> | so on your 16k pages, that's 100% of uses used it correctly! :-) |
| 22:39 | <Philip`> | http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/tag/blockquote - blockquote much more popular, but very rarely any attributes |
| 22:41 | <Dashiva> | Smells like indentation :) |
| 22:41 | <Hixie> | yeah |
| 22:43 | <annevk> | what's that like, the smell of presentational markup? |
| 22:44 | <annevk> | rather good looking, but crappy food |
| 22:45 | <roc> | I've never used blockquote with attributes, but always for quotations. Is that so wrong? |
| 22:45 | <Hixie> | no, that's fine |
| 22:47 | svl | has cite attributes automatically created in quoted replies on a message board system he wrote. |
| 22:50 | jgraham | wonders if <a rel="cite"> would generally be better than @cite |
| 22:53 | <annevk> | how about implicit rel=cite |
| 22:53 | <annevk> | paragraph scoped or some such |
| 22:54 | <jgraham> | ? In what sense implicit? |
| 22:55 | <annevk> | <p><a href=...>...</a> <q>...</q></p> |
| 22:56 | <annevk> | <a> is cite for <q> |
| 22:57 | <jgraham> | That seems like it could get messy fast <p>When I went to the <a href="">theatre</a>, I was reminded of the shakespeare quote <q>All the world's a stage</q></p> |
| 22:59 | <jgraham> | I guess <a rel=cite> doesn't work so well for replacing @cite because there's no way to attach the attribution to the quotation and it's usually the attribution that would be linked |
| 23:00 | <annevk> | labeledby! |
| 23:00 | <annevk> | or labelledby |
| 23:00 | <jgraham> | no comment :) |
| 23:01 | <Dashiva> | p contentof div |
| 23:01 | <annevk> | it seems both spellings are used by the accessibility community |
| 23:01 | <annevk> | awesome |
| 23:01 | <Dashiva> | Then you don't have to worry about where you place your stuff |
| 23:01 | <annevk> | http://www.google.com/search?q=labeledby+w3c |
| 23:01 | <annevk> | http://www.google.com/search?q=labelledby+w3c |
| 23:02 | <annevk> | aria ftw! |
| 23:02 | <Dashiva> | labeledby sameas labelledby |
| 23:03 | <jgraham> | Dashiva: Isn't contentof spelled "owns" |
| 23:04 | <Dashiva> | Not sure. Just offhand, I'd assume a div could own an element that wasn't part of its content. |
| 23:05 | <annevk> | Did you mean: pwns |
| 23:05 | <jgraham> | Dashiva: I think aria allows you to do <div id="a">This is my div</div><p owns="a">My div is somehow a child of this</p> |
| 23:05 | <jgraham> | annevk: :-) |
| 23:38 | <Hixie> | ok my plan is to keep cite="" basically unchanged from html4 |
| 23:53 | <Hixie> | can anyone find a word that can be used to describe the category to which the following things belong?: a book, a paper, a song, a movie, a TV show, a painting |
| 23:54 | <Hixie> | ...but that does not include: a person, a boat |
| 23:54 | <jgraham> | media? |
| 23:55 | <Hixie> | sadly "media" is even more overloaded that the word i've been using so far ("work") |
| 23:58 | <othermaciej> | "a work" is relatively accurate |
| 23:58 | <othermaciej> | particularly if backed by that list of examples |
| 23:58 | <Hixie> | yeah, that's all i could find so far |
| 23:58 | <Philip`> | Should it include things like plays, where it's not a written or recorded work that can be directly referenced? |
| 23:59 | Hixie | adds theatre productions, plays, operas, musicals to the list |
| 23:59 | <jgraham> | Most plays are written, no? But there are obviously other examples of oral traditions |