| 00:01 | <Lachy> | if we clearly define "obsolete" as being a feature which authors must not use, but which must still be supported as defined, and deprecated as meaning a feature in the process of being phased out and replaced with an alternative, such that it intended to become obsolete in the future |
| 00:02 | <Lachy> | or we could go with "depreciated" instead ;-) |
| 00:09 | <Dashiva> | Lachy: Why would anything be deprecated then? If there's no replacement, we can't start phasing it out. And if there is a replacement, why not start phasing it out right away? |
| 00:10 | <Dashiva> | The old deprecated vs obsolete seems to be based on the idea that you can just say "Stop using this, support is going away", but we aren't going to remove support for still used features |
| 00:14 | <heycam> | what's the difference between a poll and a vote in this case? |
| 00:15 | Philip` | assumes votes are binding, and polls aren't |
| 00:31 | <jacobolus> | wow, these are beautiful mime types: |
| 00:31 | <jacobolus> | application/vnd.openxmlformats-officedocument.wordprocessingml.document |
| 00:31 | <jacobolus> | etc. |
| 00:50 | <Lachy> | Dashiva, personally, I don't think we should have a deprecated state at all, and would prefer that we simply dropped the conforming but obsolete nonsense entirely. I'm just suggesting this as a potential compromise. |
| 00:51 | <Dashiva> | Yeah, I feel the same (I think). But neither deprecated nor obsolete (from HTML4) really fit the HTML5 concept, so I think it'll be trouble with either one. If only there was another word |
| 00:52 | <inimino> | "ungood"? |
| 00:52 | <Lachy> | I think the specific word used is less important than their definitions |
| 00:52 | <Lachy> | using the HTML4 definition of deprecated would not be a good idea |
| 00:53 | <Lachy> | refining the definition of deprecated to avoid the issues with the HTML4 definition is slightly better, though we'd have to accept the baggage associated with its perceived meaning among the web community |
| 01:08 | <Dashiva> | I'm on the "deprecated is toothless" train. Not just for HTML4, OpenGL is going through the same thing. |
| 01:09 | <Lachy> | yeah, maybe that's the reason that some people are pushing for the use of the term. They know it's toothless and still want people to acutally use the summary attribute |
| 01:10 | <Lachy> | so maybe it's not such a good compromise after all |
| 01:10 | <Lachy> | screw it, let's just go with "obsolete and non-conforming" |
| 01:13 | <Dashiva> | Well, I wouldn't mind if it was changed to deprecated just for style. As long as it's conforming with a warning the actual result is the same |
| 01:14 | roc | ignores Tom Lord |
| 01:14 | <Dashiva> | I would be surprised if there's anyone who would accept s/obsolete/deprecated/ without also removing the warning |
| 01:14 | <Lachy> | I don't want the warnings. I think the whole idea of downplayed errors or warnings for obsolete features is nonsense |
| 01:15 | <Dashiva> | I think it's an acceptable compromise for controversial features |
| 01:15 | <Dashiva> | To me it's like a rfc SHOULD |
| 01:15 | <Dashiva> | Or maybe more like a SHOULD NOT [use this], I suppose |
| 01:16 | <Lachy> | but the controversy is simply based on people wanting to maintain the status quo, rather than accept change |
| 01:17 | <Dashiva> | It's still a step forward, even if not as large a step as ideal. And the next version can include another step. |
| 01:28 | <Hixie> | i could just use "Features that are not part of the language" and "Features that are included for migration purposes only and trigger warnings" |
| 01:29 | <Dashiva> | I think "conforming" has rough consensus, please don't abandon it :) |
| 01:30 | <Hixie> | i just meant instead of "obsolete" |
| 01:36 | <Lachy> | Hixie, I don't think anyone is concered about the use of obsolete for features that are non-conforming. |
| 01:36 | <Hixie> | that's unclear to me, since there was a quote of a definition of "obsolete" that doesn't match what the spec says |
| 01:37 | <Lachy> | it's only the oxymoronic use of obsolete but conforming. |
| 01:37 | <Hixie> | why is that oxymoronic? |
| 01:37 | <Lachy> | because obsolete suggests it shouldn't be used, but conforming suggests that is ok. |
| 01:38 | <Lachy> | they're basically contradictory concepts |
| 01:39 | <Hixie> | obsolete means that it is out of date |
| 01:40 | <Hixie> | conforming means that you are allowed to do it |
| 01:40 | <Hixie> | conforming doesn't mean it's ok |
| 01:41 | <Lachy> | technically, that may be so, but you have to consider how the terms will be perceived |
| 03:11 | <Dashiva> | Probably a pipe dream due to Member restrictions, but it would be interesting to see what other WGs have changed their processes after whatwg/htmlwg's example |
| 03:17 | <Hixie> | Dashiva: forms and css became a little more open |
| 03:17 | <Hixie> | other than that, i'm not aware of any major change |
| 03:26 | <Dashiva> | Hixie: I think doug has been opening up webapps some too |
| 03:26 | <Hixie> | webapps started after htmlwg |
| 03:30 | <Dashiva> | Well, compared to webapi |
| 03:38 | <Hixie> | it is? |
| 03:38 | <Hixie> | iirc webapi started after htmlwg too, anyway |
| 03:39 | <Hixie> | (webapi and waf were merged into webapps) |
| 03:39 | <Hixie> | (but all three started after htmlwg, i thought) |
| 03:39 | <Hixie> | (certainly after whatwg) |
| 03:39 | <Hixie> | i (and others) pushed to make webapi and waf and webapps more open quite a lot |
| 04:13 | <roc> | SVG is getting a bit more open |
| 04:17 | <MikeSmith> | Hixie: is the value of the iframe "name" attribute allowed to be empty? and/or is a browsing context name allowed to be an empty string? I ask because v.nu doesn't require it to be. And not by accident. For whatever reason, Henri intentionally coded it that way. |
| 04:18 | <MikeSmith> | And fwiw, I note that in HTML4, it was defined as CDATA, with no constraints on its length. |
| 04:18 | Hixie | looks |
| 04:18 | <MikeSmith> | Hixie: Spec currently has, "A valid browsing context name is any string with at least one character that does not start with a U+005F LOW LINE character." |
| 04:18 | <MikeSmith> | at least one character |
| 04:19 | <Hixie> | yup, was about to paste that |
| 04:19 | <Hixie> | spec seems clear |
| 04:19 | <Hixie> | can't be empty |
| 04:19 | <MikeSmith> | OK |
| 04:19 | MikeSmith | goes to file a v.nu bug |
| 04:19 | <Hixie> | mathematically, if i negate -1, do i get -1 or +1 ? |
| 04:20 | <MikeSmith> | um, +1 |
| 04:20 | <MikeSmith> | was that some kind of knock-knock joke? |
| 04:20 | <Hixie> | ok, good |
| 04:20 | <MikeSmith> | to get me to say +1 ? |
| 04:20 | <Hixie> | i was just checking that "negate x" doesn't mean "-abs(x)" but means "-x" |
| 04:27 | <othermaciej> | Hixie: I think web api wg was originally created before html wg |
| 04:37 | <Lachy> | Hixie, FYI, webapi and waf started at the end of 2005. HTMLWG officially started on March 7th 2007 |
| 04:38 | <othermaciej> | the merged webapps wg follows mostly open process afaict |
| 04:38 | <othermaciej> | the member-only list is almost never used |
| 04:40 | Lachy | hopes his last mail to public-html makes John, or at least rubys, realise how silly the approach being pushed to deal with @summary is |
| 04:42 | <Hixie> | the things that bug me about this thread: |
| 04:43 | <othermaciej> | honestly, I don't even care about voting on it, but if we're going to have a vote, I'd like to have one where we actually make a decision on the issue, rather than a rushed one to make a temporary patch to a Working Draft |
| 04:43 | <othermaciej> | a vote that Sam has been asked to hold and has failed to so far |
| 04:43 | <Hixie> | 1. john keeps saying that html5 says what i want it to say... but i want summary="" out altogether, which html5 doesn't say, so how is it my opinion?? |
| 04:43 | <Hixie> | 2. john keeps saying we should work with the pfwg, but as i explained, the pfwg refused to reply to my e-mails! http://lists.w3.org/Archives/Public/public-html/2009Aug/0056.html |
| 04:44 | <Hixie> | 3. john hasn't given one shred of valid reasoning for keeping summary="", and has not provided any data at all |
| 04:44 | <Hixie> | 4. we're exactly following the process (editor makes proposals out of the blue), and he complains that this isn't the process |
| 04:44 | <othermaciej> | side note: I'm looking at implementing trivial HTML5 elements like <nav> in WebKit |
| 04:45 | <Hixie> | 5. i'm doing exactly what i said i'd do in terms of writing those proposals (use reasoning and research) |
| 04:45 | <othermaciej> | what would be appropriate test cases, besides checking the default styling? |
| 04:45 | <Hixie> | othermaciej: for <nav>, check that voiceover skips past it (assuming voiceover has "skip navigation" features) |
| 04:46 | <Hixie> | othermaciej: parsing should be checked too |
| 04:46 | <othermaciej> | I'm not sure VoiceOver has such a feature yet |
| 04:46 | <Hixie> | othermaciej: oh and HTMLSectionElement has a .cite DOM attribute |
| 04:46 | <othermaciej> | Hixie: are there special parsing requirements for these elements? should I be testing cases where they are misnested? |
| 04:46 | <Hixie> | other than that, i don't think anything in particular |
| 04:46 | <othermaciej> | I did notice that section and article have IDL interfaces |
| 04:46 | <Lachy> | Hixie, what bothers me more is that rubys is encouraging it! |
| 04:46 | <Hixie> | othermaciej: for parsing, they're like <div> iirc |
| 04:47 | <othermaciej> | Lachy: indeed, Sam does not seem to have done anything to actually resolve the issue |
| 04:48 | <Lachy> | oh, regarding sectioning elements and headings, I'm a little concerned that since we've started seeing a lot of early adopters, trying to implement the default sizing for h1 based on nesting level may prove problematic |
| 04:48 | <Lachy> | I haven' tested this out though, but it would be worth looking into |
| 04:48 | <othermaciej> | Hixie: I think I know how to make them parse like <div>, but I'm not sure what edge cases to test |
| 04:48 | <Hixie> | in parsing? dunno |
| 04:49 | <Hixie> | other than that, i don't think there really are any edge cases |
| 04:49 | <othermaciej> | I guess I should check that <p> doesn't close it, and that unclosed <b> or <i> or whatever behaves like it does for div |
| 04:49 | <Hixie> | yeah |
| 04:50 | <othermaciej> | Lachy: my intent was to initially add the various sectioning elements so they are recognized by the engine, and then have a separate task to implement the header sizing rule |
| 04:51 | <othermaciej> | Lachy: specifically I'm thinking of adding a -webkit-section-depth(n) pseudo-class or something like that |
| 04:51 | <othermaciej> | (I think the pseudo-class could be useful even if applying different sizes by default turns out to be impractical) |
| 04:51 | <Lachy> | I'd make it :-webkit-heading(n) |
| 04:52 | <Lachy> | IIRC, JQuery has a :heading(n) pseudo class and it would be worth developing something backwards compatible with that |
| 04:52 | <Lachy> | (I could have remembered the details about that wrong, though) |
| 04:53 | <Lachy> | but I need to go to bed and wake up in 3 hours, in order to take my MacBook in for repair (again!) and then get to work |
| 05:09 | <othermaciej> | how does JQuery's :heading(n) work? |
| 06:35 | <othermaciej> | MikeSmith: are you around? |
| 06:35 | <MikeSmith> | othermaciej: yep |
| 07:22 | <hsivonen> | hi |
| 07:24 | <Hixie> | you live! |
| 07:24 | <Hixie> | hsivonen: mere hours ago i hit my timeout on worrying that a devilish fate may have befallen you |
| 07:24 | <Hixie> | hsivonen: and asked around, only to learn you were on holiday until today :-P |
| 07:25 | <hsivonen> | Hixie: I said two weeks. I meant the adjacent weekends, too. |
| 07:25 | <Hixie> | i had forgotten that you had said anything |
| 07:25 | <Hixie> | i don't really keep track of where y'all are :-P |
| 07:25 | <Hixie> | btw i recommend not reading your e-mail |
| 07:25 | <Hixie> | for at least another week |
| 07:29 | <hsivonen> | Mail.app is so slow I may have to wait until next week for it to download and filter the pending email :-) |
| 07:30 | <othermaciej> | public-html has been making me a sad panda |
| 07:33 | <othermaciej> | hmm, implementing <nav> is trickier than I thought... |
| 07:34 | <Hixie> | really? |
| 07:34 | <hsivonen> | othermaciej: what's there to implement other than </p> inference, default style and exposure to VoiceOver? |
| 07:34 | <othermaciej> | I thought it would be trivial but I'm clearly messing something up |
| 07:35 | <MikeSmith> | hsivonen: hey! |
| 07:35 | <hsivonen> | MikeSmith: hi |
| 07:36 | <MikeSmith> | was kind of worried about you.. nobody seemed to know where you were, or if you were on vacation or what. Until earlier today, Hixie heard from somebody I guess |
| 07:36 | <MikeSmith> | anyway, glad you're back |
| 07:36 | <hsivonen> | MikeSmith: sorry, I guess I should have broadcast my schedule more widely |
| 07:37 | <hsivonen> | MikeSmith: I left an /away message on IRC, but the server running my irssi got rebooted |
| 07:44 | <MikeSmith> | ah |
| 07:59 | <annevk> | othermaciej, new elements also imply </p> I think |
| 08:00 | <othermaciej> | annevk: my attempted code change (which I thought was trivial) should imply </p> through the same mechanism that <div> does |
| 08:00 | <othermaciej> | but I'm not getting the <nav> elements in the DOM for some reason |
| 08:00 | <othermaciej> | need to debug |
| 08:01 | <MikeSmith> | hsivonen: how much work would it be to take make a standalone binary utility based on the v.nu/whattf HTML5 datatype library? |
| 08:02 | <MikeSmith> | would it be practical at all to try to do so? |
| 08:02 | <hsivonen> | MikeSmith: do you mean a .jar that anyone could load into Jing or MSV? |
| 08:03 | <hsivonen> | MikeSmith: or a utility that includes Jing, too? |
| 08:03 | <hsivonen> | othermaciej: you should copy <address>, not <div> |
| 08:05 | <annevk> | afaict it is identical to <div> apart from foreign content mode |
| 08:05 | <hsivonen> | <div> is scoping |
| 08:05 | hsivonen | checks if address is |
| 08:05 | <othermaciej> | <address> and <div> have different WebKit parsing behavior in a way that I don't actually understand at the moment |
| 08:08 | <hsivonen> | othermaciej: as far as I can tell, the new structural elements have the exact same tree builder dispatch bits as <address> |
| 08:08 | <hsivonen> | (by inspection of code I've written earlier, not by inspecting the spec) |
| 08:10 | <hsivonen> | http://www.whatwg.org/demos/company-home/ probably shouldn't use flags for languages (in order to be a politically correct good example) |
| 08:14 | <MikeSmith> | hsivonen: at the risk of making clear how little I understand about the v.nu architecture, I have to ask, Does the datatype library have a dependency on Jing? |
| 08:15 | <hsivonen> | MikeSmith: it doesn't |
| 08:16 | <hsivonen> | MikeSmith: Jing and MSV share interfaces for this stuff, so the datatype library depends on those shared interfaces |
| 08:16 | <MikeSmith> | hsivonen: OK, so to give you the context for why I'm asking: I would like to have something that could be used with rnv |
| 08:17 | <hsivonen> | rnv is C, right? |
| 08:17 | <MikeSmith> | yeah, but it has this simple mechanism where you can have it delegate datatype-checking to another command-lined application |
| 08:17 | <hsivonen> | and it has Scheme and stdin/out datatype lib interfaces, IIRC |
| 08:17 | <MikeSmith> | right |
| 08:18 | <MikeSmith> | I'm talking about the stdin interface |
| 08:18 | <hsivonen> | it should be possible to write a command-line wrapper host that can hold any Java datatype library |
| 08:18 | <MikeSmith> | OK |
| 08:18 | <hsivonen> | and then compile the HTML5 datatype lib with that host using GCJ to eliminate the JVM startup overhead |
| 08:19 | <MikeSmith> | right, that's what I had in mind |
| 08:19 | <hsivonen> | MikeSmith: http://iso-relax.sourceforge.net/ |
| 08:19 | MikeSmith | looks |
| 08:19 | <hsivonen> | that's the SourceForge copy of the shared interfaces |
| 08:20 | <hsivonen> | oops. maybe I have the wrong URL. sorry |
| 08:20 | <hsivonen> | MikeSmith: http://sourceforge.net/projects/relaxng/ |
| 08:20 | <hsivonen> | that's the one |
| 08:20 | <MikeSmith> | OK |
| 08:21 | <hsivonen> | http://sourceforge.net/projects/relaxng/files/datatype%20%28java%29/Ver.1.0/relaxngDatatype-1.0.zip/download |
| 08:22 | <MikeSmith> | hsivonen: yep, found it -- thanks |
| 08:25 | <othermaciej> | I think I figured out what I did wrong in implementing |
| 08:25 | <othermaciej> | I had to hook up a few more places |
| 08:26 | hsivonen | wishes Apple shipped GCJ along with the GCC pieces that Apple ships |
| 08:31 | <hsivonen> | Darxus: If you have a DTD-valid XML 1.0 file that doesn't use Namespaces, you can process it as SGML if your SGML pipeline implements Annex K, IIRC. |
| 08:32 | <MikeSmith> | hsivonen: you're scaring me with this stuff |
| 08:32 | <MikeSmith> | what the hell is Annex K? |
| 08:32 | <othermaciej> | sweet, got it working |
| 08:32 | <hsivonen> | MikeSmith: it's an annex they made to SGML in order to make XML a subset of SGML |
| 08:32 | <othermaciej> | just have to make tests now |
| 08:32 | <MikeSmith> | hsivonen: ah |
| 08:33 | <hsivonen> | MikeSmith: IIRC, it adds the <foo/> stuff to SGML |
| 08:33 | <MikeSmith> | I see |
| 08:34 | <MikeSmith> | so next I'm wondering what Darxus would want to process a document as SGML |
| 08:34 | <hsivonen> | XML processing isn't a subset of SGML processing, though, so the Right Thing happens if the input document is already known to be error-free |
| 08:38 | <hsivonen> | Hixie: does a browser implement input type=color already? |
| 08:40 | <annevk> | not as far as I know |
| 08:41 | <hsivonen> | Hixie: I think HTML5 shouldn't be silent about mutation events when it comes to the parser, innerHTML and document.open(). But I'd be OK with saying that mutation events aren't required, but if they are implemented, they need to fire / not fire so and so |
| 08:45 | <annevk> | I think we're waiting for DOM3Events |
| 08:57 | <annevk> | MikeSmith, while going through some of the older blog entries to see if additional template tweaks are needed I found http://blog.whatwg.org/vim-checker and it seems that the image is no longer there |
| 08:57 | MikeSmith | looks |
| 08:58 | <MikeSmith> | annevk: btw, it's great to have that new design |
| 08:58 | <MikeSmith> | it's like night and day |
| 08:58 | <MikeSmith> | looks like a real blog now :) |
| 09:00 | <annevk> | yeah, couple of days ago I suddenly remembered we actually had a design proposed but never implemented it :) |
| 09:01 | <hsivonen> | grr. someone is *still* sending shockwaves to my office, and I'm unable to locate a construction site with explosives nearby |
| 09:04 | hsivonen | already hoisted remaining hard disks onto rubber footing. no idea if that helps with this kind of shocks |
| 09:06 | <othermaciej> | I'm surprised at the number of separate places I had to change in WebKit to add a new HTML element |
| 09:07 | <othermaciej> | (6 to be exact) |
| 09:11 | <MikeSmith> | annevk: OK, thanks for the heads-up. I just deleted the img and the paragraph that preceded it |
| 09:12 | <hsivonen> | I wonder if I were able to tell a mac and a readynas to sleep disks without turning them off |
| 09:12 | <hsivonen> | if I knew when the next shockwave hits |
| 09:13 | <hsivonen> | yet another problem that solid-state storage would solve |
| 09:14 | <Philip`> | You could suspend the disks from springs |
| 09:15 | <hsivonen> | Philip`: has anyone productized a spring-base NAS-holder that I could buy? |
| 09:15 | <Philip`> | You could suspend the NAS-holder from springs |
| 09:16 | <hsivonen> | I want a productized spring-suspender |
| 09:17 | Philip` | got an external disk recently and it came with stretchy rubber things around each end, but he isn't quite sure what effect they're meant to have |
| 09:20 | <hsivonen> | I bought the softest erasers I could find and placed 4 under the NAS and four under the Mac |
| 09:43 | jgraham | wonders what excitement he has missed |
| 09:44 | <annevk> | since? |
| 09:44 | <jgraham> | 17th July |
| 09:44 | <annevk> | heh, your vacation is in sync with hsivonen's |
| 09:45 | <annevk> | we put up a new design for the blog |
| 09:45 | <annevk> | other than that there's been a lot of process bs email |
| 09:46 | <jgraham> | who would have guessed? |
| 09:46 | <jgraham> | The blog looks much better :) |
| 09:46 | <jgraham> | Although the green of the bar clashes with the green of the title |
| 09:51 | hsivonen | hasn't read list email yet, but from subject lines, it seems it has been another round of accessibility and RDFa :-( |
| 09:52 | <gsnedders> | And process. A lot of process. |
| 09:52 | <eighty4> | gsnedders: entertain me? |
| 09:53 | <gsnedders> | eighty4: Go read public-html. |
| 09:55 | <eighty4> | I don't want to read public-html |
| 09:55 | <eighty4> | :( |
| 09:55 | <jgraham> | ^ That should be the /topic ;) |
| 09:56 | eighty4 | is grinig |
| 10:00 | gsnedders | sighs at his Monday mornings, always spent catching up on public-html(-.*)? and whatwg, always full of process discussions |
| 10:00 | <Hixie> | hsivonen: for mutation events i'm waiting to learn if they're changing at all before saying anything |
| 10:13 | <roc> | jgraham: WAI merged with PETA, we are now considering cross-species accessibility requirements |
| 10:14 | <jgraham> | roc: now people are giving me strage looks in the office |
| 10:15 | gsnedders | looks innocent |
| 10:15 | <gsnedders> | But seriously, jgraham, if you do laugh with a facial expression like that… |
| 10:20 | <hsivonen> | wow. fielding committed unregistered types to mime.types |
| 10:20 | <jgraham> | That's my special facial expression I reserve for painfully funny things |
| 10:24 | Philip` | discovered http://www.peta.org/sea_kittens/about.asp recently, and found it hard to tell whether it was real or a parody |
| 10:25 | <gsnedders> | LOL |
| 10:27 | <annevk> | 'But if you call fish "sea kittens," maybe people will be nicer to them.' ... |
| 10:28 | <eighty4> | gsnedders: flickr a photo of jgraham laughting? |
| 10:29 | jgraham | is not /still/ laughing |
| 10:29 | <gsnedders> | I have neither a camera nor a jgraham who is laughing. |
| 10:29 | <Philip`> | Surely you could find a devilish scheme to make him laugh |
| 10:30 | <gsnedders> | Sadly I don't think I'm witty enough. |
| 10:30 | <eighty4> | I'd be willing to help |
| 10:30 | <Philip`> | You could try tickling him |
| 10:31 | <Philip`> | though people might start giving you strange looks |
| 10:32 | <MikeSmith> | hsivonen: or I guess better yet, it would be grand to have a jing command-line binary that had the v.nu HTML5 datatype library built-in |
| 11:08 | <hsivonen> | MikeSmith: that should be easy |
| 11:10 | <annevk> | Hixie, "just register those" >.5M USD or so |
| 11:10 | <hsivonen> | MikeSmith: I *think* the steps are: 1) take a Jing binary, 2) add the datatype lib jar to the same directory that holds Saxon, 3) edit the manifest of the main .jar to point to the datatype lib jar the same way it points to the saxon jar |
| 11:10 | <Hixie> | yeah that's why it was parenthetical with a "!" :-) |
| 11:11 | hsivonen | found out who is blowing up stuff inside the hill that my office is on |
| 11:11 | <MikeSmith> | hsivonen: hill trolls? |
| 11:12 | <hsivonen> | MikeSmith: nope. looks like en energy company is expanding its tunnels |
| 11:12 | <jgraham> | Does finland have trolls? |
| 11:14 | <jgraham> | Apparently in Iceland, so many people believe in "hidden people" (i.e. some sort of faerie or so) that they had to divert the main ringroad round the island several times to avoid areas where they were believed to live |
| 11:15 | <MikeSmith> | jgraham: Moomin |
| 11:15 | <Hixie> | isn't that a big white bulbous guy |
| 11:15 | <hsivonen> | Moomins live in a wooden house, not inside bedrock, though |
| 11:15 | <Hixie> | sweet i was right http://en.wikipedia.org/wiki/Moomin |
| 11:16 | <jgraham> | Moomins are awesome but I can't imagine them blowing up a hill |
| 11:16 | <Hixie> | lol |
| 11:16 | <Hixie> | we're getting far more useless bug reports than i expected |
| 11:16 | <Hixie> | there's even a prompt now confirming intent to submit |
| 11:18 | <hsivonen> | sigh. they are building a tunnel that is going to be long |
| 11:18 | <hsivonen> | I guess they aren't going to stop soon |
| 11:18 | <Hixie> | you could go politely ask them to |
| 11:18 | <Philip`> | I suppose a shorter tunnel would be pretty useless |
| 11:18 | <Hixie> | "hi i'm sorry, would you mind putting your tunnel elsewhere?" |
| 11:19 | <jgraham> | Perhaps if they tunneled somewhere with no hill it would be easier for everyone concerned |
| 11:20 | hsivonen | thought these parts of the city were already connected with tunnels |
| 11:21 | <MikeSmith> | hsivonen: maybe they are building tunnels under the existing tunnels |
| 11:21 | <MikeSmith> | that's what's done in Tokyo at least |
| 11:22 | <hsivonen> | maybe |
| 11:22 | <MikeSmith> | for subways at least (in Tokyo) - the newer a subway line is, the taller the escalators |
| 11:23 | <Hixie> | london too, though none are newer than about 4 centuries |
| 11:23 | <Hixie> | (i may be exaggerating a little) |
| 11:23 | <jgraham> | Jubilee line extension |
| 11:24 | <gsnedders> | jgraham: That's not that deep in the Docklands :P |
| 11:24 | <jgraham> | gsnedders: Sure but it is also rather new |
| 11:24 | <gsnedders> | True |
| 11:24 | <gsnedders> | The Jubilee is deep in the centre though |
| 11:25 | <hsivonen> | apparently this one is for electricity, water and central heating |
| 11:25 | gsnedders | remembers getting out of the Northern at some station in the centre, only to find the elevator had broken |
| 11:29 | <Philip`> | An elevator at a station? |
| 11:29 | <gsnedders> | On underground lines, yes. |
| 11:30 | <Philip`> | I thought they just had escalators |
| 11:30 | <gsnedders> | Not the deep level lines |
| 11:30 | <gsnedders> | Some stations on the deep level lines have elevators and stairs, nothing else. |
| 11:31 | <Philip`> | Ah |
| 11:31 | Philip` | is not an expert in train journeying |
| 11:31 | <gsnedders> | Russell Square is one such station, IIRC |
| 11:32 | <gsnedders> | Philip`: Well, get out, see Europe! |
| 11:32 | <Philip`> | I think they should use pneumatic tubes to shoot people up to ground level |
| 11:34 | <Hixie> | not if the british run it they shouldn't |
| 11:34 | <Hixie> | they'd underfund maintenance and people would be shot out at killed every other week |
| 11:34 | <Hixie> | or, more likely, it'd be perpetually out of service |
| 11:35 | <gsnedders> | There was some circular escalator built for some underground station, IIRC |
| 11:35 | <gsnedders> | The only one ever build. |
| 11:35 | <gsnedders> | *built |
| 11:35 | <gsnedders> | It always had issues, and was shut soon after being installed. |
| 11:37 | <gsnedders> | http://districtdave.proboards.com/index.cgi?board=History&action=display&thread=2596&page=1 |
| 11:39 | <gsnedders> | http://news.bbc.co.uk/2/hi/in_pictures/6182967.stm |
| 11:40 | <Philip`> | When I went in to work last week, a staircase was taped off and had a sign saying it was "out of service" and "engineers are investigating" (which was clearly untrue because nobody was even looking at it) |
| 11:41 | <Philip`> | (The lifts have been broken for a month, but I got an email today saying one was back in service) |
| 11:41 | <gsnedders> | http://www.abandonedstations.org.uk/Holloway_Road_station.html is what I originally saw about it |
| 11:42 | <gsnedders> | Anyhow, enough procrastinating |
| 11:44 | <jgraham> | Covent Garden tube station has a lift and steps |
| 11:44 | <jgraham> | I think Cambden Town might too |
| 11:44 | <jgraham> | *Camden |
| 11:49 | <jgraham> | Disappointingly the depth of tube lines seems to be considered security sensitive information and as such there are no 3D tube maps showing depth avaliable |
| 11:49 | <Philip`> | Hmm, spiral escalator? Maybe they could make one that's a rotating corkscrew, continually lifting people upwards |
| 11:51 | <gsnedders> | jgraham: Camden Town doesn't. |
| 11:51 | <gsnedders> | Actually, I think it does. |
| 11:51 | <hsivonen> | is the square border around the whatwg logo in the new blog design intentional? |
| 11:51 | <gsnedders> | It's just that it's only 40 or so steps, so it isn't that deep, so most people just use them, as the lifts are really slow |
| 11:51 | <gsnedders> | Same at Mornington Cresent |
| 11:51 | <Hixie> | you can't win that game in one step! cheater! |
| 11:52 | <Philip`> | hsivonen: It might be that nobody tested the blog in Firefox |
| 11:52 | <jgraham> | Hixie: Huh? He got there from Camden town |
| 11:53 | <Hixie> | ah ok then |
| 11:53 | <gsnedders> | Besides, I had to walk all the way from the elevator to the platform |
| 11:53 | gsnedders | remembers he has an Oyster card back in his apartment, and wonders how much money is still on that |
| 11:54 | gsnedders | remembers he also has a single BVG ticket for Berlin in his apartment |
| 11:54 | <gsnedders> | They seem highly useful things to have here |
| 12:05 | <annevk42> | weird |
| 12:05 | <annevk42> | Chromium for linux now no longer uses the platform Chrome |
| 12:06 | <gsnedders> | Yeah, that changed over the weekend |
| 12:06 | <gsnedders> | I don't think it is so much that, but they changed their default skin |
| 12:13 | gsnedders | never ceases to be amazed at how easy it is to get IE to crash |
| 12:24 | <zcorpan> | omg the blog uses <cite> incorrectly! |
| 12:25 | <hsivonen> | the easy way to avoid using <cite> incorrectly is to use <i> where italics are appropriate |
| 12:25 | <Hixie> | i fixed the spec to use <i> all over the place recently |
| 12:25 | <Hixie> | instead of <em> and various other mistakes |
| 12:26 | <annevk42> | the blog uses <cite>? |
| 12:26 | <hsivonen> | I still use <cite> and <em> out of an old habit. perhaps I should start getting used to <i> |
| 12:26 | <gsnedders> | Hixie: You probably ought to stop misusing @title sometime |
| 12:26 | <zcorpan> | <cite class="fn"><a href='http://www.brucelawson.co.uk'; rel='external nofollow' class='url'>bruce</a></cite> <span class="says">says:</span> |
| 12:26 | <Hixie> | gsnedders: pah :-) |
| 12:27 | <Hixie> | gsnedders: fixing that would be horrifically painful |
| 12:27 | <Hixie> | gsnedders: and would be a problem with the w3c until they get their [censored] and let us use html5 |
| 12:27 | <gsnedders> | Hixie: hehe |
| 12:27 | <gsnedders> | I guess you could change the conformance criteria to make it conforming, as that'd be easier :P |
| 12:27 | zcorpan | suggests "<a href='http://www.brucelawson.co.uk'>bruce</a>; says:" |
| 12:28 | <Hixie> | ok i have to go to bed before hte birds start singing |
| 12:28 | <Hixie> | nn |
| 12:28 | <hsivonen> | nn |
| 12:28 | <gsnedders> | nn |
| 12:30 | <adactio> | <cite class="vcard"><a href="http://brucelawson.co.uk"; class="url fn" rel="external colleague">Bruce</a></cite> |
| 12:30 | <annevk42> | adactio, the complaint was that <cite> is incorrect |
| 12:30 | <adactio> | That's a common usage of cite on my part. |
| 12:30 | <annevk42> | in other news, changing that seems annoying |
| 12:30 | <adactio> | I'm going to continue to use it that way even if HTML5 says otherwise. |
| 12:31 | <annevk42> | all I have i: <ol class="commentlist"><?php wp_list_comments(); ?></ol> ... |
| 12:31 | <hsivonen> | adactio: using <cite> for personal names goes against the intent of HTML 2.0 founding fathers |
| 12:31 | <adactio> | Just as specifying something that browser makers won't implement is fiction, specifying something that authors refuse to adhere to is equally fiction. |
| 12:31 | <hsivonen> | adactio: HTML 4 corrupted <cite> |
| 12:32 | <adactio> | hsivonen: I disagree. HTML4 embraced and extended <cite> ;-) |
| 12:32 | <gsnedders> | hsivonen: HTML 4 accounts for the majority of time HTML has existed |
| 12:32 | <adactio> | You could say that HTML5 is corrupting <legend> but I prefer to think of it a smart extension of an existing element ...just like HTML4 did with <cite>. |
| 12:33 | <hsivonen> | I'm not a fan of the way HTML5 uses <legend>, but the English thesaurus is exhausted |
| 12:34 | <zcorpan> | maybe we should switch to another language |
| 12:34 | <hsivonen> | both <legend> and <caption> come with legacy parsing baggage |
| 12:34 | <Lachy> | <legend> has practical problems that haven't yet been resolved too |
| 12:34 | <Lachy> | but we've yet to find a reasonable alternative |
| 12:34 | <zcorpan> | otoh, getting <legend> to work nicely in browsers will be a welcome change for web developers |
| 12:34 | <hsivonen> | if we can get authors to use <rubric>, let's go for it |
| 12:36 | <Lachy> | I'm not sure how well <rubric> would be accepted in practice. I'm quite sure most people, even native English speakers, wouldn't know what it meant |
| 12:38 | <Lachy> | Caption Synonyms: explanation, head, inscription, legend, rubric, subtitle, title, underline |
| 12:38 | <Lachy> | of those, explanation (or explain) seems like the only remotely reasonable alternative, given compat issues |
| 12:40 | <jgraham> | <rubric> would be highly confusing to most native english speakers |
| 12:40 | <adactio> | It's challenging to think of something that works equally well for <figure> and <details>. |
| 12:40 | <Lachy> | anyway, as for cite, adactio has a point. If authors are going to ignore what the spec actually says in favour of what they want to use it for, then the spec is just fiction |
| 12:41 | <jgraham> | since the only time it ius used in common parlance it means the instructions on an examination paper |
| 12:41 | <adactio> | Lachy: I could always twist the wording of the spec to suit my needs. If the spec says <cite> must only be used for "title of work", I'll use it to mark up a person as long as that person is "a real piece of work" ;-) |
| 12:42 | <Lachy> | about about we just go with <c> and say it means caption |
| 12:42 | jgraham | wonders if anyone has ever derived any value from the use of the <cite> element |
| 12:42 | <Lachy> | s/about about/how about/ |
| 12:43 | <jgraham> | Lachy: Hixie's main objection is making up any other element name not just the exact name |
| 12:43 | <adactio> | jgraham: there's the W3C semantic data extractor which picks up uses of the <cite> element but I wouldn't exactly call that a practical use. |
| 12:43 | <hsivonen> | the short non-fiction version is that <i>, <em>, <cite> and <var> mean italics. <b> and <strong> mean bold and <tt>, <code>, <kbd> and <samp> mean monospace |
| 12:43 | <Lachy> | jgraham, the only value is for the author as it allows for styling without relying on class names to distinguish among different uses of italics |
| 12:44 | <adactio> | hsivoven: I use <cite> (in pretty much every blog post I write) and I don't style it to be italic. |
| 12:44 | <Lachy> | adactio, a semantic data extractor is not a useful tool by itself. Unless it were used for some real purpose in some application, it's little more than an interesting experiment |
| 12:45 | <jgraham> | adactio: Real question: do you think using <cite> in that way is advantageous over using <i>? |
| 12:45 | <adactio> | Lachy: agreed; that's why I said it wasn't exactly a practical use. A more practical use would be auto-generated (with JavaScript) footnotes and references. |
| 12:45 | <jgraham> | (and restyling it) |
| 12:45 | <jgraham> | (or <span>) |
| 12:46 | <Lachy> | jgraham, if that's Hixie's only objection, it seems pretty weak considering the problems with <legend> |
| 12:46 | <jgraham> | Lachy: agreed |
| 12:46 | <gsnedders> | adactio: You might, but the vast majority of use makes the small amount of semantic use of it more or less irrelevant in terms of real usage |
| 12:47 | <annevk42> | it's not that weak imo |
| 12:47 | <annevk42> | in a few years <legend> issues will go away |
| 12:47 | <adactio> | jgraham: yes, for the same reason that using <p> to mark up a paragraph of text is better than using <br>s ...or why it makes sense to mark up navigation in a <ul> or <ol> rather than simply a <div> ...authors should be free to use the most *semantically* suitable element. It has *nothing* to do with styling (italics, bullet points, whatever). |
| 12:47 | <annevk42> | before <details> is properly supported will also take some time |
| 12:47 | <Lachy> | annevk42, legend issues have been known about since at least Firefox 2.0, and still after 2 major release cycles, still nothing has been done about it |
| 12:48 | <jgraham> | annevk42: How many years compared to the timescale for deployment of <figure>? |
| 12:48 | <annevk42> | Lachy, actually some fixes have been made |
| 12:48 | <Lachy> | not in Firefox 3.5. Is it fixed in Minefield? |
| 12:48 | <annevk42> | I said some |
| 12:48 | <jgraham> | (afaict the timescale for the deployment of <figure> is "next major browser release of several browsers") |
| 12:49 | <annevk42> | jgraham, I think before 2012 or so we shouldn't worry too much about this |
| 12:49 | <hsivonen> | adactio: are there content consumers who don't have prior agreement with you and whose software isn't specific to your site and who derive value from your use of <cite>? |
| 12:49 | <jgraham> | (<details> can be faked with js as long as you don't use legend) |
| 12:49 | <annevk42> | well, we should get browsers to support things better, but we should not be fixing the problem in the wrong place |
| 12:49 | <Lachy> | annevk42, since we're beginning to see a lot of early adopters, I think we should pay a little more attention to the problems now rather than later |
| 12:50 | <annevk42> | because in the end HTML5 requires <legend> to work just as well |
| 12:50 | <gsnedders> | Lachy: It's fixed in Minefield with HTML 5 parser enabled |
| 12:50 | <Lachy> | ok |
| 12:50 | <jgraham> | annevk42: Sure legend should be fixed but blocking several unrelated things on that seems like a bad idea, especially if they are useful |
| 12:51 | <adactio> | hsivonen: no, and there are no content consumers who derive use of my use of <p> or <ul> or most other elements ...but they're *still* the right elements to use. If the only argument for using an element is end practical end benefit, we need nothing more than <div> and <span>. |
| 12:51 | <annevk42> | jgraham, it just delays experimentation a little bit, and you can always experiment by just using a <div> instead |
| 12:51 | <annevk42> | jgraham, before 2012 wide-scale deployment is not really an option anyway |
| 12:52 | <Lachy> | adactio, that's not true. Assistive technology derives value from the correct use of <ul>, and, to some extent, <p> |
| 12:52 | <jgraham> | adactio: I disagree. There are several other styling-unrelated reasons for using things like lists and paragraphs. (I don't think I ever claimed that styling was the main reason for anything) |
| 12:52 | <jgraham> | AT is one obvious one. Improved source readability is another |
| 12:52 | <adactio> | jgraham: you didn't, but Hixie is arguing that on the list. |
| 12:53 | <Lachy> | jgraham, improved source readability isn't really value for a consumer |
| 12:53 | <Lachy> | unless you count the geeks who look at the source of every site they visit |
| 12:53 | <jgraham> | Lachy: I didn't just ask about consumer value |
| 12:54 | <jgraham> | Saying "I use <cite> because it makes my pages easier to maintain" seems valid to me |
| 12:54 | <Lachy> | jgraham, I thought what you said was related to hsivonen's question about content consumers deriving value from markup |
| 12:55 | <jgraham> | I wonder if google makes use of <cite>. I guess it does but only as part of a more complex set of heuristics |
| 12:56 | <hsivonen> | adactio: whether <ul> is useful depends on whether one wants to keep HTML processable without access to computed style for the screen media |
| 12:56 | <jgraham> | But maybe explicit markup like that makes automatic extraction of author names from e.g. Google scholar work better |
| 12:59 | <adactio> | I use the <cite> element (and every other element for that matter) for the same reason that I choose the particular quotation marks, em dashes, en dashes, ellipses or semi-colons. As an author, I want to choose the most appropriate structure for my content. That means I choose the most appropriate punctuation and the most semantically appropriate markup. That may bring me no practical benefit (yet) but I will still do it |
| 13:00 | <hsivonen> | quotes as dashes have immediate appeal to humans browsing content |
| 13:00 | jgraham | chooses the right punctuation to improve readability and typography which seem like very immediate obvious and practical benefits |
| 13:00 | <hsivonen> | computed style is similar |
| 13:00 | <hsivonen> | how computed style comes about is different |
| 13:03 | <adactio> | hsivonen: yes, but when it comes to *which* punctuation to use, it's author preference: do I use a semi-colon or an em-dash to separate a subclause? Do I use a colon or an ellipsis? I choose what I feel is most appropriate. Same with semantics. I have a choice of elements and I choose the one I think is most appropriate for the content. My decision. Not Hixie's. I will continue to choose the semantically appropriate eleme |
| 13:05 | <hsivonen> | adactio: I think how people arrange their selectors is a private choice. I think semanticsare useful for interchange |
| 13:05 | <jgraham> | Hmm isn't semantics about _shared_ meanings. It seems a little Alice-in-wonderland to say "when I use elements thwey mean just what I chose them to mean" |
| 13:05 | <hsivonen> | so semantics that aren't for interchange aren't different from non-microformat class names |
| 13:06 | jgraham | is not giving this conversation as much attention as it requires to do the topic justice |
| 13:06 | <Lachy> | adactio, while authors do have some freedom with regards to the punctuation they choose to use, they are generally used according to the grammatic rules of the language. |
| 13:06 | <Lachy> | You don't, for example, randomly! use, punctuation throughout @ a sentence? do you% |
| 13:07 | <jgraham> | Unless you are writing perl |
| 13:07 | <adactio> | But I'm not alone. In fact, I'm going along with the HTML4 definition of <cite>. If HTML5 chooses to revert that decision, that doesn't mean that authors will go along with it. That particular part of the spec becomes fiction precisely because it isn't documenting the *shared* meaning of an element. |
| 13:07 | <adactio> | Lachy: re-read what I said about specific cases: semi-colons vs. em-dashes, colons vs. ellipses. |
| 13:08 | <Lachy> | jgraham, if you're writing perl, you're still adhering to the grammatic and syntactic rules of the language |
| 13:09 | <hsivonen> | adactio: I see your point, but <cite> is still private even if a lot of authors do it if the choice of element matter for their own selectors and not to loosely-coupled consumers |
| 13:09 | <Lachy> | adactio, semi-colons, em-dashes, colons and ellipses have distinct purposes. They are not directly interchangeable. |
| 13:09 | <hsivonen> | (a lot of the prescriptive semantics for inline elements are over-precise to be descriptive) |
| 13:10 | <adactio> | Lachy: some authors use a semi-colon where I would use an em-dash and visa-versa. Neither of us is wrong. |
| 13:10 | <gsnedders> | adactio: The meanings of blockquote and h1 are fiction too, as to be real they'd need to "indent" and "bold". Should we change that too so the spec isn't fiction? |
| 13:11 | <Lachy> | adactio, not everyone uses punctuation correctly in all cases. |
| 13:12 | <jgraham> | Lachy: I think you are wrong about punctuation. There are style guides but natural language is really not prescriptivist |
| 13:12 | <jgraham> | As long as people think that you are using things in the right way then it is valid usage |
| 13:12 | <adactio> | gsnedders: I think you are inferring the exact opposite of what I'm saying. According to Hixie's logic with <cite> (that it is only used to italicise) then yes, <blockquote> should only be used to indent. I'm arguing the opposite. That the semantic meaning is important, not the styling. |
| 13:13 | <gsnedders> | adactio: You're arguing the spec is fiction if it does not match reality too, and I'm pointing out more examples where it does not. |
| 13:13 | <hsivonen> | If I were redesigning HTML from scratch knowing what I know now, I wouldn't put <cite>, <em>, <var>, <strong>, <code>, <kbd> and <samp> in the language |
| 13:13 | <gsnedders> | adactio: And those two examples I gave have presentation semantics in reality |
| 13:14 | <jgraham> | gsnedders: That is not fair. Headings are often (but not always) used correctly |
| 13:14 | <hsivonen> | adactio: you have discovered that Hixie is more willing to deviate form "reality" into fiction when it comes to things that aren't browser-implementation-relevant |
| 13:14 | <jgraham> | same as tables |
| 13:15 | <jgraham> | Blockquote I don;t know about |
| 13:15 | <hsivonen> | adactio: browser implementation reqs are the most reality-based and the non-machine-detectable conformance reqs are the least reality based parts of the spec |
| 13:15 | <adactio> | Let me give you another example of author choice, one that comes up a lot on web dev blogs. Suppose you're marking up a <form>. What element do you use to contain your form field and your <label>? Some authors use <div>s. Some authors use <p>s. Some authors use <li>s. We could argue (we have argued) about which is the most appropriate but in the end, it's author choice. The HTML spec shouldn't dictate that level of usage |
| 13:16 | <Lachy> | jgraham, to some extent yes, but there are still grammatical rules that exist and which should be adhered to |
| 13:17 | <jgraham> | adactio: I agree with that totally. Unless there are practical reasons for using one over another e.g. the effect in actual client applications |
| 13:17 | <jgraham> | e.g. tables would likely be treated differently in AT to <p> |
| 13:17 | <jgraham> | and possibly be harder to navigate |
| 13:18 | <adactio> | hsivonen: I think that's a good way to split features: features that need work from browsers vs. features that only need authors to buy in to. What I'm saying is that just as browser buy-in is required for the first type of feature, author buy-in is required for the second. So mandating something in the spec that authors don't agree with (and therefore won't abide by) is as pointless as mandating something that browsers w |
| 13:19 | <Philip`> | adactio: (Got cut off after "that browsers w") |
| 13:19 | <adactio> | will never implement. |
| 13:19 | <hsivonen> | adactio: I tend to agree, although I personally dislike the use of <cite> for anything but the title of work concept |
| 13:19 | <adactio> | hsivonen: and you, as an author, are free to only use it for titles of work. |
| 13:20 | <hsivonen> | eww. making innerHTML setter block network and event loop seems evil |
| 13:20 | <hsivonen> | s/block/block on/ |
| 13:21 | <hsivonen> | I'm shocked it has even been proposed |
| 14:21 | <Lachy> | woah, Rubys has now said flat out that Hixie should accept John's changes and move on! WTF? |
| 14:27 | <Dashiva> | Reading about <cite> led me to @cite, which made me wonder if no one in the RDF circles had tried to also let it accept a person URI instead of only a document URI |
| 14:28 | <zcorpan> | hsivonen: it was only proposed by Hixie as an attempt to be compatible with ie |
| 14:31 | <zcorpan> | hsivonen: btw gsnedders found an infinite loop in the html5 parser |
| 14:31 | <zcorpan> | hsivonen: something with <select>.innerHTML='<keygen>' iirc |
| 14:32 | <webben> | adactio: What is the point of features that only authors will buy into? |
| 14:32 | <hsivonen> | zcorpan: thanks. |
| 14:32 | <adactio> | webben: what is the point of features that authors won't buy into? |
| 14:33 | <webben> | adactio: Very little. |
| 14:33 | <adactio> | webben: agreed. |
| 14:35 | <webben> | adactio: My point is that the effect on the user experience is what matters (or at least, what should matter), for anything other than syntactic sugar. |
| 14:35 | <Dashiva> | Is there a one-liner about "author education" similar to "the tools will save us"? |
| 14:36 | <zcorpan> | Zeldman will save us |
| 14:36 | <webben> | So if different elements for wrapping form controls have an effect on the user experience, I don't see why HTML5 shouldn't have conformance criteria about it. |
| 14:36 | <Dashiva> | (and "search engines can use it") |
| 14:37 | <adactio> | webben: so you aren't distinguishing between features that extend the platform (canvas, video, etc.) and features that extend the language (header, footer, cite). I think it's unwise to treat all features as being in the same class. There are clearly differences between browser features (which, as you say, directly effect the UX) and language features (which affect semantics ...invisible but still important). |
| 14:38 | <webben> | I think all semantic distinctions have a /potential/ effect on user agents. |
| 14:38 | <adactio> | webben: I certainly don't equate semantics with "syntactic sugar." HTML is a markup, not a programming, language (or, now with HTML5) it is a markup *and* a programming language. |
| 14:38 | <webben> | For example, screen readers offer keys for navigating list elements, tables, and "paragraphs" independently. |
| 14:38 | <hsivonen> | adactio: header and footer should be considered to extend the platform, IMO |
| 14:38 | <hsivonen> | adactio: as far as exposure to AT goes |
| 14:40 | <adactio> | hsivoven: help me think of a better example of "extending the language" i.e. new semantics that don't require undue work from browser makers in order for authors to use them. |
| 14:40 | <webben> | adactio: I don't equate semantics with syntactic sugar. But the important thing about semantic features (as opposed to mere naming conventions) is that user agents can /do/ things with those semantics. |
| 14:40 | <Dashiva> | Was I the only one laughing when Sam assumed wcag had peer review? |
| 14:41 | <Dashiva> | I wasn't even involved in the process, but I still remember all the blog posts about how it ignored input and feedback |
| 14:42 | <adactio> | webben: even naming conventions *can* be used by user agents (see: microformats) so I don't think there's such a clear distinction between semantics and naming conventions. Both can be potentially used by user agents. |
| 14:42 | <webben> | adactio: (My point about syntactic sugar is that unlike other features, it's only of interest to authors.) |
| 14:42 | jgraham | guesses that Sam has never been a working scientist |
| 14:43 | <gsnedders> | Yes, yes, whatever you said Dr Graham |
| 14:43 | <jgraham> | Fuck off |
| 14:43 | <webben> | adactio: That's true, and to the extent that user agents can do things with them, it's appropriate for them to specified (see: microformat specs). |
| 14:43 | <adactio> | webben: I disagree. When enough authors agree on semantic usage, user agents can make use of that collective decision. Admittedly, this doesn't happen that often but it doesn't happen that often with regular elements either. |
| 14:43 | <jgraham> | :p |
| 14:43 | <gsnedders> | s/said/say/ |
| 14:43 | <Dashiva> | Analogies to lumiferous aether and phlogiston come to mind |
| 14:43 | <adactio> | webben; the "I disagree" was for your previous comment, not what you just said which I agree with. :-) |
| 14:44 | <gsnedders> | I disagree. |
| 14:46 | <zcorpan> | hsivonen: http://twitter.com/davidpaulsson/statuses/3103355788 - you need to relaunch v.nu for the wiki microsyntax changes to take effect |
| 15:04 | <zcorpan> | http://code.google.com/p/wp-basis-theme/source/browse/trunk/basis-html5/footer.php?spec=svn118&r=118 |
| 15:06 | <zcorpan> | http://code.google.com/p/wp-basis-theme/source/browse/trunk/basis-html5/header.php?spec=svn118&r=118 |
| 16:15 | <Dashiva> | So if Shelley's judgement of the anti-summary arguments is valid, what does that say about pro-summary which has even less data, even less reasoning |
| 16:23 | <Philip`> | It's means they're on an equal footing |
| 18:41 | <Philip`> | http://www.khronos.org/news/press/releases/khronos-releases-opengl-3.2-third-major-opengl-release-within-twelve-months/ - "... the new WebGL™ standard for 3D on the web ..." |
| 18:41 | <Philip`> | Seems to be the first time they've used that name, as far as I can see |
| 18:41 | <Philip`> | (presumably for the 3D canvas stuff) |
| 18:43 | <Philip`> | http://www.tgdaily.com/images/stories/450teaser/opengl/openglslide1.jpg - HTML 5 is in there, plus an awful lot of arrows |
| 18:44 | <Philip`> | http://www.tgdaily.com/images/stories/450teaser/opengl/openglslide2.jpg - "OpenGL 3.2 exposes the capability of DX 10.0 GPUs" - it seems kind of sad that they're using a competing 3D API's version numbers to refer to hardware capabilities |
| 18:52 | <Darxus> | There is no way to say a page is in two languages? |
| 18:53 | <MikeSmith> | Darxus: you can put the lang attribute on individual elements |
| 18:54 | <Darxus> | MikeSmith: Awesome, thanks. |
| 18:54 | <MikeSmith> | np |
| 18:55 | <Philip`> | What if you're marking up a multilingual pun which could be read in either language? |
| 18:55 | <MikeSmith> | Darxus: but don't ever trust anything I say until you get independent confirmation from a knowledgeable third party. |
| 18:55 | <Darxus> | Hehe. |
| 18:56 | <MikeSmith> | Hixie: per Philip`s use-case, the lang attribute should clearly allow a list instead of a just a single language code |
| 18:56 | <gsnedders> | MikeSmith: n00b |
| 18:57 | MikeSmith | prepares v.nu patch of lang datatype-checking, in anticipation of Hixie's spec change |
| 18:58 | gsnedders | dreams of a simpler life |
| 19:00 | <MikeSmith> | gsnedders: it's spelled n〇０b, you n〇０b |
| 19:01 | <gsnedders> | Sry |
| 19:27 | <tantekc> | Hixie, Philip` I remember from past chats here that both of you have research that shows that the summary attribute has been problematic, ineffective or both. |
| 19:28 | <tantekc> | could you both add links to that research to the Summary attribute page on the whatwg wiki? |
| 19:28 | <tantekc> | http://wiki.whatwg.org/wiki/Table_Summary |
| 19:28 | <tantek> | Thanks, and appreciated. |
| 19:38 | <webben> | tantek: |
| 19:40 | <webben> | nvm ... thought I had the link to hand |
| 19:44 | <Philip`> | tantek: I don't have anything that gives any conclusions like that, but there's some mostly-raw data at http://philip.html5.org/data/table-summary-values.html and http://philip.html5.org/data/table-summary-values-dotbot.html which I'm too lazy to bother editing the wiki for |
| 19:48 | <tantek> | Philip` wow that second link is quite revealing. |
| 19:51 | <tantek> | Philip` would you like any specific attribution (e.g. full name) on the wiki in addition to the links? |
| 20:04 | <tantek> | Philip` - thanks for the research. I've amo�� your links: http://wiki.whatwg.org/wiki/Table_Summary#Research |
| 20:05 | <tantek> | please feel free to make any corrections to the text I added. |
| 20:08 | <annevk2> | tantek, there is also http://esw.w3.org/topic/HTML/SummaryForTABLE though I think it is somewhat confusing and long |
| 20:09 | <tantek> | annevk2 - a few weeks ago there was a discussion about the esw wiki, and several contributors here in this IRC channel claimed their edits were removed. |
| 20:09 | <tantek> | as such I proposed that they instead add a page to the whatwg wiki to track the issue |
| 20:09 | <tantek> | and be careful to attempt to capture/preserve various points of view - as a scientist should. |
| 20:10 | <annevk2> | okidoki, just wanted to point out that wiki |
| 20:10 | <MikeSmith> | I propose that if they are going to behave like scientists, they should also wear white lab coats while editing the wiki. |
| 20:10 | <annevk2> | I'm somewhat succeeding at staying out of this mess so I think I won't contribute for now |
| 20:11 | <Philip`> | tantek: Attribution doesn't matter - people can go to the root domain to find contact information if they want to complain directly to me :-) |
| 20:11 | <tantek> | annevk2 - feel free to add a link to the other wiki page to the whatwg wiki so that others may discover it as well, and perhaps help by providing summaries (pun not-intended) of the "somewhat confusing and long" sections. |
| 20:19 | <annevk2> | let that be my only contribution then; done |
| 20:24 | <othermaciej> | I think the problem here is not of cataloging the evidence but of what seem to be irreconcilable worldviews |
| 20:25 | <othermaciej> | on the one hand, a belief in quantitative studies and willingness to break whatever eggs are necessary to make the omelet |
| 20:25 | <othermaciej> | and on the other hand, a belief in expertise and precedent, and that the issue should be primarily decided by the official designated experts |
| 20:26 | <othermaciej> | It seems to me like at this point, people are just repeating these positions at each other |
| 20:28 | <othermaciej> | (belief in the experts also results in an unreasonable burden of proof for any position that contradicts the official expert position) |
| 20:28 | <annevk2> | I think John changed his position somewhat in that he's not against research, but is against the HTML WG making decisions about the HTML language that contradict existing WAI advice. He argues that we should first change the advice before changing HTML. |
| 20:31 | <othermaciej> | I think most of the WAI/PFWG-affiliated people basically think it should be WAI's call, though some of them may be less open than John to changing what WCAG says |
| 20:33 | <othermaciej> | though the idea that WCAG Techniques should change before HTML5 suggests new techniques is kind of a chicken and egg problem |
| 20:33 | <tantek> | othermaciej - but the "experts" as you say, often disagree. witness the government document Hixie posted a link to. |
| 20:33 | <tantek> | as well as Joe Clark's "WCAG Samurai" effort: http://wcagsamurai.org/ |
| 20:34 | <tantek> | a well as: http://www.alistapart.com/articles/tohellwithwcag2 |
| 20:35 | <othermaciej> | tantek: I think the claim would be that for the W3C, the official W3C accessibility experts (namely WAI) have the jurisdiction to judge the input of other experts |
| 20:35 | <othermaciej> | (note: I'm not necessarily endorsing this view, just trying to state it dispationately) |
| 20:37 | <tantek> | I have a feeling that if W3C process/experts succeed in sufficiently slowing down HTML5 progress, at some point what happened before will happen again, WHATWG will continue progress independently. WHATWG didn't need W3C to get started (other than providing motivation/incentive), and potentially doesn't need it to finish HTML5. |
| 20:39 | <tantek> | Or we'll get a fork of HTML5 - the WHATWG version (which will presumably be what the browser vendors in WHATWG implement), and a W3C version that reflects whatever W3C experts can pile into it. |
| 20:41 | <othermaciej> | I would say the delay at this point is not so much the people making jurisdictional claims but the fact that nothing is ever resolved |
| 20:41 | <tantek> | othermaciej - but "nothing is every resolved" is just another way of saying filibuster AFAICT. |
| 20:41 | <annevk2> | cssquirrel is pretty much lastweekinhtml5 |
| 20:42 | <othermaciej> | The WHATWG context doesn't spawn perpetual flamewars, because what Hixie decides goes unless you have new info, so people learn to move on |
| 20:42 | <othermaciej> | in the HTML WG, the working group in theory has the authority to make a binding decision, but has basically never exercised that authority |
| 20:42 | <tantek> | othermaciej - I've found that documenting issues in a wiki, with data/research/opinions all captured can often reduce/end perpetual flamewars. |
| 20:43 | <othermaciej> | tantek: I definitely think it's useful to have the reference material gathered |
| 20:43 | <tantek> | in reading public-html - there is too much oft repeated, that would be easily disposed of if arguments were explained (and linked to) via URL on a wiki page. |
| 20:44 | <othermaciej> | I'm just concerned that some people seem to really be making an argument that is jurisdictional rather than epistemological |
| 20:44 | <tantek> | since I don't have the personal time volunteer to do this for WHATWG/HTML5 (I'm already doing this for microformats.org), this leaves me little choice other than to summarily delete messages from those that do the most oft-repeating. I'm open to alternatives. |
| 20:45 | <tantek> | s/summarily/automatically |
| 20:45 | <tantek> | othermaciej - even if it is a jurisdictional argument, capturing it will still allow the issues around such an argument to be documented (and hopefully resolved). |
| 20:46 | <tantek> | like appealing up to the W3C director to empower groups to do additional research beyond (and thus come to potentially different conclusions than) the top-down "expert" recommendations of other groups. |
| 20:47 | <othermaciej> | I don't think the W3C Process formally requires any WG to take the judgment of any other WG as definitive, though Working Groups are expected to coordinate |
| 20:48 | <annevk2> | yeah, I'm not sure where John gets that idea from |
| 20:48 | <annevk2> | I understand he'd like it to work that way, but that's certainly not how things work |
| 20:48 | <tantek> | othermaciej, from my experience with W3C Process, before documents can exit last call, groups MUST make mutually acceptable resolutions to issues raised by the cross-group working groups like WAI, i18n, etc. |
| 20:49 | <tantek> | (having personally taking a few documents through/past last call as an editor of W3C working drafts) |
| 20:49 | <tantek> | s/taking/taken |
| 20:49 | <annevk2> | e.g. the i18n WG has at times requested Unicode Normalization for certain things and the XML WG has declined |
| 20:50 | <tantek> | annevk2 - do you have a link to the disposition of issues on a last call working draft from XML WG that documents that? |
| 20:51 | <tantek> | othermaciej - not sure if you got the significance of http://wcagsamurai.org/ BTW |
| 20:51 | <gsnedders> | Oh noes! |
| 20:51 | <gsnedders> | It's a cabal! |
| 20:53 | <othermaciej> | there doesn't seem to be a formal requirement in the W3C Process to treat comments from WAI or the i18n group any differently than anyone else's to exit LC |
| 20:53 | <tantek> | accessibility expert Joe Clark deemed WCAG2 "nearly impossible ... to understand", and basically forked from WCAG1, and provided an errata'd WCAG1 to be used *instead of* WCAG2: http://wcagsamurai.org/errata/errata.html |
| 20:53 | <othermaciej> | though informally the Director could apply a different standard to determining whether their issues are Formally Addressed |
| 20:54 | <othermaciej> | yeah, I recall that WCAG Samurai is a divergent effort |
| 20:54 | <tantek> | othermaciej - I can't link to a formal requirement, but I do know from experience that in practice, the Director is expected to apply a different (more cautious?) standard to issues raised by WAI, i18n, etc. |
| 20:54 | <annevk2> | tantek, they did eventually agree it seems: http://lists.w3.org/Archives/Public/public-xml-core-wg/2009May/0023.html |
| 20:55 | <tantek> | othermaciej - the point is, WCAG2 is not without much criticism itself, to the point of causing a rift/split among experts that produced an alternative document. |
| 20:55 | <annevk2> | tantek, (the i18n WG agreed with a "lesser" solution) |
| 20:55 | <tantek> | annevk2 - that's usually what happens in these cases - some kind of compromise. a "lesser" solution, or dropped features (features that can't be agreed upon for example). |
| 20:56 | tantek | wonders if any / how much of WCAG 1 errata by WCAG Samurai has been incorporated (or even considered for incorporation) into HTML5 by Hixie http://wcagsamurai.org/errata/errata.html |
| 20:58 | <othermaciej> | the folks representing WAI don't seem very open to compromise, though perhaps with a more formal cross-WG request for comments things would be different |
| 20:59 | <tantek> | othermaciej - in terms of process problems, I strongly recommend you read: http://www.alistapart.com/articles/tohellwithwcag2#WCAG-documents:process |
| 21:16 | <annevk2> | i wonder if WAI made any statements in response to that article |
| 21:42 | <annevk2> | (I meant "pretty much like" above, not "pretty much", apparently the comparison made it to twitter...) |
| 21:54 | <Dashiva> | annevk2: Such is the burden of fame |
| 21:56 | <annevk2> | prolly also how a lot of bs comes into the world |
| 21:56 | <Dashiva> | The basis of news media, for one |
| 21:57 | <annevk2> | it's tempting to abuse the attention |
| 21:57 | <Dashiva> | That's what lastweek is for |
| 21:58 | <othermaciej> | if you're gonna read the logs in near-realtime, why not just join the channel? |
| 21:59 | <Dashiva> | The whatwg elite is uniform in geographical origin? That's new to me |
| 22:00 | <Dashiva> | I would call it refreshingly diverse considering how many countries are represented |
| 22:01 | <annevk2> | where's that from? |
| 22:01 | <Dashiva> | Shelley |
| 22:02 | <Dashiva> | http://www.cssquirrel.com/2009/07/09/comic-update-manners-after-the-xhtmlacolypse/#comment-26440 |
| 22:02 | <annevk2> | maybe she means not American? |
| 22:03 | <takkaria> | obviously, people who work for browser vendors and standards orgs are in a terrible situation if they want to write standards about browsers |
| 22:03 | <takkaria> | we should get some plumbers and some members of royal families in to make sure their viewpoints are heard too |
| 22:03 | <Dashiva> | Joe the Spec Writer |
| 22:03 | <annevk2> | wow, what a bs comment |
| 22:04 | <Dashiva> | Isn't othermaciej American? |
| 22:05 | <annevk2> | no |
| 22:05 | <othermaciej> | by current location, yes |
| 22:05 | <othermaciej> | by background, no |
| 22:05 | <Dashiva> | We're in trouble then. Quick, get us an American alibi. |
| 22:06 | <takkaria> | oh, let's get an Australian in too because they're about as far away from civilisation as you can get |
| 22:06 | <takkaria> | oh, wait |
| 22:08 | <othermaciej> | I'm also not "20-something", I grew up in poverty, and while I wouldn't call myself "disabled", I'm currently unable to use a mouse for extended periods |
| 22:08 | <othermaciej> | but hey, why let facts get in the way when you're stereotyping |
| 22:09 | <annevk2> | http://twitter.com/johnfoliot/statuses/3111346948 -- not unexpected |
| 22:10 | <Dashiva> | I thought we had an Australian, but now I can't think of any |
| 22:11 | <Dashiva> | annevk2: So he's finally admitting it was a game. Fun. |
| 22:11 | <takkaria> | Lachy is from Oz I think |
| 22:11 | <othermaciej> | Lachy is from Oz |
| 22:11 | <annevk2> | yup |
| 22:12 | <annevk2> | and chaals! |
| 22:12 | <takkaria> | chaals isn't part of the cabal though |
| 22:12 | <Dashiva> | I don't think he counts as part of the whatwg elite! |
| 22:12 | <annevk2> | he's my manager though |
| 22:12 | <Dashiva> | sssh |
| 22:12 | <Dashiva> | Don't tell them |
| 22:12 | <othermaciej> | yeah, anne is not allowed to have an opinion without checking it with chaals first |
| 22:13 | <Dashiva> | I wonder what sam would say about that tweet |
| 22:19 | <Philip`> | Discussing specifics and then generalising seems like a sensible approach, compared to just discussing generalities |
| 22:21 | <takkaria> | but the specifics are biased and ignore expertise |
| 22:21 | <Dashiva> | I notice cssquirrel joined the ranks of people who discovered Hixie's bible |
| 22:22 | <Hixie> | the last part of that handling-people document is especially apt given all the process nonsense recently |
| 22:22 | <Dashiva> | I don't think they get the irony |
| 22:23 | <Hixie> | few people who quote that document do |
| 23:25 | <annevk2> | oh mattur is awesome |
| 23:25 | <annevk2> | http://www.alistapart.com/comments/tohellwithwcag2/#10 |
| 23:29 | <Dashiva> | ... is that authentic? |
