Re: [svgwg] <foreignObject> and <svg:use>

The SVG Working Group just discussed `<foreignObject> and <svg:use>`, and agreed to the following:

* `RESOLVED: <foreignObject> in referenced subtrees of the <use> element would not be considered for the shadow tree`

<details><summary>The full IRC log of that discussion</summary>
&lt;krit> topic: &lt;foreignObject> and &lt;svg:use><br>
&lt;krit> GitHub: https://github.com/w3c/svgwg/issues/511<br>
&lt;myles> ScribeNick: myles<br>
&lt;myles> krit: THat was ported by Amelio from Mozilla. &lt;use> in 1.1 and in 1.2 is allowed to refer to foreign object. However, only firefox actually does that.<br>
&lt;myles> krit: Emilio would be fine to drop this support in firefox. and therefore from teh spec.<br>
&lt;myles> AmeliaBR: in SVG 1.1, there was a restriction on directly reusing foreignobject but that was confusing because you could reuse a group that contained a foreign object, that's why it was dropped. THere were concerns with maintinain state like an HTML checkbox between the shadow version and the original version. That's the way it works. There's state in HTML elements that aren't part of styles and attributes.<br>
&lt;myles> AmeliaBR: I'm trying to remember the text in SVG 2 right now. Whether we have any restrictions at all.<br>
&lt;myles> krit: AFAIK there are no restrictions w/r/t foreignObject. Perhaps in the shadow tree?<br>
&lt;myles> krit: I'm also not sure.<br>
&lt;myles> AmeliaBR: We don't have any specific mention of foreignObject in the &lt;use> section.<br>
&lt;myles> krit: Even so, coming back to it, Firefox is the only browser that supports that, i doubt that inkscape, and definitely Illustrator, don't support it. Because the request comes from Firefox, do we agree to drop support?<br>
&lt;myles> s/don't support/support/<br>
&lt;myles> krit: Are there plans in Blink or WebKit to implement?<br>
&lt;myles> AmeliaBR: We would have to clearly define what it means to clone an HTML element inside &lt;use> Otherwise if we encourage people to support it, we will have implementations that are not interoperable.<br>
&lt;myles> krit: myles, dino: Do you have any plans?<br>
&lt;myles> dino: we don't have any plans.<br>
&lt;myles> ericwilligers: &lt;silence><br>
&lt;myles> krit: I would be fine with dropping foreignObject, but it's up to the other members.<br>
&lt;myles> ericwilligers: we don't have any plans to support it.<br>
&lt;dino> dropping foreignObject from &lt;use> right? not dropping it completely.<br>
&lt;myles> krit: yes<br>
&lt;myles> myles: That includes foreignObject inside &lt;g>, right?<br>
&lt;myles> krit: yes<br>
&lt;myles> myles: it's a good idea to drop it.<br>
&lt;myles> AmeliaBR: we would still need to figure out what that means because you might have a &lt;use> that references a tree, where somewhere inside is a &lt;foreignObject>. Does that make the entire reference illegal, or does it just silently drop the html element. What do browsers do?<br>
&lt;myles> krit: WebKit and Blink just ignore the &lt;foreignObject> and its descendents, the rest of the tree is still valid<br>
&lt;myles> AmeliaBR: that sounds the most useful.<br>
&lt;myles> AmeliaBR: as long as its feasible.<br>
&lt;myles> RESOLVED: &lt;foreignObject> in referenced subtrees of the &lt;use> element would not be considered for the shadow tree<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/511#issuecomment-438032185 using your GitHub account

Received on Monday, 12 November 2018 21:19:25 UTC