- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 16 Apr 2010 01:27:14 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
Recorded: http://dev.w3.org/html5/status/issue-status.html#ISSUE-082 Regards, Maciej On Apr 7, 2010, at 8:49 AM, Julian Reschke wrote: > On 24.02.2010 14:00, Sam Ruby wrote: >> ... >> If you don't think it is a good use of our time, the alternative is >> to >> simply close the issue without prejudice. If we get to the point >> where >> somebody actually puts together a coherent and actionable proposal, >> we >> can discuss it at that time. >> >>> Best regards, Julian >> >> - Sam Ruby >> ... > > Here's a Change Proposal for this issue. I apologize for the delay. > Also, it's a bit strange to force a proper description of @profile > into an "implementation requirements" section, as @profile is > totally advisory, and to ignore it is totally ok. But the current > spec says "should ignore", and that's why we're debating this. > > With this explanation, on to the change proposal: > > SUMMARY > > Subsection 11.3.4 ("Other elements, attributes and APIs") of section > 11.3 ("Requirements for implementations") talks about implementation > requirements for the head/@profile attribute. > > This in itself is a bit strange, as there actually is no *required* > behavior for head/@profile - it is an annotation, and its use is > totally optional. > > That being said, the actual text is both misleading and inaccurate. > This proposal attempts to fix this description; a broader change > would be to actually document head/@profile properly as conforming > attribute. > > RATIONALE > > Stated "implementation requirements" should actually describe the > main use case of head/@profile (which is disambiguation); they > currently do not. > > DETAILS > > The current text (as of 2010-04-07) reads: > > "...User agents should ignore the profile content attribute on head > elements." > > Comment: if they "should" ignore it then there is no implementation > requirement, right? > > "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." > > Comment 1: The condition "When the attribute would be used as a list > of URLs identifying metadata profiles" first of all is untestable, > second of all it's always true according to HTML4. > > Comment 2: "...the user agent should instead always assume that all > known profiles apply to all pages..." -- this neglects the case > where the attribute value is actually needed to disambiguate to > extensions that use the same syntactical extension point. > > "When the attribute's value would be handled as a list of URLs to be > dereferenced, the user agent must use the following steps:" > > Comment: Untestable. > > The proposed new text addresses the main issue being that profile > URIs may be needed for disambiguation, thus, *in general*, can't be > simply ignored. > > Proposed new text: > > -- snip -- > [Supplemental] > interface HTMLHeadElement { > attribute DOMString profile; > }; > > The profile attribute contains a set of white-space separated meta > data profile names in the form of URLs. > > Processing of meta data profiles is optional. > > Meta data profile names can both be globally unique names, or links > to further information to be dereferenced. > > In the first case, the mere presence of a profile name can be used > to enable profile-specific extensions. This can be important in case > the user agent supports multiple extensions that can not be > disambiguated without this additional annotation. > > In the second case, the profile name can be resolved relative to the > head element, resulting in an absolute URL that can be fetched for > 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 -- > > IMPACT > > 1. Positive Effects > > The misleading statement about "should ignore" is removed; the > actual use case is explained. > > 2. Negative Effects > > Stating the actual use case may cause people to question why the > profile attribute is considered obsolete in the first place. > > 3. Conformance Classes Changes > > None. > > 4. Risks > > None. > > REFERENCES > > None. > > Best regards, Julian >
Received on Friday, 16 April 2010 08:27:48 UTC