W3C home > Mailing lists > Public > public-html@w3.org > June 2008

[Bug 5772] New: ID value types too restrictive and inflexible for some use cases

From: <bugzilla@wiggum.w3.org>
Date: Thu, 19 Jun 2008 10:32:24 +0000
To: public-html@w3.org
Message-ID: <bug-5772-2495@http.www.w3.org/Bugs/Public/>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5772

           Summary: ID value types too restrictive and inflexible for some
                    use cases
           Product: HTML WG
           Version: unspecified
          Platform: PC
               URL: http://esw.w3.org/topic/HTML/IdAndTypeID
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Spec proposals
        AssignedTo: dave.null@w3.org
        ReportedBy: rob@robburns.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


* The goals of maintaining document-wide uniqueness for IDs and also achieving
ID persistence are at odds with one another (for example consider pasting
content, and other aggregation of content)
 * Authors may want to uniquely identify an element without desiring the
strictness of the ID data type
 * The xml:id attribute already provides an attribute taking a value of type ID
and only one such attribute is permitted in the XML serialization of HTML5
(though it could potentially be used in both serializations)
 * Authors want consistency between the text/html serialization and the XML
serialization of HTML5
 * Authors and authoring tools already produce documents without carefully
checking the uniqueness of ID values (even within XHTML and XML documents)
within the document of the uniqueness of type ID attributes on each element, so
HTML5 should clearly define interoperable norms for matching such errant IDs,
including matching for:
    - the CSS id/ID selector.
    - DOM id related methods (getElementById).
 * Authors want a way to aggregate content such as articles from different
sites or articles from the same site in a way that does not cause ID collisions
nor id attribute collisions.
 * Authors want to mix arbitrary vocabularies in compound documents that make
use of xml:id as a cross-vocabulary/cross-namespace ID-valued attribute.
 * While including ids in hand-coded HTML can be cumbersome and therefore
authors are likely to include them only for some direct and immediate need,
authoring tools can easily add auto-generated id values to elements or elements
of a particular type. However to ensure document-wide uniqueness, such id
values may end up being difficult to read and type accurately, difficult to
distinguish, and long.
 * The usage of xml:id is still in its infancy and now is the time to shape its
usage and treatment by common UAs.
 * Unique id attribute value violations are common place and so clear
interoperable processing guidance needs to be provided when id attribute value
collisions do occur

(see http://esw.w3.org/topic/HTML/IdAndTypeID for evolving solution proposals)

Also related to improved fragment identifiers
(http://www.w3.org/Bugs/Public/show_bug.cgi?id=5744)

[authoring issue, editing implementation issue, added implementation]


-- 
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 Thursday, 19 June 2008 10:33:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC