[css-display] Should display: contents cause all SVG layout attributes to be ignored? #2502
Previously, it was decided that
In reviewing #2118 (and as discussed on the call recorded in #2118 (comment)), I realized that there wasn't any clear guidance on how
The relevant attributes:
My assumption was that these attributes would be cancelled out by
But there is also the note:
This creates a confusion for
For example: in this code, the
<text y="50%" dy="0 +1em">—<tspan dy="-1em"><a>Where am I?</a></tspan></text>
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
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
But either way, it needs to be stated explicitly, for all the attributes.
The text was updated successfully, but these errors were encountered:
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
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.
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.
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
(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.)
@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!
… issue discussion. #2502