- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 29 Apr 2009 06:49:09 +0000
- To: public-html@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6854 Summary: if attribute values enumerated, allow case-sensitivity for meta content values Product: HTML WG Version: unspecified Platform: All URL: http://www.w3.org/TR/html5/ OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: HTML 5: The Markup Language AssignedTo: mike@w3.org ReportedBy: Nick_Levinson@yahoo.com QAContact: public-html-bugzilla@w3.org CC: public-html@w3.org The present draft requires that attribute values if enumerated be case-insensitive (section 2.4.3). I propose an exception that is narrow and, I believe, won't be a problem for most user agents and conformance checkers. Elsewhere, I'm proposing that page authors be able to classify pages by subject using standard classification schemes. Because many good classification schema exist, it's not feasible to ensure that case will never matter. This information would be used, if at all, by search engines and directory editors; thus, most UAs should be unaffected by case in such a value. In other words, if a UA noncompliantly imposed case-insensitivity and still presented the Web page as the author intended, no viewer's experience would be hampered by that particular noncompliance. Those few users who want their UAs to handle case properly in this context, i.e., to be case-sensitive, would likely be directory editors or search engine managers, for whom custom-built robots would be fine. The exception, therefore, should be in meta elements that include, along with any other keyword-value pairs, the keyword-value pair case-sensitivity="true". The case-sensitivity keyword would be valid only for the meta element containing it; it would have to be repeated by a page author for every meta element to which it is to apply. A value of false or any other value would be the same as the absence of that keyword. Example: If a hypothetical Smith Cataloging System, represented here by the hypothetical keyword name subjectsmithsystem, has classifications for both liquid metals and planets which in the original catalog differ only in case: <meta name="subjectsmithsystem" content="Mercury" case-sensitivity="true" /> would mean the planet, because the search engine robot would see that case-sensitivity is true and so extract "Mercury" and not "mercury". The search engine or directory would then classify the page with planet-relevant pages and not with metal-relevant ones. These keywords do use enumerated values, although the enumeration is to be found in the catalogue referenced by the keyword proposed in the MetaExtensions Wiki and may be composed of many thousands of possible values. If such values are considered non-enumerated, none of this matters because case can be required, as when values are personal names. However, if a value supplied can be validated by a recipient by checking it against a finite list authorized under HTML5 then I think that counts as enumerated. Therefore, I propose that section 2.4.3 (in W3C Working Draft (23 April 2009)) be edited to add the following to the end of the existing 2d paragraph: Exception: For a meta element containing the keyword-value pair case-sensitive="true" and a name-content pair, the content value must be an ASCII case-sensitive match for one of the given keywords that are not said to be non-conforming, with no leading or trailing whitespace. Set "name" and "content" in red each time. This implicitly references section 4.2.5, and therefore the latter section should also be edited by adding the following as a paragraph to the end of the section (before section 4.2.5.1): For a name, the value may be case-sensitive only if in the same element the keyword-value pair case-sensitivity="true" is present, as authorized by section 2.4.3. Set "name" in red. Thank you. -- Nick -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Wednesday, 29 April 2009 06:49:19 UTC