- From: Stephen Chenney <schenney@chromium.org>
- Date: Thu, 23 May 2013 20:34:15 -0400
- To: Chris Lilley <chris@w3.org>
- Cc: Erik Dahlstrom <ed@opera.com>, "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <CAObCcUoDf=vDdxWvr7P8Er_9b1=JhNXuwxkehDofgy1mnP1tpg@mail.gmail.com>
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>. Stephen. On Thu, May 16, 2013 at 10:37 AM, Chris Lilley <chris@w3.org> wrote: > Hello Erik, > > Thursday, May 16, 2013, 10:37:09 AM, you wrote: > > > Robert Longson discovered in [1] that foreignObject is neither a > 'graphics > > element' nor a 'container element' in svg at the moment. The consequence > > being that some properties that normally apply to rendering elements > don't > > apply to foreignObject, such as 'filter', 'mask' and 'clip-path' to name > > just a few. I think this is an oversight that should be corrected, most > > implementations do apply these properties to foreignObject already (as if > > it was a 'graphics element'), see [2] and [3]. > > I suspect that its not so much an oversight, more that it was seen to > be in neither of those categories because its used by another markup > language. > > However, as an interface element, it needs to have an SVG category 'on > the outside' and be owned by the other language 'on the inside'. I > agree that it should be seen as a graphics element in that context. > > > Proposal: Make foreignObject a graphics element. > > > Rationale: Making foreignObject a container element would imply that it > > can contain other graphics elements and container elements as direct > > children, which may be ok technically, but I'd consider it bad practice. > > > > [1] > > > http://stackoverflow.com/questions/16320863/svg-image-mask-not-working-in-firefox-or-ie > > [2] http://jsfiddle.net/xeK2m/ > > [3] http://jsfiddle.net/UYZW9/ > > > > > -- > Best regards, > Chris mailto:chris@w3.org > > >
Received on Friday, 24 May 2013 00:34:45 UTC