Re: CSS selectors and xml:id

What I think is missing is a document which defines what things can be
(e.g. ID). An API only works if we have a consistent set of
terminology (i.e. types and methods). ID is a technology-independent
concept, yet isn't defined anywhere independent of the specs that use
it.

What you need is for CSS to reference some other specification and
say, #ID applies to any element that has an ID attribute (as defined
by that spec). Then other specifications can point to that same
document and their structure is an ID structure (e.g. xml:id, <html:*
id, <svg: id="">).

If this is not done, then either one of the two specifications in
question (CSS and xml:id, html, xhtml, etc) must specify the other
explicitly to subscribe to the API. If CSS doesn't say it's #ID
structure references xml:id, <html:* id="">, etc., then those
specifications must reference it.

Orion Adrian

On 5/9/05, Ian Hickson <ian@hixie.ch> wrote:
> 
> On Mon, 9 May 2005, Chris Lilley wrote:
> >>
> >>
> >> but in reality is the tip of the iceberg, as then we would also have to
> >> list the bazillion other ways of having IDs, and would have to track
> >> each and every other way of defining IDs.
> >
> > Not so, as Henry already commented.
> 
> Henry suggested that the spec cover specific mechanisms in detail and then
> refer to others generically. What makes xml:id so special that it needs to
> be covered in detail, normatively? Henry himself pointed out that he
> wouldn't include xml:id in the detailed section.
> 
> 
> >> There is also an option e, and that is the option that the working
> >> group is following. That is, CSS requires that the ID selector match an
> >> element that has the given ID. It then leaves the other specs to define
> >> what IDs an element has. It is up to xml:id to say that it gives an
> >> element an ID.
> >
> > That option would result in no xml:id tests in the test suite, I assume?
> 
> You assume incorrectly. There is no reason for xml:id to be excluded from
> testing any more than there is reason to exclude <html:* id="">, DTD-based
> IDness, DOM3-based IDness, or any number of other ID mechanisms.
> 
> However, to exit CR, only one of these mechanisms need be implemented
> (although it would need to be implemented twice), since what is being
> tested is the #id feature, not the ID mechanisms.
> 
> 
> > So, it would not really help in establishing an interoperable ID
> > mechanism that works even without DTDs.
> 
> If you want to prove that xml:id is interoperable, that would be something
> to test in the xml:id test suite, not the CSS test suite.
> 
> 
> >> Unfortunately, the xml:id specification explicitly doesn't say this.
> >
> > Huh??
> >
> > http://www.w3.org/TR/2005/CR-xml-id-20050208/#dt-id-assignment
> >
> > [Definition: The process of ID type assignment causes an xml:id
> > attribute value to be an ID.]
> >
> > You know, that seems pretty clear to me.
> 
> The spec goes on to state that what the above actually means is out of
> scope of that spec.
> 
> However, if you consider the above to be enough to make the xml:id
> attribute be of type ID, then there is no problem. xml:id already must
> work with CSS.
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 
>

Received on Monday, 9 May 2005 14:32:29 UTC