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

Hi Erik,

Thanks for your feedback.

(2012/02/21 20:24), Erik Dahlstrom wrote:
>> font -> <font> ?
> The font property shorthand? It uses font-family names, not id's.

Yes, the use case I had in mind was:

   <g font="child">
       ... font def ...

But I think it's not very useful, especially given the state of SVG 
fonts. So I propose not touching the font property.

>> <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.

Yeah, this one doesn't make much sense. Sorry about that.

>> 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.

Ok, I agree. It sounds like the only reason feComponentTransfer differs 
is because it followed what implementations were doing at the time.

> I quite like the proposed syntax.

Thanks! Actually, I think the credit goes to both you and Cameron anyway :)

> 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.

Yes, if we add xlink:href to foreignObject in SVG 2[1] it should follow 
this scheme.

I also agree that it's the presence of the attribute that matters.

Thanks Erik!



Received on Wednesday, 22 February 2012 02:32:57 UTC