Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

<foreignObject> and <svg:use> #511

Open
emilio opened this issue Aug 2, 2018 · 2 comments
Open

<foreignObject> and <svg:use> #511

emilio opened this issue Aug 2, 2018 · 2 comments
Assignees
@AmeliaBR
Labels
Embedded Content chapter Needs editing Needs tests
Milestone
SVG 2.0 Proposed ...

Comments

@emilio
Copy link

emilio commented Aug 2, 2018

All browsers but Gecko restrict <foreignObject> in <svg:use> elements. I'm considering doing that as well in Gecko.

The reason for this is that allowing <foreignObject> allows random HTML elements there as well. Which means we allow custom elements, which means that the shadow tree is exposed, and when implementations recreate them is exposed as well.

For example, the following test-case logs to the console the internal shadow tree elements from the <use> element, which Blink, WebKit and Gecko recreate when an attribute changes:

<!doctype html>
<style>
  custom-element {
    display: block;
    width: 100px;
    height: 100px;
    background: green;
  }
  custom-element:defined {
    background: green;
  }
</style>
<svg width="100" height="100">
  <defs>
    <g id="g" width="100" height="100">
      <foreignObject width="100" height="100">
        <custom-element></custom-element>
      </foreignObject>
    </g>
  </defs>
  <use x="0" y="0" width="100" height="100" href="#g"/>
</svg>
<script>
  customElements.define('custom-element', class extends HTMLElement {
    constructor() {
      super();
      console.log("no way");
      let parent = this.parentNode;
      while (parent) {
        console.log(parent);
        parent = parent.parentNode;
      }
    }
  });

  g.setAttribute("foo", "bar");
</script>

Note that Blink and WebKit remove after creation the <foreignObject> element, so the custom element is still exposed. This is at best unexpected. I'm considering avoiding creating the <foreignObject> altogether in Gecko, to avoid exposing the point at which we create / re-construct the shadow tree.
@dirkschulze
Copy link
Contributor

@emilio For the Web Components part I suggest opening an issue to the corresponding github repo. That group might be more qualified to judge all implications for referencing a foreignObject (directly or as part of a sub tree).

WebKit did not allow referencing foreignObject for complexity reasons. We did not have the time to look at all implications (including security implications) and the support for foreignObject never was great if the content was HTML based. (Blink fixed the latter part.)

@css-meeting-bot
Copy link
Member

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
The full IRC log of that discussion <krit> topic: <foreignObject> and <svg:use>
<krit> GitHub: https://github.com//issues/511
<myles> ScribeNick: myles
<myles> krit: THat was ported by Amelio from Mozilla. <use> in 1.1 and in 1.2 is allowed to refer to foreign object. However, only firefox actually does that.
<myles> krit: Emilio would be fine to drop this support in firefox. and therefore from teh spec.
<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.
<myles> AmeliaBR: I'm trying to remember the text in SVG 2 right now. Whether we have any restrictions at all.
<myles> krit: AFAIK there are no restrictions w/r/t foreignObject. Perhaps in the shadow tree?
<myles> krit: I'm also not sure.
<myles> AmeliaBR: We don't have any specific mention of foreignObject in the <use> section.
<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?
<myles> s/don't support/support/
<myles> krit: Are there plans in Blink or WebKit to implement?
<myles> AmeliaBR: We would have to clearly define what it means to clone an HTML element inside <use> Otherwise if we encourage people to support it, we will have implementations that are not interoperable.
<myles> krit: myles, dino: Do you have any plans?
<myles> dino: we don't have any plans.
<myles> ericwilligers: <silence>
<myles> krit: I would be fine with dropping foreignObject, but it's up to the other members.
<myles> ericwilligers: we don't have any plans to support it.
<dino> dropping foreignObject from <use> right? not dropping it completely.
<myles> krit: yes
<myles> myles: That includes foreignObject inside <g>, right?
<myles> krit: yes
<myles> myles: it's a good idea to drop it.
<myles> AmeliaBR: we would still need to figure out what that means because you might have a <use> that references a tree, where somewhere inside is a <foreignObject>. Does that make the entire reference illegal, or does it just silently drop the html element. What do browsers do?
<myles> krit: WebKit and Blink just ignore the <foreignObject> and its descendents, the rest of the tree is still valid
<myles> AmeliaBR: that sounds the most useful.
<myles> AmeliaBR: as long as its feasible.
<myles> RESOLVED: <foreignObject> in referenced subtrees of the <use> element would not be considered for the shadow tree

@AmeliaBR AmeliaBR self-assigned this Jul 5, 2019
@css-meeting-bot css-meeting-bot mentioned this issue Sep 19, 2019
Closed
@asmarcz asmarcz mentioned this issue Sep 21, 2019
Closed
3 tasks
@jonathantneal jonathantneal mentioned this issue Oct 5, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@AmeliaBR AmeliaBR

Labels
Embedded Content chapter Needs editing Needs tests
Projects
None yet
Milestone
SVG 2.0 Proposed Recommendation
Development

No branches or pull requests
5 participants
@dirkschulze @emilio @svgeesus @AmeliaBR @css-meeting-bot