W3C home > Mailing lists > Public > www-html@w3.org > November 2003

Re: AW: Type Attribute

From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
Date: Wed, 19 Nov 2003 20:45:22 +1100
Message-ID: <3FBB3BB2.5070400@postoffice.csu.edu.au>
To: Oskar Welzl <oskar.welzl@pan.at>
Cc: W3C HTML List <www-html@w3.org>

>i would like to add a fourth question:
>4. should the UA identify a remote resource using only the URI given in @src (@data, @whatsoever), or should it be computed from this URI plus @type. (in other words: if you strip @type from an existing tag, will the UA in any case fetch the same file as before?)

   I'm not quite sure what you mean here, but the resource should be 
identified by the URI, and @type simply advises the UA what type(s) the 
resource is available in, and thus allows the UA to decide:
1. Whether or not to request the resource; and
2. Which types, from the available list, are acceptable, and thus
3. Which type to request.
  If @type is omitted, then of course the UA can still request the 
resource as they currently do.

>>  -- Definitions --
>>Advisory: Giving advice, or information, about what content-type(s) 
>>is/are available.  The UA may then continue to take action based on this 
>>advice in any way.  Depending on the protocol in use, or any other 
>>factors the UA takes into consideration, the UA may request only those 
>>types advised of, and/or only those types that can be supported.
>>  The action taken upon receiving the requested resource is indifferent, 
>>regardless of whether that actual type delivered was listed or not.  
>i'm not sure, but reading and re-reading the HTML 4.01 spec over and over again, i think it less likely that they had the faintest intention then that a UA might "request only those types advised of";
Ok, the key to understanding what I meant by saying:
"Depending on the protocol in use, or *ANY other FACTORS* the UA takes 
into consideration, the UA *MAY* request only those types advised of, 
*AND/OR* only those types that can be supported." is in the words I 
carefully chose.

  Take note of the words I have added emphasis to.  "may" means that it 
is completely optional, and the "and/or" means it can do either one or 
both of them.  Since a UA isn't going to request anything it can't 
support, I didn't need to say that it could do neither.  The point that 
I was trying to make, in the shortest and most concise way that I could 
think of, was that there are options that are left for the UA to decide 
based on any factors the UA wishes to consider.  Unfortunately, I seem 
to have sacrificed clarity in favour of shortness.

>if advisory/single-value was meant to be the equivalent to HTML 4.01 in this document, we'd have to re-define "advisory" as
>"...Based on this advice, the UA may decide whether or not to retrieve the resource..."
  That's essentially what I meant by saying: "The UA may then continue 
to take action based on this advice in any way.".  I was just trying to 
be more general with what I said.

>>Cons of Advisory:
>>1. Places no real restriction on what types should be requested or 
>i can't see why this is listed as a 'con'? it's a very neutral fact, if not even a pro. 
  Because I didn't see any point to an advisory attribute if it doesn't 
help to determine what to request.

>>Pros of Prescriptive:
>>1. Clearly defines what is available and what should be requested 
>>(opposite of Advisory Con 1)    
>i see this as a con rather than a pro. *what* should be requested should be expressed in the URI;
  This is where our opinions differ.  Of course the resource being 
requested is in the URI, but the type of resource is expressed in 
@type.  Perhaps, to be clearer, it should have said "Clearly defines 
what is available and what TYPE should be requested" which matches my 
advisory con 1.  Also note that I said "should", not "must", thus 
placing slightly less restriction on the attribute.

> i see no benefit in splitting resource identification into two (or 
> more =>hreflang?) attributes when a URI alone is bad enough.

  Because a canonical URI cannot express, sufficiently, both the 
language and the type.  If it could, what would be the point in having 
either of the attributes?

> <span src="valid-xhtml2" style="width:88px;height:31px" 
> type="image/png">Valid XHTML 2.0!</span>

  If a single, advisory (HTML4) type attribute is used, and the resource 
can be either valid-xhtml2.png, valid-xhtml2.gif or even 
valid-xhtml2.jpg, valid-xhtml2.svg, or any other image type, then what 
is the point of having the type attribute at all, since it is only 
descriptive of one of the possible resources?
  I realise that the multiple types could be nested, but what right does 
the author have to *strictly* enforce a preference of some image types 
over others, onto a user?  As I have essentially said before, nesting 
forces the outer most type to be used in preference to any of the 
others.  Also note that this is not an argument against q-values, since 
I don't believe they would be as strict in most cases.

>assuming that, as in HTML 4.01, this is not the case, the results are different:
>Version a) tells the UA that the image is either GIF or PNG; no decision can be taken with that information (a user agent supporting GIF, but not PNG wouldn't know whether or not to retrieve the file)

Why not?  The multi-value attribute is simply advising of more than one type.  If a user agent can support one or more of the listed types, then it can, and should request the resource.

>...@type in the embedding attribute collection (interestingly enough, not the object-attribute with the same name) and in your proposal has two meanings now:

  Actually, <object> uses the 'Common' collection, which includes the embedding collection.  Why is it also defining its own @data and @type, rather than just using @src and @type from the embedding collection?

Received on Wednesday, 19 November 2003 04:45:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:06 UTC