| 00:17 | <Philip`> | Hixie: You have a bogus </colgroup> that is breaking my attempt to run the spec-splitter :-( |
| 00:17 | <Hixie> | oops |
| 00:18 | <Hixie> | um |
| 00:18 | <Hixie> | why is it broken |
| 00:18 | <Hixie> | source seems ok |
| 00:18 | <Philip`> | and the spec-splitter happily dies and then uploads it non-existent output and thus deletes the multipage spec |
| 00:18 | <Hixie> | what's broken about it? |
| 00:19 | <Philip`> | <table class=apple-table-examples><col></colgroup><col><col><col><thead><tr><th> <th>2008 <th>2007 <th>2006 |
| 00:19 | <Hixie> | wtf |
| 00:19 | <Hixie> | that must be a libhtml bug |
| 00:19 | <Hixie> | or libxml |
| 00:19 | <Hixie> | or whatever we're using |
| 00:19 | <Philip`> | That's quite possible |
| 00:19 | <hober> | I've written a blog post about how to use HTML5's new sectioning elements. |
| 00:19 | <hober> | Would anyone like to review it before I publish? I want to be sure I'm making good recommendations. I'd rather the article reduce, not add, to the confusion around these elements. |
| 00:20 | <Philip`> | (I'm using libxml for parsing, because html5lib is unbearably slow) |
| 00:20 | <Hixie> | hober: can't review right now, but i'd be happy to do so after my meeting which starts in 10 minutes |
| 00:20 | <Philip`> | (Also, this is the index document, not the source document) |
| 00:20 | <Philip`> | lxml.etree.XMLSyntaxError: Unexpected end tag : colgroup, line 29957, column 53 |
| 00:21 | <hober> | Hixie: ok, I'll /msg you the link; please review at your leisure |
| 00:21 | <Philip`> | (using etree.HTMLParser) |
| 00:22 | <Philip`> | Is this something that is easily fixable without me doing anything? |
| 00:26 | <TabAtkins> | hober, I'll take a look. |
| 00:28 | <Philip`> | annevk2: http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html - now with added TOC |
| 00:29 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html - it's a little peculiar on certain pages, but I think it's probably about correct |
| 00:29 | <TabAtkins> | Philip`, I love the new TOCs. |
| 00:29 | <Philip`> | Hmm, the toc.js script messes things up a bit :-( |
| 00:29 | <Philip`> | Hixie: Is there some way toc.js could be disabled on the mini-TOCs in the multipage view? |
| 00:30 | Philip` | temporarily switched to the html5lib parser, but it's too resource-intensive for him to be particularly happy running it |
| 04:59 | Hixie | is proud of his table examples |
| 07:47 | <othermaciej> | hi all |
| 09:19 | <annevk3> | Philip`, sweet |
| 09:20 | <annevk3> | Philip`, for the introduction page the "full table of contents" should probably not be there |
| 09:20 | <annevk3> | Philip`, and the link above it, it's not present on other pages either |
| 09:20 | <Philip`> | annevk3: I blame Hixie for that |
| 09:21 | <Philip`> | since toc.js adds the full table of contents automatically |
| 09:21 | <annevk3> | ah |
| 09:21 | <annevk3> | i see, it's also present on full table of contents |
| 09:21 | <annevk3> | maybe toc.js should recognize a class name or something |
| 09:21 | <Philip`> | Hixie: It's all your fault :-( |
| 09:22 | <Philip`> | annevk3: I think I have to use class="toc" to get the right styling, but could add an extra class to make toc.js ignore it |
| 09:22 | <annevk3> | that could work, or hixie adds a class to the main toc; either way |
| 09:41 | <annevk3> | Hixie, pretty sure that if the fieldset is disabled the contents of the legend element are too |
| 09:42 | <annevk3> | in Opera they are |
| 09:42 | <annevk3> | which is per spec |
| 09:42 | <annevk3> | Hixie, so the fieldset example will never work |
| 09:43 | <annevk3> | Hixie, I'd move the checkbox into a <p> or so before the fieldset |
| 10:17 | <Hixie> | annevk3: should we fix that? |
| 10:17 | <Hixie> | the spec i mean? |
| 10:17 | <Hixie> | seems like a reasonable use case |
| 10:17 | <Hixie> | anyway i gotta sleep now |
| 10:28 | <annevk3> | I guess we could |
| 10:29 | <Lachy> | would it work to just say that controls within the <legend> don't get disabled along with the fieldset? |
| 10:30 | <annevk3> | spec-wise it's no problem |
| 10:30 | <annevk3> | just wondering about implementation complexity with dynamic updates and all |
| 10:30 | <annevk3> | not more crazy I guess than other stuff, but the question is whether it's worth it |
| 10:31 | <Lachy> | I'd be more convinced if there were real sites built with equivalent functionality |
| 10:31 | <annevk3> | sites prolly will if the styling issue gets solved |
| 12:53 | Philip` | tries to work out whether he should be using zh or zh-CN or zh-Hans |
| 12:53 | <Philip`> | Languages are too confusing :-( |
| 12:57 | <annevk2> | don't bother tagging it? |
| 12:57 | annevk2 | tries to work out which alias table Safari is using for ICU |
| 12:57 | <Dashiva> | zh-x-Philip` |
| 12:58 | <Philip`> | annevk2: I need to at least have some language code for the filename |
| 12:58 | <Philip`> | so I might as well use the correct one |
| 12:59 | <annevk2> | why is that? |
| 13:00 | <Philip`> | Because of a pointless desire for correctness |
| 13:00 | <annevk2> | carry on then :) |
| 13:04 | <Philip`> | So which one is correcter? :-) |
| 13:10 | <and> | Philip`: zh-CN looks wronger/older; zh-Hans is preciser (so likelier to be incorrect). |
| 13:11 | <and> | (Apart from that, CN would be associated with mainland China, and Hans with simplified ideograms, which originated there.) |
| 13:12 | <annevk2> | was to be expected: http://meiert.com/en/blog/20090911/html-5-or-html5/ |
| 13:13 | <annevk2> | Philip`, zh seems safest if you're unsure |
| 13:14 | <Philip`> | http://blog.whatwg.org/spelling-html5 - "Isn’t 5 a *version number*? As in HTML 4.01. Shouldn’t it actually be HTML 5?" |
| 13:14 | <Philip`> | That seems a good argument to call it "HTML5", so people don't think it's a version number |
| 13:16 | <annevk2> | and, new grouping is nice btw |
| 13:16 | <Philip`> | annevk2: I'm sure it's simplified Chinese, written by someone from mainland China, so the issue is just what code to use (rather than what language it is) |
| 13:17 | <Philip`> | The person who wrote it called it zh_cn, but e.g. http://www.w3.org/International/articles/language-tags/ seems to indicate zh-Hans is newer and more consistent and accurate |
| 13:20 | <annevk2> | are you sure it's not zh-Hant? |
| 13:20 | <annevk2> | anyway, http://tools.ietf.org/html/rfc5646 seems to suggest a couple of those are at least out of date (though still valid for backcompat reasons) |
| 13:22 | <and> | Hant/Hans means traditional/simplified Han characters (ideograms). |
| 13:23 | <and> | The use of CN to mean Hans is obsolete, but probably still fine to indicate mainland China. |
| 13:23 | <and> | (as I understand it, anyway) |
| 13:24 | <annevk2> | language tags certainly became a whole lot more complicated since I last looked at it |
| 13:29 | <and> | Hierarchically constructed tags like zh-Hans-CN are nice in theory, but I am not sure they are handled reasonably by matching algorithms. |
| 13:32 | <and> | annevk2: Glad you like it. I tried to choose clear and uncontroversial categories, but the labels are not completely self-explanatory (e.g., Mac CJK encodings belong to the CJK group, not to the Mac group). I hope I did not change anything in the process. |
| 13:32 | <annevk2> | oh, I haven't checked that |
| 13:33 | <annevk2> | it makes it a lot easier to compare browsers anyway |
| 13:34 | <annevk2> | once the data is more complete I plan to write a scraper that allows you to run comparisons on it |
| 13:34 | <and> | Well, I tried to be careful. |
| 13:34 | <and> | That is a good idea. We might want to add the IANA registry as a "browser" as well. |
| 13:35 | <annevk2> | yeah |
| 13:35 | <annevk2> | unfortunately it seems i'm booked for most of the weekend at least until sunday evening so it'll have to wait a little |
| 14:14 | gsnedders | hears loud roar of small jet engines, and looks up at window, and sees some of the red arrows flying fairly low and fast |
| 16:24 | <Philip`> | http://philip.html5.org/demos/rdfa/google-rich-snippets.html - it's a bit pathetic really |
| 16:25 | <Dashiva> | wau |
| 16:26 | <Dashiva> | Looks like something you'd make with regular expressions :) |
| 16:29 | gsnedders | sighs at British train prices |
| 16:58 | <gsnedders> | So a ticket from Reading to Leuchars is the same price as one from Birmingham New Street to Leuchars. That makes sense. |
| 16:59 | <gsnedders> | That's untrue. There is a slight difference. |
| 17:06 | <Philip`> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0124.html |
| 17:06 | Philip` | hopes he didn't make too many stupid mistakes |
| 17:11 | <Dashiva> | Philip`: I expect one response will be "But nobody is going to use v:g/#Person so it's just silly to support it" |
| 17:14 | <Philip`> | Then I might respond that some people seriously considered xmlns:http="http:" as a valid trick to transition to non-prefix-based URLs, which would be broken by this kind of thing |
| 17:15 | <Dashiva> | They were silly too |
| 17:16 | <Philip`> | Recent experience indicates RDFa people are happy with requiring specific behaviour for invalid input anyway, even when it's weird edge cases |
| 17:17 | <Philip`> | (and any disagreement is just about how explicitly and clearly it needs to be specified, vs being determined by the spec authors' intentions) |
| 17:47 | <Philip`> | "we will [...] deviate from the standard in some cases to be forgiving of webmaster errors. For example, we expect that some webmasters will forget the xmlns attribute entirely." (says a person from Google) |
| 17:47 | <Philip`> | Hooray for standards and interoperability! |
| 17:48 | <hober> | I think the Google parsing behavior sounds reasonable, at least as a forgiving, "real-world" processor of RDFa bits and pieces that survive copy&paste |
| 17:49 | <hober> | It seems like the extent to which they're deviating from RDFa-as-specified is the extent to which RDFa-as-specified isn't a web-ready tech... |
| 17:53 | <Steve^> | Should an element with display: none be included in the outline? |
| 17:53 | <Philip`> | If they want something that's forgiving and web-ready and works in the real world, and don't think RDFa is suitable for that, then they shouldn't pretend to support RDFa |
| 17:55 | <Philip`> | Then they could simplify it further (e.g. not use xmlns at all), and would no longer be flagrantly violating standards |
| 17:55 | <Philip`> | It'd be good if they documented whatever they implement, too |
| 17:55 | <hober> | indeed |
| 17:56 | <hober> | I'm just saying I think the RDFa folks should take a different lesson than the one I think they'll take from this |
| 17:56 | <Philip`> | Steve^: Yes |
| 17:57 | <Philip`> | since CSS is just an optional rendering thing |
| 17:57 | <Philip`> | Maybe <whatever hidden> shouldn't be included, though |
| 17:57 | <Philip`> | ("shouldn't" in terms of what's sensible, not necessarily what the spec says) |
| 18:02 | <Steve^> | It is good to avoid the "untitled section" in an outline |
| 18:14 | <Philip`> | (For future reference: That quote is from http://www.w3.org/mid/6934bc6b0909120945l7e721b90pda3ec06ca4d4c917⊙mgc which doesn't exist since it hasn't hit the list yet) |
| 18:14 | <Philip`> | (The Google RDFa quote, that is) |
| 18:20 | <jgraham> | Steve^: Yes. Indeed if you use one of the techniques that shows things to AT but not to ordinary browsers (e.g. the left -10000 thing) it is even better |
| 21:15 | <hober> | OK, I've published my blog post about how to use sectioning elements correctly http://edward.oconnor.cx/2009/09/using-the-html5-sectioning-elements |
| 21:37 | <Lachy> | hober, did you make any changes since I reviewed it earlier? |
| 21:37 | <hober> | only a handful of litle edits; nothing major |
| 23:56 | gsnedders | wonders if trying to change at Clapham Junction is a good idea |