- From: Erik Dahlstrom <ed@opera.com>
- Date: Fri, 24 May 2013 16:45:59 +0200
- To: "Cameron McCormack" <cam@mcc.id.au>, "Stephen Chenney" <schenney@chromium.org>
- Cc: "Chris Lilley" <chris@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
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, 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 Friday, 24 May 2013 14:47:01 UTC