| 00:16 | <Philip`> | Hmm, Konqueror 3.8 renders 021 and 022 correctly but then crashes when loading 023 |
| 01:40 | <bzed> | hmm, firefox and konquerer just do nothign on 023 here, but they don't crash |
| 01:40 | <bzed> | and 021 doesn't work in FF |
| 01:40 | <bzed> | if anybody is interested... |
| 01:41 | <bzed> | konqueror 3.5.5 |
| 01:54 | <Philip`> | 3.5.5 doesn't have any canvas support at all |
| 01:54 | <Philip`> | (It's new in 3.8, which is the pre-alpha KDE4 version) |
| 02:12 | <jruderman> | http://www.i-marco.nl/weblog/archive/2006/06/24/time_breakdown_of_modern_web_d |
| 11:19 | zcorpan | created http://wiki.whatwg.org/wiki/Test_cases |
| 11:21 | othermaciej | considers nominating all the people named on that page to be HTML WG Test Suite Editors |
| 11:22 | <zcorpan> | there might be others that i don't know about or have forgotten about |
| 11:24 | <zcorpan> | hixie should have some tests now that i think of it |
| 11:24 | <zcorpan> | and the html5lib project has a test suite |
| 11:25 | <annevk> | hixie has quite some tests |
| 11:27 | <annevk> | can someone explain to me wtf the <label> discussion is about? |
| 11:27 | annevk | hasn't followed it |
| 11:28 | othermaciej | neither |
| 11:28 | <zcorpan> | it started with a misunderstanding i think |
| 11:28 | <zcorpan> | the rest i don't know |
| 11:29 | <annevk> | ok, yeah, I got the bit about someone thinking that <textarea> was not allowed inside or something... |
| 11:29 | <zcorpan> | where are hixie's tests? |
| 11:29 | <zcorpan> | http://www.hixie.ch/tests/adhoc/html/ ? |
| 11:31 | <othermaciej> | I like the fix to <label> click behavior in WF2, but it's unclear what should happen if the label is associated with something that does not correspond to a native OS control |
| 11:32 | <annevk> | if for= points to something that's not a form control the label doesn't have an associated element |
| 11:32 | <othermaciej> | ah |
| 11:32 | <annevk> | zcorpan, yeah |
| 11:32 | <othermaciej> | on Mac OS X in normal system UI, labels only do anything on checkboxes and radio buttons |
| 11:32 | <othermaciej> | and what they do is toggle it, not focus |
| 11:33 | <othermaciej> | is there any OS where clicking on the label next to a control focuses it in native UI? |
| 11:34 | <annevk> | dunno |
| 11:34 | <zcorpan> | on windows it seems like it's the label that has focus |
| 11:35 | <othermaciej> | you do want access-keys defined on the label to focus or activate the control I guess |
| 11:36 | <annevk> | i'd think so |
| 11:36 | <othermaciej> | except that accesskey is so tragically useless |
| 11:37 | <annevk> | ah, the complaint is indeed about activating |
| 11:37 | <annevk> | that clicking a label should always focus a textarea where other people say it should happen only when the OS defines it |
| 11:37 | <annevk> | makes sense to follow platform behavior |
| 11:37 | <zcorpan> | yup |
| 11:38 | <annevk> | otoh, some devices don't have a concept of a platform... |
| 11:38 | <annevk> | Nintendo Wii for instance |
| 11:38 | <zcorpan> | this isn't something that has to be interoperable |
| 11:38 | <zcorpan> | you do what makes sense for the UA or device |
| 11:39 | <zcorpan> | imho |
| 11:39 | <annevk> | sure |
| 11:39 | <annevk> | it's just annoying if you're cross platform :) |
| 11:39 | <othermaciej> | only if the platforms you target differ on this |
| 11:40 | <othermaciej> | I can't think of any platform where clicking a text field label in a native dialog focuses the text field |
| 11:40 | <annevk> | ok |
| 11:40 | <annevk> | (this is annoying with key events for instance) |
| 11:50 | <hsivonen> | thesis printed and bound \o/ |
| 11:53 | <othermaciej> | hsivonen: well done |
| 11:58 | <annevk> | will you bring it to XTech? :) |
| 12:00 | <hsivonen> | annevk: I wasn't planning to. should I? |
| 12:00 | <annevk> | not sure, but it might be nice to see it |
| 12:01 | <annevk> | howcome would certainly be pleased if he hears it's done using PrinceXML :) |
| 12:04 | <hsivonen> | annevk: I guess I could bring it. howcome already knows that it is set using Prince |
| 12:04 | <hays> | is that a ph.d thesis perchance? |
| 12:04 | <hsivonen> | hays: master's |
| 12:27 | <Philip`> | Non-blocking partial drawImage could be interesting if it worked with progressive JPEGs/PNGs... No idea if that's technically feasible, though |
| 12:30 | Philip` | also wonders what happens when you try drawing an animated GIF/PNG |
| 12:30 | <annevk> | hmm |
| 12:30 | <annevk> | feel free to follow-up |
| 12:30 | <annevk> | animated SVG would be another :) |
| 12:39 | <Philip`> | Ah, excellent, non-interoperability - Firefox draws whatever frame of animation is shown at the current point in time, and Opera refuses to draw animated images at all |
| 12:40 | <annevk> | I would not have expected anything else |
| 12:40 | Philip` | adds it to his list of things to test properly |
| 12:41 | annevk | wonders when an image starts animating |
| 12:41 | <annevk> | the moment .complete switches to true, the moment you have partial data or the moment it's inserted into the DOM, etc. |
| 12:41 | <annevk> | does that differ per image format? say SVG... |
| 12:43 | annevk | ponders |
| 12:44 | <annevk> | the amount of choices you need to make when implementing something (and think of when writing a spec)... |
| 13:14 | <MichaelMH> | why is the w3c website so ugly? |
| 13:17 | <Philip`> | Possibly because it was designed in 2002 and hasn't changed much since then |
| 13:17 | <Philip`> | (http://www.w3.org/2002/11/homepage) |
| 13:21 | <MichaelMH> | yeah but who picked mongy brown? |
| 13:21 | <MichaelMH> | and they shove so much information on the one page.. it just looks messy |
| 13:22 | <mpt> | The Web was ever thus |
| 13:50 | <Philip`> | jgraham_: About lxml: sounds good! I'll be interested in playing with that once I have some more time |
| 13:54 | met_ | is looking for help with Ian Hixie article for czech wikipedia 8-) |
| 13:54 | met_ | hopes Hixie is sleeping now 8-) |
| 13:55 | <met_> | what should write in the basic sentence "Ian Hickson is...." |
| 13:55 | <met_> | expert for web technogies ? |
| 13:56 | <met_> | ...is programmer/developper is probably not correct (not his main interest) |
| 13:57 | <Philip`> | Does it have to be non-libellous? |
| 13:57 | <met_> | any suggestions, anyone who now Hixie i little bit? |
| 13:57 | <met_> | of course 8-) |
| 13:58 | <Philip`> | Oh, I can't think of anything then :-( |
| 13:58 | <met_> | something short like this http://en.wikipedia.org/wiki/Dave_Hyatt |
| 13:58 | <met_> | basic info |
| 13:58 | <met_> | dunnot what write in the 1st sencence as his main characteristic |
| 14:03 | <jdandrea> | anne: Would you prefer the "Changes from HTML4" page redirect to a new "Differences from HTML4" page? (Only two pages on the Wiki are affected - http://wiki.whatwg.org/wiki/Special:Whatlinkshere/Changes_from_HTML4 ) |
| 14:03 | jdandrea | is happy to adjust it if it helps clarify things for visitors |
| 14:04 | <jdandrea> | s/anne/annevk |
| 14:07 | <karlUshi> | met_: http://ian.hixie.ch/ hixie by himself |
| 14:08 | <met_> | karlUshi now this page |
| 14:09 | <met_> | ok, we wrote "expert for web technoligies" (in Czech) |
| 14:10 | <karlUshi> | http://www.google.com/search?num=20&hl=en&safe=off&q=%22ian+hickson+is+%22&btnG=Search |
| 14:12 | <met_> | ok we have it, and some photo under creative common licence (this licence is requirement for wikipedia)? 8-) |
| 14:13 | <met_> | http://cs.wikipedia.org/wiki/Daniel_Glazman looks better than http://en.wikipedia.org/wiki/Daniel_Glazman |
| 14:18 | <met_> | ok Pavel Cvrcek just saved http://cs.wikipedia.org/wiki/Ian_Hickson |
| 14:21 | <met_> | http://www.flickr.com/photos/cindyli/265665723/ 8-) |
| 14:21 | <met_> | ok http://flickr.com/photos/distobj/15915885/ |
| 14:29 | <annevk> | jdandrea, I suppose that could work |
| 14:30 | <jdandrea> | annevk: Can do ... |
| 14:30 | <annevk> | sure |
| 14:30 | <jdandrea> | s/Can/Will |
| 14:30 | <annevk> | k |
| 14:30 | <Dashiva> | "using <SPAN> and in-line styles is a significant improvement on using the <FONT> tag. <SPAN> is a well established neutral container, whereas <FONT> is purely presentational." |
| 14:30 | <Dashiva> | They just keep going and going and going... |
| 14:31 | karlUshi | wonders if met_ is populating wikipedia with people's name and bios? |
| 14:31 | <met_> | not me but my friend yes |
| 14:31 | <karlUshi> | eeek |
| 14:31 | <met_> | and not people but people around web, browsers etc. |
| 14:32 | met_ | only find he forgot Hixie |
| 14:32 | <met_> | is still does not exist in en wiki |
| 14:32 | <karlUshi> | met_: does he want to exit on wikipedia should have been the first question |
| 14:32 | <met_> | flickr.com is full of hixie photos but none is good for publishing 8-( |
| 14:34 | <met_> | karlUshi, exit on? what you mean |
| 14:34 | <Dashiva> | exist, maybe |
| 14:34 | <karlUshi> | s/exit/exist/ |
| 14:35 | <met_> | i am not wikipedist, but from the wikipedist point of view it is not question |
| 14:36 | <met_> | someone is important or not important for encyklopedia (not only wikipedia), it is the question |
| 14:36 | <annevk> | yeah, as is the case for Mark Pilgrim for instance |
| 14:36 | <annevk> | iirc |
| 14:40 | <met_> | karlUshi, some explanation why I wanted this |
| 14:41 | <met_> | when I write some czech article about whatwg, w3c, html5, many people have some wikipage so i can link it for details |
| 14:41 | <met_> | and every time hixie was one who. hadn't |
| 14:42 | met_ | hope english version will come too |
| 14:43 | <jdandrea> | annevk: Differences from HTML4 now in place. WIki links adjusted. Original link still redirects. |
| 14:46 | <hsivonen> | Iana Hicksona could register en-GB-x-hixie :-) |
| 14:47 | <annevk> | it's actually a dialect to both en-GB and en-US |
| 14:47 | <Dashiva> | Does it make sense to register a x-prefix? |
| 14:48 | <annevk> | when registered you'd remove the prefix |
| 14:48 | <met_> | hsivonen, do not understand 8-) |
| 14:48 | <hsivonen> | just slighly amused by the Czech genetive of Ian |
| 14:49 | <met_> | it's czech suffix |
| 14:49 | <met_> | ok |
| 14:49 | <Dashiva> | Hint: IANA |
| 14:49 | <met_> | ah 8-) |
| 14:51 | <jdandrea> | That's it! x-classname! :) |
| 14:52 | <hsivonen> | jdandrea: x- for registered classes? ;-) |
| 14:52 | <jdandrea> | No, for unregistered ones. (I kid.) |
| 14:52 | <met_> | and xxx- for adult only classes? 8-) |
| 15:49 | <mpt> | en-hixie is a language with GB and US serializations |
| 15:52 | <annevk> | That might violate the RFC... |
| 15:52 | annevk | believes the second tag is reserved for locations |
| 15:53 | <annevk> | Maybe not... zh-Hans-TW for instance |
| 16:00 | <gsnedders> | annevk: registration is required unless it is one of a special few (inc. x) |
| 16:00 | <gsnedders> | annevk: the requirements for registration allow all sorts of things for the second tag |
| 16:04 | <annevk> | yes, i just figured that out |
| 16:32 | <hsivonen> | the length of a subtag is significant when deciding its role |
| 18:53 | <bewest> | if you press "enter" in an input, what happens? |
| 18:53 | <bewest> | I'm having a hard time locating this in the spec, and AFAICT it's totally absent from the w3c html4 spec |
| 18:53 | <bewest> | apparently firefox will activate the next button-type element according to document order |
| 18:54 | <bewest> | and there doesn't seem to be any mechanism to alter it. |
| 18:55 | <bewest> | I thought perhaps tabindex would be suitable, but it doesn't work for a few reasons |
| 18:55 | <bewest> | would be nice for tabindex to be scoped to the form |
| 18:56 | <Philip`> | Do you mean something like where it says "If the platform supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then when doing so the form's default submit button must be the one used to initiate form submission"? |
| 18:59 | <bewest> | I'm talking about specifying it as one of the things missing from html4 |
| 18:59 | <bewest> | so that we don't have to guess from implementation to implementation |
| 19:02 | <bewest> | so, yeah, something like that |
| 19:03 | <bewest> | so I guess allowing an attribute for describing which button should be the default for a form, and also making tabindex local to the form |
| 19:03 | <bewest> | latter might not be feasible |
| 19:08 | <Hixie> | the text Philip` quoted is in the spec |
| 19:08 | <Hixie> | and making a particular button the default is on the list for WF3 |
| 19:12 | <Hixie> | http://www.w3.org/2007/Talks/0509-dsr-forms/#(28) |
| 19:13 | <bewest> | oh |
| 19:14 | <bewest> | what does default submit button currently mean? |
| 19:14 | <bewest> | Philip`: I didn't realize you were quoting from the spec. thanks |
| 19:14 | <Hixie> | in the spec, that part is a link, iirc |
| 19:16 | <Philip`> | bewest: Ah, sorry, I should have been clearer |
| 19:16 | <Philip`> | (http://www.whatwg.org/specs/web-forms/current-work/#enter-submit) |
| 19:17 | <Philip`> | ("User agents may establish a button in each form as being the form's default button. (This should be the first submit button in the form, but UAs may pick another button if another would be more appropriate for the platform.)") |
| 19:27 | <Alystair> | What's this $10,000 to David Hyatt thing in the Acknowledgements section at the botom of the web apps 1.0 spec? |
| 19:28 | <bewest> | Philip`: ah... I think that breaks what's out there currently |
| 19:28 | <bewest> | Philip`: depending on what is meant by "submit button" |
| 19:29 | <bewest> | Philip`: if it means type="submit" then that's not what currently happens |
| 19:29 | <bewest> | type="image" also counts in FF |
| 19:31 | <Alystair> | This is so cool, so, you guys are actually planning the future for HTML/etc? :) |
| 19:31 | <Philip`> | http://www.whatwg.org/specs/web-forms/current-work/#extensions3 - "... a submit button (an input or button element with the type attribute set to submit, or an input element with the type attribute set to image) ..." |
| 19:31 | <bewest> | ah |
| 19:32 | <bewest> | ah ok |
| 19:32 | <bewest> | that's what happens |
| 19:32 | <bewest> | good job, then. that's some high quality speccing |
| 19:32 | <Philip`> | Alystair: I think that's the idea :-) |
| 19:33 | <bewest> | and I look forward to being able to tell UA's which one is the default |
| 19:33 | <Alystair> | my earlier question still remains unanswered, I thought that work was unpaid here |
| 19:33 | <Alystair> | unless there was a $10k bounty for that specific algorithm |
| 19:33 | <Philip`> | bewest: It probably would be nicer if the spec linked to the definitions for all those terms, so you don't have to just search through the text, but at least the definitions do appear to exist |
| 19:33 | <bewest> | Philip`: yeah. and it matches what actually happens already |
| 19:34 | <Philip`> | Alystair: I have no idea what that thing means either |
| 19:34 | bewest | wonders if tests are needed for this feature |
| 19:35 | <Philip`> | Tests are needed for every feature :-) |
| 19:35 | <Philip`> | ...unless someone's written some already |
| 19:35 | Alystair | should really read the faq, the site looks like it contains 3 different designs though |
| 19:35 | <bewest> | Philip`: let me be more direct then: how do I know if tests for this feature already exist? |
| 19:36 | <bewest> | Alystair: for some individuals, this is there full time job |
| 19:36 | <bewest> | Alystair: for example, the editor, Ian Hickson, is employed fulltime by google to do this work |
| 19:36 | <Philip`> | bewest: Hmm, I have no idea |
| 19:36 | <bewest> | Alystair: other stakeholders also recieve significant support from their companies to participate |
| 19:37 | <Alystair> | wow |
| 19:37 | <bewest> | Philip`: who would know? |
| 19:38 | <bewest> | Alystair: in particular, most of those stakeholders actually make browsers... and I imagine they balance their time between actually working on their browsers and participating in this and other, similar, groups |
| 19:38 | <Philip`> | (The last two in http://www.hixie.ch/tests/adhoc/html/forms/input/submit/ seem kind of relevant) |
| 19:38 | <Alystair> | 15 years! |
| 19:39 | <bewest> | Philip`: yes, test 3 does it |
| 19:39 | <bewest> | and 4, evidently |
| 19:40 | <Philip`> | bewest: I'm unsure who would know of any other relevant tests |
| 19:40 | <bewest> | hmmm I'll browse through zcorpan's stuff |
| 19:41 | bewest | doesn't see anything that looks relevant |
| 19:45 | <Alystair> | the faq's pretty funnny |
| 19:45 | <Alystair> | *funny |
| 19:47 | <Philip`> | Any particular bits? I think it's intended to be mostly serious :-) |
| 19:48 | <Alystair> | well, the whole xhtml/html war |
| 19:48 | <bewest> | Philip`: the part where one question redirects you to the next question, which redirects you to the previous question, which... |
| 19:49 | <Alystair> | I think the "Why do we need both HTML 5 and XHTML 2.0?" should really be fleshed out |
| 19:49 | <Alystair> | er answer to it |
| 19:49 | <Alystair> | "We don't!" isn't a legitimate answer to a serious question |
| 19:50 | <bewest> | Alystair: it's not considered a very serious problem, I think |
| 19:50 | <bewest> | Alystair: xhtml2 is DOA |
| 19:55 | <Hixie> | annevk: what's the xml-not-well-formed access-control problem? |
| 20:02 | <Alystair> | .... |
| 20:06 | <Hixie> | Alystair: i updated the faq to answer that question |
| 20:06 | <Alystair> | danke |
| 22:10 | <zcorpan_> | is a drocanian parser faster than a parser that does error recovery? |
| 22:11 | <zcorpan_> | http://www.autisticcuckoo.net/archive.php?id=2007/05/09/forward-towards-the-past |
| 22:12 | <othermaciej> | well, if there's an error right at the beginning of the document it will likely be faster to fail than a recovering one would be to succeed |
| 22:12 | <zcorpan_> | i mean if there are no errors |
| 22:13 | <othermaciej> | in the case where there are no errors, I don't know of any fundamental reason it would have to be slower |
| 22:13 | <zcorpan_> | i don't see it either |
| 22:13 | <zcorpan_> | but i keep hearing that xml parsers are so fast |
| 22:14 | <zcorpan_> | because they don't do error recovery |
| 22:14 | <othermaciej> | some forms of error recovery require maintaining extra buffers |
| 22:14 | <othermaciej> | but I don't think that effect dominates in practice |
| 22:14 | <othermaciej> | for WebKit at least, the XML parser we use works all in UTF-8 |
| 22:14 | <othermaciej> | and otherwise our engine does everything in UTF-16 |
| 22:14 | <othermaciej> | so I'm pretty sure it's slower than the HTML parser |
| 22:15 | <zcorpan_> | ok. i'm not surprised |
| 22:15 | <zcorpan_> | though my limited testing before with gecko showed that their xml parser was slightly faster than their html parser |
| 22:16 | <zcorpan_> | but that testing might well be flawed in some way |
| 22:16 | <jruderman> | what version of gecko did you test? |
| 22:16 | <zcorpan_> | it was probably 1.8 |
| 22:16 | <jruderman> | incremental rendering for xml was only turned on recently, on trunk |
| 22:16 | <zcorpan_> | yeah |
| 22:16 | <zcorpan_> | when i tested incremental rendering wasn't implemented yet |
| 22:17 | <jruderman> | it's likely "slower" in simple measurements now that there is incremental rendering |
| 22:17 | <jruderman> | but "faster" in practice |
| 22:17 | <jruderman> | i don't know if incremental rendering happens with the same frequency between html and xml, so i wonder how you could compare the two sanely |
| 22:18 | <zcorpan_> | by not rendering anything? :) |
| 22:18 | <zcorpan_> | :root { display:none } |
| 22:18 | <jruderman> | perhaps |
| 22:19 | <zcorpan_> | i could do the benchmark again but i'm not curious enough |
| 22:19 | <zcorpan_> | http://zcorpan.1go.dk/test/parsing-benchmark/ |
| 22:23 | <hsivonen> | zcorpan_: expat and the Gecko HTML parser are radically different. libxml2 and the WebKit HTML parser are likely different in other ways than operating on different code units. |
| 22:23 | <hsivonen> | zcorpan_: in Gecko, both operate on UTF-16, btw |
| 22:23 | <zcorpan_> | hsivonen: ok |
| 22:24 | <hsivonen> | zcorpan_: but if you have roughly the same buffering code and implementation approach for both XML and HTML5, there's no fundamental reason why the HTML5 parser should be slower if you don't actually print out the errors (which tends to block on IO) |
| 22:24 | <hsivonen> | zcorpan_: after all, a Draconian parser has to have the if branches to detect errors |
| 22:25 | <hsivonen> | zcorpan_: in the conforming case, you don't take those branches |
| 22:25 | <hsivonen> | zcorpan_: in the conforming HTML5 case, you don't take the error branches, either |
| 22:25 | <Hixie> | error handling can actually be faster because you don't have to test for some of the errors -- you just ignore them completely |
| 22:25 | <othermaciej> | hsivonen: there are some cases where the recovering parser has to buffer in case an error occurs later |
| 22:26 | <othermaciej> | but what Hixie said is also true |
| 22:26 | <hsivonen> | zcorpan_: so in conforming cases, you pay the price of doing roughly similar checks in both cases |
| 22:26 | <Hixie> | e.g. the html5 parser doesn't have to check for what characters are allowed in attribute values |
| 22:26 | <Hixie> | it just looks for the ones that terminate it |
| 22:26 | <othermaciej> | I think there is no a priori reason to think one needs to be faster than the other |
| 22:26 | <Hixie> | which is (trivially) faster |
| 22:26 | <Hixie> | but yeah, it's not really worth talking about in practice, it's such a small effect either way |
| 22:26 | <zcorpan_> | Hixie: yeah, makes sense |
| 22:26 | <hsivonen> | othermaciej: the HTML5 parser has one extra stack, but the "buffering" happens in the DOM |
| 22:27 | <hsivonen> | othermaciej: no buffering penalty DOM vs. DOM |
| 22:27 | <hsivonen> | othermaciej: I agree for SAX, though |
| 22:27 | <hsivonen> | zcorpan_: but basically, the fanboys saying that XML is so much faster probably have never benchmarked or implemented a markup parser :-) |
| 22:28 | <othermaciej> | HTML(tm) 5 can now officially be called that |
| 22:28 | <hsivonen> | ooh. something new in email? |
| 22:29 | <othermaciej> | aye (on public-html) |
| 22:30 | <hsivonen> | looks like Hixie has to do an SVN to CVS replay of revisions |
| 22:31 | <hsivonen> | "we suggest taking the rest of week off from |
| 22:31 | <hsivonen> | HTML WG email discussion." :-) |
| 22:31 | <hsivonen> | but yeah, great news! |
| 22:31 | <zcorpan_> | hsivonen: time to look at how large the diff is you mentioned before? :) |
| 22:31 | <hsivonen> | zcorpan_: yeah :-) |
| 22:32 | <othermaciej> | unfortunately, most CVS <--> SVN tools are designed for going the other way |
| 22:32 | hsivonen | looks |
| 22:32 | <Philip`> | Sounds like it'd be alright to just copy revision 785 into CVS, and then copy the latest version on top, rather than fiddling around with all the intermediate revisions |
| 22:32 | <hsivonen> | Philip`: good point |
| 22:32 | <Philip`> | (I guess people just want to know the difference between the version that they probably didn't read before voting, and the latest version) |
| 22:35 | <Philip`> | http://html5.org/tools/web-apps-tracker?from=785&to= - doesn't look like there's any major new contentious issues |
| 22:37 | <hober> | Would 'tailor' do the job? |
| 22:38 | <Philip`> | http://progetti.arstecnica.it/tailor/ ? |
| 22:38 | <Philip`> | There's only been ten revisions anyway, so it'd probably be quicker to do it by hand |
| 22:39 | <zcorpan_> | the html wg was launched march 7th, right? what was the revision of the WA1 spec then? |
| 22:39 | <hsivonen> | zcorpan_: The Diff: http://html5.org/tools/web-apps-tracker?from=668&to=796 |
| 22:39 | <hober> | IIRC, tailor could be used for bidirectional syncing |
| 22:39 | <hsivonen> | zcorpan_: 668 |
| 22:40 | <zcorpan_> | hsivonen: cheers |
| 23:00 | <zcorpan_> | what benefit is there for markup consumers to be able to know that all <p>s are paragraphs in the english sense and not e.g. poems or thematic groups of form controls? |
| 23:02 | <Philip`> | Perhaps someone doing automated corpus analysis of language used on the web, who wants to identify plain English sentences and not include spurious poems and form controls in their data? |
| 23:03 | <zcorpan_> | hrm. could be. but if it operated on the real web it would have to look at things that aren't <p>s anyway. because many aren't using <p>s at all |
| 23:03 | <zcorpan_> | and is there such an app anyway? sounds hypothetical to me |
| 23:04 | <Philip`> | Something like http://www.webcorp.org.uk/webcorp_linguistic_search_engine.html sounds similar |
| 23:05 | <zcorpan_> | interesting |
| 23:05 | <Philip`> | But this is probably a case where it's only valuable if everybody in the world uses <p> correctly. That's never going to happen, so you have to implement heuristics/hacks anyway, so it doesn't matter if a few people do use <p> properly (particularly since you can't even identify whether someone is using it properly) |
| 23:06 | <zcorpan_> | also, what is the benefit for markup producers to differentiate between whether a piece of text is a paragraph or not? (making it easier for the aforementioned app is one reason...) how would it work in a wysiwyg context? |
| 23:07 | <Philip`> | (I would tend to believe that semantics on the web only works when content creators benefit from doing it right, content consumers benefit from creators doing it right, and consumers don't suffer when creators get it wrong) |
| 23:07 | <Philip`> | (Things like <meta> keywords managed the first two of those, but died out because of the third point) |
| 23:08 | <zcorpan_> | makes sense |
| 23:10 | <zcorpan_> | i'm trying to understand the issue toolman has with <p> but i still don't get it |
| 23:10 | <othermaciej> | I agree with Philip` |
| 23:10 | <othermaciej> | if we favor better markup, the right way to get it is to create positive incentives for doing it right |
| 23:11 | <zcorpan_> | yeah |
| 23:11 | <jgraham_> | Yeah. We don't have a stick so we have to try and use carrots |
| 23:12 | <zcorpan_> | the xhtml2 wg have sticks :) |
| 23:12 | <bewest> | hehe |
| 23:12 | <jgraham_> | Nah the xhtml2 wg are _stuck_ |
| 23:12 | <jgraham_> | ;) |
| 23:12 | <zcorpan_> | oh right |
| 23:19 | <bewest> | hmmm I thought I recently saw something that was able to compare html5lib dom and your browser's DOM. |
| 23:19 | <bewest> | who did that? |
| 23:19 | <bewest> | maybe I should search the archive |
| 23:20 | <zcorpan_> | it was probably jgraham_ |
| 23:20 | <bewest> | yeah, probably |
| 23:22 | <Philip`> | http://hasather.net/html5/parsetree/ or a different one? |
| 23:23 | <bewest> | dunno |
| 23:27 | <jgraham_> | bewest: The other possibility is http://wordsandpictures.dyndns.org/html5/html5view.html |
| 23:28 | <jgraham_> | (otherwise it's something someone else did) |
| 23:31 | <bewest> | yes |
| 23:31 | <bewest> | I think that's it |