Re: [blink-dev] Re: Intent to Ship: Add containerName and containerQuery, update conditionText

['Daniil Sakhapov' via blink-dev]

Now I see, thanks!

Firefox has updated their implementation and is up-to-date.
Safari hasn't done anything yet from what I can tell. I will ping them.

Long live the web platform!

On Tue, Jan 24, 2023 at 7:00 PM Rick Byers  wrote:

> Sorry I wasn't clear. I mean that WebKit and Gecko have implementations of
> container queries, do they already support these properties? If not, we
> want to ensure they're aware of the spec change and have open bugs tracking
> making updates to their engines to reduce the likely time period for
> inconsistent behavior between browsers especially since there's some web
> compat risk around conditionText.
>
> In general we're looking for signals from the other engines. This is what
> the Safari and Firefox signals portion of the status entry
>  are for, but yours
> are both blank. In this case it's a tiny change approved by the CSSWG so
> I'm not too worried (hence my LGTM without blocking), but the principle of
> evolving the web together with the other engines still applies.
>
> Thanks,
>Rick
>
> On Tue, Jan 24, 2023 at 12:31 PM Daniil Sakhapov 
> wrote:
>
>> Hi, Rick!
>>
>> Thanks! Not sure I understand what you mean.
>>
>> On Tue, Jan 24, 2023 at 6:21 PM Rick Byers  wrote:
>>
>>> Looks to be a very low risk update to a brand new feature, LGTM3
>>>
>>> But what do we know about the other implementations with respect to this
>>> change? For any which haven't yet updated, are there bugs tracking it?
>>>
>>> On Tue, Jan 24, 2023 at 10:27 AM Mike Taylor 
>>> wrote:
>>>
 LGTM2

 On 1/24/23 9:19 AM, Philip Jägenstedt wrote:

 LGTM1

 Thanks Daniil for that httparchive analysis. The second one looking for
 use of the @container rule should include all cases that could matter. 56
 unique matches is a very small number when it comes to httparchive compat
 analysis. I double checked just one of them (botaniska.se, a nice park
 in Gothenburg!) and indeed that usage doesn't even
 involve CSSContainerRule. When we're unable to find even a single case that
 would break, that's as good as it gets for compat risk.

 Let's ship it before something starts to depend on the old behavior!

 On Tue, Jan 24, 2023 at 12:48 PM Daniil Sakhapov 
 wrote:

> And another query for @container + conditionText. There are no things
> that can be broken.
>
>
> https://docs.google.com/spreadsheets/d/1ILyBkGLud7fy4kXjlLURELhcMRAPqdEWz8X8J25SfDY/edit?usp=sharing
>
> On Mon, Jan 23, 2023 at 11:35 AM Daniil Sakhapov <
> sakha...@chromium.org> wrote:
>
>> Hi!
>>
>> So, I haven't found any usage on the websites chromestatus gave me.
>> But looking at WebArchive results
>> 
>>  I
>> can see that the usage is very small and the update won't change 
>> anything.
>>
>> On Wed, Jan 18, 2023 at 6:04 PM Alex Russell <
>> slightly...@chromium.org> wrote:
>>
>>> Hey Daniil:
>>>
>>> Thanks for filing for this change while the feature is still
>>> low-use; it'll be much more challenging to make this switch later.
>>>
>>> Something that wasn't clear from the use counters you linked was the
>>> use of the IDL properties vs. the CSS names. Given that it seems like we
>>> have use-counters for the latter but not the former, it seems 
>>> reasonable to
>>> consider CSS usage to be a hard cap on potential use of the JS 
>>> interface.
>>>
>>> Would you be willing to manually inspect some content (say 10-20
>>> sites) that use the CSS `container-name` and `container-query` 
>>> attributes
>>> to look for script access? Presumably it's a fraction that population, 
>>> but
>>> verifying would be helpful.
>>>
>>> Thanks
>>>
>>> On Tuesday, January 17, 2023 at 8:31:42 AM UTC-8 Daniil Sakhapov
>>> wrote:
>>>
 Contact emails sakha...@chromium.org

 Specification
 https://w3c.github.io/csswg-drafts/css-contain-3/#the-csscontainerrule-interface

 Summary

 Updates the CSSContainerRule interface to match the specs.
 Implements containerName and containerQuery, updates conditionText for
 @container to be up-to-date with specs.

 Blink component Blink>CSS
 

 TAG review https://github.com/w3ctag/design-reviews/issues/592

 TAG review status Issues addressed

 Risks

 Activation

 Previous conditionText attribute contained only container-query
 part, but now it's both container-name and container-query. But it 
 should
 not break a lot of sites 

Re: [blink-dev] Re: Intent to Ship: Add containerName and containerQuery, update conditionText

['Daniil Sakhapov' via blink-dev]

Hi, Rick!

Thanks! Not sure I understand what you mean.

On Tue, Jan 24, 2023 at 6:21 PM Rick Byers  wrote:

> Looks to be a very low risk update to a brand new feature, LGTM3
>
> But what do we know about the other implementations with respect to this
> change? For any which haven't yet updated, are there bugs tracking it?
>
> On Tue, Jan 24, 2023 at 10:27 AM Mike Taylor 
> wrote:
>
>> LGTM2
>>
>> On 1/24/23 9:19 AM, Philip Jägenstedt wrote:
>>
>> LGTM1
>>
>> Thanks Daniil for that httparchive analysis. The second one looking for
>> use of the @container rule should include all cases that could matter. 56
>> unique matches is a very small number when it comes to httparchive compat
>> analysis. I double checked just one of them (botaniska.se, a nice park
>> in Gothenburg!) and indeed that usage doesn't even
>> involve CSSContainerRule. When we're unable to find even a single case that
>> would break, that's as good as it gets for compat risk.
>>
>> Let's ship it before something starts to depend on the old behavior!
>>
>> On Tue, Jan 24, 2023 at 12:48 PM Daniil Sakhapov 
>> wrote:
>>
>>> And another query for @container + conditionText. There are no things
>>> that can be broken.
>>>
>>>
>>> https://docs.google.com/spreadsheets/d/1ILyBkGLud7fy4kXjlLURELhcMRAPqdEWz8X8J25SfDY/edit?usp=sharing
>>>
>>> On Mon, Jan 23, 2023 at 11:35 AM Daniil Sakhapov 
>>> wrote:
>>>
 Hi!

 So, I haven't found any usage on the websites chromestatus gave me.
 But looking at WebArchive results
 
  I
 can see that the usage is very small and the update won't change anything.

 On Wed, Jan 18, 2023 at 6:04 PM Alex Russell 
 wrote:

> Hey Daniil:
>
> Thanks for filing for this change while the feature is still low-use;
> it'll be much more challenging to make this switch later.
>
> Something that wasn't clear from the use counters you linked was the
> use of the IDL properties vs. the CSS names. Given that it seems like we
> have use-counters for the latter but not the former, it seems reasonable 
> to
> consider CSS usage to be a hard cap on potential use of the JS interface.
>
> Would you be willing to manually inspect some content (say 10-20
> sites) that use the CSS `container-name` and `container-query` attributes
> to look for script access? Presumably it's a fraction that population, but
> verifying would be helpful.
>
> Thanks
>
> On Tuesday, January 17, 2023 at 8:31:42 AM UTC-8 Daniil Sakhapov wrote:
>
>> Contact emails sakha...@chromium.org
>>
>> Specification
>> https://w3c.github.io/csswg-drafts/css-contain-3/#the-csscontainerrule-interface
>>
>> Summary
>>
>> Updates the CSSContainerRule interface to match the specs. Implements
>> containerName and containerQuery, updates conditionText for @container to
>> be up-to-date with specs.
>>
>> Blink component Blink>CSS
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/592
>>
>> TAG review status Issues addressed
>>
>> Risks
>>
>> Activation
>>
>> Previous conditionText attribute contained only container-query part,
>> but now it's both container-name and container-query. But it should not
>> break a lot of sites due to low current usage as per:
>> https://chromestatus.com/metrics/css/timeline/popularity/697
>> https://chromestatus.com/metrics/css/timeline/popularity/699 The
>> real breakage is hard to measure, as it's not possible to track the how
>> result of conditionText is used and the usage of container-name is low
>> compared to the container-type usage. Also, conditionText is readonly, so
>> there are no round-trip issues
>>
>> Will this feature be supported on all six Blink platforms (Windows,
>> Mac, Linux, Chrome OS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> https://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
>>
>> https://wpt.fyi/css/css-contain/container-queries/at-container-serialization.html
>> https://wpt.fyi/css/css-contain/container-queries/idlharness.html
>> https://wpt.fyi/css/cssom/CSSContainerRule.tentative.html
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1393577
>>
>> Estimated milestones
>> DevTrial on desktop 112
>> DevTrial on Android 112
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5159369837117440
>>
>> This intent message was generated by 

Re: [blink-dev] Intent to Ship: CSS Root Font Units: 'rex', 'rch', 'ric', 'rlh'

['Daniil Sakhapov' via blink-dev]

Safari has claimed to implement rlh, but nothing else I guess. None of them
are in Firefox.

On Tue, Jan 10, 2023 at 11:11 AM Philip Jägenstedt 
wrote:

> I see the Gecko issue has now been resolved as positive, which is great.
>
> Are any of these units already supported in Firefox or Safari, or would we
> be the first to ship all of them? (I took a look at one test and have a
> guess, but just as well to ask.)
>
> On Sat, 7 Jan 2023 at 01:48 Mike Taylor  wrote:
>
>> On 1/5/23 5:07 AM, 'Daniil Sakhapov' via blink-dev wrote:
>>
>> Contact emails sakha...@chromium.org
>>
>> Specification https://www.w3.org/TR/css-values-4/#font-relative-lengths
>>
>> Summary
>>
>> Allows usage of root font units. Currently only 'rem' is supported in
>> Blink. This feature supports root element variants of ex, ch, ic, and lh
>> too.
>>
>> Blink component Blink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> Search tags rlh <https://chromestatus.com/features#tags:rlh>, ric
>> <https://chromestatus.com/features#tags:ric>, rch
>> <https://chromestatus.com/features#tags:rch>, rex
>> <https://chromestatus.com/features#tags:rex>, root font
>> <https://chromestatus.com/features#tags:root%20font>
>>
>> TAG review The feature is not fundamental and only implements an
>> existing standard
>>
>> Note that CSS Values and Units Level 4 is not yet a standard, but a working
>> draft <https://www.w3.org/standards/types#WD>.
>>
>> That said, it seems the TAG recently reviewed the draft spec and was
>> satisfied with it:
>>
>> https://github.com/w3ctag/design-reviews/issues/781
>>
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/725)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/112)
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> no
>>
>>
>> Debuggability
>>
>> The new units should be automatically supported by devtools. No need for
>> any changes.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>
>> 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/css/css-values/rlh-invalidation.html
>> https://wpt.fyi/css/css-values/ric-invalidation.html
>> https://wpt.fyi/css/css-values/rch-invalidation.html
>> https://wpt.fyi/css/css-values/rex-invalidation.html
>> https://wpt.fyi/css/css-values/lh-rlh-on-root-001.html
>>
>> https://wpt.fyi/css/css-typed-om/stylevalue-subclasses/numeric-objects/cssUnitValue.html
>> https://wpt.fyi/css/css-contain/container-queries/font-relative-units.html
>>
>> https://wpt.fyi/css/css-contain/container-queries/font-relative-units-dynamic.html
>>
>> Flag name #enable-experimental-web-platform-features /
>> CSSNewRootFontUnits (Blink)
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1381037
>>
>> Estimated milestones
>> DevTrial on desktop 111
>> DevTrial on Android 111
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5073969265246208
>> --
>> 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/CAK_fkKV3D8Gpno7mie4LD5B%2BNiGvjfnRvAtJ5rsiBWYL8Mv2Bw%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_fkKV3D8Gpno7mie4LD5B%2BNiGvjfnRvAtJ5rsiBWYL8Mv2Bw%40mail.gmail.com?utm_medium=email_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 fr

[blink-dev] Intent to Ship: CSS Root Font Units: 'rex', 'rch', 'ric', 'rlh'

['Daniil Sakhapov' via blink-dev]

Contact emailssakha...@chromium.org

Specificationhttps://www.w3.org/TR/css-values-4/#font-relative-lengths

Summary

Allows usage of root font units. Currently only 'rem' is supported in
Blink. This feature supports root element variants of ex, ch, ic, and lh
too.

Blink componentBlink>CSS


Search tagsrlh , ric
, rch
, rex
, root font


TAG reviewThe feature is not fundamental and only implements an existing
standard

TAG review statusNot applicable

Risks


Interoperability and Compatibility



*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/725)

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/112)

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

no


Debuggability

The new units should be automatically supported by devtools. No need for
any changes.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes
https://wpt.fyi/css/css-values/rlh-invalidation.html
https://wpt.fyi/css/css-values/ric-invalidation.html
https://wpt.fyi/css/css-values/rch-invalidation.html
https://wpt.fyi/css/css-values/rex-invalidation.html
https://wpt.fyi/css/css-values/lh-rlh-on-root-001.html
https://wpt.fyi/css/css-typed-om/stylevalue-subclasses/numeric-objects/cssUnitValue.html
https://wpt.fyi/css/css-contain/container-queries/font-relative-units.html
https://wpt.fyi/css/css-contain/container-queries/font-relative-units-dynamic.html

Flag name#enable-experimental-web-platform-features / CSSNewRootFontUnits
(Blink)

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1381037

Estimated milestones
DevTrial on desktop 111
DevTrial on Android 111
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5073969265246208

-- 
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/CAK_fkKV3D8Gpno7mie4LD5B%2BNiGvjfnRvAtJ5rsiBWYL8Mv2Bw%40mail.gmail.com.