Thanks for the detailed explanation of compat and for filing a TAG
review. The risk of breakage seems low (and I suppose we'll learn how
true that is as the change rides the trains), and breakage in this case
would just be cosmetic (unless someone is doing something really clever).
LGTM1 to ship. Good luck. :)
On 11/3/23 12:19 PM, Stephen Chenney wrote:
Note that I have moved the shipping milestone to M121, and have
created a TAG review issue.
On Thu, Nov 2, 2023 at 10:07 AM Stephen Chenney
<schen...@chromium.org> wrote:
On Wed, Nov 1, 2023 at 11:11 AM Stephen Chenney
<schen...@chromium.org> wrote:
Answers inline. Regarding Ander's comment on the current
base_feature setting: I'll fix that.
Cheers,
Stephen.
On Wed, Nov 1, 2023 at 4:17 AM Yoav Weiss
<yoavwe...@chromium.org> wrote:
On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney
<schen...@chromium.org> wrote:
Contact emails
schen...@chromium.org
Specification
https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
Summary
With CSS Highlight Inheritance, the CSS Highlight
pseudo classes, such as ::selection and ::highlight,
inherit their properties through the pseudo highlight
chain, rather than the element chain. The result is a
more intuitive model for inheritance of properties in
highlights. Specifically, "When any supported property
is not given a value by the cascade ... its specified
value is determined by inheritance from the
corresponding highlight pseudo-element of its
originating element’s parent element."
(https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)
Blink component
Blink>CSS
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
TAG review
None
Features are exempt from a TAG review only when another
vendor has already shipped them. That doesn't seem to be
the case here.
The feature is in the CSS pseudos spec and has been for quite
a while. The CSS Working Group has been discussing issues too
and Safari, at least, is implementing according to the spec. I
think the ship has sailed for any major revision to the
behavior. (For context, there was no feature defined for this
change until recently because it was originally viewed as a
"make the code implement the spec" change.)
TAG Review Issue: https://github.com/w3ctag/design-reviews/issues/914
TAG review status
Not applicable
Risks
Interoperability and Compatibility
The feature is still under implementation in other
browser engines, but the standards are well developed
and there is general agreement on the spec. I think
compat risk is very limited at this time.
Does this feature change the behavior of existing uses of
::highlight and ::selection? Is there risk from breakage
there?
The change aligns the behavior of ::selection with Firefox.
::highlight is already implemented with this behavior. There
was breakage of ::selection due to custom property handling,
which was resolved at the spec level and fixed in chromium
before sending this intent. No other bugs have come in over
the extended period that this has been on for experimental web
platform features (since M111).
My above comment is wrong: The spec defining this feature does
change the behavior of ::selection (not ::highlight) for all
browsers. But evidence suggests that the mitigations that sites
used to work around the old behavior still work with the new
behavior, so breakage is very limited. There was a single source
of significant breakage when the feature was first turned on and
the spec and code have been changed to maintain the former
behavior (related to custom properties on root applying to
::selection). We have had zero other reported bugs from enabling
the feature experimentally.
Some history ... The spec was changed in response to an issue
where Firefox wanted to un-prefix -moz-selection but was not
obeying the old spec. As I understand it, the selection style was
checking for ::selection on the selected element, using it if
found, otherwise using the root selection styling. All
browsers were doing this.
Sites were designed to work around this through the judicious use
of ::selection on various elements. That is, put ::selection on
anything you wanted a specified selection on, and if the
inheritance was wrong, add a more specific ::selection selector.
Hence the heavy use of custom properties to keep all these
::selection declarations in sync. You can see this, for example,
on GitHub where they define ::selection for an element, element >
span, and element > span > span, and again for light and dark
mode. Sass even has an operator with a comment on it saying they
would remove it if the spec is fixed.
This intent to ship does not break sites that have taken this
approach. Specific selectors for ::selection will resolve to
the same properties as they do now. The improvement is that
"element > span::selection" and "element > span > span::selection"
can now be removed in favor of just "element::selection".
/Gecko/: Neutral
(https://github.com/mozilla/standards-positions/issues/548)
emilio@ is active in standards discussions on the
issues, but I am not aware of implementation.
https://bugzilla.mozilla.org/show_bug.cgi?id=1703963
https://bugzilla.mozilla.org/show_bug.cgi?id=1703961
/WebKit/: In development
(https://github.com/WebKit/standards-positions/issues/95)
I have a private email from the Apple engineer tasked
with implementing. I don't want to reveal PI.
/Web developers/: Developer ergonomics is the primary
concern motivating highlight inheritance. See
https://github.com/w3c/csswg-drafts/issues/2474 for
the initial spec discussion related to the behavior of
::selection. See
https://bugs.chromium.org/p/chromium/issues/detail?id=1490471
for
an example of a user seeing unexpected behavior
without this feature.
/Other signals/:
Ergonomics
None.
Activation
No. This reflects the already active behavior for
::selection in Firefox and the already used behavior
for ::highlight, ::spelling and ::grammar.
Security
There are no security risks.
WebView application risks
None
Debuggability
Devtools supports highlight pseudos and correctly
shows the inheritance chain.
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux, Chrome
OS, Android, and Android WebView)?
Yes
There are no cross-platform issues with implementation
and no reason to discriminate on platform.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/css/css-pseudo?label=experimental&label=master&aligned
<https://wpt.fyi/results/css/css-pseudo?label=experimental&label=master&aligned>
highlight-cascade-* covers this functionality. There
are additional WPT that make use of the feature in
https://wpt.fyi/results/css/css-highlight-api?label=experimental&label=master&aligned
<https://wpt.fyi/results/css/css-highlight-api?label=experimental&label=master&aligned>
Flag name on chrome://flags
experimental-web-platform-features
Finch feature name
HighlightInheritance
Non-finch justification
The feature was enabled as experimental way back in
M111 and stayed that way until M116 when it was
switched back to test, and it is back on experimental
for M118. Developers have significant experience with
the feature enabled via experimental web platform
features. There is no value to running a finch trial
given the large amount of existing experience with the
feature.
Requires code in //chrome?
False
Estimated milestones
Shipping on desktop 120
DevTrial on desktop 118
Shipping on Android 120
DevTrial on Android 118
Shipping on WebView 120
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5090853643354112
Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/BbvI5VAguvk
This intent message was generated by Chrome Platform
Status <https://chromestatus.com/>.
--
You received this message because you are subscribed
to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQfdRQU81Cdm2phXD9f4wktm4f%2BReeYJaYVZKLrt_T4rg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQfdRQU81Cdm2phXD9f4wktm4f%2BReeYJaYVZKLrt_T4rg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQV-S4-w5nen9dWqeGRjSx_ietab3MzfF%2B-UdikH-8Hmw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQV-S4-w5nen9dWqeGRjSx_ietab3MzfF%2B-UdikH-8Hmw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0b3fb6e-bc93-4823-a9e8-d3e7f8e4a388%40chromium.org.
