- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Wed, 02 Oct 2013 09:48:52 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
Le 01/10/2013 23:37, Tab Atkins Jr. a écrit : > On Tue, Oct 1, 2013 at 1:35 PM, Simon Sapin <simon.sapin@exyr.org> wrote: >> Hi, >> >> We have two drafts with features that refer to an element from the value of >> a CSS property. They do so with two different mechanisms; I think we should >> pick one preferred way. >> >> * The element() function in css-image-4 takes an ID selector. >> * The cross-reference functions in css-gcpm such as target-counter() take an >> URL (which needs to be in the same document and have a fragment identifier.) >> >> Even though the two may seem similar (#foo), they are different in syntax >> (eg. character escaping) and semantics (<a name=foo> is a fragment target >> but not an ID.) > > The syntax is more different than that, actually, since the id > selector can just be "#foo", while a url has to be "url(#foo)". Yes. >> ID selectors are the easiest from a spec point of view: we can just refer to >> the Selectors spec and we’re done. For URLs however, we need to define how >> fragments are mapped to elements or refer to something that does. This is >> probably defined in HTML, but CSS so far is supposed to support any type of >> document and maybe shouldn’t depend on HTML. >> >> URLs on the other hand are very nice for using 'attr(href url)' on link >> elements. 'target-counter(attr(href url), page)', for table of contents, is >> a typical use case for target-counter(). > > I'm fine with defining a more general <element-ref> type, which allows > both ID selectors and <url>s, which can be used for > element()/target-counter()/etc. If we have to deal with defining how fragments map to elements anyway, I don’t see a point in keeping ID selectors for this. Unless we want to extend this to more selectors later? -- Simon Sapin
Received on Wednesday, 2 October 2013 08:49:22 UTC