[csswg-drafts] [css-display] Should display: contents cause all SVG layout attributes to be ignored?

AmeliaBR has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-display] Should display: contents cause all SVG layout attributes to be ignored? ==
Previously, it was decided that `display: contents` "unboxes" SVG's rendered containers (`<g>`, `<svg>`, `<a>`), `<use>`, and text formatting elements (`<tspan>`, `<textPath>`, `<a>`).

In reviewing #2118 (and as discussed on the call recorded in https://github.com/w3c/csswg-drafts/issues/2118#issuecomment-378779196), I realized that there wasn't any clear guidance on how `display: contents` applies to SVG layout attributes that don't have direct CSS counterparts.  (At least some of which we would like to eventually map to CSS properties).

The relevant attributes:

- `viewBox` and `preserveAspectRatio` on `<svg>` and a `<symbol>` that is rendered in a `<use>`
- `x`, `y`, `dx`, `dy`, and `rotate` on `<tspan>` (this `x` and `y` doesn't currently map to the new geometry property, since the syntax is different)
- the path for `<textPath>` (whether specified as a link or in the new `path` attribute) and other attributes defining how the text is positioned on the path

(In contrast, `x`, `y`, `width`, and `height` on `<svg>`, `<symbol>`, and `<use>` do all currently map to CSS properties, although with special rules for the interaction of the values on `<use>` with the values on its immediate shadow child.)

My assumption was that these attributes would be cancelled out by `display: contents`, following the [general definition of the `contents` value](https://drafts.csswg.org/css-display/#valdef-display-contents):

> For the purposes of box generation and layout, the element must be treated as if it had been replaced in the element tree by its contents.

But there is also the note:

>  As only the box tree is affected, any semantics based on the document tree, such as selector-matching, event handling, **and property inheritance,** are not affected. [emphasis added]

This creates a confusion for `x`, `y`, `dx`, `dy`, and `rotate` on `<tspan>` which define values that apply to individual characters, and which inherit down through any nested elements to the actual text spans.

For example: in this code, the `dy` value on the `<tspan>` _overrides_ the `dy` value from the parent `<text>`, so that the words end up above the reference dash (negative offset).  If you removed the `<tspan>`, the words would be placed below the dash (positive offset):

```xml
<text y="50%" dy="0 +1em">—<tspan dy="-1em"><a>Where am I?</a></tspan></text>
```
Does the `dy` on the `<tspan>` count as a "layout" feature, and disappear if the `<tspan>` is made `display: contents` (allowing the parent value to apply instead)?

Or, does it count as a property that is "inherited" through the DOM tree to the individual text nodes, which applies regardless of the number of parent boxes?

It's worth mentioning that this "inheritance" doesn't work in the CSS sense of the word. For example, the `0` value on the `<text>` doesn't inherit into the `<tspan>`, because it is consumed by the "—" character.  If we ever converted these attributes to CSS properties, they wouldn't be inherited properties, since there would still need to be SVG-specific code to describe how values are assigned to characters.

So, on reflection, I think it's best if these attributes are also considered to be "layout" of the element with the attribute, and are ignored if you use `display: contents` on that element.

But either way, it needs to be stated explicitly, for all the attributes.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2502 using your GitHub account

Received on Thursday, 5 April 2018 00:24:47 UTC