- From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 Jan 2023 18:55:41 +0000
- To: public-css-archive@w3.org
The problem with `parent()` is that, when used on a pseudo-element, it should get the style from the originating element (there isn't an actual parent) or even, in the case of `::backdrop`, the initial value. I don't follow @mirisuzanne logic above, `prop1: inherit(prop2)` would just set `prop1` to the [inherited value](https://drafts.csswg.org/css-cascade-5/#inherited-value) of `prop2`. It's explicit inheritance. So I like `inherit()` or `inherited()`, with preference for the former for consistency with the `inherit` keyword. The problem that I see with the feature (custom properties seem fine) is that, if this is based on serializations, they aren't completely well-defined or interoperable. For example: ```js document.body.style.counterIncrement = "c"; getComputedStyle(document.body).counterIncrement; // "c" or "c 1" ?? ``` So if I set `body > * { list-style-type: inherit(counter-increment) }`, it won't work if it serializes as `c 1` like in Firefox and Chromium, but it would work with `c` which is what I would expect from the shortest serialization principle. I'm not sure if TypedOM could be a better basis than serialization. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2864#issuecomment-1409161797 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 January 2023 18:55:43 UTC