containment probably shouldn't apply to most SVG elements #2987

dbaron · 2018-08-03T17:48:31Z

layout, size, and paint containment probably shouldn't apply to SVG elements other than svg and foreignObject. Currently the spec excludes elements that "do not generate a principal box"... but I don't actually see anything in the relevant definitions that says that these SVG elements don't generate a principal box.

I think it should be the case that they don't, and therefore that layout, size, and paint containment don't apply, but this ought to be defined. (It's also not 100% clear about things like outer svg, svg within an SVG structure, and foreignObject.)

The text was updated successfully, but these errors were encountered:

tabatkins · 2018-08-03T20:57:09Z

At the moment SVG elements don't generate any boxes at all, as they're not defined to interact with the CSS box model in any way, besides the outermost SVG in an HTML document.

dbaron · 2018-08-03T21:00:37Z

What about a foreignObject containing HTML? I'd think that has a box, and contain: paint could apply to it.

tabatkins · 2018-08-03T21:08:14Z

The <foreignObject> still doesn't, it just provides an ICB to the contained <html> element, which does generate a box.

AmeliaBR · 2018-08-03T21:53:30Z

The <foreignObject> still doesn't, it just provides an ICB to the contained <html> element, which does generate a box.

You can't have an <html> or <body> inside a <foreignObject> in inline SVG parsed by the HTML parser.

Ideally, the foreignObject would provide a fixed-height containing block (most browsers do not currently treat it as if it had a fixed height, so you can't set height: 100% on a child) for all child CSS boxes, but I'm not sure whether it is necessary to define it as a CSS box.

Basically, a foreignObject is a CSS box in the sense of having an inner display type (flow-root), but it does not have an outer display type.

More generally, see @tabatkins's comment on the filter / containing block issue:

The proper resolution to this boils down to "actually define how SVG operates in the CSS box model finally", correct?

AmeliaBR · 2018-08-03T22:03:12Z

Focusing on the original issue, containment:

The <svg> element that defines an SVG canvas (that is, root element or a direct child of a non-SVG-namespaced element), does have an outer CSS layout box, and so contain: paint would be useful. These always currently contain: size in practice, although that could change if we ever add auto-calculated viewBox based on the content bounding box. Pending resolution on proper behavior of positioned elements inside foreignObject, such an element would also contain layout indirectly, although it would be the foreignObject that did the actual containing.

For other SVG elements on which overflow applies, much the same points could be made, and so containment could make sense there, too.

For other SVG elements, which don't have boxes other than those defined by their contents or drawing commands, containment doesn't make sense without a lot of special definitions..

dbaron · 2018-08-06T18:38:15Z

So it seems like the right thing to implement is that containment should apply to outer <svg> but nothing else in SVG.

(Note that for containment to make sense, it needs to be clear what it means for an element to establish a containing block for absolutely positioned and fixed positioned elements; see w3c/fxtf-drafts#307.)

…er frames support contain:layout and contain:paint. r=dholbert This is needed for patch 4. This is based both on the wording in the spec and the discussion in w3c/csswg-drafts#2987, and also doesn't support them for nsMathMLContainerFrame, which is similar to inlines and ruby. Differential Revision: https://phabricator.services.mozilla.com/D2815 --HG-- extra : rebase_source : b7e23fb248fa34957ca2d539134e872f5a03f5a8

…er frames support contain:layout and contain:paint. r=dholbert This is needed for patch 4. This is based both on the wording in the spec and the discussion in w3c/csswg-drafts#2987, and also doesn't support them for nsMathMLContainerFrame, which is similar to inlines and ruby. Differential Revision: https://phabricator.services.mozilla.com/D2815

frivoal · 2018-09-06T09:03:31Z

@dbaron and @AmeliaBR , you seem to be in agreement. Could one of you propose a phrasing to be added to the spec?

Agenda+ to try and get closure on this.

css-meeting-bot · 2018-09-12T16:22:37Z

The CSS Working Group just discussed containment probably shouldn't apply to most SVG elements, and agreed to the following:

RESOLVED: containment should apply to outer SVG but nothing else in SVG

The full IRC log of that discussion

<dael> Topic: containment probably shouldn't apply to most SVG elements
<dael> github: https://github.com//issues/2987
<dael> florian: Looking to raise attention and get a consentual answer. Last issue on containment.
<dael> florian: Seemed dbaron and ameliabr were getting somewhere
<dael> chrishtr: Agree with dbaron on outer svg and nothing else
<dael> florian: Can we say that or need to be more specific?
<dael> dbaron: I think applying to outer SVG is pretty straight forward
<dael> astearns: Don't have ameliabr on the call. Shall we resolve on outer SVG and ask Amelia?
<dael> chris: I think there's agreement on outer SVG. And it's what's outside foreign object. TabAtkins is correct foreign object est containing block but that's all it does.
<dael> Rossen_: eq. of iframe basically
<dael> astearns: Prop: containment should apply to outer SVG but nothing else in SVG
<dael> astearns: Obj?
<chris> +1 to proposed resolution
<dael> RESOLVED: containment should apply to outer SVG but nothing else in SVG
<dael> astearns: I'll tag ameliabr for review
<dael> florian: I expect next call to have spec ready for CR. Thanks to Gerard for the test suite

astearns · 2018-09-12T16:23:10Z

@AmeliaBR please let us know if you're good with the resolution above

AmeliaBR · 2018-09-12T16:39:34Z

Sorry I missed the discussion.

I agree that the "outer" SVG should support the containment properties. The wording should be something like "an <svg> element that has an associated CSS layout box" to be consistent with other specs.

As selectors, that looks like:

@namespace svgns url(http://www.w3.org/2000/svg);

svg:root, /* root svg, starts an SVG canvas */
:not(svgns|*) > svg, /* svg that is a child of a non-SVG namespace element, also starts a canvas */
foreignObject > svg /* a new SVG canvas inside a foreignObject */
{ /* containment works */}

I still think it would be perfectly sensible for <foreignObject> and other elements that support overflow: hidden to also support containment, but I also think that's something that could be left undefined/unsupported for now.

frivoal · 2018-09-28T02:42:43Z

Actually, I'm removing the "needs testcase" label here, as there isn't really anything to test. We just defined that the property does not apply to elements where it wouldn't be clear what applying means... It doesn't really seem meaningful to try and test for the lack of effect. If anyone catches a browser accidentally doing something when it should do nothing, we can add tests to wpt to make sure that doesn't happen again, but until then I think no test is needed for this.

…er frames support contain:layout and contain:paint. r=dholbert This is needed for patch 4. This is based both on the wording in the spec and the discussion in w3c/csswg-drafts#2987, and also doesn't support them for nsMathMLContainerFrame, which is similar to inlines and ruby. Differential Revision: https://phabricator.services.mozilla.com/D2815 UltraBlame original commit: 8e24328ba71484dd144b9d0d2fdd287a9327c1b4

dbaron added the css-contain-1 label Aug 3, 2018

AmeliaBR added the SVG label Aug 3, 2018

frivoal added the Agenda+ label Sep 6, 2018

css-meeting-bot removed the Agenda+ label Sep 12, 2018

frivoal closed this as completed in 687c2ff Sep 28, 2018

frivoal added Closed Accepted by CSSWG Resolution Needs Testcase (WPT) Tracked in DoC labels Sep 28, 2018

frivoal self-assigned this Sep 28, 2018

frivoal removed the Needs Testcase (WPT) label Sep 28, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

containment probably shouldn't apply to most SVG elements #2987

containment probably shouldn't apply to most SVG elements #2987

dbaron commented Aug 3, 2018

tabatkins commented Aug 3, 2018

dbaron commented Aug 3, 2018

tabatkins commented Aug 3, 2018

AmeliaBR commented Aug 3, 2018

AmeliaBR commented Aug 3, 2018 •

edited

Loading

dbaron commented Aug 6, 2018

frivoal commented Sep 6, 2018

css-meeting-bot commented Sep 12, 2018

astearns commented Sep 12, 2018

AmeliaBR commented Sep 12, 2018 •

edited

Loading

frivoal commented Sep 28, 2018

containment probably shouldn't apply to most SVG elements #2987

containment probably shouldn't apply to most SVG elements #2987

Comments

dbaron commented Aug 3, 2018

tabatkins commented Aug 3, 2018

dbaron commented Aug 3, 2018

tabatkins commented Aug 3, 2018

AmeliaBR commented Aug 3, 2018

AmeliaBR commented Aug 3, 2018 • edited Loading

dbaron commented Aug 6, 2018

frivoal commented Sep 6, 2018

css-meeting-bot commented Sep 12, 2018

astearns commented Sep 12, 2018

AmeliaBR commented Sep 12, 2018 • edited Loading

frivoal commented Sep 28, 2018

AmeliaBR commented Aug 3, 2018 •

edited

Loading

AmeliaBR commented Sep 12, 2018 •

edited

Loading