/irc-logs / freenode / #whatwg / 2007-07-14 / end

Options:

# Session Start: Sat Jul 14 00:00:00 2007
# Session Ident: #whatwg
# [00:18] * Quits: Charl (n=charlvn@net-153-078.mweb.co.za) ("Leaving")
# [00:30] * Parts: hasather (n=hasather@22.80-203-71.nextgentel.com)
# [00:56] * Joins: othermaciej (n=mjs@17.255.98.236)
# [01:01] * Quits: tndH_ (i=Rob@adsl-87-102-36-227.karoo.KCOM.COM) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
# [01:15] * Parts: billmason (n=billmaso@ip156.unival.com)
# [01:16] * Quits: zcorpan_ (n=zcorpan@90-229-146-10-no117.tbcn.telia.com) (Read error: 110 (Connection timed out))
# [01:28] * Quits: othermaciej (n=mjs@17.255.98.236)
# [01:29] * Joins: othermaciej (n=mjs@17.255.98.236)
# [01:34] * Quits: kingryan (n=kingryan@corp.technorati.com)
# [02:03] * Quits: othermaciej (n=mjs@17.255.98.236) (Read error: 104 (Connection reset by peer))
# [02:03] * Joins: othermaciej (n=mjs@17.255.98.236)
# [02:04] * Quits: mksm (n=mksm@201-68-29-50.dsl.telesp.net.br)
# [02:09] * Joins: weinig_ (i=weinig@nat/apple/x-383e288366e9a155)
# [02:10] * Quits: weinig (i=weinig@nat/apple/x-4bb1ab8b6bbb4614) (Read error: 104 (Connection reset by peer))
# [02:14] * Quits: KevinMarks (i=KevinMar@nat/google/x-0d60304257986902) ("The computer fell asleep")
# [02:33] * Quits: weinig_ (i=weinig@nat/apple/x-383e288366e9a155)
# [02:38] * Joins: weinig (i=weinig@nat/apple/x-05da91a4348f2015)
# [02:55] * Quits: h3h (n=w3rd@66-162-32-234.static.twtelecom.net) ("|")
# [03:15] * Quits: weinig (i=weinig@nat/apple/x-05da91a4348f2015)
# [03:27] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
# [03:34] * Quits: tantek (n=tantek@corp.technorati.com)
# [03:59] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
# [04:15] * Quits: othermaciej (n=mjs@17.255.98.236)
# [04:25] * Quits: eigentone (n=craig@206-248-134-242.dsl.teksavvy.com) (Client Quit)
# [04:41] * Quits: gavin (n=gavin@firefox/developer/gavin)
# [04:45] * Joins: gavins (n=gavin@firefox/developer/gavin)
# [04:56] * Joins: MikeSmith (n=MikeSmit@eM60-254-212-114.pool.emobile.ad.jp)
# [04:58] * Joins: billyjack (n=MikeSmit@eM60-254-212-114.pool.emobile.ad.jp)
# [05:02] * Quits: billyjack (n=MikeSmit@eM60-254-212-114.pool.emobile.ad.jp) (Client Quit)
# [05:20] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
# [05:21] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
# [05:25] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (Read error: 104 (Connection reset by peer))
# [05:27] * Quits: MikeSmith (n=MikeSmit@eM60-254-212-114.pool.emobile.ad.jp) (Read error: 110 (Connection timed out))
# [05:36] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [06:21] * Joins: rabies2 (n=raunchy@p54882770.dip0.t-ipconnect.de)
# [06:32] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
# [06:36] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [06:39] * Quits: rabies (n=raunchy@p5488139B.dip0.t-ipconnect.de) (Read error: 110 (Connection timed out))
# [06:54] * Joins: eigentone (n=craig@206-248-134-242.dsl.teksavvy.com)
# [07:05] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
# [07:54] * Joins: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
# [08:04] * Quits: toolskyn (i=toolskyn@amy.bdick.de) (Read error: 101 (Network is unreachable))
# [08:19] * Joins: KevinMarks (n=KevinMar@c-76-102-254-252.hsd1.ca.comcast.net)
# [08:43] * Joins: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
# [08:49] * Joins: Lachy (n=Lachy@203-214-140-60.perm.iinet.net.au)
# [08:50] <Lachy> Hi all
# [09:19] * Quits: eigentone (n=craig@206-248-134-242.dsl.teksavvy.com)
# [09:21] * Joins: eigentone (n=craig@206-248-134-242.dsl.teksavvy.com)
# [09:25] * Joins: toolskyn (i=toolskyn@amy.bdick.de)
# [09:28] * Joins: MikeSmith (n=MikeSmit@eM60-254-219-70.pool.emobile.ad.jp)
# [09:40] * Quits: MikeSmith (n=MikeSmit@eM60-254-219-70.pool.emobile.ad.jp) ("Less talk, more pimp walk.")
# [09:57] * Joins: ROBOd (n=robod@86.34.246.154)
# [10:17] * Quits: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
# [10:20] * Joins: MikeSmith (n=MikeSmit@eM60-254-213-202.pool.emobile.ad.jp)
# [10:22] * Joins: hendry (n=hendry@91.84.62.62)
# [10:25] <hendry> hsivonen: i've heard several ppl lately talking about exposing APIs on mobile devices
# [10:26] <hendry> i wondered if you had any thoughts on that, or know someone who is working on that
# [10:27] <hsivonen> hendry: my main thought is that I'd like to see Nokia, Opera and Apple standardize what they are doing so that we don't need a layer of abstraction libraries on the JS side
# [10:27] <hendry> i heard opera were doing something in their namespace
# [10:28] <hsivonen> hendry: I haven't looked into this really, so I don't know if they are already aligning their APIs with each other
# [10:28] <hendry> i didn't manage to track down the relevant document yet though
# [10:30] <hendry> i imagine this 'layer of abstraction libraries' might be difficult to implement on a range of devices
# [10:30] <hendry> and i was thinking if UAs might connect the JS caps with typical mobile JVMs
# [10:31] <hsivonen> hendry: why would be difficult? (I don't do mobile stuff, so forgive my cluelessness)
# [10:32] <hendry> i haven't seen anyone do it. i am just thinking of some sort of strategy of getting 'APIs exposed'
# [10:32] <hsivonen> hendry: I didn't mean abstracting random "mobile UAs" but abstracting iPhone, S60 Browser and Opera for Mobile
# [10:33] <hendry> sure, they will be most of the market and the ones that are reasonable
# [10:33] <hsivonen> I have no idea whether Minimo should be on the list. that is, I have no idea if Minimo tries to expose some non-desktop features of the host device to JS
# [10:33] <hendry> however i do wonder about the future of the 'S60 Browser'
# [10:34] <hsivonen> hendry: how so?
# [10:34] <hendry> well my ex-flatmate andrei has left Nokia :)
# [10:34] <hsivonen> oh
# [10:34] <hendry> so I am wondering who is maintaining it for one and implementing new features
# [10:34] <hendry> the community is small ;)
# [10:36] <hendry> about minimo. do you think ever get some market share on mobile devices?
# [10:37] <hendry> it seems webkit has all the mindshare on mobiles atm
# [10:37] <hsivonen> hendry: I guess that depends on how much work attention Minimo gets and whether "Gecko 2" deCOMtamination takes the RAM footprint down.
# [10:38] <hendry> hehe, there has been talk of that for many years now :)
# [10:41] <hsivonen> w00t! I get the right trees on tests2.dat (after fixing a bunch of test cases :-)
# [10:42] * Quits: Lachy (n=Lachy@203-214-140-60.perm.iinet.net.au) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502]")
# [10:51] * Joins: Ducki (n=Ducki@dialin-212-144-065-130.pools.arcor-ip.net)
# [11:04] * Joins: tndH_ (i=Rob@adsl-87-102-36-227.karoo.KCOM.COM)
# [11:04] * tndH_ is now known as tndH
# [11:11] * Joins: Lachy (n=Lachy@203-214-140-60.perm.iinet.net.au)
# [11:14] * Quits: MikeSmith (n=MikeSmit@eM60-254-213-202.pool.emobile.ad.jp) ("Less talk, more pimp walk.")
# [11:18] * Joins: hasather (n=hasather@22.80-203-71.nextgentel.com)
# [11:26] * Joins: webben (n=benh@82.153.85.49)
# [11:40] <Dashiva> "both the image and the rich description thereof should not be an either/or proposition, but a "let the user decide how to expose rich content" question..."
# [11:40] <Dashiva> I hope I'm not the only one thinking "we use images because they provide something more than not having images"
# [11:41] <webben> Dashiva: That depends on the user.
# [11:41] <webben> User-centric design has to recognize that. :)
# [11:42] <webben> You could equally say we provide a text alternative to an image because it provides something more (for some users) than having images.
# [11:44] <webben> Dashiva: what were you quoting there?
# [11:44] <Dashiva> A recent list post
# [11:45] * Dashiva ponders the possibility of pushing accessibility to get more images as alternate content on pure-text pages, to be more accessible for people who don't like reading so much
# [11:47] <hsivonen> Dashiva: I think Gregory's thinking on this point doesn't match very well the way seeing authors think of their use of images
# [11:48] <webben> Dashiva: That's quite right. Images are more accessible to certain people in certain situations.
# [11:48] <webben> Dashiva: That's why WCAG has had (admittedly weak) provisions about including image alternatives.
# [11:51] <webben> Dashiva: see e.g. the introduction to WCAG 1: http://www.w3.org/TR/WAI-WEBCONTENT/
# [11:51] <webben> and Checkpoint 14: http://www.w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-comprehension
# [11:53] <Dashiva> That's to supplement, like having a graph sidebar. It's not equivalent content, which seems to be the rage these days
# [11:54] <hsivonen> webben: I think it is extremely rare for authors to hide some of their text when they provide an illustration. hence, as Dashiva said, supplementary--not alternative
# [11:54] <webben> Dashiva: The text refers you back to Guideline 1. Read it a bit more carefully.
# [11:54] <hsivonen> webben: the thing is, if an image is supplementary, does it need an alternative?
# [11:55] <webben> "Providing non-text equivalents (e.g., pictures, videos, and pre-recorded audio) of text is also beneficial to some users, especially nonreaders or people who have difficulty reading."
# [11:55] <webben> hsivonen: That depends on what exactly it's supplementing.
# [11:56] <webben> e.g. a chart might supplement a text with /data/ in graphical form.
# [11:56] <hsivonen> webben: is there a way for people to indicate that they are non-readers or have difficulty of reading so that the UA could withdraw some text from them?
# [11:56] <webben> and hence need an alternate presentation of that data
# [11:57] <webben> hsivonen: I think to a large measure communicating via images is kind of a default for common UAs/
# [11:58] <hsivonen> webben: my point is that if you can see, it is generally up to the user to treat supplementary content as alternative and skim over it. should it be the UA's and author's responsibility to suppress some content in some cases based on a pref that indicates that the user has a trouble comprehending text?
# [11:59] <webben> hsivonen: Possibly, yes. Actually getting UAs to incorporate such customization would probably be an uphill struggle though.
# [12:00] <webben> hsivonen: I think what's happening in practice atm is the web bifurcates into websites that are friendly to those with learning disabilities and those that aren't.
# [12:01] <Dashiva> Heh, so image equivalents get a pri 3 checkpoint refering to an orphaned sentence in guideline 1. Oh well, no surprise.
# [12:01] <webben> e.g. http://simple.wikipedia.org/ and http://www.peepo.co.uk/
# [12:02] <hsivonen> webben: one of the problems with expecting the author to mark some parts of content suppressible from people with learning disabilities is that it would require authors to understand the needs of people with learning disabilities
# [12:03] <webben> hsivonen: Yes. People trying to communicate to an audience need to have some understanding of the needs of that audience. Failing that, they need guidelines to follow. (That's the basic premise of WCAG.)
# [12:03] <hsivonen> webben: another problem is that people who are capable of writing prose that is fine for cognitively capable native readers of a given language don't want their literary expression curtailed
# [12:03] <webben> hsivonen: Curtailed by what?
# [12:04] <hsivonen> webben: by having to cater to people with limited vocabulary (foreigners) or learning disabilities
# [12:04] <webben> hsivonen: In practice, people who aren't providing a commercial or public service don't seem to be "curtailed".
# [12:05] <webben> I should probably say in theory, given how little business and government seems to be touched by accessibility legislation anyhow.
# [12:05] <hsivonen> webben: for example, the Time magazine overdoes its thing with the thesaurus, but if you wanted Time to work for people with limited vocabulary, you'd effectively ask them to change their writing style
# [12:05] <webben> hsivonen: Or have two writing styles.
# [12:06] <webben> It wouldn't /necessarily/ be a commercial disaster, since their reach could increase to cover people with learning disabilities (a massive population) and people who have only basic english (an even bigger population).
# [12:06] <hsivonen> webben: do you mean writing article once in a supposedly witty way and then another time with all the intertextualism, implications, rare synonyms and idiomatic English eliminated?
# [12:07] <webben> hsivonen: Yeah, have a look at the simple wikipedia example I gave.
# [12:08] <hsivonen> webben: I think solutions that require you to author your content twice aren't gonna fly *in general*
# [12:09] <webben> hsivonen: Do they have to fly *in general*?
# [12:09] <hsivonen> webben: I think I don't have a learning disability, but I've never understood what the peepo site is supposed to be about
# [12:09] <webben> hsivonen: It's a series of fun web resources for people with learning disabilities + children.
# [12:10] <webben> it doesn't have a single unifying theme beyond that.
# [12:10] <webben> e.g. games + videos
# [12:10] <hsivonen> webben: no, if it is just a shadow site of wikipedia with plain hyperlinks in between. But if we're talking about building article alternatives into the markup, yes, the use case catered for should be a general one
# [12:11] <hsivonen> webben: Peepo gives me 401 when I try to follow a link
# [12:12] <webben> hsivonen: It gives me a request for authentication. I suspect he's gone and broken something temporarily.
# [12:12] <webben> hsivonen: A use case can be general without everyone choosing to use it.
# [12:12] <webben> hsivonen: e.g. PHP contains loads of functions. Not every PHP program uses every or even most of them.
# [12:12] <webben> but together they provide an immense power
# [12:13] <hsivonen> I would guess that "translations" within a language to a different cognitive audience would suck even more than normal traslations
# [12:13] <hsivonen> translations
# [12:13] <webben> hsivonen: Why would you guess that?
# [12:13] <webben> It seems non-obvious to me.
# [12:13] <hsivonen> webben: for example, the Web supposedly has a feature that lets me indicate a preference of Finnish over English
# [12:14] <webben> indeed
# [12:14] <webben> but problems with that have more to do with UA + server failures to implement HTTP properly than anything else.
# [12:14] <hsivonen> webben: however, in practice, when sites do have translations, *in practice* the English one is up-to-date. the other languages may or may not be
# [12:15] <webben> hsivonen: That can be a big problem with alternate content that is not in the same document.
# [12:15] <hsivonen> webben: hence, I tell my browser that I prefer English, because I prefer up-to-date foreign language that I can read over sucky out-of-date translations any time
# [12:15] <webben> hsivonen: It was a big problem with text-only "accessible" versions of sites.
# [12:15] * Joins: Ducki_ (i=Ducki@dialin-212-144-083-225.pools.arcor-ip.net)
# [12:16] <hsivonen> webben: so when I *do* switch between languages, I want to do it with explicit links so I can see what my bogometer says instead of the existence of translations being hidden from me
# [12:16] <webben> hsivonen: That's purely a matter of UA interface.
# [12:17] <webben> I don't think it's at all necessary to have every site come up with it's own interface for language switching.
# [12:17] <hsivonen> webben: no, it isn't. when you do content negotiation, the UA doesn't know what else was available
# [12:18] <hsivonen> anyway, I seriously don't trust automatic alternative selection
# [12:19] <hsivonen> webben: the big problem with alternatives for cognitively different audiences is that you really need a human editor
# [12:19] <webben> hsivonen: That depends on what UAs send.
# [12:20] <webben> For example, a UA could send a HEAD request without language preference and get back a list of choices.
# [12:20] <webben> And use that to construct a clientside menu.
# [12:20] <hsivonen> webben: "text only" browsers like Lynx show the same text content and screen readers read the same text content
# [12:21] <hsivonen> webben: I think you're now in the territory where fixing the failings of a feature balloon to such complication that we should concede that the feature is broken
# [12:22] <webben> "feature balloon"?
# [12:22] <webben> I don't think UAs ever took conneg terribly seriously.
# [12:22] <hsivonen> the attempts to fix the feature cause the solution as a whole to balloon
# [12:22] <webben> hsivonen: It's not an attempt to fix it.
# [12:22] <hsivonen> so the initially simple idea becomes very complex
# [12:23] <webben> it's just using the conneg drafts
# [12:23] <webben> http://www.ietf.org/rfc/rfc2296.txt
# [12:24] <webben> Features cannot break. They can be useful or non-useful. Only implementations can be broken.
# [12:24] <webben> (Non-useful features probably aren't features.)
# [12:24] <hsivonen> webben: that's what I'm talking about. first there was a simple idea: the browser tells a server what languages the user groks, the server sends matching content.
# [12:24] <hsivonen> webben: then, people figured out that it isn't enough
# [12:25] <hsivonen> webben: they try to patch and extend the feature
# [12:25] <hsivonen> webben: the feature becomes so complex that users can't configure it and implementors don't bother to implement
# [12:25] <webben> hsivonen: Well strictly the failure of sites like the ones with Finnish translations is simply that they don't set their q values properly.
# [12:25] <webben> (the q values should be set to indicate the Finnish content is of poor quality)
# [12:26] <hsivonen> webben: whereas everyone understands plain links "in English", "en français", "suomeksi"
# [12:26] <hsivonen> webben: now you are again saying that the implementations just aren't good enough
# [12:26] <hsivonen> webben: when the reality is that the feature just isn't as simple as it first looks
# [12:26] <webben> Those aren't at all contradictory.
# [12:27] <webben> The feature may not be simple (I don't think the conneg draft is immensely simple, except from an end-user perspective).
# [12:27] <webben> and also implementations aren't good enough.
# [12:27] <hsivonen> webben: my point is that if the feature fails most of the time in practice, practice wins over theory
# [12:27] <webben> Features can't fail.
# [12:28] <webben> It's a contradiction in terms.
# [12:28] <webben> Unimplemented features certainly can't fail. Since they haven't even existed in practice.
# [12:29] <hsivonen> if a feature is designed to give me content that I'd prefer with little effort on my part, the feature is a failure if most of the time I don't get what I wanted and spent effort finding that out
# [12:30] <webben> hsivonen: If I design a bridge and no-one builds it, the bridge can't be said to be a failure since you cannot walk across it.
# [12:30] <hsivonen> by "fail" I mean that all the trouble that went into the feature hasn't resulted in a net gain in satisfaction
# [12:31] <webben> The /design/ might (or might not) be a failure; but that can't actually be deduced from the fact that you can't walk across the bridge.
# [12:31] <webben> (For instance, it might be the government ran out of bridge-building funds, or that there was a better design. There are multiple possibilities.)
# [12:33] <webben> As far as I can tell, the only advantage of "plain links" (which are so often not plain at all, but weird Flash widgets in practice) is that it doesn't require UAs or servers to implement anything.
# [12:34] <webben> (advantage in terms of the design, I mean, not how things are actually done)
# [12:34] * Quits: Ducki (n=Ducki@dialin-212-144-065-130.pools.arcor-ip.net) (Read error: 113 (No route to host))
# [12:35] <webben> Much web development seems to be about replacing simple interfaces like links with complicated ones like <object> and <video>.
# [12:35] <webben> The advantage of successfully shifting such interface into the UA is that it slightly discourages authors from confusing users with such interfaces.
# [12:36] <webben> (Because the user only has to deal with one way of doing things.)
# [12:37] <webben> hsivonen: Another problem with "plain links" as a solution is that developers who struggle to create single versions that cater to multiple audiences often can't even manage to provide a simple link to the supposedly "accessible" version.
# [12:38] <webben> It's truly amazing how many text-only sites remain effectively invisible to the target users for that reason.
# [12:38] <webben> It's a similar problem with skip links. People tend to hide the skip links, so that mobility impaired and screen magnifier users never see them.
# [12:40] <hsivonen> webben: since TTY display or speech rendering can be programmatically derived from the primary content, the problem is very different from an editor taking a Time magazine article and tranforming it for those who lack the reading comprehension capabilities required to read the usual Time magazine stuff
# [12:40] <webben> hsivonen: I didn't say it wasn't different, did I?
# [12:41] <webben> hsivonen: Note however that such alternate renderings still need editorial input for alternative text.
# [12:41] <webben> (I mean TTY/speech renderings)
# [12:41] <hsivonen> webben: you did't. however, translation is closer to the problem than "text only" links that you were using as an example
# [12:42] <webben> hsivonen: The issues of how you produce alternate sets of content, and the issue of how the user navigates/chooses between them, seem to me to be quite distinct.
# [12:42] <hsivonen> webben: providing textual alternetives for images is very different from potentially rephasing every sentence
# [12:43] <webben> Like I said, I didn't say it wasn't different. But your formulation of the difference seemed to make a false distinction between programmatic and editorial derivation of the alternate content.
# [12:44] <webben> Both forms of alternate content need editorial input. Simple text alternatives to buttons and link text need very little editorial input.
# [12:44] <hsivonen> the distinction makes a difference when you can place the programmatic derivation on the client but you have to place the editorial derivation on the server
# [12:44] <webben> Long descriptions, translations, symbolic represents, signed interpretations, basic english, etc need much more.
# [12:45] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [12:45] <webben> hsivonen: Can you elaborate? I'm a bit confused about what you're getting at.
# [12:46] <hsivonen> webben: with e.g. alt, you put a little something in the main content. with Basic English, you rewrite the whole content.
# [12:46] <hsivonen> supposed you have an URI for an article
# [12:46] <webben> Yes that's what I mean with less vs more editorial input.
# [12:46] <hsivonen> enabling that URI to be read by a text-to-speech software is easier and less disruptive than cramming a Basic English rewrite in there
# [12:47] <webben> hsivonen: Probably easier. Not sure what you mean by "less disruptive"?
# [12:48] <hsivonen> less distruptive for the authoring process and for non-Basic English use
# [12:48] <webben> hsivonen: example where it might not be easier would be an article about artwork for example, where you might need to provide long descriptions, or an article with loads and loads of charts.
# [12:48] <webben> hsivonen: I don't think either is disruptive to "non-Basic English use".
# [12:49] <hsivonen> to make it absurd by induction: would you cram all translations in one delivery file?
# [12:49] <webben> hsivonen: Well that's the argument for things like longdesc, src, href, and conneg.
# [12:49] <webben> (part of the argument)
# [12:50] <webben> e.g. link href for RSS version
# [12:50] <webben> (can also be used for alternate language versions etc)
# [12:51] <webben> hsivonen: I think whether these things make sense as one file or many probably is ultimately a question of efficient use of bandwidth vs. trying to ensure information doesn't get los due to linkrot.
# [12:51] <webben> plus also whether authoring systems require one to update multiple files or just one.
# [12:51] <webben> e.g. RSS is easy with WordPress, it updates automatically
# [12:52] <webben> translations are easy in Java, as translation editors present all the translations with one interface
# [12:53] <hsivonen> webben: do you mean translating Java UIs?
# [12:53] <webben> yeah
# [12:53] <webben> we have a similar system for localization in the template management system we at work; all translations are presented together
# [12:54] <webben> so you see the German French English etc for "Hello World" all at once
# [12:54] <webben> *we use
# [12:54] <webben> although ultimately those translations get pushed into files that are published separately of course
# [12:55] <hsivonen> anyway, my point is that from an authoring perspective, addressing the needs of blind users entails augmenting the page with textual alternatives whereas addressing the needs of those who can't read full-featured English involves a situation similar to translations in general
# [12:56] <webben> hsivonen: That's true for recasting into basic english.
# [12:57] <webben> not so true for providing image alternatives
# [12:57] <webben> which tends to be handled via embedding
# [12:59] <webben> e.g. lot of pages describe something but also show a diagram or picture of it
# [13:00] <webben> equally, in terms of longdesc, you are actually pointing users out to another resource
# [13:00] <webben> which is not that different to <link>ing to RSS or another language
# [13:07] <webben> I think providing a consistent, explicit facility for providing and navigating equivalent content is more important that the question of whether such content is at the same URI. (That's an important question in its own right, but I'm not /as/ worried about it.)
# [13:21] * Quits: hendry (n=hendry@91.84.62.62) ("bbq")
# [14:15] * Joins: Ducki__ (n=Ducki@dialin-145-254-189-090.pools.arcor-ip.net)
# [14:16] * Quits: Ducki_ (i=Ducki@dialin-212-144-083-225.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
# [14:44] * Joins: zcorpan_ (n=zcorpan@90-229-146-10-no117.tbcn.telia.com)
# [14:45] <zcorpan_> Would it be possible to add functionality so that the drawImage call in HTML5 canvas could take an SVGSVGElement as the first parameter?
# [14:46] <zcorpan_> and getting an svg from the HTMLImageElement
# [15:00] * Joins: Jero (n=Jero@d207230.upc-d.chello.nl)
# [15:04] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
# [15:10] * Quits: Jero (n=Jero@d207230.upc-d.chello.nl) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502]")
# [15:22] * Joins: ravenn (n=ravenn@203-217-84-24.dyn.iinet.net.au)
# [15:35] * Quits: ravenn (n=ravenn@203-217-84-24.dyn.iinet.net.au)
# [16:13] * Joins: Ducki (n=Ducki@dialin-145-254-186-128.pools.arcor-ip.net)
# [16:22] * Parts: hasather (n=hasather@22.80-203-71.nextgentel.com)
# [16:38] * Quits: Ducki__ (n=Ducki@dialin-145-254-189-090.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
# [18:04] <Philip`> zcorpan_: I would have thought that'd work most easily if you could just do <img src="whatever.svg">, and used the normal drawImage function
# [18:05] <Philip`> Or do browser people really not like doing SVG in <img>, so it's worth special-casing for SVG images?
# [18:07] <webben> It would be interesting to try and spec how svg text and longdesc is supposed to work alongside alt and longdesc.
# [18:12] * Joins: Ducki_ (i=Ducki@dialin-145-254-187-020.pools.arcor-ip.net)
# [18:26] * Joins: Codler (n=Codler@84-218-6-170.eurobelladsl.telenor.se)
# [18:32] * Quits: Ducki (n=Ducki@dialin-145-254-186-128.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
# [18:33] <zcorpan_> Philip`: it would be nice to be able to pass an SVGSVGElement node as parameter instead of having to use svg via HTMLImageElement
# [18:34] <zcorpan_> Philip`: both are apparently pretty straight-forward to implement (given that svg as HTMLImageElement already works)
# [18:34] <Philip`> Might a generic drawElement(...) be able to handle SVG elements like that, as well as handling drawing of e.g. boxes full of text?
# [18:39] * Quits: eigentone (n=craig@206-248-134-242.dsl.teksavvy.com) (Client Quit)
# [18:39] <zcorpan_> dunno
# [18:40] * Joins: eigentone (n=craig@206-248-134-242.dsl.teksavvy.com)
# [19:29] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
# [19:35] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
# [19:39] * Quits: zcorpan_ (n=zcorpan@90-229-146-10-no117.tbcn.telia.com) (Read error: 110 (Connection timed out))
# [20:09] * Joins: MikeSmith (n=MikeSmit@eM60-254-214-234.pool.emobile.ad.jp)
# [20:10] * Quits: MikeSmith (n=MikeSmit@eM60-254-214-234.pool.emobile.ad.jp) (Read error: 104 (Connection reset by peer))
# [20:10] * Joins: MikeSmith (n=MikeSmit@eM60-254-214-234.pool.emobile.ad.jp)
# [20:12] * Joins: Ducki__ (i=Ducki@dialin-145-254-187-020.pools.arcor-ip.net)
# [20:12] * Quits: Ducki_ (i=Ducki@dialin-145-254-187-020.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
# [20:25] * Quits: webben (n=benh@82.153.85.49) (Connection reset by peer)
# [20:32] * Joins: webben (n=benh@82.153.85.49)
# [20:35] * Joins: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
# [20:58] * Quits: Ducki__ (i=Ducki@dialin-145-254-187-020.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
# [21:04] * Quits: Codler (n=Codler@84-218-6-170.eurobelladsl.telenor.se) ("- nbs-irc 2.21 - www.nbs-irc.net -")
# [21:16] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [21:19] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Client Quit)
# [22:01] * Joins: zcorpan_ (n=zcorpan@90-229-146-10-no117.tbcn.telia.com)
# [22:02] <zcorpan_> ftp doesn't work for me today :|
# [22:26] * Quits: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
# [22:40] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [22:43] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
# [22:48] * Joins: weinig (i=weinig@nat/apple/x-165270d07ed1da52)
# [23:05] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
# [23:35] * Quits: MikeSmith (n=MikeSmit@eM60-254-214-234.pool.emobile.ad.jp) ("Less talk, more pimp walk.")
# [23:47] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
# Session Close: Sun Jul 15 00:00:00 2007

The end :)