W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: Change Proposal for ISSUE-82 (Profile-Disambiguation), was: ISSUE-82 - profile-disambiguation - Chairs Solicit Proposals

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 7 Apr 2010 09:30:58 -0700
Message-ID: <g2h63df84f1004070930l2049f84am5db0d147ece310a6@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "public-html@w3.org WG" <public-html@w3.org>
On Wed, Apr 7, 2010 at 9:21 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 07.04.2010 18:02, Jonas Sicking wrote:
>>
>> ...
>> Why not simply remove any and all mention of @profile from the HTML5
>> specification? This way the separate @profile spec that is being
>> developed (right?) has the freedom to define anything it wants. This
>> would put @profile on par with RDFa and Microdata.
>> ...
>
> I think the answer to this is that the spec still wants to define the DOM
> IDL attribute (which I actually missed when I claimed that there was no
> required implementation behavior).

The *spec* doesn't want anything, it's just a document with no intelligence ;-)

> Thus, we'd still need:
>
> -- snip --
> [Supplemental]
> interface HTMLHeadElement {
>           attribute DOMString profile;
> };
>
> 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 --
>
> I'd be ok with this, avoiding misleading statements about what @profile is
> for, and delegating the documentation to a proper spec.

IMHO we can remove this part too. If really needed it can live in the
separate @profile spec, but it seems to me that that spec should
either define the property on all HTMLElements, or on none of them. If
the latter browsers should remove the implementation of the IDL
attribute. (This is something I'd be ok with doing in firefox
experimentally to see if it would break any websites).

/ Jonas
Received on Wednesday, 7 April 2010 16:31:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:16 UTC