| 00:39 | <mpilgrim> | it's weird how rubys can quote chapter and verse of the w3c process document, but can't be arsed to read the mailing list archives from a few months before he was installed as our Fearless Leader |
| 00:39 | <mpilgrim> | i guess Fearless Leaders don't need to avail themselves of history |
| 00:40 | <othermaciej> | to be fair, the W3C mailing list archive search is a pain to use |
| 00:40 | <othermaciej> | it took me a good 5 minutes to find that email |
| 00:47 | <mpilgrim> | i searched for this: alt "from: ian hickson" site:lists.w3.org/Archives/Public/public-html/ |
| 00:47 | <mpilgrim> | the message you linked is the 3rd result |
| 00:47 | <othermaciej> | ah, using Google would have been a better idea |
| 00:50 | <mpilgrim> | on an unrelated note, google's lawyers would really like employees not to use "Google" as a verb |
| 00:50 | <mpilgrim> | so now i say "search" and assume everyone uses Google |
| 02:32 | <othermaciej> | Hixie: are you at all interested in what the PFWG had to say (informally and tentatively) about your Last Call feedback on ARIA btw? I can't remember if I told you after the telecon |
| 02:32 | <othermaciej> | Hixie: or would you rather wait for their promised email on the topic? |
| 02:45 | <Hixie> | i need either a satisfactory edit to their spec, or a satisfactory reply that convinces me that no edit is needed, or an unsatisfactory reply i can reply to |
| 02:53 | <othermaciej> | I can tell you what reply is likely coming |
| 02:53 | <othermaciej> | I agree that such informal info is not enough to act on |
| 02:54 | <othermaciej> | let me just say it instead of asking whether I should: |
| 02:55 | <othermaciej> | 1) They already (tentatively) planned to make native element semantics "win" over ARIA semantics for everything but the role attribute; host languages could make conflicting states nonconforming, and in case of a conflict the native semantics win (so <input type="checkbox" checked aria-checked=false> will be presented as checked. |
| 02:55 | <othermaciej> | this is unpublished and not yet stated officially in a public forum |
| 02:56 | <othermaciej> | 2) They were not planning to do this with role, but after my examples of nonsensical role combinations, such as <input type="radionbutton" role="combobox">, they agreed to reconsider this. |
| 02:57 | <othermaciej> | And to give some form of feedback on this soon, possibly privately. |
| 02:57 | <othermaciej> | Whether they will follow up with an actual public post or actual spec edits, I cannot say. |
| 02:59 | <othermaciej> | they also said that if there is a limit on what elements are allowed to have what roles, they would want to review that |
| 03:01 | <Hixie> | k |
| 03:01 | <Hixie> | well |
| 03:01 | <Hixie> | until all that is something i can act on... |
| 03:03 | <othermaciej> | if they stated something about #1 on the record, and agreed as to #2 (that host languages can limit what roles apply to what elements), would you feel like that is something you can act on? |
| 03:05 | <Hixie> | what i need to be able to act on something is the normative text |
| 03:06 | <othermaciej> | which forms of normative text would be satisfacotry: (a) a snippet in an informal reply; (b) an Editor's Draft including new text; (c) a published Working Draft containing the new text? |
| 03:07 | <Hixie> | (b) |
| 03:08 | <othermaciej> | and is it ok if (b) is Member-only or otherwise not fully public? |
| 03:08 | <othermaciej> | (as long as you get to see it?) |
| 03:09 | <Hixie> | member-only is fine |
| 03:09 | <Hixie> | i mean, it's dumb, but it's just regular w3c-dumb, it doesn't prevent me from doing my work |
| 03:10 | <Hixie> | what i need to be able to reference aria from html5 is the text that i'm going to be referencing, so i can make sure it makes sense |
| 03:10 | <Hixie> | authoring and implementation conformance criteria |
| 03:11 | <Hixie> | and host language hooks |
| 03:11 | <Hixie> | same as with any other spec |
| 03:13 | <othermaciej> | I'm hoping that they give at least an informal reply soon |
| 03:13 | <othermaciej> | I believe Sam asked for one in "72 hours" on the conference call but I will be generous and assume that means business day hours |
| 03:14 | <othermaciej> | with that in hand, it's probably not hard to get it in an Editor's Draft in less than their projected 3-month timeline to reply at all |
| 03:15 | <mpilgrim> | given the history of interaction, i expect their response to be a poetic reading of the revised spec during next week's teleconference |
| 03:16 | <othermaciej> | I will give Sam credit for pressing them to give some kind of response |
| 03:16 | <othermaciej> | let's see if it actually works |
| 03:17 | <Hixie> | i'm really not in any rush |
| 03:17 | <Hixie> | i don't think it's a problem if aria isn't in HTML5 LC |
| 03:17 | <Hixie> | we can always add it in the next version, like half the other features in the spec |
| 03:18 | <Hixie> | though i will be amused if we go to LC without ARIA given that the whole reason for ARIA's existence is that ARIA is something that can be done quickly instead of requiring the whole of HTML to rev |
| 03:19 | <othermaciej> | this particular feature is somewhat important because it's actively being implemented by user agents and validators |
| 03:20 | <othermaciej> | if it has to be held up for substantive technical reasons, fine, but it would be a shame for it to be held up solely by procedural BS |
| 03:20 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#usage-summary |
| 03:21 | <JonathanNeal> | Hey all! |
| 03:22 | <JonathanNeal> | Anyone around? |
| 03:23 | <Hixie> | some people |
| 03:23 | <Hixie> | some are also triangular. |
| 03:24 | <JonathanNeal> | That's wonderful. |
| 03:24 | <mpilgrim> | the <kbd> example obviously needs to say "Keyboard error, no keyboard present. Press <kbd>F1</kbd> to continue" |
| 03:25 | <JonathanNeal> | I so just repeated that reply to Beth, Hixie, thanks. |
| 03:25 | <JonathanNeal> | That was excellent. |
| 03:26 | <Hixie> | mpilgrim: i prefer my more subtle references. :-) |
| 03:26 | <Hixie> | mpilgrim: (half the examples in the spec are subtle jokes.) |
| 03:26 | <mpilgrim> | "Bubbles followed us everywhere." |
| 03:26 | <Hixie> | (or references to things i happen to like, or that were relevant when i wrote the example) |
| 03:27 | <JonathanNeal> | I'm writing up some drafts on HTML5 usage, specifically moving my company's existing templates from XHTML1 to HTML5. |
| 03:27 | <Hixie> | mpilgrim: indeedmpdo you know who bubbles is? :-) |
| 03:27 | <mpilgrim> | i do |
| 03:27 | <Hixie> | s/mp/; / |
| 03:27 | <Hixie> | good good |
| 03:28 | <JonathanNeal> | http://pastebin.org/9576 |
| 03:28 | <mpilgrim> | i used the flickr api to reverse-engineer the original URL based on the filename in the <img src> |
| 03:28 | <JonathanNeal> | That's one of my suggestions so far, but I wanted to get feedback from the whatwg channel on it. |
| 03:28 | <Hixie> | mpilgrim: :-D |
| 03:29 | <Hixie> | JonathanNeal: seems reasonable, though it's probably a little early to be using <section> and company still |
| 03:29 | <mpilgrim> | yah, if you want to use the new semantic elements, you need to make accommodations for IE and older versions of Firefox |
| 03:30 | <JonathanNeal> | mpilgrim and hixie, we are aiming for ie6+, ff, safari, opera, chrome compatibility. We're using some CSS and JS to give some of the browsers support. |
| 03:31 | <JonathanNeal> | It's not anything remotely complicated, just the document.createElement function. |
| 03:31 | <mpilgrim> | do you know about modernizr? |
| 03:32 | <JonathanNeal> | We've already been using that for abbr tags, since we also aim for accessibility. I had a long discussion about whether or not adopting the HTML5 draft would be accessible, but he who knows about Section501 gave a positive review - actually most are excited about moving forward. |
| 03:33 | <JonathanNeal> | We don't use modernizr, but we've had support for browser and css-capability-based selectors for a while. |
| 03:34 | <JonathanNeal> | We actually have a serverside script that takes care of most of it, and it actually attaches the class to the html tag, which is okay to do in JS (not in static, I believe). |
| 03:35 | <mpilgrim> | i assume you mean section 508, but that's neither here nor there |
| 03:35 | <JonathanNeal> | mpilgrim, thank you. I am certainly not an expert. |
| 03:36 | <JonathanNeal> | Seriously, I am absolutely lucky to even get the attention I do. However, I'm a big HTML5 fan, even if it's not done. |
| 03:36 | <mpilgrim> | html 5 does a lot of good for accessibility |
| 03:37 | <mpilgrim> | it codifies a lot of recent work in the accessibility field |
| 03:37 | <JonathanNeal> | Awesome. |
| 03:37 | <mpilgrim> | and will (perhaps sooner, perhaps later) be integrating roles and states as well |
| 03:37 | <mpilgrim> | (a.k.a. ARIA) |
| 03:37 | <JonathanNeal> | Well that's why I'd love you guys to see my two drafts, did you see the first one i just posted on pastebin? |
| 03:37 | <mpilgrim> | i did |
| 03:37 | <mpilgrim> | html5 attempts to make @accesskey sane |
| 03:38 | <JonathanNeal> | Yea, someone was mentioning aria. |
| 03:38 | <mpilgrim> | and is the first standard to include the de facto "negative @tabindex" thing that's implemented in IE and Firefox |
| 03:38 | <JonathanNeal> | I have no idea how I got the thumbs up to look into how we can move to html5 but we are for sure going there, how much we actually take from the new elements and semantics is up to how much research we do. |
| 03:38 | <JonathanNeal> | So that's why I'm here. |
| 03:38 | <mpilgrim> | there's other stuff too |
| 03:38 | <JonathanNeal> | Normally I just write jQuery plugins. |
| 03:39 | <JonathanNeal> | Here is my other draft @ http://pastebin.org/9577 |
| 03:39 | <mpilgrim> | work on rich <canvas> accessibility is only just beginning (html 5 has basic support for including fallback content, but nothing for "accessifying" dynamic scripted graphics) |
| 03:41 | <mpilgrim> | if you're targeting current browsers and assistive technologies, you should include skip links before your navigation |
| 03:42 | <Hixie> | JonathanNeal: you can replace "<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />" with just <meta charset="utf-8"> |
| 03:42 | <mpilgrim> | since i think ATs don't yet support the <nav> element |
| 03:42 | <Hixie> | JonathanNeal: also, it looks like your h1/h2/h3 shouldn't be in an hgroup |
| 03:42 | <Hixie> | JonathanNeal: since the h1 is for the site and the h3 for the page, at least those two should be distinct |
| 03:42 | <JonathanNeal> | Hixie, I thought they should, could you tell me why you think they shouldn't? |
| 03:43 | <Hixie> | JonathanNeal: see http://www.whatwg.org/specs/web-apps/current-work/#distinguishing-site-wide-headings-from-page-headings |
| 03:43 | <Hixie> | other than that it looks good |
| 03:43 | <JonathanNeal> | Well, I want to be as perfectly implementing these technologies as possible. |
| 03:44 | <JonathanNeal> | So, are you suggesting that the h1 and h2 tags are okay, but the h3 tag should be distinct from the Company Title and Community Title? |
| 03:44 | <JonathanNeal> | eg, the h3 exists within a different <section> where it is the h1? |
| 03:45 | <mpilgrim> | AFAIK, http://www.webaim.org/techniques/skipnav/ is the best article on skip links |
| 03:45 | <JonathanNeal> | mpilgrim, are you referring that link to me? |
| 03:45 | <mpilgrim> | yes |
| 03:45 | <Hixie> | JonathanNeal: i'm not sure exactly what the community title is |
| 03:45 | <Hixie> | JonathanNeal: so it's hard to say exactly what should happen |
| 03:46 | <Hixie> | JonathanNeal: but the h1 and the h3 are titling different things, so they shouldn't be in a gorup |
| 03:46 | <JonathanNeal> | mpilgrim, that's great, I love that. We would need to use some kind of unique styling to hide those links from users without removoing them from screen-readers. |
| 03:46 | <mpilgrim> | in your second html 5 prototype, you had a <nav> section. i'm saying that even if you're using the <nav> element, you need to include a "skip navigation" link before it, because current ATs don't support the <nav> element yet. |
| 03:46 | <JonathanNeal> | Typically, like for the company logo on the h1 tag, we use font-size:0,text-indent: 99999em; overflow: hidden; or something where it's not hidden to screen-readers but stylistically invisible. |
| 03:46 | <mpilgrim> | the webaim article shows you how to hide them properly but make them appear for screenreader users *and* keyboard-only users |
| 03:47 | <JonathanNeal> | Well, we're using the nav section as the main site navigation. |
| 03:47 | <mpilgrim> | see http://www.webaim.org/techniques/skipnav/#focus |
| 03:47 | <JonathanNeal> | We would probably attach #skip to a class so it could be re-used. |
| 03:48 | <JonathanNeal> | That's great. |
| 03:48 | <mpilgrim> | yeah |
| 03:48 | <mpilgrim> | a class is fine |
| 03:48 | <JonathanNeal> | Hixie, are you then also saying that, if there was to be an h2, the h2 should be the company branding (you know, like the company slogan) if it's to be looped in with the h1 in the hgroup? |
| 03:49 | <mpilgrim> | i actually insert them dynamically before certain types of blocks (large chunks of code or ASCII art) |
| 03:49 | <mpilgrim> | http://hg.diveintopython3.org/hgweb.cgi/file/5a24abbc66a8/j/dip3.js#l151 |
| 03:50 | <mpilgrim> | ^-- dynamically creating skip links using jquery |
| 03:50 | <JonathanNeal> | Yay, jQuery. |
| 03:52 | <Hixie> | JonathanNeal: not sure i understand the premise of your question |
| 03:54 | <JonathanNeal> | For skip, http://pastebin.org/9578 |
| 03:55 | <JonathanNeal> | Hixie, I didn't want to be lazy and ask you how you would do it, so I was trying to understand how/when you think these tags should be used. |
| 03:55 | <JonathanNeal> | I asked a question badly though, it seems. |
| 03:55 | <JonathanNeal> | poorly, rather. |
| 03:55 | <Hixie> | JonathanNeal: my problem is i don't understand what the community title is |
| 03:56 | <Hixie> | JonathanNeal: do you have a site, a site subsection, and then a page? |
| 03:56 | <JonathanNeal> | Well, that gets complicated because our product is pretty big. |
| 03:56 | <Hixie> | JonathanNeal: if so, then you want an h1 for the site, an h2 for the subsection, and an h3 for the page, none in an hgroup |
| 03:56 | <Hixie> | JonathanNeal: since they would all be titling different things |
| 03:56 | <JonathanNeal> | http://www.liferay.com/ We're a portal. |
| 03:56 | <Hixie> | JonathanNeal: the way to think about it is this -- if you were to put every single page into the same HTML file |
| 03:57 | <Hixie> | JonathanNeal: would there be a single heading or multiple headings? |
| 03:57 | <Hixie> | JonathanNeal: the answer is presumably you'd have one site header, and then one subsection header per subsection, and one page header per "page" in each section |
| 03:57 | <JonathanNeal> | Hixie, I completely understand what you mean by if you were to put every single page into the same html file. At work, I describe multiple pages as paginated content. |
| 03:57 | <Hixie> | JonathanNeal: so, <hgroup> is basically saying "there's only one header here" |
| 03:58 | <JonathanNeal> | That's how we won keeping h1 as the company name and not the page title, because if every page was one page then that would be the global title of them all. |
| 03:58 | <Hixie> | right |
| 03:58 | <JonathanNeal> | I see, I see. So, truely, if we wanted to group an entire company, and then an entire community, and then a page, they would each exist within their own (sub) sections |
| 03:59 | <JonathanNeal> | I see what you mean. Thanks for the skip css, mpilgrim. |
| 04:00 | <JonathanNeal> | mpilgrim, if the AT doesn't know the nav element, will it still try to read the ul/li's inside of it? |
| 04:01 | <mpilgrim> | AFAIK, ATs just ignore unknown elements (like browsers do) |
| 04:01 | <mpilgrim> | so yes, it will still read the list of links |
| 04:01 | <mpilgrim> | as a list |
| 04:02 | <mpilgrim> | of links |
| 04:02 | <JonathanNeal> | Excellent, just like they have been in html4 and so forth. |
| 04:02 | <mpilgrim> | yeah |
| 04:02 | <mpilgrim> | i haven't done anything drastic, like testing that |
| 04:03 | <JonathanNeal> | I'm looking for the documentation that explains the usage of header tags within the hgroup as basically saying "there's only one header here". I agree and believe it, but part of enforcing these standards, I need the docs to back it up, but I'm looking. |
| 04:03 | <mpilgrim> | hence the "AFAIK" disclaimer |
| 04:03 | <JonathanNeal> | mpilgrim, yea, we have a guy who will test that and then we can work from there, but at first, I want the draft to be as html5 friendly as possible. |
| 04:03 | <mpilgrim> | yay, testing! |
| 04:04 | <mpilgrim> | please report back if there are any oddities with current ATs + new HTML 5 markup |
| 04:04 | <JonathanNeal> | That will be weeks from now. The first few weeks will be extensively reviewing and re-reviewing and testing the elements and new themes themselves. |
| 04:05 | <mpilgrim> | "weeks" is better than "never" |
| 04:05 | <JonathanNeal> | We love standards, so standardizing on something means really being pro about it. I think we've slipped on being pro about html standards, so that's perhaps why I'm getting such an opportunity. |
| 04:05 | <JonathanNeal> | mpilgrim, here here. |
| 04:06 | <JonathanNeal> | Hixie, other than the multiple headings, did you have any other objections or suggestions? |
| 04:06 | <JonathanNeal> | Actually, that remark is for anyone. |
| 04:06 | mpilgrim | wanders off |
| 04:08 | <JonathanNeal> | Well, in case there is, I'll check back in 15 - 20 minutes. Thanks already so much! |
| 04:38 | <JonathanNeal> | Hello again! |
| 04:41 | <JonathanNeal> | Where do you think accesible nav items like skip navigation should go, within the main navigation? |
| 04:55 | <JonathanNeal> | So this is right? http://img23.imageshack.us/img23/2844/hgroup.jpg |
| 05:07 | <JonathanNeal> | Or even http://img35.imageshack.us/img35/2844/hgroup.jpg |
| 05:10 | <JonathanNeal> | <section> tags effectively reset the meaning behind the numerical value of header tags, right? |
| 05:18 | <JonathanNeal> | Can article elements have sub-article elements within them? |
| 05:21 | <JonathanNeal> | Nvm, they can have nested children. |
| 05:37 | <mpilgrim> | "I wish we had had this information on Thursday." gee, if only there were some sort of asynchronous communication protocol we could have used instead of a live teleconference. |
| 05:43 | <JonathanNeal> | :-D |
| 06:35 | <Hixie> | is sam just going to not reply to me, do we think? |
| 06:36 | <othermaciej> | mpilgrim: I think Sam's emails sometimes make him seem more interested in smacking Hixie on the nose than in building consensus |
| 06:37 | <Hixie> | i'm confused (again) by sam's recent e-mails |
| 06:38 | <Hixie> | does he think wai is different than anyone else? |
| 06:38 | <othermaciej> | I think I pretty much said that I expect everyone (including you) to justify their position if there is a disagreement |
| 06:38 | <Hixie> | i've always been clear that i make edits based on people bringing forward issues and showing problems in the spec, arguing for changes based on reasoning and data. |
| 06:39 | <Hixie> | doesn't matter if it's WAI, the pope, larry page, an implementor, or the US House of Representatives |
| 06:39 | <Hixie> | (all but one of whom have in fact sent feedback) |
| 06:40 | <mpilgrim> | hixie: the only part of the "Consensus Resolution" that matters to these people is the one this one: |
| 06:40 | <mpilgrim> | """"We recommend that HTML5 state that "For guidance on accessibility requirements for text alternatives authors should consult WCAG 2.0." and that HTML should not provide any guidance that conflicts with WCAG.""" |
| 06:41 | <mpilgrim> | i.e. they want you to remove all the examples in the entire @alt section and replace it with a link to WCAG 2 |
| 06:42 | <othermaciej> | mpilgrim: I'm not sure that is what matters to them |
| 06:42 | <othermaciej> | mpilgrim: in fact Steve Faulkner specifically said they are *not* requesting that the current examples be removed |
| 06:43 | <othermaciej> | however, it seems like a worthwhile exercise to find out what does matter to them |
| 06:44 | <mpilgrim> | i stand corrected |
| 06:44 | <Hixie> | see, THIS is why i asked for a statement of what problem they were trying to solve |
| 06:44 | <othermaciej> | I would think that clear mutual understanding of people's positions should be an active goal for the chair |
| 06:44 | <Hixie> | sam says he understands what steven wants |
| 06:44 | <Hixie> | he just won't tell me! |
| 06:45 | <mpilgrim> | "fetch me a rock" |
| 06:45 | <Hixie> | because apparently being editor involves some sort of game of tea leaf reading, in his eyes |
| 06:46 | <othermaciej> | I don't believe he said that he knows what Steven (or rather, WAI) wants |
| 06:46 | <mpilgrim> | but i stand by my original statement, that that recommendation is the sole reason for bringing up the consensus resolution again and again |
| 06:46 | <mpilgrim> | see also this discussion on bruce lawson's site shortly after the resolution was initially published: http://www.brucelawson.co.uk/2009/alternate-text-in-html-5/ |
| 06:46 | <mpilgrim> | they don't give a shit about helping people |
| 06:47 | <mpilgrim> | they just want you to defer to the "experts" |
| 06:47 | <mpilgrim> | JF has actually stated that, on-list |
| 06:47 | <mpilgrim> | "You need to stop contradicting WAI, even if you have proof that they need to update their advice." |
| 06:47 | <mpilgrim> | that's not an accessibility advocate |
| 06:47 | <mpilgrim> | that's a W3C advocate |
| 06:47 | <mpilgrim> | not that there's anything wrong with that, per se |
| 06:47 | <othermaciej> | he just implied that it is wrong to ask them to justify themselves, because Hixie hasn't justified what's in the spec (and when it's pointed out that Hixie did, he claims he knew that and just sort of sweeps it aside) |
| 06:47 | <mpilgrim> | (well, i don't personally think the W3C needs advocates, but however he chooses to spend his time is his business) |
| 06:48 | <Hixie> | othermaciej: i didn't even ask them to justify anything! |
| 06:48 | <mpilgrim> | but someone who actually gave a shit about actually helping disabled people would never say "WE ALL NEED TO FOLLOW THE SAME BAD ADVICE" |
| 06:48 | <Hixie> | othermaciej: i just asked them to tell me what they wanted to solve |
| 06:49 | <mpilgrim> | (source for that JF quote about not contradicting WAI: http://lists.w3.org/Archives/Public/public-html/2009Aug/0149.html ) |
| 06:49 | <othermaciej> | Hixie: that's more or less isomorphic to asking them to give the reason for their suggested changes |
| 06:50 | <othermaciej> | (I suppose the "justify" formulation is more generous by allowing a reason to be given that is not in terms of a problem.) |
| 06:51 | <othermaciej> | mpilgrim: I do remember him saying that |
| 06:51 | <Hixie> | othermaciej: justification is something based on reasoning and data, which is something i typically would ask for once i understood wtf we were actually trying to solve, if a solution was being proposed that wasn't obviously correct |
| 06:51 | <Hixie> | othermaciej: but i'm a long way from getting to the point of looking at the solution yet |
| 06:51 | <mpilgrim> | othermaciej: this discussion about the Consensus Resolution is the same thing |
| 06:52 | <mpilgrim> | this time it's @alt instead of @summary |
| 06:52 | <mpilgrim> | but it's all the same discussion |
| 06:52 | <mpilgrim> | just search-and-replace the name of the attribute, and you could play out this entire thread in advance |
| 06:52 | <Hixie> | othermaciej: they gave me the exam answer. i'm asking for the exam question. the justification is the workings that lead to the answer. |
| 06:53 | <mpilgrim> | hixie: there is no technical justification |
| 06:53 | <mpilgrim> | you have to defer to their guidance because they're experts |
| 06:54 | <mpilgrim> | there. isn't. anything. else. |
| 06:54 | <mpilgrim> | to their argument |
| 06:54 | <Hixie> | mpilgrim: that's possible, but i intend to continue giving them the benefit of the doubt. |
| 06:55 | <othermaciej> | the Goals section of this document is admittedly a bit thin on stating the goals |
| 06:55 | <othermaciej> | I am assuming the general high-level goal is to make content including images accessible to the blind |
| 06:55 | <mpilgrim> | i stopped giving them the benefit of the doubt when JF referred to his fork as "the respect draft" |
| 06:55 | <mpilgrim> | and made it clear that he was not an accessibility advocate |
| 06:56 | <othermaciej> | I have to mention in fairness that not everyone in WAI agrees with JF or likes him being acting as their advocate |
| 06:57 | <Hixie> | mpilgrim: i treat all input independently of where it comes from, which means in this instance not caring if there's a history here. |
| 06:57 | <othermaciej> | and that, conversely, JF has shown himself more open to negotiating than other WAI advocates |
| 06:58 | <mpilgrim> | in related news, i'm anxiously looking forward to seeing sam's next excuse for not publishing the editor's draft that the working group has told him they want published |
| 06:59 | <mpilgrim> | not that it matters |
| 06:59 | <mpilgrim> | hixie's made over 60 edits since the poll began |
| 06:59 | <mpilgrim> | time marches on |
| 06:59 | <othermaciej> | mpilgrim: I believe he will publish it |
| 07:00 | <mpilgrim> | then you are less of a cynic than i |
| 07:01 | <othermaciej> | I am differently cynical |
| 07:01 | <mpilgrim> | steve has published http://www.paciellogroup.com/blog/misc/HTML5/textalternatives.html |
| 07:01 | <othermaciej> | I think Sam would prefer the other draft, but doesn't care enough to put his credibility on the line |
| 07:01 | <mpilgrim> | (linked from http://lists.w3.org/Archives/Public/public-html/2009Aug/0826.html ) |
| 07:02 | <mpilgrim> | perhaps sam could latch onto that and claim that it was an editor's draft of a rewrite of the @alt section |
| 07:03 | <othermaciej> | While Sam is willing to indulge late-breaking objections to publication, I doubt he will enter one himself |
| 07:04 | <mpilgrim> | well, steven did say "I have taken it upon myself to work an alternative version of the spec that impacts on both of these parts" |
| 07:04 | <mpilgrim> | sounds poll-worthy to me! |
| 07:05 | <mpilgrim> | Sam would obviously prefer Manu's draft; he voted for it, after all. |
| 07:07 | <mpilgrim> | hixie: you said "The WHATWG is going to be ready for last call in less than two months" ( http://lists.w3.org/Archives/Public/public-html/2009Aug/0844.html ) |
| 07:07 | <mpilgrim> | what does that mean, exactly? |
| 07:08 | <othermaciej> | Steve's draft doesn't seem to be in line with the WAI resolution as stated |
| 07:09 | <othermaciej> | (it doesn't include any of the ARIA stuff, and it doesn't allow <figure><legend> instead of alt, to give two concrete examples) |
| 07:09 | <Hixie> | mpilgrim: it means we'll be at zero issues in the three issue trackers that have real issues in them before the end of october. |
| 07:09 | <mpilgrim> | ok |
| 07:10 | <mpilgrim> | and then what happens? |
| 07:10 | <Hixie> | then the spec goes to last call |
| 07:10 | <mpilgrim> | ...within the WHATWG |
| 07:10 | <Hixie> | and the w3c, unless the wg decides otherwise |
| 07:10 | <mpilgrim> | snort |
| 07:11 | <othermaciej> | I believe the W3C condition for Last Call would be closing out all issue tracker issues, followed by some sort of vote |
| 07:13 | <othermaciej> | I have decided to work on the former, I do wish I had somewhat more active support from Sam |
| 07:14 | <othermaciej> | I am having a hard time reading the issues graph |
| 07:14 | <othermaciej> | is there any particular browser I should use? |
| 07:17 | <Hixie> | safari trunk works |
| 07:17 | <othermaciej> | so it does |
| 07:18 | <Hixie> | actually safari trunk shows two bugs |
| 07:18 | <Hixie> | one is that fillText() doesn't support its width argument |
| 07:18 | <Hixie> | and the other is that there's some sort of repaint bug |
| 07:18 | <Hixie> | sometimes you have to cause the window to repaint to see the labels |
| 07:18 | <othermaciej> | in Safari 4.0.3 what was missing were the green and cyan lines |
| 07:18 | <othermaciej> | is Issues measuring issue tracker issues or something else? |
| 07:19 | <othermaciej> | (guessing based on e-mails and bugs being the other lines) |
| 07:19 | <othermaciej> | I guess the data doesn't fit that hypothesis so nevermind |
| 07:20 | <Hixie> | issues is the XXX markers in the spec |
| 07:20 | <Hixie> | some of them show as red boxes |
| 07:20 | <Hixie> | others are just in comments |
| 07:59 | <JonathanNeal> | YAY!ch-T-M-L |
| 07:59 | <annevk42> | the sync database API is now async? |
| 07:59 | <annevk42> | mwaha |
| 08:05 | <JonathanNeal> | What is currently <div id="wrapper"> would best be replaced with <section> or <article> in HTML5? My assumption is <section> because it doesn't specifically intend the page to have any subject, it could be completely administration based. |
| 08:06 | <annevk42> | <section> has certain implications so <div> is probably better |
| 08:07 | <othermaciej> | if something is in fact a section, it's good to use <section> |
| 08:07 | <annevk42> | I think we should have an element for <div id=wrapper> / <div id=content> / <div id=main> though |
| 08:07 | <annevk42> | othermaciej, not if it doesn't have a header |
| 08:07 | <othermaciej> | if its peers are <aside>, <nav>, <header>, etc |
| 08:07 | <JonathanNeal> | well, the thing is that the page does have a header. |
| 08:07 | <othermaciej> | I see |
| 08:08 | <othermaciej> | then per current spec, <div> would be correct, but it does seem useful to have an element for the main content |
| 08:08 | <annevk42> | you typically want something like <header/> <content/> <footer/> but we do not have <content/> |
| 08:08 | <JonathanNeal> | http://pastebin.org/9577 - in this example I'm using section. I know accessibility folks mentioned that I need a skip element in the nav |
| 08:09 | <annevk42> | JonathanNeal, oh, for that markup you do not need id=wrapper at all |
| 08:09 | <annevk42> | JonathanNeal, just style the body element |
| 08:10 | <othermaciej> | yeah, <div id="wrapper"> seems redundant |
| 08:10 | <JonathanNeal> | Well, what if the site needs to be a certain overall width and centered. |
| 08:10 | <hsivonen> | in general, one shouldn't use <section> unless the purpose is to get the outline algorithm effects that come with <section> |
| 08:10 | <othermaciej> | id="banner" could be <header> |
| 08:10 | <othermaciej> | id="navigation" could be <nav> |
| 08:10 | <annevk42> | JonathanNeal, body { width:700px; margin:0 auto } ? |
| 08:10 | <othermaciej> | id="footer" could be <footer> |
| 08:11 | <JonathanNeal> | Right, I used section because I believed the meaning of the content to be <section>. |
| 08:11 | <othermaciej> | id="content-wrapper" should be the hypothetical "main content" element |
| 08:12 | <JonathanNeal> | But the <section> element meets the criteria of content, if it has meaning. |
| 08:12 | <JonathanNeal> | If it doesn't have meaning, then <div> already works perfectly. |
| 08:12 | <annevk42> | dude, you can style the body element :) |
| 08:15 | <hsivonen> | I'm curious if the list of premises I sent to public-html turns out to be flawed |
| 08:15 | <othermaciej> | hsivonen: the text about <section> says "the section element is appropriate only if the element's contents would be listed explicitly in the document's outline", but on the other hand it says it's a "generic document or application section", and applications don't generally have outlines |
| 08:16 | <hsivonen> | othermaciej: hmm. "application section" has a bad spec smell |
| 08:16 | <JonathanNeal> | Can the header and footer elements be children of the body? |
| 08:16 | <othermaciej> | whether applications have "sections", it's hard for me to say |
| 08:16 | <othermaciej> | JonathanNeal: yes |
| 08:17 | <hsivonen> | don't we have <fieldset> for application "sections"? |
| 08:17 | <JonathanNeal> | Well, I can be very direct with it's application, Liferay Portal. So, at that point we're talking about multiple applications per page many times. |
| 08:17 | <othermaciej> | hsivonen: <fieldset> implies some rendering behavior that is no longer considered a good idea for modern HI design |
| 08:17 | <hsivonen> | JonathanNeal: are you developing Liferay itself or are you developing a portal based on Liferay (just curious) |
| 08:17 | <hsivonen> | othermaciej: true |
| 08:20 | <JonathanNeal> | hsivonen, the front end of the portal, http://www.liferay.com/web/jonathan.neal/blog |
| 08:22 | <othermaciej> | hsivonen: you didn't comment directly on auto-generated title= |
| 08:23 | <JonathanNeal> | I want to be as true to the intent of html5 as possible. The move to html as the doctype is already in core, but without taking advantage of the newer, proper usage then it's not the most meaningful switch. |
| 08:23 | <othermaciej> | hsivonen: I assume that was an oversight |
| 08:23 | <JonathanNeal> | move to html5* |
| 08:23 | <othermaciej> | (in your premises email) |
| 08:23 | <hsivonen> | othermaciej: Is autogenerated @title materially different from autogenerated @alt under ATAG 2? |
| 08:24 | <othermaciej> | hsivonen: I don't know |
| 08:24 | <othermaciej> | hsivonen: did you mean to imply that ATAG 2 has the same kind of requirement for title? |
| 08:25 | <hsivonen> | othermaciej: I meant to imply that to the extent @title is considered to be a text alternative, ATAG 2 restricts it the same way it restricts alt |
| 08:25 | <hsivonen> | I could be wrong, though |
| 08:26 | <othermaciej> | I think in HTML5, it is considered a substitute text description in light of proper text alternative being unavailable |
| 08:26 | <othermaciej> | I'm not saying what the spec says to do is a good idea necessarily, but I don't think you addressed it |
| 08:27 | <hsivonen> | othermaciej: I sent email addressing it now |
| 08:28 | <othermaciej> | ATAG 2.0 B.2.4 seems to allow a tool to suggest an autogenerated alt, as long as the author has the opportunity to accept, modify or reject it |
| 08:29 | <othermaciej> | so it would be superficially ATAG-compliant to pop up a dialog on every image drop suggesting some alt text with a default OK button |
| 08:29 | <othermaciej> | although I do not think this would lead to good usability for the tool, or good accessibility in the resulting context |
| 08:29 | <hsivonen> | othermaciej: yes. Hence "Most authors don't respond to prompts in a meaningful way." |
| 08:30 | <othermaciej> | it would probably be completely off the table for a tool like Word where producing HTML is a side feature and not the main focus |
| 08:30 | <hsivonen> | It seems I forgot to add yet one more point |
| 08:31 | <hsivonen> | but it's such a given that I don't send more email now |
| 08:32 | <JonathanNeal> | hsivonen, what do you do? |
| 08:32 | <hsivonen> | the point being that the goal is to make average accessibility over the Web better--not just to comply with the letter of ATAG 2 |
| 08:32 | <othermaciej> | ATAG 2.0 does require allowing the author to reject, so on its terms, it has to be possible to use an authoring tool to create output with no alternative text |
| 08:33 | <hsivonen> | JonathanNeal: I develop an HTML5 parser for Gecko, an HTML5 validator, and I read and write a lot of related email |
| 08:34 | <JonathanNeal> | hsivonen, well that's excellent! |
| 08:35 | <JonathanNeal> | Most of us are big fans of HTML5 and want to do it right, and the thumbs up has been given to make the move. |
| 08:35 | <JonathanNeal> | Minus the part where we wait for it to be final, you know, cause it's like after the second coming. |
| 08:46 | <othermaciej> | hsivonen: sent reply in email |
| 08:47 | <othermaciej> | hsivonen: I think the way HTML5 suggests using title does not technically run afoul of the letter ATAG2, even if a tool added it automatically, but I am not sure if it is in the spirit of ATAG2 |
| 08:58 | <JonathanNeal> | annevk42, I agree with killing the wrapper div, I think we were using it when really the css margin style could have been safely set on the body tag, and also, when anything tricky needs to be made, we can still add <div> elements, but there's no reason to add a page-wide <section> when there's nothing outside of it and the body. |
| 09:01 | <JonathanNeal> | Also, I need to fix my improper usage of the hgroup tag, I even made a graphic to remind myself that the hgroup element should not group together tree-based hierarchies, but rather group together descriptive headlines. |
| 09:03 | <annevk42> | JonathanNeal, because of bugs in IE5 and the somewhat special status of the body element lots of people do not realize it is just another <div> |
| 09:04 | <annevk42> | JonathanNeal, i.e. you can give it a width, center it, etc. |
| 09:04 | <JonathanNeal> | Right, and I was testing all of this against ie6 too. |
| 09:05 | <annevk42> | it should work fine in IE6 in standards mode |
| 09:06 | <othermaciej> | annevk42: doesn't <body> have some special behavior for backgrounds though? |
| 09:06 | <JonathanNeal> | Someone was asking if Liferay has an official "supported" list, and I'm not sure that we do, but I know that we support Internet Explorer 6+, Firefox 2+, and Safari 4+. I know that I personally test everything on IE6+, FF3, and Safari 4. |
| 09:07 | <annevk42> | othermaciej, only if nothing is set on html {} |
| 09:07 | <hsivonen> | JonathanNeal: is there a reason why old safari versions get cut faster than old Firefox? |
| 09:08 | <hsivonen> | JonathanNeal: is it hard to keep old Safari around? or is the population on Safari 3.x insignificant? |
| 09:08 | <annevk42> | othermaciej, but yeah, it has a somewhat special status, e.g. some event handler attributes on the body element register event handlers on the Window object |
| 09:08 | <JonathanNeal> | Yes, because Safari3 was never really tested to begin with. |
| 09:08 | <hsivonen> | JonathanNeal: I see |
| 09:08 | <JonathanNeal> | We supported it on a per-client basis, which means that most of the features probably worked fine, and I bet we took on a few tickets addressing incompatibilities. |
| 09:09 | <JonathanNeal> | So, Nate is the director of UI and he works on a Mac now, which has probably made a significant impact on our Safari and Mac testing. :-) |
| 09:09 | hsivonen | wonders if remaining Firefox 2 users are Mac & Windows self-installed copies or system copies on long-term-supported Linux distros |
| 09:10 | <othermaciej> | FWIW Safari 4 is around 55% of all Safari users |
| 09:10 | <othermaciej> | I believe in absolute numbers, slightly more people use Safari 3.x than Firefox 2.x, though Firefox 3.0 is still above all versions of Safari |
| 09:11 | <JonathanNeal> | Well, a lot of our support is directed by what the corporate clients are running, and sadly they're pretty-much all running IE6. |
| 09:11 | <JonathanNeal> | Whether it's government policy or MS built them a custom chop of IE6 that couldn't reasonably be afforded an upgrade. |
| 09:11 | <othermaciej> | IE6 has itself a solid little perch there |
| 09:15 | <JonathanNeal> | othermaciej, you could set html { overflow-y: scroll; } *for sure triggering the scrollbar* and body { background: *whatever color and whatever image*; margin: 100px auto 0; width: 960px; } and the background will still expand from the very top and all the way from either side of the page, in IE6+, FF, Safari. |
| 09:16 | <JonathanNeal> | However, if you set html { background: *anything* } then it will trigger the background to act like it would on a div. |
| 09:20 | <JonathanNeal> | <nav> should go within <header>? But is it required? |
| 09:22 | <JonathanNeal> | e.g: http://pastie.org/585630 should I move <nav> out of <header> and make it a direct child of <body>? Or is it proper for <nav> to reside as a direct child of <header>? |
| 09:27 | <annevk42> | either way is ok |
| 09:36 | <JonathanNeal> | Well, then here is my latest draft @ http://pastie.org/585640 |
| 09:38 | <jgraham> | JonathanNeal: Did someone already point you toward http://gsnedders.html5.org/outliner/ ? |
| 09:38 | <jgraham> | If the output from that looks sensible you are probably using headings/sectioning elements in the right way |
| 09:38 | <JonathanNeal> | jgraham, yes, but very early in my research. All right, thanks. |
| 09:40 | <jgraham> | (I'm not really sure your <header> shouldn't be a <hgroup> but I didn't follow the earlier discussion of that too closely) |
| 09:43 | <JonathanNeal> | jgraham, the idea is that hgroup is for non-tree hierarchical headings, but instead for subheadings, alternative titles, or taglines like, in our case, company slogans, mottos, etc. |
| 09:44 | <jgraham> | JonathanNeal: I understand what hgroup is for |
| 09:44 | <jgraham> | What I'm not sure about is how you expect the document outline to look |
| 09:44 | <JonathanNeal> | Well, my community title is part of a larger tree. |
| 09:44 | <jgraham> | JonathanNeal: Oh well it might be fine then |
| 09:45 | <JonathanNeal> | You have a multiple portal instances which can have the company title, then within a portal instance you can have any number of communities, and those communities have pages. |
| 09:45 | <JonathanNeal> | *you have multiple |
| 09:45 | <jgraham> | Just make a demo page with some portal contents and see if it looks right :) |
| 09:45 | <annevk42> | Hmm, I proposed a solution; hopefully the problem is clear |
| 09:46 | <jgraham> | annevk42: Would you only be allowed exactly one <content> element per page? |
| 09:47 | jgraham | doesn't know what the corresponding aria requirements are |
| 09:47 | <hsivonen> | why <content>? why not <main> |
| 09:47 | <hsivonen> | or <therealbody> :-) |
| 09:48 | <jgraham> | fwiw <main> sounds better to me |
| 09:48 | <jgraham> | because it communicates "singleton" better |
| 09:49 | <hsivonen> | what does Firefox+JAWS do if you have more than one role=main? |
| 09:49 | <annevk42> | hsivonen, see above about me proposing a solution |
| 09:49 | <jgraham> | (you can argue that anything is "content" and I imagine we would get pages with dozens of <content> elements when they meant <article>) |
| 09:49 | <annevk42> | :/ |
| 09:49 | <annevk42> | maybe it is because I always used <div id=content> :) |
| 09:50 | <othermaciej> | I like <main> better |
| 09:50 | <JonathanNeal> | I think the html outliner thinks my nav needs a title. |
| 09:50 | <beowulf> | i use 'page', but isn't the use of an element like that presentational? |
| 09:50 | <othermaciej> | I think identifying the main content is no more presentational than identifying the header or the navigation area |
| 09:51 | <hsivonen> | the situation with these elements and ARIA landmarks is a very sad case of turf wars and parsing badness |
| 09:51 | <othermaciej> | hsivonen: are you suggesting one of the two should not exist? |
| 09:51 | <othermaciej> | (and if so, which?) |
| 09:52 | <hsivonen> | othermaciej: ideally, yes |
| 09:52 | <annevk42> | if we had the elements on time ARIA landmarks would not be needed |
| 09:52 | <othermaciej> | once the elements are widely usable, ARIA landmarks will be less necessary |
| 09:52 | <JonathanNeal> | Yes, the outliner wants my <nav> to have a header. Is that even right? |
| 09:52 | <hsivonen> | othermaciej: ideally, I think we should just have the elements (in an ideal world they'd parse sanely in IE6) |
| 09:53 | <jgraham> | JonathanNeal: Er... this is an area of some confucion |
| 09:53 | <jgraham> | *confusion |
| 09:53 | <hsivonen> | for the same reason we in general prefer to write <eltname> instead of <div role=eltname> |
| 09:53 | <othermaciej> | hsivonen: I agree it would be better to have just the elements |
| 09:54 | <othermaciej> | I don't think the roles came into existence mainly due to "turf wars", more because HTML was unmaintained at W3C at the time |
| 09:54 | <jgraham> | _in principle_ I think it is useful if <nav> had a heading. In practice I have neverr seen anyone do it |
| 09:54 | <jgraham> | Or at least it is unusual |
| 09:54 | <hsivonen> | othermaciej: ok. maybe this isn't a case of turf wars, but it is a case of WGs doing their own thing instead of working on the platform holistically |
| 09:54 | <jgraham> | Generally as long as you don't have any more sections nested under the <nav> I doubt it is a practical issue |
| 09:55 | <othermaciej> | and also the older HTML WG seemed to think that <div role=eltname> was genuinely better than <eltname> |
| 09:55 | <JonathanNeal> | Well, isn't the sibling <header> element representing what the <nav>'s <h1-h6> elements be doing? |
| 09:55 | <jgraham> | If you do then I think you will hit badness in the current outline algorithm |
| 09:55 | <hsivonen> | othermaciej: the older HTML WG assumed their stuff wouldn't be natively implemented in IE |
| 09:55 | <jgraham> | JonathanNeal: In general sibling relationships are not used |
| 09:55 | <jgraham> | formally |
| 09:56 | <othermaciej> | hsivonen: eventually they assumed it wouldn't be natively implemented by anyone... |
| 09:56 | <othermaciej> | but I think their love of role fits their design taste |
| 09:56 | <othermaciej> | comes from the same spiritual place as allowing src= and href= on everything |
| 09:57 | <hsivonen> | it also comes from the place where stuff needs to be DTD-valid but declaring attributes to take any CDATA is OK |
| 09:57 | <JonathanNeal> | So if a page has a header with navigation, then the navigation needs to either re-specify that the navigation belongs to the header, and/or that the navigation is, in fact, navigation through use of an <h1>Navigation</h1>? |
| 09:57 | <othermaciej> | as a side note: I'm really happy that I asked Steve Faulkner to help me understand the reasoning behind the proposal, now that he spoke up about point (7) |
| 09:58 | <othermaciej> | and I'm even more upset at Sam for criticizing me for it |
| 10:00 | <hsivonen> | part of the sadness regarding the landmarks is that now that <div role=main> etc. exist, it's not clear that the incremental elegance of the HTML5 elements is worth the cost of having a dual system |
| 10:01 | <hsivonen> | also, it seems that Firefox 2 will have expired by the time these semantics really take off (if they ever take off) |
| 10:01 | <jgraham> | JonathanNeal: Well I think in general you would want something like <nav><h1>Site Map</h1></nav> or whatever the actual <nav> contents are but, in practice, I think it is likely fine to leave it with no header |
| 10:01 | <annevk42> | we can phase out ARIA landmarks over time |
| 10:01 | <JonathanNeal> | I want to understand this one, because <header><h1>Header</h1> ... actual header title ... </header> isn't necessary, so why would <nav><h1>Navigation</h1> ... actual navigation ... </nav> be? |
| 10:01 | <hsivonen> | oops. I've managed to intertwingle the conceptual parts of the Gecko HTML5 parser more that I meant to |
| 10:02 | <JonathanNeal> | If you see my concern with this, it seems redundant to create an element to specify navigation if you're only going to force me to label it again. |
| 10:03 | <jgraham> | JonathanNeal: You are not forced to label it. But you might have several types of navigation on a page so it is possible to label it to distinguish them |
| 10:03 | <jgraham> | for example |
| 10:03 | <othermaciej> | hsivonen: I think the cost of landmark roles existing is fairly low, and if the elements take off, the roles can fade in importance over time |
| 10:04 | <jgraham> | Presumably a good outline generator on encountering <nav> with no heading would be sensible enough to present it as if it had some generic heading like "navigation" |
| 10:05 | <JonathanNeal> | jgraham, I understand. In the meantime, I'll probably add the label and fear how Google might try to parse an h1 so much earlier than the site's content. |
| 10:05 | <hsivonen> | doh. I forget the image-as-sole-content-of-<a> case when replying to the alt="" stuff |
| 10:05 | <hsivonen> | *forgot |
| 10:06 | <Hixie> | annevk42: the sync database api is still sync, the callbacks aren't called asynchronously. |
| 10:07 | <JonathanNeal> | So, Liferay let's you place any number of portlets on a page, but I was changing our div#content-wrapper to section#content, however all section's need a title so best practice would be instead to use a div? |
| 10:07 | <JonathanNeal> | the content-wrapper wrapped any number of applications, be it blogs, wikis, forums, web content, etc. |
| 10:09 | <jgraham> | JonathanNeal: How would you expect it to look in outline view? If you don't expect the content-wrapper to appear then yes, you should use <div> |
| 10:10 | <JonathanNeal> | Got it. We'll end up failing the outline wrapper anyway if we don't move from tables to divs. I hate divs though, I feel like they are still not at the level of td positioning. |
| 10:11 | <jgraham> | Yeah some layoput effects can be hard to achieve with CSS, especially if you are supporting IE6 |
| 10:12 | <jgraham> | I keep hoping flexbox will get implemented sometime soon but even that won't help in legacy clients |
| 10:13 | <JonathanNeal> | We have a fully div based layout system, but it will never be as flexable as td in the next 5+ years. |
| 10:14 | <JonathanNeal> | Even IE7 does not support the table/table-cell css display settings |
| 10:15 | <JonathanNeal> | What we have going for us is the growing facination of corporations to use 960 grids and the like. |
| 10:16 | <JonathanNeal> | Anywho, it's 2:18am where I am and I should get some sleep, but I really appreciate everyone's input tonight. I'll be back tomorrow morning. |
| 10:20 | <annevk42> | Hixie, ah, interesting |
| 10:35 | <annevk42> | ok, I can now quickly test name matching rules for ISO-8859-9 at least |
| 10:35 | <annevk42> | hopefully they're generic :) |
| 10:46 | <jgraham> | webben_: Isn't the <a href="#"><img src="delete.png" alt=""></a> assuming that @alt is being used incorrectly? Given that why would you assume that the same authour would get aria right? |
| 10:46 | jgraham | will just say that to the list |
| 10:47 | <jgraham> | Or maybe I am missing something |
| 10:48 | <jgraham> | I guess people don't need more email |
| 10:48 | <annevk42> | so actually the rules Chromium is using for charset matching break pages too |
| 10:48 | <annevk42> | e.g. http://memorystick.com/en/index.html does not look good |
| 10:48 | <annevk42> | I think the far stricter rules Firefox uses might be better |
| 10:49 | <annevk42> | does anyone here have IE (any version)? |
| 10:50 | <Lachy> | annevk42, yes |
| 10:50 | <annevk42> | results for http://dump.testsuite.org/2009/encoding-matching/ would be appreciated |
| 10:51 | <annevk42> | not the PASS/FAIL bit but what the used encoding is |
| 10:52 | <Lachy> | ok, give me a few minutes before I get to it |
| 11:06 | <nvartolomei> | something interesting here? :-) |
| 11:07 | <Lachy> | annevk42, results for IE8: 001 Windows-1254; 002 Windows-1252; 003 Windows-1254; 004 Windows-1252; 005 Windows-1252; 006 Windows-1254; 007 Windows-1252; 008 Windows-1252; 009 Windows-1252; 010 Windows-1254; 011 Windows-1254; 012 Windows-1252; 013 Windows-1252; 014 Windows-1252; 015 Windows-1252; 016 Windows-1252 |
| 11:15 | <nvartolomei> | In html5 we can use <meta charset="UTF-8" /> right? |
| 11:16 | <Hixie> | no need for the "/" but otherwise yes |
| 11:16 | <nvartolomei> | should we wait <meta description="something here" /> ? :-) |
| 11:16 | <Hixie> | what would it be for? |
| 11:17 | <nvartolomei> | now: <meta name="description" content="" />, <meta description="" /> is prettier :-) |
| 11:19 | <Lachy> | nvartolomei, by that logic, we should also have <meta author="...">, <meta date="..."> and attributes for whatever other metadata authors want to use. That would not be a good solution |
| 11:20 | <Lachy> | besides, the using <meta> for providing a description is of questionable value anyway |
| 11:20 | <Lachy> | s/the using/using/ |
| 11:21 | <Hixie> | nvartolomei: <meta name=description> is a waste of time, i wouldn't worry about it |
| 11:21 | <nvartolomei> | Hixie, google shows it in description :-) |
| 11:22 | <Hixie> | yeah but it's better to let google figure out its own description |
| 11:22 | <nvartolomei> | Hixie i never used it, but today i noticed that |
| 11:23 | <Lachy> | nvartolomei, can you give an example where Google uses the content from a meta description in its results? |
| 11:23 | <nvartolomei> | http://www.google.md/search?hl=mo&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=O7e&q=w3&btnG=C%C4%83utare |
| 11:24 | <nvartolomei> | good example? |
| 11:25 | <Lachy> | yeah, but I'd still advise against using it |
| 11:27 | <hsivonen> | othermaciej: IIRC, Safari+VO is already smart about <a href="..."><img alt=""></a> |
| 11:27 | <Hixie> | i'm going to bed. hopefully while i'm sleeping _someone_, whether sam or steven, will deign to reply to one of my e-mails and explain what on earth the problem with the spec is that they're so eager to have me fix. |
| 11:27 | <Hixie> | nn |
| 11:27 | <hsivonen> | nn |
| 11:28 | <othermaciej> | hsivonen: that's great, but I bet it wouldn't be if we had to follow a requirement to never expose <img alt=""> to accessibility APIs... |
| 11:28 | <othermaciej> | hsivonen: agreed though that it works better as an actual and not a mere hypothetical :-) |
| 11:29 | <hsivonen> | fwiw, what I want is software-developer-readable (i.e. not lawyerly) explanation of what GUI HTML editors should/must do under certain plausible sequences of user actions |
| 11:29 | <hsivonen> | so that the explanation is blessed by WAI |
| 11:30 | <hsivonen> | without consensus on what the HTML-generating software must do, discussing the rest is rather pointless |
| 11:31 | <annevk5> | thanks Lachy! |
| 11:32 | <annevk5> | so IE has rather strict matching rules too |
| 11:33 | <annevk5> | and I guess they have ISO_8859-1 and ISO-8859-1 as alias but not ISO_8859_9 |
| 11:34 | <hsivonen> | fun |
| 11:34 | <annevk5> | only ISO_8859-9 is IANA endorsed |
| 11:35 | <annevk5> | (that they treat ISO-8859-9 as Windows-1254 is not IANA endorsed, but I guess all browsers should just copy that) |
| 11:36 | <annevk5> | Hixie, btw, you should really talk to hyatt about <menu>; afaik he's the only implementor that let his opinion known so far and he doesn't like it at all |
| 11:37 | <hsivonen> | who asked for <menu>? |
| 11:38 | <annevk5> | it's part of the feature set needed for apps |
| 11:38 | <annevk5> | but the way we solved it is not optimal for the vast majority of menu systems in use on the Web |
| 11:38 | <annevk5> | dhyatt wants something that can replace all the DHTML stuff with something cleaner |
| 11:40 | <adactio> | Sorry to butt in but I have a quick question about <article>... |
| 11:40 | <adactio> | Can <article> be used for the *synopsis* of an article e.g. an index page that lists the "latest news" stories—they each have a header, a footer and content in-between but the content is a description or synopsis of the linked article rather than the entire article. |
| 11:44 | <hsivonen> | adactio: I recall criticizing an HTML5-based blog design using <article> like that |
| 11:44 | <hsivonen> | adactio: because the idea is that <article> stands alone |
| 11:49 | <annevk5> | While doing charset research I also found http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu38/eucjp.patch.txt?revision=4634&view=markup which suggests encodings themselves are not always implemented accorded to the standard... |
| 11:50 | <annevk5> | I know pretty much every layer of the Web is a mess, but when I actually encounter it it still surprises me... |
| 11:50 | <jgraham> | http://www.alertdebugging.com/2009/08/16/on-html-5-drag-and-drop/ |
| 11:52 | <nvartolomei> | hm |
| 11:53 | <hsivonen> | jgraham: the comment has a new metaphor: aluminum foil around a pig |
| 12:31 | <jgraham> | The bullet list in section 4.3.1 just before the "runnjing a script" algorithm kind of implies that doing something like var a = document.createElement("script"); a.src="foo.js" will cause foo.js to run |
| 12:33 | <jgraham> | which is not the case. Even if a thorough reading of the spec would give the right behaviour here it would be nice to make it obvious upfront |
| 12:34 | <adactio> | hsivonen: do you mind if I ask a quick question about your validator? |
| 12:34 | <hsivonen> | adactio: go ahead |
| 12:35 | <adactio> | hsivonen: it seems to be choking on the aria role="search" on a form element but all the other aria roles I'm using are passing fine. Have I misunderstood something about this particular role? |
| 12:37 | <hsivonen> | adactio: looks like a bug in the schema. thanks |
| 12:37 | <adactio> | hsivonen: phew! I was hoping you'd say that. ;-) |
| 13:04 | <virtuelv> | whee |
| 13:04 | <virtuelv> | javascript:alert(window.frames) |
| 13:04 | <virtuelv> | three browser engines, three different results |
| 13:06 | <virtuelv> | Webkit (Chromium): [object global], Opera: [object WindowCollection], Gecko: [object Window] |
| 13:08 | <zcorpan> | virtuelv: gecko is right |
| 13:09 | <virtuelv> | zcorpan: according to some spec written post-facto, yes |
| 13:09 | <virtuelv> | there's so much about the frames interface that doesn't make sense, though |
| 13:09 | <virtuelv> | window.frames.location |
| 13:09 | <virtuelv> | location of what, exactly |
| 13:09 | <zcorpan> | window.frames is the same as window.window |
| 13:09 | <zcorpan> | and window.self |
| 13:10 | <virtuelv> | zcorpan: yes, but by that logic, I should be able to address frames in a document as |
| 13:10 | <virtuelv> | window[0..n] |
| 13:10 | <zcorpan> | you can |
| 13:10 | <virtuelv> | and I'm saying this still doesn't make the slightest bit of sense |
| 13:11 | zcorpan | points at topic :) |
| 13:11 | gsnedders|work | wonders how much of HTML and its related APIs makes sense |
| 13:12 | <virtuelv> | zcorpan: and to answer your question: at least up to firefox-3, you can't |
| 13:12 | <hsivonen> | zcorpan: do you have plans to change lookupNamespaceURI in Web DOM Core? I see you have Lachy's email on file. |
| 13:13 | <hsivonen> | zcorpan: see comments at https://bugzilla.mozilla.org/show_bug.cgi?id=505178 |
| 13:13 | <hsivonen> | zcorpan: did you see othermaciej's suggestion to add markupAsXML to Document and Element? |
| 13:15 | <virtuelv> | (apologies, you can) |
| 13:22 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/211 is interesting in Opera |
| 13:23 | <hsivonen> | does Opera not implement lookupNamespaceURI per spec? |
| 13:26 | <hsivonen> | hmm. it seems that Opera implements things like Gecko |
| 13:27 | <hsivonen> | so we have Opera and Gecko on one hand and the spec an WebKit on the other |
| 13:27 | <hsivonen> | oops sorry. I mistested |
| 13:27 | <hsivonen> | I misdiagnosed Opera |
| 13:28 | <zcorpan> | hsivonen: i hadn't given lookupNamespaceURI much thought yet, or even tested it |
| 13:30 | <Lachy_> | WTF?! http://lists.w3.org/Archives/Public/public-html/2009Aug/0882.html |
| 13:31 | <hsivonen> | http://hsivonen.iki.fi/test/moz/lookupNamespaceURI.xhtml |
| 13:31 | <hsivonen> | yay for interop |
| 13:31 | <othermaciej> | Lachy: upon examining William's recent list contributions, that message is not outside expectations |
| 13:31 | <hsivonen> | Gecko treats null and "" equally |
| 13:31 | <hsivonen> | Opera understands "" but not null |
| 13:32 | <hsivonen> | WebKit understands null but not "" |
| 13:32 | <hsivonen> | for the values they do understand, WebKit and Opera work per spec but Gecko does not |
| 13:32 | <hsivonen> | and one might argue that the spec sucks and Gecko sucks less |
| 13:33 | <zcorpan> | i think it makes sense to treat null and "" equally |
| 13:34 | <Lachy> | othermaciej, I found that one reached a new level of incomprhensibility. |
| 13:34 | <jgraham> | Lachy: As far as I can tell William Loughborough is pure troll. I have never noticed him make any constructive sontribution to a discussion on public-html |
| 13:34 | <hsivonen> | the question I'm interested in is this: will we make the spec suck less or are we sticking to the current spec |
| 13:34 | <jgraham> | s/son/con/ |
| 13:34 | <gsnedders|work> | make it suck more! |
| 13:35 | <hsivonen> | the spec is kinda nice for new world text/html |
| 13:35 | <othermaciej> | Lachy: I believe he's saying that the conversation thread in question is crazy and will contribute to HTML5 taking a really long time to complete |
| 13:36 | <othermaciej> | hsivonen: I didn't understand the issue from the bug comments |
| 13:37 | <zcorpan> | hsivonen: if you convince webkit to implement the gecko behavior then that's what it will be |
| 13:37 | <zcorpan> | hsivonen: if you implement the spec behavior then that' |
| 13:37 | <zcorpan> | s what it will be |
| 13:37 | <zcorpan> | or s/webkit/opera/ |
| 13:37 | <Lachy> | I don't see how that thread is crazy. In comparison with previous threads on the topic, it seems to be at least on the positive side |
| 13:37 | <hsivonen> | Lachy: indeed |
| 13:37 | <hsivonen> | zcorpan: OK |
| 13:37 | <jgraham> | zcorpan: If no one is willing to budge? |
| 13:38 | <othermaciej> | Lachy: I didn't say I agreed with him - it seemed like a constructive thread to me |
| 13:38 | <hsivonen> | othermaciej: the issue is that the spec allows the immutable prefixes on element nodes participate in the lookup |
| 13:38 | <zcorpan> | jgraham: then we don't have interop and writing the spec is a waste of time |
| 13:38 | <othermaciej> | Lachy: but after reading over his other recent emails, I decided not to apply |
| 13:38 | <hsivonen> | othermaciej: so even if you mutate xmlns:* attrs in script, the immutable prefixes in node names still interfere with the lookup |
| 13:39 | <othermaciej> | hsivonen: I guess I don't understand the use cases for lookupNamespaceURI enough to understand why that's a problem |
| 13:39 | <zcorpan> | the html5 spec uses lookupNamespaceURI for defining innerHTML in XML |
| 13:40 | <zcorpan> | that's the only use case i'm aware of |
| 13:40 | <hsivonen> | isDefaultNamespace in Gecko is implemented so that it agrees with lookupNamespaceURI(null) |
| 13:40 | <hsivonen> | which is sane |
| 13:40 | <zcorpan> | so i guess lookupNamespaceURI should make things serialize sanely in innerHTML |
| 13:42 | <hsivonen> | othermaciej: the use cases are basically anti-patterny to begin with |
| 13:43 | <othermaciej> | zcorpan: isn't that putting the cart before the horse? it seems like step 1 is to determine how an XML DOM in this state should serialize for innerHTML, and step 2 is to determine whether lookupNamespaceURI is useful for specifying that behavior |
| 13:43 | <hsivonen> | othermaciej: since lookupNamespaceURI makes sense for qnames-in-content |
| 13:44 | <hsivonen> | othermaciej: so the spec sucks when you try to create synthetic DOMs with qnames-in-content and the same prefixes in parser-created pre-mutation parts |
| 13:44 | <zcorpan> | othermaciej: true |
| 13:45 | <zcorpan> | othermaciej: Hixie just took the easy course and made it my problem when i asked questions about namespace declarations in innerHTML |
| 13:45 | <othermaciej> | hsivonen: hearing the problem statement just names me hate Namespaces in XML more |
| 13:46 | <Lachy> | is there any kind of protection against the abuse of role="presentation" by authors who don't really know what they're doing? Given that it's supposed to be to inform UAs not to report the element to accessibility APIs, what if an author does <body role="presentation">? |
| 13:46 | <othermaciej> | zcorpan: I guess the specific question raised by hsivonen's mutated DOM scenario is - let's say you have a node with prefix "foo", local name "bar", namespace URI "http://foo.com/"; created by the parser, then using DOM manipulation you give it an xmlns:foo="http://something-else"; attribute |
| 13:46 | <othermaciej> | how should innerHTML serialize that? |
| 13:47 | <zcorpan> | othermaciej: that's what i asked Hixie |
| 13:47 | <hsivonen> | othermaciej: I'm not only hearing the problem. I'm on hook for implementing it! |
| 13:47 | <gsnedders|work> | You're allowed to change namespace prefixes to serialize the DOM, so however you want, provided the element has the same local anme and namespace URI, no? |
| 13:48 | <gsnedders|work> | s/anme/name/ |
| 13:48 | <jgraham> | gsnedders|work: I assume qnames-in-content is the issue |
| 13:48 | <othermaciej> | hsivonen: mutating a DOM to rebind parser-created prefixes, so that you can use lookupNamespaceURI to process QNames in content, sounds like a giant pile of bad |
| 13:48 | <othermaciej> | hsivonen: changing specs to make that marginally less terrible doesn't seem very useful |
| 13:48 | <jgraham> | s/ mutating a DOM to rebind parser-created |
| 13:48 | <jgraham> | prefixes, so that you can use lookupNamespaceURI to |
| 13:48 | <gsnedders|work> | jgraham: Where guarantees that that can roundtrip? |
| 13:49 | <zcorpan> | as far as i'm concerned i would be happy to drop lookupNamespaceURI |
| 13:49 | <jgraham> | process QNames in content/namespaces in XML/ |
| 13:49 | <othermaciej> | hsivonen: if you want a synthetic DOM to be isolated from parser artifacts, you can always make a new document, or a detached DOM subtree, for your namespace processing |
| 13:49 | <jgraham> | (sorry) |
| 13:50 | <hsivonen> | Lachy: no protection. ARIA provides all the rope to shoot your users in the foot |
| 13:50 | <othermaciej> | gsnedders|work: I suspect if browsers don't serialize that weirdo case in the same way, there will be interop problems down the road |
| 13:50 | <jgraham> | gsnedders|work: I don't think they exist. But nevertheless some stuff depend on qnames in content roundtripping |
| 13:51 | <othermaciej> | hsivonen: what kind of rope can you use to shoot people in the foot? <rope role="bullet">? |
| 13:51 | <hsivonen> | othermaciej: yeah |
| 13:52 | <jgraham> | (I think elementree ha[s|d] problems with this since it didn't preserve namespace prefixes by default |
| 13:52 | <jgraham> | ) |
| 13:53 | <othermaciej> | Lachy: I suspect we'll have to put in some kind of heuristics in WebKit to not always respect role="presentation" if it starts getting used in bad ways |
| 13:54 | <Lachy> | my guess is that some people using HTML for presentation slides will misuse role=presentation in their pages |
| 14:05 | <hsivonen> | hmm. Opera and WebKit are so compliant they don't even hard-wire "xml" and "xmlns" |
| 14:45 | <Lachy> | hsivonen, I'm surprised any editor would output this: <img src="file:///Volumes/koti/hsivonen/Pictures/koli/2009-07-21T14-48-54.jpg" alt=""> |
| 14:45 | <Lachy> | http://hsivonen.iki.fi/test/bluegriffon-alt/Koli.html |
| 15:52 | smedero | wonders how this new mailing list came about: http://lists.w3.org/Archives/Public/public-canvas-api/ |
| 15:52 | <JonathanNeal> | Hello all! |
| 15:52 | smedero | grumbles about lack of coffee |
| 15:52 | <gsnedders|work> | Oh noes! He's gone to bed, and woken up again! |
| 15:52 | <gsnedders|work> | smedero: Are you not in your hometown then? |
| 15:52 | <smedero> | lol |
| 15:53 | <smedero> | Am in fact in Seattle. |
| 15:53 | <jgraham> | smedero: That mailing list is old |
| 15:53 | <smedero> | s/Am/I am/ |
| 15:53 | <smedero> | jgraham: why did steven faulkner send a pointer to it then? |
| 15:55 | <jgraham> | smedero: Not sure |
| 15:55 | <smedero> | jgraham: http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0000.html |
| 15:56 | <smedero> | was canvas API discussion always suppose to be directed over there? if so I missed the memo. |
| 15:56 | <jgraham> | smedero: I think it was a failed experiment |
| 16:00 | <smedero> | ahh MikeSmith created it back in March 2008: "The list was created to facilitate focused discussion on the canvas API and to encourage participation in that discussion from graphics experts and others who may not be members of the HTML working group (and may not want to be)." |
| 16:06 | <JonathanNeal> | This weekend was a great crash course in HTML5. |
| 16:06 | <TabAtkins> | Hey, it made me learn something too. |
| 16:06 | <TabAtkins> | I went and reviewed the <article> semantics again, which was useful, and will also be adding a "skip nav" link to my sites today. |
| 16:07 | <JonathanNeal> | TabAtkins, and don't forget to label your <nav> with some type of heading. |
| 16:07 | <TabAtkins> | I prefer to do that anyway, so that's good. |
| 16:10 | <JonathanNeal> | I'm still not sure where to place certain h2 elements. We have company name -> community name -> page name, I know where to put company name and page title, but i don't know where to put the community name. Also, I'll have to look into how Google would parse my site with all these newly introduced h1s. |
| 16:15 | <gsnedders|work> | othermaciej: ping |
| 16:18 | <JonathanNeal> | http://pastebin.org/9738 --- after many discussions. |
| 16:19 | <JonathanNeal> | And I still haven't added the accessibility links, since I think they're not supposed to go in the actual nav. |
| 16:27 | <TabAtkins> | Do you mean the skipnav links? |
| 16:27 | <TabAtkins> | Yeah, they should just be the very first focusable thing in the page. |
| 16:28 | <TabAtkins> | I really like the idea of the link that hides until it's focused, but is positioned off-screen so that pointing devices *can't* focus it even accidentally. |
| 16:28 | <JonathanNeal> | http://madison.thewikies.com/html5test/ |
| 16:32 | <webben> | Am I right in thinking hsivonen's HTML5 parser is part of Fx nightly now? |
| 16:32 | <TabAtkins> | I think so. |
| 16:33 | webben | was trying to experiment with meeting WCAG2 requirements with figure and details, but was getting stuck on the bad support for "legend" in just about everything. |
| 16:33 | <TabAtkins> | JonathanNeal: Let me see if I can go make a static version of one of my most recent intranet apps that I used html5 on. |
| 16:35 | <jgraham> | webben: Set html5.enable to true in about:config |
| 16:36 | <webben> | jgraham: ta |
| 16:37 | <TabAtkins> | JonathanNeal: http://www.xanthir.com/etc/html5-example.html |
| 16:37 | <nvartolomei> | why we need to close script tag if he has src? :-) why not if script tag has src specified we can close it as img tag |
| 16:37 | <TabAtkins> | I *think* all of my uses are right. |
| 16:38 | <TabAtkins> | nvartolomei: Because changing it would make your page disappear in legacy browsers, as they vainly search for a closing tag and instead just treat the entire page as the contents of the <script> block. |
| 16:39 | <JonathanNeal> | TabAtkins, your outline shows a few untitled sections but you validate. |
| 16:40 | <TabAtkins> | Well, not quite. I'm exposing <style> in the <body>. |
| 16:41 | <JonathanNeal> | You still validated. |
| 16:41 | <TabAtkins> | Using what validator? |
| 16:43 | <JonathanNeal> | http://html5.validator.nu/ |
| 16:43 | <TabAtkins> | Yeah, I get an error there - it's complaining about my second <style> block |
| 16:45 | <JonathanNeal> | That's funny 'cause it reports validity to me :-P |
| 16:47 | <TabAtkins> | How... strange. |
| 16:47 | <JonathanNeal> | I'm still miffed about the recommended usage of h1-6 tags within all articles / sections, especially when the h# resets itself. You end up with http://pastie.org/585996 |
| 16:48 | <JonathanNeal> | TabAtkins, ha, it was reporting validity because I was giving it the outerliner page outling your url |
| 16:48 | <TabAtkins> | Hehe. |
| 16:48 | <TabAtkins> | Hmm, what do you mean about the recommend h1-6 usage? |
| 16:49 | <JonathanNeal> | Well @ http://pastie.org/585999 I have three h1 tags. |
| 16:50 | <TabAtkins> | Yeah? |
| 16:50 | <JonathanNeal> | Because I was told that <section> elements should reset the # on h#. |
| 16:50 | <TabAtkins> | Essentially, yeah. They 'scope' <hn> elements, at least, so you can use <h1> without fear of it clobbering your outline. |
| 16:51 | <TabAtkins> | Is there a problem with that? |
| 16:52 | <JonathanNeal> | Is there documentation specifically on how h elements are scoped? |
| 16:52 | <JonathanNeal> | They seem to be scoped on article, nav, and section elements. |
| 16:52 | <TabAtkins> | They're scoped on "sectioning elements". |
| 16:53 | <TabAtkins> | Which is precisely those that you mentioned, I believe. |
| 16:54 | <JonathanNeal> | Docs that describe this? |
| 16:54 | <TabAtkins> | One sec... |
| 16:54 | <JonathanNeal> | particularly how to use this |
| 16:54 | <JonathanNeal> | In my drafts I try to back everything up with docs. |
| 16:55 | <TabAtkins> | http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#sectioning-content |
| 16:55 | <TabAtkins> | <aside> is also on the list. |
| 17:02 | <JonathanNeal> | So --- "article", "aside", "nav", (and) "section" (elements may have) a heading and an outline (and redefine) the scope of headings and footers. |
| 17:02 | <TabAtkins> | Yes. |
| 17:03 | <JonathanNeal> | However, look @ http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#sectioning-root |
| 17:05 | <TabAtkins> | Ah, right, good catch. Those four elements also scope headings, they just don't contribute to their parent's outline. |
| 17:05 | <JonathanNeal> | And they do say "Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level." |
| 17:06 | <TabAtkins> | Yup. |
| 17:06 | <TabAtkins> | Just because it's confusing to mix them up, even if technically produces a correct outline. |
| 17:06 | <JonathanNeal> | So, while that first example is okay, it would have been better to use an h1 element inside the section element? |
| 17:08 | <TabAtkins> | Slightly better, if only to make things simple. |
| 17:08 | <TabAtkins> | (Ian writes the spec examples in several styles on purpose.) |
| 17:08 | <JonathanNeal> | Does anyone know if / how this affects Google's page crawling? |
| 17:10 | <TabAtkins> | I dunno. :/ |
| 17:10 | gsnedders | guesses Hixie does, and he probably can't say |
| 17:10 | <JonathanNeal> | Got it. Well, I'll be back after I make the drive to work. |
| 17:12 | <TabAtkins> | That's one of those things that really *does* need to be made public, though. There's SEO folk wisdom that using too many <h1>s causes google to downrank you. |
| 17:13 | <TabAtkins> | Hixie: Do you know anything about the effects on Google ranking of switching to using only <h1>s? And can you say anything about it? |
| 17:14 | <TabAtkins> | Details aren't all that important, just a yes/no to "Does that hurt us?" |
| 17:16 | <miketaylr> | TabAtkins: I recall seeing this video from the Google Webmaster Central Channel...http://www.viget.com/inspire/ending-the-great-h1-debate/ |
| 17:16 | <miketaylr> | but I find the answer somewhat ambiguous |
| 17:17 | <TabAtkins> | Yeah, that's useful, but not useful *enough*. |
| 17:17 | <miketaylr> | I agree. |
| 17:17 | <TabAtkins> | 'cause the html5 advice *is* to use <h1> all over the page. |
| 17:18 | <TabAtkins> | Thanks for that, though. It didn't show up in my search. |
| 17:18 | <miketaylr> | np |
| 18:20 | <JonathanNeal> | Hello again |
| 18:27 | <nvartolomei> | hello |
| 18:27 | <TabAtkins> | Yo. |
| 18:42 | <JonathanNeal> | How do you folks feel about this? Is this proper HTML5 usage? |
| 18:47 | <TabAtkins> | JonathanNeal: Did you mean to post a link? |
| 18:54 | <JonathanNeal> | TabAtkins, haha, yes I did. |
| 18:55 | <JonathanNeal> | Here are my drafts @ http://pastebin.com/d68b7ab26 and http://pastebin.com/d5b0e8900 and the example page is @ http://madison.thewikies.com/html5test/ |
| 18:57 | <TabAtkins> | bbs - wife is calling me for lunch |
| 19:08 | <jablko> | where can i find discussion of nesting <form> elements in html5 vs html4? |
| 19:08 | <jablko> | am having trouble finding a link... |
| 19:14 | <JonathanNeal> | jablko, I wouldn't know for sure, but perhaps @ http://www.w3.org/TR/html5-diff/ ? |
| 19:15 | <JonathanNeal> | And then also @ http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html |
| 19:20 | <jablko> | JonathanNeal: thanks - i looked in those places without success |
| 19:52 | <smedero> | jablko: do you mean nesting a <form> inside another <form> element? or do you mean nesting elements like <input>, <select>, <textarea>, <button>, etc inside a <form>? |
| 19:53 | <jablko> | smedero: nesting a <form> inside another <form> element |
| 19:56 | <smedero> | http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-form-element |
| 19:56 | <smedero> | Content model: |
| 19:56 | <smedero> | Flow content, but with no form element descendants. |
| 19:57 | <smedero> | HTML 3, 4 and XHTML 1 I think also explicitly said something about such constructions not being valid. I have _zero_ idea about UA support. |
| 19:58 | <jablko> | huh - i thought a difference between html 4 and 5 was 5 allowed nested <form> elements... |
| 19:59 | <Dashiva> | Not <form> elements, but you can have form element elements (heh) outside the form element they belong to |
| 19:59 | <smedero> | I suppose you could use the new @form |
| 19:59 | <smedero> | http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#attr-fae-form |
| 20:01 | <jablko> | http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#association-of-controls-and-forms |
| 20:01 | <jablko> | A form-associated element is, by default, associated with its nearest ancestor form element (as described below), but may have a form attribute specified to override this. |
| 20:02 | <jablko> | mistook that to mean there could be multiple ancestor form elments |
| 20:24 | <annevk2> | shepazu, why not focus on DOM3Events? isn't that in much more need of maintenance than <canvas>? |
| 20:24 | gsnedders | wonders what he could do to do more maths this year |
| 20:24 | <annevk2> | shepazu, I mean, of the things that delay HTML5 I think DOM3Events would come first |
| 20:38 | <annevk2> | anything interesting happened today btw? |
| 20:38 | annevk2 | was travelling for most of it |
| 20:42 | <Hixie> | today only just started |
| 20:43 | <annevk2> | you self-centered twat :p |
| 20:46 | <Hixie> | ojan: ok my plan is to remove UndoManager, leave everything else that's in the spec in the spec, and add no new features for now regarding editing |
| 20:46 | <Hixie> | ojan: if julie sends me info, i'll integrate it when i get it |
| 20:53 | <annevk2> | Hixie, made a little bit progress on figuring out something better btw |
| 20:53 | <annevk2> | Hixie, for encodings |
| 20:53 | <Hixie> | cool |
| 20:53 | <gsnedders> | Hixie: My advice, FWIW, in the short term, would be to revert the change to UTS22 |
| 20:54 | <annevk2> | what did it say before? |
| 20:55 | <ojan> | Hixie: yeah, UndoManager would need some work. the info from julie will likely include recommended new execcommands, but otherwise will just be a documentation of what current word processors do with recommendations for what should be done. |
| 20:56 | <annevk2> | gsnedders, no, what it said before is wrong too |
| 20:57 | <gsnedders> | annevk2: But is it not closer? |
| 20:57 | <annevk2> | gsnedders, no |
| 20:57 | <annevk2> | gsnedders, it's more or less the same |
| 20:57 | <annevk2> | it said to ignore all whitespace and punctuation characters in ASCII |
| 20:57 | <annevk2> | which is wrong |
| 20:58 | <annevk2> | likely, only whitespace needs to be trimmed at the start and end, and it needs to be compared in an ASCII case-insensitive manner |
| 21:00 | <ojan> | Hixie: I think what's there now is fine. Eventually, I don't think the behavior of the execCommands should be UA dependent though, at least not as much as is currently UA dependent. |
| 21:00 | <annevk2> | yeah, it's nearly useless :( |
| 21:34 | <gsnedders> | gah. I needz advice. I fail at life. |
| 21:37 | <krijnh> | Sup? |
| 21:39 | annevk2 | suggests buying a t-shirt: http://store.theonion.com/get-il-p-139.html |
| 21:39 | <annevk2> | so sad that the "horses deserve better" t-shirt is gone |
| 21:40 | <Dashiva> | The right to bear arms |
| 21:41 | annevk2 | is considering http://store.theonion.com/good-day-to-go-sailing,-if-youre-a-dick-new-p-1025.html |
| 21:43 | gsnedders | needs advice from people who aren't about to run away, dammit :P |
| 21:43 | <krijnh> | Hrhr |
| 21:43 | <krijnh> | O:) |
| 21:44 | gsnedders | slaps krijnh |
| 21:44 | <gsnedders> | krijnh: Either go away, or I will take advantage of you being here :P |
| 21:44 | <annevk2> | if krijnh runs away we're all in trouble |
| 21:44 | <annevk2> | or at least our evil log readers are |
| 21:45 | <Dashiva> | Nah, we can always feed him backups later |
| 21:45 | <gsnedders> | He eats them like PMS eats specs. |
| 21:45 | <annevk2> | what's up with "him", I'm talking plural here |
| 21:46 | <Dashiva> | Him as in krijnh |
| 21:46 | <Dashiva> | Or is krijnh another one of those trap names you have in Holland? Is krijnh female? |
| 21:46 | <annevk2> | yeah |
| 21:47 | <krijnh> | o_O |
| 21:47 | <annevk2> | indeed, you did not _know_? o_O |
| 21:47 | <annevk2> | make that /know/ |
| 21:47 | <Dashiva> | "know" |
| 21:47 | <annevk2> | god I /hate/ that /syntax/ in /emails/ |
| 21:48 | <gsnedders> | /awww/ |
| 21:48 | <Dashiva> | /why are you writing regular expressions/ |
| 21:48 | <gsnedders> | Not enough slashes for that! |
| 21:48 | <Dashiva> | You only need two |
| 21:51 | <TabAtkins> | So what's this fail-at-life advice? |
| 21:51 | <gsnedders> | Sex, drugs, rock and roll. |
| 21:53 | <TabAtkins> | Isn't that how to win at life? |
| 21:53 | <gsnedders> | (More seriously, it's just gsnedders-is-a-totally-hopeless-romantic-and-fails-at-doing-anything) |
| 21:54 | <krijnh> | So that's how you get to work at Opera, hmm |
| 21:54 | <krijnh> | :o) |
| 21:54 | <ezyang> | Rock drugs. Sex roll. |
| 21:54 | <gsnedders> | krijnh: Well in guarantees I won't end up running off on parental leave or anything like that |
| 21:54 | <gsnedders> | *it |
| 21:57 | <mpilgrim> | krijnh is female? |
| 21:57 | <mpilgrim> | i had no idea |
| 21:57 | <mpilgrim> | of course, i thought annevk2 was female for several years |
| 21:57 | <ezyang> | == |
| 21:57 | <mpilgrim> | does one cancel out the other? |
| 21:57 | <krijnh> | Oh noes |
| 21:57 | <gsnedders> | annevk2 is female, though |
| 21:58 | <krijnh> | mpilgrim: I'm not, btw :) |
| 21:58 | <ezyang> | http://annevankesteren.nl/about |
| 21:58 | <krijnh> | http://krijnhoetmer.nl/about |
| 21:58 | gsnedders | wonders who ezyang is pointing that out to |
| 21:58 | <krijnh> | There, enough spamming for today |
| 21:59 | <mpilgrim> | hmph |
| 21:59 | <mpilgrim> | do non-americans find american names this confusing? |
| 21:59 | <krijnh> | No |
| 21:59 | <gsnedders> | mpilgrim: Americans merely find use of rare names confusing |
| 21:59 | <annevk2> | that's not really fair |
| 22:00 | <annevk2> | there's too much american movies everywhere |
| 22:00 | <gsnedders> | I mean, is snedders male or female? |
| 22:00 | <gsnedders> | (Oh, wait, I'm on the intarwebs, so I must be male) |
| 22:00 | <annevk2> | pretty dominant "culture" in general actually |
| 22:00 | <krijnh> | annevk2: still people confuse pilgrim with something like pigrim :) |
| 22:01 | <krijnh> | Perhaps due to those movies, but still |
| 22:01 | <TabAtkins> | gsnedders: Not quite. I found "anne" confusing, precisely *because* it's a common name over here, but pretty much solely for females. |
| 22:01 | <gsnedders> | TabAtkins: It's rare as a male name, though… which means it is a rare name :P |
| 22:01 | <TabAtkins> | Bah, okay. |
| 22:02 | <mpilgrim> | you'd be amazed how often people misspell "pilgrim" |
| 22:02 | <krijnh> | Anyway, I have the most non-international name ever |
| 22:02 | <jcranmer> | you'd be amazed how many people misspell "Cranmer" |
| 22:02 | <jcranmer> | it's a 100% phonetic name! |
| 22:02 | <gsnedders> | You'd be amazed how many people misspell "Geoffrey" |
| 22:03 | <annevk2> | krijnh, hmm, I'd like to compete |
| 22:03 | <jcranmer> | I ask people which spelling they use when I get that name |
| 22:03 | <krijnh> | Both ij and oe are hell for others :/ |
| 22:03 | <TabAtkins> | I really wouldn't, gsnedders. It's confusingly spelled. |
| 22:03 | <krijnh> | annevk2: accepted |
| 22:03 | gsnedders | wishes he had a cool name, like Anna |
| 22:03 | <Dashiva> | You'd be surprised how many people misspell "misspell" |
| 22:04 | <JonathanNeal> | they messpill it? |
| 22:04 | <mpilgrim> | irc should add a little "male" and "female" icon next to your nick |
| 22:04 | <ezyang> | "You'd be surprised how many mispell 'mispell'." :-P |
| 22:04 | <gsnedders> | mpilgrim: and we need an evil bit too |
| 22:04 | <TabAtkins> | The ss looks wrong. ^_^ |
| 22:04 | <ezyang> | pharoah and rhythm always get me |
| 22:04 | <mpilgrim> | but i suppose someone would complain that that discriminated against hermaphrodites |
| 22:04 | <gsnedders> | It's long soft sensual "s" letters |
| 22:04 | <ezyang> | mpilgrim: you could put both... |
| 22:04 | <ezyang> | And I bet there's a Unicode character for it too |
| 22:05 | <gsnedders> | mpilgrim: What about transgendered people? |
| 22:05 | <Dashiva> | What about AIs? |
| 22:05 | <ezyang> | UNICODE IS THE ANSWER |
| 22:05 | <gsnedders> | ezyang: In what encoding, and what normalization form? |
| 22:05 | <TabAtkins> | Unicode has a non-gendered artificial entity gender symbol? |
| 22:06 | <ezyang> | If it doesn't, we should submit a request for one to be put in |
| 22:06 | <TabAtkins> | We'll write the request together. |
| 22:06 | <gsnedders> | Write alternating words. |
| 22:06 | <gsnedders> | Separately, so you don't know what the other one has written. |
| 22:07 | <annevk2> | gsnedders, UTF-8, NFC, doh |
| 22:07 | <krijnh> | annevk2: so when you're up to podcasting the WG calls, start by asking where some of the IRC logs are hosted ;) I'll be your first subscriber! |
| 22:07 | <Dashiva> | UTF-8 and UTF-16 discriminate against astral entities. |
| 22:08 | <krijnh> | Ow, where did this brain boiling topic come from? I'm out of here :) |
| 22:08 | <gsnedders> | krijnh: n00b |
| 22:08 | <Dashiva> | krijnh: It's your fault for being (not) female |
| 22:08 | <krijnh> | gsnedders: agreed |
| 22:08 | <TabAtkins> | http://en.wikipedia.org/wiki/Gender_symbol |
| 22:09 | <ezyang> | Haha! |
| 22:09 | <ezyang> | Excellent. |
| 22:09 | <krijnh> | gsnedders: I'm just a simple web author, no ambitions to work for a browser vendor :) |
| 22:09 | <TabAtkins> | Damns, IRC doesn't let you use all of unicode in nicks... |
| 22:09 | <gsnedders> | krijnh: Gah. Browser vendors where it's at. |
| 22:09 | <Dashiva> | Most IRC servers don't even know what unicode is |
| 22:10 | <krijnh> | gsnedders: ow, yeah, I so envy you :) |
| 22:11 | <TabAtkins> | Hrm. There *is* an appropriate gender symbol for an AI. |
| 22:11 | <krijnh> | Well, nn |
| 22:12 | <Dashiva> | TabAtkins: Which one? All of them seem to imply humans. |
| 22:12 | <TabAtkins> | U+26AA |
| 22:13 | <Dashiva> | That's a MEDIUM WHITE CIRCLE |
| 22:13 | <TabAtkins> | Yeah? |
| 22:13 | <TabAtkins> | Also, apparently, a gender symbol. |
| 22:13 | <Dashiva> | For humans |
| 22:13 | <TabAtkins> | I see no such restriction. |
| 22:14 | <Dashiva> | It's implied |
| 22:14 | <Dashiva> | It's like using 'he' as a gender neutral pronoun. |
| 22:14 | <gsnedders> | Singular they, dammit! |
| 22:14 | <TabAtkins> | No such thing. Those gender symbols are all perfectly fine for other lifeforms. |
| 22:15 | <TabAtkins> | Artificial lifeforms count. |
| 22:15 | <Dashiva> | Now you're being lifeist |
| 22:15 | <TabAtkins> | Unless you're saying that you can't use the male symbol for, say, a male rabbit? |
| 22:16 | <Dashiva> | What if the AI doesn't consider itself a life form? |
| 22:16 | <TabAtkins> | Yup, I'm lifeist. I'd like to see non-life say anything to me about it. |
| 22:16 | <Dashiva> | You will be first up against the wall when skynet comes |
| 22:17 | <Hixie> | ojan: yeah, but that will depend on your general operations] |
| 22:17 | <TabAtkins> | Pfft, Skynet's still alive. |
| 22:17 | <Hixie> | s/]// |
| 22:17 | <Hixie> | gsnedders: any idea what revision that was? |
| 22:17 | <gsnedders> | Hixie: no |
| 22:17 | <gsnedders> | :D |
| 22:17 | <gsnedders> | Hixie: If annevk2 says it was no better, then don't bother. |
| 22:18 | <gsnedders> | Hixie: He's done more looking into it, so I trust he's right saying there's no point |
| 22:18 | <TabAtkins> | Hixie: Any option of getting a response from Google's search team on the SEO implications of HTML5's recommended advice of using <h1> exclusively on pages? |
| 22:18 | <Hixie> | TabAtkins: i'll ask around |
| 22:19 | <TabAtkins> | Cool. |
| 23:22 | <JonathanNeal> | TabAtkins, good question. |
| 23:23 | <JonathanNeal> | I was curious to know how the constant possible usage of h1 tags might muck things up :-) |
| 23:28 | <JonathanNeal> | I figured that we just have to try it, anything else would be google giving away search info. |
| 23:40 | <annevk2> | Hixie, you should replace lines such as "Objects implementing the ApplicationCache interface must also implement the EventTarget interface." with "ApplicationCache implements EventTarget;" in the IDL |
| 23:41 | <Hixie> | can you file a bug? |
| 23:41 | <Hixie> | just paste the above into the text box |
| 23:41 | <Hixie> | on the spec |
| 23:41 | <Hixie> | and hit the button |
| 23:41 | <Hixie> | :-) |
| 23:41 | <Hixie> | after clicking the relevant section |
| 23:42 | <annevk2> | done |
| 23:42 | <annevk2> | it still annoys me the text is not cleared btw |
| 23:42 | <Hixie> | thanks |
| 23:42 | <Hixie> | if the text cleared, it would have made my life hell when i filed the 60 or so identical bugs recently |
| 23:42 | <Hixie> | let me know once you've filed more than 60 different bugs in a row :-) |
| 23:43 | <annevk2> | hmm |
| 23:44 | <vvv> | Hixie: is <input type=url> supposed to be an absolute IRI (as 4.10.4 says) or an absolute URL (as it's said everywhere else)? |
| 23:44 | <Hixie> | what's the difference? |
| 23:45 | <vvv> | So there's no difference? |
| 23:45 | <annevk2> | "add examples here" haha |
| 23:45 | <Hixie> | vvv: there is a minor difference, but since you're asking which it is, i was wondering what you thought the difference was :-) |
| 23:46 | <vvv> | Hixie: no, I just noticed the inconsistence |
| 23:46 | <Hixie> | vvv: (the minor difference is related to what is allowed in the query component of the string in documents whose character encoding is not UTF-8) |
| 23:46 | <Hixie> | vvv: the one that says "IRI" is non-normative, so it's trying to explain what's expected |
| 23:47 | <annevk2> | is that really a difference? for an absolute URL I would assume that would be normalized to percent-encoded stuff which makes it a valid IRI |
| 23:47 | <Hixie> | vvv: the one that says "valid absolute URL" is normative, and it has to handle the weird edge cases |
| 23:47 | <Hixie> | annevk2: URL in HTML5 currently is a superset of IRI |
| 23:47 | <Hixie> | annevk2: i'm waiting for the IRI spec to fix the definition of IRI so i can just use "IRI" |
| 23:47 | <annevk2> | Hixie, but input type=url is about submission |
| 23:47 | <annevk2> | hmm |
| 23:48 | <Hixie> | yes? |
| 23:48 | <annevk2> | so a) what is submitted can always be a valid IRI and b) we could even make it always UTF-8 |
| 23:48 | <annevk2> | b) would make a lot of sense for an IRI value to be honest |
| 23:49 | <annevk2> | though supposedly it might get mangled by the form encoding hmm |
| 23:49 | <annevk2> | rather than the document encoding |
| 23:49 | <annevk2> | maybe URI would be simpler :) |
| 23:50 | <Hixie> | no doubt it would be simpler |
| 23:50 | <Hixie> | it's a "valid absolute URL" because that's what it has to be for the value="" attribute |
| 23:51 | <Hixie> | and i don't want to end up in the very confusing situation of what is allowed in value="" and what is allowed in .value being different |
| 23:52 | <annevk2> | but you could force the encoding flag |
| 23:52 | <Hixie> | how do you mena? |
| 23:52 | <annevk2> | that value is always parsed with HREF-charset set to UTF-8 |
| 23:52 | <annevk2> | though if accept-charset is not some Unicode thingie it might get lost anyway |
| 23:53 | <Hixie> | the value is parsed by the html parser, unless i'm very confused |
| 23:53 | <Hixie> | i really don't understand what you're proposing |
| 23:54 | <annevk2> | if you set href dynamically it isn't, but I suppose it doesn't really matter |
| 23:54 | <annevk2> | people should just use UTF-8 |
| 23:54 | <Hixie> | what is href in this context? |
| 23:55 | <annevk2> | s/href/the value attribute/ |
| 23:56 | <Hixie> | k... i guess if you think something should change, file a bug :-) |
| 23:56 | <Hixie> | and explain why it should change |
| 23:56 | <Hixie> | :-) |
| 23:57 | <annevk2> | i thought there was an issue for a while if you have accept-charset set to iso-8859-1 or something, but then realized that it wouldn't be a new problem |
| 23:57 | <Hixie> | k |
| 23:58 | <annevk2> | but clearly, I should get some sleep :) |
| 23:58 | <annevk2> | nn |
| 23:58 | <Hixie> | nn |
