SVG and CSS display:contents

[ghost]

While implementing display:contents in Blink, we encountered the question of whether display:contents means an SVG node should be rendered or not. The current draft says all other values than display:none should be rendered [1], but we assume this statement pre-dates the introduction of display:contents. Gecko, which already shipped display:contents, do render SVG nodes for display:contents.

[1] https://svgwg.org/svg2-draft/render.html#VisibilityControl

[AmeliaBR]

This is a good question, but I think the easiest solution is to follow both specs as written.

Hypothetically, if display: contents were to apply for SVG, the logical implementation would be:

• If display: contents is on the <svg> element that is the start of the SVG subtree (i.e., a root element or a direct child of an HTML element), don't switch to SVG rendering mode, don't create an SVG canvas, treat all the child nodes as if they were plain CSS-styled-XML nodes. If there are nested <svg> elements, they each start their own inline SVG canvases.

• If display: contents is on a nested <svg> or a <g>, ignore any transformations applied on that element, including the implicit transformations created by viewBox and x,y,width, and height and the effect they have on percentage units and the user-space coordinate system for child elements. Based on the way <use> behaves in the rendering tree for the Shadow DOM model, it should follow this behavior, with the shadow DOM elements being rendered but without any x/y/transform adjustments from the <use>.

• If display: contents is on an SVG shape, the child elements would be rendered as if they were children of the parent. Assuming the SVG DOM tree is valid, the effect would be that nothing is rendered: any valid child elements of a shape are not rendered when added directly to an SVG canvas.

• Setting display: contents on a never-rendered SVG element type (such as defs or pattern) should not have any effect, consistent with the fact that the display mode can never be changed on those elements. (In SVG 2, we define this using an !important user agent stylesheet rule; previously, it was defined in prose.)

All of this is very complicated, and of questionable utility. The only use case that I could see is being able to turn off SVG rendering mode on an <svg> to render its plain text content (including alt text) as CSS-styled text. However, if that is a desired behavior, it would probably be better to have a more explicit switch.

I am therefore inclined to follow the SVG spec as written (and the Gecko implementation), and say that display: contents should not apply to SVG elements that do not have any CSS layout boxes anyway.

For <svg> elements that are direct children of HTML elements (and do have regular CSS layout boxes for positioning the SVG canvas, and are affected by other display values), the guidance from the Display 3 spec applies:

This value has no effect on replaced elements and form controls; it computes to inline exactly as if the UA style sheet had specified display: inline !important on such elements.

An SVG canvas is a "replaced element" for the purpose of the CSS box tree, so display: contents should be treated as display: inline. (I'm not sure why the !important bit is mentioned; I'm assuming this is a "used value" fix that only applies after all the cascade is calculated. But that's an issue to bring up with CSS WG.)

[tabatkins]

On Mon, Feb 13, 2017 at 12:02 PM, Amelia Bellamy-Royds ***@***.***> wrote: This is a good question, but I think the easiest solution is to follow both specs as written.

I disagree. ^_^ While SVG isn't specced as working with the CSS box model (instead hooking into 'display' directly to do something similar), it's not hard to imagine how it would be implemented, and putting SVG on the box model is still one of my long-term goals. I believe we should act in a way that's consistent with that long-term goal. I do have slightly different opinions on how to do so, tho: * on a root <svg>: nothing displays. The SVG elements generate some special kind of box, that I think only knows how to render if there's an svg-canvas ancestor box. Take that away, and they can't display. They don't magically become block or inline boxes. * on a grouping element (nested <svg> or <g>): the transform/filter/etc that element would apply is ignored, same as you suggest. * on a shape element: I'm inclined to say that nothing renders, because I think it's reasonable to state that, at the language level, shapes suppress the generation of boxes below them. In other words, identical to display:none, because shape elements *only* generate their own box anyway; children are always suppressed. * on a text element: nothing renders - like the relationship of svg boxes to an svg-canvas ancestor, I think svg inline text needs an svg-text ancestor to render. Remove that, and it's suppressed. * on anything else: nothing happens, because they don't generate boxes anyway. The end result is that display:contents and display:none end up almost identical, except display:contents "unwraps" a wrapper element. ~TJ

[fantasai]

Okay, so @tabatkins and I added an appendix to the Display module to break down all of this for discussion: https://drafts.csswg.org/css-display/#unbox Comments/suggestions welcome. CSSWG thread still at w3c/csswg-drafts#540

[dbaron]

The CSS WG just discussed this; see the IRC log. The resolution was:

RESOLVED: SVG elements <g>, <use>, nested <svg>, and <tspan> are eliminated and their contents are hoisted under display:contents but all other SVG elements are display:none'ed

[AmeliaBR]

So to confirm, that means that display: contents on an <svg> that defines an SVG layout context (e.g. root or child of box model) is effectively display: none?

[tabatkins]

Yes, as it's a replaced element in the outer page's context (and there's no good answer for what to do with the contents of the SVG if we did just strip the wrapper).

[boggydigital]

This has been resolved in CSS WG and I don't think there is anything required from SVG WG. This is certainly not blocking updated 2.0 CR publication. Closing the issue