- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 21 Feb 2012 12:24:03 +0100
- To: www-svg@w3.org
On Tue, 21 Feb 2012 06:19:16 +0100, Brian Birtles <birtles@gmail.com> wrote: ... > 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 [3] http://www.w3.org/TR/SVGTiny12/extend.html#ForeignObjectElementHrefAttribute -- 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