| 00:34 | <Hixie> | woot, i'm up to the parsing comments that were sent earlier this month! |
| 01:40 | <Philip`> | Woah, the HTML4 DTD has attributes 'datasrc', 'datafld', 'dataformatas' and 'datapagesize' as "reserved for possible future use" - I wonder what they were meant for... |
| 01:40 | <othermaciej> | weird |
| 01:40 | <othermaciej> | <object>? |
| 01:42 | <Philip`> | The first three are in span, div, object, input, select, textarea, button, table |
| 01:43 | <Philip`> | datapagesize is in table |
| 01:48 | <Hixie> | IE supports 'datasrc', 'datafld', 'dataformatas' and 'datapagesize' |
| 02:00 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%5B%26%23xd840%3B%26%23xdc00%3B%5D |
| 02:01 | <Hixie> | how sad |
| 02:01 | <othermaciej> | what do they do? |
| 02:02 | <Hixie> | all browsers except the latest firefox seem to treat �� as U+20000 |
| 02:03 | <jruderman> | mmm, surrogates |
| 02:05 | <Hixie> | dunno what to do about this |
| 02:06 | <Hixie> | i guess it's unlikely to be a compat problem |
| 02:06 | <Hixie> | i'll just make firefox3's behaviour the spec |
| 02:08 | <jruderman> | thanks, how nice of you :) |
| 02:08 | <othermaciej> | what's wrong with the all other browser behavior? |
| 02:08 | <othermaciej> | I'm guessing that's separate NCRs for the two parts of a surrogate pair for a single char? |
| 02:09 | <Hixie> | yeah |
| 02:10 | <Hixie> | actually the spec already requires this |
| 02:13 | <Hixie> | wtf are High Private Use Surrogates |
| 02:41 | <Lachy> | Hey Hixie, while you're looking at unicode stuff, I made a test page to test the upper/lowercasing algorithms. It seems that browsers get it wrong sometimes (though, my test could be wrong as well) |
| 02:42 | <Lachy> | http://lachy.id.au/temp/Unicode/case.html (it may take a while to load, XHR has to load a 1MB unicode data file) |
| 02:44 | <Hixie> | Lachy: i'm not really looking at unicode stuff, i'm just going down through the e-mail pile |
| 02:44 | <Lachy> | just ignore all the results for chars above U+10000, there's a limitation with JS |
| 02:44 | <Hixie> | happened to get to an e-mail of someone complaining about surrogates |
| 02:44 | <Lachy> | ok |
| 02:45 | <Hixie> | wow, firefox sucks on that test |
| 02:46 | <Lachy> | woah, Opera doesn't render the table properly |
| 02:51 | <Hixie> | hsivonen? |
| 02:52 | <Hixie> | hsivonen requested that we drop spaces that are around the <html> element, because XML drops them |
| 02:52 | <Hixie> | and he was concerned about round-tripping HTML5-XHTML5-HTML5 |
| 02:52 | <Hixie> | but dropping them makes the round-tripping through _HTML5_ much worse |
| 02:53 | <Lachy> | why? |
| 02:53 | <Hixie> | e.g. "<!-- --> <!DOCTYPE HTML> <html>...</html> <!-- -->" becomes "<!-- --><!DOCTYPE HTML><html>... </html><!-- -->" |
| 02:53 | <Hixie> | (in particular, imagine those as newlines) |
| 02:56 | <Hixie> | well |
| 02:56 | <Hixie> | based on my tests with the live dom inspector |
| 02:56 | <Hixie> | i'm the only who cares! |
| 02:56 | <Lachy> | that depends on how you serialise it, not whether those spaces are presentin the DOM |
| 02:57 | <Lachy> | and since the DOM doesn't retain text nodes outside the root anyway |
| 02:57 | <Hixie> | it used to :-) |
| 02:57 | Hixie | checks in a change to drop whitespace outside the DOM |
| 02:57 | <Lachy> | it used to in the spec, or in some implementation? |
| 02:58 | <Hixie> | spec |
| 03:16 | <Hixie> | wow, well here's a solid argument like none before it: |
| 03:16 | <Hixie> | Deprecating the embed element would make the standard more consistent and |
| 03:16 | <Hixie> | would make me feel better about the standard eventually. |
| 03:16 | <Hixie> | Not that I feel bad right now, that is. |
| 04:37 | <Hixie> | othermaciej, you might need to do another IANAL-but e-mail, this time explaining trademark law... :-) |
| 04:44 | <othermaciej> | Hixie: the legal standing of the W3C's trademark is so many steps removed from relevance to the discussion... |
| 04:44 | <othermaciej> | Hixie: but I'll explain it if I have to |
| 04:44 | <Hixie> | i was mostly kidding :-) |
| 04:45 | <Hixie> | they lost that trademark long ago, when they didn't sue me for calling the web apps spec's language "html5" and "xhtml5" |
| 04:47 | <othermaciej> | they don't claim a trademark on HTML |
| 04:47 | <othermaciej> | and yes, I doubt most of the language trademarks on that page would hold up |
| 04:47 | <othermaciej> | CSS, DOM, SVG, XHTML, no one cites their trademark when referring to those |
| 04:47 | <Hixie> | yeah, they used to claim the trademark but stopped around 2001 |
| 04:47 | <Hixie> | iirc |
| 04:48 | <Hixie> | probably had a lawyer laugh at them :-) |
| 05:06 | <Lachy> | Hixie, regarding your last post about versioning on public-html, I wouldn't call consistency with previous HTML versions a valid reason for versioning at all because it assumes that consistency actually achieves something useful |
| 05:07 | <Hixie> | it was consistency with future versions that was being suggested i think |
| 05:08 | <Hixie> | but as a general rule, it's good to give the "other side" in a debate the impression of having won something... admitting defeat on an irrelevant and worthless argument is a good way to win the argument overall. |
| 05:08 | <Lachy> | then it's even less valid, because the assumption is the future revisions will need to add versioning |
| 05:08 | <Lachy> | ok |
| 05:08 | <Hixie> | i agree that it's a ridiculuous argument. that's why's it a good one to agree about. |
| 05:08 | <Hixie> | :-) |
| 05:09 | <Hixie> | (that's one reason to never give the other side _all_ your arguments -- only to give the strong ones -- because then they are forced to either disagree with everything, or to give you a strong argument if they do what i just described) |
| 05:10 | <Hixie> | (and if they disagree with everything, then they look like they're being unreasonable, and then the clueless people who come in and try to be "reasonable" by giving "compromises" invariably take one of the things you said as a way to give you an argument |
| 05:10 | <Hixie> | which is then a strong argument, since you didn't give them the weak ones to pick from) |
| 05:10 | Lachy | is confused |
| 05:45 | <Hixie> | so... someone pointed out that "character entity reference" was being misused in the HTML5 spec |
| 05:45 | <Hixie> | since there's no DTD or anything |
| 05:45 | <Hixie> | what should we call them instead? |
| 05:54 | <Lachy> | just call them character references |
| 05:55 | <Hixie> | and drop the word "entity"? |
| 05:55 | <Hixie> | hmm, that could work |
| 05:56 | <Lachy> | the problem is calling &#nnnn; and &#xnnnn; entities is wrong. In SGML and XML, &foo; is an general entity ref. &, for example, is commonly called a character entity ref because it only contains 1 char |
| 05:57 | <Lachy> | but officially, there is no such thing as a character entity ref in SGML or XML |
| 05:57 | <Hixie> | yeah, mike explained that on the list |
| 05:57 | <Lachy> | ok |
| 05:57 | <Hixie> | there's a numeric character reference and a character entity reference |
| 05:57 | <Lachy> | yeah |
| 05:58 | <Lachy> | I recommend only using entity when you need to distinguish between &#...; and &foo; |
| 05:59 | <Hixie> | well, we'll see what replies i get to the thread |
| 06:53 | <Hixie> | ok how the hell do i do this |
| 06:53 | <Hixie> | complete this sentence: |
| 06:53 | <Hixie> | <p>The contents of CDATA and RCDATA elements must... |
| 06:54 | <Hixie> | ...in a way that defines that they can contain pairs of <!-- and --> (which can overlap) and that </endtags> that aren't escaped by those pairs are not ok |
| 06:58 | <jruderman> | why does it have to be a sentence, rather than a paragraph, and why does it have to start that way? |
| 06:58 | <Hixie> | it doesn't. in fact i'm up to three paragraphs so far. |
| 06:59 | <Hixie> | i was just phrasing it as a quiz show question :-) |
| 07:01 | <karlUshi> | just for the record. Hixie didn't decide to call it html5 |
| 07:01 | <karlUshi> | in fact it has been suggested by someone else |
| 07:01 | <karlUshi> | :) anyway |
| 07:01 | <karlUshi> | childish |
| 07:02 | <Hixie> | ? |
| 07:02 | <Hixie> | didn't decide to call what html5? |
| 07:03 | <karlUshi> | webapps 1.0 |
| 07:03 | <Hixie> | the whatwg language was called html5 before the whatwg was announced |
| 07:03 | <Hixie> | in fact howcome suggested it to me when we had dinner after my interview at opera back in 2003 |
| 07:03 | <Hixie> | or 2002 |
| 07:03 | <Hixie> | 2003 i think |
| 07:03 | <Hixie> | which was about a year before we started web apps 1.0 |
| 07:05 | karlUshi | will abstain to talk :) for the benefits of everyone. |
| 07:05 | <Hixie> | the spec itself was called "web apps 1.0" (as opposed to "html5" as it is now) for various political reasons, but it claimed to define html5 since the very start, as far as i recall |
| 07:11 | <jruderman> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=385434 |
| 07:11 | <Hixie> | interesting idea |
| 07:24 | <othermaciej> | that is a good idea |
| 07:24 | <othermaciej> | especially with the fragment ID being used to simulate "AJAX history" |
| 07:24 | <Hixie> | woot, the HTML parser folder is empty! |
| 07:24 | <Hixie> | now for the input-for-whatwg-html-parsing-rules-encoding folder. |
| 07:25 | <Hixie> | maybe i should go home first |
| 07:25 | <Lachy> | I just checked in a whole bunch of new and revised examples. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.src.html?content-type=text/html;%20charset=utf-8 |
| 07:25 | <othermaciej> | that would be advisable yes |
| 07:25 | <othermaciej> | I am happy with the way HTML5 is coming along |
| 07:25 | <Hixie> | glad to hear it |
| 07:25 | <othermaciej> | (though I have only been able to pay ~3% of my attention to it the past few weeks) |
| 07:29 | <Hixie> | bbl |
| 08:12 | <Hixie> | hsivonen: yt? i was wondering if you had any opinions on whether we should continue the way we have for the encoding detection or if we should require the algorithm you suggested back in march last year where we basically do the encoding detection in the main parser and then rewind if necessary |
| 08:15 | <Lachy> | Hixie, do you mean this one? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-March/005989.html |
| 08:17 | <Hixie> | yeah |
| 08:17 | <Hixie> | it |
| 08:17 | <Hixie> | er |
| 08:17 | <Hixie> | it's tempting to just use that, but it's more complicated to implement |
| 08:17 | <Hixie> | also i'm not really sure how you would handle event handlers and stuff like that |
| 08:18 | <Hixie> | i mean, we'd need to raise the REWIND flag in a _lot_ of places |
| 08:18 | <othermaciej> | what would REWIND do? reparse from scratch? |
| 08:19 | <Hixie> | yeah |
| 08:19 | <Hixie> | see the algorithm proposed in the e-mail above |
| 08:19 | othermaciej | reads |
| 08:19 | <Hixie> | how does safari actually implement encoding detection? |
| 08:21 | <othermaciej> | it's changed semi-recently so my knowledge of it may be out of date |
| 08:22 | <Hixie> | what source file is it in? |
| 08:23 | <othermaciej> | (reading the algorithm) |
| 08:23 | <othermaciej> | it's in WebCore/loader/TextResourceDecoder.cpp |
| 08:24 | <othermaciej> | (mostly) |
| 08:25 | <othermaciej> | One part of hsivonen's algorithm definitely needs changing |
| 08:25 | <othermaciej> | "If the tentative encoding name does not identify a rough ASCII |
| 08:25 | <othermaciej> | superset supported by the UA, emit a hard parse error and perform |
| 08:25 | <othermaciej> | implementation-specific heuristics." |
| 08:25 | <othermaciej> | UTF-16 needs to be handled as UTF-8 in such cases for web compatibility |
| 08:26 | <othermaciej> | I guess you could call that an implementation-specific heuristic |
| 08:26 | <Hixie> | good to know |
| 08:26 | <othermaciej> | I know we discovered at some point that Firefox appears to do a full parse and rewind |
| 08:27 | <othermaciej> | we used to have a dumbed-down preparse, and I think we still do, but we are considering changing |
| 08:27 | <othermaciej> | or maybe doing the preparse but also rewinding parsing if we hit a <meta charset> |
| 08:27 | <Lachy> | yes, regardless of how big the file is, a <meta charset=""> anywhere will cause a reparse if the declared encoding is incompatible with Win 1252 |
| 08:27 | <Lachy> | (or something like that) |
| 08:29 | <Hixie> | but is the reparse done despite scripts having run? |
| 08:29 | <Lachy> | yes |
| 08:29 | <Hixie> | lovely |
| 08:31 | <Hixie> | sounds like what we want to do is have an optional dumb preparse, then if that was skipped or if it didn't find an encoding, default to some encoding and start parsing, and if you hit a charset declaration that disagrees with the current one (notwithstanding UTF-16) then you start over (only doing that for the first charset seen) |
| 08:32 | <Lachy> | hmm. I can't get FF to execute the script twice, but IE will |
| 08:32 | <Hixie> | really? |
| 08:32 | <Hixie> | how are you testing? |
| 08:34 | <Hixie> | also i guess you would only reparse if one of the bytes you saw was incomptaible |
| 08:34 | <Lachy> | yes |
| 08:34 | <Hixie> | no point reparsing if you've not seen a disagreeable byte, as it were |
| 08:34 | <Lachy> | <!DOCTYPE html>©<script>alert("Hi");</script><meta charset="ISO-8859-2"> (save as ISO-8859-1) |
| 08:35 | <Lachy> | also, IE remembers the last encoding it used for the file, so it won't do a reparse if you hit reload |
| 08:35 | <Hixie> | does the byte in mozilla when you do that look like (c)? |
| 08:36 | <Lachy> | no, it interprets it as 8859-2: Š |
| 08:36 | <Hixie> | without running the script twice? it must have some sort of dumb preparser |
| 08:36 | <Hixie> | try sticking 2k of text before the byte |
| 08:36 | <Hixie> | i saw something about a 2k buffer when i was just browsing the mozilla code a few minutes ago |
| 08:38 | <Lachy> | yes, it reparsed it that time |
| 08:39 | <Hixie> | does it also do it if you don't have the (c) byte? |
| 08:41 | <Lachy> | yes |
| 08:41 | <Hixie> | interesting |
| 08:42 | <Hixie> | thanks |
| 08:42 | <Hixie> | i think this will work pretty well |
| 08:42 | <Hixie> | it's compatible with what browsers do, and allows for interesting optimisations |
| 08:43 | <Hixie> | this = what i proposed above, slightly tweaked to take into account what you've found out |
| 08:43 | <Lachy> | I prefer the algorithm in the spec already since it's much saner and easier to implement |
| 08:44 | <Lachy> | would hsivonen's algorithm handle cases like <script>document.write("<meta charset='ISO-8859-2'>");</script>? |
| 08:50 | <Hixie> | yeah, we would keep the algorithm in the spec |
| 08:50 | <Hixie> | we'd just add that if you hit a <meta> later, you reparse in certain cases |
| 08:50 | <Hixie> | i don't propose using henri's idea |
| 08:51 | <Hixie> | my notes are as follows: |
| 08:51 | <Hixie> | have an optional dumb preparse, allow it to use more than 512 bytes |
| 08:51 | <Hixie> | if it found an encoding, let "tentative" be that encoding |
| 08:51 | <Hixie> | if it was skipped, or if it didn't find an encoding, |
| 08:51 | <Hixie> | let "tentative" be the last encoding used for this page, |
| 08:51 | <Hixie> | or some other default |
| 08:51 | <Hixie> | begin parsing using "tentative" as the encoding |
| 08:51 | <Hixie> | if you hit a <meta> tag that defines the encoding |
| 08:51 | <Hixie> | which disagrees with the current, |
| 08:51 | <Hixie> | reparse with that encoding (except treat "UTF-16" as "UTF-8") |
| 08:51 | <Hixie> | optionally: if no bytes that differ between the encodings has yet been |
| 08:51 | <Hixie> | found, just replace the decoder in place and don't reparse |
| 08:52 | <Hixie> | to reparse, use the session history things that save state |
| 08:53 | <Hixie> | i wonder if people realise that a version="" attribute won't help XHTML2 since the DOM node interfaces are decided by tagname and namespace, unaffected by attributes |
| 08:54 | <Hixie> | unless they want to play with HTMLHtmlElement as well |
| 08:55 | <othermaciej> | I would be more worried about this if there were any sign of anyone wanting to implement XHTML2 |
| 08:56 | <Hixie> | indeed |
| 08:56 | <zcorpan> | Hixie: is it possible to build a dom with "=" as attribute name? |
| 08:57 | <Hixie> | it is in HTML5, sure |
| 08:57 | <Hixie> | <x => |
| 08:57 | <zcorpan> | but not with dom apis like setAttribute? |
| 08:58 | <Hixie> | seems browsers raise an exception for that |
| 08:59 | <zcorpan> | ok |
| 09:03 | <zcorpan> | Hixie: i know some entities require a semi-colon even in attributes -- that's what i wrote ("a third column that says which entities always require a semi-colon", i.e. both in attributes and in content) |
| 09:03 | <Lachy> | for <x =>, couldn't it just drop the attribute entirely? |
| 09:04 | <Lachy> | actually, for that IE creates an attribute with no name and no value |
| 09:05 | <Lachy> | FF drops it |
| 09:05 | <zcorpan> | Lachy: old news ;) |
| 09:05 | <Hixie> | zcorpan: ah ok |
| 09:16 | <zcorpan> | Hixie: although what is specced now has the same result as what i proposed, so the spec is fine |
| 09:19 | <zcorpan> | Hixie: btw, the innerHTML algorithm is used when scripting is disabled... iirc Genshi implements the innerHTML algorithm for serializing to html |
| 09:27 | <Hixie> | the html fragment serialising algorithm? |
| 09:27 | <Hixie> | hm |
| 09:27 | <Hixie> | wonder if that works well |
| 09:28 | <Hixie> | might be a problem if you have <noscript></noscript> ... </noscript> in a document |
| 09:34 | <zcorpan> | it probably doesn't, but i wouldn't be surprised if more people implement the fragment serialising algorithm for no scripting contexts... so if the algorithm took it into account then it might lead to less buggy tools |
| 09:37 | <Hixie> | yeah |
| 09:37 | <Hixie> | might just need two modes |
| 10:24 | Hixie | waits for othermaciej to explain that having "html|*:not([version=2]) " at the start of every selector in the UA stylesheet isn't going to scale well |
| 10:24 | <othermaciej> | Hixie: I hope that's a joke |
| 10:25 | <Hixie> | i take it you haven't seen the reply to your last mail |
| 10:25 | othermaciej | facepalms |
| 10:25 | <Hixie> | it was put quite that way |
| 10:26 | <mpt> | You're almost making me wish I was subscribed to the html-wg mailing list |
| 10:27 | <mpt> | but doubtless there are more efficient sources of humor |
| 10:28 | <Hixie> | yeah, public-xhtml2 has a much higher humor-per-mail quotient |
| 10:28 | <Hixie> | oops, did i say that out loud |
| 10:32 | <annevk> | <meta http-equiv> requirements are a bit odd |
| 10:32 | <Hixie> | yeah i wondered if i should allow <meta charset> in there too |
| 10:32 | <Hixie> | but that seemed dangerous |
| 10:32 | <annevk> | "it must be either in a <code>head</code> element" "Otherwise, it must be in a <code>head</code> element." |
| 10:32 | <annevk> | is what I meant |
| 10:33 | <Hixie> | hm? |
| 10:33 | Hixie | looks |
| 10:34 | <Hixie> | what's the problem? |
| 10:34 | <annevk> | it says the same thing twice? |
| 10:34 | <Hixie> | oh, i see, the "otherwise" clause is unclear |
| 10:34 | <Hixie> | i'll change it to just "if it doesn't have..." |
| 10:35 | <othermaciej> | I pointed Jirka to the mozilla and webkit source code |
| 10:35 | <othermaciej> | in case he'd like to make comments about what is doable in browsers that are actually informed |
| 10:36 | <Hixie> | i'm sure that will go down well |
| 10:37 | <othermaciej> | I also gave a more concrete example where a version attribute cannot possibly help resolve a namespace clash |
| 10:38 | <Hixie> | annevk: fixed |
| 10:38 | <zcorpan> | Hixie: i can't think of use-cases for <noscript><meta name>, however i don't see a good reason to disallow it either |
| 10:39 | <Hixie> | othermaciej: nice example |
| 10:39 | <Hixie> | zcorpan: shouldn't the metadata not change based on whether scripting is enabled? |
| 10:39 | <zcorpan> | dunno |
| 10:39 | <zcorpan> | perhaps |
| 10:40 | <Hixie> | if you feel it should change, send mail, it wouldn't take much to make me change the spec |
| 10:40 | <Hixie> | i agree with your mail about entities |
| 10:40 | <Hixie> | i wonder what the people who care will say |
| 10:46 | <zcorpan> | Hixie: why are the <!-- and --> in (R)CDATA allowed to overlap when they are not allowed to overlap in PCDATA? (i.e. from a conformance POV) |
| 10:48 | <annevk> | we're seriously debating <html version=> now? |
| 10:48 | <annevk> | wow |
| 10:48 | <othermaciej> | annevk: mainly whether it would miraculously allow XHTML5 and XHTML2 to share the same namespace |
| 10:49 | <annevk> | http://www.itwriting.com/blog/?p=257 is interesting |
| 10:50 | <zcorpan> | xhtml2 already has the version attribute. if they think it's enough to trigger different handling of xhtml2, then all is well already. |
| 10:54 | <Hixie> | sweet! only 371 days to go! |
| 10:54 | <Hixie> | http://www.apple.com/trailers/disney/walle/hd/ |
| 10:54 | Hixie | does a little dance |
| 10:55 | <othermaciej> | so you're not as interested in ratatouille? |
| 11:07 | <annevk> | is 0x0D equal to CR? |
| 11:10 | <othermaciej> | yes |
| 11:10 | <othermaciej> | (man ascii) |
| 11:10 | <Hixie> | othermaciej: i'm ecstatic about ratatouille. But I knew the release date last year. http://ln.hixie.ch/?start=1149918352&count=1 |
| 11:11 | <Hixie> | how can you not know that 0x0D / 13 is CR :-P |
| 11:11 | <othermaciej> | so you like to keep your countdowns one ahead? |
| 11:11 | <Hixie> | othermaciej: i just countdown as far as i can :-) |
| 11:11 | <Hixie> | othermaciej: more things to be excited about that way |
| 11:12 | <Hixie> | amusingly, june 29th is the release date of 3 things, two of which steve-jobs-related, and two of which movies |
| 11:12 | <Hixie> | only one of which i care about |
| 11:12 | <annevk> | so why does 0x0D become LF now? |
| 11:13 | annevk | thought browsers did not fix it up |
| 11:13 | <Hixie> | 0x0D wher? |
| 11:13 | <Hixie> | where, even |
| 11:13 | <annevk> | as character reference |
| 11:14 | <Hixie> | opera doesn't fix it up, ie drops it altogether, firefox and safari fix it up, css expects it to be fixed up |
| 11:14 | <Hixie> | (iirc) |
| 11:14 | <annevk> | k |
| 11:17 | <Hixie> | i have to say it amazes me that pixar can set release dates more than a year ahead |
| 11:17 | <Hixie> | and hit them, year after year |
| 11:18 | <Hixie> | i'm lucky if i can set release dates a week ahead, and i'm just one person with one little set of tasks |
| 11:24 | <annevk> | news just in: readyState = 2 -> HEADERS_RECEIVED |
| 11:24 | <annevk> | or does someone have a better name? |
| 11:26 | <Jero> | and HEADERS_RECEIVED is an array of all the headers the object received? |
| 11:26 | <annevk> | it's a state |
| 11:27 | <Hixie> | what was it before? |
| 11:27 | <Jero> | oh ok, i see what you mean now |
| 11:27 | <Jero> | sorry for the misunderstanding |
| 11:27 | <annevk> | currently we have UNSENT, OPEN, SENT, LOADING, DONE |
| 11:27 | <annevk> | SENT -> HEADERS_RECEIVED |
| 11:28 | <annevk> | but it would be nice if it was a little bit shorter |
| 11:28 | <Hixie> | what did i use for the media elements? |
| 11:29 | <annevk> | FRAME_AVAILABLE or something? or PLAY_THROUGH |
| 11:29 | <annevk> | but that's slightly different |
| 11:29 | <Hixie> | i thought i had one for headers only |
| 11:30 | <Hixie> | LOADED_METADATA |
| 11:30 | <Hixie> | i have EMPTY, (no equivalent for OPEN), LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED |
| 11:30 | <annevk> | ok, UNSENT, OPEN, LOADED_METADATA, LOADING, DONE |
| 11:31 | <annevk> | mjs suggested that EMPTY was not quite the same for XHR or so iirc |
| 11:31 | <annevk> | and DONE is there because it's also readyState = 4 when the request failed |
| 11:31 | <Hixie> | the problem with XHR having LOADED_METADATA, LOADING is that it's the opposite order |
| 11:31 | <Hixie> | which would be confusing |
| 11:31 | <annevk> | yeah, that too |
| 11:31 | <Hixie> | oh well |
| 11:32 | <annevk> | LOADED_HEADERS maybe? |
| 11:32 | <Hixie> | similar though, with a LOADING after a LOADED, bit confusing |
| 11:32 | <Hixie> | how about just HEADERS? |
| 11:33 | <Hixie> | UNSENT, OPEN, HEADERS, LOADING, DONE |
| 11:33 | <annevk> | sure |
| 11:33 | <Hixie> | not a verb, i guess |
| 11:33 | <annevk> | hmm |
| 11:33 | <Hixie> | or adjective |
| 11:33 | <Hixie> | or whatever those are |
| 11:33 | <annevk> | HEADERS_IN |
| 11:34 | <Hixie> | HEADERS_RECEIVED and HEADERS are my favourites so far |
| 11:38 | <Philip`> | About serialising: The HTML5 spec splitter uses the innerHTML fragment serialising algorithm too (or at least the version of the algorithm from ages ago) |
| 11:43 | <annevk> | http://lists.w3.org/Archives/Public/public-html/2007Jun/0543.html has that guy even remotely considered DOM interfaces? |
| 11:46 | <annevk> | besides the fact that the charter mentions to align more with browsers as opposed to diverging from them in weird ways |
| 12:33 | <Lachy> | Hixie, what is ratatouille and why are you so ecstatic about it? |
| 12:33 | Lachy | is downloading the trailer for Wall-E |
| 12:34 | <annevk> | hixie &heart; pixar |
| 12:34 | <Lachy> | is there a trailer for ratatouille somewhere? |
| 12:35 | <Lachy> | found it |
| 12:57 | Philip` | wonders if it's cruel to write tests that require globalCompositeOperation = darker to be unrecognised |
| 12:58 | <annevk> | weren't there proposals to keep that in? |
| 12:59 | <Philip`> | Yes, but it's not in the list at the moment so it mustn't be supported |
| 12:59 | Philip` | also checks for globalCompositeOperation=over being unrecognised, just so that Firefox fails |
| 13:00 | <annevk> | I suppose |
| 13:00 | Philip` | checks if anyone else is secretly supporting non-standard values |
| 13:08 | <Philip`> | Oh, FF does 'clear' too |
| 13:09 | <Philip`> | and WebKit does 'clear' and 'highlight' |
| 13:18 | <Philip`> | Hmm, interesting that 'clear' is supported in two of the three main browsersa, and it's the only Porter-Duff operator missing from the spec... I can't think of any possible use cases at all, though |
| 13:19 | <annevk> | maybe it was easy to implement? |
| 13:21 | <Philip`> | "CANVAS_OP_TO_CAIRO_OP("clear", CLEAR)" - the implementation in Gecko doesn't look that tricky |
| 13:24 | <Philip`> | and the entirety of WebKit's 'clear' implementation is: |
| 13:24 | <Philip`> | "clear", |
| 13:24 | <Philip`> | which isn't too tricky either |
| 13:26 | <annevk> | what does it do? |
| 13:27 | <Philip`> | It takes the source image, and the destination image, and then discards both of them and outputs transparent black |
| 13:28 | <Philip`> | I believe you can get exactly the same effect by doing "globalAlpha = 0; globalCompositeOperation = 'copy'" |
| 13:29 | <Philip`> | (Ah, looks like Opera is nice and doesn't support anything non-standard except for "darker") |
| 13:32 | <annevk> | we're a likably product :p |
| 13:33 | <Philip`> | Opera does incorrectly accept strings like "source-over\0", though :-p |
| 13:35 | <annevk> | I suppose we strip \0 before it's passed... |
| 13:35 | <annevk> | hmm |
| 13:36 | <Philip`> | If I remember correctly, everything after the \0 gets stripped off too |
| 14:13 | Philip` | wonders what makes Opera dislike <canvas>x<canvas>y</canvas>z</canvas> |
| 14:22 | <Dashiva> | Would that ever be useful fallback? |
| 14:25 | <Philip`> | I'm not sure about 'useful', but it could be used - if you have non-interactive static visual media, and you paint on the inner canvas but not the outer one, then it would use the fallback content for the outer one and would display the inner one |
| 14:26 | <Philip`> | but as far as I can see, that's the only situation in which you'd ever see the inner canvas |
| 14:26 | <Dashiva> | I don't understand that example, what triggers fallback on the outer one? |
| 14:27 | <Philip`> | "In non-interactive, static, visual media, if the canvas element has been previously painted on ... then the canvas element must be treated as embedded content with the current image and size. Otherwise, the element's fallback content must be used instead." |
| 14:28 | <Dashiva> | So you'd have to paint on it somewhere else, and then adoptNode or similarly move it to the static media? |
| 14:30 | <Philip`> | I think you could just have a script that's run by the static-media UA and does getElementsByTagName('canvas')[1].getContext('2d').fillRect(0, 0, 300, 150) or whatever, in order for it to become "previously painted on" |
| 14:34 | <Philip`> | I can't think of any situations at all in which anyone would want to do that, though |
| 14:35 | <Philip`> | (but it'd be nice if it worked correctly anyway :-) ) |
| 14:35 | <Dashiva> | Yeah, I have problems imagining "previously" combined with "static, non-interactive" |
| 14:36 | <Philip`> | As I understand it, it's the media that's static and non-interactive - you could have a real web browser that loads the page and runs scripts, and then renders the result to a (static, non-interactive) PDF file |
| 14:37 | <Dashiva> | Aha |
| 14:38 | <Dashiva> | That at least makes sense. |
| 14:44 | <annevk> | so what exactly do we do for nested <canvas> elements that is not expected? |
| 14:45 | <annevk> | actually, I believe we have some bugs in the way we parse <canvas> elements |
| 14:45 | <annevk> | "bugs" as parsing for HTML was not really defined until HTML5 came along |
| 14:46 | <annevk> | (Entity handling in html5lib is now per the specification.) |
| 14:46 | <annevk> | (Except for some special character range, fwiw.) |
| 14:47 | <Philip`> | That case gives a (empty) canvas element followed by a "y", when it should give one containing "x (canvas y) z" - presumbly it just looks for the first </canvas>, instead of actually parsing the content |
| 14:48 | <annevk> | followed by a "z" you mean? |
| 14:48 | <Philip`> | At least Opera is no more broken than IE/excanvas, which just looks for the first "/canvas" element :-) |
| 14:48 | <Philip`> | Oops, yes |
| 14:49 | <annevk> | we parse it similar to iframe I think |
| 14:49 | <annevk> | well, those type of elements |
| 14:50 | <Philip`> | Ah, okay - looks like it's handled like iframe, when (I think) it ought to be handled like object instead |
| 14:50 | <annevk> | i agree, we have some bug report on the matter |
| 14:51 | <annevk> | well, prolly not <object> exactly as <object> is quite hairy too iirc |
| 15:32 | <Lachy> | Hixie, I just watched the trailers and preview for ratatouille. It looks like an awesome movie |
| 16:38 | <Lachy> | I have the selectors api naming narrowed down to 7 pairs of names, having written detailed justification for rejecting the other ~30 :-) |
| 16:43 | <Dashiva> | Lachy: In other words, all the good ones are gone :) |
| 16:43 | <Lachy> | no, the crap ones have been rejected |
| 16:44 | <Lachy> | These are the remaining choices: |
| 16:44 | <Lachy> | matchSingle() matchAll() |
| 16:44 | <Lachy> | matchOne() matchAll() |
| 16:44 | <Lachy> | getElement() getElementList() |
| 16:44 | <Lachy> | getElement() getElements() |
| 16:44 | <Lachy> | selectElement() selectElementList() |
| 16:44 | <Lachy> | selectOneElement() selectAllElements() |
| 16:44 | <Lachy> | chooseOne() chooseAll() |
| 16:46 | <Lachy> | anyone have any preferences from that list? |
| 16:48 | <Philip`> | Is selectElement+selectAllElements not a choice? |
| 16:50 | <Lachy> | Philip`: that's a close call. I had to reject some simply because they were very similar to other options that were considered equal, and I felt the slight inconsistency between the names was good reason at that point |
| 16:51 | <Lachy> | so it was only barely rejected |
| 16:55 | <Philip`> | I guess I kind of like 'select' since it looks easy to remember when I forget the exact name but know I want to find that function that's like CSS selectors; and 'selectOneElement' sounds unnecessarily verbose compared to 'selectElement'; and 'selectElementList' is vague whereas 'selectAllElements' is self-descriptive |
| 16:55 | <Philip`> | But I don't have any strong feelings :-) |
| 16:55 | <Lachy> | oh, good point |
| 16:56 | <Lachy> | ok, I'll switch selectOneElement for selectElement |
| 17:05 | <hallvors> | IMO 'selectElementList' is clearer than 'selectAllElements', I'd assume the latter did the same as getElementsByTagName('*') |
| 17:10 | <Philip`> | hallvors: But you wouldn't normally see just the function name by itself - you'd see something like "selectAllElements('h1')" or "selectAllElements('[class|="shadow"]')", and then it'd be obvious that it's not just selecting all the elements in the document |
| 17:11 | <Lachy> | the other option is selectElement() and selectElements(), but I think they look too similar and make editing and reviiewing more difficult |
| 17:12 | <Lachy> | do you consider selectElement to be better than getElement? |
| 17:12 | <Dashiva> | Has overloading (e.g. function selectElement(selector, selectall=true)) been considered and rejected? |
| 17:13 | <Philip`> | (Assuming that [class|="shadow"] thing actually works, I guess that'd be nice for the Unobtrusive JavaScript people so they can just add class="shadow-25x25" and easily scriptise things) |
| 17:13 | <Lachy> | Dashiva: yes. That would require the method to change its return type based on a parameter, which isn't good |
| 17:13 | <Dashiva> | Ah right, JS match returns array in both cases |
| 17:13 | <Lachy> | document.evaluate() does that for DOM3 XPath, but I don't think that's particularly good design |
| 17:14 | <Lachy> | yeah, selectElement() would return a single element, selectAllElements() would return a static node list |
| 17:14 | <annevk> | hallvors on IRC, yay! |
| 17:14 | <Philip`> | getElement sounds vague again to me - with something like getElementById or (once you've heard of it at least once) selectElement, the name tells you how it decides which element you want, which makes it easier to remember |
| 17:15 | <Dashiva> | I agree, getSomething is too vague without a BySomething |
| 17:15 | <Lachy> | that rationale for getElement is that it's like a superset of all existing getElementBy* methods |
| 17:16 | <Dashiva> | But since it doesn't let you get an id without prefixing #, it's not a true superset |
| 17:16 | <Lachy> | a superset in functionality, not in syntax |
| 17:17 | <Philip`> | Will people still use the old getElementBy* functions? It seems slightly nicer to still say getElementById(variablething) rather than getElement('#'+variablething) |
| 17:18 | <Philip`> | (particularly if you have IDs with spaces in them) |
| 17:18 | <annevk> | IDs with spaces are non-conforming |
| 17:19 | <Philip`> | People might still use them, and be unhappy that it gets mangled by the CSS-selector parser when all they want is an exact string match |
| 17:19 | <hallvors> | Philip`: good point, I like the name with some more context |
| 17:19 | <Lachy> | IDs with spaces can be escaped as #foo\ bar |
| 17:20 | <Lachy> | hallvors: which name do you like? |
| 17:20 | <Philip`> | Lachy: But then you'd have to write a function to do CSS escaping, which is probably non-trivial and will probably be done wrong, and it's much safer to stick with getElementById when you just want to match IDs |
| 17:21 | <Lachy> | oh, does gEBId allow spaces? |
| 17:21 | <Lachy> | HTML doesn't allow spaces |
| 17:21 | <Lachy> | I don't know of any language that does |
| 17:21 | <hallvors> | At first I preferred selectElementList over selectAllElements, but the examples changed my mind. |
| 17:22 | <hallvors> | so now I think selectAllElement is better of the two.. |
| 17:22 | <Lachy> | do you think it's better than the other 5 alternatives as well? |
| 17:24 | <Philip`> | Lachy: id="x y" ... getElementById('x y') seems to work perfectly well in browsers, which is usually much more interesting than whether it's meant to be allowed :-) |
| 17:24 | <Dashiva> | I don't like match because it crosses over into regexp language. choose doesn't really fit. Among the rest, I prefer select over get, because it is about selectors after all. |
| 17:24 | <annevk> | getElement("#x\u20y") will also work likely |
| 17:24 | <Lachy> | I was more concerned about whether gEBId() threw an exception, than the validity if the syntax |
| 17:25 | <annevk> | given that \u20 is the correct escape |
| 17:25 | <Philip`> | Lachy: Ah, okay - seems to work happily with no exceptions |
| 17:25 | <Philip`> | annevk: Wouldn't that have to be getElement("#x\\u20y") ? |
| 17:25 | <annevk> | Philip`, btw, any chance you can e-mail me with the changes I missed in html4-differences and maybe also with the script you used? |
| 17:25 | <Lachy> | annevk: \u20 is a JS escape for a space char, that won't be seen by the selector parsor |
| 17:26 | <Lachy> | it would be equivalent to "#x y" |
| 17:26 | <annevk> | Philip`, yeah, fair enough |
| 17:27 | <Philip`> | IE throws exceptions on "x\u20y" because it wants "20y<EOF>" to be a hex string |
| 17:27 | <Lachy> | oh, you need \u0020 |
| 17:30 | <Lachy> | you would actually need to use ("#x\\\u0020y"), though "#x\\ y" is easier |
| 17:31 | <Philip`> | annevk: http://krijnhoetmer.nl/irc-logs/html-wg/20070622#l-47 is all the bits I noticed originally that weren't mentioned |
| 17:31 | <Philip`> | http://canvex.lazyilluminati.com/misc/htmldiffs.pl is the script, though it's rather ugly and hacked-together and I gave up trying to keep it even vaguely clean when I was half way through |
| 17:31 | <Philip`> | (Should I email these links?) |
| 17:32 | <annevk> | preferably |
| 17:32 | <annevk> | maybe I'll just write a small python script that parses your results page though :) |
| 17:32 | <annevk> | and turns it into an HTML table |
| 17:33 | <Philip`> | The code in the bottom third of the script that produces the output should be relatively easy to read and modify into a different format, if you ignore the few lines that have too much syntax on them :-) |
| 17:35 | <annevk> | whoa, did the real Philip Taylor just post to publib-html? :D |
| 17:35 | <annevk> | Philip`, hmm, it's in Perl though |
| 17:36 | <Philip`> | The original list of non-mentioned things is probably missing a few bits since I fixed my code, so I'll re-check that this evening and send the list to you |
| 17:38 | <Philip`> | I did post, just so I can confuse everyone who doesn't realise there's two people with one name rather than one person with multiple personalities |
| 17:39 | <Philip`> | Perl isn't that bad, as long as you skip over the pieces like [@{$attrs4s{$e}||[]}, @{$attrs4t{$e}||[]}] :-p |
| 17:40 | <Dashiva> | You mean there are other pieces? |
| 17:40 | <Lachy> | Woo Hoo! I think I have made my final decision :-) |
| 17:41 | <annevk> | getElement and getAllElements? |
| 17:42 | <annevk> | match and matchAll? |
| 17:42 | <Philip`> | If it's a final decision, you shouldn't actually tell anyone what the decision was, because there's nothing they could do other than argue for changing the decision :-) |
| 17:42 | <Lachy> | I know, that's why I didn't say what it is yet |
| 17:42 | Dashiva | sharpens axe |
| 17:43 | <Lachy> | you can all wait till I finish writing the rationale and send it to public-webapi |
| 17:46 | hallvors | is patient |
| 17:46 | <Lachy> | now the final issue in the spec is to finish reviewing, editing and adding examples. Then I can get it republised as a WD and then hopefully go LC in a few weeks |
| 17:46 | <Dashiva> | How much of the total time has gone to name selection? |
| 17:47 | <Lachy> | a few hours per day over the last 3 days |
| 17:48 | <Lachy> | a lot of it was spent reading through about 300 emails on the topic |
| 17:53 | <Dashiva> | Where is the line between "If we /provide/ version information, we allow others to make use of it" and "we /encourage/ others to make use of it", I wonder |
| 17:54 | <Philip`> | Perhaps "If we provide version information, others are more likely to make use of it" - the consequences are important, rather than the direction of the motivation |
| 19:08 | Lachy | is trying to figure out if Sam Ruby is being serious with his proposal for a new HTML MIME type: application/html ??? |
| 19:08 | othermaciej | links |
| 19:09 | <Lachy> | http://www.w3.org/mid/467BE62A.3060102⊙uic |
| 20:53 | <aa> | Hello. I was looking at HTML5 timers, and I was wondering if there is documentation somewhere about which browsers currently support which features. |
| 20:59 | <Philip`> | aa: The timers in http://www.whatwg.org/specs/web-apps/current-work/multipage/section-timers.html ? |
| 21:04 | <aa> | Philip`: yes, those are the ones |
| 21:05 | <aa> | like, for example, do all browsers currently support the extra args in the function pointer overload |
| 21:05 | <aa> | (I figure there must have been research on all these at some point) |
| 21:05 | <Philip`> | IE7 doesn't |
| 21:07 | <Philip`> | FF3 / Opera 9 do, and I expect much older versions of those supported it too, but I don't know if proper test results have been collected anywhere |
| 21:09 | <aa> | ok, thanks. |
| 21:11 | <Philip`> | (More specifically: I believe proper test results haven't been collected anywhere) |
| 21:14 | <hallvors> | oh do we? I actually thought we didn't :-p off to test.. |
| 21:14 | <hallvors> | javascript:void(setTimeout( function(a){alert(a)}, 100, 'hi' )); |
| 21:14 | <hallvors> | you're right :) |
| 21:14 | <aa> | We're going to put timers into Workers in Gears and was just wondering about support for comparison. We'll just do all of them. |
| 21:16 | <Philip`> | Firefox is fun because it passes an extra argument to the function, indicating how many milliseconds late it was |
| 21:16 | <aa> | yeah "fun". I have been bitten by that bug. |
| 21:17 | <othermaciej> | one thing that is weird about timers in browsers is that the rate at which they can fire is limited, due to OS limitations on windows and for compatibility on mac |
| 21:17 | <othermaciej> | dunno if the spec handles that |
| 21:18 | <othermaciej> | I think IE does not support the extra args in the function case and other browsers don't support the language parameter in the string case |
| 21:18 | <Philip`> | I believe browsers vary in terms of whether they run the function multiple times as fast as possible until it catches up with the requested rate, or if they just start dropping calls when they're too slow |
| 21:19 | <Philip`> | (Also, Firefox limits the time to be no less than 10msec) |
| 21:19 | <aa> | I think we are just going to implement it in terms of nsITimer on Firefox, so it will be whatever it does. Dunno about on windows. |
| 21:30 | <Philip`> | From some experiments I tried ages ago: On Windows (where various timer things have 16ms resolution), when doing setInterval(f, 1), everything (Opera, FF, Safari, IE) runs the function once every 16ms |
| 21:32 | <Philip`> | When the interval is larger, but the script takes a long time to run, FF remembers how far behind it is and then tries running once every 16ms until it has caught up. None of the other browsers do that - they always just wait another roundup(time, 16ms) before running the function again |
| 21:33 | <virtuelv_> | Philip`: You're _sure_ that's accurate? |
| 21:35 | <othermaciej> | Philip`: I think in Safari we only throttle to 10ms, not 16ms |
| 21:35 | <othermaciej> | Philip`: we don't rely on the Windows system call that would limit it to 16ms resolution IIRC |
| 21:36 | <othermaciej> | (could be wrong though) |
| 21:37 | <Philip`> | On Linux, Opera runs consistently at 10ms when I do setInterval(f, 1), and FF2 runs slightly less consistently at roughly 10-14ms |
| 21:37 | <Philip`> | (Hmm, looks like the interval-catchup has changed in FF3) |
| 21:38 | <othermaciej> | on windows the interval varies with the OS and whether you have a single CPU/core or multiple |
| 21:41 | <Philip`> | http://canvex.lazyilluminati.com/misc/timer.html - that does setInterval(f, 1), and does lots of computation for the first 64 repeats, then does nothing for the next 192, and reports the measured time intervals via Date() |
| 21:42 | <Philip`> | (On Windows, Date() is limited to 16ms resolution, but it should alternate between 16 and 0 if the function is being run more frequently than that) |
| 21:42 | <virtuelv_> | note that setInterval with lower than 15/16ms is wildly inaccurate |
| 21:42 | <Philip`> | In every browser in Windows (in VMware) I get lots of 16s at the end |
| 21:43 | <virtuelv_> | timers don't run more often either, fwiw |
| 21:44 | <virtuelv_> | The practical limit for Opera on Linux is 8 |
| 21:44 | <Philip`> | virtuelv_: Yep, it's just trying to find the maximum frequency which the browser will run at - they all seem to be limited to 16ms on Windows (and less limited on Linux) |
| 21:45 | <virtuelv_> | 16ms is the safe bet on any platform |
| 21:46 | <Philip`> | It's a bit of a pain when you're trying to write real-time games in a web browser :-( |
| 21:46 | <virtuelv_> | if you're doing animation, I'd probably just specify something to reach an acceptable target framerate |
| 21:46 | <virtuelv_> | 20,25 or so |
| 21:47 | <Philip`> | ...though fortunately my game ended up running at about 8fps, so timers weren't the problem that I had anticipated :-) |
| 21:47 | <virtuelv_> | then again, I have some code for a presentation library where I break my own rule, by specifying 0 |
| 21:47 | <virtuelv_> | for transitions and similar |
| 21:47 | <virtuelv_> | hm |
| 21:48 | <virtuelv_> | :) |
| 21:50 | <Philip`> | https://bugzilla.mozilla.org/show_bug.cgi?id=376643 |
| 21:51 | <Philip`> | Looks like that's why they stopped the try-to-catch-up-when-running-too-slowly behaviour in FF3 |
| 21:56 | <Philip`> | http://msdn2.microsoft.com/en-us/library/ms536753.aspx - hmm, did they even try running the second example there? |
| 22:02 | <Hixie> | Lachy: of course, ratatouille is the best movie of the year |
| 22:06 | Philip` | wonders if it's possible to get web browsers to load a 0x0 image |
| 22:06 | <Philip`> | (I don't think PNG can do that, but I'm not sure about other formats...) |
| 22:08 | <Philip`> | (Looks like JPEG probably can't do that either, given how it crashes when I try to save) |
| 22:21 | <Philip`> | Hmm, looks like it's not possible at all - I can construct a 0x0 BMP but they refuse to load it |
| 22:21 | <Hixie> | rofl @ the e-mail in www-html |
| 22:24 | <Hixie> | http://lists.w3.org/Archives/Public/www-html/2007Jun/0008.html |
| 22:37 | <othermaciej> | My favorite line: "The Christians took 325 years to produce their spec, before declaring a Rec at the Council of Nicaea." |
| 22:39 | <Hixie> | there are definitely some places where i was misquoted |
| 22:39 | <Hixie> | for example, not killing people has to be a MUST, not a SHOULD |
| 22:41 | <othermaciej> | thou MUST NOT kill |
| 22:41 | <Hixie> | ironcially, "thou shalt not kill" is very close to rfc2119 terminology |
| 22:41 | <othermaciej> | but what about the exception list? |
| 22:41 | <Hixie> | because 2119 defines "shall not" |
| 22:41 | <othermaciej> | oh yeah |
| 22:41 | <Hixie> | what exceptions? |
| 22:41 | <othermaciej> | self-defense? |
| 22:42 | <othermaciej> | I think we want to support that, at least as an option |
| 22:42 | <Hixie> | you shouldn't kill, even in self-defence |
| 22:42 | <Hixie> | valid concern, though |
| 22:42 | <Hixie> | i think Bible5 will be easier than SVG5, which the article claims i'll have already done by 2008 |
| 22:43 | <othermaciej> | with Bible5 you can just delete the mass of non-normative material and not much remains |
| 22:43 | <Hixie> | actually that was my first thought when i read it |
| 22:44 | <Hixie> | i was like "well that'll be a short book, if i write it" |
| 22:48 | <jgraham_> | Have you two considered a career in stand up if this web thing doesn't take off? |
| 22:49 | <jgraham_> | The feedline-punchline thing there worked for me anyway |
| 22:49 | jgraham_ | goes back to packing |
| 23:24 | <Philip`> | Hmm, this run-lots-of-tests-at-once-in-an-iframe system doesn't work too well when half the tests in this section make the browser crash |
| 23:50 | <webben> | Hixie: Yesterday you gave an example of a lack of definition in WAI-ARIA about what happens when a element declared as treeitem is a child of an element declared as checkbox, but I'm not quite sure what you meant. What are two of the alternate implementation possibilities you had in mind? |
| 23:56 | <Hixie> | i have no idea |
| 23:57 | <Hixie> | that's the problem |
| 23:57 | <Hixie> | i have no idea what browsers should do |