| 00:00 | <webben> | looking at the manual when they introduced it, seems it originally was read by default |
| 00:00 | <Lachy> | It'll be interesting to see if anyone actually volunteers to carry out that study, or whether they're just going to continue saying the study is flawed and push for longdesc anyway |
| 00:00 | <webben> | then they stopped, and now they've started again |
| 00:01 | <Lachy> | either way, I'm confident that the study would show that longdesc is useless regardless of the implementation used |
| 00:01 | <Hixie> | having seen blind users browse the web, i agree |
| 00:03 | <webben> | Hixie: fwiw looking at the lottery article again, looks like one could repair a lot of the longdesc attributes by (a) fixing Wikipedia and (b) not exposing a UI for certain machine-detectable cases where it's wrong. |
| 00:04 | <webben> | e.g. "not a valid url", "blank", 404 |
| 00:07 | <webben> | Hixie: I suppose you'd also have to look at how much of the incorrect content is useful content anyways to get an idea of how much it would affect people. |
| 00:07 | <webben> | wikipedia is definitely useful content. |
| 00:07 | <Hixie> | even when you ignored those, the fraction of useful longdesc values was still below 1% |
| 00:07 | <Hixie> | (based on a hand inspection of the remaining pages) |
| 00:09 | <webben> | Hixie: sorry, 1% of what? |
| 00:09 | <webben> | the article mentions a 1% figure, but that's of all longdescs in the sample. |
| 00:10 | <Hixie> | if you discard all pages that didn't have longdesc, then discard all pages that had mechanically-observably-bad longdesc, and then look at the remaining pages (a tiny fraction of the web) and examine the longdescs by hand, you find that it is still below 1% of _those_ that are actually useful. |
| 00:10 | <Hixie> | we're talking about an insanely small fraction of the web here |
| 00:11 | <Hixie> | certainly far below the nominal 80% that we normally target for features |
| 00:11 | <othermaciej> | hello all |
| 00:11 | <webben> | I may just be tired, but I can't reconcile that with the article's stats |
| 00:11 | <Hixie> | i don't think the article mentions the final step |
| 00:11 | <Hixie> | i didn't talk to mark about that iirc |
| 00:12 | <webben> | Hixie: is that sample still extant somewhere? could it still be documented? |
| 00:13 | Lachy | remembers stargate is on tonight :-) |
| 00:14 | <webben> | it might actually change between now and HTML5 being finished actually. |
| 00:15 | <webben> | if Wikipedia got fixed and large sites started using it for programmatic associations to diagrams. |
| 00:15 | <Hixie> | webben: it was on the web somewhere, probably one of the files on junkyard.damowmow.com |
| 00:15 | <Hixie> | webben: it might be linked from the whatwg wiki |
| 00:18 | <Philip`> | http://wiki.whatwg.org/wiki/Longdesc_usage ? |
| 00:19 | <Philip`> | (That's not from Hixie's data set, but it's the only detailed manual analysis I remember being done) |
| 00:19 | <Hixie> | not the one i was thinking of, but that shows much the same result |
| 00:19 | <Hixie> | ok, gotta go, meeting |
| 00:20 | <blooberry> | Philip`: I've got some results that might be interesting there too. |
| 00:20 | <webben> | some of those are machine detectable and some I wouldn't regard as a problem |
| 00:25 | <takkaria> | oo, I did that analysis |
| 00:25 | <takkaria> | always meant to do more |
| 00:26 | <webben> | takkaria: do you still have a link to it? |
| 00:27 | <takkaria> | that was the one Philip pointed at |
| 00:27 | <Philip`> | blooberry: Have you published any of the results so far? |
| 00:28 | <webben> | the problem with these numbers is they're very susceptible to changes in authoring practices from small codebases. |
| 00:28 | <blooberry> | philip`: Trying to get that done presently. Hoping to have it out soon. 8-} |
| 00:30 | <takkaria> | webben: yeah, well. Hixie gave me a larger sample which I need to investigate at some point |
| 00:31 | <blooberry> | Philip`: Would a summary be more interesting or the actual longdesc data? |
| 00:32 | <Philip`> | blooberry: I'm not interested in longdesc at all, so someone else might have a better idea of what'd be good :-) |
| 00:33 | <blooberry> | Philip`: ok. Good point. ;-} |
| 00:33 | blooberry | reads back and notices where the confusion arose |
| 01:25 | Philip` | wonders whether a Jython program using Protocol Buffers should use the Java version of the library or the Python version |
| 08:18 | <hsivonen> | I like it how XMLPorn.jpg was from a talk called "Practical RDF" |
| 08:18 | <hsivonen> | I tend to send a link to XMLPorn.jpg when friends are having trouble with Namespaces |
| 08:20 | <gavin> | google doesn't know about XMLPorn.jpg - link? |
| 08:23 | <hsivonen> | gavin: http://www.tbray.org/ongoing/When/200x/2003/12/13/MegaXML |
| 08:23 | <hsivonen> | gavin: actually, it's XMLporn.jpg |
| 08:23 | <gavin> | heh |
| 09:51 | <annevk> | http://www.google.com/chrome/intl/en/webmasters-faq.html#html5 o_O |
| 09:56 | <annevk> | "w.document.location" (where w is a Window object) |
| 09:58 | <Dashiva> | grgr |
| 09:58 | <Dashiva> | Using location directly is a pox on the internet |
| 10:01 | <annevk> | see also: http://ejohn.org/blog/javascript-in-chrome/#comment-320344 (re link above) |
| 12:14 | <hsivonen> | btw, if anyone has a solution for scaling Validator.nu hosting up in a way that could handle spikes from Google Blog, digg or somesuch without raising the fixed cost to the level of paying for the peak capacity all the time, I'd like to hear it |
| 12:26 | <Dashiva> | If they're all validating the same site(s), caching might help. But I suppose that's not the common case. |
| 12:29 | <hsivonen> | Dashiva: in general, though, making a validator cache input is a sure way to cause confusion when author edits and revalidates but has a bug in cache control |
| 12:30 | <hsivonen> | it would be interesting to see, though, what the limits of the current setup are |
| 12:30 | <hsivonen> | since I got rid of Schematron on the HTML5 side, there haven't been cases where the server would have died due to load |
| 12:31 | <Dashiva> | Well, if the same IP submits twice, you could invalidate. Or you could hash the markup or something to detect changes. I'm not a caching expert, but it should be doable. :) |
| 12:31 | <hsivonen> | and the previous load deaths were on the Apache side--not in the Java process |
| 12:32 | <Dashiva> | Less time per request would help the apache end as well, though |
| 12:34 | <hsivonen> | I guess the first step of serious scaling would be to have 3 IP addresses each with a separate process: Apache for static files. Jetty for html5.validator.nu. Jetty for validator.nu and parsetree.validator.nu |
| 12:35 | <hsivonen> | Gandi's pricing scales down better than Amazon's |
| 12:35 | <hsivonen> | on my current host, changing the VM setup cost money and takes 24 hours |
| 12:36 | <hsivonen> | but so far, I haven't seen any system for any hosting provider that automated allocation of extra resources during a peak for Java hosting |
| 12:36 | <hsivonen> | like App Engine does for Python hosting |
| 12:36 | <hsivonen> | Amazon doesn't scale down well |
| 12:37 | <hsivonen> | because you have to host your persistent instance elsewhere |
| 12:37 | <hsivonen> | and it sucks that everyone has to reinvent infrastructural solutions for detecting the need for capacity and instructing EC2 to allocate it |
| 12:46 | <hsivonen> | perhaps in the future, automatically spawnable Xen VMs and Amazon ESB functionality becomes commoditized, and App Engine-like software on top of those becomes commoditized, too |
| 13:01 | <tusho> | Why can't I put <nav> in <header>...? |
| 13:02 | <tusho> | My navigation bar is in my header. |
| 13:02 | <tusho> | Like this: |
| 13:02 | <tusho> | <header><h1>Site name</h1> <nav><ul>...</ul></nav></header> |
| 13:10 | <tusho> | :\ |
| 13:17 | <hsivonen> | tusho: I'm just implementing what Hixie wrote in the spec here. |
| 13:17 | <tusho> | Yea, but I'm asking why |
| 13:17 | <tusho> | It seems very silly |
| 13:19 | <tusho> | If nobody gives me a good justification then I'll just be invalid until it's fixed ;) |
| 13:35 | <tusho> | Nobody want to offer an explanation? :P |
| 13:35 | <Philip`> | Probably everyone who knows (e.g. Hixie) is asleep :-) |
| 13:36 | tusho | throws a bucket of water onto Hixie |
| 13:37 | <tusho> | Hmm. |
| 13:37 | <hsivonen> | Philip`: perhaps s/e.g./i.e./ in this case? :-) |
| 13:37 | <tusho> | I wonder how many invalid pagers there are claiming to be HTML5 in the world. |
| 13:37 | <tusho> | *pages |
| 13:37 | <tusho> | (I mean, unintentionally) |
| 13:37 | <tusho> | Probably very little, as only the kind of people who would know about & actually use HTML 5 are the ones who would validate their pages as a matter of routine |
| 13:38 | <hsivonen> | tusho: an infinite number of Google Maps pages |
| 13:38 | <tusho> | google maps pages claim to be html5? |
| 13:38 | <tusho> | weird |
| 13:38 | <tusho> | yes they do |
| 13:38 | <tusho> | is that intentionally claiming to be html5? |
| 13:38 | <Philip`> | Infinite? I thought they only mapped a finite area |
| 13:38 | <tusho> | or just coincidence of the doctype |
| 13:39 | <hsivonen> | Philip`: I'd expect possible Google Maps URIs to be infinite, but there might be limits |
| 13:39 | <tusho> | Philip`: you can navigate outside of the map |
| 13:39 | <tusho> | and it also loops |
| 13:39 | <Philip`> | tusho: But that might just be a client-side effect, with the server only recognising a fixed-size rectangular set of coordinates |
| 13:39 | <tusho> | Philip`: Well, no, navigating outside the map doesn't wall in that |
| 13:40 | <tusho> | http://maps.google.com/?ie=UTF8&ll=89.999508,-127.96875&spn=0.001249,113.554688&z=3 |
| 13:40 | <tusho> | *fall in that |
| 13:41 | <tusho> | But yea, is that intentional? |
| 13:41 | <tusho> | The doctype being HTML5's. |
| 13:41 | <hsivonen> | tusho: I suspect it's intentional |
| 13:41 | <Philip`> | I don't think the client sends a request to some URL asking for a piece of the map that is off the edge of the world, and gets back a blank response - it just doesn't send the request at all, since it knows how big the world is |
| 13:41 | <tusho> | hsivonen: Why would they do that?... Claim to be HTML5 (for no particular gain, as far as I can see, they don't use any of its features) and then be _invalid_ HTML5 |
| 13:41 | <tusho> | Philip`: It's still a unique page. |
| 13:42 | <hsivonen> | tusho: perhaps they want the Standards Mode in Gecko, WebKit, Opera and IE <= 7 |
| 13:42 | <tusho> | hsivonen: use an html4 doctype? |
| 13:42 | <hsivonen> | (it seems they want IE8 to emulate IE7) |
| 13:42 | <hsivonen> | tusho: costs more bytes |
| 13:43 | <tusho> | hsivonen: I'm sure even google could handle <!DOCTYPE html "-//W3C//DTD HTML 4.01//EN"> :P |
| 13:43 | <tusho> | But yea, it just seems odd to me. |
| 13:43 | <Philip`> | tusho: Oh, right, the actual maps.google.com URI itself? |
| 13:43 | <Philip`> | Sorry, I'm a bit slow :-p |
| 13:43 | <tusho> | Philip`: I think the HTML source will change too a bit |
| 13:44 | <tusho> | relating to the query params |
| 13:45 | <Philip`> | Why does Google send <meta http-equiv=X-UA-Compatible content="IE=EmulateIE7" /> instead of (a) saving space by omitting the quotes and the trailing slash, or (b) sending it via HTTP instead? |
| 13:45 | <Philip`> | They're really quite profligate with their bandwidth |
| 13:46 | <tusho> | a script is run through the theme on http://eso-std.org/ before it's uploaded |
| 13:46 | <tusho> | that strips all the whitespace from the php & css files |
| 13:46 | <tusho> | to make it go a little faster :P |
| 13:46 | <tusho> | Probably misguided. |
| 13:46 | <tusho> | Seemed to have an effect, although likely just a placebo |
| 13:47 | <tusho> | But yeah. |
| 13:47 | <tusho> | It's a bit odd for google to waste space like that |
| 13:47 | <Philip`> | Browsers need a pretty-printing 'view source' feature |
| 13:47 | <hsivonen> | perhaps next to YouTube, nothing else matters |
| 13:47 | <hsivonen> | Philip`: indeed |
| 13:48 | <hsivonen> | Philip`: and JS debuggers operating on the pretty-printed line numbers |
| 13:48 | <jgraham> | tusho: The reason you can't put <nav> in <header> is that <header> doesn't quite mean "page header" |
| 13:48 | <tusho> | jgraham: Yes, but it means 'header of the containing element', right? |
| 13:48 | <jgraham> | It means something like "title box" |
| 13:48 | <tusho> | So <header> in <body>... |
| 13:51 | <jgraham> | <header> is designed for things like <heading><h1>Yet Another Weblog</h1><h2>With a witty subtitle</h2></header> where you want to associate the title and the subtitle but don't want to have the subtitle appear in a table of contents |
| 13:51 | <tusho> | Hm. |
| 13:51 | <tusho> | jgraham: Well, how would you improve this? |
| 13:51 | <tusho> | <nav><ul><li id="site-name"><a href="http://eso-std.org"><h1>ESO</h1></a></li><li><a href="http://eso-std.org/archive">Archive</a></li></ul></nav>; |
| 13:54 | <jgraham> | tusho: What is wrong with what you have? |
| 13:54 | <tusho> | jgraham: I dunno, the placement of the <h1> just seems a bit weird. |
| 13:55 | <tusho> | In a list item. |
| 13:55 | <tusho> | And tbh if you look at http://eso-std.org/ I'm not sure it belongs in the <anv> |
| 13:55 | <tusho> | Archive, and any other links that are displayed on the right, are the nav bar to me |
| 13:55 | <tusho> | I think header{h1,nav{ul}} would be more appropriate |
| 13:55 | <tusho> | but as I said & you expalined, that's incorrect |
| 13:55 | <tusho> | (and invalid) |
| 13:57 | <jgraham> | I think that only makes sense under a different definition of "header" than the one HTML 5 is currently aiming for. You could s/header/section/ I guess |
| 13:58 | <jgraham> | FWIW I have a crappy tool for producing outlines of HTML5 documents here http://james.html5.org/outliner.html |
| 13:59 | <hsivonen> | jgraham: does it have random access to the tree or does it just sweep it in document order? |
| 14:00 | <jgraham> | hsivonen: The tool? It has random access. I don't remember if it uses it ore not |
| 14:00 | <jgraham> | s/ore/or/ |
| 14:02 | <hsivonen> | jgraham: ok |
| 14:02 | <tusho> | jgraham: so you'd reccomend <section id="header">? |
| 14:05 | <jgraham> | tusho: Well there is a disdvantage that <section><h1>ESO</h1></section><article><h2>Foo</h2></article> won't have ESO as a parent of Foo in the outline |
| 14:06 | <tusho> | Ah. |
| 14:06 | <tusho> | jgraham: Should I just do <div id="header"> then? |
| 14:06 | <jgraham> | So just <body><h1>ESO</h1><nav></nav><article><h2>Foo</h2></article> seems OK |
| 14:06 | <jgraham> | tusho: Or use div if you need it |
| 14:06 | <tusho> | jgraham: I do need it, if you take a look at the page I need to group the header and the nav bar |
| 14:08 | <tusho> | Alrighty. |
| 14:08 | <tusho> | Done. |
| 14:22 | gsnedders | updates <http://stuff.gsnedders.com/spec-gen/>; |
| 15:03 | <csarven> | Is @longdesc dropped in HTML5? |
| 15:06 | <Philip`> | csarven: Yes, in the sense that it's not in the current draft |
| 15:07 | <Philip`> | (since it's very rarely used, and when it is used it's almost always used wrongly, so it doesn't seem to be a good solution to whatever the problem is) |
| 15:19 | <jgraham> | I thought the point of @longdesc was to act as flamebait for public-html |
| 15:19 | <jgraham> | I seriously don't understand any of the arguments that have been going on around it |
| 15:21 | <jgraham> | Like the ones that go: 1) Users never encounter longdesc 2) Therefore it is hard to tell if they would find it useful 3) Therefore we must leave it in so that it can be used more |
| 15:22 | <jgraham> | 4) Even though we have no expectation of that happening any time soon |
| 15:22 | <jgraham> | I mean, as far as I can tell that is an exact summary of one of David's emails |
| 15:23 | <annevk> | I believe the argument is that it's the fault of user agents that the feature failed. So that we should first have good implementations of it before we can determine whether the feature is actually bad. |
| 15:24 | <jgraham> | That didn't seem to be what David was arguning, but I find him quite difficult to follow sometimes so I might be wrong |
| 15:25 | <annevk> | Oh ok, well, that's one of the arguments I hear now and then anyway. If an accessibility feature failed, it's because of UAs, not because it's simply a bad feature. |
| 15:25 | <jgraham> | Also, since very few authors actually test with AT it seems very unlikely that better AT support would lead to substantially more widespead usage |
| 15:25 | <annevk> | (It's also so wrong to think of things as "accessibility features", but whatever.) |
| 15:26 | <jgraham> | annevk: The "accessibility features" thing seems to be one of the fundamental points of disagreement |
| 15:31 | <hsivonen> | it seems to me that there's also tacit disagreement on how long the trial window for a given feature is |
| 15:32 | <hsivonen> | that is, it seems that some people think that 10 years should be enough |
| 15:32 | <hsivonen> | and others want to give the feature a chance still |
| 15:59 | <takkaria> | heh, that is madness |
| 15:59 | <takkaria> | "Many of us have done real work on issues like @headers, @alt, @summary, including but not limited to: ... Attending teleconferences" |
| 16:12 | <Philip`> | I hope I can count "making snide comments on IRC" as real work |
| 16:23 | <jgraham> | I think I'm making a more useful contribution by not making all the snide comments I can think of on IRC |
| 16:27 | <takkaria> | I have nowhere else to express incredulity :/ |
| 16:29 | Philip` | isn't complaining about it :-) |
| 16:33 | <jgraham> | takkaria: I'm not complaining. |
| 16:34 | <jgraham> | It's just the "scientists are corrupt" post somewhat riled me |
| 16:36 | Philip` | must have skipped over that post |
| 16:36 | <jgraham> | "It has been known for some time that some scientists skew their |
| 16:36 | <jgraham> | research to gain favor in the eyes of their peers and to gain fame" |
| 16:37 | <jgraham> | "When there is an economic interest involved one can be virtually |
| 16:37 | <jgraham> | guaranteed that the full facts will not come out, it's naive to |
| 16:37 | <jgraham> | suppose otherwise." |
| 16:38 | <Philip`> | The first statement is true but I don't see any justification for the second |
| 16:39 | <jgraham> | Indeed. It's a crazy generalization |
| 16:39 | jgraham | notes that these are not the snide comments |
| 16:40 | <Philip`> | Fortunately I'm only a computer scientist so I don't have to even pretend to do real science |
| 16:42 | Philip` | can't remember when he last read a paper that was based on a hypothesis - it always seems to be "we built this system because we thought it'd be interesting, and here's how we did it, and look how neat it is" |
| 16:44 | <jgraham> | Many astrophysics papers are "We did these observations and got these cool results. Maybe it works like this." where "this" is not necessarily a unique explaination |
| 16:47 | <jgraham> | (you generallly need a hypothesis to get telescope time in the first place though) |
| 16:51 | <Philip`> | Nowadays anyone can get virtually unlimited computer time with no justification from the box sitting under their desk, so we don't even need to do that :-( |
| 16:52 | <Philip`> | and if you have greater requirements and need a dozen machines, you can just run them all as VMs in the box sitting under your desk |
| 17:04 | <Philip`> | http://marketshare.hitslink.com/report.aspx?sample=21&qprid=43&qpcustom=Chrome+0.2 - that doesn't seem to have taken long to have mostly flattened off |
| 17:08 | <takkaria> | I wonder what the figure will be in a month |
| 17:10 | <Philip`> | (http://getclicky.com/global-marketshare-statistics gives a significantly different absolute value, but seems to have the same one-day growth and then a slow decline) |
| 17:11 | <takkaria> | nice to see that 7% of people are on ff3 so soon after release |
| 17:12 | <Philip`> | Automatic updates are a great idea :-) |
| 17:12 | Philip` | nudges the Opera people |
| 17:12 | <takkaria> | I didn't think ff2 automatically updated to ff3 yet |
| 17:12 | <Philip`> | (Actually it's fine for me since Gentoo upgrades Opera automatically) |
| 17:13 | <Philip`> | takkaria: Well, it's automatic once you click the right button in the automatically-popped-up dialog, I think |
| 17:14 | <takkaria> | I thought I read in meeting minutes somewhere that it was being delayed until 3.0.2 or something |
| 17:15 | <Philip`> | Oh |
| 17:15 | Philip` | isn't at all sure |
| 17:16 | <takkaria> | https://wiki.mozilla.org/Firefox3.1/StatusMeetings/2008-08-12#Firefox_2.0.0.17_.2F_3.0.2 |
| 17:17 | <takkaria> | "3.0.2 will be the version which we eventually offer as a major update" |
| 17:18 | <Philip`> | Fair enough |
| 17:18 | <Philip`> | I'm sure I've heard people complaining that they're using FF2 and it keeps nagging them to update to FF3, though :-) |
| 17:19 | <takkaria> | ah well |
| 17:19 | <takkaria> | who knows? :) |
| 17:22 | <Philip`> | Hmm, someone should have told me the Chromium SVN repository was going to use 1.9GB of space, before I downloaded it |
| 17:43 | <tusho> | well |
| 17:43 | <tusho> | i just got a report from someone that their firefox was "all different" |
| 17:43 | <tusho> | sure enough it was ff3 |
| 17:43 | <tusho> | they said it did an update thingy |
| 17:43 | <tusho> | so... |
| 18:17 | <gsnedders> | Lachy: Can you live with straight hair, not green hair? |
| 18:19 | <Philip`> | Straight hair is not quite as extreme nor as likely to result in people laughing at you in the street :-( |
| 18:19 | <gsnedders> | Okay okay okay… |
| 18:41 | <gsnedders> | Lachy: Will having it green and straight do? |
| 18:41 | <gsnedders> | I've been bullied into this for tonight. |
| 18:55 | gsnedders | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks! -- gsnedders has green hair, photos coming really soon :-)' |
| 19:02 | <Philip`> | hsivonen: You should make your validator into a Java applet, so you can support any number of users just by serving a static file and not having to worry about server load |
| 19:20 | <Philip`> | http://www.xkcd.com/ - <img ... alt="<span style="color: #0000ED">House</span> of Pancakes" /> - oops |
| 19:23 | <Lachy> | gsnedders, green hair is non-negotiable. But why does it have to be straight? |
| 19:23 | <gsnedders> | Lachy: It is green now |
| 19:23 | <gsnedders> | And curly |
| 19:23 | <gsnedders> | Well, not entirely green |
| 19:23 | <gsnedders> | But mostly |
| 19:23 | <Lachy> | good |
| 19:28 | <Philip`> | s/good/crazy/ |
| 19:32 | <Lachy> | Philip`, crazy is good. |
| 19:33 | <Lachy> | we're all crazy in here |
| 19:33 | Philip` | wonders about correlation vs causation |
| 19:34 | <Philip`> | (Are we here because we're crazy, or are we crazy because we're here, or is there an external cause of both situations, or no cause at all?) |
| 19:34 | <takkaria> | this place doesn't make you crazy, just slowly more realistic |
| 19:34 | <takkaria> | so my guess is option three or four |
| 19:43 | <Lachy> | I think we only stick around because we're crazy. The non-crazy people tend leave pretty quickly when they see the kind of nonsense we talk about in here |
| 19:44 | jgraham | wonders why the photos are taking so long |
| 19:45 | <Lachy> | gsnedders could be using a non-digitial camera and I hear those can take a little while to develop. |
| 19:46 | <Lachy> | but I don't know, I haven't used one of those for years |
| 19:53 | <jgraham> | I know for a fact that gsnedders has a digital camera. However I guess he might be using a manual camera and developing in his kitchen. In black and white. |
| 19:53 | <Philip`> | That would somewhat defeat the point |
| 19:54 | <Lachy> | w00t! gsnedders will look hilarious with black hair :-) |
| 20:55 | Lachy | adds more people to his list of people to whom never to respond |
| 20:55 | <Lachy> | it's interesting how people's responses to me have ignored the real issue, and instead focussed on irrelevant crap |
| 20:56 | <Lachy> | on public-html |
| 20:56 | <Lachy> | and how Laura took what I said way out of context |
| 21:21 | <Dashiva> | "Because the author did not know how to make the @longdesc attribute accessible for sighted users." |
| 21:21 | <Dashiva> | Why put it in a hidden attribute if you want to make it visible? |
| 21:31 | <Dashiva> | "Those AT tools that *do* support @longdesc are generally configured so that announcing @longdesc is a toggle ON setting; it is toggled off by default." |
| 21:32 | Dashiva | facepalms |
| 21:34 | <Lachy> | Dashiva, that was my reaction too |
| 21:35 | <Lachy> | in fact, that was pretty much my reaction to the messages from Laura, PTW, David and John |
| 21:36 | <Dashiva> | webben mentioned yesterday that longdesc announcement was on by default when JAWS first added it, and it was later turned off |
| 21:36 | <Dashiva> | Which is pretty much unconditional surrender |
| 21:37 | <jruderman> | turned off by default *in jaws*? |
| 21:37 | <Lachy> | apparently it's on by default in the jaws 10 beta though |
| 21:38 | <Dashiva> | <webben> Dashiva: JAWS has exposed it since version 4.something. |
| 21:38 | <Dashiva> | <webben> although in some recent versions, you've had to enable announcements for it. |
| 21:38 | <Dashiva> | <webben> Dashiva: that behavior appears to have changed back to announcing by default in current JAWS 10 Beta. |
| 21:39 | <Dashiva> | (and I wouldn't be surprised if it's off by default in v10 final) |
| 22:03 | jgraham | wonders if gsnedders parents are making him shave his head |
| 22:31 | <Lachy> | wow, finally John has sent some real evidence to support his case. http://lists.w3.org/Archives/Public/public-html/2008Sep/0222.html |
| 23:08 | <webben_> | Lachy: The MSDN documentation he cites is somewhat bungled I think. I think what they meant to say is that they now expose longdesc directly via MSAA and that they no longer show alt as tooltip (based on my own experimentation with Beta 2 + http://www.paciellogroup.com/blog/?p=43) |
| 23:08 | <webben_> | that is, they expose the longdesc URI. |
| 23:10 | <webben_> | whether it's a good idea to dump that in accDescription seems a bit dubious |
| 23:10 | <webben_> | but maybe they're trying to work around fundamental limitations in MSAA. |
| 23:11 | <webben_> | I can't get it to display as a tooltip at any rate, and personally I doubt that would be a great implementation. |
| 23:12 | <Philip`> | Dumping the URI into a textual description field? That seems likely to encourage incorrect usage of the attribute, if anything |
| 23:13 | <webben_> | Philip`: the complication is accDescription may not be used for a textual description (at least by consumers in the know about IE, which is each reader produced after release) |
| 23:14 | <webben_> | as I understand it, MSAA is quite limited and getting a complex application exposed to it properly (e.g. an office suite, or a browser) involves a lot of hackery. |
| 23:15 | <webben_> | Philip`: see http://www.mozilla.org/access/windows/msaa-server for Gecko's notes on the subject |
| 23:15 | <webben_> | iAccessible2 is standardization based on such overloading of MSAA. |
| 23:16 | <webben_> | Philip`: for example, an AT might just use the presence of an accDescription to tell it to present an announcement that there's a longdesc present and provide a mechanism to access it. |
| 23:17 | Philip` | tries AccExplorer |
| 23:18 | <Philip`> | With IE8b2, on an image with longdesc, it says "Description: images/small_puppy.txt" |
| 23:18 | <Lachy> | yeah, well, whatever is implemented, it's still not enough until there is evidence that the implementations are even usable by those who need it |
| 23:18 | <Philip`> | so it does seem to be putting the (relative) URI (or whatever the attribute value is) in the 'description' field |
| 23:18 | <Lachy> | and that the increased usage of longdesc by authors can be verified to be significant enough |
| 23:22 | <webben_> | Philip`: what's in accValue out of interest? |
| 23:22 | <webben_> | Philip`: (I'm just looking at http://www.mozilla.org/access/windows/msaa-server#Dueling_text_equivalents ) |
| 23:22 | <Philip`> | webben_: Would that be what AccExplorer calls "Value"? |
| 23:22 | <webben_> | Philip`: I suspect so, yeah. |
| 23:22 | <Philip`> | If so, that's the absolute image URI |
| 23:22 | <webben_> | ah okay |
| 23:23 | <Philip`> | (i.e. it's actually resolved to an absolute URI, rather than just being the attribute value) |
| 23:23 | <Philip`> | and "Name" is the alt value |
| 23:29 | <Philip`> | (In Gran Paradiso 3.0.1, Name is the alt text, and Description and Value are empty) |
| 23:30 | <Philip`> | (Opera 9.5 is the same) |
| 23:30 | <webben_> | strange. |
| 23:34 | <Philip`> | (The Inspect tool shows the same, and interestingly it lists ancestors with labels like '"p" [ BUG? State/Role should not be a string ]' in Firefox) |
| 23:35 | <webben_> | Philip`: http://msdn.microsoft.com/en-us/library/ms696156(VS.85).aspx : Remarks section is interesting |
| 23:35 | <webben_> | "This property provides a textual equivalent of the object for the user. The description should be similar to the text supplied with the ALT attribute in HTML, which is the text that is displayed to describe images for people using text-only browsers." |
| 23:35 | <webben_> | "However, some controls use this property to store extra information about the control that is not related to a textual equivalent." |
| 23:35 | <webben_> | (i.e. overloading it, presumably) |
| 23:36 | <Philip`> | (Oh, also, in Firefox, for "Value" Inspect says "[Error: getting string: hr=0x80004005 - Unspecified error]", so it's not quite just an empty string or missing) |
| 23:37 | <Philip`> | webben_: That sounds like utterly useless documentation |
| 23:38 | <webben_> | Don't look at me; I didn't write it! ;) |
| 23:38 | <webben_> | Philip`: I agree. Not very helpful. |
| 23:38 | <Philip`> | "The Description property might contain a description, or it might not! Have fun figuring it out yourselves" |
| 23:39 | <Philip`> | and it seems nobody puts the alt attribute text into that Description property anyway |
| 23:39 | <Philip`> | so it's actively misleading |
| 23:39 | <webben_> | including IE. |
| 23:41 | <Philip`> | Safari 3.1.2 seems to be totally opaque to these MSAA tools - it's just a WebViewWindowClass and that's it |
| 23:41 | <webben_> | http://msdn.microsoft.com/en-us/library/ms695710(VS.85).aspx |
| 23:41 | <webben_> | "An object's Description property provides a textual description about an object's visual appearance. The description is primarily used to provide greater context for low-vision or blind users, but is also used for context searching or other applications" |
| 23:41 | <webben_> | Philip`: yeah, WebKit's MSAA implementation is still in the early stages AFAIK. |
| 23:42 | <webben_> | (VoiceOver doesn't do anything with longdesc. Then again VO doesn't do anything with tables either.) |
| 23:45 | <Philip`> | Looks like IE8b2 sets Description to the longdesc text (if any), else the title text (if any), else it's a 'none' value |
| 23:45 | <Philip`> | (If you have longdesc then the title isn't exposed anywhere that I can see) |
| 23:46 | <Philip`> | And it sets Name to the alt text (if any), else the title text (if any), else 'none' |
| 23:46 | <webben_> | What? they drop title if longdesc is present? |
| 23:46 | <Philip`> | but that's only in standards-mode |
| 23:46 | <webben_> | Philip`: is your test title the same as the alt or different? |
| 23:47 | <Philip`> | In quirks mode, the Description is the longdesc else the alt else none |
| 23:47 | <Philip`> | and the Name is the title else the alt else none |
| 23:47 | <Philip`> | webben_: Different |
| 23:48 | <webben_> | this implementation sounds completely crazed. |
| 23:48 | <Philip`> | Sure :-) |
| 23:48 | Philip` | is just using <!doctype html><img src=image alt=alttext longdesc=longdesctext title=titletext> in the Live DOM Viewer to test this |
| 23:48 | <webben_> | Philip`: I can't remember does either tool show accHelp? |
| 23:49 | <webben_> | because I think WebKit dumps title into a help field. |
| 23:49 | <Philip`> | webben_: Inspect says "Help: none [nimpl]" for images in IE |
| 23:52 | <webben_> | oh well |
| 23:52 | <Philip`> | (I don't see any way to get any data out of Safari at all) |
| 23:52 | <webben_> | not exposing title sounds like a bug worth reporting |
| 23:53 | <Philip`> | Where could it be exposed? |
| 23:54 | <webben_> | Philip`: http://msdn.microsoft.com/en-us/library/ms695735(VS.85).aspx (accHelp) |
| 23:55 | <webben_> | "This property contains balloon-style information (as found in ToolTips) that is used either to describe what the object does or how to use it." |
| 23:55 | <Philip`> | Ah |
| 23:55 | <Philip`> | That's not what title text is, though |
| 23:55 | <Philip`> | (Well, it's balloon-style information, but it's not describing what something does or how to use it) |
| 23:56 | <webben_> | I don't think MSAA is going to allow the level of granular semantics you're assuming there. |
| 23:56 | <Philip`> | I suppose I'm assuming something more than "stuff into whatever available field is kind of vaguely related to your data" :-) |
| 23:57 | <webben_> | Sure :) |
| 23:57 | <Philip`> | I guess it's kind of hard when a single image can have three distinct pieces of descriptive text, and you want to fit it into an application-agnostic API |
| 23:58 | <webben_> | title in HTML4 is "advisory text" |
| 23:58 | <webben_> | I think accHelp is best fit there. |
| 23:58 | <webben_> | I can't remember what HTML5 says (and don't think it matters since for practical web authoring purposes title = tooltip) |