[html4all] [html4all.org] Content-type negotiation as an alternative to ALT, LONGDESC and fallback

[Leif Halvard Silli]

2007-08-26 10:38:10 +1000 Jason White <jason at jasonjgw.net>:
> On Sat, Aug 25, 2007 at 08:20:34AM -0500, Robert Burns wrote:
>> I have to say that is an intriguing idea. I had never though of  delivering 
>> text instead of an image through negotiation. I'll have to  think about it 
>> further, but it might be a workable solution in some  settings. I wouldn't 
>> want us to just give up on providing an HTML  solution to the problem, but 
>> until that solution exists, this could  work.
> 
> The main problem is that HTML (and XHTML) documents are not always served via
> HTTP. If they are on my local file system, or a networked file system such as
> NFS or AFS, there won't be any HTTP negotiation.

This is a problem thing related the bridging of offline and online. W3C advice that we use <example.com/Alt> rather than e.g. <example.com/Alt.html> in URLs. Cool URIs dont change. [1] 

iCab «makes sense» of e.g. localfile.html.utf8 - it understand that the page is in UTF-8 encoding. It is the only browser that does so, I think. But iCab does not have something like "local content negotiation". So it does not allow me to paste 'file://localfile' into its URL-field, and the get localfile.html.utf8 served (as it would have happened in a configured web server, if my UA announces that it prefers Russian pages in UTF8 encoding).

But not only the page-URIs can be cool. Even the URIs and file paths within the page has to be cool, if this idea should work. And the iCab feature does not help here - since it has no local content negotiatoin "thing". And thus, we have the problem that Jason mentions.

However (see below)

> Serving HTML over ftp is possible, and sometimes happens.
> 
> Finally, not all authors are able to configure their servers, as in certain
> hosted situations.
> 
> Thus, while it may work in some cases, it isn't a substitute for a solution
> implemented entirely in markup;

I agree, almost.

> and I wouldn't mention it on the main list, as
> it could then lead to a debate about the circumstances in which it is
> inadequate, distracting attention from the problem of deciding what
> markup-based solution the spec should provide.

We are allready discussing HTTP and how to bridge the gap between local editing and online serving. Everything depends on everthing, as one politician said [2]. And this is an example of that. Bettering the gap between local editing/online reading, could better the accessibility situation.

So, we have to think of something that could make this work - offline. Here are some ideas about how UAs could improve:

It should be possible to define possible file extensions somewhere. And then, the browser would, when it found <img src="image"> it would compare the files beginnign with the name 'image' against a list of preferred extensions.

Example: We have 'localpage.html.utf8.ru'. Internally, it uses "cool URI". For offline browsing, there exists a _local/offline_ HTML profile somewhere for this page. This profile specifies a file extension hierarchy for each mediatype this page is aimed at. The hierarchy must list extensions for media type, for language and for for encoding.  For media types it e.g. lists the possible file extensions for <img src="image.???"> for each media types (aural, screen etc).

For all this to be usefull, we need one more thing: the UA must identify itself correctly. And it must be simple for the author to change the UA identity, in order ot test how the page then works! 

Currently many UAs can e.g. identify themselves as Internet Explorer. But are there any GUAs which can identify themselves as aural UAs? And how simple - no, difficult - isn't it to change the preferred language of the UA? 

But in order to make the above useful, users/authors must be able to change the web browsers's _media identity_ - so that, when the browser present itself as an aural browser, it will read what aural browsers would read. I have sofar not heard about any UA that is able to to this! This would be useful in both an online and offline situation! 

Because, the preferred language of the UA should be part of the UA's «network identifacion profile». I mean: it should be much simpler than it is ot change the preferred language of the UA. (iCab is perhaps the simplest one there ... ) For instance, on Mac OS X, we might say that this have worsened: The preferred language of Safari and Opera and (I believe) Camino always equals the preferred language of that Mac OS X user. It isn't even possible to change it without going into the system preferences! Unlike in Firefox and iCab, where it is independent. For authors, this is very impractictical.

[1] http://www.w3.org/Provider/Style/URI
[2] Gro Harlem Brundtland

Leif Halvard Silli