- From: Dan Clark via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Nov 2021 23:23:21 +0000
- To: public-css-archive@w3.org
Thanks for pointing this out! For custom highlights at least, the original intention of the custom highlight [#default-styles](https://drafts.csswg.org/css-highlight-api-1/#default-styles) was indeed for an unstyled ::highlight to yield no visible change in rendering. I had written the spec text with the legacy ::selection behavior in mind, so it doesn't fit with the new [#highlight-cascade](https://drafts.csswg.org/css-pseudo-4/#highlight-cascade) behavior. Maybe we could change [#default-styles](https://drafts.csswg.org/css-highlight-api-1/#default-styles) to something like the following, borrowing some language from [#highlight-text](https://drafts.csswg.org/css-pseudo-4/#highlight-text): > If the author does not specify a custom highlight pseudo-element's color, the text is painted using the color of the next highlight pseudo-element layer below, or if none exists, the colors that would otherwise have been used (those applied by the originating element or an intervening pseudo-element such as ::first-line or ::first-letter). If the author does not specify a custom highlight pseudo-element's background-color, the UA must paint the highlight pseudo-element's background using the value 'transparent'. -- GitHub Notification of comment by dandclark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6779#issuecomment-972264613 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 November 2021 23:23:23 UTC