-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add paint-order #1696
Add paint-order #1696
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels a quite small feature grouping, but if no other logical home for it, then looks good otherwise.
Good question, and thanks for the reminder to look at it through this lens. I'm not thinking of a logical grouping for this, but there could be one. There are articles an demos on just this feature that make it seem like a standalone feature. https://css-tricks.com/almanac/properties/p/paint-order/ https://nerdy.dev/css-paint-order |
- css.properties.paint-order | ||
- svg.global_attributes.paint-order |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I probably ought to have asked for this previously, but there's no time like the present: are SVG attributes part of their corresponding CSS properties? I'm not sure that's quite right, but it's not wrong either. I think there's two ways to handle this:
- Keep including SVG attrs, but also start assigning these things to an SVG group (maybe even an SVG-in-CSS group?).
- Drop the SVG attributes, then consider SVG more holistically later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's pretty helpful for authors to associate the SVG and CSS versions of a feature like this. They really are the same feature - similar to JS API's being included along side CSS. But I expect in most cases SVG support will be significantly broader/farther back, since these generally start in SVG and then get adopted into CSS. Ideally, if they're not together, they are at least clearly associated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, cool. This works for me. I've had a bit of a look around and it does seem common for SVG and CSS to mentioned in the same setting—let's keep these together. If we want to group the SVG stuff, we can do that later.
features/paint-order.yml
Outdated
@@ -0,0 +1,7 @@ | |||
name: paint-order | |||
description: "The `paint-order` CSS property sets whether the `stroke` is above or below the `fill`. In SVG content, `markers` can also be ordered. For example, `paint-order: markers stroke fill;` will draw the markers, then stroke, then fill." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edits here with these motivations:
- I read "above or below" as meaning the vertical axis and I've made an attempt to clear this up. I don't know if I succeeded.
- Using values as both literals and words strikes me as a bold stylistic choice. Since we don't really know where these things will end up, I'm taking a more conservative approach.
- I should probably write it up in the guidelines, but we ought to prefer the present tense whenever it makes sense.
description: "The `paint-order` CSS property sets whether the `stroke` is above or below the `fill`. In SVG content, `markers` can also be ordered. For example, `paint-order: markers stroke fill;` will draw the markers, then stroke, then fill." | |
description: "The `paint-order` CSS property sets the z-order of strokes, fills, and (in SVG content) markers. For example, `paint-order: markers stroke fill;` draws the markers, then stroke, then fill." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is an improvement. I am on the fence on whether it is clear that the later layers might cover up earlier layers, as it is reliant on the "paint" metaphor, and not explicitly stated. Thoughts?
Co-authored-by: Daniel D. Beck <daniel@ddbeck.com>
Opened mdn/browser-compat-data#24367 to address Safari iOS support in
svg.global_attributes.paint-order
.