Re: Format for type attribute value

(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.   `._.-(,_..'--(,_..'`-.;.'