W3C home > Mailing lists > Public > www-svg@w3.org > February 2012

Re: Allowing <mask>, <clipPath> etc. to target their parents

From: Brian Birtles <birtles@gmail.com>
Date: Wed, 22 Feb 2012 11:19:03 +0900
Message-ID: <4F445097.5070602@gmail.com>
To: www-svg@w3.org
Hi Robert,

Thanks for your feedback.

(2012/02/21 20:40), Robert Longson wrote:
> What happens if the first direct child does not pass conditional
> processing tests? Do we move onto the next child till we find one that
> does pass?

That's an interesting question. That seems to make sense.

As in:

<rect clip-path="child">
   <clipPath systemLanguage="ja"> ... </clipPath>
   <clipPath systemLanguage="mk"> ... </clipPath>
</rect>

?

Is <switch> useful too? For testing a feature string plus a fallback?

> For textPath any path child would not be directly rendered, right?

I was thinking about this later, and I wonder if it's better to just add 
an attribute (e.g. 'path') to textPath that takes path data. Kind of 
like what we do for animateMotion where you have a 'path' attribute or 
an <mpath> element to refer to a path elsewhere in the doc. For 
textPath, if both 'path' and 'xlink:href' are specified, you use 'path' 
(older user agents fall back to xlink:href).

One disadvantage of that approach is that you can't have a separate 
transform applied to the path data like you can now.

 > And
> no children of feImage directly rendered?

Presumably not.

> Seems kind of pointless for tref so that's explicitly excluded I suppose.

Yeah, there are a few elements that I ruled out for that reason. 
<glyphRef>, <use>, and <mpath>, being a few of the others.

Thanks,

Brian
Received on Wednesday, 22 February 2012 02:19:36 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:50 GMT