Re: AW: XHTML 2.0 and hreflang and type

> [Original Message]
> From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
> To: W3C HTML List <www-html@w3.org>
> Date: 11/13/2003 11:29:18 PM
> Subject: Re: AW: XHTML 2.0 and hreflang and type
>
>
> Ernest Cline wrote:
>
> >... if an author wishes to indicate that a png file is preferable to a
gif (As is usually the case. :)) then instead of:
> >
> ><span type="image/png, image/gif; q=0.1" src="../images/115">
> > Image #115
> ></span>
> >
> >One could use:
> ><span type="image/png" src="../images/115.png">
> > <span type="image/gif" src="../images/115.gif">
> >   Image#115
> > </span>
> ></span>
> >
>   Although the above example should work, The reason for making the
> type attribute a list of media types, rather than only a single type is 
> because it is better to be able to use the same URI and receive a 
> different version based on what can be understood by the UA.

Then that would be case for:

<span src="../images/115">
 Image#115
</span>

As can be done using the <img> or <object> elements
in HTML4 already, IIRC.

>   In the example given in section 6.6 of the current working draft 
> (2003-05-06) [1]:
>     <p src="w3c-logo" type="image/png, image/jpeg;q=0.2">W3C logo</p>
> the URI is specified without a file extension, though the actual file 
> delivered by the server will be either w3c-logo.png or w3c-logo.jpg.
>
>   This uses content negotiation with the server, rather than specifying 
> which particular file version is needed within the page.  (The document 
> "Cool URIs don't change" [2], as well as some other various documents on 
> W3, explain this concept much better than I have)
>
> >I see no reason why type should be changed from being advisory as it
> > is in HTML4 to being proscriptive as it is in the XHTML2 draft.
> 
>   Type is only meant to be advice about what content types are 
> available, to allow the UA to build the HTTP request header 
> appropriately.  It just allows multiple content-types to be specified 
> which will be quite useful for some authors.

An expansion from the current single type to a comma separated list of types
(as per the accept attribute in HTML4) for type does make sense, but I don't
think that putting q-values in what is supposed to be advisory info makes
sense.  And if it does make sense for type why does it not make sense for
hreflang or any other attribute that might be proposed  that corresponds
 to an HTTP field that uses q-values?

The introduction of q-values in type will add needless complexity,
 since an author should be able to specify his intended q-values
server-side.

If duplication of something that can be accomplished server-side
is acceptable in this case, what about other things such as redirection?
XHTML2 should be follow a consistent philosophy regarding
server-side vs. client-side issues.

I> [1] 
>
http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-attribute-collections.html#
col_Embedding
> [2] http://www.w3.org/Provider/Style/URI

Received on Thursday, 13 November 2003 10:39:25 UTC