Re: [svg2] make foreignObject a graphics element

In WebKit and now Blink we've had some problems around foreignObject (or
any other "invalid" tags) inside <use>. It's difficult to be precise, but I
think the underlying cause is the challenge of keeping the instance tree up
to date under all circumstances. Adding the need to keep HTML (or other)
content in a valid state inside <use> seems like a hard thing to get right.

I'm not saying that it's hard to do "something". Rather, its hard to do
enough to be useful while scoping it to make the security attack surface
manageable.

Stephen.


On Fri, May 24, 2013 at 10:45 AM, Erik Dahlstrom <ed@opera.com> wrote:

> On Fri, 24 May 2013 14:05:32 +0200, Stephen Chenney <schenney@chromium.org>
> wrote:
>
>  On Thu, May 23, 2013 at 9:29 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>>
>>  Stephen Chenney wrote:
>>>
>>>  Making foreignObject a Graphics Element would allow it in <use>
>>>> elements, which we absolutely do not want to allow given the current
>>>> semantics of <use>.
>>>>
>>>>
>>> You could get around around that restriction anyway by putting a
>>> <foreignObject> in a <g> and then having your <use> reference the <g>.
>>>
>>>
>> Yes. Dirk's suggestion to explicitly excluding <foreignObject> from a
>> <use>'ed subtree would address the problems, I believe.
>>
>> Stephen.
>>
>
> Could you explain what you see as the primary concern with use referencing
> a subtree that includes a foreignObject? I'm not against restricting it if
> there are good reasons to do so, but in that case those reasons should be
> clearly spelled out in the spec. Are the majority of use+foreignObject
> cases unproblematic? Most actual usage of foreignObject I've seen does not
> use complicated html markup or styling (like needing different css boxes as
> illustrated by the thread below), commonly it's just used for automatic
> text wrapping.
>
> Some good points were raised by Robert O'Callahan here:
> http://lists.w3.org/Archives/**Public/www-svg/2009Oct/0018.**html<http://lists.w3.org/Archives/Public/www-svg/2009Oct/0018.html>,
> I presume that's part of the reason. FWIW I agree that it is desirable to
> not do actual cloning, but that's a separate issue.
>
>
>
> --
> Erik Dahlstrom, Core Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
> Personal blog: http://my.opera.com/macdev_ed
>