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

[Robert Burns]

Hi Leif,

[Re: Content-type negotiation as an alternative to ALT, LONGDESC and  
fallback; UA gathering of user preferences; bridging the HTTP  
server / local file system divide ]

I too was thinking this discussion was related to the HTTP discussion  
going on the WG list. One of the problems I see in both situations is  
they both try to rely on a particular transport protocol when I think  
HTML should be mored independent of that. I think Phil's idea is  
interesting as stopgap measure more so than permanent solution. As I  
said before, I would want to make sure there was a way within HTML  
markup alone to accomplish these things.

Having said that, I think you're right that we should include more  
norms and guidance for UAs to handle other aspects of content  
negotiation. I feel language is handled adequately in such browsers  
as Safari by using the system's language preferences. I'd be  
interested in hearing more about the problem as you see it Leif, in  
do that. It would be nice if Safari made that clear in its  
preferences with a button to take the user directly to the language  
preference pane.

Other content negotiation would be good. With resolution independence  
on the horizon, I would really like to see servers and UAs adding  
resolution negotiation for bitmapped based media. Even before  
resolution independence comes to screen media, such negotiation would  
be useful for providing a screen display image separate from the  
image used to print the document. Phil's proposal would suggest the  
need for some sort of equivalent media negotiation. Like you  
suggested Lefi, this could be in the form of listing different media  
types for sub-resources: primarily just ranking video, audio, and  
text, I think

Once this is instituted in servers and UAs, then the problem of  
local / server separation becomes larger. I think the iCab approach  
to solving this is interesting. Extending that to actually select the  
the appropriate file from among several files in the same local  
directory would not be out of the question. In this way, typing an  
URL into the browser and leaving off parts of the filename extension  
could still select the correct file based on user preferences (and  
similar for files referenced within the main document).

Another kind of solution for local files that occurred to me is  
Apple's web archive format. I don't think it currently handles  
content negotiation, but it is an ingeniously file format that  
includes any number of web pages and their sub-resources in the same  
document. It also includes the HTTP headers, so adding content  
negotiation information would also be possible. In other words in  
creating a web archive, the UA would alternately negotiate with the  
server for different content and add each response from the server to  
the archive.

Despite the potentially fruitful avenues for investigation, I still  
want to include solutions as much as possible within HTML markup  
itself. Even with the discussions on the HTML WG list regarding HTTP,  
I'm concerned that many of those problems rely to much on the server  
and the HTTP protocol. Requiring that the server be the authoritative  
source for content type is the problem. Certainly the server should  
be configured to gather and transmit the correct information about  
content type, but making it authoritative is the problem. Here too, I  
worry that by leaning too much on the server for a solution to this  
problem, needlessly complicates the situation. Now to create  
accessible documents, an entirely new set of protocols and RFCs are  
needed. So while I think it's worth pursuing (and the scope of the  
HTML WG certainly includes guidance to UAs like this already)  we  
should still try to make sure the HTML markup can meet the needs itself.

Take care,
Rob

On Aug 26, 2007, at 8:45 AM, Leif Halvard Silli wrote:

> 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