| 00:01 | <hober> | In HTML5 as currently specced, <header> can be used as the header of many elements, including <body>, <article>, <section>, and the like. |
| 00:01 | <hober> | I don't see why "we will have to still use ..." |
| 00:02 | <paulgendek> | for practical css designs |
| 00:02 | <hober> | just use selectors that pull out the relevant elements |
| 00:02 | <paulgendek> | first child and > don't work in ie6 |
| 00:02 | <hober> | consider <body><header>...</header><article><header>...</header>...</article>...</body> |
| 00:02 | <paulgendek> | for body > header |
| 00:02 | <inimino> | IE6 is hardly relevant in the HTML5 timeframe |
| 00:03 | <hober> | the "article header" selector works fine in all relevant browsers, no? |
| 00:03 | <inimino> | for many people IE6 isn't worth supporting even now |
| 00:04 | <paulgendek> | i work for a major publishing company and there is still a significant percentage of ie6 users across all of our brands, of over US magazines |
| 00:04 | <paulgendek> | which is a pretty wide range of diverse niches |
| 00:05 | <paulgendek> | so it seems like it would still need to be supported for some time longer, even though the fight is going pretty strong lately |
| 00:05 | <paulgendek> | and there is a lot of html5 website development moving rapidly |
| 00:06 | <paulgendek> | so i'm worried about moving forward, the problem is that we _need_ id specific selectors for layout structural elements |
| 00:06 | <hober> | you could leave out "layout structural" in that sentence |
| 00:06 | <paulgendek> | so header, content, sidebar, footer, should all be <sections> |
| 00:06 | <paulgendek> | and would still need id's |
| 00:07 | <hober> | there are lots of designs which require the use of class="" and/or id="" in browsers with impoverished selector support |
| 00:07 | <hober> | this isn't a spec bug |
| 00:07 | <hober> | and has nothing to do with the elements you're talking about |
| 00:08 | <paulgendek> | understood, but i don't understand using <header id="header"> and <section id="content"> and being more semantic and organized in the xml style |
| 00:08 | <hober> | I definitely don't follow how you get from "I'll need to use class='' or id='' in some cases" to "we shouldn't have these elements at all" |
| 00:08 | <hober> | err, I don't understand what you just wrote. |
| 00:09 | <paulgendek> | i mean header and footer in the sense of the location of the design/structure of the site, not the actual <header> element.... <header>/<footer> make a lot of sense being the top/bottom containers for <sections>/<articles> etc |
| 00:09 | <paulgendek> | but it doesn't make sense being used as the header container in a design |
| 00:10 | <paulgendek> | i feel that after body, should be sections... and in the #header section, you can have a header/footer, hgroup, inner content, etc |
| 00:10 | <hober> | I don't follow. It makes just as much sense to use <header> as the header for a <body> element as it does to use it as the header for some other sectioning element. |
| 00:10 | <paulgendek> | and if the design requires wrapping containers around sections, divs are used |
| 00:10 | <hober> | sometimes you'll need to distinguish different <header> elements on the page for styling purposes, so we have class="" and id="", but this also applies to all other elements in the language. |
| 00:11 | <hober> | e.g. <em class="rfc2119">should</em> might be styled differently than <em>should</em> |
| 00:11 | <hober> | that doesn't mean we need two separate elements |
| 00:14 | <paulgendek> | it just seems like it's redundant to have <header> within the body and still need to add id="header" 90%+ of the time in real-world cases than to group all the "header" items of a design into <section id="header">, would it then make sense to have <header> under body but place a <section> within it to apply the structural/layout id ? |
| 00:15 | <hober> | Let's assume I have a page with one <body>, one <header> child of <body>, and several <article> and <section> elements with their own <header>s. |
| 00:16 | <paulgendek> | <header> seems more appropriate at meaning to the top section of the parent element... and using it under <body> would mean the same thing... so then body > header would be appropriate for accessibility links, "skip to", etc, and you would then still have <section id="header"> |
| 00:16 | <hober> | the number of <header> elements that require distinguishing with class="" or id="" (in browsers with impoverished selector support) in such as case is more like 10%, not 90%. |
| 00:18 | <paulgendek> | if you write css targeting header, and you want to design the header of the layout, you would need to use body > header selector... which is a lot more to type (ridiculous but practical) and not natively supported in ie6 |
| 00:18 | <Hixie> | wtf, http://webstore.iec.ch/webstore/webstore.nsf/artnum/025408!OpenDocument&Click= |
| 00:18 | <Hixie> | the hard copy of sRGB is cheaper than the PDF! |
| 00:19 | <hober> | what's wrong with <body><header id="foo">...</header><article><header>...</header>...</article>...</body>? |
| 00:20 | <beowulf> | you can select that without a class or id, obviously |
| 00:21 | <paulgendek> | so a 3-col page layout would be header, section.col, section.col, section.col, footer? |
| 00:23 | <paulgendek> | hober: in most cases, at least in my experience with magazine-layout/blog websites, is that the dom is never that simply constructed |
| 00:24 | <hober> | I'd probably use <div> for the columns in such a layout |
| 00:24 | <paulgendek> | i guess that is what i'm looking for... what is the "holy grail" for common floating column page layouts in the html5 world? |
| 00:24 | <paulgendek> | in base structure |
| 00:26 | <paulgendek> | i may be confusing myself here :P |
| 00:26 | <hober> | body { column-count: 3; column-gap: 2em; }? |
| 00:26 | <paulgendek> | hober: in a perfect world |
| 00:26 | <hober> | I was joking :) |
| 00:26 | <paulgendek> | haha |
| 00:26 | <paulgendek> | hoped so |
| 00:27 | <hober> | I think the real answer is something handwavy like "use the most semantically appropriate element for your context, or <div>/<span> if none exists" |
| 00:27 | <Hixie> | 31 to go |
| 00:27 | <hober> | cont. "then layer on additional/more precise semantics with class=''" |
| 00:29 | <paulgendek> | idk, i think this looks much more elegant: http://www.grabup.com/uploads/418240ad1cf963160cc003c2b76cd0fe.png?direct |
| 00:32 | <paulgendek> | and if the h-tags are used in order, along with hgroups when needed, and within <header> tags... it would be practical to design with css, and be semantic... |
| 00:32 | <paulgendek> | am i missing something? |
| 00:36 | <hober> | paulgendek: I think I would have marked that up more like so: http://paste.lisp.org/display/85165 |
| 00:37 | <deltab> | Hixie: with the PDF they have to send someone out to colour-calibrate your screen |
| 00:38 | <Hixie> | 26 to go... |
| 00:38 | <Hixie> | deltab: hah |
| 00:45 | <paulgendek> | hober: that really makes me uncomfortable with theming complicated website headers and everything is targeting a first-child or > selector body header:first-child or body > header.... there WILL need to be an id there, and <header id="header"> is redundant |
| 00:55 | <paulgendek> | are there any documented best practices? |
| 00:58 | <paulgendek> | i consider the header of a design to be sectioning content, not flow content, but that the section contains flow content |
| 00:58 | <paulgendek> | i meant, i consider the header container of a design |
| 01:06 | <paulgendek> | would this be appropriate for use today? http://www.grabup.com/uploads/46007d0ff9e19b933047f0eb0cc05ced.png?direct |
| 01:07 | <paulgendek> | using sections with id's for sectioning content, but still using <header>/<footer> in their section containers |
| 01:08 | <paulgendek> | the section element is the only element that is spec'd to be bolth flow content and sectioning content categories |
| 01:08 | <paulgendek> | s/bolth/both |
| 01:10 | <paulgendek> | besides article, aside, and nav, of course |
| 01:17 | <paulgendek> | or you would use header, nav, article, aside, footer for the sectioning |
| 01:17 | <paulgendek> | anyone? |
| 01:21 | <smedero> | i've always though <header> & <footer> were more compelling when nested inside an <article> or a <section> than when used in a traditional website template header & footer model. |
| 01:23 | <smedero> | i agree <header id="header"> is annoying and relying on selectors could be problematic with large CMS deployments that have a lot of hands in the pot. |
| 01:29 | <Hixie> | 18 to go... |
| 01:29 | <paulgendek> | smedero: here's a template that i'm working with, let me know what you think: http://www.grabup.com/uploads/8b5623a6613dafd5dfd99df70b7081a9.png?direct |
| 01:36 | <smedero> | on a first pass that only thing I had to go back and re-read the spec on was <hgroup>. |
| 01:37 | <paulgendek> | smedero: i've altered the h-tags throughout slightly, for seo: http://www.grabup.com/uploads/b6e7062958f481eb4088d747c23f2cc3.png?direct |
| 01:40 | <Hixie> | woo, all done |
| 01:40 | <smedero> | wrt <header id="header">. Many layouts I see about, the "page header" tends to have it is own "header" and "footer" so-to-speak... so I really think <section> is most appropriate there (because you can't nest a <footer> in <header>... or at least you couldn't last I read that section.) |
| 01:42 | <paulgendek> | thank you smedero |
| 01:42 | <paulgendek> | that was very helpful |
| 02:15 | <khmer42> | Does anyone know if any of the broswers (including dev versions) currently have an implementation of the websockets specification? |
| 02:16 | <Hixie> | khmer42: webkit and gecko are working on it, dunno if they have anything testable yet |
| 02:19 | <khmer42> | Hixie: Thanks. Do you know if without using comet techniques is there anything else that we can work against (even if it doesn't follow the spec) until someone has got an implementation out? I'm thinking Gears/Adobe AIr/browser plugins. |
| 02:19 | <Hixie> | i expect flash has something like this |
| 02:20 | <khmer42> | After watching the Google Wave demo, I thought websockets had been released into the wild. Google must be using long polling or something, well I suppose they do have the resources :-) |
| 02:24 | <khmer42> | Yep I see Flash has XMLSocket, I'll see if anyone else has made JS lib to bridge the WebSockets spec to this, if not I'll have a stab at it myself. |
| 02:32 | <inimino> | khmer42: look at Orbited, they had something very similar |
| 02:32 | <Hixie> | gsnedders|work: nevermind, i did the biblio filtering myself |
| 02:36 | <khmer42> | inimino: Thanks, I checked them out before and also Kazing but looked like they were using long polling that imitated a socket. We don't have the servers to scale that solution. |
| 02:49 | <inimino> | khmer42: yes, it is long polling |
| 03:09 | <franksalim> | khmer42, at Kaazing, we have done what you are talking about |
| 03:10 | <franksalim> | khmer42, we use flash's socket (not the xml socket, but the tcp one) and bridge to javascript. if we can't use flash, then we try http streaming. then long polling only as a last resort |
| 03:11 | <franksalim> | *(xml messages over tcp. xml vs. tcp doesn't make any sense.) |
| 03:11 | <khmer42> | franksalim: Sounds interesting, I will got check it out. Is it a complete port of the websocket spec so it will just be ignored in future as websocket compliant browsers come into play? |
| 03:12 | <franksalim> | khmer42, yes. it first checks for native websocket |
| 03:13 | <khmer42> | franksalim: Cool, I had a play with Kaazing last year and like where it was heading. Is the front end JavaScript API independent of any server products you have? (if you have such products) |
| 03:14 | <franksalim> | khmer42, no, there is a single product |
| 04:28 | <paulgendek> | why can't <nav> be inside of <footer> ? |
| 04:44 | <Code_Bleu_> | for those of you using Twitter, I created a "Twibbon" overlay for your avatar. Sorry if this is inappropriate to do..just thought you might like to show your support. http://twibbon.com/join/WHATWG---HTML5 |
| 04:57 | <othermaciej_> | So far I am really enjoying Microsoft's new more active participation in the WG |
| 05:18 | <stefanschipor> | Has anyone tried using new html5 elements like article with css pseudo-class selectors (I'm trying first-child)? I'm running FF 3.5 and it doesn't seem to work. |
| 05:19 | <stefanschipor> | btw, if this is the wrong place or way to ask the question please correct me. new here |
| 05:41 | <othermaciej_> | I haven't tried it |
| 05:41 | <othermaciej_> | did you check if the <article> element ends up in the DOM properly? |
| 06:18 | <stefanschipor> | that's it :) I had a h1 before the articles which was hidden so I kinda missed it. thanks a lot! :) |
| 06:23 | <othermaciej> | did Mozilla drop their <a ping> implementation? |
| 06:23 | <othermaciej> | I can't remember what happened with that |
| 06:24 | <paulgendek> | if anyone is bored and would like to critique: http://paulgendek.com/html5/ html5 blog layout, validates, with some hcard microformats... |
| 06:24 | <paulgendek> | going to do single article view with <dialog> for comments |
| 06:31 | <tantek> | paulgendek - looks like Optimus likes your microformats: http://microformatique.com/optimus/?format=validate&uri=http%3A//paulgendek.com/html5/ |
| 06:32 | <paulgendek> | tantek: :) i also added a few hResume tags, although i don't know what will pick up on it |
| 06:32 | <tantek> | I think microtron might |
| 06:33 | <paulgendek> | tantek: is it running anywhere? |
| 06:33 | <paulgendek> | online |
| 06:41 | <othermaciej> | ok, I proposed actually closing some issue tracker issues |
| 06:42 | <othermaciej> | let's see if it works! |
| 06:42 | <tantekc> | othermaciej - your proposed closures seem reasonable to me. |
| 06:46 | <hsivonen> | othermaciej: I think I saw the code for implementing @ping last month |
| 06:46 | <hsivonen> | my guess is that the code is there but preffed off |
| 06:47 | <othermaciej> | hsivonen: do you know if Mozilla has any intent to actually ship the feature? |
| 06:47 | <hsivonen> | othermaciej: I know nothing about intent |
| 06:47 | <othermaciej> | hsivonen: that's what I was hoping to flush out |
| 06:52 | <Hixie> | i imagine chrome will want to support it eventually |
| 06:52 | <Hixie> | though i doubt it's a priority |
| 06:53 | <Hixie> | (ping="" could dramatically improve the performance of google search while improving the user's ability to control his privacy, which are both things google cares very much about) |
| 06:59 | <Hixie> | othermaciej: re ARIA, I don't think we have any reason to believe the ARIA group isn't working at the fastest rate possible |
| 07:00 | <othermaciej> | Hixie: at the last HTML WG telecon, someone (who I think was a PFWG member) they said they would not give a reply to your issue for 2-3 months |
| 07:00 | <Hixie> | oh |
| 07:00 | <Hixie> | well then aria won't make LC |
| 07:00 | <Hixie> | we can always do it after LC |
| 07:00 | <othermaciej> | I don't care if it's the fastest rate possible, it's clearly not acceptable |
| 07:01 | <Hixie> | is there a rush? |
| 07:01 | <othermaciej> | (they said they want to do that so they can address all LC comments at once) |
| 07:01 | <Hixie> | do they realise that the odds are that the LC comments will get further replies from people saying "i'm not happy with this..." |
| 07:01 | <Hixie> | ? |
| 07:01 | <othermaciej> | I'm not sure they thought it through |
| 07:01 | <othermaciej> | I guess they want to make sure all their answers consider all comments... or something |
| 07:02 | <othermaciej> | given when you sent your comment, 2-3 months from now would result in a 6 month response time from them |
| 07:02 | <othermaciej> | which I think is unacceptable for meaningful coordination |
| 07:03 | <othermaciej> | also, I think ARIA missing LC is totally an option for the WHATWG, but probably would not fly in the HTML WG (it's possible the WG would vote to agree that ARIA can wait until after first LC, but I wouldn't bet on it) |
| 07:03 | <Hixie> | it's far less than the time it took me to reply to the e-mails i was replying to today |
| 07:04 | <othermaciej> | that is true, but you reply to emails that are specifically cast as urgent requests much faster than that |
| 07:04 | <Hixie> | yeah well i'm not expecting the HTMLWG to actually reach LC until the WHATWG is ready for CR, at the rate the chairs are running the group |
| 07:04 | <Hixie> | sure |
| 07:05 | <othermaciej> | in case you haven't noticed - I'm trying to change the way the chairs are running the HTML WG for pretty much that reason |
| 07:05 | <Hixie> | good luck |
| 07:05 | <othermaciej> | I'll need it :-( |
| 07:07 | <Hixie> | i expect that they're working on this weekly cycle now, because of the telecon |
| 07:07 | <Hixie> | so you'll not hear anything until thursday or whenever the telecons are |
| 07:07 | <Hixie> | this is another reason i hate telecons -- people end up paralysed and unable to make decisions without holding the phone in their hands |
| 07:08 | <othermaciej> | I do not enjoy anything about telecons |
| 07:09 | <othermaciej> | If the issues I suggested for immediate closure get closed on Thursday, or, hell, even a week from Thursday, that will still be better than I am expecting |
| 07:09 | <Hixie> | me too |
| 07:15 | <hsivonen> | othermaciej: IIRC, I have sent some unresponded-to ARIA feedback in March 2008 (before ARIA went to LC). My preference would be for PFWG to send out replies as soon as they know what they are going to say. |
| 07:15 | <othermaciej> | hsivonen: if I understood what was said on the telecon correctly, they want to defer deciding what they are going to say until they have had time to consider every single issue |
| 07:16 | <hsivonen> | othermaciej: it seems to me, that key questions regarding inclusion by reference into HTML 5 hinge on the "Implementors' Guide" side--not necessarily on "ARIA 1.0" |
| 07:16 | <othermaciej> | that doesn't seem like a good approach to me, but I'd rather just send a WG-to-WG request for expedited processing |
| 07:17 | <othermaciej> | hsivonen: what do you think are the key questions? |
| 07:17 | <hsivonen> | othermaciej: UA implementation requirements |
| 07:17 | <hsivonen> | othermaciej: and I think the UA implementation requirements have some bearing on what makes sense to author |
| 07:18 | <othermaciej> | hsivonen: can you give a specific example? |
| 07:18 | <hsivonen> | othermaciej: what must an UA do with <input type=radio checked role=checkbox aria-checked=false> |
| 07:19 | <othermaciej> | hsivonen: I think regardless of the UA implementation requirements, that markup should be non-conforming |
| 07:19 | <hsivonen> | othermaciej: I agree, but that's just our opinion |
| 07:20 | <othermaciej> | hsivonen: sure, but I don't think the Implementor's Guide will affect our opinion one way or the other |
| 07:20 | <othermaciej> | Here's why I think so. |
| 07:20 | <hsivonen> | othermaciej: it will affect HTML 5 plus its normative references having UA implmentation reqs |
| 07:22 | <othermaciej> | (A) ARIA can't (by its own goals and scope) require anything different than HTML5 for display and behavior of that markup other than through accessibility APIs - so that markup has to be rendered as a checked radio button for normal visual interactive use. |
| 07:22 | <othermaciej> | (B) ARIA Implementor's Guide can specify two possible behaviors for that markup from an accessibility POV: |
| 07:22 | <othermaciej> | (1) The conflicting ARIA markup is ignored. |
| 07:23 | <othermaciej> | (2) The conflicting ARIA markup means that the checked radio button is expressed as an unchecked checkbox through screen readers and such. |
| 07:23 | <othermaciej> | clearly neither of B.1 or B.2 is likely to be intended or good behavior, so either way the markup should be nonconforming |
| 07:23 | <othermaciej> | now, it might be that we think B.2 is bad UA behavior on its own terms, but that seems like a separate issue from authoring conformance |
| 07:24 | <othermaciej> | I personally would expect B.1 to be a little bit easier to implement, but perhaps more complex to specify |
| 07:25 | <hsivonen> | othermaciej: it seems that there's disagreement on what's easier: B.1 or B.2 |
| 07:26 | <hsivonen> | othermaciej: IIRC, Aaron Leventhal advocated position B.2 |
| 07:26 | <othermaciej> | hsivonen: neither is completely trivial |
| 07:26 | <othermaciej> | personally I'd be willing to implement either, if it's considered as error-handling behavior |
| 07:27 | <othermaciej> | (the hard part of B.1 is explicitly ignoring certain aria roles, states and properties in particular cases) |
| 07:28 | <othermaciej> | (the hard part of B.2 is explicitly ignoring built-in behavior of the element when certain aria roles/states are set) |
| 07:30 | <othermaciej> | I think there's other examples where it's not clear to me how B.1 or B.2 would dictate the UA behavior |
| 07:30 | <othermaciej> | for example: <input type=radio checked aria-checked=false> |
| 07:31 | <othermaciej> | I guess it's mainly a problem for position B.2, for B.1 the answer is clear |
| 07:31 | <othermaciej> | but in the case of B.2, does the aria state still apply, even though there is no relevant role defined? |
| 07:31 | <othermaciej> | or, conversely: <input type=radio checked role=checkbox> |
| 07:32 | <othermaciej> | under B.2, does ARIA report that as a checked checkbox, or a checkbox with no defined checked state at all? |
| 07:35 | <hsivonen> | no idea |
| 07:44 | <paulgendek> | is there an issue with 'figure legend' ? it's in the source but firebug doesn't see the legend, font is inherited from figure |
| 07:44 | <Hixie> | yeah <figure> doesn't work in most browsers yet |
| 07:45 | <paulgendek> | is there a javascript fix for that yet? |
| 07:45 | <Hixie> | dunno |
| 07:45 | <paulgendek> | thx |
| 07:46 | <Hixie> | if there is, nobody has updated the issue marker at http://www.whatwg.org/specs/web-apps/current-work/#the-legend-element yet |
| 07:46 | <Hixie> | (the fifth icon in those boxes represents js implementations) |
| 07:47 | <hsivonen> | What document conformance rules is Optimus based on? |
| 07:55 | <Lachy> | othermaciej, why didn't you suggest closing ISSUE-4? |
| 07:55 | <Lachy> | (html-versioning) |
| 07:56 | <othermaciej> | Lachy: I personally think it should be closed with no change to the spec, but there has been continuing debate and Larry intends to make a proposal |
| 07:56 | <othermaciej> | Lachy: so I'm leaving that one in the hands of the chairs |
| 07:56 | <Lachy> | ok |
| 07:56 | <Philip`> | Hixie: #refsE163 and #refsRFC2965 are still missing |
| 07:57 | <Hixie> | i just fixed 2965 |
| 07:57 | <Hixie> | E163 is there though |
| 07:57 | <othermaciej> | paulgendek: there's a problem with parsing of <legend> in all existing browsers, and you can't practically use <figure> with backup styling until it is fixed |
| 07:57 | <othermaciej> | paulgendek: I raised the issue with Hixie but he was not inclined to increase the number of elements in HTML to fix it |
| 07:58 | <Hixie> | <figure>'s not important enough. just pretend that it's not in html5 and that we added it 3 years from now. |
| 07:58 | <othermaciej> | Lachy: I tried to limit my suggested closures to thinks that it's just painfully obvious should be closed, and where there has not really been discussion to the contrary |
| 07:59 | <Lachy> | othermaciej, any idea when the <legend> parsing issues will be fixed in webkit? |
| 07:59 | <othermaciej> | once all browsers either adopt HTML5 parsing or at least change parsing of <legend> not found in a <fieldset>, <figure> will be practically usable |
| 08:00 | <Hixie> | on a completely different note, does anyone want to volunteer to take point on the encoding aliases issue? |
| 08:00 | <othermaciej> | Lachy: at the very latest, when we adopt HTML5 parsing, but I will propose doing it sooner |
| 08:00 | <Lachy> | Hixie, what's the issue? |
| 08:00 | <Hixie> | lachy: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021207.html |
| 08:00 | <Philip`> | Hixie: I don't see E163 there |
| 08:00 | <Philip`> | e.g. http://www.whatwg.org/specs/web-apps/current-work/#refsE163 doesn't exist |
| 08:00 | <Philip`> | (but is referenced) |
| 08:00 | <Hixie> | Philip`: hm, odd |
| 08:01 | <Hixie> | it's in the source |
| 08:01 | <Hixie> | wonder what broke |
| 08:03 | <Lachy> | Hixie, what specifically needs to be done? Do we need to update the IANA registry? |
| 08:04 | <Hixie> | Lachy: yeah |
| 08:04 | <Hixie> | Lachy: basically i want to remove the "Additional character encoding aliases" table |
| 08:04 | <Hixie> | Lachy: and just have hte IANA registry be all up to date |
| 08:05 | <Hixie> | Philip`: wtf |
| 08:05 | <Lachy> | ok. I don't have time to do it right now, but if no-one else volunteers within a few weeks, I might be able to do it |
| 08:06 | <Hixie> | k |
| 08:06 | <Lachy> | what's the process for updating the IANA registry? |
| 08:06 | <Hixie> | depends on the registry; i haven't looked into what it takes to update that one |
| 08:08 | <Hixie> | given this line: href="#refsE163">[E163]</a> <a href="#refsX121">[X121]</a></p> |
| 08:08 | <othermaciej> | Hixie, hsivonen: does either of you think it is useful to continue tracking this as an issue: http://www.w3.org/html/wg/tracker/issues/17 |
| 08:09 | <Hixie> | why does this not match two things: while ($substedline =~ m/\G.*href="#refs([^"]+)"/osg) { |
| 08:10 | <Lachy> | Looks like it will take a few e-mails to this list http://www.iana.org/assignments/charset-info |
| 08:10 | <hsivonen> | othermaciej: depends on what MQ says now. I'll have to check |
| 08:11 | <Lachy> | http://tools.ietf.org/html/rfc2978 |
| 08:11 | <othermaciej> | would it be inappropriate spamming if I suggested a bunch more issue closures? |
| 08:11 | <othermaciej> | I am doing one per message to associate them in the issue tracker |
| 08:11 | <Lachy> | othermaciej, doesn't the issue tracker allow one message to be associated with multiple issues? |
| 08:12 | <othermaciej> | Lachy: I don't know - I'm counting on the automated detection of ISSUE-nn in the subject |
| 08:12 | <Hixie> | othermaciej: we fixed that years ago |
| 08:12 | <hsivonen> | othermaciej: as far as I can tell, the MQ WS issue still stands |
| 08:12 | <Lachy> | looks like it does |
| 08:13 | <Hixie> | othermaciej: (U+000B isn't a whitespace character anymore in HTML5) |
| 08:13 | <othermaciej> | is it fixed in HTML5? |
| 08:13 | <hsivonen> | Hixie: oh |
| 08:13 | <Lachy> | see http://www.w3.org/html/wg/tracker/issues/1 and http://www.w3.org/html/wg/tracker/issues/4 -- your last mail appears in both |
| 08:13 | <hsivonen> | Hixie: nice |
| 08:13 | <hsivonen> | I wonder how I forgot |
| 08:13 | <Hixie> | i'd forgotten too |
| 08:13 | <Hixie> | i just checked :-) |
| 08:13 | <Hixie> | had to look up wtf vertical tab was first |
| 08:14 | <othermaciej> | Lachy: is it searching the text? |
| 08:14 | <hsivonen> | othermaciej: so yeah, the issue has been addressed. No point in keeping it open. |
| 08:14 | <Lachy> | othermaciej, yes |
| 08:14 | <othermaciej> | Lachy: do you think it would be better to gang them up? |
| 08:14 | <Lachy> | yes |
| 08:15 | <Philip`> | Hixie: Because the .* is greedy and will match the whole first href, I expect |
| 08:16 | <Philip`> | Hixie: You probably want .*? |
| 08:16 | <Hixie> | ohhh! |
| 08:16 | <Hixie> | yes |
| 08:16 | <Hixie> | thanks |
| 08:18 | Philip` | would just use "while ($substedline =~ /href="#refs([^"]+)"/g)" which works the same and has fewer funny characters |
| 08:19 | <Hixie> | there's an implied \G? |
| 08:19 | <Hixie> | i always had problems using /g |
| 08:19 | <othermaciej> | Hixie: is there anything to do in response to this: http://www.w3.org/html/wg/tracker/issues/26 |
| 08:20 | <Hixie> | (without the \G, i mean) |
| 08:20 | <othermaciej> | (it appears to be suggestions for accessibility of the spec text itself) |
| 08:20 | <Hixie> | for one of those things we're waiting for gsnedders to add features to anolis |
| 08:21 | <Hixie> | i can't read the bottom two paragraphs, they're too "wall of text" for me |
| 08:21 | <Hixie> | i guess i have a disability, and whoever wrote that doesn't know how to write accessible comments :-) |
| 08:21 | <hsivonen> | what's still pending about issue 37? |
| 08:21 | <othermaciej> | #3 explains why hex/rgb colors are supposed to be bad |
| 08:21 | <hsivonen> | also, wasn't issue 54 addressed long ago? |
| 08:22 | <Hixie> | Philip`: ok fixed, thanks for catching that |
| 08:22 | <hsivonen> | issue 60 is not realistically actionable |
| 08:23 | <othermaciej> | #4 in issue-26 looks too vague to be actionable |
| 08:23 | <Lachy> | issue 60 should have been closed at the telcon a month ago. It was kept open for silly reasons |
| 08:23 | <othermaciej> | I guess I won't suggest closing it if there are anolis changes planned which will help |
| 08:23 | <othermaciej> | hsivonen: I don't understand why 37 is open, indeed |
| 08:24 | <othermaciej> | also I thought 54 was addressed |
| 08:24 | <hsivonen> | Is anyone but Larry expressing active interest in keeping issue 4 open? |
| 08:24 | <othermaciej> | and 60 should obviously be closed in light of the news about the XHTML2 WG |
| 08:24 | <Lachy> | issue 54 is pending the registration of the about: URI scheme |
| 08:25 | <Lachy> | I haven't heard from Joseph in a while, so I don't know what he's doing about that RFC |
| 08:25 | <othermaciej> | hsivonen: no idea - I would hope the chairs would make some assessment of who has objections |
| 08:26 | <Philip`> | Hixie: It's similar to an implied \G, except it starts where the previous execution of the current regexp on the current string left off, whereas \G starts where the previous regexp on the current string left off (even if it's a different regexp) |
| 08:27 | <Philip`> | Hixie: (so \G is useful when chaining multiple regexps together, and /g works fine if you're just looping over a single one) |
| 08:27 | <Hixie> | Philip`: ah, i see. yeah, i usually use /g with multiple regexps, that's why i had trouble without \G. |
| 08:27 | <Hixie> | Philip`: thanks. |
| 08:29 | <othermaciej> | do these remain issues of controversy (it's not clear to me from the issue tracker item what the point is): <http://www.w3.org/html/wg/tracker/issues/27>; <http://www.w3.org/html/wg/tracker/issues/28>; |
| 08:29 | <Hixie> | for 27, i'm fine with the WHATWG registry, but others are probably not |
| 08:29 | <Philip`> | Hixie: (Also the /o is redundant unless you've got interpolated variables in the regexp, and the /s is redundant since you're only processing a single line) |
| 08:30 | <Hixie> | 28 is fixed by abarth's mimesniff draft |
| 08:30 | <Philip`> | Hixie: (Also you should get rid of all the pesky whitespace and variable names, they're just wasting bytes :-( ) |
| 08:30 | <gsnedders> | othermaciej: Anolis changes for #4 in issue-26? |
| 08:30 | <Hixie> | Philip`: yeah i just always include /o and /s |
| 08:30 | <gsnedders> | othermaciej: Or one of the others? |
| 08:30 | <othermaciej> | gsnedders: Hixie mentioned that something in http://www.w3.org/html/wg/tracker/issues/26 is waiting on anolis changes - I do not know what he had in mind |
| 08:30 | <gsnedders> | ah, yeah |
| 08:30 | <Hixie> | Philip`: /s actually isn't redundant here, one of the operations that makes $line into $substedline can introduce more lines |
| 08:30 | <othermaciej> | Hixie: does the HTML5 spec completely defer to mimesniff now? |
| 08:31 | <Hixie> | othermaciej: yeah |
| 08:31 | <Hixie> | othermaciej: where appropriate, anyway |
| 08:31 | gsnedders | wonders where in the multi-level feedback queue of his to-do list that is |
| 08:32 | <gsnedders> | oh, there |
| 08:32 | gsnedders | shrugs, and heads off to work |
| 08:32 | <Philip`> | Hixie: Oh, okay |
| 08:32 | <gsnedders> | Hixie: I'll try and work out the encoding change today though |
| 08:32 | <Philip`> | Hixie: Clearly you shouldn't use such confusing variable names like "$substedline", and should try to put absolutely everything into $_ |
| 08:33 | <Hixie> | gsnedders: i don't mind the encoding change at all |
| 08:33 | <gsnedders> | Hixie: I do. You specify US-ASCII and get UTF-8. |
| 08:33 | <Hixie> | Philip`: this is nested inside several loops, one of which uses $_ :-) |
| 08:33 | <Hixie> | gsnedders: k :-) |
| 08:34 | <gsnedders> | Hixie: If you specify US-ASCII, you should get US-ASCII. |
| 08:34 | <gsnedders> | I spoke to jgraham about it briefly yesterday, I suspect it is in the PMS code the bug :P |
| 08:34 | <heycam> | Hixie, what do you expect calling mutator methods like setHours() on a Date object returned from HTMLTimeElement.time and friends to do? |
| 08:34 | <heycam> | anything? |
| 08:35 | <Hixie> | gsnedders: can i specify cross-spec cross refs and get those too? :-) |
| 08:35 | gsnedders | stabs Hixie |
| 08:36 | <Lachy> | gsnedders, great, now who will edit the spec? |
| 08:36 | <Hixie> | manu, apparently |
| 08:36 | <gsnedders> | Lachy: I didn't say I killed him, or harmed him that much. |
| 08:36 | <Hixie> | heycam: i expect the Date object to be a real Date object with no relationship to the underlying attribute |
| 08:36 | <heycam> | ok, so a new one gets returned every time you access it? |
| 08:36 | <Hixie> | yeah |
| 08:36 | <heycam> | ok you'll need to say that i think |
| 08:36 | <gsnedders> | Lachy: Just a bit of knife play :P |
| 08:37 | <Hixie> | heycam: can you add a comment in the comment box to that effect and hit the button? it'll file a bug for you |
| 08:37 | <heycam> | sure |
| 08:37 | Philip` | hopes gsnedders used a stab-proof knife |
| 08:39 | <jgraham> | He just used one of those plasic toy knives where the blade goes in |
| 08:40 | <heycam> | Hixie, i'm still not sure of the usefulness of having separate date/time/timezone attributes |
| 08:40 | <heycam> | it might be better to have one Date and then booleans to state whether certain parts were present |
| 08:40 | <Lachy> | Philip`, are they anything like those useless plastic, cut-proof scissors often given to children so they can't cut themselves, or paper? |
| 08:41 | <Hixie> | heycam: it seems that whatever you do, you're going to have to end up creating these Date objects for yourself, typically |
| 08:41 | <Hixie> | heycam: having just these dates seems as useful or more than one date and booleans |
| 08:42 | <Philip`> | Lachy: They're like http://www.foxnews.com/story/0,2933,526590,00.html |
| 08:44 | <Lachy> | the claim about them being inneffective as a weapon seems a little inaccurate |
| 08:44 | <heycam> | Hixie, I suppose I'd like to see use cases to convince me. maybe i'll send mail about it. |
| 08:44 | <Lachy> | they may not be effective for stabbing due to the blunt end, but they look to be perfectly effective for slitting someone's throat |
| 08:45 | <heycam> | btw are <time>s meant to represent an instance in time or an instance in time and an associated time zone? |
| 08:45 | <othermaciej> | they seem unlikely to reduce the risk of injuries |
| 08:45 | <othermaciej> | most accidental knife injuries while cooking are from the edge, not the point |
| 08:46 | <Hixie> | heycam: heycam: a date, a time, or an instance in time with time zone |
| 08:46 | <Philip`> | othermaciej: It seems it's designed to reduce injuries when e.g. a burglar breaks into your house and you disturb him and he grabs the nearest knife and stabs you, not when cooking |
| 08:46 | <heycam> | Hixie, ok. currently the spec says only "The time element represents a precise date and/or a time in the proleptic Gregorian calendar." |
| 08:47 | <othermaciej> | Philip`: s/injuries/accidental injuries/ |
| 08:47 | <othermaciej> | it might prevent deliberate stabbings, but it would also prevent self-defense with a knife |
| 08:47 | <Philip`> | (Presumably it's no good for premeditated attacks, because you've have to be pretty stupid to intentionally take a stab-proof knife to stab someone with) |
| 08:47 | <othermaciej> | then again, the UK doesn't believe in self-defense any more |
| 08:48 | <Hixie> | bbiab |
| 08:48 | <Lachy> | it may not be effecitve for stabbing, but slicing attacks are still as effective as before |
| 08:49 | <Lachy> | unless they make it blunt on the edge as well |
| 08:49 | <Philip`> | Were slicing attacks still effective before? |
| 08:49 | <Philip`> | I imagine they're much harder to do |
| 08:49 | <Philip`> | and much harder to cause fatal injuries |
| 08:49 | <othermaciej> | if you are any good at knife fighting you can mess up an attacker really bad, probably fatally |
| 08:49 | <Lachy> | just grab someone from behind, hold the knife to their throat and slice |
| 08:49 | <othermaciej> | or if you are strong enough to overpower someone, you can cut their throat or the like |
| 08:50 | Lachy | notes that discussing murdering techniques is a new low for this channel :-) |
| 08:50 | <othermaciej> | just slashing at the arms of someone coming for you, they will quickly reach a point where they are likely to bleed to death |
| 08:50 | <othermaciej> | (forearms) |
| 08:52 | <Philip`> | Hmm, seems more difficult and situational than just shoving the knife into someone's chest and then running off before anyone notices you |
| 08:53 | <Philip`> | (Mostly this is in the context of e.g. http://www.telegraph.co.uk/news/newstopics/politics/2078201/Gordon-Brown-urges-tougher-punishments-for-teenage-knife-crime.html and not trained knife fighters) |
| 09:28 | <jgraham> | I guess the main use case for the stab-proof knife is "violent hasband flies into a rage and attacks wife" |
| 09:28 | <jgraham> | *husband |
| 09:29 | <gsnedders|work> | Are you calling myself and Hixie husband and wife? :\ |
| 09:30 | <hsivonen> | I'd like to have stab-proof knives just to mitigate the consequences of dropping a knife |
| 09:30 | jgraham | shan't enquire which recesses of gsnedders psyche caused him to infer that |
| 09:30 | <hsivonen> | I wonder if the stab-proof knives will be delayed by 20 due to a patent |
| 09:31 | <hsivonen> | *20 years |
| 09:32 | <gsnedders|work> | jgraham: Well, I seemingly often attack Hixie in a rage… |
| 09:32 | gsnedders|work | thinks something is a bit backwards though, seeming he's the one wearing a girls T-shirt |
| 09:33 | <GPHemsley> | well, this is an interesting conversation to walk into... |
| 09:35 | <hsivonen> | it's inappropriate for use cases to assign gender to attacker and victim |
| 09:35 | <gsnedders|work> | GPHemsley: See /topic :) |
| 09:36 | <GPHemsley> | you people really should have a logic detector at the entrance |
| 09:36 | <GPHemsley> | you can't expect me to remember to voluntarily relinquish it every time I come in here |
| 09:36 | hsivonen | also thinks non-violent discourse without stabbing would be good on #whatwg |
| 09:38 | <hsivonen> | aargh. I just realized that if nodes have been moved from a document to another during the parse, the HTML5 parser in Gecko notifies the subsequent child insertion on the wrong document |
| 09:38 | <hsivonen> | fixing that in a performant way seems like a can of worms |
| 09:40 | <hsivonen> | I guess I need to ship a pointer to the parser's doc to each tree operation |
| 09:40 | <hsivonen> | sigh. |
| 09:45 | <hsivonen> | hey. Theora support has migrated from Chrome dev channel to beta channel |
| 09:45 | <hsivonen> | nice |
| 10:26 | <hsivonen> | I wonder how hard it would be to generate static status markers from the WHATWG dynamic status marker data |
| 10:27 | <jgraham> | hsivonen: Not hard but possibly not worthwhile either. |
| 10:28 | <jgraham> | I can't imagine that it would make people happy |
| 10:29 | <othermaciej> | status markers are a bit of a sideshow |
| 10:29 | <othermaciej> | issues need to actually be resolved in some final way - it's only the total lack of closure on anything in the HTML WG that makes people play games with publishing WD and adding status markers and such |
| 10:31 | <jgraham> | Indeed. I would rather we spent time resolving issues than shuffling little red boxes around |
| 10:31 | <hsivonen> | jgraham: it seems to me that autogenerating the markers into the W3C snapshots would address the issue Manu's draft is said to address |
| 10:31 | <hsivonen> | I agree that actully resolving issues is better |
| 10:32 | <hsivonen> | hmm. looks like Wikipedia now tells a bogus story about video codec debate as far as dates of events go |
| 11:43 | <Philip`> | http://www.exalead.com/search/web/results/?q=html5 - wow, a site that actually uses SVG for real |
| 11:44 | <Philip`> | (in the Languages/Countries pie charts) |
| 11:45 | <pablof> | Philip`: http://www.opera.com/company/jobs/ ;-) |
| 11:49 | <Philip`> | Oh, looks like they didn't write the SVG themselves, they just used http://raphaeljs.com/ |
| 12:18 | <StefanShipor> | hey people! could you take a look at http://bearditch.com/stuff/debate.html and give your 2cents about the markup. Would you structure it differently? It's for a general tabbed content section of a site. If you have the time or mood ofc. |
| 12:24 | <hsivonen> | http://twitter.com/mattur |
| 12:26 | <paulgendek> | hsivonen: followed... |
| 12:28 | <paulgendek> | StefanShipor: looks pretty good! |
| 12:30 | <jgraham> | paulgendek, StefanShipor: You may find http://gsnedders.html5.org/outliner/ useful in assessing whether you are using sectioning elements in the right way |
| 12:31 | <paulgendek> | cool, thanks! |
| 12:32 | <jgraham> | paulgendek: In your case I think you have too many sibling <section>s |
| 12:32 | <StefanShipor> | jgraham: but why do the untitled sections appear? http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fbearditch.com%2Fstuff%2Fdebate.html |
| 12:32 | <StefanShipor> | I waas expecting only one since it doesn't have a heading |
| 12:34 | <jgraham> | StefanShipor: You have a <body> with no heading, a <nav> with no heading at the top and two <nav>s with no heading further down |
| 12:34 | <paulgendek> | <nav> should have <heading> within? |
| 12:34 | <jgraham> | (FWIW I think that the approach to sections with no heading in the spec needs to change) |
| 12:35 | <jgraham> | paulgendek: Theoretically, yes |
| 12:36 | <paulgendek> | i stared at my dom for a few hours and couldn't think of any other ways of ordering elements, etc. it seems like the most practical for a real world solution, as a base theme, etc |
| 12:36 | <jgraham> | paulgendek: e.g. you miught say <nav><h1>Blogroll</h1></nav> |
| 12:37 | <jgraham> | paulgendek: In yoour specific case, I think you want to structure the page so that the main page header is outside of the <section>s |
| 12:37 | <paulgendek> | that doesn't make sense, because from what i read, you would put the h-tags in the <header>, followed by the <nav> |
| 12:38 | <jgraham> | Like <body><header><h1>My blog</h1></header><nav></nav><article><h1>My post</h1></article> |
| 12:38 | <paulgendek> | i think body's header should be reserved for accessibility links, in a magazine/blog layout |
| 12:39 | <StefanShipor> | there will be lots of navs on sites for navigation through posts and such. I hope they don't leave the heading inside nav mandatory |
| 12:39 | <jgraham> | I don't know what you mean by accessibility links really (do you mean "skip to content" type links?) but that seems like a strange belief |
| 12:39 | <StefanShipor> | cause if you fave "older" and "newer" it's already pretty self-explanatory |
| 12:40 | <StefanShipor> | have* |
| 12:40 | <paulgendek> | it's nowhere near 2022, we still need to be practical here... |
| 12:40 | <paulgendek> | in 2009/2010, i still need skip to content links |
| 12:41 | <paulgendek> | may be a want, idk |
| 12:41 | <jgraham> | paulgendek: Maybe, I'm not sure what the state of the art in AT is in this regard. But I see no readon why that precludes having a header for the body |
| 12:42 | <paulgendek> | because in modern web design, where we have containers, centered, with borders, padding, maybe even nested with special corners, etc |
| 12:42 | <paulgendek> | the body header should be reserved for top-most content |
| 12:43 | <jgraham> | What is the title of your blog if not topmost content? |
| 12:43 | <paulgendek> | like an admin bar that is position absolute, or leaderboard ads that are outside of the centered/bordered container, or the accessibility links that are hidden for screen |
| 12:45 | <jgraham> | In any case, at the very least the articles on the page should be nested below the main page title otherwise your markup has the wrong structure (which will show up as an incorrect outline) |
| 12:45 | <paulgendek> | we can agree that title of the blog should be an h1, which will take its order correctly just by being an h1... let it be in section#header's header with the site slogan, logo, and primary nav... better for designing real website header sections |
| 12:46 | <jgraham> | paulgendek: That's not how headers work in HTML5 |
| 12:46 | <gsnedders|work> | paulgendek: Why should one section's header apply to one of its siblings? |
| 12:46 | <jgraham> | Any header can be a <h1> as long as you get the structual elements right |
| 12:47 | <paulgendek> | or for the sake of having a clean outline, and the elements where they need to be in the dom for design, should we then hide the h1 in body header, and use an h2 for the logo in the actual header section of the design? |
| 12:47 | <gsnedders|work> | paulgendek: Why is it a section, even? |
| 12:47 | <paulgendek> | because it's a page layout section |
| 12:47 | <jgraham> | Note that <header> is not a sectioning element |
| 12:47 | <paulgendek> | "header, content, sidebar, footer" |
| 12:47 | <hsivonen> | about.validator.nu, etc. going down now |
| 12:48 | <paulgendek> | exactly, section is sectioning, which is why i apply the id to sections, for building the page structure |
| 12:48 | <gsnedders|work> | paulgendek: "section" is _not_ a page layout section. It is a semantic section. |
| 12:48 | <paulgendek> | gsnedders|work: the spec says that it's flow AND structural |
| 12:48 | <jgraham> | Doing <body><section><header><h1>My blog instead of <body><header><h1>My blog is both unnecessary and wrong |
| 12:49 | <jgraham> | Unless you further nest all other content in that outer section |
| 12:49 | <paulgendek> | headers are only for sections and articles |
| 12:49 | <gsnedders|work> | the body is a section. |
| 12:49 | <paulgendek> | body's header is reserved for top content imo |
| 12:50 | <paulgendek> | at least, in blog layout |
| 12:50 | <paulgendek> | maybe for a single page site or basic app |
| 12:50 | <paulgendek> | sure |
| 12:50 | <jgraham> | paulgendek: I don't see how to reach your opinion from the spec or from logic |
| 12:50 | <paulgendek> | but not for magazine/blog layout that can be fairly complex |
| 12:50 | <annevk42> | http://tools.ietf.org/html/bcp19#section-2.4 how can HTML be a character set? |
| 12:50 | <jgraham> | But I have toi go now... |
| 12:50 | <paulgendek> | jgraham: i'll continue to work on it, and we'll see how it goes, thanks |
| 12:52 | <gsnedders|work> | paulgendek: If you absolutely don't want the body's header to be that, which I think is what you do, then don't you want the whole page in that section? |
| 12:53 | <paulgendek> | i see it as the body has a header and a footer, and sections... and all of the structural sections are grouped in a div#container to remain ambiguous... body's header for top most meta-ish content, body footer for debug/version info, javascripts, etc |
| 12:54 | <paulgendek> | the #container can then constrain the width and be centered of all the structural sections of the layout |
| 12:54 | <gsnedders|work> | What is wrong with using header for the header? |
| 12:55 | <paulgendek> | i think there is confusion between <header> as the top part of a section, and #header which is the container for the structural header of a design |
| 12:56 | <paulgendek> | gsnedders|work: because any css done to the body header for a complex design's header section would nest a lot of selectors based off of "header", which would inherit down to all other headers, you would need to use body > header:first-child, which is much more to type, and not really much more semantic, body is more like a canvas for sections imo |
| 12:57 | <gsnedders|work> | paulgendek: Per the spec, body is a section. |
| 12:57 | <paulgendek> | i'm a front-end developer and i bring this up from tons of real-world application in common practice |
| 12:57 | <gsnedders|work> | paulgendek: And yes, you do end up with complex selectors in CSS doing almost anything |
| 12:58 | <annevk42> | hmm, all the charset registry lists are offline? |
| 12:58 | <paulgendek> | it's much easier for css and javascript to target #header than body > header:first-child |
| 12:58 | <annevk42> | btw, if I'm right and we cannot use the Unicode mapping algorithm for charsets we prolly need to register more aliases |
| 12:58 | <gsnedders|work> | then give the body > header:first-child an id of header |
| 12:58 | <gsnedders|work> | annevk42: http://www.iana.org/assignments/character-sets wfm |
| 12:58 | <paulgendek> | but then you'll have <header id="header"> which is then pointless |
| 12:59 | <paulgendek> | might as well go back to it being a div |
| 12:59 | <paulgendek> | at least it's 3 less chars on open/close |
| 12:59 | <gsnedders|work> | paulgendek: @id has no semantic value anyway, id="foobar" is just as meaningful. It's just a way to select the element. |
| 12:59 | <annevk42> | gsnedders|work, that's not a mailing list |
| 12:59 | <paulgendek> | and the container with #header is a structural section of a design, not necessarily the header of body |
| 12:59 | <Philip`> | "12:52 < jgraham> [...] <body><header><h1>My blog is both unnecessary and wrong" - sounds like an accurate description of many blogs |
| 12:59 | <gsnedders|work> | annevk42: It is a charset registry list :D |
| 13:00 | <annevk42> | sure, but not the one I'm after |
| 13:00 | annevk42 | wants ietf-charsets⊙io archives |
| 13:00 | <gsnedders|work> | annevk42: I don't think I ever managed to subscribe to that when I tried |
| 13:01 | <annevk42> | it is supposed to be based here: http://mail.apps.ietf.org/ietf/charsets/threads.html |
| 13:01 | <gsnedders|work> | That's long gone |
| 13:01 | <annevk42> | doh |
| 13:01 | <annevk42> | where's Julian when you need him |
| 13:02 | <gsnedders|work> | Not on IRC? :) |
| 13:04 | <beowulf> | paulgendek: can't you select every header but the body header on the basis that they're all children of another element? |
| 13:05 | <Lachy_> | annevk42, http://lists.w3.org/Archives/Public/ietf-charsets/ |
| 13:05 | <gsnedders|work> | Lachy_: That's older and more dead :P |
| 13:05 | <Lachy_> | I noticed taht |
| 13:05 | <Lachy_> | *that |
| 13:05 | <gsnedders|work> | beowulf: Only with :not that really isn't well supported |
| 13:06 | <annevk42> | yeah, that's not the archive I was looking for |
| 13:06 | <annevk42> | I wonder if we should email iana⊙io |
| 13:06 | <beowulf> | header {foo:bar}; body * header {foo:none} # no? |
| 13:06 | <gsnedders|work> | I guess |
| 13:06 | <gsnedders|work> | beowulf: That would work, but you then have to override everything |
| 13:07 | <beowulf> | gsnedders|work: c'est la vie |
| 13:07 | <gsnedders|work> | beowulf: Only CSS 3 Selectors can be relied upon, body > header and *:not(body) > header |
| 13:07 | <gsnedders|work> | *Once |
| 13:08 | <Philip`> | If you want to style a specific element, why would you not simply use id? |
| 13:08 | <beowulf> | Philip`: iurro |
| 13:09 | <gsnedders|work> | Philip`: Because @id is _so_ yesterday, and XPointer is _so_ the future. |
| 13:09 | <paulgendek> | like i said, maybe in 2015 or whatever, but right now i have to cover all bases, which means older browsers and screen readers, and search crawlers |
| 13:09 | <beowulf> | i don't have bare headers in my documents, so it doesn't apply to me :) |
| 13:09 | <beowulf> | the top header is usually nested in a <div id=banner> or some such |
| 13:09 | <gsnedders|work> | paulgendek: Why doesn't @id work now? |
| 13:10 | <gsnedders|work> | paulgendek: If you want to get one specific element, it seems the most sensible way |
| 13:10 | <paulgendek> | header for body, section, article, aside, nav, sure... but that doesnt mean the same as the structural header of the design |
| 13:11 | <beowulf> | paulgendek: but that has nothing to do with css, surely? |
| 13:11 | <gsnedders|work> | paulgendek: How does that effect selecting elements? |
| 13:11 | <paulgendek> | it affects css, with the > and :first-child selectors not being supported in ie6 |
| 13:11 | <gsnedders|work> | paulgendek: Well how would you select a specific p element for example? |
| 13:12 | <paulgendek> | nested selectors |
| 13:12 | <paulgendek> | section#primary article header p |
| 13:12 | <gsnedders|work> | And when you can't do that? |
| 13:12 | <gsnedders|work> | (Because of other siblings, or whatever) |
| 13:13 | <beowulf> | paulgendek: doesn't that get all the p's in a header? how do you get just one specific p? |
| 13:13 | <paulgendek> | if there is a reason to target that specific p versus the others, then the article would need an id to specify why it's different |
| 13:13 | <paulgendek> | section#primary article.different-view header p |
| 13:13 | <gsnedders|work> | How does that not apply to the case of getting one specific header? |
| 13:13 | <gsnedders|work> | What is so different between the two cases? |
| 13:13 | <paulgendek> | seems like going backwards though |
| 13:13 | <beowulf> | paulgendek: that would still get all the p's in the header, no? |
| 13:13 | <paulgendek> | <header id="header"> |
| 13:14 | <paulgendek> | just looks wrong |
| 13:14 | <gsnedders|work> | Is that more backwards than <p id=p>? |
| 13:14 | <beowulf> | <header id=banner> |
| 13:14 | <gsnedders|work> | <header id=pageheader>? |
| 13:14 | <beowulf> | <header id=typeline> |
| 13:14 | <beowulf> | <header id=hammer> |
| 13:14 | <paulgendek> | beowulf: ok, header#banner, sure, but that still is not the header of a layout where you would place user meta, logo, site name/slogan, primary menu, search, etc |
| 13:15 | <gsnedders|work> | Well what header is it? |
| 13:15 | <gsnedders|work> | I'm sure you can come up with a sensible id for it., |
| 13:15 | <paulgendek> | the body's header, which i said i'd prefer to reserve for accessibility links, banners, admin bars, etc |
| 13:15 | <beowulf> | paulgendek: when i do html like that i create a div called banner, and place header in it with all that other stuff as siblings |
| 13:15 | <beowulf> | div with id banner |
| 13:15 | <paulgendek> | the "header" that contains a design's header elements are a section, imo |
| 13:16 | <beowulf> | selecting the header is then simply #banner header |
| 13:16 | <paulgendek> | why a div? it's structural |
| 13:16 | <paulgendek> | div/span seems to be block/inline containers for design |
| 13:17 | <beowulf> | is that not what we're talking about? |
| 13:18 | <beowulf> | perhaps i'm being stupid |
| 13:19 | gsnedders|work | thinks that trying to describe what design you're talking about in words is never going to be as effective as showing us it graphically |
| 13:20 | <paulgendek> | i have to run to work |
| 13:20 | <paulgendek> | but here's the design in question |
| 13:20 | <paulgendek> | http://paulgendek.com/html5 |
| 13:21 | <Philip`> | We could avoid a lot of debate if the new elements were named <element0>, <element1>, etc, instead of <section>, <header>, etc, because that would avoid the problem of people having different intepretations of what the names mean |
| 13:21 | <paulgendek> | well i don't agree that <header> is the same a section#header |
| 13:21 | <paulgendek> | but we will continue this some other time ;) |
| 13:21 | <gsnedders|work> | It isn't. |
| 13:22 | <Philip`> | Ooh, there's the "WAHTWG" image again |
| 13:22 | <Dashiva> | Philip`: That would be too easy to confuse. How about naming them after animals instead? |
| 13:22 | Philip` | wonders where it originally came from |
| 13:23 | <Philip`> | Dashiva: Hmm, that could work |
| 13:24 | <Philip`> | Dashiva: Then we could add easy-to-remember conventions to distinguish different classes of elements, e.g. inline elements can be named after insects while block elements are named after mammals, so you never have to wonder "hmm, is <video> inline or block?" because it'll be obvious from the name |
| 13:29 | <jgraham> | hsivonen: Do yo have a bug on file about adding document outline functionality to validator.nu? |
| 13:31 | <beowulf> | paulgendek: http://pastie.org/private/9iv6v5eikq3ahbccblhxig # that's how I'd go about it, though I could be wrong |
| 13:31 | <hsivonen> | jgraham: I think I do, but the bugzilla machine is undergoing a dist upgrade |
| 13:33 | <jgraham> | hsivonen: OK |
| 13:33 | <hsivonen> | hrm. interpid seems to map .ogg to audio/ogg rather than application/ogg |
| 13:33 | <beowulf> | (there is no need for that class on the nav, obv) |
| 13:34 | <jgraham> | beowulf: What's the point of <div class=page>? |
| 13:34 | <beowulf> | jgraham: you need a wrapper for the 'page' in the design |
| 13:34 | <jgraham> | Oh OK |
| 13:35 | <beowulf> | a div of a certain width that sits margin auto left and right in the middle of the page |
| 13:35 | <jgraham> | I assume just styling <body> doesn't work for some reason that isn't clear in your fragment |
| 13:35 | <beowulf> | jgraham: correct |
| 13:36 | <beowulf> | jgraham: i'd have to try hard to remember why though :) |
| 13:42 | <jgraham> | "OSError: [Errno 26] Text file busy" - WTF? |
| 13:42 | <jgraham> | What was my file doing? |
| 13:42 | <gsnedders|work> | Oh, yeah, sorry, I'll stop looking at that. |
| 16:05 | beowulf | starts editing a spec with warnings on the warnings |
| 16:06 | <Philip`> | "Warning: This warning is controversial"? |
| 16:06 | <Philip`> | Add that into each of the warnings, and then everyone should be happy |
| 16:07 | <Dashiva> | Warning: This warning may be self-referential |
| 16:07 | <beowulf> | I just want one that says "Danger Will Robinson!" or something |
| 16:44 | <Dashiva> | I see the poll is open. A comment about vote whipping is trying to find its way here. |
| 16:57 | <d8uv> | <article pubdate="2009-08-19">[stuff]</article> is invalid. @pubdate can only work for full time AND date strings. This is stupid as hell. |
| 17:04 | <Lachy> | d8uv, not to worry, the pubdate attribute should be dropped anyway |
| 17:04 | <sbp> | Lachy: should be as in it is your opinion that it ought to be dropped? |
| 17:04 | <sbp> | Lachy: or should be as in it should soon actually be dropped as this is planned? |
| 17:05 | <d8uv> | I kinda like the pubdate attribute, honestly. It'd be better if it were more like atom:updated |
| 17:05 | <Lachy> | should be as soon as Hixie deals with my feedback about it and realises how much of a stupid idea it was to add it |
| 17:05 | <Lachy> | use the <time> element instead |
| 17:05 | <Lachy> | visible metadata is always better |
| 17:05 | <sbp> | so the former... :-) |
| 17:05 | <d8uv> | That's a damn good point |
| 17:05 | <gsnedders|work> | Lachy: The time element still requires datetime, so you don't avoid the issue. |
| 17:06 | <Lachy> | time doesn't require a full date AND time. It allows just dates or just times |
| 17:07 | <Lachy> | "The datetime attribute, if present, must contain a valid date or time string that identifies the date or time being specified." |
| 17:07 | <sbp> | Lachy: where ought the <time> element be used to *explicitly* associate it with the <article>? |
| 17:07 | <d8uv> | Yeah. What I'm working on is HTML5 -> Atom, sans micro* |
| 17:07 | <sbp> | otherwise you might just be mentioning random times in your article content |
| 17:08 | <Lachy> | <article><h1>Heading</h1><p>By Author, <time>2009-08-11</time></p> ...</article> |
| 17:08 | <d8uv> | And time is too floofy semantically to be of terrible use |
| 17:08 | <sbp> | how does that explicitly associate it? |
| 17:08 | <Lachy> | you may also wish to throw in a <header> element there too |
| 17:08 | <sbp> | that would require natural language parsing |
| 17:08 | <Lachy> | it doesn't |
| 17:08 | <Lachy> | what's your use case for requiring explicit association? |
| 17:08 | <sbp> | so, it's impossible to explicitly associate it? |
| 17:09 | <sbp> | d8uv's HTML5 -> Atom thing |
| 17:09 | <Lachy> | currently, yes, but there were ideas floated yesterday about how to achieve that |
| 17:09 | <sbp> | hmm. what kind of options were mooted? |
| 17:09 | <sbp> | got a reference? |
| 17:09 | <Lachy> | does the hAtom microformat solve your use case? |
| 17:09 | <Lachy> | check the IRC logs for yesterday |
| 17:10 | <d8uv> | Use case being how to best semantically do article headers/footers, using explicit data |
| 17:10 | <d8uv> | And yeah, I breathe hAtom, but... with hAtom, it's kind of an all-or-nothing thing |
| 17:10 | <Lachy> | d8uv, that's not a use case. Why do you need to "semantically do article headers/footers, using explicit data" |
| 17:11 | <sbp> | hmm. time/@for=$id and time/@role='pubdate' |
| 17:11 | <Lachy> | sbp, yeah, something like that |
| 17:11 | <sbp> | ref: http://krijnhoetmer.nl/irc-logs/whatwg/20090810#l-326 |
| 17:11 | <d8uv> | Pretty much to do hAtom, but natively. The use cases for hAtom are really really strong, and I think too strong to hide in Microformat land |
| 17:12 | <Lachy> | or there's various RDFa/Microdata/Microformts solutions as well |
| 17:12 | <d8uv> | Yeah, I'm working on all of the former, honestly |
| 17:13 | <d8uv> | I just hate overloading @class with stuff that would be better expressed explicitly using native semantics |
| 17:13 | jgraham | agress that bolt-on sematics are less nice than baked in ones |
| 17:14 | <tantekc_> | d8uv - web designers have been using the class attribute to "subclass" elements for nearly a decade now. so it's a solution that's both works and has been widely adopted in the wild |
| 17:14 | <tantekc_> | hence why microformats took advantage of that existing design pattern |
| 17:14 | <sbp> | Lachy: does this mean you'd like ins/@datetime removed too? |
| 17:15 | <sbp> | (and del/@datetime) |
| 17:15 | <tantekc_> | jgraham - indeed, microformats specifically instructs authors to make use of native language semantics *before* using microformats. |
| 17:16 | <Lachy> | sbp, those are questionable. But given their nature, they really can't use visible metadata alternatives. It's more a question of whether or not they're acutally useful in practice |
| 17:16 | <tantekc_> | sbp ins/del with datetime attribute is purely backward compat IMHO. I wouldn't recommend authors actually use those tags since they encourage invisible metadata. |
| 17:16 | <Lachy> | I've never seen an application actually make use of the datetime attribute on ins and del elements |
| 17:17 | <tantekc_> | Lachy - every mediawiki diff page |
| 17:17 | jgraham | would happily remove <ins> and <del> |
| 17:17 | <Lachy> | tantekc_, oh, I stand corrected |
| 17:17 | <sbp> | well, I was thinking about <ins datetime="..."><article>...</></> for doing what d8uv asks |
| 17:17 | <tantekc_> | with green and red inserted/deleted sections |
| 17:17 | <tantekc_> | and *visible* date time information |
| 17:17 | <tantekc_> | in practice, real world examples of ins and del have visible datetimes or at least titles |
| 17:17 | <Lachy> | I didn't realise they actually used the datetime attributes |
| 17:17 | <d8uv> | Is there any block-level equivalent to @datetime? |
| 17:18 | <Lachy> | d8uv, I don't understand the question |
| 17:18 | <sbp> | shame that certain attributes can't be agglomerated together on mouseover. so for example, if you had <article title="ABC" pubdate="2008"> a mouseover on that could display "ABC / Published: 2008" or something |
| 17:19 | <sbp> | that would solve the visible metadata problem. it'd be visible! |
| 17:19 | <Lachy> | tantekc_, are there any client side applications that make use of the datetime attributes on ins and del elements though? |
| 17:19 | <d8uv> | @datetime is used on time, ins, and del. To say that X happened on D date. I'd love to see something like that, but for section content |
| 17:19 | <tantekc_> | Lachy - not that I know of, but I haven't particularly searched, so I wouldn't claim that there aren't any. |
| 17:19 | <Lachy> | sbp, it'd also be incredibly annoying |
| 17:20 | <sbp> | well, that's a subjective opinion |
| 17:20 | <sbp> | I'm not sure how to find out whether it really would be |
| 17:20 | <tantekc_> | sbp - indeed, even partial visibility (e.g. via title attribute) is better than invisibility. |
| 17:20 | <sbp> | apart from doing a wide poll |
| 17:20 | <Lachy> | sbp, just imagine hoving your mouse anywhere over an article and having a tooltip displayed constantly? |
| 17:21 | <sbp> | no, I mean only for certain attributes |
| 17:21 | <sbp> | so basically certain attributes could be treated as @title adjuncts |
| 17:21 | <d8uv> | That's what sbp does on his blog, actually |
| 17:21 | <Lachy> | sure, I get what you mean. I just don't think it's usually a good idea to give a tooltip to an entire article |
| 17:21 | <Lachy> | where is sbp's blog? |
| 17:22 | <sbp> | so article/@title is a bad idea too? |
| 17:22 | <sbp> | my blog is a bunch of cheats, I wouldn't take it seriously |
| 17:22 | <Lachy> | I generally wouldn't use it |
| 17:22 | <Lachy> | but there may be a few cases that it might be acceptble |
| 17:27 | <sbp> | thinking about it, the date information is only required in Atom |
| 17:27 | <sbp> | there is a motivation for it being secret. I might not want to display it |
| 17:27 | <sbp> | as a matter of fact, I don't like displaying dates in my articles |
| 17:27 | <sbp> | I don't find them important on a trashy weblog |
| 17:28 | <sbp> | but they are required by Atom |
| 17:28 | <annevk42> | display:none? |
| 17:28 | <d8uv> | BTW, Lachy? You rule. And have convinced me to drop article@pubdate, for the verdant fields of footer/time@datetime. If I want to make it more explicit, I'll use Microdata, possibly RDFa or microformats |
| 17:28 | <sbp> | so I wonder about @data-date |
| 17:28 | <sbp> | annevk42: sure, or that. but @data-* require no styling at least :-) |
| 17:28 | <tantekc_> | d8uv - feel free to hang out in #microformats and ask any questions about hAtom |
| 17:28 | <annevk42> | or pubdata then :) |
| 17:29 | <sbp> | annevk42: well, in the context of Lachy wanting @pubdate removed... |
| 17:29 | <sbp> | sure, if @pubdate stays then obviously that'd be the thing to use... |
| 17:29 | <Lachy> | sbp, dates are very useful for readers, as it gives some temporal context to an article. |
| 17:30 | <d8uv> | I love microformats, and hAtom has saved me thousands of hours of work, due to my unconventional workflow |
| 17:30 | <sbp> | Lachy: temporal context is not important for my articles |
| 17:30 | <Lachy> | sbp, it takes talent to be able to write articles of a timeless nature |
| 17:30 | <sbp> | no, the opposite |
| 17:30 | <Lachy> | I guess it depends what you write about |
| 17:30 | <sbp> | I mean I do not expect them even worth reading now |
| 17:30 | <Lachy> | LOL |
| 17:31 | <sbp> | so why date them? :-) |
| 17:31 | <d8uv> | sbp writes mainly about 80s hairstyles, so... you know. Dates aren't important, really |
| 17:31 | <Lachy> | sbp, can you give a link to your blog? |
| 17:31 | <sbp> | yeah. you're just going there for folicular action really |
| 17:31 | <sbp> | http://inamidst.com/whits/ |
| 17:31 | <gsnedders|work> | Well, personally, I just mindlessly vandalize my own blog, if you believe jgraham, at least. |
| 17:32 | <sbp> | note that I'm using HTML5, but only those elements and attributes which were already available in HTML 4.01. the source is just a few lines of python2, http://inamidst.com/whits/code/iris/feed.py |
| 17:34 | <Lachy> | gsnedders|work, that's true. you're site is unique case in which it's administrator is also considered an out of control vandal |
| 17:34 | <d8uv> | gsnedders works with Hixie? |
| 17:35 | <Lachy> | d8uv, on HTML5, yes, like the rest of us. But otherwise no |
| 17:35 | <gsnedders|work> | I mean, it's hardly as if I stabbed him earlier. |
| 17:35 | <gsnedders|work> | With one of those toy plastic knives, though, so no harm done. |
| 17:35 | <Lachy> | LOL |
| 17:36 | <jgraham> | So, do I point out that removing @summary never put us in conflict with another spec or not? |
| 17:36 | <jgraham> | I have written the email but I am scared of a new thread being generated |
| 17:37 | <sbp> | point out to whom? |
| 17:37 | <sbp> | have WAI PF said much more about this issue? |
| 17:37 | <annevk42> | jgraham, no |
| 17:37 | <sbp> | last time I went looking, just a few days ago, it seemed they were very quiet |
| 17:38 | <annevk42> | jgraham, there's no real benefit to saying "you were wrong" imo |
| 17:39 | <jgraham> | annevk42: You might be right. But the point is really that where HTML 5 is actually in conflict with other specs it is generally because of irreconcilable technical differences between those specs and required browser behaviour |
| 17:40 | <jgraham> | Manu seems to want to paint it as "WHATWG are selfish and don't care about anyone else's ideas" |
| 17:40 | <Lachy> | jgraham, that's been pointed out before |
| 17:40 | <jgraham> | Lachy: Which part? |
| 17:41 | <Lachy> | the part about removing @summary not actually conflicting with another spec |
| 17:41 | <Lachy> | in that it only contradicts a non-normative guidline in a NOTE |
| 17:41 | <jgraham> | Lachy: Indeed. But it is still being presented as if it were an actual spec conflict |
| 17:42 | <Lachy> | I know. But there doesn't appear to be much that can be done to make them acknowledge that fact |
| 17:42 | <annevk42> | jgraham, we've not always approached every group when there was a problem |
| 17:42 | <annevk42> | jgraham, e.g. CharMod was after the fact, I think |
| 17:42 | <annevk42> | jgraham, for URLs we did try, but were initially rejected |
| 17:43 | <jgraham> | annevk42: Yeah, but we had a meeting with the i18n people and explained the requirements and everything was more or less OK |
| 17:43 | <sbp> | funny thing is that WAI PF aren't even chartered |
| 17:43 | <Lachy> | what? |
| 17:43 | <sbp> | their charter expired in 30th June 2009 |
| 17:43 | <sbp> | *on |
| 17:43 | <jgraham> | So it wasn't like we were unwilling to work with others |
| 17:43 | <Lachy> | didn't it get renewed? |
| 17:43 | <sbp> | not according to the charter, nope |
| 17:44 | <gsnedders|work> | I guess it's in the process of being renewed. |
| 17:44 | <sbp> | if it did, the charter hasn't been updated to reflect that |
| 17:44 | <gsnedders|work> | CSS WG was unchartered for a time |
| 17:44 | <sbp> | probably. they keep giving it little extensions, which is weird |
| 17:44 | <sbp> | I don't know why they don't just heap another couple of years on it |
| 17:44 | <sbp> | probably internal stuff going on |
| 17:44 | <Lachy> | It would make much more sense if they were just given a perpetual charter with the ability to revise it when needed |
| 17:44 | <annevk42> | jgraham, maybe you should ask Manu first for a list of where he fails we have not taken our input to other groups |
| 17:45 | <sbp> | yeah, that'd be fine |
| 17:45 | <annevk42> | jgraham, maybe his concern is that we put anything in the draft at all without first solving the issue |
| 17:46 | <jgraham> | annevk42: Maybe. Which might be a reasonable position (dunno how it would work in practice) but it's not really what he said |
| 17:46 | <sbp> | also I notice Janina Sajka signs herself PFWG chair |
| 17:46 | <sbp> | whereas the charter says Al Gilman is still chair |
| 17:46 | <gsnedders|work> | Charters often aren't updated for chair changes, FWIW |
| 17:46 | <sbp> | ah |
| 17:47 | <sbp> | ah yes, the homepage is accurate |
| 17:47 | <annevk42> | jgraham, since this borders on having a process discussion better safe than sorry applies :) |
| 17:48 | <annevk42> | well, maybe not, but this discussion has been going back and forth a long time already, so figuring out what everyone wants first seems better |
| 17:49 | <sbp> | better Spiderman than sorry... |
| 17:50 | jgraham | also notes that if the intent of the warnings draft is to make the draft indicate the stability of various sections of HTML5 then it is woefully inadequate and the process that people have been talking about using to get issues is not going to help |
| 17:50 | <jgraham> | hsivonen's suggestion of porting the WHATWG annotaions would work better |
| 17:52 | <sbp> | I'm off. thanks for your help, Lachy et al. |
| 17:52 | <Philip`> | Is anyone intending/planning to actually port the annotations? |
| 17:55 | <jgraham> | Philip`: I have too many other things to do to add more things to the pile at the moment |
| 18:00 | <Lachy> | Philip`, port them to where? |
| 18:00 | <Philip`> | Lachy: To the W3C version |
| 18:00 | <Philip`> | (without scripting) |
| 19:00 | <Philip`> | http://www.w3.org/mid/PM-GA.20090811195755.954F1.1.1D⊙sc |
| 19:00 | <Dashiva> | Philip`: Now watch that email get buried |
| 19:01 | <annevk42> | jgraham, maybe you should call it out |
| 19:01 | <annevk42> | jgraham, Manu is not really representing things factual |
| 19:02 | <annevk42> | also, if it's just about other specifications, why does microdata need to be called out? |
| 19:05 | <Dashiva> | Philip`: Now watch that email get buried |
| 19:23 | <Philip`> | "... the idea that it is not dangerous to read any part of the standard" - hmm, it can often be dangerous to one's composure and/or sanity |
| 19:26 | <Dashiva> | So any section without a warning is set in stone? |
| 19:27 | <Philip`> | I think we should carve the HTML5 spec into a mountain, so that it won't be lost to future archeologists |
| 20:16 | <Lachy> | oh no, Manu's draft has pulled ahead in the polls :-( |
| 20:17 | <Lachy> | oh well, I suppose, even if it is published, at least it will become irrelevant as soon as its published |
| 20:19 | <Hixie> | hsivonen: there's already a version of the contents list that has static issue markers, iirc |
| 20:19 | <Hixie> | hsivonen: ask mikesmith |
| 20:24 | <tantekc__> | Lachy - it appears that the form presents the *option* to cc answers to public-html, but by default no-one is cc'd. |
| 20:26 | <tantekc> | tabulated results: http://www.w3.org/2002/09/wbs/40318/wd08/results |
| 20:26 | <Lachy> | tantekc, I know. That's what I've been looking at |
| 21:21 | <othermaciej> | Lachy: I see more "yes" votes for the vanilla draft so far |
| 21:23 | <Dashiva> | This doesn't actually specifiy votes for or against :) "I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft." |
| 21:26 | <anne-w> | test |
| 21:26 | <othermaciej> | lol |
| 21:27 | <anne-w> | guess it works... what happened to the logs? |
| 21:27 | <gsnedders> | anne-w: fail |
| 21:27 | <Dashiva> | Too bad Ericsson isn't sending in 39 people to vote here |
| 21:27 | <Lachy> | othermaciej, it changed in the short time since I said Manu's was in the lead |
| 21:42 | <othermaciej> | Lachy: seems like it will be close, either way |
| 21:47 | <Lachy> | I updated my response to the poll linking to jgraham's comments http://lists.w3.org/Archives/Public/public-html/2009Aug/0447.html |
| 21:48 | <Lachy> | oops, wrong link |
| 21:48 | <Lachy> | http://lists.w3.org/Archives/Public/public-html/2009Aug/0563.html |
| 22:12 | <othermaciej> | how long is the poll going to be open? |
| 22:12 | <Lachy_> | "This questionnaire is open from 2009-08-10 to 2009-08-17." |
| 22:13 | <othermaciej> | fun, fun |
| 22:14 | <Dashiva> | I don't get this comment: "I just dislike having content inside attributes in general..." |
| 22:15 | <Dashiva> | It's for a 'yes' vote to Hixie's draft |
| 22:16 | <othermaciej> | maybe an elliptical comment about summary? |
| 22:37 | <othermaciej> | it looks like there are only 2 people who voted yes on both documents |
| 22:37 | <othermaciej> | if I am doing my math right |
| 22:37 | <Dashiva> | I wonder if they know about the poll flaw |
| 22:40 | <Hixie> | http://www.w3.org/2002/09/wbs/40318/wd08/results?view=compact is a more useful view, i think |
| 22:41 | Dashiva | shakes fist at Member-only |
| 22:41 | <othermaciej> | it looks like the WG really doesn't want to publish two competing documents |
| 22:41 | <Lachy_> | oh, much better |
| 22:42 | <othermaciej> | I'm not clear on how voting yes on both amounts to an abstain - is it just because it fails to express a preference, where voters may have a preference in the case we publish only one? |
| 22:44 | <Dashiva> | othermaciej: Yes |
| 22:44 | <Dashiva> | If you had voted for only one, the 'do both' would still have failed, but your preference would be better placed to be the one |
| 22:44 | <othermaciej> | I guess preferred / acceptable / unacceptable would have been better than yes / no voting |
| 22:56 | adactio | (n=adactio⊙rnbrc) has left #whatwg |
| 22:59 | <Hixie> | woah, the IANA said we shouldn't have ports for WebSocket, and should just reuse HTTP's ports |
| 22:59 | <othermaciej> | that's... surprising |
| 22:59 | <othermaciej> | but good |
| 23:01 | <Hixie> | they also said that if we used our own ports, we shouldn't have two, but should just use one and upgrade in-line |
| 23:01 | <Hixie> | not sure how they expect that to work with http... |
| 23:01 | <othermaciej> | there is such a thing as TLS upgrade |
| 23:01 | <Hixie> | sure, but nobody uses it because it's a security nightmare |
| 23:02 | <othermaciej> | I am not sure if it is actually deployed and usable in practice |
| 23:02 | <Hixie> | they also said that if we want to use a port than isn't HTTP, we should not use a system port |
| 23:03 | <othermaciej> | also surprising |
| 23:50 | <rubys2> | I miss krijnhoetmer.nl |
