Update: Due to breakage of the Wordpress editor, and a couple of other sites, we plan to delay the Stable ship milestone to 122.
I'll update the status entry etc. Stephen. On Wed, Nov 8, 2023 at 10:34 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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/CAGsbWzS8U-KU_QE_aWkicYW_1NJDC0hp_j4B9t%2Ba66DqKeENdw%40mail.gmail.com.
