- From: Dirk Schulze <dschulze@adobe.com>
- Date: Sat, 25 May 2013 15:16:08 -0700
- To: Erik Dahlstrom <ed@opera.com>
- CC: Cameron McCormack <cam@mcc.id.au>, Stephen Chenney <schenney@chromium.org>, Chris Lilley <chris@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
On May 24, 2013, at 7: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. I do not think that we have a lot of experience in WebKit and Blink with foreignObject and use. As Stephen said, it is a pain to implement it correctly. The security concerns come more with things like iFrame and maybe HW acceleration of certain elements. The later point is more of an implementation detail for the time being. There is no proof that there really are security problems with the former statement. That all together just made us feel we should not investigate further at this point and spend the resources on other things first. This even affects any child elements of a use reference. The following won't be rendered in WebKit/Blink: <g id="referencedByUse"> <foreignObject>….</foreignObject> </g> <use xlink:href="#referencedByUse"/> Greetings, Dirk > > Some good points were raised by Robert O'Callahan here: > 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 >
Received on Saturday, 25 May 2013 22:19:01 UTC