LGTM3 On Wednesday, November 8, 2023 at 4:18:59 PM UTC+1 Daniel Bratell wrote:
> LGTM2 > > You may want to ping the Mozilla standards position issue and let them > know that we are close to shipping. It looks like they forgotten it. > > /Daniel > On 2023-11-06 16:43, Mike Taylor wrote: > > 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 >>>>> >>>>> 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 >>>>> >>>>> >>>>> 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0b3fb6e-bc93-4823-a9e8-d3e7f8e4a388%40chromium.org?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/59fd80fc-a34f-49a9-af50-75aba75d649en%40chromium.org.
