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

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

From: Erik Dahlstrom <ed@opera.com>
Date: Tue, 21 Feb 2012 12:24:03 +0100
To: www-svg@w3.org
Message-ID: <op.v900mdy5geuyw5@localhost.localdomain>
On Tue, 21 Feb 2012 06:19:16 +0100, Brian Birtles <birtles@gmail.com>  

> font -> <font> ?

The font property shorthand? It uses font-family names, not id's.

> <font-face-uri xlink:href> -> <font>

The font-face-uri element is how to reference external font content sure,  
but you can already put svg font content directly in <font-face> without  
using the <font-face-uri> element.

> For properties we could have:
>   clip-path: <funciri> | none | inherit | child
>If it's 'child', it means "find the first child element that is a  
> <clipPath> and use that."

For the case where there is more than one child <clipPath> element what  
you are proposing is different from how e.g feComponentTransfer [1]  
handles the same case (rationale in [3]). It is however similar to how  
<title> is chosen, and I think it's better to align with <title> here.

> In either case, the absence of xlink:href means, "but what about the  
> children?"
> As well as extending the grammar for various CSS properties, this would  
> also mean changes to the permitted child content of various elements.
> What do you think?

I quite like the proposed syntax.

The foreignObject element in SVG Tiny 1.2 is actually already using the  
scheme you are proposing, where if xlink:href is missing you render the  
children[3]. Note that invalid values in xlink (a broken link etc) do not  
affect the choice, it's only whether the attribute was specified or not,  
same as for the animation elements.

[1] http://www.w3.org/TR/SVG11/filters.html#feComponentTransferElement
[2] http://lists.w3.org/Archives/Public/www-svg/2007Nov/0004.html

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 21 February 2012 11:24:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:34 UTC