Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
AmeliaBR opened this issue Apr 5, 2018 · 6 comments

Comments

@AmeliaBR
Copy link
Contributor

AmeliaBR commented Apr 5, 2018

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 #2118 (comment)), 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 don't currently map to the new geometry properties, 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:

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):

<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.

@AmeliaBR AmeliaBR added css-display-3 Current Work SVG labels Apr 5, 2018
@frivoal
Copy link
Collaborator

frivoal commented Apr 5, 2018

White / black listing all the svg attributes in a CSS spec does not sound like the right way forward. It's not very maintainable.

We should have categories, and say FOO attributes on display:contents svg elements are suppressed and have no effect, while BAR attributes continue to affect descendants.

Based on this discussion, I'm guessing that FOO and BAR are not existing categories, but we should consider creating them. Ideally they should be in the SVG spec(s), so that any time a new attribute is created it is defined which category it belongs to.

@AmeliaBR
Copy link
Contributor Author

AmeliaBR commented Apr 5, 2018

If we go with my final suggestion, and don't add a special case for the text layout attributes, then it would be "any attribute that affects the rendering of child (or shadow-child) elements". Maybe with extra clarification that "presentation attributes no longer apply on this element but follow the normal CSS inheritance rules, including inheritance to anonymous text nodes."

So that's another argument in favour of keeping it simple.

@fantasai
Copy link
Collaborator

fantasai commented Apr 5, 2018

I think the rule here should be, if this attribute were mapped to a CSS property, would it inherit or no? If it wouldn't inherit, then it goes away with display: contents. If it would inherit, then it behaves as if it did. Because there's been an ongoing trend of converting SVG attributes to CSS properties, and we wouldn't want to have any difference in behavior as that process continued.

(Note that some CSS properties that affect descendant content aren't inherited because we needed to know exactly at which point in the tree they were applied and/or because their effects accumulate. The same is likely to be true of some SVG attributes.)

tabatkins added a commit that referenced this issue Apr 20, 2018
* [css-display] Describe SVG unboxing with element categories

Fixes #2118

* [css-display] Clarify impact of display: contents on SVG attributes

Addresses #2502

* [css-display] Add an issue re SVG attributes & display: contents
@AmeliaBR
Copy link
Contributor Author

If you're closing this issue @fantasai, then you also need to update the spec.

124396a
adds an inline issue pointing here as an open issue for discussion about "Is this description clear enough to identify the SVG attributes affected by display: contents?"

fergald pushed a commit to fergald/csswg-drafts that referenced this issue May 7, 2018
* [css-display] Describe SVG unboxing with element categories

Fixes w3c#2118

* [css-display] Clarify impact of display: contents on SVG attributes

Addresses w3c#2502

* [css-display] Add an issue re SVG attributes & display: contents
@fantasai
Copy link
Collaborator

@AmeliaBR Thanks for the warning. Tightened up the wording a bit, so I think it should be fine unless there are some regular (non-presentation) attributes that ought to inherit but aren't yet defined as being properties. (See #2502 (comment)) Let me know / reopen the issue if you think it needs further adjustment!

@AmeliaBR
Copy link
Contributor Author

LGTM. Thanks @fantasai

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants