| 00:53 | hdh | votes for <m> staying, it makes more sense than strong i b em for highlighting blockquotes |
| 01:14 | <Lachy_> | hdh, where was there any discussion of removing <m>? |
| 01:14 | <hdh> | #the-m says so |
| 01:15 | <hdh> | "This section has a large number of outstanding comments and will likely be rewritten or removed from the spec." |
| 01:16 | <Lachy_> | nooo! It absolutely must stay |
| 01:16 | <hdh> | ai'ight, two votes :) |
| 13:56 | <annevk> | http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0409.html |
| 14:01 | <MikeSmith> | annevk - I commented over on #html-wg about your link pointing to XForms WG aiming at Turing completeness |
| 14:01 | <MikeSmith> | If all working groups were expected/required to working under the expectation that all major features of their specs should be explicitly mentioned in their charters, I wonder what the verdict would be on the XForms WG resolution to add a capability for user-defined functions. |
| 14:01 | <MikeSmith> | looking at the XForms charter, almost none of its actual features are mentioned in the scope section or anywhere else in that charter at all. |
| 14:02 | <annevk> | yeah, dunno |
| 14:03 | <annevk> | I thought part of the idea of XForms was that it was not turing complete so that you can "reason" about it or something |
| 14:13 | <MikeSmith> | annevk - I think it's great for it to evolve along to meet whatever is needed by the people who are actually using it or want to use it. But I think it would be hard for anybody to claim that the group's charter gives an accurate description of the scope of what XForms has evolved into or what they seem to be further evolving it into. |
| 14:14 | <MikeSmith> | If that charter were held to the same standard that some seem to expect the HTML WG charter to be held to, it would need to be a lot more explicit about particular features than it is now. |
| 16:27 | <gsnedders> | nice emails on http-wg |
| 16:27 | <gsnedders> | "Specifying behaviour for handling every conceivable error isn't possible" |
| 16:28 | <takkaria> | surely if you can conceive of an error then you can say how you should handle it? |
| 16:28 | <gsnedders> | takkaria: oh, you just define what happens for any possible next byte. |
| 16:28 | <gsnedders> | like HTML5 :P |
| 16:29 | <gsnedders> | But I must remember seeming I'm doing it for HTTP outwith the WG that it isn't possible. |
| 16:29 | <Philip`> | takkaria: I can conceive of every positive integer, but I can't necessarily say how every positive integer should be handled since they might each need different handling |
| 16:31 | <gsnedders> | I guess if it is infinite then you can't |
| 16:31 | <gsnedders> | (if you don't use a state machine) |
| 16:31 | <gsnedders> | (or something else that can run forever) |
| 16:35 | <Philip`> | If you're willing/able to define your error handling in a finite set of rules, then that's alright, but that's a special case and doesn't apply in general |
| 16:39 | <gsnedders> | for HTTP you can definitely define error handling, though not always for what is transmitted over it |
| 17:55 | <gsnedders> | Hixie: http://ln.hixie.ch/?start=1047614078&count=1 — a perfectly linear one which she climbs quicker and quicker? or maybe she gains mass? |
| 17:57 | <Philip`> | Or a mountain which is less steep near the summit, so you go faster and have larger momentum as you climb? |
| 17:59 | hdh | lol @ the twitter status |
| 18:01 | <gsnedders> | Philip`: but if it's steeper getting up to that less steep part, your average velocity would surely be lower? |
| 18:02 | <gsnedders> | because you'd waste so much time on the steep part |
| 18:02 | <Philip`> | gsnedders: Why is average velocity relevant? |
| 18:03 | <Philip`> | (Also, can I be pedantic and point out that average speed is more useful than average velocity, particularly if you're going up then back down the same side of the mountain?) |
| 18:04 | <gsnedders> | Philip`: momentum = mass * average velocity |
| 18:06 | <Philip`> | momentum = instantaneous mass * instantaneous velocity :-p |
| 18:06 | gsnedders | headdesks |
| 18:06 | <gsnedders> | that's true. |
| 18:07 | <gsnedders> | which means the fact it is velocity is irrelevant. |
| 18:08 | <Philip`> | That's relevant since it means momentum is a vector quantity |
| 18:08 | <gsnedders> | and of course we're comparing it |
| 18:10 | <Philip`> | We're implicitly considering the magnitude of it before comparing car vs mountain-climber, I guess |
| 18:11 | <gsnedders> | Philip`: but if it is less steep near the summit, surely she'd need to move really quickly to keep the momentum growing |
| 18:12 | <Philip`> | She could be going really slowly on the steep bits, and then just start moving slightly quicker as it becomes continually less steep - there's no need to ever go really quickly |
| 18:12 | <gsnedders> | but comparatively |
| 18:14 | <Philip`> | She should start off at 30 kg m s^-1 where it's really steep near the start, and then end up at 30.01 kg m s^-1 towards the end where it's much less steep, which would still be gaining momentum but wouldn't be comparatively really quick |
| 18:15 | <gsnedders> | but to compensate for the difference in direction? |
| 18:22 | <gsnedders> | I'm sure enough of us could come up with mad theories about how it works out :) |
| 22:23 | <Lachy__> | http://blog.fawny.org/2007/12/23/janefonda/ |
| 22:23 | <Lachy__> | That's more complaints about HTML5 accessibility issues |
| 22:28 | <takkaria> | that article is high on rhetoric and appeals to emotion using a bad analogy |
| 22:29 | <gsnedders> | oh, I've seen worse analogy. |
| 22:30 | <takkaria> | I don't believe I was disputing that. :) |
| 22:30 | <takkaria> | the last paragraph is amusing too |
| 22:30 | <takkaria> | all the bits of HTML4 and XHTML1 that don't work very well now will continue not working very well into the future. :) |
| 22:31 | <gsnedders> | For example: a potential divider is somehow related to a ladder coming out of water. |
| 22:35 | <csarven> | "benevolent dictator, Hixie, with Maciej as court jester" woah |
| 22:35 | <gsnedders> | well, Hixie is a benevolent dictator :P |
| 22:36 | csarven | wonders if he ever gives it a break with the complaints and bashing |
| 22:36 | gsnedders | takes a sausepan, and bashes csarven about over the head |
| 22:36 | <gsnedders> | sorry, I had to |
| 22:37 | <takkaria> | he says benevolent dictator as if it's a bad thing |
| 22:37 | <Philip`> | gsnedders: That doesn't make no sense - the (gravitational) potential difference between the top of the ladder and the water, and the water and the bottom of the ladder, is analogous to the electrical potential difference in the divider, e.g. the two differences add up to a constant but you can move things up and down within a certain range |
| 22:37 | <Philip`> | It's not an especially great analogy, since it doesn't give any insight into additional behaviours, but it's not like it's totally wrong :-) |
| 22:37 | <gsnedders> | Philip`: yeah, I did get it. |
| 22:38 | <gsnedders> | Philip`: But how my teacher explained it left me more confused than before he started. |
| 22:41 | <Philip`> | I liked the idea of coulomb beetles (charge) walking through pipes (circuits), with each beetle carrying a backpack with some number of Mars bars (voltage) of which some get removed when passing through components in the circuit |
| 22:44 | <ray> | better than a malevolent dictator |
| 22:44 | <gsnedders> | Philip`: that's nice |
| 23:02 | <othermaciej_> | csarven: who declared me court jester? that's kinda cool :-) |
| 23:03 | <gsnedders> | othermaciej_: http://blog.fawny.org/2007/12/23/janefonda/ |
| 23:03 | <gsnedders> | othermaciej_: not a good context :P |
| 23:04 | <othermaciej_> | dictators don't have jesters |
| 23:07 | <othermaciej> | wow, I'm part of the politburo |
| 23:09 | <takkaria> | oh, a bad metphor to complement the bad analogy :P |
| 23:09 | <othermaciej> | that was a pretty childish post |
| 23:10 | <othermaciej> | "add longdesc... for the children! the poor disabled children!" |
| 23:10 | <takkaria> | or they'll have to hack the system |
| 23:12 | <othermaciej> | Joe seems to think accessibility is too important to apply normal standards of evidence for what features are truly effective |
| 23:12 | <othermaciej> | I think it's too important *not* to |
| 23:12 | <Lachy_> | I didn't get the analogy Joe was trying to make using the story about the airline passenger in a wheelchair |
| 23:13 | <othermaciej> | he's trying to say that it's the working group's moral duty to do all required research to justify accessibility features |
| 23:13 | <othermaciej> | (perhaps unaware of how much detailed research has been done) |
| 23:13 | <Lachy_> | of course we do |
| 23:14 | <othermaciej> | (and perhaps assuming any research that doesn't justify every single one of HTML4.01's features that are "for accessibility" is prima facie invalid because the experts don't agree) |
| 23:15 | <Lachy_> | we need research to find out what accessibility features actually work and are benefitial to add or retain, not just automatically accept features because they are for accessibility, especially if those features don't actually work in practice |
| 23:19 | <gsnedders> | JAWS implements @longdesc, does it not? |
| 23:20 | <webben> | gsnedders: Both JAWS and Window-Eyes implement longdesc. |
| 23:20 | <webben> | gsnedders: As do add-ons for Firefox and IE. |
| 23:20 | <gsnedders> | webben: the latter is less important for accessibility alone, though, really |
| 23:21 | <webben> | gsnedders: I strongly disagree. If you're colorblind, you might well not use a screen reader but still need a longdesc. |
| 23:21 | <webben> | ditto with screen magnifier users |
| 23:21 | <gsnedders> | that's true |
| 23:22 | <webben> | Now I know that HAL doesn't support longdesc and neither does VoiceOver (there's no interface in WebKit; I lost my code which added one and haven't had time to recode it for submission, unfortunately). |
| 23:22 | <webben> | I don't know about the current situation with NVDA and Orca. |
| 23:23 | <othermaciej> | the main problems people have documented with longdesc are that the vast majority of longdesc attributes out there are wrong in various ways |
| 23:24 | <othermaciej> | so following longdesc whenever possible would be actively harmful to the user |
| 23:24 | <othermaciej> | some evidence was also presented that many blind users are unaware longdesc even exists |
| 23:25 | <webben> | Actually, I think a lot of that documentation shows longdesc being misinterpreted as a string value rather than a URI. |
| 23:25 | <othermaciej> | taken together that makes the feature seem somewhat unsuccessful in achieving its intended purpose |
| 23:25 | <webben> | Which means it can be used for error correction of alternative text where necessary. |
| 23:25 | <othermaciej> | I do not think that's the case |
| 23:26 | <othermaciej> | what Hixie found is that many longdescs are links to the image itself, links to the site's top-level page, 404s, irrelevant spam links, stuff like that |
| 23:26 | <webben> | The "blind users" being "unaware" is entirely down to the UI and documentation of assistive tech. (And in fact it's quite clearly documented.) Never mind we're talking about tiny sample sizes of people and a tiny sample of sites. |
| 23:27 | <webben> | othermaciej: A UA that presented a 404 as a longdesc would be a bit silly. |
| 23:27 | <gavin_> | presumably hixie search through his large web archive |
| 23:27 | <webben> | I don't think there's any element or attribute not misused by spammers. |
| 23:27 | <gavin_> | I wonder whether the people arguing for its inclusion care about "the web" |
| 23:27 | <gavin_> | rather than "the web they frequently use" |
| 23:28 | <webben> | I also pointed Hixie to various examples of longdesc used correctly. |
| 23:28 | <webben> | (real examples from government websites for example) |
| 23:29 | <webben> | I think arguing from what AT currently does is highly problematic, given how UAs are trying to hack around broken web content, itself highly determined by flaws in normal UAs. |
| 23:29 | <webben> | *given how ATs |
| 23:29 | <webben> | it's not a technical argument really. |
| 23:30 | <webben> | and in any case Window-Eyes and JAWS do in fact support it. |
| 23:31 | <othermaciej> | webben: well, you don't know it's gonna be a 404 until the user requests to follow it |
| 23:31 | <webben> | othermaciej: It's a longdesc not an anchor or form control. It should be safe for a HEAD request at least. |
| 23:32 | <othermaciej> | webben: I suppose you could pre-emptively load all longdesc contents to decide whether to even show the UI to the user, however, that's not what we do with normal hyperlinks |
| 23:32 | <othermaciej> | HEAD requests are not reliable |
| 23:32 | <othermaciej> | many servers out there give mismatched HEAD results |
| 23:33 | <takkaria> | from the research I did, I found one longdesc being used right in Philip's directory |
| 23:33 | <webben> | othermaciej: Well there's an argument for doing that for normal hyperlinks (preloading) ... particularly ones where alt is missing (image links). The main problem is the misuse of GET requests for destructive actions, although the RoR fiasco with web accelerator may have reduced that abuse. But I very much doubt the same problem exists at any significant scale with longdesc URIs. |
| 23:34 | <takkaria> | out of 62 pages that used longdesc |
| 23:34 | <webben> | takkaria: Yeah, I found more examples than "1". |
| 23:34 | <webben> | (not in Philip's directory, though) |
| 23:34 | <takkaria> | fair enough. if you cite government websites, though, then that's hardly regular usage |
| 23:36 | <othermaciej> | webben: most longdesc attributes do not point to longdesc-specific content, so I don't know if it would be materially different (other than the fact that longdesc in general is so rare) |
| 23:37 | <Lachy_> | Most of the good examples of long descriptions include a regular link, making longdesc redundant |
| 23:38 | <Lachy_> | and the information often includes information that would be useful for more than just those with assistive technology |
| 23:39 | <webben> | Lachy_: There's no reason why longdesc shouldn't be in primary UI. |
| 23:39 | <Lachy_> | the best solution I've seen for the longdesc issue is rel="longdesc" |
| 23:39 | <webben> | Lachy_: That's not very helpful since it can't be programmatically associated with the image. |
| 23:39 | <Lachy_> | it can be when used within a <figure> |
| 23:40 | <webben> | what about when it's not in a figure? |
| 23:40 | <webben> | and what about when your photoshop-mock maker complains about the visible longdesc link? |
| 23:41 | <webben> | visible associations are ideal, but they are problematic in the real world. |
| 23:41 | <webben> | (witness the microformat's movements endless trouble with "visible" yet "hidden" data) |
| 23:41 | <Lachy_> | hidden metadata is more problematic in the real world, and londesc="" simply doesn't work in practice |
| 23:41 | <othermaciej> | the link anchor can be around the image |
| 23:41 | <webben> | It /works/ fine. Saying it doesn't work is like saying alt doesn't work because some people write garbage alt text. |
| 23:42 | <webben> | othermaciej: Not if the image is a link already. |
| 23:42 | <othermaciej> | if it is a link already, then likely a separate longdesc link is unnecessary |
| 23:43 | <webben> | othermaciej: For example. An image of painting of Lady of Shalott linking to the poem. A long description for the painting. |
| 23:43 | <Lachy_> | since authors can always include a <figure> around the image to explicitly associate the <a rel="longdesc" ...>, the case where there is no figure could be considered an error. But that doesn't prevent any heurisitics from making a reasonable guess about which image it's associated with |
| 23:43 | <othermaciej> | I dunno, I don't really have a horse in the longdesc race |
| 23:44 | <webben> | Lachy_: I think you're wildly underestimating how difficult authors make it to write effective heurestics for that sort of case. |
| 23:44 | <othermaciej> | however, it seems to be the case that very few (less than 1 in 100,000) pages use it, and of those, at best 1 in 1000 use it correctly (that's just eliminate longdescs that simple testing can show you are wrong) |
| 23:44 | <othermaciej> | those are pretty poor odds |
| 23:44 | <webben> | I know AT have had enormous trouble associating fields with labels; I know from experience it's difficult even to conclusively associate permalinks with blog articles. |
| 23:44 | <Lachy_> | webben, there's still the issue that longdesc doesn't work in practice. Authors rarely use properly, and when they do, they most often include a redundant link anyway |
| 23:45 | <webben> | Lachy_: "work in practice" and "is widely used" are completely different things. |
| 23:45 | <webben> | Especially when even accessibility resources have long continued under an apprehension that longdesc isn't supported. |
| 23:45 | <othermaciej> | it's not just rarely used - the rare times it is used, it is usually used wrong |
| 23:46 | <othermaciej> | (at least that's what the stats I have seen seem to show) |
| 23:46 | <webben> | Even that isn't the same thing as "not work in practice". |
| 23:46 | <Lachy_> | given that it's supported with extremely bad UI, treating it as if it's not supported makes little difference |
| 23:46 | <othermaciej> | I guess it depends on how you define work |
| 23:46 | <webben> | e.g. if responsible authors assume it doesn't work, then you'd /expect/ a higher proportion of misuse by spammers |
| 23:46 | <othermaciej> | I would assume the goal of the feature is to convey useful information to the blind and visually impaired |
| 23:47 | <othermaciej> | so far it does not seem to have become an effective way to do that |
| 23:47 | <webben> | othermaciej: That's not exactly the stated rationale in the HTML4 spec. |
| 23:48 | <webben> | although it's certainly a goal. |
| 23:48 | <othermaciej> | this would lead me to at least wonder if other ways of associating a long description might be better |
| 23:48 | <webben> | othermaciej: It's perfectly effective if you let people know that you're using longdesc and they have supporting AT or an add-on. |
| 23:49 | <webben> | Although again I'd tend to say that OBJECT's nesting model is a cleaner solution. |
| 23:49 | <othermaciej> | it's true, HTML 4.01 says "This attribute specifies a link to a long description of the image", but I think it has to be assumed it's not intended for general audiences because then a normal link would be better |
| 23:50 | <webben> | othermaciej: Yeah but it's emphatically not just targeted at disabled users. |
| 23:50 | <webben> | note the rationale given for ALT: http://www.w3.org/TR/html4/struct/objects.html#adef-alt |
| 23:53 | <webben> | In an ideal world, it would always be good to give authors the opportunity to express accessibility information/metadata visibly. In the real world, publishers are never going to always choose to do so. Therefore there will always be a set of publishers willing to express accessibility information/metadata "invisibly" (to some degree) and not visibly. |
| 23:55 | <takkaria> | that set seems to be very small today, though |
| 23:55 | <webben> | So while I think the "hidden metadata is evil" argument is a powerful argument for allowing ways to explicitly markup visible content as being a genuine equivalent for some other bit of content, I don't think it's a real-world argument for preventing authors providing "invisible" equivalents/metadata. |
| 23:56 | <webben> | takkaria: On the contrary, it's vast. ALT is one of the more successful accessibility features. Microformats have been surprisingly successful, given that while they preach visible metadata they practice a lot of invisible metadata. |
| 23:56 | <webben> | (a lot of key data is buried in TITLE attributes) |
| 23:57 | <webben> | I can't imagine a solution where to provide text for a image button you would have needed to make it visible would have been half as successful. |
| 23:57 | <webben> | It certainly doesn't parallel the model adopted for desktop UIs. |
| 23:57 | <takkaria> | true, but given that many people are willing to use alt text, the fact that most of those same people aren't willing to use longdesc, means that the number of people who actually want to provide longdesc must be fairly small |
| 23:58 | <webben> | takkaria: Again clearly false, given alt is /heavily/ evangelized, and longdesc, where mentioned at all by evangelists, has generally being accompanied by caveats about it not being supported. |
| 23:58 | <Dashiva> | alt is just text. longdesc requires a whole webpage. |
| 23:59 | <webben> | Dashiva: Yes. Which is the advantage of the OBJECT model for equivalent content. |