Intent to ship: <svg> and <foreignObject> will be stacking contexts

[Chris Harrelson]

Contact emails chri...@chromium.org Spec https://svgwg.org/svg2-draft/single-page.html#render-EstablishingStackingContex Summary SVG2 specifies <svg> and <foreignObject> to be stacking contexts. Reference: https://svgwg.org/svg2-draft/single-page.html#render-EstablishingStackingContex

Other SVG elements are unaffected by this change. Note that z-index is not supported for non-root SVG elements in Chromium, so the stacking context requirement for those elements would have no effect in any case. Motivation

* Spec conformance

* Interop: three browsers will now agree on this behavior

* Improved cache performance: display lists and texture backings for stacking contexts can be more easily cached

* Implementation complexity: behavior underneath SVG-induced clips, transforms and effects will be simpler and more well-defined

Interoperability risk Firefox: Shipped Edge: Shipped Safari: No public signals Web developers: Positive (a number have bugs have been filed relative to bugs and inconsistencies in foreignObject positioning and paint; this intent is a step towards fixing them) Compatibility risk

The only content which could be affected by this change is HTML content underneath a <foreignObject> element which has z-index.

<foreignObject> appears on about 0.09% of pages. A manual review of the top ranked sites from HTTPArchive and top ranked search result pages from internal Google corpora found no examples with z-index.

Further, since Edge and Gecko both have the proposed stacking context behavior, any such site is broken in those browsers already.

Is this feature fully tested by web-platform-tests?

Yes: the CL to implement this change contains such tests.

Ongoing technical constraints

None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no.

Yes OWP launch tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=723076 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5663772639232000 Requesting approval to ship?

Yes

[Jochen Eisinger]

lgtm1

[Mike West]

LGTM2

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b86826c5-8173-4e4b-8e67-85a643cdea1b%40chromium.org.

[Ojan Vafai]

lgtm3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dcono9OEhTM%2BiNik3fScSZUCPPcOfvXJjuwDxjMVM%3D2Mg%40mail.gmail.com.

[Chris Harrelson]

Update: turns out <svg> is not actually a stacking context on the other browsers, just <foreignObject>. Example here ("text" would not appear on top if <svg> were a stacking context).

I have updated this intent to apply to just to <foreignObject>, and am proceeding assuming LGTMs still apply.

[Robert Longson]

It looks like one of the web platform tests doesn't have width and height attributes on the foreignObject tag. Can those be added so as not to rely on that SVG 2 feature in order to pass the test?

Robert

[Chris Harrelson]

Sure, will fix that.

[Chris Harrelson]

Update: this has now landed, behind the SPv175 flag. For technical reasons we could not get it to work correctly without SPv175. It is expected to ship with M67.

[danb...@gmail.com]

Please do *not* ship this feature in its current state!

It has broken our application (https://app.moqups.com), used by thousands of users daily.

I've reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=842668 that it's now impossible to control the stacking of a <foreignObject> inside a SVG in regards to the other elements.

[Chris Harrelson]

Hi,

I'm sorry to hear this created a problem for your app. Unfortunately, the implementation of <foreignObject> in Chrome has been quite broken in many ways, and we are trying our best to improve it over time and minimize additional issues for existing sites. See this bug for a systemic issue with positioning content under <foreignObject> that this intent-to-ship helped to fix. I will follow up separately on crbug.com/842668 as well.

Regards,

Chris

[Chris Harrelson]

Sorry for the broken bug link, here is the correct one.

[emil...@gmail.com]

I just tested this in Canary. This is really bad. Neither Firefox or Edge exhibit this horrible regression that's breaking our core functionality. Again, please reconsider. This is absolutely going to affect our business before we can do any significant changes to our rendering engine that relies heavily on <foreignObject> for proper text rendering inside SVG.

Thanks,
Emil 

[emil...@gmail.com]

Are you kidding me? Since you guys are the stewards of the Internet now, you should care more about breaking existing apps using web standards properly. I'm one of the co-founders at Moqups. This attitude is simply unacceptable. We're being used by hundreds of thousands of users a month and this regression can simply bury our small business. 

Please reconsider – we've been screwed by the Chrome team with the svg path API deprecation in the past and we had to adopt a non native implementation literally over night, causing our team a lot of stress. This is a regression – please don't ship with it.

Thanks,

Emil 

[Philip Jägenstedt]

Hi Emil,

It sounds like the problem is the combination of this change and z-index? Do you have a link to an SVG where the rendering has changed and where Chrome still doesn't match Firefox or Edge? Perhaps there are as-of-yet unknown edge cases.

Chris, I see that one test involving z-index was added, now available here:

https://wpt.fyi/svg/extensibility/foreignObject/stacking-context.html

Unfortunately screenshots aren't available on wpt.fyi, but Firefox is passing. I've tested it manually in Chrome Dev, Edge and Safari. Chrome Dev now passes it as expected, Safari fails in the same way as Chrome stable does. In Edge, the failure is actually because of https://github.com/w3c/web-platform-tests/issues/11007, and stacking-context.html itself matches the order of Firefox and Chrome Dev.

So... seems like there must be some other case which is broken?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/64db7d80-7ade-4ba2-8934-8fe5457b8b02%40chromium.org.

[danb...@gmail.com]

Philip,

Please see the simplified test case I added to this Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=842668

The change has broken the stacking within a SVG element, which is not the case in any other browser. We've been using the same approach since around 2012 without problems, but this is going to be incredibly disruptive for us.

It's already hard to handle rich (multiline) text inside SVG and foreignObject has allowed us to bypass a host of problems. We cannot implement robust multi-line text layouting with SVG <text> elements in due time, and we've little chance of handling em/strong elements, embedded links, bulleted lists and all that.

In conclusion, we *really* (bankrupcy-level really) need the foreignObjects to respect their stacking order inside an SVG, like it does in all the other browsers.

Thanks,
Dan

[Philip Jägenstedt]

Thanks Dan,

Emil, I didn't pick up that you and Dan both are from Moqups, so I presume https://bugs.chromium.org/p/chromium/issues/detail?id=842668 captures the problem. With the attached fo.html I can confirm that Firefox and Chrome stable have the same behavior.

The issue has the ReleaseBlock-Stable label and Chris is assigned, so no need for me to poke around any more :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f89201a6-9f9f-43a0-b044-74f40d990d5c%40chromium.org.

[danb...@gmail.com]

Ah, I had missed the label, that is wonderful news!
Thank you all,
Dan

[emil...@gmail.com]

God bless you guys :-)

[Chris Harrelson]

Update: all of the reported regressions in paint order have been fixed and merged into Chrome 67.

Thank you for bringing this issue to our attention, and for testing your site on the Beta, Dev and Canary channels! The web is a very big place, and we need your help in our mission to move the web forward, while at the same time preventing regressions in existing content.

Regards,

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5b158dc7-dbbf-47a4-b9ae-3115362d4c59%40chromium.org.

[emil...@gmail.com]

That's amazing. Thanks for the quick resolution. We'll definitely ping back in case we see more oddities with foreignObject. 

To be really honest, we'd like to eventually move away from it, but there are no good alternatives with good typography support within the SVG and canvas worlds. Most online authoring tools are making huge compromises when supporting canvas or SVG based text layout and editing and end up not supporting a lot of international scripts or offering sub-par text support while reinventing the wheel or even compiling OpenType via emscripten. We even looked at the internals of Chromium to see if there's a possibility to vectorize the text on the server side and get its pure SVG output in return (I believe Google Docs used to do this in the past?).

Best,

Emil