Re: [css-masking] Referring to elements from CSS. (In, but not limited to [css-images-4] and [css-gcpm])

On Oct 9, 2013, at 3:21 PM, Simon Sapin <simon.sapin@exyr.org> wrote:

> Le 09/10/2013 11:25, Dirk Schulze a écrit :
>> I agree that it is better to come up with a general proposal that we
>> accept for all specifications. For this reason I removed select() and
>> child from the first level of CSS Masking. This gives us enough time
>> to discuss element selecting and we don't need to rush it.
>> url(#fragment) for element referencing still needs to be supported
>> for legacy reasons anyway.
> 
> Although this is another case of "everyone at this table knows what this 
> means", for the spec to be well-defined CSS Masking will, like GCPM, 
> need to define (or refer to something that defines) exactly how 
> url(foo.svg#bar) is mapped to a single element.
> 
> * What is the base for relative URLs? (V&U probably already covers this)

This is already covered by URI in RFC3986 (and respecified in the WHATWG URL spec).

> * If the URL (fragment aside) is for another document, is an external 
> resource fetched? (The answer here might differ for Masking and GCPM)
Yes, it is fetched with specific security implications specified in the Security section. There are further implications that implementations already handle, but need to addressed by SVG and the SVG WG separately. The SVG WG is already aware of this and we work on a specification called "SVG Integration" that eventually will specify these implications in detail. Again, these are SVG specifics.

> * What happens if the URL has no fragment?

The spec requires a fragment and specifies what happens if this fragment is not present or not valid.

> * How is a fragment mapped to an element? (Not just IDs, but <a name> etc.)

This is not in the scope of CSS to define. See next comment.

> * What happens if more that one element have that ID/name?

This must be handled by HTML and other host languages. For CSS the definition of a fragment is important (and already specified). 

> 
> These issues are not especially hard, but they need normative statements.

I believe that these issues are already handled in this specification or derived specifications/external specifications that are either normatively referenced in this specification or by other (also) normatively referenced specifications.

Greetings,
Dirk

Received on Wednesday, 9 October 2013 14:28:06 UTC