Issue with "<foreignObject>": …

[chozandrias76]

MDN URL: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject

What information was incorrect, unhelpful, or incomplete?

If a foreignObject is not supplied a width and a height on Safari, it will not display.

Specific section or headline?

What did you expect to see?

a foreignObject rendered in Safari

Did you test this? If so, how?

D3 rendering of an svg:

const labelTexts = barsGroup
      .append("foreignObject")
      .attr("class", "label")
      .attr("width", barWidth + spaceBetween)
      .attr("height", 200) // Wouldn't render without this attribute
      .text((d) => d[0]);

MDN Content page report details

• Folder: en-us/web/svg/element/foreignobject
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject
• GitHub URL: https://github.com/mdn/content/blob/master/files/en-us/web/svg/element/foreignobject/index.html
• Report started: 2021-01-14T16:50:47.897Z

[sideshowbarker]

@mdn/yari-content-svg probably has some insight and guidance on this one

[chozandrias76]

I was also able to get the element to render by toggling overflow on and off strangely. This was not reproduceable on firefox or chrome.

[Ryuno-Ki]

I cannot investigate here due to lack of a macOS machine.

[Ryuno-Ki]

@chrisdavidmills Do you use a macBook? Can you check with Safari to at least confirm the issue? I can add a note under the live example then to denote the requirement to define those attributes for Safari.

[sideshowbarker]

@Ryuno-Ki I have a macbook. Do we have a ready-made test case for this somewhere?

[Ryuno-Ki]

const labelTexts = barsGroup
      .append("foreignObject")
      .attr("class", "label")
      .attr("width", barWidth + spaceBetween)
      .attr("height", 200) // Wouldn't render without this attribute
      .text((d) => d[0]);

I could extend this to a test case (or even go with Vanilla JS). Where would I place the test case and allow you to commit on top of it, @sideshowbarker?

[sideshowbarker]

Where would I place the test case

jsfiddle or codepen?

Maybe this is already a known issue. I found some possibly-related Stack Overflow questions:

• https://stackoverflow.com/questions/51313873/svg-foreignobject-not-working-properly-on-safari
• https://stackoverflow.com/questions/38624603/svg-foreignobject-doesnt-display-in-safari
• https://stackoverflow.com/questions/8185845/svg-foreignobject-behaves-as-though-absolutely-positioned-in-webkit-browsers/31303446#31303446

[Ryuno-Ki]

@sideshowbarker Created https://codepen.io/Ryuno-Ki/pen/ZEBxrmj?editors=1100

Interestingly, I cannot see the div on the right hand side either (the one without height / dimension attributes). That being said, if I add the height attribute (via Inspector) and remove it again (via the checkbox their) the div remains visible.

[sideshowbarker]

OK, thanks — what I get for that in Safari is this:

…that is, nothing seems to be rendered at all.

[Ryuno-Ki]

That's less than I saw :-( Most likely something wrong with the code … I'll try to investigate.

[chozandrias76]

I'm able to view both rectangles equally with the following HTML + CSS

<p>This CodePen serves as demo case for a bug in Safari.</p>
<p>For this, we have two SVGs. One of them contains a <code>height</code> attribute, while the other does not.</p>
<p>It was reported in <a href="https://github.com/mdn/content/issues/1319">mdn/content#1319</a>.</p>

<div class="container">
  <svg viewBox="0 0 100 100" width="100" height= "100" xmlns="http://www.w3.org/2000/svg">
    <foreignObject x="20" y="20" width="40" height="40">
      <div xmlns="http://www.w3.org/1999/xhtml">
      </div>
    </foreignObject>
  </svg>
  
  <svg viewBox="0 0 100 100" width="100" height="100" xmlns="http://www.w3.org/2000/svg">
    <foreignObject x="20" y="20" width="40">
      <div xmlns="http://www.w3.org/1999/xhtml">
      </div>
    </foreignObject>
  </svg>
</div>

.container {
  display: flex;
  gap: 1rem;
}

svg {
  background-color: rebeccapurple;
}

svg foreignObject {
  overflow: visible;
}

svg foreignObject div {
  background-color: lime;
  height: 40px;
  width: 40px;
}

Removing

svg foreignObject {
 overflow: visible;
}

Causes the righthand SVG to not display.

[chozandrias76]

Note: On safari, svgs containing elements still have to have sizes IIRC.

[Ryuno-Ki]

@sideshowbarker Would it be okay for you to let me update the codepen? I can add a button or checkbox to toggle the rule for

svg foreignObject {
 overflow: visible;
}

[chozandrias76]

Toggling the rule off after it has already been set doesn't appear to set it back to the state if you had never added the selector in the first place.

[Ryuno-Ki]

That becomes more interesting as we go >_< Okay. Two pens then?

[sideshowbarker]

@sideshowbarker Would it be okay for you to let me update the codepen?

Sure — fine by me

[Ryuno-Ki]

Dang, missed the notification on this. Okay, two codepens then.

[chozandrias76]

I get this to display in Safari 12 with a virtual browser: Adding width and height % to both.

<p>This CodePen serves as demo case for a bug in Safari.</p>
<p>For this, we have two SVGs. One of them contains a <code>height</code> attribute, while the other does not.</p>
<p>It was reported in <a href="https://github.com/mdn/content/issues/1319">mdn/content#1319</a>.</p>

<div class="container">
  <svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
    <foreignObject x="20" y="20" width="60" height="60">
      <div xmlns="http://www.w3.org/1999/xhtml">
      </div>
    </foreignObject>
  </svg>
  
  <svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg" style='width: 100%; height; 100%;'>
    <foreignObject x="20" y="20">
      <div xmlns="http://www.w3.org/1999/xhtml">
      </div>
    </foreignObject>
  </svg>
</div>

.container {
  display: flex;
  gap: 1rem;
}

svg {
  background-color: rebeccapurple;
  width: 100%;
  height: 100%;
}

svg foreignObject {
  overflow: visible;
  display: contents;
}

svg foreignObject div {
  background-color: lime;
  height: 40px;
  width: 40px;
}

[dscotese]

I have explored this issue a little bit and my conclusion is that @chozandrias76 has a codepen that demonstrates a bug in Safari, and testing (https://github.com/mdn/content/issues/1319#issuecomment-792308225) has shown that the overflow CSS property on the foreignObject does not behave properly, which kind of confirms that there is a bug in Safari, at least the version he tested. If anyone is interested in exploring the way to handle Safari bugs (which I argue is beyond the scope of MDN), they should be able to get what they need from the comments on this issue so far.

Therefore, I recommend that this issue be closed, unless MDN wants to take on the role of letting people know about bugs in the software that claims to implements the standards. If we do want that role, then the testing of Safari versions to see if and when this bug was fixed is the next step here.

[Josh-Cena]

Therefore, I recommend that this issue be closed, unless MDN wants to take on the role of letting people know about bugs in the software that claims to implements the standards. If we do want that role, then the testing of Safari versions to see if and when this bug was fixed is the next step here.

The typical way to do this is to search in the Webkit bug tracker. If the bug is open and confirmed, then we should update BCD to note about the temporary inconsistency expected to be reconciled. If the bug is closed as working-as-intended, then we should update the content prose to note about the intended inconsistency expected to persist forever. Nevertheless, inconsistencies need to be exposed to readers.

[dscotese]

https://bugs.webkit.org/show_bug.cgi?id=90738 is an effort to harmonize HTML and SVG which has been ongoing for 10 years. I didn't study it enough to tell, but the second to last comment on it is "This is ongoing work." It seems safe to reference the bug and point out that SVGs in Safari need to be tested by the page author because, as that bug insinuates, Safari's handling of SVG, especially for foreignObjects (because they hold HTML), does not yet behave exactly right.

What is BCD?

If my work on the mdn/content project in the last few days has any chance of finding me paid work, I'd like to know.

[hamishwillee]

@dscotese I have not read the rest of this thread, so a fly-by comment

What is BCD?

BCD is browser compatibility data, which is maintained in this directory https://github.com/mdn/browser-compat-data

Essentially if there is some compatibility issue between browsers we try to keep it all in that repository. This then gets displayed in the Browser Compatibility section of each page, referenced from a front-matter key at the top of the pay. We try to avoid any comments about different implementations in the body of the MDN docs. The BCD is also used by other tools and services, such as canIuse.com

If my work on the mdn/content project in the last few days has any chance of finding me paid work, I'd like to know.

IMO only, probably not directly.

The people who see these changes are a mix of employees or contractors or volunteers. They are not there looking for new employees. I guess if you were to hang around for some months and prove to be a great asset in some area you might get approached when someone was needed.

When I've been looking for work I've found being able to talk about my contributions to open source have been useful once I already have an interview.

I certainly don't want to discourage you - you're doing good stuff. But nor should you be here under some kind of false expectation.

[Josh-Cena]

After some research, it appears to me that Safari's SVG implementation is generally buggy—to the point that you probably shouldn't assume anything without tests. They are working on a new SVG engine: https://wpewebkit.org/blog/status-of-lbse-in-webkit.html that should fix most of this stuff, which explicitly includes <foreignObject>. The originally given jsfiddle can be fixed by giving the SVG an explicit size. So I'm going to take a judgment call and say we shouldn't change either BCD or content since it's such a major issue rather than a single incompatibility. If someone disagrees with this decision, please yell loudly at me and we can reconsider what exactly to do.