Re: ISSUE-82 - profile-disambiguation - Chairs Solicit Proposals

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