- From: Stephen Chenney via GitHub <noreply@w3.org>
- Date: Fri, 27 Mar 2026 02:27:27 +0000
- To: public-css-archive@w3.org
I see the utility of this, for sure, but it's not clear how to make it happen. Firstly these could only apply to `::highlight` pseudos because others would pose privacy risks (revealing spelling errors, for instance, which reveals dictionaries). From an implementation perspective this proposal is hard. At least in Chromium, the geometry associated with highlight area is only computed at painting time and is quite a lot of work. Figuring it out at layout time is possible but making the whole system efficient would be challenging. Painting vs. anchor positioning would also require a different view of the highlight range, because the former operates per text run, while the latter would consider the entire highlight. Then there are 3 fairly significant specification challenges: 1. The same `::highlight` may apply to multiple ranges visible at the same time, and these ranges are JS defined, not declarative (though there is some discussion in WHATWG about using declarative markers for highlights). Which range should be used for the anchor position? 2. The painted highlight for the range may not be a box when the range spans multiple nodes or text offsets that cross line breaks. It could be very far from a box. How do the anchor positioning values map to an odd shape while still seeming visually attached? 3. I can't even imagine how accessibility would be implemented, but we would want some way for systems to announce the popup at the time they traverse the highlighted text. -- GitHub Notification of comment by schenney-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11100#issuecomment-4139669701 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 March 2026 02:27:28 UTC