| 00:02 | <Lachy> | if you need any help with it, read this forum thread http://hymn-project.org/forums/viewtopic.php?t=2494 and the FAQ http://hymn-project.org/forums/viewtopic.php?t=2615 |
| 05:31 | <Hixie> | heh maybe we should adopt role="" for <img> just to make it harder to adopt over the role spec should anyone propose we do that later :-P |
| 12:45 | <hsivonen> | hmm. I think either my parser or Jing has a memory leak... |
| 16:10 | <Dashiva> | I see nothing has changed on public-html today either |
| 16:10 | <gsnedders> | Change is over-rated. |
| 16:11 | <hsivonen> | I hope Change Congress doesn't depend on RDF |
| 18:55 | <gsnedders> | jgraham: Nice email :) |
| 18:55 | <gsnedders> | jgraham: (your latest on public-html) |
| 18:57 | <Philip`> | Nicer if it didn't end with a paragraph saying "I" and look like it was sent prematurely :-) |
| 18:57 | <gsnedders> | That's true :) |
| 18:58 | <jgraham> | Philip`: I just noticed that. I wonder what I was going to write there |
| 19:00 | <jgraham> | I wasn't sure if I had made my point clearly so I kept it as a draft for a while. Then I realised that I may as well just send it |
| 19:22 | webben_ | is still keen on seeing a clear explanation of what the goal of HTML5 conformance is beyond weakly protecting future extension points. (The main purpose of HTML 4.01 conformance seems to have been a common core of interoperability.) |
| 19:25 | <Philip`> | webben_: Do you mean UA conformance, or author conformance, or both? |
| 19:25 | <webben_> | author conformance |
| 19:28 | <jgraham> | webben_: I think the goal is a) increasing interoperability (also in the face of future changes) b) discouraging things that are known to have bad cost/benefit |
| 19:29 | <jgraham> | But I admit I find it hard to pin down in simple terms |
| 19:29 | <webben_> | jgraham: a) is the same as protecting future extension points, or more than that? |
| 19:29 | <jgraham> | webben_: a) is also about working with existing UAs |
| 19:30 | <webben_> | hmm |
| 19:30 | <webben_> | I see. |
| 19:31 | <webben_> | so preferring features that work with Internet Explorer over features that don't? |
| 19:32 | <webben_> | roughly speaking |
| 19:32 | <webben_> | *equivalents that don't |
| 19:33 | <webben_> | Why do things that have bad cost/benefit ratios need to be discouraged by conformance rules? |
| 19:33 | <webben_> | assume it's not an interoperability issue |
| 19:33 | <webben_> | *assuming |
| 19:34 | <Philip`> | Perhaps so that validators will alert authors when they make a mistake and do those bad cost/benefit things |
| 19:34 | <jgraham> | (for an example of b, discouraging presentational markup seems to be one of the goals of HTML5 conformance yet, for an author aware of the issues presentational markup need not have an adverse effect. It's just that sometimes it's easier to say "don't play with guns" than to stand by and watch people blow their own feet off) |
| 19:35 | <webben_> | so the cost/benefit ratio changes from one authoring situation to another? |
| 19:35 | <webben_> | but the conformance should be geared to help newbie authors? |
| 19:37 | <jgraham> | webben_: Not necessarily just things that work in IE. Consider an attribute that takes a date. It's good for consistency and readability if everyone adopts the same syntax without relying on the funky parsing that browsers have to do; allowing any random string that could be converted into a date would have no benefits |
| 19:37 | <jgraham> | So sometimes it's about reducing choice |
| 19:38 | <jgraham> | (which is usually a good thing as long as you're not taking away functionality. indeed it often is if you are) |
| 19:38 | <webben_> | jgraham: Sounds very much like the arguments for requiring attributes to be quoted. |
| 19:39 | <jgraham> | webben_: Sure. I don't think those arguments are unreasonable. OTOH, I don't think they're necessarily strong enough to warrant making the change |
| 19:40 | <jgraham> | I guess if there was a lot of evidence of authors doing the wrong thing because they weren't quoting attributes, it would be a good change |
| 19:40 | <webben_> | jgraham: you mean because there's a counterbalancing benefit (slightly fewer bytes/less typing)? |
| 19:40 | <jgraham> | webben_: Yeas |
| 19:41 | <jgraham> | s/Yeas/Yeah/ :) |
| 19:41 | <Philip`> | jgraham: There is evidence - see <meta charset>, and the very common garbage attributes that come from unquoted keyword/description strings |
| 19:42 | <webben_> | isn't there a danger in making validators throw errors over mere consistency and readability? |
| 19:42 | <webben_> | (in that it becomes, perhaps, harder to migrate old content and maintain new conforming content, given common authoring practices atm) |
| 19:43 | <webben_> | to put it another way, is it a problem to lump in "stuff that arguably makes HTML maintenance harder" with stuff that harms end-users? |
| 19:43 | <jgraham> | Who gains if the date 2008-08-23 can also be conformingly written aa2008--08:23--? |
| 19:44 | <webben_> | in the same category of error. |
| 19:44 | <jgraham> | (I have no idea if that would parse in HTML5 btw; it was random :) ) |
| 19:44 | <gsnedders> | jgraham: No, it wouldn't. |
| 19:44 | <webben_> | jgraham: If browsers /can/ parse that, anyone whose code already relies on it. |
| 19:45 | <jgraham> | webben_: I think you are underestimating the value of consistency and readability |
| 19:46 | <jgraham> | Also some things have knock on consequences |
| 19:46 | <webben_> | Just to be clear, I like consistency and readability and prefer to follow coding conventions in my own work. |
| 19:46 | <webben_> | I'm just trying to tease out the aims of conformance and validity here. |
| 19:46 | <webben_> | and whether they really make sense. |
| 19:47 | <webben_> | both in terms of end-goals and in terms of author psychology/pressures. |
| 19:48 | <jgraham> | e.g. people who have systems that depend on presentational markup are probably making their users' experience worse (usually slower to download, no caching, harder to adapt the style to different media, harder to restyle on the client side, harder to extract information from programmatically) |
| 19:48 | <jgraham> | So making those systems non conforming can be a win |
| 19:48 | <jgraham> | even thoough in the short term the author losees out |
| 19:57 | <Dashiva> | Related question: Is conformance a carrot or a stick? |
| 19:59 | <gsnedders> | Dashiva: A pineapple. |
| 20:00 | <Dashiva> | I'm not familiar with that metaphor |
| 20:00 | <gsnedders> | Nor am I. |
| 20:01 | Dashiva | fills gsnedders' tub with glow-in-the-dark hubcaps |
| 20:01 | <jgraham> | Dashiva: It's an organic carrot, an non conforming web page is a non-organic carrot, and there is no stick. |
| 20:01 | <gsnedders> | Ooooo! Glow-in-the-dark hubcaps! Awesome! |
| 20:03 | <jgraham> | (by organic, I mean grown to organic food standards without pesticides and so on, not "made from organic molecules") |
| 20:04 | <Dashiva> | jgraham: Sure, okay. But I was talking about the concept of conformance, not a specific page. :) |
| 20:06 | <jgraham> | Dashiva: My point was that the concept of conformance is similar to the difference between an organic and a non-organic carrot |
| 20:06 | <jgraham> | Functionally either will work as a carrot |
| 20:06 | <Dashiva> | Yeah, I got that |
| 20:07 | <Dashiva> | But I'm asking if conformance is something we offer, or something we deny. |
| 20:35 | <jgraham> | Dashiva: In practice it is only something we offer |
| 20:36 | <Dashiva> | jgraham: But we'd rather it be something to deny? |
| 20:44 | <jgraham> | Dashiva: I don't think so. But I'm not quite sure what "deny" means. I understood carrot and stick. |
| 20:47 | <jgraham> | (obviously I know what "deny" means. but I don't understand what the difference between allow and deny in this context is. I was assuming allow == carrot deny == stick) |
| 20:48 | <Dashiva> | "Congratulations, you get to call yourself conforming." vs "You have failed us, so we will label you as a failure." |
| 20:49 | <gsnedders> | EPIC FAIL. |
| 20:52 | <jgraham> | Dashiva: I think the answer is "none of the above" |
| 20:53 | <jgraham> | But offer is much closer because you have to choose to test yourself for conformance |
| 20:54 | <jgraham> | We don't come round, check conformance and go "sorry you don't conform we're shutting you down" |
| 20:54 | <Dashiva> | Except if you're Target |
| 20:55 | gsnedders | shoots an arrow |
| 20:55 | <jgraham> | Dashiva: That was failing to comply with a11y legislation, not faliure to comply with HTML |
| 20:55 | <jgraham> | HTML could have said nothing about alt and they still could have been sued if blind users couldn't use their site |
| 20:56 | <jgraham> | (I guess XML does go "you don't conform we're shutting you down" but that's a huge mistake) |
| 20:57 | <Dashiva> | heh |
| 20:59 | gsnedders | shuts jgraham down for not conforming to Man 1.0, requirement 3B: MUST have short hair. |
| 21:04 | <benoitc> | hi |
| 21:06 | <jgraham> | benoitc: Hi |
| 21:06 | <webben_> | jgraham: "people who have systems that depend on presentational markup are probably making their users' experience worse (usually slower to download, no caching, harder to adapt the style to different media, harder to restyle on the client side, harder to extract information from programmatically)" ... absolutely, but those are all side issues to readability/consistency. |
| 21:07 | <krijnh> | jgraham: wouldn't your points remain the same for http://juicystudio.com/wcag/tables/complexdatatable.html ? |
| 21:07 | <jgraham> | krijnh: I hope so, otherwise I'm going to have it pointed out to me in excrutiating detail just how idiotic I am :) |
| 21:07 | <krijnh> | (I would also markup those <td class="header"> as <th>'s) |
| 21:09 | <krijnh> | http://lists.w3.org/Archives/Public/public-html/2008Aug/0633.html |
| 21:09 | <jgraham> | webben_: I agree. I guess those are examples of conformance requirements designed to make end user's lives better by increasing the probability the the author does the thing that works best for the user |
| 21:09 | <jgraham> | krijnh: I replied |
| 21:10 | <krijnh> | That example has way too complex markup, for such a simple table, imho |
| 21:11 | <jgraham> | krijnh: Seriously |
| 21:12 | <krijnh> | Yeah :) |
| 21:12 | <jgraham> | :) |
| 21:13 | <krijnh> | <td id="col8-2a">Budgeted</td> is interesting though |
| 21:13 | <krijnh> | Should <th scope="row">Budgeted</th> work on that? |
| 21:17 | <benoitc> | mmm what is the current status of web forms 2 ? I just saw that dev of http://code.google.com/p/webforms2/ has been suspended |
| 21:17 | <jgraham> | krijnh: See http://tinyurl.com/624mko for my take on how it should work. That has just <th>Budgeted</th> (no @scope) |
| 21:17 | <benoitc> | i would like to make my website in html5 if possible so I don'tt know if it's better to use current forms standard or trying web forms 2 ? |
| 21:18 | <webben_> | benoitc: well, WF2 is designed to degrade gracefully. |
| 21:18 | <webben_> | (not that it necessarily achieves that 100%) |
| 21:18 | <jgraham> | benoitc: WF2 will be merged into HTML5 soon (the forms task force kind of died) |
| 21:18 | <jgraham> | Only Opera has any support atm though |
| 21:18 | <gsnedders> | It never came into life. |
| 21:19 | <Lachy> | LOL, Google translate is broken. I translated a page with a price list on it, and it chagned "NOK" to "U.S. $", but left the value unchanged. |
| 21:19 | <webben_> | benoitc: If you're going to try and conform to the changing requirements of HTML5, you'd want to use web forms 2. |
| 21:19 | <krijnh> | jgraham: cool! |
| 21:20 | <benoitc> | webben_: ok thanks |
| 21:20 | <benoitc> | this lib is the only one to do it or ther is another ? I found one on sf |
| 21:21 | <webben_> | benoitc: Using a library isn't the same as using web forms 2. |
| 21:21 | <webben_> | benoitc: you can use web forms 2 without using a library |
| 21:21 | <webben_> | like I said, it's designed to degrade gracefully |
| 21:22 | <krijnh> | jgraham: can your tool also show the inspected html source? |
| 21:22 | <webben_> | benoitc: all a library would do is try to provide the same functionality as a wf2 implementation when js is available. |
| 21:22 | <Philip`> | Lachy: I'd guess that's a danger of Google's apparent statistical model of translation, since it recognises when languages use different words for the same concept but fails to understand the more subtle differences in meanings, so it gets more false positives than a more human-based approach |
| 21:23 | <benoitc> | ok i see thanks |
| 21:23 | <benoitc> | will try to get further before coming with any question :) |
| 21:24 | <benoitc> | I would like to use any js lib to emulate behaviour off new features anyway |
| 21:27 | <jgraham> | krijnh: Not at the moment. |
| 21:28 | <krijnh> | jgraham: would be handy, imho |
| 21:28 | Philip` | was just about to ask precisely the same question, having failed to notice krijnh ask it |
| 21:28 | <jgraham> | Well it should be trivial to add but on the other hand I should be spending less time at the moment doing this not more :) |
| 21:28 | <krijnh> | Would also easily show "that we're able to markup data tables accessibly" |
| 21:29 | <krijnh> | Where "we" includes more people than with http://juicystudio.com/wcag/tables/complexdatatable.html |
| 21:29 | jgraham | should note the algorithm in the tool is not the same as the one in the spec |
| 21:29 | <krijnh> | I don't care |
| 21:29 | <jgraham> | (the one in the spec doesn't allow headers to have headers) |
| 21:30 | <krijnh> | Just show that it's possible, with whatever markup |
| 21:37 | Philip` | wonders how to be sure that the table headers algorithm isn't just overfitted to the finite number of examples it was designed for |
| 21:40 | <Hixie> | i looked at a few tables, distilled the requirements, designed the algorithm, then checked the algorithms on the remainder of ben's data tables |
| 21:40 | <Hixie> | and it seemed to work ok |