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

Hi Brian,

Some comments inline.

> -----Original Message-----
> From: Brian Birtles [mailto:birtles@gmail.com]
> Sent: Tuesday, 21 February 2012 4:19 PM
> To: 'www-svg'
> Subject: Allowing <mask>, <clipPath> etc. to target their parents


> cursor -> <cursor>

We've discussed this one in the previous SVG WG call (see http://www.w3.org/2012/02/23-svg-minutes.html#item01). Since CSS is adding x and y to the cursor property, SVG might deprecate the <cursor> element.

> Possible solution:
> ------------------
>
> It would be really nice if a mask etc. could be applied to an element simply by
> making it a child of that element.

I like the idea.

> This is currently how animations work. An
> <animate> element can either refer to its target by xlink:href="#id" or, if no
> such attribute exists, it will default to targeting its parent element.


Why make it the default as this breaks existing content. Why not have something like a 'target-element' property (for lack of a better name) with two values 'parent' or 'by-reference', the default one being 'by-reference'.

> Using that approach, instead of:
>
>    <filter id="myFilter">
>      ...
>    </filter>
>    <path filter="url(#myFilter)"/>
>
> You could have:
>
>    <path>
>      <filter>
>      ...
>      </filter>
>    </path>

This would give:
<path>
<filter target-element="parent">
...
</filter>
</path>

>
> But, of course, that breaks existing content such as:
>
>    <g>
>      <filter id="MyFilter">
>      ...
>      </filter>
>      <path filter="url(#MyFilter)"/>
>      <path/>
>    </g>


>
> I think our next best option is to extend the syntax.
>
> 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."

Somehow I think it's better if the child references the parent, than the other way round.

> For 'xlink:href' attributes it's a bit more difficult since really all 'xlink:href'
> attributes should take the same values.

Didn't we say that we wanted to introduce alternate attributes to xlink:href (e.g. src for image ...) to avoid namespace issues? If this was the case, we would have more freedom to define it as needed.

Cyril
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Sunday, 26 February 2012 23:05:12 UTC