W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: Format for type attribute value

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 11 Aug 2009 00:09:06 +0000 (UTC)
To: Henri Sivonen <hsivonen@iki.fi>, Julian Reschke <julian.reschke@gmx.de>
Cc: "public-html@w3.org List" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0908102348110.6420@hixie.dreamhostps.com>

(Changes mentioned below are not yet committed at this time, though they 
are live on the WHATWG copy of the spec.)

On Mon, 19 Nov 2007, Henri Sivonen wrote:
> 
> Quoting the spec:
> > The type attribute gives the MIME type of the linked resource. It is 
> > purely advisory. The value must be a valid MIME type, optionally with 
> > parameters. [RFC2046]
> 
> For attributes that take "a valid MIME type, optionally with 
> parameters", the spec references RFC 2046. I think this normative 
> reference doesn't meet the level of quality expected of HTML5.
> 
> First, the syntax spec is awfully fragmented. First one has to follow a 
> normative reference to RFC 2045. Then one has to look up additional 
> rules from the future from RFC 2822. Moreover, the syntax doesn't define 
> the syntax for MIME types as such. Instead, it defines the entire 
> Content-Type header for Internet email.
> 
> The syntax for the entire header is gratuitously complex: white space is 
> allowed between tokens in surprising places and there's even syntax for 
> comments hidden in the specs! Preliminary evidence from #whatwg suggests 
> that the full syntax is not interoperably implemented in the browser 
> context.
> 
> Also, the requirement for the MIME type to be "valid" is problematic, 
> because the registration mechanism is dysfunctional. Requiring 
> conformance checkers to know about the IANA registry for e.g. language 
> tags is feasible (and implemented :-). However, it would be unhelpful to 
> flag unregistered MIME types as HTML5 conformance errors, since 
> unregistered types are commonly used interoperably on the Web.
> 
> It seems to me that the spec should refer to section 3.7 of RFC 2616 
> instead. I also suggest not implying that HTML5 conformance depended on 
> the IANA media type registry.

On Mon, 19 Nov 2007, Julian Reschke wrote:
> 
> > It seems to me that the spec should refer to section 3.7 of RFC 2616 
> > instead.
> 
> That's definitively a better way to define it.

Done.


> As far as I can tell, right now most references are work-in-progress. 
> IMHO they really should cite concrete sections, so that a reader has a 
> real chance to find out what's being referenced without having to scan 
> the full text.

If there are specific cases where this would be helpful, please let me 
know. I've done it for a few places, but it's possible there are others 
that would benefit from this.


> > I also suggest not implying that HTML5 conformance depended on the 
> > IANA media type registry.
> 
> I'm not even sure it currently depends on the registry. Does RFC2045/6 
> define "valid" anywhere? I would agree if it said "registered".

I have made it not depend on the registry.


On Mon, 19 Nov 2007, Henri Sivonen wrote:
> 
> No, HTML5 has nothing to do with Internet email headers. In fact, after 
> the experience this morning of reading the referenced RFC instead of the 
> more useful RFC (2616), I'm inclined to presumptively consider any 
> normative references to the email stack RFCs spec bugs in HTML 5.

Unfortunately it seems we still need to refer to them for some stuff (e.g. 
text/plain handling).


On Mon, 19 Nov 2007, Henri Sivonen wrote:
> 
> Moreover, document conformance needs to define if leading and trailing 
> whitespace is OK in the attribute value. (For consistency with other 
> single-valued attributes, I suggest no.) Also, the HTTP definition of 
> LWS doesn't make sense for HTML5 attribute values, so the attribute 
> values should probably allow zero or more HTML5 space characters around 
> the semicolon.

I haven't done anything special here; do I need to? Could you elaborate on 
what you think is needed?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 11 August 2009 00:09:43 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:53 UTC