- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 25 Feb 2010 15:42:49 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- CC: "public-html@w3.org WG" <public-html@w3.org>
On 24.02.2010 10:18, Maciej Stachowiak wrote: > ... > I would personally recommend option #2. I think if we are going to have > a separate profile spec, then it there's no point mucking with the > profile definition in the HTML5. The separate profile draft would > automatically make this use of profile conforming in text/html so long > as the profile draft is considered an applicable specification, whatever > our IANA registration says. And changing the details of HTML5's > processing requirements would not change. If anything, we should > probably remove most of what HTML5 says about @profile currently. > ... The current language about @profile in HTML5 is: -- snip -- [Supplemental] interface HTMLHeadElement { attribute DOMString profile; }; User agents should ignore the profile content attribute on head elements. When the attribute would be used as a list of URLs identifying metadata profiles, the user agent should instead always assume that all known profiles apply to all pages, and should therefore apply the conventions of all known metadata profiles to the document, ignoring the value of the attribute. When the attribute's value would be handled as a list of URLs to be dereferenced, the user agent must use the following steps: 1. Split on spaces the value of the profile attribute. 2. Resolve each resulting token relative to the head element. 3. For each token that is successfully resolved, fetch the resulting absolute URL and apply the appropriate processing. The profile IDL attribute of the head element must reflect the content attribute of the same name, as if the attribute's value was just a string. (In other words, the value is not resolved in any way on getting.) -- snip -- (from <http://dev.w3.org/html5/spec/obsolete.html#other-elements-attributes-and-apis>) This is simply incorrect. Assuming we *do* publish a separate spec defining @profile, it would remain incorrect and still would need to be fixed. Is the "applicable specification" rule for extensions meant to allow extensions to override "processing requirements"? Best regards, Julian
Received on Thursday, 25 February 2010 14:43:30 UTC