- 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>
(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