| 00:00 | <nickshanks> | zcorpan: i logged that against safari as 14423 |
| 00:00 | <zcorpan> | following ie/firefox would be to just say "act as if a p start tag with no attributes has been seen then reprocess the current token" or something |
| 00:04 | <zcorpan> | nickshanks: not closing tags in general (it's just </p> and </br> that are magic... except in ie...) and not style attributes specifically |
| 00:05 | <nickshanks> | oh, i misunderstood you then |
| 00:14 | <Hixie> | ok </p> and </br> magic is now in the spec |
| 00:14 | <Hixie> | annevk: would be cool if the web-apps-tracker had a way of showing the changelist going further back than the last N changes |
| 00:16 | Hixie | starts the daunting task of backporting all the changes to the parser spec into his year-old parser |
| 00:24 | <Hixie> | annevk: also cool would be a "next" link next to "I've read the changes!", so that you can go through the diffs one at a time |
| 00:25 | <othermaciej> | is annevk actually here? |
| 00:25 | <Hixie> | no idea but i'm sure he'll see the comments when he comes back online later if no |
| 00:25 | <Hixie> | t |
| 00:26 | <othermaciej> | I'd want to talk to him if he was, is all |
| 00:26 | <Hixie> | ah |
| 00:27 | <Hixie> | wow, still nobody has pointed out sebastian's faux pas |
| 00:28 | <othermaciej> | you mean that the more obvious solution would be to rename XHTML 2? |
| 00:29 | <Hixie> | yeah (http://krijnhoetmer.nl/irc-logs/whatwg/20070627#l-8) |
| 00:30 | <Hixie> | i wish i understood what the www-tag were talking about |
| 00:30 | <othermaciej> | in general? or is there some specific issue at hand? |
| 00:31 | <Hixie> | most of the discussion in www-tag is way over my head |
| 00:31 | <Hixie> | they're arguing about the meaning of "resource" as far as i can tell |
| 00:36 | <Hixie> | hahaha, his mail got +1ed! |
| 00:36 | <Hixie> | given my e-mail earlier today that's especially funny |
| 00:40 | <nickshanks> | i know what resource means |
| 00:41 | <nickshanks> | it's a data block referenced by a ResourceHandle :) |
| 01:20 | <zcorpan> | Hixie: please make stray </p> and </br> parse errors |
| 01:22 | <zcorpan> | s/<\/p> and // |
| 01:23 | <Hixie> | valid request! |
| 01:24 | <Hixie> | done |
| 01:30 | <zcorpan> | Hixie: stray </p> were already parse errors, apparently: "If the current node is not a p element, then this is a parse error." |
| 01:30 | <Hixie> | d'oh |
| 01:31 | <Hixie> | fixed |
| 01:34 | <zcorpan> | nn |
| 01:41 | <Philip`> | Lachy: In Selectors: s/consise/concise/ |
| 01:49 | <mpt> | I don't care about the name of HTML 5's XML serialization, I want to know what HTML 5's codename is going to be |
| 01:49 | <mpt> | HTML 3.2 was Wilbur |
| 01:49 | <mpt> | HTML 4.0 was Cougar |
| 01:49 | <mpt> | HTML 5 is ... |
| 01:50 | <Hixie> | Web Apps 1.0 is HTML 5 :-) |
| 01:50 | <Hixie> | HTML5 _was_ the codename :-) |
| 01:50 | <mpt> | oh but that's so boring |
| 01:51 | <Hixie> | hey, i'm just telling it how it is |
| 02:09 | <Lachy> | Philip`: fixed. |
| 02:11 | Hixie | gets to r886 |
| 02:11 | <Hixie> | well crap, now i have to do work |
| 06:34 | <Hixie> | oh hey, people did eventually point out to sebastian that he was made a mistake |
| 06:34 | Hixie | looks forward to the reply |
| 06:35 | <Hixie> | this whole naming this is such a joke |
| 06:35 | <Hixie> | i don't understand why we can't just share the name |
| 06:35 | <Hixie> | maybe we should call our XML serialisation "XHTML1 5" |
| 06:35 | <Hixie> | which would get shorted to XHTML 15 |
| 07:07 | <Lachy> | Sebastian responded to me off list and accused me of not addressing his argument. :-/ |
| 07:25 | <Hixie> | what was his argument? |
| 07:25 | <Hixie> | You can make the exact same e-mail with s/2/5/ and vice versa |
| 07:25 | <Hixie> | or rather |
| 07:26 | <Hixie> | s/2/5/ and s/5/1/ |
| 07:26 | <othermaciej> | I think he would claim that 2 is the valid authoritative continuation of xhtml 1, and 5 is a fork |
| 07:27 | <Lachy> | Hixie: this one http://www.w3.org/mid/4681C56C.8020501⊙lia |
| 07:27 | <othermaciej> | i.e. that organizational continuity trumps language-level compatibility |
| 07:28 | <othermaciej> | I don't think sharing the name "XHTML" is a problem and the fact that it is even being debated is annoying |
| 07:28 | <Hixie> | me neither |
| 07:28 | <Hixie> | and i agree |
| 07:28 | <Hixie> | i really don't understand the problem |
| 07:28 | <Lachy> | there isn't a problem, which is why I said that the debate needs to stop |
| 07:29 | <Hixie> | the thing that nobody has brought up is that XHTML5 is one of _three_ new names in the spec |
| 07:29 | <Hixie> | HTML5, XHTML5, and DOM5 HTML |
| 07:29 | <Hixie> | and having one of those have a different number than the others would be aethestically very displeasing |
| 07:29 | <Hixie> | imho |
| 07:31 | <Lachy> | let's just drop the number, call it HTML, XHTML and DOM |
| 07:31 | <Hixie> | that'd go down well with the versionists |
| 07:32 | <othermaciej> | DOM5 HTML is kind of odd, since there is otherwise no such thing as DOM5 |
| 07:33 | <othermaciej> | and with the HTML DOM in the spec, it's not really tied to a specific DOM Core level any more, in any case |
| 07:33 | <othermaciej> | but that's a whole other can of worms |
| 07:33 | <Hixie> | DOM HTML 5 |
| 07:34 | <Lachy> | or DHTML5 |
| 07:34 | <Lachy> | :-) |
| 07:34 | <othermaciej> | HTML5 DOM |
| 07:34 | <othermaciej> | (SVG spec refers to the "SVG DOM") |
| 07:35 | <othermaciej> | I'm not sure if any other w3c languages have a DOM |
| 07:38 | <othermaciej> | XForms appears to have a bunch of events, and only has a DOM interface for the <model> element (wow, it must be brutally painful to use with scripting) |
| 07:38 | <othermaciej> | MathML calls it the "MathML DOM" |
| 07:51 | <annevk> | someone should e-mail the Sebastian e-mail again and just change XHTML5 to XHTML 2.0 and XHTML 2.0 to XHTML5 :) |
| 07:52 | <hsivonen> | aargh. entity tokenization is subtle. I change something and a bunch of test cases fail :-( |
| 07:54 | <annevk> | at least the test harness is no longer broken :) |
| 07:55 | <othermaciej> | hey annevk |
| 07:55 | <annevk> | morning |
| 07:55 | <annevk> | I see you wanted to ask me something... |
| 07:55 | <hsivonen> | annevk: yeah. there are some new tests that are wrong, too. fixing those now |
| 08:07 | <othermaciej> | annevk: just wanted to talk about the design principles document, but I don't remember if I had anything specific - I'll try to do a proofreading pass on it to improve the wording |
| 08:07 | <annevk> | just edit and commit I'd say |
| 08:46 | <annevk> | the </p> and </br> fix in HTML5 was no good btw |
| 08:47 | <annevk> | it's more complicated than that |
| 08:47 | <annevk> | Hixie, you need to let </br> and </p> pass to trough the <head> element phases and such as well |
| 08:48 | <annevk> | to make <!doctype html></br> work |
| 08:53 | <Hixie> | send mail? |
| 08:54 | <Hixie> | nn |
| 08:54 | <annevk> | done |
| 08:54 | <annevk> | g'night |
| 08:57 | <zcorpan> | "behave similar to the browsers we try to imitate in English." -- in English? |
| 08:59 | <annevk> | the parsing spec is in English, no? |
| 09:00 | <zcorpan> | oh. yes. it sounded like you tried to imitate in english |
| 09:04 | <annevk> | landed support for my version of the spec in html5lib |
| 10:13 | <annevk> | Hixie, we don't have <ruby> |
| 10:35 | <zcorpan> | hmm, wonder what i should write test cases for today. content-type sniffing perhaps? |
| 10:36 | <annevk> | <embed>, <object>, etc.? |
| 10:36 | <zcorpan> | sure |
| 10:36 | <othermaciej> | I'd really like to see someone start organizing test cases into a test suite |
| 10:37 | <othermaciej> | at least for more solid areas of the spec |
| 10:37 | <zcorpan> | i might do that later on |
| 10:37 | <annevk> | it would be nice if all <canvas> tests were somehow merged |
| 10:38 | <annevk> | and checked for conformance |
| 10:40 | <othermaciej> | yeah |
| 10:41 | <othermaciej> | that is one area that is ripe for being turned into a test suite |
| 10:41 | <othermaciej> | parser tests might be another |
| 10:41 | <annevk> | we have loads of parser tests |
| 10:41 | <annevk> | and I believe someone wrote a JS framework for them |
| 10:41 | <othermaciej> | so someone needs to review and slap them into dev.w3.org |
| 10:42 | <zcorpan> | how should we deal with automated testing in general? |
| 10:43 | <othermaciej> | there's kind of a tradeoff here |
| 10:43 | <othermaciej> | if you build a test automation framework, that might make the tests harder to integrate into existing test automation frameworks |
| 10:43 | <annevk> | we have this boilerplate for automated tests: "try{top.opener.rr(passed);}catch(e){}" |
| 10:43 | <annevk> | that should be quite trivial to integrate in any framework |
| 10:43 | <othermaciej> | for instance the WebKit regression test suite works best on just raw html files |
| 10:44 | <annevk> | that's for tests that have some JS in them |
| 10:44 | <zcorpan> | or where the result can be determinated with js |
| 10:44 | <annevk> | right |
| 10:45 | <othermaciej> | I guess top.opener would be nil in our regression test system and so harmless |
| 10:45 | <annevk> | it means you either run them in an iframe or some popup window |
| 10:45 | <zcorpan> | i could use both visual indicator and try{top.opener.rr(result);}catch(e){} where possible |
| 10:45 | <annevk> | yeah, most XMLHttpRequest tests on tc.labs.opera.com work that way |
| 10:46 | <zcorpan> | ok. good |
| 10:46 | <othermaciej> | we have a nice framework for test assertions that can be expressed in JS in WebKit |
| 10:46 | <annevk> | there's also a small thingie that lets you run the tests in serie |
| 10:46 | <othermaciej> | I made a sorta-clone of it for the Window spec |
| 10:46 | <annevk> | and report the results |
| 10:47 | <othermaciej> | see here for a live example: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/WindowTestSuite/publish/html/ecmascript/browsing-contexts/Window-document.html |
| 10:47 | <othermaciej> | probably only really good for API tests though |
| 10:51 | <zcorpan> | hmm... perhaps i should use the same technique as hsivonen proposed for document conformance indication -- a file that lists all tests are noninteractive |
| 10:52 | <zcorpan> | or use different folders |
| 10:53 | <zcorpan> | or in the file name -- 001-noninteractive.htm |
| 10:54 | <annevk> | js-framework.txt |
| 10:54 | <annevk> | although you don't really need that |
| 10:54 | <annevk> | if you simply stick with the boilerplate mentioned above a simple crawling script can take care of that |
| 10:55 | <zcorpan> | oh, right |
| 12:01 | <Philip`> | My approach to the canvas tests is to write them all in YAML with some Python that writes HTML (and PNG), so I'd guess it should be straightforward for that to output different HTML for a different test framework |
| 12:25 | <zcorpan> | made http://simon.html5.org/test/html/parsing/stray-end-tags/with-attributes/ non-interactive |
| 12:51 | <annevk> | we need a http://www.google.com/search?q=site%3Alists.whatwg.org+{s} bookmarklet :D |
| 13:02 | <mw22> | I think you more need to just answer the question |
| 13:03 | <annevk> | if you have time to do that, great |
| 13:04 | <annevk> | having people do some research into previous discussions isn't that bad I think |
| 13:06 | <mw22> | well, if there is no time to anser question, just tell that then |
| 13:08 | <annevk> | this seems more helpful |
| 13:10 | <mw22> | no, it's not |
| 13:11 | <annevk> | that's just your opinion |
| 13:11 | <mw22> | no, it's not |
| 13:11 | <annevk> | ok |
| 13:12 | <hsivonen> | mw22: my reply may have been impolitely terse but at least it points to where you can find the answer |
| 13:14 | <mw22> | hsivonen, yeah, I also think it's impolite, it would be somewhat friendlier if you at least added one line ('maybe this is useful?') to it |
| 13:15 | <hsivonen> | will do next time |
| 13:16 | <mw22> | ok, thanks |
| 13:16 | <hsivonen> | yay, Minefield now supports em-sized <svg> elements |
| 13:40 | <annevk> | mw22, you see, the person found it helpful ;) |
| 13:40 | <mw22> | annevk, I don't have the reply yet, gmail sucks ;) |
| 13:41 | <annevk> | http://lists.w3.org/Archives/Public/public-html/2007Jun/0900.html |
| 13:47 | <mw22> | ah, ok, so now someone should probably reply to him that there is not time to answer his question, but it was already answered and he should look for it himself, or something along that line |
| 13:48 | <mw22> | I still don't have that mail in my mail box |
| 13:48 | <mw22> | gmail is really slow |
| 13:52 | <mw22> | oops, no, it's my fault |
| 13:58 | <Lachy> | someone reply and say that it is not the purpose of the differences document to provide justification for the changes, just to reflect the current state of the spec and describe what they are |
| 13:58 | <annevk> | the difference doc provides some rationale |
| 13:59 | <Lachy> | yeah, but not the detailed rationale some people are asking for, like the people wanting it to explain why accessibility features have been dropped |
| 13:59 | <annevk> | yeah whatever |
| 14:00 | <annevk> | I'll leave that up to Danc I think |
| 14:00 | <mw22> | http://tools.ietf.org/html/draft-ietf-run-netiquette-guide-00 |
| 14:00 | <mw22> | "Be brief without being overly terse. When replying to a message, include enough original material to be understood." |
| 14:01 | <annevk> | see above |
| 14:02 | <virtuelv> | mw22: see http://tools.ietf.org/html/rfc1855 instead |
| 14:03 | <mw22> | virtuelv, thanks |
| 15:28 | <krijnh> | Oi, anything interesting happened lately? |
| 16:44 | <gsnedders> | hmmm… I've been asking around about people's thoughts on recommending a codec, and the consensus is there should be either none, or multiple recommendations, all of which should be openly documented |
| 17:12 | <zcorpan> | a working draft is not a "spec"? |
| 17:14 | <annevk> | I think it is |
| 17:14 | <annevk> | well, depends on the type of working draft... some are specs, others are not |
| 17:14 | <zcorpan> | e.g. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8 |
| 17:15 | <zcorpan> | i referred to that as "the spec", and got a reply that it wasn't a spec. it was a working draft |
| 17:16 | <annevk> | heh |
| 17:17 | <annevk> | at some point it might become a "W3C Recommendation" |
| 17:18 | <hsivonen> | annevk: do I understand correctly that html5lib unifies phases and insertion modes? |
| 17:21 | <annevk> | yes |
| 17:21 | <annevk> | we need that to correctly deal with EOF |
| 17:21 | <hsivonen> | annevk: is there a reason why the spec doesn't? |
| 17:22 | <annevk> | the spec doesn't deal correctly with EOF yet |
| 17:22 | <annevk> | I suppose Hixie will fold them in due course too |
| 17:22 | <hsivonen> | oh great |
| 17:22 | <hsivonen> | tracking that spec refactoring will be a mess |
| 17:22 | <annevk> | this is about corner cases such as "<!doctype html>" not giving you "<!DOCTYPE html><html><head></head><body></body>" |
| 17:23 | <hsivonen> | annevk: is your deviation from the spec written down in English somewhere? |
| 17:23 | <annevk> | Hixie said it would be a fairly trivial change |
| 17:24 | <annevk> | hsivonen, it's quite simple, put the three tokens that are handled the same for each insertion mode in HTML 5 in each insertion mode and then drop the concept of insertion modes |
| 17:25 | <annevk> | hsivonen, then modifiy EOF in each phase appropriately |
| 17:25 | <hsivonen> | annevk: ok. thanks |
| 17:28 | <annevk> | I was just thinking that maybe your Java parser might be fast enough for surveys |
| 17:31 | <hsivonen> | annevk: I've been thinking about that, too. |
| 19:11 | <duryodhan> | hey is there an upper limit to the height for <canvax> drawWindow method ? |
| 20:18 | <Jero> | What was the last spec revision html5lib implemented? |
| 20:20 | <annevk> | I implemented </br> and </p> |
| 20:21 | <Jero> | oh cool, that basically means html5lib is completely up to date, right? |
| 20:22 | <annevk> | I guess |
| 20:22 | <annevk> | if you find bugs, let me know |
| 20:24 | <Jero> | i will, but i just wanted to be sure i'm not testing the results of my parser against the results of html5lib if it were a couple of revisions behind |
| 20:25 | <Jero> | though i think i should reorganize my parser a bit |
| 20:25 | <Jero> | one big file of almost 5000 lines isn't exactly optimal |
| 20:25 | <annevk> | we're a little bit ahead of the spec fwiw |
| 20:25 | <Jero> | sweet |
| 20:25 | <annevk> | EOF handling and what I posted regarding </br> and </p> on the list |
| 20:26 | <Jero> | cool |
| 20:51 | <hsivonen> | Hixie: how does one determine if <datagrid> is being used as a tree widget or whether it is being used as a grid widget? |
| 21:01 | <Jero> | annevk, <t?> makes the script throw an internal error |
| 21:01 | <Jero> | and by script i mean html5lib of course |
| 21:02 | <annevk> | wfm |
| 21:02 | <annevk> | using the latest SVN version? |
| 21:03 | <Jero> | no, i'm using hasather.net atm |
| 21:03 | <annevk> | that might not be up to date |
| 21:04 | <Jero> | yeah, i guess that's the case then |
| 21:05 | <Hixie> | hsivonen: i don't understand the question (datagrid) |
| 21:07 | <hsivonen> | Hixie: platform widget sets have tree widgets (disclosure triangles or equivalent on the left) and grid widgets (typically no disclosure triagles, column headings available) |
| 21:07 | <hsivonen> | Hixie: how should a UA decide which widget to use? |
| 21:07 | <hsivonen> | Hixie: should the UA report the datagrid to AT as a tree or as a grid? |
| 21:08 | <hasather> | Jero: I upgraded html5lib just minutes ago |
| 21:08 | <annevk> | Jero, if you checkout the CVS version you can cd into the python directorary and run something like 'python parse.py "<t?>"' and get something out of it |
| 21:08 | hsivonen | is creating a table that shows mappings between WAI roles and HTML5 features |
| 21:08 | <Hixie> | hsivonen: the <datagrid> element is both, you can have it in a mode with headers amd discolsure triangles |
| 21:08 | <annevk> | hasather, why does http://hasather.net/html5/parsetree/parsetree?source=%3Ct%3E throw an error though? |
| 21:08 | <Jero> | annevk, that's good to know, not an expert at Python yet, thanks! |
| 21:08 | <annevk> | hasather, does it have strict handling? |
| 21:09 | <hsivonen> | Hixie: so do you report it to AT as a tree or as a grid? |
| 21:09 | <hsivonen> | Hixie: is there a way to tell? |
| 21:09 | <annevk> | hasather, everything throws errors, it seems like something is no longer correct |
| 21:09 | <hasather> | annevk: yea, I look into it |
| 21:10 | annevk | wonders if there were any architecture changes |
| 21:10 | <Hixie> | hsivonen: report it as a tree, i guess, though it might all be at the same level |
| 21:11 | <hsivonen> | Hixie: mmkay |
| 21:11 | <hsivonen> | Hixie: I expect this spec detail will get comments down the road |
| 21:11 | <annevk> | <datagrid> is quite hard to get through as currently specced :( |
| 21:13 | <Hixie> | hsivonen: as far as i can tell, the <datagrid> widget maps directly to the widget in iTunes and to similar widgets in pretty much every modern mail client |
| 21:13 | <Hixie> | hell even _pine_ uses this kind of widget |
| 21:15 | <hsivonen> | hmm. I see disclosure triangles in iTunes only in the Podcast view |
| 21:15 | <hsivonen> | and in that view they aren't the leftmost column... |
| 21:16 | <hsivonen> | Hixie: how does JAWS read that widget to you? |
| 21:16 | hsivonen | turns on VoiceOver |
| 21:18 | <hsivonen> | when VoiceOver reads a cell that is on a row that has an open disclosure triagle, it says "expanded" |
| 21:19 | <hsivonen> | it seems that VoiceOver groks the concept of cell and the expanded status of rows at the same time |
| 21:19 | <Hixie> | dunno, haven't tried using JAWS there yet |
| 21:19 | <annevk> | Hixie, are you creating a new code.google.com/ page this week or doing different surveys? |
| 21:20 | <hasather> | annevk: Jero: I'm back to the old version for now. I don't really have time to look into it now, but I'll update it as quickly as possible |
| 21:21 | <Jero> | no problem, thanks! |
| 21:22 | <Jero> | ... @ PHP's built-in DOM implementation |
| 21:22 | <Hixie> | annevk: ? |
| 21:22 | <Jero> | $dom->createElement('p-') causes it to throw an error |
| 21:22 | <annevk> | Hixie, specifically, publishing a new version of the 2005-12 stats |
| 21:26 | <Hixie> | annevk: i might do, if i find something worth publishing. let me know if you have any ideas on what i should study. |
| 21:27 | <Hixie> | wow, my e-mail had absolutely no effect on public-html |
| 21:27 | <Hixie> | people are still just shouting at each other over style="", over role="", over <object>... |
| 21:27 | <annevk> | in addition you got a lengthy e-mail back :) |
| 21:28 | <Hixie> | oh good |
| 21:28 | <annevk> | Hixie, I'd be very interested how often the adoption agency algorithm is hit |
| 21:28 | <Hixie> | haven't got to that yet |
| 21:28 | <Hixie> | ^_^ |
| 21:29 | <Hixie> | i could report frequency of certain errors i guess |
| 21:29 | <annevk> | As in, how many times is an element duplicated in the average case |
| 21:29 | <Hixie> | my parser skips straight past the entity parsing and the input stream tweaking (e.g. getting rid of U+0000) |
| 21:29 | <Hixie> | hm, might be able to do that |
| 21:30 | <Hixie> | mail the list? |
| 21:30 | <Hixie> | or me |
| 21:30 | <Hixie> | best jut e-mail me on that |
| 21:30 | <annevk> | And maybe investigate if we can adopt the Safari algorithm that produces significantly less elements |
| 21:30 | <Hixie> | ian⊙hc |
| 21:30 | <Hixie> | i thought that's what the spec was |
| 21:30 | <Hixie> | what's the difference? |
| 21:31 | Hixie | wonders why sebastian doesn't mind XHTML 1.5 as much as XHTML5 |
| 21:31 | <othermaciej> | I guess because it gives the impression that XHTML2 is the future |
| 21:31 | <othermaciej> | (and always will be) |
| 21:32 | <zcorpan> | 1.5 doesn't have the useful property of being able to say (x)html5 |
| 21:33 | <zcorpan> | anyway |
| 21:33 | zcorpan | will stay away from naming debates |
| 21:34 | <annevk> | for <p><b><p>...<p>...<p>... the spec does <p><b></b><p><b>....</b><p> and Safari does <p><b>..</b><p><b><p>...</p> ...</b> aiui |
| 21:35 | <annevk> | dhyatt said that it's less expensive than the current algorithm but they encountered one issue with it so far |
| 21:35 | <hsivonen> | Hixie: answer to http://lists.whatwg.org/pipermail/implementors-whatwg.org/2007-June/000108.html would be good to know if you happen to discover it as a side effect of your research |
| 21:36 | <hsivonen> | I'm similarly interested in attribute value and comments lengths |
| 21:38 | <hsivonen> | are XForms alerts modal? |
| 21:41 | <Hixie> | hsivonen: yeah that's on my list of things to look at |
| 21:42 | <Hixie> | annevk: oh you mean reopen the formatting elements for block elements as well as inline elements? |
| 21:42 | <hsivonen> | Hixie: great |
| 21:44 | <annevk> | Hixie, maybe, dunno |
| 21:46 | <annevk> | they reopen the inline accross the next set of elements instead of reopening it in each one of them |
| 21:46 | <annevk> | according to dhyatt |
| 21:59 | <Hixie> | annevk: right, so reopening it for blocks instead of inlines |
| 21:59 | <Hixie> | or as well as |
| 21:59 | <Hixie> | as i said in e-mail, not really sure how to quantify that |
| 22:01 | <hsivonen> | a WAI spinbutton offers "discreet" choices... |
| 22:02 | <hsivonen> | is input type='number' with step, min and max supposed to be rendered as a "spinbutton"? |
| 22:11 | <Hixie> | it could be, sure |
| 22:12 | <Hixie> | i'm amused that WAI is exposing platform-specific and presentation-derived widget concepts, instead of exposing underlying concepts and allowing ATs to optimise for their users |
| 22:56 | <hsivonen> | Hixie: what's the deal with "limited quirks" when everyone calls it "almost standards"? |
| 23:16 | <Hixie> | hsivonen: it's no longer "almost standards". quirks, limited quirks, and no quirks are all standards now. |
| 23:18 | <Hixie> | lordy, poor lachy |
| 23:18 | zcorpan | hopes that limited and no quirks still can be merged... not sure if it'll fly |
| 23:19 | <Hixie> | the only difference is the inline box model |
| 23:19 | <Hixie> | and that can't be merged |
| 23:19 | <Hixie> | it's why the mode exists |
| 23:20 | <zcorpan> | the mode exists because mozilla wanted to comply with the css spec, and the spec was incompatible with the real world |
| 23:21 | <Hixie> | it must be pointed out that the spec's inline box model is far superior to the legacy rendering mode |
| 23:21 | <zcorpan> | but perhaps there is enough content on the web using standards mode and relying on the standards inline model (despite ie not supporting it) that it can't be merged after all |
| 23:21 | <zcorpan> | oh sure |
| 23:21 | <Hixie> | at least typographically |
| 23:21 | <zcorpan> | but having two modes suck |
| 23:21 | <Hixie> | sure |
| 23:21 | <Hixie> | having four is even worse |
| 23:21 | <Hixie> | we have four right now |
| 23:21 | <zcorpan> | yeah |
| 23:21 | <Hixie> | at least they're not too far apart |
| 23:22 | <Hixie> | microsoft want to introduce even more, with much bigger differences |
| 23:23 | <zcorpan> | yeah well. still, 90% of the web or so is in quirks mode |
| 23:24 | <Hixie> | i plan to discover exactly how much this week |
| 23:25 | <Hixie> | since the spec now requires me to implement doctype parsing :-P |
| 23:25 | <zcorpan> | :) |
| 23:25 | <zcorpan> | i would also like to know the ratio between almost/full |
| 23:26 | <Hixie> | well the %age of xml-mode is about 0.0014% |
| 23:26 | <Hixie> | last i checked |
| 23:26 | <zcorpan> | (which i'd expect to be 9:1) |
| 23:26 | <zcorpan> | yeah |
| 23:26 | <Hixie> | so it's bound to be higher than that for the other one |
| 23:28 | <Hixie> | bbl |