Re: [blink-dev] Intent to Ship: 'pageswap' event

[Manuel Rego Casasnovas]

What's going on with the tests?

https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pageswap?label=master=experimental=chrome=firefox=safari

Thanks,
  Rego

On 06/03/2024 11:57, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wed, Mar 6, 2024 at 11:54 AM Noam Rosenthal > wrote:




Summary

The `pageswap` event is fired on a Document's window
object when a navigation will replace this Document with
a new Document. The event provides activation info about
the navigation (type, NavigationHistoryEntry for the new
Document). If the navigation has a cross-document
ViewTransition, the event is dispatched before capturing
state for the old Document. This allows the page-author
to configure the old state captured for the transition
based on the navigation's activation info and the
current visual state of the old Document. This feature
is split out from the larger
ViewTransition-on-Navigation project.


Why is it split out? Is there some utility for this regardless
of view transitions?

Absolutely! For example it's a place where you can figure out that
you're navigating away to a different same-origin document (after
redirects), and act on it in some way, e.g. put something in
`sessionStorage` like a video playback position.
It's different from `pagehide` in that sense, because with
`pagehide` you don't know you're going to a new document.

Also by having a generic event with an optional viewTransition
property, it can tell the author that a view transition *didn't*
take place, which we can't do with a view-transition event.

The design for this (as for `pagerveal`) started from
view-transition-specific events and ended up gravitating towards
this kind of event with an optional attribute for this reason, and
also to avoid a situation where people create fake view transitions
for the purpose of getting these events.


Makes sense!


Blink component

Blink>ViewTransitions




TAG review


https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258 



TAG review status

Pending


Risks


Interoperability and Compatibility

None


/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/969 
)


Is that the right position?

Yes, the name was changed while iterating, but it's the same feature
and Gecko folks took active part in the design and reviews.


Ooh, got it!

--
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/CAOmohSKjwe8bHquJ09vUW%2BeSvXr3tuBASCOKh1SAk7ay4Fay4Q%40mail.gmail.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/cbd4c7d1-aba2-4449-9a4e-83efce62491b%40igalia.com.

Re: [blink-dev] Intent to Ship: Compute Pressure

[Manuel Rego Casasnovas]

The TAG asked to be updated after the experimental phase, but the issue 
hasn't been updated yet:

https://github.com/w3ctag/design-reviews/issues/795#issuecomment-1691188175

Also for WebKit position, we might want to fill a new issue in the new 
place: https://github.com/webkit/standards-positions/

And explain what has changed from the email in 2021.

Cheers,
  Rego

On 06/03/2024 09:14, Arnaud Mandy wrote:

Reilly,

We do not have direct access (non-googlers) to the OT feedback 
unfortunately.

We are working with our google contact to publish a summary.

On Tuesday, March 5, 2024 at 8:14:45 PM UTC+2 rei...@chromium.org wrote:

On Tue, Mar 5, 2024 at 5:56 AM Mike Taylor  wrote:

__


On 3/5/24 6:57 AM, Mandy, Arnaud wrote:



Contact emails

kenneth.r.c...@intel.com, arnaud...@intel.com,
wei4...@intel.com, raphael.ku...@intel.com


Explainer

https://github.com/w3c/compute-pressure/blob/main/README.md



Specification

https://www.w3.org/TR/compute-pressure



Summary

The Compute Pressure API offers high-level states that
represent the pressure on the system. It allows the
implementation to use underlying hardware/platform metrics to
inform the API users of possible stress (high CPU load at the
moment) on the system and consequently take the corrective
actions needed.

“Pressure” is a generic term by design – at the moment it is
calculated based on CPU load, but future plans include using
signals from temperature and battery status, for example.


https://developer.chrome.com/docs/web-platform/compute-pressure/ 



Blink component

Blink>PerformanceAPIs>ComputePressure




Search tags

compute pressure



TAG review

spec review:
https://github.com/w3ctag/design-reviews/issues/795


wide review tracker:
https://github.com/w3c/compute-pressure/issues/177



TAG review status

Issues addressed


Chromium Trial Name

ComputePressure


Origin Trial documentation link

https://developer.chrome.com/docs/web-platform/compute-pressure/ 



Origin Trials history

The first Origin Trial


 was run between M92-94.

The Compute Pressure API was widely redesigned after this OT
to resemble existing observer-based web APIs and also to
provide better privacy and security guarantees after
discussions with PING.


The second Origin Trial
 
took place during M115-M120.
During this origin trial we realized that the full capacity of
the API couldn’t be tested due to a lack of support for
third-party tokens. An Origin Trial extension


 was necessary until M123.


Is there any developer feedback that can be shared from the origin
trials? I'm looking for signals that developers have been able to
improve user experiences by using the new signals.



Risks


Interoperability and Compatibility


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


Can you add a comment to this issue pointing to this I2S, and
any relevant changes since the original issue was opened?


/WebKit/: Negative
(https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html 
) This issue has 
been taken into account: https://github.com/w3c/compute-pressure/issues/24 



https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116 
 
suggests asking for re-review once issue 24 is settled (at least that's my 
interpretation). Do you know if that ever happened?


/Web developers/: Positive

Re: [blink-dev] Intent to Ship: Form Controls Support Vertical Writing Mode Direction Support

[Manuel Rego Casasnovas]

On 23/02/2024 21:42, Di Zhang wrote:

Specification

https://github.com/whatwg/html/issues/8413 



What's the status of this issue? Is there any spec text that needs to 
change?



Interoperability and Compatibility

Chrome: implemented behind flag Safari: implemented behind flag Firefox: 
implemented for  in stable, issue created for 
meter/progress.




/Gecko/: No signal


It seems something is implemented already and you mention there's a bug 
for some other things, could you link that bug? Are they currently 
working on it?


/WebKit/: In development 
(https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes ) Added support for vertical writing mode support for form controls. (12072686)


Has this actually shipped in WebKit or is "in development"?

You first mentioned "Safari: implemented behind flag", but you're 
linking to some release notes.


Which parts are shipped in Safari and which are not yet?


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/css/css-writing-modes/forms?label=master=experimental=chrome=firefox=safari=interop=label%3Ainterop-2022-forms%20or%20label%3Ainterop-2023-forms
 



These tests are all passing in Chrome and Safari (only 3 failing in 
Firefox). Is this feature adding new tests?


Open questions about a feature may be a source of future web compat or 
interop issues. Please list open issues (e.g. links to known github 
issues in the project for the feature specification) whose resolution 
may introduce web compat/interop risk (e.g., changing to naming or 
structure of the API in a non-backward-compatible way).


HTML spec currently under review: 
https://github.com/whatwg/html/pull/10096 



Ok, answering my own question on the Spec link, there's indeed a PR 
here. How far is this from being merged?


Thanks,
  Rego

--
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/7248abb1-b5dd-438c-bae8-6457816d39d5%40igalia.com.

Re: [blink-dev] Intent to Ship: Do not invert author selection background color when it matches text color

[Manuel Rego Casasnovas]

Hi Stephen,

I think it'd be nice to send a new intent-to-ship and update the 
chromestatus entry with the new agreed behavior on CSSWG (I've made you 
an owner of https://chromestatus.com/guide/edit/5657973985640448). As 
this a quite old one and the template and process has changed a lot 
since then.


Thanks,
  Rego

On 22/02/2024 19:55, Stephen Chenney wrote:
It's been a while but it's time to revive this intent to respect author 
provided colors in ::selection rather than inverting the background when 
it matches the foreground. This makes chromium compatible with other 
engines.


The CSS Working group resolved issue 6150 
<https://github.com/w3c/csswg-drafts/issues/6150> to require that 
browsers respect the author supplied colors in ::selection pseudos. This 
resolution has no impact on the browser's default selection behavior.


CL 5314122 
<https://chromium-review.googlesource.com/c/chromium/src/+/5314122> 
implements the change.


Any objections?

In implementing this I discovered that in the default case (of no 
::selection pseudo at all) we would only have problems in inactive 
windows on Linux. In other cases there is transparency so even if you 
have matching colors in the foreground and background there remains some 
contrast due to opacity blending.


Stephen.

On Tuesday, October 5, 2021 at 6:02:10 AM UTC-4 Manuel Rego wrote:


On 04/10/2021 14:24, Yoav Weiss wrote:
 > Do we know the reasons why WebKit changed behavior?

Thanks for the question Yoav. This question lead to further
investigation to find out this is a total mess, so I abandon this
intent
for now. Maybe in the future we could resend this.

For more details you can check this CSSWG issue (just found it today):
https://github.com/w3c/csswg-drafts/issues/6150
<https://github.com/w3c/csswg-drafts/issues/6150>

WebKit still changes the background color, but not in the same
situations than Chromium:
* Chromium inverts it here:
::selection { color: lime; background: lime; }
* While WebKit does this here:
::selection { color: rgba(0, 255, 0, .8); background: lime; }
Because WebKit modifies the background set by the user to add 80%
opacity to it.

This code comes from an older commit than the one I pointed in the
intent: https://trac.webkit.org/changeset/1447/webkit
<https://trac.webkit.org/changeset/1447/webkit> (19 years ago).

And there was a funny comment on WebKit source code 17 years ago
(https://trac.webkit.org/changeset/7766/webkit
<https://trac.webkit.org/changeset/7766/webkit>):
// If the text color ends up being the same as the selection
// background, invert the selection background. This should
// basically never happen, since the selection has transparency.

Like this only happens if the text color also has such transparency.

Anyway, we'll add this information on the CSSWG issue and see if
there's
any kind of agreement.

So ignore this intent for now.

Cheers,
Rego

 > On Mon, Oct 4, 2021 at 1:34 PM Manuel Rego Casasnovas
mailto:r...@igalia.com>
 > <mailto:r...@igalia.com <mailto:r...@igalia.com>>> wrote:
 >
 >
 > **Contact emails**
 > r...@igalia.com <mailto:r...@igalia.com> <mailto:r...@igalia.com
<mailto:r...@igalia.com>>, dazab...@igalia.com
<mailto:dazab...@igalia.com>
 > <mailto:dazab...@igalia.com <mailto:dazab...@igalia.com>>
 >
 > **Specification**
 > https://www.w3.org/TR/css-pseudo-4/#selectordef-selection
<https://www.w3.org/TR/css-pseudo-4/#selectordef-selection>
 > <https://www.w3.org/TR/css-pseudo-4/#selectordef-selection
<https://www.w3.org/TR/css-pseudo-4/#selectordef-selection>>
 >
 > **Summary**
 >
 > Right now selection background color is inverted when it matches the
 > text color in Chromium.
 > So if you have a rule like this "::selection { color: cyan;
background:
 > cyan; }" the background gets inverted and a red background color is
 > used.
 > This is an old behavior inherited from WebKit but Safari doesn't
do this
 > anymore (and Firefox has never done this).
 > The proposal is to stop inverting the background color for
::selection.
 >
 > **Blink component**
 > Blink>CSS
 >
 > **TAG review**
 > N/A
 >
 > This is mostly a bug fix but we're sending the intent as a PSA
and due
 > to the potential compat risk.
 >
 > **Risks**
 >
 > **Interoperability and Compatibility**
 >
 > The current Chromium behavior comes from WebKit
 > (trac.webkit.org/changeset/52548/webkit
<http://trac.webkit.org/changeset/52548/webkit>
 > <http://trac.

Re: [blink-dev] Intent to Experiment: Document Subtitle (Fix PWA app titles)

[Manuel Rego Casasnovas]

On 20/02/2024 18:47, 'Diego Gonzalez' via blink-dev wrote:

Specification

https://github.com/whatwg/html/compare/main...diekus:html:main 



Should this be an actual HTML PR so discussion with third parties can 
happen there?


/Gecko/: Defer 
(https://github.com/mozilla/standards-positions/issues/749 
)


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


This is closed as "oppose".

Anyway it seems these standard positions requests are quite old and for 
a different initial proposal that has evolved and changed. Shouldn't we 
reopen them (or fill new ones, I'm not sure about the best practice in 
this case) and update them with the new proposal.



Goals for experimentation


I think you should describe the goals of this intent-to-experiment.


Estimated milestones

DevTrial on desktop

123


And you should define the OriginTrial first and last milestones.

Cheers,
  Rego

--
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/b601f4b5-9b71-4eda-981a-b852a46853bd%40igalia.com.

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

[Manuel Rego Casasnovas]

LGTM3

On 21/02/2024 07:48, Yoav Weiss (@Shopify) wrote:

LGTM2

On Wednesday, February 21, 2024 at 6:19:50 AM UTC+1 Domenic Denicola wrote:

LGTM1. I recall these methods getting lots of good design review and
discussion in the PR, from multiple parties. I'm excited to see them
ship.

Thanks Luke for spotting the trusted types interaction, and fixing it!

On Saturday, February 17, 2024 at 2:15:09 AM UTC+9 Joey Arhar wrote:

 > Is this the relevant explainer (referenced from the PR
below):
https://github.com/WICG/sanitizer-api/blob/main/explainer.md


Yes, as far as I know.

 > This seems positive, right?

Whoops, meant to put positive. I updated the chromestatus.

 > Both of these look like "Shipped/Shipping", per
https://bit.ly/blink-signals .
That status is a little odd, because it doesn't look like
they've actually made it to a stable release, but if I'm reading
the bug trackers right they're both merged, so they're past "In
Development".

Ok, I'll change them to shipped/shipping.

On Thu, Feb 15, 2024 at 9:35 AM Luke mailto:lwar...@igalia.com>> wrote:

Just to keep everyone up to date, you can disregard my
remarks above I've landed a patch which addresses the lack
of trusted types protection, thanks for the quick review Joey.

Regards,
Luke

On Wednesday, February 14, 2024 at 10:49:23 PM UTC Luke wrote:

Hi,

In it's current form Chromium's implementation of these
functions bypasses trusted types protection.

The below WPT tests cover this behaviour:


https://wpt.fyi/results/trusted-types/block-string-assignment-to-ShadowRoot-setHTMLUnsafe.html?label=experimental=master
 


https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setHTMLUnsafe.html?label=experimental=master
 


https://wpt.fyi/results/trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html?label=experimental=master
 


This should be addressed before shipping, else it will
be an unexpected security regression.

On Wednesday, February 14, 2024 at 10:23:01 PM UTC
Vladimir Levin wrote:

On Wed, Feb 14, 2024 at 1:53 PM Jeffrey Yasskin
 wrote:

Non-API-owner opinions inline:

On Wed, Feb 14, 2024 at 1:42 PM 'Vladimir Levin'
via blink-dev  wrote:

I just had some clarifying questions

On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar
 wrote:

Some additional notes:
- This API is tested in the declarative
ShadowDOM tests in interop2024, and it
is counting against us to not have it
enabled by default.
- The future sanitization options will
be added as an optional second parameter
to both methods, so there will not be
any compat issues with shipping now.

On Wed, Feb 14, 2024 at 1:11 PM Joey
Arhar  wrote:


Contact emails

jar...@chromium.org


Explainer

None


Is this the relevant explainer (referenced
from the PR below):

https://github.com/WICG/sanitizer-api/blob/main/explainer.md 




Specification


https://html.spec.whatwg.org/C/#unsafe-html-parsing-methods 

https://github.com/whatwg/html/pull/9538 



Summary

The setHTMLUnsafe and

Re: [blink-dev] Intent to Ship: Shadow root clonable attribute

[Manuel Rego Casasnovas]

LGTM2.

On 17/02/2024 02:40, Mason Freed wrote:
On Fri, Feb 16, 2024 at 6:30 AM Mike Taylor > wrote:


__

LGTM1 to ship (see below).

Thanks!

It looks like Safari has only shipped to Beta...


Yes, this was a recent consensus/spec, so it hasn't made it all the way 
to stable yet.




/Gecko/: Positive
(https://bugzilla.mozilla.org/show_bug.cgi?id=1868428
) Shipping soon


...but this has also been in Firefox Nightly and Beta, shipping to
Stable in 123 
(on Feb 20). Obvious breakage tends to surface in Firefox Nightly
pretty quickly. Mozilla shipping 2 months before us will also allow
us to get a sense of possible breakage before we hit the stable channel.

Ahh, thanks for checking on this. I agree that should help.

I think the risk is non-zero, but likely very, very low - so thanks
for rolling this out slowly and being willing to turn it off if you
discover significant issues that can't be quickly resolved via outreach.

Thanks! Will do.

Thanks,
Mason



/WebKit/: Shipped/Shipping

(https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes#Web-API
 
)

/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?

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/shadow-dom/shadow-root-clonable.html




Flag name on chrome://flags

ShadowRootClonable


Finch feature name

ShadowRootClonable


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1510466 


Estimated milestones

Shipping on desktop 124

Shipping on Android 124

Shipping on WebView 124



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known github issues in the project for the feature specification)
whose resolution may introduce web compat/interop risk (e.g.,
changing to naming or structure of the API in a
non-backward-compatible way).

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161435196030976



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiPDiSgLRpcW8Q%3DhYTrt%3Dgp%2B%2B6eiS21s_TwFEr%2BHamONA%40mail.gmail.com
 


This intent message was generated by Chrome Platform Status
.
-- 
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/CAM%3DNeDjeNTzKD%3DMpiPbi64%2BEq97vnAA1Q%2BfMG--iFCG8N%3DSa9Q%40mail.gmail.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/CAM%3DNeDhpEru0j03S04%2Bea0LBfFNfRvqZPaRbXS_s3dG8qVza8A%40mail.gmail.com .


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this 

Re: [blink-dev] Intent to Ship: CSS picture-in-picture display mode

[Manuel Rego Casasnovas]

Thanks for adding the test. LGTM2.

Cheers,
  Rego

On 14/02/2024 13:15, 'François Beaufort' via blink-dev wrote:


On Wed, Feb 14, 2024 at 10:48 AM Manuel Rego Casasnovas <mailto:r...@igalia.com>> wrote:




On 14/02/2024 10:46, François Beaufort wrote:
 >
 >
 > On Wed, Feb 14, 2024 at 10:43 AM Manuel Rego Casasnovas
mailto:r...@igalia.com>
 > <mailto:r...@igalia.com <mailto:r...@igalia.com>>> wrote:
 >
 >     Hi,
 >
 >     On 13/02/2024 11:13, 'François Beaufort' via blink-dev wrote:
 >      >
 >      >         Is this feature fully tested by web-platform-tests
 >      >
 > 
  <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>>>?

 >      >
 >      > Yes
 >      >
 >      > https://wpt.fyi/results/css/mediaqueries/display-mode.html
<https://wpt.fyi/results/css/mediaqueries/display-mode.html>
 >     <https://wpt.fyi/results/css/mediaqueries/display-mode.html
<https://wpt.fyi/results/css/mediaqueries/display-mode.html>>
 >      >
<https://wpt.fyi/results/css/mediaqueries/display-mode.html
<https://wpt.fyi/results/css/mediaqueries/display-mode.html>
 >     <https://wpt.fyi/results/css/mediaqueries/display-mode.html
<https://wpt.fyi/results/css/mediaqueries/display-mode.html>>>
 >      > https://wpt.live/css/mediaqueries/display-mode.html
<https://wpt.live/css/mediaqueries/display-mode.html>
 >     <https://wpt.live/css/mediaqueries/display-mode.html
<https://wpt.live/css/mediaqueries/display-mode.html>>
 >      > <https://wpt.live/css/mediaqueries/display-mode.html
<https://wpt.live/css/mediaqueries/display-mode.html>
 >     <https://wpt.live/css/mediaqueries/display-mode.html
<https://wpt.live/css/mediaqueries/display-mode.html>>>
 >
 >     Is this only testing the parsing of the new value?
 >
 >
 > These ones only do that.
 >
 > We have chromium browser tests for this at
 >

https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1
 
<https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1>
 
<https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1
 
<https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1>>

Is there any WPT limitation preventing us for testing this there? If so
we should report a WPT issue.

Having behavioral tests in WPT is always useful to ensure
interoperability in the future.


I'm adding tests in WPT as suggested.
See 
https://chromium-review.googlesource.com/c/chromium/src/+/5290634/3/third_party/blink/web_tests/external/wpt/document-picture-in-picture/display-mode.https.html <https://chromium-review.googlesource.com/c/chromium/src/+/5290634/3/third_party/blink/web_tests/external/wpt/document-picture-in-picture/display-mode.https.html>


Thank you for catching!


Cheers,
    Rego

--
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 
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2B-ajZwj01sZ3TOHADOwFd04FLoF0Zk7bF4Ow--riK6OA%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2B-ajZwj01sZ3TOHADOwFd04FLoF0Zk7bF4Ow--riK6OA%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 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/3c37cf6d-0419-4dd6-ac8a-b3cae2dbee2c%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS picture-in-picture display mode

[Manuel Rego Casasnovas]

On 14/02/2024 10:46, François Beaufort wrote:



On Wed, Feb 14, 2024 at 10:43 AM Manuel Rego Casasnovas <mailto:r...@igalia.com>> wrote:


Hi,

On 13/02/2024 11:13, 'François Beaufort' via blink-dev wrote:
 >
 >         Is this feature fully tested by web-platform-tests
 >   
  <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>>?

 >
 > Yes
 >
 > https://wpt.fyi/results/css/mediaqueries/display-mode.html
<https://wpt.fyi/results/css/mediaqueries/display-mode.html>
 > <https://wpt.fyi/results/css/mediaqueries/display-mode.html
<https://wpt.fyi/results/css/mediaqueries/display-mode.html>>
 > https://wpt.live/css/mediaqueries/display-mode.html
<https://wpt.live/css/mediaqueries/display-mode.html>
 > <https://wpt.live/css/mediaqueries/display-mode.html
<https://wpt.live/css/mediaqueries/display-mode.html>>

Is this only testing the parsing of the new value?


These ones only do that.

We have chromium browser tests for this at 
https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1 <https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1>


Is there any WPT limitation preventing us for testing this there? If so 
we should report a WPT issue.


Having behavioral tests in WPT is always useful to ensure 
interoperability in the future.


Cheers,
  Rego

--
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/143520a9-3985-4035-8d63-782f6e79ac61%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS picture-in-picture display mode

[Manuel Rego Casasnovas]

Hi,

On 13/02/2024 11:13, 'François Beaufort' via blink-dev wrote:


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/css/mediaqueries/display-mode.html 
 
https://wpt.live/css/mediaqueries/display-mode.html 



Is this only testing the parsing of the new value?

Do we have any test checking the behavior? Maybe we should have some in 
the /picture-in-picture/ folder in WPT.


Cheers,
  Rego

--
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/7748ab4d-d088-42b5-99ce-eff99b39f1bc%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS paint-order for non-SVG text

[Manuel Rego Casasnovas]

Oops, before we can approve you have to fill the other review gates at 
chromestatus, e.g. 
https://chromestatus.com/feature/5178467903864832?gate=5166816630669312


Could you make sure you request the review for all the gates: Privacy, 
Security, Enterprise, Debuggability and Testing?


Thanks!
  Rego

On 12/02/2024 12:02, Manuel Rego Casasnovas wrote:

LGTM1.

Good to know it's a different issue in Firefox.

Now that all browsers will be supporting this, please could you make the 
test non tentative?


JFYI, I've filled an issue so the MDN documentation gets updated to also 
include the HTML case: https://github.com/mdn/content/issues/32236


Cheers,
   Rego

On 09/02/2024 09:00, Stefan Zager wrote:



On Thu, Feb 8, 2024 at 4:00 AM Manuel Rego Casasnovas <mailto:r...@igalia.com>> wrote:


    Why is the WPT test marked as tentative?

https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html <https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html>


    Not sure if there are more tests or is only that one, but it's 
failing
    in Firefox. What are the interop issues? Are those reported 
somewhere?



Looks like an implementation-specific line-breaking issue in the 
Firefox runs, but the text rendering appears consistent with webkit 
and chromium.


I'm unaware of any interop issues.


    Thanks,
    Rego

    On 08/02/2024 11:48, Fredrik Söderquist wrote:
 > On Thu, Feb 8, 2024 at 11:30 AM Daniel Bratell
    mailto:bratel...@gmail.com>
 > <mailto:bratel...@gmail.com <mailto:bratel...@gmail.com>>> wrote:
 >
 >     __
 >
 >     I didn't really get how it affects non-SVG text. The
    documentation
 >     and the examples are all for SVG. Is there HTML text that is
    also a
 >     mix of stroke, fill and marker blitting?
 >
 > Here's an example for non-SVG (HTML) text:
 > https://jsfiddle.net/4mh71efb/ <https://jsfiddle.net/4mh71efb/>
    <https://jsfiddle.net/4mh71efb/ <https://jsfiddle.net/4mh71efb/>>
 >
 > Getting a stroke on HTML text requires using the
    -webkit-text-stroke-*
 > family of properties. Markers don't apply to text (same as for
    SVG text).
 >
 >
 > /fs
 >
 >     /Daniel
 >
 >     On 2024-02-08 10:14, Fredrik Söderquist wrote:
 >>     On Thu, Feb 8, 2024 at 2:48 AM Stefan Zager
    mailto:sza...@chromium.org>
 >>     <mailto:sza...@chromium.org <mailto:sza...@chromium.org>>>
    wrote:
 >>
 >>
 >>                 Contact emails
 >>
 >> sza...@chromium.org <mailto:sza...@chromium.org>
    <mailto:sza...@chromium.org <mailto:sza...@chromium.org>>
 >>
 >>
 >>                 Explainer
 >>
 >> https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order
    <https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order>
 >>  
 <https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order

    <https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order>>
 >>
 >>
 >>                 Specification
 >>
 >> https://svgwg.org/svg2-draft/painting.html#PaintOrder
    <https://svgwg.org/svg2-draft/painting.html#PaintOrder>
 >>         <https://svgwg.org/svg2-draft/painting.html#PaintOrder
    <https://svgwg.org/svg2-draft/painting.html#PaintOrder>>
 >>
 >>
 >>                 Summary
 >>
 >>         Adds support for the existing CSS property
    `paint-order`. This
 >>         change only affects html (non-SVG) text; SVG text already
 >>         supports paint-order via attribute or CSS property.
 >>
 >>
 >>
 >>                 Blink component
 >>
 >>         Blink>Paint
 >>  
 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPaint <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPaint>>

 >>
 >>
 >>                 TAG review
 >>
 >>         None
 >>
 >>
 >>                 TAG review status
 >>
 >>         Not applicable
 >>
 >>
 >>                 Risks
 >>
 >>
 >>
 >>                 Interoperability and Compatibility
 >>
 >>         None
 >>
 >>
 >>
 >>         /Gecko/: Shipped in version 60 (2018)
 >>
 >>         /WebKit/: No signal
 >>
 >>
 >>     Also shipped in WebKit (since Safari 11 according to MDN;

Re: [blink-dev] Intent to Ship: CSS paint-order for non-SVG text

[Manuel Rego Casasnovas]

LGTM1.

Good to know it's a different issue in Firefox.

Now that all browsers will be supporting this, please could you make the 
test non tentative?


JFYI, I've filled an issue so the MDN documentation gets updated to also 
include the HTML case: https://github.com/mdn/content/issues/32236


Cheers,
  Rego

On 09/02/2024 09:00, Stefan Zager wrote:



On Thu, Feb 8, 2024 at 4:00 AM Manuel Rego Casasnovas <mailto:r...@igalia.com>> wrote:


Why is the WPT test marked as tentative?
https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html 
<https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html>

Not sure if there are more tests or is only that one, but it's failing
in Firefox. What are the interop issues? Are those reported somewhere?


Looks like an implementation-specific line-breaking issue in the Firefox 
runs, but the text rendering appears consistent with webkit and chromium.


I'm unaware of any interop issues.


Thanks,
    Rego

On 08/02/2024 11:48, Fredrik Söderquist wrote:
 > On Thu, Feb 8, 2024 at 11:30 AM Daniel Bratell
mailto:bratel...@gmail.com>
 > <mailto:bratel...@gmail.com <mailto:bratel...@gmail.com>>> wrote:
 >
 >     __
 >
 >     I didn't really get how it affects non-SVG text. The
documentation
 >     and the examples are all for SVG. Is there HTML text that is
also a
 >     mix of stroke, fill and marker blitting?
 >
 > Here's an example for non-SVG (HTML) text:
 > https://jsfiddle.net/4mh71efb/ <https://jsfiddle.net/4mh71efb/>
<https://jsfiddle.net/4mh71efb/ <https://jsfiddle.net/4mh71efb/>>
 >
 > Getting a stroke on HTML text requires using the
-webkit-text-stroke-*
 > family of properties. Markers don't apply to text (same as for
SVG text).
 >
 >
 > /fs
 >
 >     /Daniel
 >
 >     On 2024-02-08 10:14, Fredrik Söderquist wrote:
 >>     On Thu, Feb 8, 2024 at 2:48 AM Stefan Zager
mailto:sza...@chromium.org>
 >>     <mailto:sza...@chromium.org <mailto:sza...@chromium.org>>>
wrote:
 >>
 >>
 >>                 Contact emails
 >>
 >> sza...@chromium.org <mailto:sza...@chromium.org>
<mailto:sza...@chromium.org <mailto:sza...@chromium.org>>
 >>
 >>
 >>                 Explainer
 >>
 >> https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order
<https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order>
 >>   
  <https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order

<https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order>>
 >>
 >>
 >>                 Specification
 >>
 >> https://svgwg.org/svg2-draft/painting.html#PaintOrder
<https://svgwg.org/svg2-draft/painting.html#PaintOrder>
 >>         <https://svgwg.org/svg2-draft/painting.html#PaintOrder
<https://svgwg.org/svg2-draft/painting.html#PaintOrder>>
 >>
 >>
 >>                 Summary
 >>
 >>         Adds support for the existing CSS property
`paint-order`. This
 >>         change only affects html (non-SVG) text; SVG text already
 >>         supports paint-order via attribute or CSS property.
 >>
 >>
 >>
 >>                 Blink component
 >>
 >>         Blink>Paint
 >>   
  <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPaint <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPaint>>

 >>
 >>
 >>                 TAG review
 >>
 >>         None
 >>
 >>
 >>                 TAG review status
 >>
 >>         Not applicable
 >>
 >>
 >>                 Risks
 >>
 >>
 >>
 >>                 Interoperability and Compatibility
 >>
 >>         None
 >>
 >>
 >>
 >>         /Gecko/: Shipped in version 60 (2018)
 >>
 >>         /WebKit/: No signal
 >>
 >>
 >>     Also shipped in WebKit (since Safari 11 according to MDN; Safari
 >>     TP 25 looking at changelog)
 >>
 >>
 >>     /fs
 >>
 >>
 >>         /Web developers/: Positive; 48 stars on tracking bug
 >>
 >>         /Other signals/:
 >>
 >>
 >>                 WebView application risks
 &g

Re: [blink-dev] Intent to Ship: CSS paint-order for non-SVG text

[Manuel Rego Casasnovas]

Why is the WPT test marked as tentative?
https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html

Not sure if there are more tests or is only that one, but it's failing 
in Firefox. What are the interop issues? Are those reported somewhere?


Thanks,
  Rego

On 08/02/2024 11:48, Fredrik Söderquist wrote:
On Thu, Feb 8, 2024 at 11:30 AM Daniel Bratell > wrote:


__

I didn't really get how it affects non-SVG text. The documentation
and the examples are all for SVG. Is there HTML text that is also a
mix of stroke, fill and marker blitting?

Here's an example for non-SVG (HTML) text: 
https://jsfiddle.net/4mh71efb/ 


Getting a stroke on HTML text requires using the -webkit-text-stroke-* 
family of properties. Markers don't apply to text (same as for SVG text).



/fs

/Daniel

On 2024-02-08 10:14, Fredrik Söderquist wrote:

On Thu, Feb 8, 2024 at 2:48 AM Stefan Zager mailto:sza...@chromium.org>> wrote:


Contact emails

sza...@chromium.org 


Explainer

https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order



Specification

https://svgwg.org/svg2-draft/painting.html#PaintOrder



Summary

Adds support for the existing CSS property `paint-order`. This
change only affects html (non-SVG) text; SVG text already
supports paint-order via attribute or CSS property.



Blink component

Blink>Paint




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped in version 60 (2018)

/WebKit/: No signal


Also shipped in WebKit (since Safari 11 according to MDN; Safari
TP 25 looking at changelog)


/fs


/Web developers/: Positive; 48 stars on tracking bug

/Other signals/:


WebView application risks

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

123



Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5178467903864832


This intent message was generated by Chrome Platform Status
.
-- 
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/CAHOQ7J9i%3DwoeX%2Bh%2B1rwpidM%3D5SiMPnCq9fskupy2tDUjXcMAMw%40mail.gmail.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/CAHediLRsC%3DiYN%3D5iKfpYF99c62gqb_1nw4PnFQpawECXiQp7WQ%40mail.gmail.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 

Re: [blink-dev] Intent to Ship: WebGPU: separate Read-only depth-stencil

[Manuel Rego Casasnovas]

LGTM3

On 18/01/2024 02:26, Mike Taylor wrote:

LGTM2

On 1/17/24 7:45 PM, Chris Harrelson wrote:
LGTM1 (as noted in the other intent, tests are needed but we aren't 
blocking approval on them in this case)


On Wed, Jan 10, 2024 at 11:02 AM Corentin Wallez 
 wrote:


Hey Rick,

The spec PRs for all of these intents are landed but you're
correct that all the tests are. Tests aren't blocked, they just
need someone to get to it (myself for this particular feature) and
we won't turn the feature on until they are finished. I didn't
realize that LGTMs waited on tests to be finished. We have a
pretty strong focus on testing in WebGPU and will definitely not
let a feature get enabled without tests being completed so
hopefully it's ok to LGTM without them? We totally expect some of
these recent I2S to slip to M123 because tests are still needed,
we just don't know which ones yet.

Cheers,

Corentin

On Wed, Jan 10, 2024 at 4:00 PM Rick Byers 
wrote:

Hi Corentin,
This looks minor and probably pretty easy. But we do normally
like to see spec PRs and tests land (or have a discussion
around why they're blocked) before approving. Thoughts?

Rick

On Fri, Jan 5, 2024 at 8:18 AM Corentin Wallez
 wrote:


Contact emails

cwal...@google.com


Explainer

None


Specification

https://github.com/gpuweb/gpuweb/pull/4331


Summary

Functionality added to the WebGPU/WGSL spec after its
first shipment in a browser. Loosens a restriction where
using readonly depth-stencil attachments in a render pass
required both aspects (depth and stencil) to be readonly.
This was too strict, and prevent use-cases where for
example the depth is used readonly for contact shadow
tracing, while the stencil buffer is written to do
identify pixels for further processing. (Both Unity and
Unreal do things with mixed depth-stencil readonliness).



Blink component

Blink>WebGPU




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Separate RODS has not yet been implemented in any browser,
but has been approved by the GPU for the Web Community
Group, with representatives from Chrome, Firefox, and Safari.



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

/WebKit/: Positive

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
 Note that this is a blanket approval from Safari for additions to the v1 
WebGPU/WGSL spec.

/Web developers/: Positive Requested by multiple
developers including for ports of the Unity and Unreal
engines to WebGPU.

/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?

None at the moment, WebGPU currently does not ship on
Android WebView.



Debuggability

None



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

No

All platforms will eventually have support. Will
immediately be available on Android, ChromeOS, Mac, and
Windows, since those platforms already support WebGPU.
Linux is planned to have WebGPU support in the future, so
this feature will become available when WebGPU does.



Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly pulled
into Chromium and part of the testing of Dawn/Tint in
Chromium. Note that tests are still being written, but the
feature will not be launched until it is fully tested.



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking 

Re: [blink-dev] Intent to Ship: New ALPS code point

[Manuel Rego Casasnovas]

On 13/01/2024 00:08, Victor Tan wrote:

TAG review

https://github.com/w3ctag/design-reviews/issues/549 



TAG review is from 2021, has anything changed since then or is it still 
the same feature/spec that is shipping now?



Firefox: Pending https://github.com/mozilla/standards-positions/issues/510



That's also quite old. Could you do a ping there, explaining the 
willingness to ship in Blink, trying to reactivate it?


Safari: Pending 
https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html 



For WebKit I think we should fill a new standards position request at:
https://github.com/WebKit/standards-positions/issues

Thanks,
  Rego

--
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/7ee096c8-22c1-4fcc-a2b4-c52de0010e5d%40igalia.com.

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

[Manuel Rego Casasnovas]

On 15/01/2024 11:31, Noam Rosenthal wrote:


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6118675067699200



Can you tick the other review boxes on the entry?

Not sure I understand what boxes?


Yoav refers to the buttons to request other reviews (apart from the API 
owners review that happens here).


In "Prepare to ship" section you can find buttons for the following reviews:
* Privacy
* Security
* Enterprise
* Debuggability
* Testing

You should click those to request a review from the different parties.

Cheers,
  Rego

--
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/704e3d0e-e8cb-4802-8e20-e8cb01641b99%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS Pseudo Element ::backdrop inheriting from Originating Element

[Manuel Rego Casasnovas]

LGTM3.

BTW, one question about pseudo-elements, for some of them we have use 
counters buts not for all (like this one, or at least I didn't find it). 
Is that fine? Or should we usually add use counters for new pseudo-elements?


Cheers,
  Rego

On 10/01/2024 16:46, Daniel Bratell wrote:

LGTM2

/Daniel

On 2024-01-10 16:41, Rick Byers wrote:
Given how trivial and niche this is and that WebKit and Gecko have 
both shipped this without any apparent compat fallout, I agree the 
compat risk is very low. I'm ok treating it as a bugfix, but please 
circle back here (and consider using your killswitch) if you hear of 
any breakage in practice. LGTM1 to ship.


On Tue, Jan 9, 2024 at 6:50 AM Rune Lillesveen  
wrote:



Contact emails

futh...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-position-4/#backdrop


Summary

The ::backdrop pseudo element used to inherit from initial values.
That meant ::backdrop could not use custom property values unless
specified directly on the ::backdrop rule. The specification has
now changed so that ::backdrop inherits from the originating
element, and with that the implementation.



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

A compatibility risk is that existing content may rely on
inheriting initial values. For instance, this rule may change from
having a backdrop with the initial foreground color to using the
color property of the originating element: ::backdrop {
background: currentColor } Interop risk is low for shipping since
Firefox and Safari already do ship.



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1855668) Shipped in
Firefox 120

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=263834)

/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?

None



Debuggability

N/A



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.live/css/css-position/backdrop-inherit-computed.html
https://wpt.live/css/css-position/backdrop-inherit-rendered.html



Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

BackdropInheritOriginating


Requires code in //chrome?

False


Tracking bug

https://crbug.com/827397


Estimated milestones

Shipping on desktop 122
DevTrial on desktop 119

Shipping on Android 122
DevTrial on Android 119

Shipping on WebView 122



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known github issues in the project for the feature specification)
whose resolution may introduce web compat/interop risk (e.g.,
changing to naming or structure of the API in a
non-backward-compatible way).

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4875749691752448

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen


-- 
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/CACuPfeRpWk%2BOh_g1LD7wUwXk7L1Agu%2Bd84Myk8uCkZQy_-S35g%40mail.gmail.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/CAFUtAY-8sefA9ZJh5q0cDnqRjUAcaBBM_wEVw0DLvHiqYErCtw%40mail.gmail.com 

Re: [blink-dev] Web-Facing Change PSA: CSS Highlight Inheritance

[Manuel Rego Casasnovas]

Hi Stephen,

Please send a new email in a separated thread for the intent to ship.

Thanks,
  Rego

On 31/10/2023 01:17, Stephen Chenney wrote:
The new launch process workflow wouldn't let me do an Intent to Ship for 
this one, at least not without some as-yet-unknown gate based on this 
email. I've filed an issue to get it resolved.


It would be great if the API owners could treat this as an intent to 
ship, but I'm also fine resending it with a different title.


On Mon, Oct 30, 2023 at 7:27 PM Chris Harrelson > wrote:


Hi Stephen,

Just checking: were you intending to send an intent-to-ship or a PSA?

On Mon, Oct 30, 2023 at 2:17 PM Stephen Chenney
mailto: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




TAG review

None


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.



/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/: No signals 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

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

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

?

Yes

https://wpt.fyi/results/css/css-pseudo?label=experimental=master 
 highlight-cascade-* 

Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Manuel Rego Casasnovas]

LGTM2

On 04/10/2023 11:49, Yoav Weiss wrote:

Thanks for clarifying and verifying! :) My LGTM still stands.

On Wed, Oct 4, 2023 at 11:48 AM Anders Hartvoll Ruud 
mailto:andr...@chromium.org>> wrote:




On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud
mailto:andr...@chromium.org>> wrote:

On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss
mailto:yoavwe...@chromium.org>> wrote:

LGTM1

Thanks for evaluating the compat risk for this. While
non-zero, it seems manageable given Mozilla already shipping
this, with Safari likely to follow, given the landed
implementation.


Clarification: Mozilla is shipping the main part of the feature
(retrying a failed declaration as a nested style rule), but they
are not (yet) shipping the tweaks to css-syntax described as
risk (1) and (2). (1) is a recent resolution (~three weeks), so
no mystery there. (2) has been part of this all along - I assume
it was seen as something that could be done separately (and it is).


Just to make sure it wasn't /deliberately/ omitted for whatever
reason, I checked with Emilio and they do intend to implement (1)
and (2) once it's specified.


So in this case "Mozilla: Shipping" should only be interpreted
as a positive signal for the overall change, not as a way to
manage compat risk. :-)

I'll emphasize again though, that in both (1) and (2), we're
just changing from one kind of invalid/has-no-effect to a
/slightly/ different kind of invalid/has-no-effect.

On Mon, Oct 2, 2023 at 1:30 PM Anders Hartvoll Ruud
mailto:andr...@chromium.org>> wrote:


Contact emails

andr...@chromium.org 


Specification

https://drafts.csswg.org/css-syntax/#consume-block-contents 



Summary

Allows nested style rules
 to 
begin with an identifier. For example, the following will now be possible:


p {

   span { color: green; }

}




   I am green




Before this change, the inner spanselector had to be
“escaped” using :is()or similar, due to restrictions in
css-syntax. These restrictions have now been lifted by
giving the parser the ability to restart

.


Blink component

Blink>CSS




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

To address some problematic parsing edge cases, the
CSSWG has made two additional changes to css-syntax that
have theoretical web-facing impact. These changes will
ship in this intent as well:


 1.

Braces ({}) are now fundamentally invalid in
standard properties, unless they span the whole
value. No property grammar allows {}in any part of
the value currently, so this is already invalid, but
when var()is used in combination with {}, this
intent changes whenit becomes invalid. With this
intent, e.g. color: var(--x) {};becomes invalid
parse-timeinstead of at computed-value time

. This isan 
observable difference, but there’s no known reason for this to occur in practice outside of 
mistakes. Nevertheless, I have tried to estimate the number of possibly-impacted sites:  ~0.0011% 
(Web Compat Analysis: Relaxed Nesting 
[@chromium.org
 ]).

 2.

A style rule prelude (i.e. the selector list) can no
longer start with --ident:. Again, this is in a
sense already “invalid”, since HTML elements never
start with -- (including custom elements, which must
start with a letter), so such rules can never match
anything. This intent makes the situation a parse
error instead. Estimated impact: ~0.0007% (Web
  

Re: [blink-dev] Intent to Ship: CSS :dir() pseudo-class selector

[Manuel Rego Casasnovas]

LGTM1

Just for context, this was already approved 3 years ago:
https://groups.google.com/a/chromium.org/g/blink-dev/c/p0Wc66rbVOc/m/khHJ0dSsAwAJ

But then we realized the spec text was not ready, there were some 
misunderstandings and things got blocked on that.


Big thanks to push this to the finish line!

Cheers,
  Rego

On 03/10/2023 20:37, David Baron wrote:


Contact emails

dba...@chromium.org , dizha...@chromium.org 
, myid.s...@igalia.com 




Explainer

None


Specification

https://www.w3.org/TR/selectors-4/#the-dir-pseudo 




Summary

The :dir() CSS pseudo-class selector matches elements based on 
directionality, which is determined based on the HTML dir attribute. 
:dir(ltr) matches left-to-right text directionality, and :dir(rtl) 
matches elements with right-to-left text directionality. It is not 
equivalent to [dir] attribute selectors because it matches against 
directions inherited from an ancestor with the dir attribute, and 
because it matches against the direction computed from use of dir=auto 
(which determines directionality from the first character in the text 
with strong directionality).




Blink component

Blink>CSS 




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is largely an additive feature. However, as part of the process of 
preparing to ship the feature, we worked on more clearly specifying 
exactly how directionality in HTML works, and particularly how it 
interacts with shadow DOM. This work is occurring in 
https://github.com/whatwg/html/issues/3699 
 
https://github.com/whatwg/html/pull/9554 
 and 
https://github.com/whatwg/html/pull/9796 
 . Since these changes to HTML 
directionality also affect the dirname attribute (which is a form 
submission feature), they have been implemented behind the same flag as 
the pseudo-class. However, they are likely to be low risk because the 
recommended way of using the dirname attribute is to use dir=auto on the 
same element as the dirname attribute, and that usage pattern should not 
be affected. This feature is part of Interop2023's focus area on CSS 
Pseudo-classes: https://wpt.fyi/interop-2023 




/Gecko/: Shipped/Shipping 
(https://bugzilla.mozilla.org/show_bug.cgi?id=562169 
)


/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=64861 
) Supported as of Safari 
16.4 according to https://caniuse.com/css-dir-pseudo 



/Web developers/: No signals

/Other signals/: CSSWG consensus to ship documented in 
https://www.w3.org/TR/css-2017/#experimental 
 (CSSWG includes reps from 
all major browser vendors)



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

Same as other pseudo-classes



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

No


Is this feature fully tested by web-platform-tests

?

Yes

WPT test plan (somewhat out of date, since recent CLs have added many 
tests) at https://github.com/web-platform-tests/wpt/issues/25569 
 Existing tests 
have names starting with "dir" in https://wpt.fyi/results/css/selectors 
 and 
https://wpt.fyi/results/html/dom/elements/global-attributes 
 PR for 
testing shadow DOM interaction at 
https://github.com/web-platform-tests/wpt/pull/29820 
 which will add 
additional tests




Flag name on chrome://flags



Finch feature name

kCSSPseudoDir


Requires code in //chrome?

False


Tracking bug

https://code.google.com/p/chromium/issues/detail?id=576815 




Availability expectation

Available in all major browsers once we ship.


Sample links


https://jsfiddle.net/fxc9a8uc/1 


Estimated milestones

Shipping on desktop 120

Shipping on Android 120

Shipping on WebView 120

Re: [blink-dev] Intent to Ship: Media Queries: scripting feature

[Manuel Rego Casasnovas]

LGTM1

Thanks for catching up on this feature.

Cheers,
  Rego

On 26/08/2023 17:56, Luke wrote:
> 
> Contact emails
> 
> lukewarlow...@gmail.com
> , l...@warlow.dev 
> 
> 
> Explainer
> 
> None
> 
> 
> Specification
> 
> https://drafts.csswg.org/mediaqueries-5/#scripting
> 
> 
> 
> Summary
> 
> The scripting media feature is used to query whether scripting
> languages, such as JavaScript, are supported on the current document.
> Valid options are 'enabled', 'initial-only', 'none'. However,
> 'initial-only' never matches inside a browser.
> 
> 
> 
> Blink component
> 
> Blink>CSS
> 
> 
> 
> Search tags
> 
> scripting
> , media-queries
> 
> 
> 
> TAG review
> 
> None
> 
> 
> TAG review status
> 
> Not applicable
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> Already implemented in Firefox and WebKit so only interoperability risk
> would be differing implementions. As of the other day WebKit now matches
> Chromium and Firefoxs implementation.
> 
> 
> 
> /Gecko/: Shipped/Shipping
> (https://groups.google.com/a/mozilla.org/g/dev-platform/c/BU3zzial8lE/m/6e2LBQFIAwAJ
>  
> )
> 
> /WebKit/: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/15076
> )
> 
> /Web developers/: No signals
> 
> /Other signals/:
> 
> 
> Ergonomics
> 
> This feature will not be used in tandem with other platform APIs. The
> default usage of this API will not make it hard for chrome to maintain
> good performance.
> 
> 
> 
> Activation
> 
> It will not be challenging for developers to use this feature
> immediately. There is already an MDN article for this feature, so I
> don't think that we need additional outreach.
> 
> 
> 
> Security
> 
> There are no security risks for this feature.
> 
> 
> 
> 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?
> 
> None
> 
> 
> 
> Debuggability
> 
> This media query can be tested using the 'Disable JavaScript' setting
> inside of DevTools Preferences.
> 
> 
> 
> 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
> 
> 
> Flag name on chrome://flags
> 
> #enable-experimental-web-platform-features
> 
> 
> Finch feature name
> 
> ScriptingMediaFeature
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Tracking bug
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1467097
> 
> 
> 
> Availability expectation
> 
> This feature is already implemented by safari and firefox, so it will be
> available on the web platform mainline as soon as it reaches the stable
> version of all browsers.
> 
> 
> Adoption expectation
> 
> This will be considered best practice for its use case once launched
> 
> 
> Adoption plan
> 
> This is already implemented in safari and firefox, so we don't need to
> do anything in order to gain adoption of this feature.
> 
> 
> Non-OSS dependencies
> 
> Does the feature depend on any code or APIs outside the Chromium open
> source repository and its open-source dependencies to function?
> 
> No
> 
> 
> Sample links
> 
> 
> https://developer.mozilla.org/en-US/docs/Web/CSS/@media/scripting
> 
> 
> 
> Estimated milestones
> 
> Shipping on desktop   118
> DevTrial on desktop   118
> 
> Shipping on Android   118
> DevTrial on Android   118
> 
> Shipping on WebView   118
> 
> 
> 
> Anticipated spec changes
> 
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github
> issues in the project for the feature specification) whose resolution
> may introduce web compat/interop risk (e.g., changing to naming or
> structure of the API in a non-backward-compatible way).
> 
> There are no anticipated spec changes.
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://chromestatus.com/feature/5075009105559552
> 
> 
> 
> Links to previous Intent discussions
> 
> Intent to
> 

Re: [blink-dev] Intent to Ship: CSS Relative Color Syntax (RCS)

[Manuel Rego Casasnovas]

On 29/08/2023 16:17, Aaron Krajeski wrote:
> *Explainer: *go/rcs-chromium 

That's not a public link, please could you make it public?

> Risks
> 
> Interoperability and Compatibility
> 
> None
> 
> 
> /Gecko/: No signal

Why no signals from Gecko? Have we filled a standards position request
or do we know other information about Gecko supporting this feature?

> /WebKit/: Shipped (https://caniuse.com/css-relative-colors
> )
> 
> /Web developers/: No signals

I guess some developers have asked about this feature right? Do we have
any info regarding that?

Thanks,
  Rego

-- 
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/1aa1b50b-5745-3dee-46cb-eae57182eeb5%40igalia.com.

Re: [blink-dev] Intent to Implement & Ship: AudioEncoderConfig.bitrateMode

[Manuel Rego Casasnovas]

LGTM3

On 22/08/2023 16:30, Mike Taylor wrote:
> LGTM2
> 
> On 8/22/23 10:10 AM, Yoav Weiss wrote:
>> LGTM1. Mirroring video codecs makes sense. Glad to see Mozilla being
>> supportive.
>>
>> On Thu, Aug 17, 2023 at 8:51 PM 'Thomas Guilbert' via blink-dev
>>  wrote:
>>
>> Contact emails
>>
>> tguilb...@google.com
>>
>>
>> Explainer
>>
>> None
>>
>>
>> Specification
>>
>> https://w3c.github.io/webcodecs/#dom-audioencoderconfig-bitratemode
>>
>> 
>>
>>
>> Summary
>>
>>
>> Some audio codecs support specifying the audio encoder bitrate
>> modes. This feature adds a "bitrateMode" flag with a default value
>> of “variable” to WebCodec's AudioEncoderConfig, which mirrors the
>> functionality already present for VideoEncoderConfig
>> .
>>
>>
>> This flag will allow web authors to choose between encoding audio
>> with a variable bitrate or a constant bitrate. Specific codec
>> encoder implementations might have slightly different terminology
>> (e.g. `CBR` vs `VBR` for Opus), but all of them should map to the
>> general concept of "constant" versus "variable" bitrate.
>>
>>
>> The two options have the following effects:
>>
>>  *
>>
>> “variable”:  allows an audio encoder to increase or lower its
>> bitrate according to the content of the audio it is encoding,
>> in order to preserve bandwidth/binary-size, while still
>> maintaining a target quality. For example, an encoder might
>> lower its bitrate when encoding silence, and revert to a full
>> bitrate when encoding speech.
>>
>>  *
>>
>> “constant” : forces an audio encoder to maintain the same
>> bitrate, regardless of the audio content. This can be useful
>> when a predictable bandwidth consumption is preferable.
>>
>>
>> As of M118, this flag will affect two codecs on Chromium: Opus and
>> AAC.
>>
>>
>>
>> Blink component
>>
>> Blink>Media>WebCodecs
>> 
>> 
>>
>>
>> TAG review
>>
>> None
>>
>>
>> TAG review status
>>
>> Not applicable
>>
>>
>> Risks
>>
>>
>>
>> Interoperability and Compatibility
>>
>> The risk is low. Firefox has not yet shipped WebCodecs, but is
>> currently developing it. Safari has developed video WebCodecs, but
>> not yet audio. The flag should be easy for other browsers to add
>> as they implement WebCodecs.
>>
>>
>> Gecko: Positive
>> (https://github.com/mozilla/standards-positions/issues/837
>> )
>>
>>
>> WebKit: No signal
>> (https://github.com/WebKit/standards-positions/issues/218
>> )
>>
>>
>> Web developers: Positive, as feature was originally a developper
>> request – https://github.com/w3c/webcodecs/issues/649
>> 
>>
>>
>> Other signals:
>>
>>
>> WebView application risks
>>
>> This change does not deprecate existing APIs, and only supplements
>> existing APIs, with a sensible default. This should not be a
>> WebView risk.
>>
>>
>>
>> Debuggability
>>
>>
>>
>> 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
>> 
>> ?
>>
>> It will be at the time it is implemented. Example test
>> 
>> .
>>
>>
>> Flag name on chrome://flags
>>
>> N/A
>>
>>
>> Finch feature name
>>
>> N/A
>>
>>
>> Non-finch justification
>>
>> Simple parameter change
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1462467
>>
>> 
>>
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>>  
>>
>> 118
>>
>>
>> Shipping on Android
>>
>>  
>>
>> 118
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5084320053592064
>> 
>>
>>
>> -- 
>>

Re: [blink-dev] Intent to Ship: CSS Subgrid

[Manuel Rego Casasnovas]

LGTM3

Really looking forward for having subgrid support everywhere!

On 15/06/2023 23:22, Yoav Weiss wrote:
> LGTM2
> 
> On Thu, Jun 15, 2023 at 6:10 PM Yoav Weiss  > wrote:
> 
> 
> 
> On Thu, Jun 15, 2023 at 6:04 PM Ian Kilpatrick
> mailto:ikilpatr...@chromium.org>> wrote:
> 
> 
> 
> On Thu, Jun 15, 2023 at 2:36 AM Yoav Weiss
> mailto:yoavwe...@chromium.org>> wrote:
> 
> Also, thank you so much for working on this and aligning us
> with other vendors on this important developer feature!! :)
> 
> On Thu, Jun 15, 2023 at 11:32 AM Yoav Weiss
> mailto:yoavwe...@chromium.org>> wrote:
> 
> 
> 
> On Thu, Jun 15, 2023 at 7:49 AM 'Ethan Jimenez' via
> blink-dev  > wrote:
> 
> 
> Contact emails
> 
> etha...@microsoft.com 
> 
> __ __
> 
> 
> Explainer
> 
> None
> 
> 
> Well, a short search revealed this article
>  (by
> Ahmed Shadeed) as a great explainer!
>  
> 
> 
> 
> __ __
> 
> 
> Specification
> 
> https://www.w3.org/TR/css-grid-2/#subgrids
> 
> 
> __ __
> 
> 
> Design docs
> 
> __ __
> 
> 
> https://docs.google.com/document/d/1cpsCmzdDlXUKtMxOUKIoJFyLH54mLVhZnam_z0PriO0/edit?usp=sharing
>  
> 
> 
> __ __
> 
> 
> Summary
> 
> Implements the CSS Grid Layout Module Level 2
> specification, which introduces the concept of a
> "subgrid" to nested grid containers.
> 
> __ __
> 
> 
> Blink component
> 
> Blink>CSS
> 
> 
> 
> __ __
> 
> 
> Search tags
> 
> subgrid
> ,
> css-grid-2
> ,
> css 
> 
> __ __
> 
> 
> TAG review
> 
> Review Request for CSS Subgrid · Issue #712 ·
> w3ctag/design-reviews (github.com)
> 
> 
> __ __
> 
> 
> TAG review status
> 
> Issues addressed
> 
> __ __
> 
> 
> Risks
> 
> __ __
> 
> 
> Interoperability and Compatibility
> 
> This is a well-defined specification from the W3C,
> so we would be addressing some interoperability gaps
> instead of causing them.
> 
> __ __
> 
> /Gecko/: Shipped/Shipping
> 
> __ __
> 
> /WebKit/: Shipped/Shipping
> 
> __ __
> 
> /Web developers/: Strongly positive
> 
> __ __
> 
> /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?/
> 
> __ __
> 
> 
> Debuggability
> 
> This feature is an extension of the capabilities of
> the CSS Grid Layout Module, no new properties will
> be introduced, but a new value "subgrid" will be
> introduced and properly rolled into the DevTools
> repository.
> 
> __ __
> 
> 
> Will this feature be supported on all six
> Blink platforms (Windows, Mac, Linux, Chrome
> OS, Android, and Android WebView)?
> 
> Yes
> 
> 

Re: [blink-dev] Intent to Ship: Boolean Context Style Container Queries

[Manuel Rego Casasnovas]

LGTM1

On 03/05/2023 14:22, Rune Lillesveen wrote:
> 
> Contact emails
> 
> futh...@chromium.org 
> 
> 
> Explainer
> 
> None
> 
> 
> Specification
> 
> https://drafts.csswg.org/css-contain-3/#style-container
> 
> 
> 
> Summary
> 
> Support style() container queries without a declaration value, only a
> property name, as a way of matching non-initial values. Previously you
> would have to do: not style(--my-property: initial) Now you can do:
> style(--my-property) to match any non-initial value.
> 
> 
> 
> Blink component
> 
> Blink>CSS
> 
> 
> 
> TAG review
> 
> None
> 
> 
> TAG review status
> 
> Not applicable
> 
> 
> Risks
> 
> 
> This is a minor change in the existing style() queries API. No new
> standards positions. Chrome shipped style() queries for custom
> properties in M111, but none of the other browsers have.
> 
> The effect on existing content is that boolean context style queries
> that currently parse as  and evaluate to 'unknown'
> will start evaluating to true/false depending on computed value. It is
> so unlikely that existing content will be affected by this that it does
> not seem to be worth the effort to measure.
> 
> 
> Interoperability and Compatibility
> 
> 
> 
> /Gecko/: No signal
> (https://github.com/mozilla/standards-positions/issues/686
> )
> 
> /WebKit/: No signal
> (https://github.com/WebKit/standards-positions/issues/57
> )
> 
> /Web developers/: No signals
> 
> /Other signals/:
> 
> 
> 
> 
> Debuggability
> 
> Works
> 
> 
> 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
> 
> Tests added for custom property queries under:
> 
> http://wpt.fyi/css/css-contain/container-queries/at-container-style-parsing.html
>  
> 
> http://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
>  
> 
> http://wpt.fyi/css/css-contain/container-queries/custom-property-style-queries.html
>  
> 
> 
> 
> 
> Flag name
> 
> #enable-experimental-web-platform-features
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Tracking bug
> 
> https://crbug.com/1442183 
> 
> 
> Estimated milestones
> 
> Shipping on desktop   115
> DevTrial on desktop   114
> 
> Shipping on Android   115
> DevTrial on Android   114
> 
> Shipping on WebView   115
> 
> 
> 
> Anticipated spec changes
> 
> Resolved in [1], first PR merged [2], and a second spec-text-tweak PR to
> be merged [3]. 
> 
> 
> [1] https://github.com/w3c/csswg-drafts/issues/8127#issuecomment-1479871971 
> 
> 
> [2] https://github.com/w3c/csswg-drafts/pull/8729
> 
> 
> [3] https://github.com/w3c/csswg-drafts/pull/8756
> 
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://chromestatus.com/feature/6332337266098176
> 
> 
> 
> Links to previous Intent discussions
> 
> 
> 
> This intent message was generated by Chrome Platform Status
> .
> 
> -- 
> Rune Lillesveen
> 
> -- 
> 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/CACuPfeQszxjQghv1Gu7huZxNrWOCT0GS_9YEDmqejdont8%3D6_Q%40mail.gmail.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 

Re: [blink-dev] Intent to Ship: overflow:overlay aliases overflow:auto

[Manuel Rego Casasnovas]

LGTM3

On 07/04/2023 17:38, Mike Taylor wrote:
> LGTM2
> 
> On 4/7/23 11:34 AM, Yoav Weiss wrote:
>> LGTM1
>>
>> On Thu, Apr 6, 2023 at 2:01 AM Chris Harrelson 
>> wrote:
>>
>>
>> Contact emails
>>
>>
>> chris...@chromium.org
>>
>>
>> Specification
>>
>>
>> https://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto
>>
>>
>> Summary
>>
>>
>> Removes the overflow:overlay scrolling mode, and makes
>> overlay a legacy alias of auto. overflow:overlay is the
>> same as overflow:auto, except that it does not prevent
>> content from extending into the scrollbar gutter, in cases
>> where non-overlay OS scrollbars are present. (If overlay
>> scrollbars are present, there is no effect.) Example: With
>> overflow:overlay: https://output.jsbin.com/yujenuq/quiet
>> With overflow:auto: https://output.jsbin.com/ruzogaf/quiet
>>
>>
>>
>> Blink component
>>
>>
>> Blink>Scroll
>> 
>> 
>>
>>
>> TAG review
>>
>>
>> None
>>
>>
>> TAG review status
>>
>>
>> Not applicable
>>
>>
>> Risks
>>
>>
>>
>>
>> Interoperability and Compatibility
>>
>>
>> Developers currently relying on content overlapping the
>> scrollbar gutter would instead see some additional line
>> wrapping. Users, on the other hand, would be able to see
>> more content that is currently invisible underneath a
>> scrollbar. On platform configurations with overlay
>> scrollbars in the OS, this change has no effect; it only
>> applies to situations where a non-overlay scrollbar is
>> configured by the browser. Use counter:
>> 
>> https://chromestatus.com/metrics/feature/timeline/popularity/2995 Adoption 
>> is more than 2% of page loads. However: * I don't think any sites will break 
>> for users. * Some sites will improve because they are currently preventing 
>> users from seeing some content that is accidentally underneath a non-overlay 
>> scrollbar. * Interop will be achieved with Webkit and Gecko. I reviewed 
>> 
>>  20 sites listed from the HTTPArchive and found nothing broken. The only 
>> "downside" was that the visible spacing between content and the scrollbar 
>> increased by a few pixels in some cases. In none of these cases was it a 
>> significant change to the user experience. On two of the sites, 
>> -webkit-scrollbar was also used to make the scrollbar narrower when not 
>> hovered, in conjunction with overflow:overlay to reduce the gutter spacing. 
>> On those sites, the gutter got a bit wider but the user experience was not 
>> materially affected.
>>
>>
>>
>> /Gecko/: Shipped/Shipping
>> (https://github.com/mozilla/standards-positions/issues/768)
>>
>> /WebKit/: Shipped/Shipping
>> (https://github.com/WebKit/standards-positions/issues/157)
>>
>> /Web developers/: No signals
>>
>> /Other signals/:
>>
>>
>> Ergonomics
>>
>>
>> After this change, sites will no longer be able to avoid
>> reserving space for the scrollbar. However, this is good,
>> because the scrollbar does take up space and it's bad for
>> users not to be able to read content obscured by it. The
>> CSSWG has in the past considered all of this and resolved
>> not to let developers prevent a scrollbar gutter, because
>> overlay scrollbars are an OS feature, and it's more
>> important for users to see content than for developers to
>> micro-manage an important user affordance. See
>> https://github.com/w3c/csswg-drafts/issues/4501 for
>> example. I found three use cases developers seemed to want
>> to achieve on these sites: * Reduce scrollbar gutter size
>> * "force" overlay scrollbars (there is no way to do that,
>> but overflow:overlay might lead them to that conclusion) *
>> Reduce the gutter when used in conjunction with a custom
>> scrollbar via -webkit-scrollbar that reduces its width
>> when not hovered. Use case 3 is better solved by shipping
>> scrollbar-width in the future
>> 
>> (https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-width)
>>
>>
>>
>> Activation
>>
>>
>> None
>>
>>
>>
>> Security
>>
>>
>> None
>>
>>
>>
>> WebView application risks
>>
>>
>> Does this intent deprecate or change behavior of existing
>> APIs, such that it has potentially 

Re: [blink-dev] Intent to Ship: CSS "overflow" media features

[Manuel Rego Casasnovas]

LGTM2

On 14/03/2023 16:13, Daniil Sakhapov wrote:
> Done:
> https://github.com/WebKit/standards-positions/issues/146
> 
> On Wednesday, March 8, 2023 at 6:09:22 PM UTC+1 Yoav Weiss wrote:
> 
> LGTM1 % filing a WebKit position
> 
> We discussed this intent at the API owner meeting (Rick, Chris,
> Daniel, MikeT, Philip,, Alex and myself). We agreed that there's
> value in filing a WebKit position issue here, if anything to put
> this on their radar (pun not intended) and let them know we intend
> to ship this and that Gecko already has.
> 
> I also wish we had some developer signal for this, but given the
> fact Gecko already shipped, I won't block on it.
> 
> On Tue, Mar 7, 2023 at 12:37 PM Philip Jägenstedt
> mailto:foo...@chromium.org>> wrote:
> 
> I think this feature falls under Implementations of
> already-defined consensus-based standards
> 
> 
>  in our process, and Signals from other implementations in an intent-to-ship 
> 
>  aren't part of that section.
> 
> If this wasn't already shipped in Gecko I do agree with Alex
> that the spec status shouldn't carry a lot of weight and we
> should file standards positions, but I don't think our
> documented process backs up that preference.
> 
> Anyway, this has already shipped in Gecko, and I don't think we
> need to file a standards position issue for WebKit.
> 
> In other words, I'd be happy to LGTM this, but will abstain
> since Daniil is on my team.
> 
> On Mon, Mar 6, 2023 at 6:49 PM Alex Russell
> mailto:slightly...@chromium.org>> wrote:
> 
> Our history with the WebKit project suggests that
> imputations of implicit consent are unwelcome, and so in
> addition to the general orientation of our process towards
> explicit evidence, it is in the interest of respecting the
> WebKitten's own preferences that we ask formally.
> 
> Best,
> 
> Alex
> 
> On Friday, March 3, 2023 at 8:33:26 PM UTC-8
> flo...@rivoal.net  wrote:
> 
> 
>> On 4Mar 2023, at 5:59, Alex Russell
>> > > wrote:
>>
>> Our process does not pay much mind to arbitrary
>> standards gates when others have not already shipped.
>> If WebKit had (has?) implemented, that would shortcut
>> our analysis, otherwise, it's still worth asking.
> 
> The point is not about what the W3C Process say you can
> do at what stage, the point is that for a CSS spec to
> get to CR, there needs to be a sign off from the groups’
> members that this is OK to ship. This is not as strong
> as “we want to ship this ourselves soon”, but this is
> stronger than “no signal”, as was stated earlier.
> 
> This may be true in other groups, but it is especially
> true in the CSSWG, which includes all the browsers, and
> has an explicit policy that publishing something as a CR
> means we have consensus it is OK to ship it.
> https://www.w3.org/TR/css/#testing
> 
> 
> So my read of webkit’s position would be: “has indicated
> support for the feature being shipped in general,
> unclear when they intend to do so themselves”. It’s
> absolutely reasonable to ask webkit if you’re looking
> for something more firm that than (or more recent, or…),
> but I think it is worth noting you at least have that much.
> 
> —Florian
> 
> -- 
> 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/f709d52b-46ba-4390-b307-cda73990db1en%40chromium.org
>  
> .
> 
> -- 
> 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 

Re: [blink-dev] Intent to Ship: WebAssembly extended-const Proposal

[Manuel Rego Casasnovas]

LGTM2.

On 08/03/2023 14:00, Yoav Weiss wrote:
> LGTM1
> 
> On Mon, Mar 6, 2023 at 12:39 PM Lutz Vahl  > wrote:
> 
> 
> Contact emails
> 
> manosk...@google.com 
> 
> 
> Explainer
> 
> 
> https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/Overview.md
>  
> 
>  
> 
> 
> Specification
> 
> https://github.com/WebAssembly/extended-const
> 
> 
> 
> Summary
> 
> We implement the WebAssembly extended-const proposal according
> tohttps://github.com/WebAssembly/extended-const
> .
> 
> Specifically, we add i32.add, i32.sub, i32.mul, i64.add, i64.sub and
> i64.mul to the list of constant instructions.
> 
> 
> 
> Blink component
> 
> Blink>JavaScript>WebAssembly
> 
> 
> 
> 
> TAG review
> 
> Not needed in our view, as this is a very small change to existing
> functionality.
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> N/A. The WebAssembly spec
> 
> reached
>  Phase 4, therefore engines will implement it.
> 
> 
> 
> Debuggability
> 
> 
> 
> 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
> 
> ?
> 
> WebAssembly Spec Tests:
> https://github.com/WebAssembly/extended-const/tree/main/test
>  
> 
> 
> Flag name
> 
> Experimental WebAssembly
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Estimated milestones
> 
> M113 behind a flag, M114 as default
> 
> 
> 
> Tracking bug
> 
> https://bugs.chromium.org/p/v8/issues/detail?id=12089
> 
> 
> 
> Estimated milestones
> 
> DevTrial on desktop
> 
>   
> 
> 113
> 
> 
> DevTrial on Android
> 
>   
> 
> 113
> 
> 
> 
> 
> 
> 
> Anticipated spec changes
> 
> Open questions about a feature may be a source of future web compat
> or interop issues. Please list open issues (e.g. links to known
> github issues in the project for the feature specification) whose
> resolution may introduce web compat/interop risk (e.g., changing to
> naming or structure of the API in a non-backward-compatible way).
> 
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://chromestatus.com/feature/5131077456232448
> 
> 
> 
> This intent message was generated by Chrome Platform Status
> .
> 
> 
> -- 
> 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/CAH0ixBN2UjgnumxjSWj0GX0GgKJL0mtEinbr-NRWHwpvjth8fA%40mail.gmail.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/CAL5BFfVgZCURALU28Q9%2BUL5mrSqT551wFSUZ0jpfvEkb_AGCrQ%40mail.gmail.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/9085bcd5-af51-9127-5493-d879c75783dd%40igalia.com.

Re: [blink-dev] Re: Intent to Ship: CSS "update" media feature

[Manuel Rego Casasnovas]

On 02/03/2023 05:59, Mike Taylor wrote:
> 
> On 3/1/23 3:41 PM, Domenic Denicola wrote:
>>
>>
>> On Wed, Mar 1, 2023 at 10:14 PM Yoav Weiss  wrote:
>>
>>
>>
>> On Tue, Feb 28, 2023 at 4:07 PM Daniil Sakhapov
>>  wrote:
>>
>> agree, my mistake, I thought about explaining 3 types of
>> output displays, not the media feature values
>>
>> On Tue, Feb 28, 2023 at 2:28 PM Patrick Lauke
>>  wrote:
>>
>> Shouldn't the first value be `none` rather than `print` ?
>>
>> On Tuesday, 28 February 2023 at 12:22:03 UTC Daniil
>> Sakhapov wrote:
>>
>>
>> Contact emails
>>
>> sakh...@chromium.org
>>
>>
>> Specification
>>
>> https://drafts.csswg.org/mediaqueries-4/#descdef-media-update
>>
>>
>> This is one of the rare cases where the feature is simple enough
>> and the spec is clear enough that an explainer is not really
>> needed! :)
>>  
>>
>>
>>
>> Summary
>>
>> Implements "update" media feature. Allows to
>> distinguish styles for print, slow and fast output
>> displays: print - for documents on the paper; slow -
>> for e-ink and underpowered displays; fast - regular
>> computer displays.
>>
>> Note:
>>
>> Browser should set the web setting, saying if it has a
>> slow or fast screen, default is fast.
>>
>>
>> Blink component
>>
>> Blink>CSS
>> 
>> 
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>> /Gecko/: Shipped/Shipping
>>
>>
>> (You could have used the WPT results
>> 
>> 
>>  as a link to back this up)
>>  
>>
>>
>> /WebKit/: No signal
>>
>>
>> Can you file a WebKit position?
>>
>>
>> I wonder if this might not be necessary for features that are part of
>> Interop 2023? I think given the veto process in how that list is
>> assembled, that guarantees at least a "neutral" position from all
>> vendors. (Knowing whether WebKit feels "positive" or "neutral" about
>> the feature might be interesting, but doesn't feel like a great use of
>> our or their time, at least for small features like this.)
> 
> I like this idea, but let's move this part of the discussion to
> blink-api-owners-discuss@ (I can start a thread), and we can circle back
> with an update on the consensus view.
> 
>>  
>>
>>
>>
>> Any word on web developer demand for it?
>>  
>>
>>
>> /Spec/: the feature is marked as "at risk", but it's
>> part of the Interopt 2023 + Firefox has shipped it. We
>> can save the feature!

I guess that if this is part of Interop 2023 and we're planning to ship
too, we should ask CSSWG to remove the feature from "at-risk".

Cheers,
  Rego

>>
>>
>>
>> Is this feature fully tested
>> by web-platform-tests
>> 
>> ?
>>
>> Yes
>> https://wpt.fyi/css/mediaqueries/update-media-feature.html
>>
>>
>> Flag name
>>
>> CSSUpdateMediaFeature
>>
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=791028
>>
>>
>> Estimated milestones
>>
>> DevTrial on desktop  113
>>
>> DevTrial on Android  113
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5154424982339584
>>
>> This intent message was generated by Chrome Platform
>> Status .
>>
>> -- 
>> 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/CAH3Z92_-FaTz7z9S-eiWGw-_ZOap32FcOVig3VMJLxguQpoq0Q%40mail.gmail.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 

Re: [blink-dev] Intent to Ship: Linear easing function

[Manuel Rego Casasnovas]

This has been already approved.

Anyway one minor question, why are the WPT tests marked as "tentative"?
https://wpt.fyi/results/css/css-easing

Maybe now that is shipping in 2 browsers we could rename them.

Cheers,
  Rego

On 07/03/2023 16:57, Mike Taylor wrote:
> LGTM2
> 
> On 3/7/23 6:10 AM, Yoav Weiss wrote:
>> LGTM1 given the fact we'd be catching up to Gecko here, and the
>> developer interest in this.
>>
>> On Thu, Mar 2, 2023 at 10:38 PM Bienes Raices Vargas y A
>>  wrote:
>>
>> 2023-03-01 7:24 GMT-06:00, Yoav Weiss :
>> > On Tue, Feb 28, 2023 at 9:04 PM Mike Taylor
>>  wrote:
>> >
>> >> On 2/28/23 7:25 AM, Daniil Sakhapov wrote:
>> >>
>> >> Contact emails sakha...@chromium.org
>> >>
>> >> An explainer (even a short & inlined one) would have been
>> helpful here to
>> > understand what the feature does and how developers will use it.
>> >
>> >> Specification
>> >>
>> https://w3c.github.io/csswg-drafts/css-easing/#the-linear-easing-function
>> >>
>> >> Summary
>> >>
>> >> Introduces linear() easing function that allows linear
>> interpolation
>> >> between a number of points.
>> >>
>> >> Note: Requires implementation work from the DevTools team in
>> the line
>> >> editor
>> >>
>> >> Are there bugs on file to track this work? Do we expect it to
>> be ready
>> >> for
>> >> M113?
>> >>
>> >>
>> >> Blink component Blink>CSS
>> >>
>> 
>> 
>> >>
>> >> Risks
>> >> Interoperability and Compatibility
>> >> *Gecko*: Shipped/Shipping
>> >>
>> >> *WebKit*: No signal
>> >>
>> >>
>> > Can you file for a signal?
>> >
>> > Any word on developer interest in this?
>> >
>> >>
>> >> 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
>> >>
>> wpt.fyi/css/css-easing/linear-timing-functions-syntax.tentative.html
>> >>
>> wpt.fyi/css/css-transitions/parsing/transition-timing-function-valid.html
>> >>
>> >> Flag name CSSLinearTimingFunction
>> >>
>> >> Tracking bug
>> >> https://bugs.chromium.org/p/chromium/issues/detail?id=1416540
>> >>
>> >> Estimated milestones
>> >> DevTrial on desktop 113
>> >> DevTrial on Android 113
>> >> Link to entry on the Chrome Platform Status
>> >> https://chromestatus.com/feature/5139710823890944
>> >>
>> >> Links to previous Intent discussions Intent to prototype:
>> >>
>> 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z92-JJPXCivY0%2BZZZ_FyW8enk_zrco74oYN2Ub0ZyYuA6Qw%40mail.gmail.com
>> >>
>> >>
>> >> This intent message was generated by Chrome Platform Status
>> >> .
>> >> --
>> >> 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/CAH3Z92_naoNMzYobpYxQp99BEUg2PD2_BjLM%2BaOCNZPyk%3Ds_9Q%40mail.gmail.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/55271f85-287c-93c3-4837-86a7e6ec60cd%40chromium.org
>> >>
>> 
>> >  
>> >
>> >> .
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the
>> 

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Manuel Rego Casasnovas]

LGTM2

Thank you very much for fixing the issues before shipping.

On 08/03/2023 10:53, Yoav Weiss wrote:
> Even though wpt.fyi
> 
>  is reddish, I'm seeing all the tests pass on ToT. Thank you!!

I guess that's because wpt.fyi is still using Chrome 112, when the last
patches have landed in 113.

Cheers,
  Rego

-- 
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/6120b437-2cf9-db52-6a2b-b6a7eb34bda8%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[Manuel Rego Casasnovas]

Hi David,

Thanks for the amazing email!

On 23/02/2023 23:52, David Baron wrote:
> I don't think the specification was designed around the idea that some
> implementations would follow the spec's rules on synthesis and some
> implementations would ignore the spec... and thus it does appear to be a
> problem that whether an implementation does synthesis isn't detectable. 
> (This seems worth discussing in the CSS Working Group if it hasn't been
> already.)

There's a CSSWG issue about this topic in particular:
https://github.com/w3c/csswg-drafts/issues/7441

Cheers,
  Rego

-- 
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/649bb2a0-26f1-320f-dc32-b630b8b7c608%40igalia.com.

Re: [blink-dev] Intent to Ship: Change beforeunload handler dialog condition

[Manuel Rego Casasnovas]

LGTM1

This aligns us with the rest of browsers, thanks for fixing it.

Cheers,
  Rego

On 21/02/2023 19:24, Di Zhang wrote:
> 
> Contact emails
> 
> dizha...@chromium.org 
> 
> 
> Specification
> 
> https://html.spec.whatwg.org/multipage/browsing-the-web.html#checking-if-unloading-is-user-canceled
>  
> 
> 
> 
> Summary
> 
> Change beforeunload handler to show confirm dialog when preventDefault()
> gets called.
> 
> 
> 
> Blink component
> 
> Blink>DOM
> 
> 
> 
> TAG review
> 
> None
> 
> 
> TAG review status
> 
> Not applicable
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> Now, if website is calling `preventDefault()` on a beforeunload event,
> it will show the confirmation dialog to cancel the unload event. Before,
> if website is calling `preventDefault()` on a beforeunload event, it
> will not show the confirmation dialog and navigate.
> 
> 
> 
> /Gecko/: Shipped/Shipping
> 
> /WebKit/: Shipped/Shipping
> 
> /Web developers/: Positive
> 1. https://bugs.chromium.org/p/chromium/issues/detail?id=866818
> 
> 2. 
> https://stackoverflow.com/questions/9626059/window-onbeforeunload-in-chrome-what-is-the-most-recent-fix
>  
> 
> 3. 
> https://stackoverflow.com/questions/1119289/how-to-show-the-are-you-sure-you-want-to-navigate-away-from-this-page-when-ch
>  
> 
> 
> /Other signals/:
> 
> 
> Ergonomics
> 
> There are no other APIs that this feature will be used in tandem with.
> 
> 
> 
> Activation
> 
> It should not be challenging for developers to take advantage of this
> feature immediately.
> 
> 
> 
> Security
> 
> There are no security risks for this feature.
> 
> 
> 
> WebView application risks
> 
> There is no high risk for webview.
> 
> 
> Debuggability
> 
> DevTools support for this feature is not needed.
> 
> 
> 
> Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
> 
> Yes
> 
> All platforms support the cancel dialog.
> 
> 
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Yes
> 
> 
> Flag name
> 
> BeforeunloadEventCancelByPreventDefault
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Estimated milestones
> 
> 112
> 
> 
> 
> Anticipated spec changes
> 
> There are no open spec issue and the spec already says that calling
> preventDefault() on beforeunload event should show the cancel dialog.
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://chromestatus.com/feature/4968823574233088
> 
> 
> This intent message was generated by Chrome Platform Status
> .
> 
> -- 
> 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/CA%2BSS7eAfjeL8MZfTuVDGZR5Lg%3DPquwoUeF91fNJqV1vs%3DHsKZQ%40mail.gmail.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/d0b0743d-b484-f7e6-4d84-5e4960bfddb5%40igalia.com.

Re: [blink-dev] Intent to Deprecate: non-standard `shadowroot` attribute for declarative shadow DOM

[Manuel Rego Casasnovas]

Hi Mason,

Are we planning to use deprecation reports (reporting API) for this
deprecation?

As a side note, I've realized we don't mention that at
https://www.chromium.org/blink/launching-features/#feature-deprecations
We only mention:
"At this point, you should also notify developers by adding a
deprecation console message, pointing to the updated status entry in the
console message."
Should we update that?

Cheers,
  Rego

On 21/02/2023 22:36, Mason Freed wrote:
> 
> 
> On Sun, Feb 19, 2023 at 11:33 PM Yoav Weiss  > wrote:
> 
> That uptick may suggest a single large entity that started using
> this, and may be easy to move to the new attribute.
> Have you tried turning the usecounter into a UKM
> 
> 
>  to try and see where the usage is coming from?
> 
> 
> Agreed, that uptick is likely a single party. My hope is that it will go
> back down as that entity moves to the new attribute. Adding a UKM sounds
> like a reasonable idea - I'll do that if I don't see a down-trend in the
> usecounter data soon.
>  
> 
> The other alternative is that some developer documentation is
> pointing at the old attribute name. Can you verify that's not the case?
> 
> 
> Indeed that's very likely. Our own blog post
>  still describes the old
> attribute. (I'm working on getting that updated.)
>  
> 
> Otherwise, we typically prefer to have deprecation messages with
> clear milestones for their removal date. It seems to me that a year
> may be a lot for this. Would you be comfortable with setting the
> removal date for 6 milestones ahead? Maybe the UKM analysis can
> change our thinking here?
> 
> 
> I'm reasonably comfortable with targeting 6 milestones out. That'd be
> roughly M118 as the last version that supports the old `shadowroot`
> attribute, and M119 as the first that doesn't. And closer to the
> deadline we can re-evaluate usage and make sure it's low enough for
> comfort. Does that sound reasonable? If so, I'll update the
> documentation and console messages accordingly.
> 
> Thanks,
> Mason
> 
>  
> 
> 
> On Fri, Feb 17, 2023 at 6:38 PM Mason Freed  > wrote:
> 
> 
> On Thu, Feb 16, 2023 at 5:19 PM Jason Robbins
> mailto:jrobb...@google.com>> wrote:
> 
> On Wednesday, February 15, 2023 at 10:14:48 PM UTC-8
> yoav...@chromium.org  wrote:
> +Jason Robbins - FYI, this didn't make it to the
> chromestatus tool.
> 
> I have an idea about what went wrong.
> 
> "Intent to deprecate" is the subject line that is expected
> for the first stage in the deprecation process.  It was
> detected as such, but that stage does not require any
> review.    Based on this thread and the contents of the
> feature entry it looks like the final stage was what needed
> to be reviewed.
> 
> 
> Sorry - this was my fault. The stages of deprecation are kind of
> different, and the two options I had for this "deprecation" (not
> "removal") were "Draft Ready for Trial email" and "Draft Intent
> to Ship email". I chose the latter and renamed the subject line
> to "Intent to Deprecate". I hadn't realized we had tooling look
> at these emails. I guess the right thing was to choose the
> "Ready for Trial" email template, and not change the subject
> line. Perhaps a suggestion would be to rename those links or add
> help text explaining which one is appropriate at each stage for
> a deprecation/removal intent?
> 
> Thanks,
> Mason
>  
> 
> The final stage detects an intent email with the subject
> line "Intent to ship" or "Intent to remove".  The
> launching-features page uses "Intent to ship" for the final
> stage of a deprecation, and when we generate the email
> preview we use that subject line, but I'm guessing that it
> sounded wrong so Mason edited it.  
> 
> It would probably be better if chromestatus generated a
> preview with the subject line "Intent to remove" and we
> updated launching-features to use that wording too.  I am
> tracking the issue here:
> https://github.com/GoogleChrome/chromium-dashboard/issues/2749 
> 
> 
> Thanks,
> jason!
> 
>  
> 
> -- 
> 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
> 

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[Manuel Rego Casasnovas]

On 21/02/2023 10:06, 'Munira Tursunova' via blink-dev wrote:
>> Is there a way to feature detect the synthesis functionality or not? How
>> a web author will be able to differentiate between Gecko vs
>> Chromium/WebKit behaviors? Would the lack of this feature confuse
>> authors? Maybe having some console message information when
>> font-variant-position doesn't have any effect due to missing synthesis
>> functionality, dunno if that makes sense.
>> 
>> Do we have an use counter for the cases where we're not using
>> synthesized glyphs due to lack of functionality? So we can track how
>> common that situation is and understand the priority of such feature in
>> the future.
>  
> I’m not sure I completely understand your question, but I suppose
> identifying cases when the feature is requested and the font does not
> have subscript/superscript glyphs might not be possible since we perform
> the checking of the font features in the shaping stage in Harfbuzz and
> we check different fonts in the shaping process without knowing what
> font will be finally used in the page. So, for example, we can trigger
> on some system font that does not have sub/superscript glyphs (so this
> glyphs should be synthesised) however, in the end, this font won’t be
> used in the page but a different web font will be used instead.  
> 
> One of the ways to detect whether a font has super/subscript glyphs is
> to check whether the font with the feature has loaded (using
> document.fonts for instance) and if it did then we won’t synthesise.

Mmmm, I'm not sure if I'm understanding properly.
In the first email you wrote:
> Currently font-variant-position is implemented without synthesis
functionality and affects only fonts that have superscript or subscript
glyphs (“sups”/”subs” opentype feature); i.e. if the font doesn’t have
superscript/subscript then setting font-variant-position to
“super”/“sub” won’t synthesize superscript and subscript glyphs,
therefore won’t change anything.

I understood that if the font has super/subscript glyphs we'll use them,
but if the font doesn't have them, we won't synthesize them, so the user
will see no difference between a text with `font-variant-position:
normal;` vs `font-variant-position: super;`. Am I getting this wrong?

If I'm right, my question was how to feature detect if the browser is
synthesizing things or not. For example we have this:
  x2

In Firefox that will always look as "x²". In Chromium/WebKit I
understand that depending on the font it'll look as "x²" or "x2".
Is there any way the author can detect what's going on so they can use a
different method to do the superscript here?
Isn't this going to be confusing to web authors why this is not working
in Chromium, while working in Firefox? Are they going to be able to
understand this is because the selected font doesn't have the proper
glyphs (even when it's the same font in Firefox)?

I was wondering about this kind of things, but I'm not sure if I
understood properly the original message.

Cheers,
  Rego

>> I'm curious how this relates to the "old" way of doing superscript. If
> I understand correctly (and I might not!), then x style="font-variant-position: super">2 will render as "x²",
> somehow finding > the "super" variant of 2 in the font? The old way of
> doing this would be with x2 which will use the normal glyph for 2, but smaller and
> differently > positioned?
> 
> Not exactly, vertical-align always does synthesis, so even if the font
> has subscript or superscript opentype features vertical-align would
> still synthesize the glyphs. The old way of activation
> superscript/subscript is through font-feature-settings, i.e. setting it
> to “sups” or ”subs”.  
> 
> On Wednesday, February 15, 2023 at 6:08:20 PM UTC+1 Daniel Bratell wrote:
> 
> I'm curious how this relates to the "old" way of doing superscript.
> 
> If I understand correctly (and I might not!), then
> 
> x2
> 
> will render as "x²", somehow finding the "super" variant of 2 in the
> font?
> 
> The old way of doing this would be with
> 
> x2
> 
> which will use the normal glyph for 2, but smaller and differently
> positioned?
> 
> /Daniel
> 
> On 2023-02-14 22:26, Manuel Rego Casasnovas wrote:
> > Is there a way to feature detect the synthesis functionality or
> not? How
> > a web author will be able to differentiate between Gecko vs
> > Chromium/WebKit behaviors? Would the lack of this feature confuse
> > authors? Maybe having some console message information when
> > font-variant-position doesn't have any effect due to missing
>

Re: [blink-dev] Intent to Ship: WebAssembly Tail Call

[Manuel Rego Casasnovas]

LGTM3

On 15/02/2023 18:16, Yoav Weiss wrote:
> LGTM2
> 
> On Wed, Feb 15, 2023 at 6:10 PM Chris Harrelson  > wrote:
> 
> LGTM1
> 
> On Wed, Feb 15, 2023 at 8:09 AM 'Thibaud Michaud' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> 
> 
> /Web developers/: No signals
> 
> 
> Have you tried to gather signals? Are there developers
> involved in the WASM process? (if so, the phase can count as
> a signal for them as well).
> 
>  
> Maybe Leaning Tech qualifies: they develop an x86 virtualization
> technology using wasm. They have written publicly about their
> use case for tail calls (here
> 
> ,
>  here  and here 
> ), 
> and unblocked the move to phase 4 by implementing it in WebKit (here 
> ).
> 
> 
> /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?
> 
> 
> I'm guessing the answer here is "no"?
> 
>  
> Indeed. 
> 
> -- 
> 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/CALowwNYfhC78Juo%3DBg%2Bp8OD77A4%3Dha7nU%2BCcXFe58R%3DX%2BmrUHA%40mail.gmail.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/CAL5BFfXXb6vc70PVuAfCe5adMxsRy0OPGrqBX8gqrun5iD8KvQ%40mail.gmail.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/518ec509-e51e-c25d-49bf-1597a6d67708%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[Manuel Rego Casasnovas]

Is there a way to feature detect the synthesis functionality or not? How
a web author will be able to differentiate between Gecko vs
Chromium/WebKit behaviors? Would the lack of this feature confuse
authors? Maybe having some console message information when
font-variant-position doesn't have any effect due to missing synthesis
functionality, dunno if that makes sense.

Do we have an use counter for the cases where we're not using
synthesized glyphs due to lack of functionality? So we can track how
common is that situation and understand the priority of such feature in
the future.

Cheers,
  Rego

On 14/02/2023 17:08, Philip Jägenstedt wrote:
> I will recuse myself from this one since I have an interest in the
> success of Interop 2022 (and 2023), but I think shipping this makes
> sense. Chrome is the last browser to not support it at all, and we've
> seen with other features that the time it becomes available in all
> browsers can be an inflection point in usage.
> 
> On Tue, Feb 14, 2023 at 4:56 PM 'Munira Tursunova' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> 
> Contact emails
> 
> moon...@google.com , dr...@google.com
> 
> 
> 
> Explainer
> 
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position 
> 
> 
> 
> Specification
> 
> https://drafts.csswg.org/css-fonts-4/#propdef-font-variant-position
> 
> 
> 
> Summary
> 
> The font-variant-position CSS property controls the use of
> alternate, smaller glyphs that are positioned as superscript or
> subscript.
> 
> 
> Motivation
> 
> Font-variant-position property allows users to control usage of
> typographic superscript and subscript glyphs. 
> 
> Currently font-variant-position is implemented without synthesis
> functionality and affects only fonts that have superscript or
> subscript glyphs (“sups”/”subs” opentype feature); i.e. if the font
> doesn’t have superscript/subscript then setting
> font-variant-position to “super”/“sub” won’t synthesize superscript
> and subscript glyphs, therefore won’t change anything.
> 
> Subscript and superscript glyphs can be also activated using the
> font-feature-settings property, however using font-variant-position
> property might be more reasonable since it cascades like a regular
> CSS property and with the font-feature-settings, if the element
> inherits the “sups” or “subs” value, users need to
> activate/deactivate other features that were also defined in
> font-feature-settings of the parent element. 
> 
> Implementing the synthesis part would be complex and it is
> questionable if it is worth the cost since synthesized glyphs may
> look unnatural and synthesis of the font-variant-position property
> is at risk in the spec
> 
> .
>  Also Safari supports font-variant-position property without synthesis 
> functionality as well.
> 
> This feature is implemented behind the ‘experimental’ flag and is
> part of Interop 2022. Shipping this feature will provide a higher
> stable score for Interop and will decrease the stable vs.
> experimental score difference.Since Chrome is the last browser to
> ship this, this will enable broader usage of the feature on the web.
> 
> 
> Blink component
> 
> Blink>Fonts
> 
> 
> 
> 
> Search tags
> 
> font-variant-position
> ,
> subscript glyphs
> ,
> superscript glyphs
> , sub
> , super
> 
> 
> 
> TAG review
> 
> Already shipped in other browsers, see below, no TAG review required.
> 
> 
> TAG review status
> 
> Not applicable, existing standard, shipped in other UAs
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> 
> Gecko: Shipped/Shipping
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1024804
> Gecko has
> implemented the feature with the synthesis functionality.
> 
> 
> WebKit: Shipped/Shipping
> 
> https://bugs.webkit.org/show_bug.cgi?id=148413
> WebKit has
> implemented the feature without the synthesis functionality.
> 
> 
> Web developers: No signals

Re: [blink-dev] Intent to Ship: WebGPU

[Manuel Rego Casasnovas]

Thanks for the detailed explanation.

Cheers,
  Rego

On 08/02/2023 05:24, Kai Ninomiya wrote:
> There is no active plan to export or migrate the WebGPU CTS into WPT.
> It's something we'd theoretically like to do in the long run, but there
> are a lot of blockers:
> 
> - If we just export without moving it, then browser-to-wpt auto-export
> will not be usable, so I would want to move it.
> - TypeScript meaningfully enables our test development and we would not
> want to strip it from the code, so we would want to somehow support that
> inside WPT. (We actually had an idea involving running babel in a
> service worker that could make this work now, but it's something we
> wouldn't want to do just for WebGPU.)
> - Each browser's wpt-to-browser auto-import will need to run the WebGPU
> tests on all hardware/software configurations used on that browser's CQ
> equivalent, and be able to collect the test results and update
> expectations files automatically. Without this, auto-imports will
> frequently be unable to import without breaking the build.
> - Chromium doesn't actually run most of the WebGPU CTS through
> WPT/web_tests anymore - only reftests still use web_tests. For numerous
> reasons, it was more practical to run under Chromium's GPU integration
> test framework. Other browsers are integrating the tests in whatever way
> is most practical for them (for example WebKit can't run it under their
> WPT runner using the WPT "variants" feature - they need it split up into
> files or somehow baked into the WPT manifest).
>     - The test tree is very large and deep and test runtimes are highly
> variable, we needed a heartbeat mechanism for timeouts, which WPT does
> not have.
>     - We needed expectations
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/webgpu-cts/expectations.txt>
>  to depend on the GPU hardware and various configurations of Chromium's 
> graphics and WebGPU stack, which we already had in that framework.
>     - It uses the real browser instead of content_shell: tests what we
> ship, and we also had difficult-to-debug flakiness somehow relating to
> GPU initialization in content_shell.
> 
> -Kai (he/they)
> 
> 
> On Tue, Feb 7, 2023 at 5:28 AM Corentin Wallez  <mailto:cwal...@chromium.org>> wrote:
> 
> Hey Rego,
> 
> The WebGPU CTS is meant to be exportable into a WPT subdirectory,
> see https://github.com/gpuweb/cts/blob/main/docs/build.md
> <https://github.com/gpuweb/cts/blob/main/docs/build.md>. However I
> don't know that there's a specific plan to integrate into WPT proper
> since development uses a lot of combination testing and Typescript,
> which is not something WPT support (the export step creates
> individual HTML pages for each test case and compiles the Typescript
> to Javascript). +Kai Ninomiya <mailto:kain...@chromium.org>, feel
> free to correct me if I missed something.
> 
> Cheers,
> 
> Corentin
> 
> On Mon, Feb 6, 2023 at 5:55 PM Manuel Rego Casasnovas
> mailto:r...@igalia.com>> wrote:
> 
> 
> 
> On 14/12/2022 18:02, Corentin Wallez wrote:
> > The WebGPU Conformance Test Suite is being built
> > at https://github.com/gpuweb/cts
> <https://github.com/gpuweb/cts> <https://github.com/gpuweb/cts
> <https://github.com/gpuweb/cts>> and can
> > be integrated as a subdirectory of WPT. Coverage is still
> incomplete due
> > to the complexity of the API but progressing quickly. We
> expect to ship
> > with coverage holes, but with most important and risky aspects of
> > interoperability well tested.
> 
> Any plans about integrating the test suite into WPT?
> 
> Thanks,
>   Rego
> 
> -- 
> 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
> <mailto:blink-dev+unsubscr...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyD6G97bLgnCFRpqMCmkXhtkpkV9rP7wk2ByoiGgMznoSw%40mail.gmail.com
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyD6G97bLgnCFRpqMCmkXhtkpkV9rP7wk2ByoiGgMznoSw%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 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/8875118c-ff89-037f-643e-7d8d79bfeae9%40igalia.com.

Re: [blink-dev] Intent to Ship: WebGPU

[Manuel Rego Casasnovas]

On 14/12/2022 18:02, Corentin Wallez wrote:
> The WebGPU Conformance Test Suite is being built
> at https://github.com/gpuweb/cts  and can
> be integrated as a subdirectory of WPT. Coverage is still incomplete due
> to the complexity of the API but progressing quickly. We expect to ship
> with coverage holes, but with most important and risky aspects of
> interoperability well tested.

Any plans about integrating the test suite into WPT?

Thanks,
  Rego

-- 
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/b475d88c-0535-6b6c-6d92-a2c29305840a%40igalia.com.

Re: [blink-dev] Intent to Ship: RegExp v flag with set notation + properties of strings

[Manuel Rego Casasnovas]

LGTM3

On 26/01/2023 10:12, Yoav Weiss wrote:
> LGTM2
> 
> On Wed, Jan 25, 2023 at 5:55 PM Chris Harrelson  > wrote:
> 
> LGTM1
> 
> On Wed, Jan 25, 2023 at 7:52 AM 'Patrick Thier' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> 
> Contact emails
> 
> pth...@chromium.org
> , math...@chromium.org
> 
> 
> 
> Explainer
> 
> https://github.com/tc39/proposal-regexp-v-flag
> 
> https://v8.dev/features/regexp-v-flag
> 
> 
> 
> Specification
> 
> https://github.com/tc39/proposal-regexp-v-flag
> 
> 
> 
> Summary
> 
> Add set operations, string literals, nested classes and unicode
> properties of strings to regular expression character classes.
> Set operations and unicode properties of strings allow
> developers to create regular expressions matching strings with
> certain unicode characters with ease. E.g.
> /[\p{Script_Extensions=Greek}&&\p{Letter}]/v matches all greek
> letters.
> 
> 
> 
> Blink component
> 
> Blink>JavaScript>Regexp
> 
> 
> 
> 
> TAG review
> 
> 
> 
> TAG review status
> 
> Not applicable
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> Covered by TC39 process:
> https://github.com/tc39/proposal-regexp-v-flag
> 
> 
> 
> 
> /Gecko/: Positive
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1713657
> ) Assumed
> positive because this proposal is Stage 3 in TC39.
> 
> /WebKit/: Positive
> (https://bugs.webkit.org/show_bug.cgi?id=241593
> ) Assumed
> positive because this proposal is Stage 3 in TC39.
> 
> /Web developers/: No signals
> 
> /Other signals/:
> 
> 
> Activation
> 
> The new features are gated behind a new regular expression flag
> (/v). See
> 
> https://github.com/tc39/proposal-regexp-v-flag#is-the-new-syntax-backwards-compatible-do-we-need-another-regular-expression-flag
>  
> 
> 
> 
> 
> 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?
> 
> 
> 
> Debuggability
> 
> Uses existing debugging support for regular expressions. No
> additions required.
> 
> 
> 
> Will this feature be supported on all six Blink
> platforms (Windows, Mac, Linux, Chrome OS, Android, and
> Android WebView)?
> 
> Yes
> 
> The feature is enabled for all platforms when compiled with
> internalization support.
> 
> 
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Covered by test262:
> 
> https://github.com/tc39/test262/tree/main/test/built-ins/RegExp/unicodeSets/generated
>  
> 
> 
> 
> Flag name
> 
> --harmony-regexp-unicode-sets
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Non-OSS dependencies
> 
> Does the feature depend on any code or APIs outside the Chromium
> open source repository and its open-source dependencies to function?
> 
> no
> 
> 
> Sample links
> 
> 
> https://v8.dev/features/regexp-v-flag
> 
> 
> 
> Estimated milestones
> 
> DevTrial on desktop   110
> 
> DevTrial on Android   110
> 
> 
> Planned to ship in M112
> 
> 
> 
> Anticipated spec changes
> 
> Open questions about a feature may be a source of future web
> compat or interop issues. Please list open issues (e.g. links to
> known github issues in the project for the feature
> specification) whose resolution may introduce web compat/interop
> risk (e.g., changing to naming or structure of the API in a
> 

Re: [blink-dev] Intent to Ship: CSS Nesting

[Manuel Rego Casasnovas]

Adding to Philip questions, there seems to be quite a lot of ongoing
discussions around this topic on the CSSWG, for example today there's a
special meeting only for CSS Nesting topics:
https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html

What's their impact on the current implementation?

Thanks,
  Rego

On 23/01/2023 18:00, Philip Jägenstedt wrote:
> I think that we should ship this. It's a high profile and in-demand new
> feature
> , so
> I have a few questions and comments first.
> 
> Taking a look at the open spec issues
> (https://github.com/w3c/csswg-drafts/labels/css-nesting-1
> ) some are
> explicitly ideas for future changes, but are there any where shipping
> amounts to a decision that isn't easily changed? I'm thinking especially
> of the CSSOM issues.
> 
> In https://wpt.fyi/results/css/css-nesting
>  there's a single subtest
> failure, related to how a rule serializes. Is that implemented per spec,
> or is it tied up with the open CSSOM issues?
> 
> Regarding the threat of a formal objection, there doesn't appear to be
> any solution that would fully satisfy everyone, but I trust your
> judgment that this is the best option. Additionally, we should not
> pre-commit Blink to shipping parser changes, and accept the possibility
> that what we ship now is the final shape of the feature.
> 
> On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> Contact emails: se...@chromium.org ,
> futh...@chromium.org 
> Explainer: None
> 
> Specification: https://drafts.csswg.org/css-nesting
> 
> 
> Summary: Add the ability to nest CSS style rules inside other style
> rules,
> combining selectors from the outer with the inner rule for increasing
> modularity and maintainability of style sheets.
> 
> Blink component: Blink>CSS
> 
> TAG review: https://github.com/w3ctag/design-reviews/issues/791
> 
> 
> TAG review status: Pending
> 
> Risks: There is a threat of a formal objection in CSSWG.
> 
> Interoperability and Compatibility:
> 
> Gecko: Positive
> (https://github.com/mozilla/standards-positions/issues/695
> )
> WebKit: Positive
> (https://github.com/WebKit/standards-positions/issues/69
> )
> 
> Debuggability
> Nesting style rules will be a big change for editing and displaying
> style rules in the inspector:
> 
> - Showing displaying nested rules for matching declarations
> - Editing selectors
> - Inserting nested rules
> - etc...
> 
> Tracking issue for devtools support: https://crbug.com/1172985
> 
> Devtools says they're on track for shipping in M111.
> 
> 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
> 
> Flag name: CSSNesting
> 
> Requires code in //chrome? False
> 
> Tracking bug: https://crbug.com/1095675 
> 
> Estimated milestones
> DevTrial on desktop     109
> DevTrial on Android     109
> Shipping                112
> 
> 
> Anticipated spec changes: See above.
> 
> Link to entry on the Chrome Platform Status:
> https://chromestatus.com/feature/5800613594529792
> 
> 
> Links to previous Intent discussions:
> Intent to prototype:
> 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com
>  
> 
> 
> -- 
> Software Engineer, Google Norway
> 
> -- 
> 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/Y8ph9gk50U2D92f3%40google.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
> 

Re: [blink-dev] Intent to Ship: Style Container Queries for CSS Custom Properties

[Manuel Rego Casasnovas]

LGTM3

On 19/12/2022 14:57, Rune Lillesveen wrote:
> On Fri, Dec 16, 2022 at 9:11 PM Rick Byers  > wrote:
> 
> LGTM1
> 
> For other reviewers, I verified these tests are all passing 100%
> (thank you Rune!):
> 
> https://wpt.fyi/css/css-contain/container-queries/custom-property-style-queries.html
>  
> 
>  
> https://wpt.fyi/css/css-contain/container-queries/custom-property-style-query-change.html
>  
> 
>  https://wpt.fyi/css/css-contain/container-queries/at-container-parsing.html 
>  
> https://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
>  
> 
> 
> 
> Thanks, I did add the tests to "Web Platform Tests Description:", but
> the generated e-mail does not include that field. I've reported
> https://github.com/GoogleChrome/chromium-dashboard/issues/2591
> 
> 
> 
> On Fri, Dec 16, 2022 at 5:13 AM Rune Lillesveen
> mailto:futh...@chromium.org>> wrote:
> 
> 
> Contact emails
> 
> futh...@chromium.org 
> 
> 
> Explainer
> 
> https://css.oddbird.net/rwd/style/explainer
> 
> 
> 
> Specification
> 
> https://drafts.csswg.org/css-contain-3/#style-container
> 
> 
> 
> Summary
> 
> Adds a style() function to @container rules to make it possible
> to apply styles based on the computed values of custom
> properties of an ancestor element. style() queries can be
> combined with size container queries which shipped in M105.
> 
> 
> 
> Blink component
> 
> Blink>CSS
> 
> 
> 
> 
> TAG review
> 
> https://github.com/w3ctag/design-reviews/issues/787
> 
> 
> 
> TAG review status
> 
> Pending
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> None of the other vendors have responded to the
> standards-positions or, to my knowledge, started implementing.
> There were concerns raised by an Apple engineer in
> https://github.com/w3c/csswg-drafts/issues/7185
>  mainly for
> standard property queries. This intent is for shipping support
> for custom property queries only.
> 
> 
> 
> /Gecko/: No signal
> (https://github.com/mozilla/standards-positions/issues/686
> )
> 
> /WebKit/: No signal
> (https://github.com/WebKit/standards-positions/issues/57
> )
> 
> /Web developers/: No signals
> 
> /Other signals/:
> 
> 
> Activation
> 
> Feature detection is not very ergonomic before we add at-prelude
> testing to @supports, which requires a resolution for [1]. [1]
> https://github.com/w3c/csswg-drafts/issues/6966
> 
> 
> 
> 
> 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?
> 
> 
> 
> Debuggability
> 
> DevTools may need to show style containers like it is done with
> size container queries today. However, all elements are style
> containers by default, so probably not the same type of UI.
> There is an issue where we look up the wrong container, that is,
> always assume that the closest container supporting logical
> inline axis queries is the closest one:
> https://crbug.com/1378237  If we fix
> that issue, we will automatically also implement correct
> container lookup for pure style containers. That should work
> both for highlighting elements querying a given container, and
> also list the query for the matched style rule correctly.
> 
> 
> 
> Will this feature be supported on all six Blink
> platforms (Windows, Mac, Linux, Chrome OS, Android, and
> Android WebView)?
> 
> Yes
> 
> 
> Is 

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Manuel Rego Casasnovas]

If we have plans to fix issues on this feature later, why not fixing
them before and then shipping when things look good?

If we unprefix it, it'll kind of appear as a new Chromium feature that
people can use, and they will expect it follows the spec. But we'll have
to document it just works for this specific syntax but not this other
and things like that, which would be hard to document and explain. Then
as bugs are fixed more syntax will be supported, how are we going to
announce that?

Checking the tests results in wpt.fyi:
https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=chrome%5Bexperimental%5D=chrome%5Bstable%5D=firefox%5Bexperimental%5D=safari%5Bexperimental%5D=subtest

I'm confused about the first examples there:
* e.style['background-image'] = "image-set(url(example.png) 1x)"
  is passing
But:
* e.style['background-image'] = "-webkit-image-set(url(example.png) 1x)"
should set the property value
  is not passing

The first test is failing in without the runtime flag, and is passing
with it. I'm not sure I'm understanding what we're shipping exactly, as
I understood it was the same syntax than then prefixed version.

Cheers,
  Rego

On 08/12/2022 03:47, Traian Captan wrote:
> Hi Rego,
>  
> 
> I do wonder what's the goal of removing the prefix, if we're not also
> improving the spec compliance and interoperability?
> 
> It's an incremental step in the direction of spec compliance and
> interoperability.
> Further improvements will follow.
> This is similar to how Firefox handled the implementation, splitting it
> over several patches and releases
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1107646
> ).
> 
> If we ship "image-set" people would expect it's a complete feature, and
> then they'll get confused when somethings don't work. How are we going
> to explain which is shipping exactly, is there any kind of documentation
> about that?
> 
> I would expect that if they find something that doesn't work, they would
> open bug / feature requests, which we can use to prioritize what we
> should look at implementing next.
> 
> Regards,
> Traian
> 
> -- 
> 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/CAFxahvsO-axM0xi_E1bKQHk0_KgorSsJCQKmdA4EM_axOgm5hg%40mail.gmail.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/cf00b332-6a63-9dd4-ed85-a91f8a0f2089%40igalia.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Manuel Rego Casasnovas]

On 07/12/2022 12:37, Yoav Weiss wrote:
> LGTM1
> 
> Thanks for working on this!! Looking at wpt.fyi, other implementations
> are passing the test suite for this to varying degrees. Does this intent
> cover full compliance with the test suite? (e.g. `type()`, `url()`, non
> `x` descriptors, and maybe other dimensions) Or does it only cover the
> unprefixing and further interop improvements will come later?

I do wonder what's the goal of removing the prefix, if we're not also
improving the spec compliance and interoperability?

If we ship "image-set" people would expect it's a complete feature, and
then they'll get confused when somethings don't work. How are we going
to explain which is shipping exactly, is there any kind of documentation
about that?

Cheers,
  Rego

> 
> On Tuesday, December 6, 2022 at 3:23:32 AM UTC+1 Traian Captan wrote:
> 
> 
> Contact emails
> 
> tcap...@chromium.org 
> 
> 
> Explainer
> 
> None
> 
> 
> Specification
> 
> https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation
> 
> 
> 
> Summary
> 
> Unprefix -webkit-image-set to expose the current image-set
> functionality without needing the '-webkit-' prefix.
> 
> 
> 
> Blink component
> 
> Blink
> 
> 
> 
> 
> Motivation
> 
> Currently Blink only supports '-webkit-' prefixed image-set, while
> Gecko and WebKit support both prefixed and unprefixed versions. With
> this change interop with Gecko and WebKit will be increased by
> allowing web developers to use the current Blink image-set
> functionality both with and without the '-webkit-' prefix.
> 
> 
> Search tags
> 
> image-set 
> 
> 
> TAG review
> 
> Skipping because this is a straightforward interop fix.
> 
> 
> TAG review status
> 
> Not applicable
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> The Interoperability Risk is Low. This change increases interop with
> Gecko and WebKit which already support both '-webkit-' prefixed and
> unprefixed image-set. The Compatibility Risk is Low. If both
> prefixed and standard versions are defined in the right order, and
> the standard version fails parsing, Blink will fallback to the
> prefixed version. The 'image-set-fallback' test has been added to
> verify this behavior.
> 
> 
> 
> /Gecko/: Shipped/Shipping
> (https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2
> )
> 
> /WebKit/: Shipped/Shipping
> (https://trac.webkit.org/changeset/202765/webkit
> )
> 
> /Web developers/: Strongly positive - This issue has been Starred by
> 55 users.
> 
> /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
> 
> N/A
> 
> 
> 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/results/css/css-images/image-set
> 
> 
> 
> Flag name
> 
> CSSImageSet
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Tracking bug
> 
> https://crbug.com/630597 
> 
> 
> Estimated milestones
> 
> 110 Or 111
> 
> 
> 
> Anticipated spec changes
> 
> Open questions about a feature may be a source of future web compat
> or interop issues. Please list open issues (e.g. links to known
> github issues in the project for the feature specification) whose
> resolution may introduce web compat/interop risk (e.g., changing to
> naming or structure of the API in a non-backward-compatible way).
> 
> None
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://chromestatus.com/feature/5109745420075008
> 
> 
> This intent message was generated by Chrome Platform Status
> .
> 
> -- 
> 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 

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Manuel Rego Casasnovas]

Given the answer, I agree with Yoav that it'd be better to forget about
this thread and start a new one when things are ready to ship.

Thanks,
  Rego

On 02/12/2022 22:09, Traian Captan wrote:
> Hi Rego,
> 
> Thank you for your message!
> 
> > This issue has been bugging devs since 2016.
> >
> > I'm landing a patch
> > <https://chromium-review.googlesource.com/c/chromium/src/+/4063134
> <https://chromium-review.googlesource.com/c/chromium/src/+/4063134>> to
> > unprefix -webkit-image-set which will expose the current image-set
> > functionality without needing the '-webkit-' prefix.
> I don't think this is the right way to move this topic. 3 LGTMs from
> 2016 shouldn't be enough to land the change without a previous notice on
> this thread. 
> 
> Sorry about that, it was meant more as an FYI on the old thread since
> there was no follow up after the LGTMs and the issue is still open.
> I will create a new Chrome status entry and send out a brand new email
> about it.
> 
>  
> 
> > To address the compat issue, if both prefixed and standard versions are
> > defined in the right order,
> > and the standard version fails parsing, Chrome will fallback to the
> > prefixed version.
> > The `image-set-fallback` test has been added to verify this behavior.
> > Unprefixing image-set fixes 2 of the failing subtests of the
> > image-set-parsing WPT test 
> > 
> <https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=experimental=subtest=image-set-parsing
>  
> <https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=experimental=subtest=image-set-parsing>>
> >
> > As a follow up, I will investigate whether we can fix the remaining
> > compat issues.
> 
> How is the interop with WebKit and Firefox implementations?
> According to MDN Firefox added support for -webkit-image-set() in
> version 90, so it'd be nice that this change is in alignment too.
> 
> WebKit and Firefox support both prefixed and unprefixed versions.
> I am not removing the prefixed version, only adding the possibility of
> using the current functionality without needing the `-webkit-` prefix.
> 
>  
> 
> What's the status of WPT tests? Why only 2 subtests are getting fixed
> with this change? Are there plans to fix the rest?
> 
> For the image-set-parsing test, Firefox is passing 46/50, Safari 37/50
> and Chrome 20/50 (22 with my patch).
> For the overall WPT tests for image-set
> <https://wpt.fyi/results/css/css-images/image-set?label=master=experimental=subtest=image-set>,
>  Firefox is passing 71/77, Safari 50/77 and Chrome 23/77 (25 with my patch).
> We only pass 2 more tests because we are only exposing the current
> implemented functionality not adding any new functionality with this patch.
> I will follow up with additional fixes for some of the other issues.
>  
> 
> Do we have use counters for both the prefixed and uprefixed versions to
> see if we can get rid of them in the future?
> 
> Yes, we have counters for both, but I don't think we can get rid of the
> prefixed version, as there were talks about adding the prefixed version
> to the spec: https://github.com/w3c/csswg-drafts/issues/6285
> <https://github.com/w3c/csswg-drafts/issues/6285>
> 
> I guess we should also update things at:
> https://chromestatus.com/feature/5432024223449088
> <https://chromestatus.com/feature/5432024223449088>
> 
> I'll send a brand new one.
>  
> 
> And probably notify MDN so it can get updated if the prefix is no longer
> needed in any browser.
> 
> Good idea.
> 
> Regards,
> Traian
> 
> 
> On Wed, Nov 30, 2022 at 11:57 PM Manuel Rego Casasnovas  <mailto:r...@igalia.com>> wrote:
> 
> Hi,
> 
> On 01/12/2022 00:59, Traian Captan wrote:
> > This issue has been bugging devs since 2016.
> >
> > I'm landing a patch
> > <https://chromium-review.googlesource.com/c/chromium/src/+/4063134
> <https://chromium-review.googlesource.com/c/chromium/src/+/4063134>> to
> > unprefix -webkit-image-set which will expose the current image-set
> > functionality without needing the '-webkit-' prefix.
> I don't think this is the right way to move this topic. 3 LGTMs from
> 2016 shouldn't be enough to land the change without a previous notice on
> this thread.
> 
> > To address the compat issue, if both prefixed and standard
> versions are
> > defined in the right order,
> > and the sta

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Manuel Rego Casasnovas]

Hi,

On 01/12/2022 00:59, Traian Captan wrote:
> This issue has been bugging devs since 2016.
> 
> I'm landing a patch
>  to
> unprefix -webkit-image-set which will expose the current image-set
> functionality without needing the '-webkit-' prefix.
I don't think this is the right way to move this topic. 3 LGTMs from
2016 shouldn't be enough to land the change without a previous notice on
this thread.

> To address the compat issue, if both prefixed and standard versions are
> defined in the right order,
> and the standard version fails parsing, Chrome will fallback to the
> prefixed version.
> The `image-set-fallback` test has been added to verify this behavior.
> Unprefixing image-set fixes 2 of the failing subtests of the
> image-set-parsing WPT test 
> 
> 
> As a follow up, I will investigate whether we can fix the remaining
> compat issues.

How is the interop with WebKit and Firefox implementations?
According to MDN Firefox added support for -webkit-image-set() in
version 90, so it'd be nice that this change is in alignment too.

What's the status of WPT tests? Why only 2 subtests are getting fixed
with this change? Are there plans to fix the rest?

Do we have use counters for both the prefixed and uprefixed versions to
see if we can get rid of them in the future?

I guess we should also update things at:
https://chromestatus.com/feature/5432024223449088

And probably notify MDN so it can get updated if the prefix is no longer
needed in any browser.

Cheers,
  Rego

> 
> Regards,
> Traian
> 
> On Tuesday, August 30, 2016 at 8:51:03 AM UTC-7 dgla...@google.com wrote:
> 
> LGTM3 + investigate the syntax issue mentioned by PhistucK.
> 
> :DG<
> 
> 
> On Monday, August 29, 2016 at 5:06:06 PM UTC-7, Dru Knox wrote:
> 
> Is this blocked on API owner feedback?
> 
> On Mon, Aug 15, 2016 at 1:47 AM PhistucK  wrote:
> 
> It has come to my attention in comment 5
>  
> that the standard syntax is a superset of the Blink syntax.
> https://drafts.csswg.org/css-images-3/#image-set-notation
> 
> 
> Blink supports -
> background-image: image-set( url("foo.png") 1x,
>                              url("foo-2x.png") 2x,
>                              url("foo-print.png") 3x );
> 
> The standard supports this -
> background-image: image-set( "foo.png" 1x,
>                              url("foo-2x.png") 2x,
>                              "foo-print.png" 600dpi );
> Basically, you do not need url("..."), you can enter it as a
> string without the url() function. Also, the resolution part
> supports more than just #x.
> 
> I do not have Safari, but according to the unprefixing
> layout test, it looks like it does not support the standard
> syntax as well.
> 
> Should the standard syntax be dropped? Can you talk to
> WebKit and see if they intend to implement the standard syntax?
> 
> 
> ☆*PhistucK*
> 
> On Fri, Aug 12, 2016 at 11:47 PM, Chris Harrelson
>  wrote:
> 
> LGTM2
> 
> On Fri, Aug 12, 2016 at 1:11 PM, Philip Jägenstedt
>  wrote:
> 
> Easy LGTM1. Given that authors generally assume that
> prefixed things are aliases and that WebKit has made
> it just so, whatever problems there might be with
> image-set, the only way to move forward is to
> consider -webkit-image-set as part of the compat
> constraint and navigate accordingly.
> 
> When it comes to tests, I guess this (like almost
> all) feature doesn't have a shared test suite that
> we actually use? Nothing
> in 
> https://github.com/w3c/csswg-test/tree/master/css-images-3 
>  and I don't know 
> where else it would be?
> 
> I suspect that contributing to csswg-tests is, like
> web-platform-tests, not streamlined enough to
> require it for shipping new things, but it would be
> great if you wanted to take a look at how feasible
> it is in this case. Even just a few reftests testing
> the very basics would be valuable.
> 
> Finally, I wouldn't assume that compat risk is low.
> When things (like 

Re: [blink-dev] Intent to Ship: Expose Reporting API interfaces to JavaScript

[Manuel Rego Casasnovas]

WebKit has been doing some work implementing the Reporting API:
https://bugs.webkit.org/show_bug.cgi?id=189365

Do we know their plans regarding this topic? Should we ask for signals?

Cheers,
  Rego

On 25/11/2022 15:39, Rick Byers wrote:
> On Fri, Nov 25, 2022 at 9:27 AM Ian Clelland  > wrote:
> 
> 
> 
> On Fri, Nov 25, 2022 at 1:54 AM Domenic Denicola
> mailto:dome...@chromium.org>> wrote:
> 
> 
> 
> On Fri, Nov 25, 2022, 14:53 Yoav Weiss  > wrote:
> 
> 
> On Fri, Nov 25, 2022 at 5:50 AM Domenic Denicola
> mailto:dome...@chromium.org>> wrote:
> 
> Note that in the past I've suggested these not be
> interfaces at
> all: https://github.com/w3c/reporting/issues/216
>  . As far
> as I can tell that issue is still open, and it would
> have been better to resolve it by making everything use
> dictionaries (or even just non-dictionary objects, like
> several specs do today) instead of creating new
> interfaces against proposed W3C TAG Design Principles
> .
> 
> 
> Thanks Domenic. Turning those into dictionaries does sound
> appealing. Let's wait to hear what Ian says.
>  
> 
> 
> Also that there is no spec for several of these
> interfaces (at least CoopAccessViolationReportBody,
> possibly others). So I think there's considerable
> interop risk.
> 
> 
> That interop risk is orthogonal to whether we expose those
> interfaces or not, right? Not saying it shouldn't be fixed,
> just that the risk exists already.
> 
> 
> I don't think it's orthogonal. Once the interfaces are exposed,
> they're much easier to depend on the existence of, and given
> that there is no spec for their shape or behavior, such
> dependence seems like an Interop risk.
> 
> 
> Most of these are spec'd:
> Report: https://w3c.github.io/reporting/#ref-for-dom-report
> 
> ReportBody: https://w3c.github.io/reporting/#reportbody
> 
> CSPViolationReportBody: 
> https://www.w3.org/TR/CSP3/#cspviolationreportbody 
> 
> DeprecationReportBody: 
> https://wicg.github.io/deprecation-reporting/#deprecationreportbody 
> 
> InterventionReportBody: 
> https://wicg.github.io/intervention-reporting/#interventionreportbody 
> 
> 
> CoopAccessViolationReportBody and DocumentPolicyViolationReportBody
> are not. CrashReportBody *is*, though not usefully, as it's not
> observable.
> 
> 
> We definitely shouldn't be exposing interface objects that aren't
> spec'd.  Thanks for catching this Domenic.
> 
> I'm definitely not against turning these into WebIDL dictionaries,
> as they don't actually have any behaviour - they're just a
> collection of named data. They were originally defined as
> interfaces, I believe, in order to spec the constraints on the names
> and types of their data members. Using plain objects at the time
> would have made that more difficult. As I understand it, WebIDL
> dictionaries do not expose any symbols on the global namespace, so
> that would remove the compatibility concern.
> 
> I'd like the API Owners to reconsider their LGTMs in
> light of these unresolved discussions. At the very
> least, I think at TAG review is warranted for this, as
> there are architectural implications here. But fixing
> the spec situation would be even better.
> 
> 
> I'll revert the change for now, and take a pass at changing the
> specs involved.
> 
> Thanks for weighing in, Domenic!
> 
> 
> Saying this intent is on hold
> until https://github.com/w3c/reporting/issues/216
>  is resolved one way or the
> other makes sense to me. Let's take the design debate there. I have some
> additional questions / concerns but blink-dev isn't the right forum for
> API design discussions.
>  
> 
> On Thursday, November 24, 2022 at 3:01:12 PM UTC+9 Yoav
> Weiss wrote:
> 
> LGTM3
> 
> On Wed, Nov 23, 2022 at 11:28 PM Chris Harrelson
>  > wrote:
> 
> LGTM2 
> 
> On Wed, 

Re: [blink-dev] Intent to Ship: Anonymous iframes

[Manuel Rego Casasnovas]

Hi,

A few questions, is there any plan to move the spec code into HTML or
other relevant specs? Do we have PRs for that?

There's another feature called "Fenced frames"
(https://chromestatus.com/feature/5699388062040064) that is currently
being worked on. Wouldn't be nice to explain how anonymous iframes vs
fencedrames are? And if they interact in some way or not? Would
fencedrames need an anonymous attribute at some point? Maybe we could
add some of this information into the explainer.

About the explainer, the one used in the TAG review is:
https://github.com/camillelamy/explainers/blob/main/anonymous_iframes.md
But now it seems to be integrated into the spec
https://wicg.github.io/anonymous-iframe/ which is not very common. Also
the explainer usually includes the problem, alternatives discussed and
the like, and now they're like separated sections in the spec. Maybe
some reformatting could be useful.

I guess it'd be also nice to ensure we have proper documentation about
this, "anonymous" attribute is not mentioned at MDN:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe

Cheers,
  Rego

On 01/11/2022 16:54, Rick Byers wrote:
> [Removing internal-only chrome-security-owp-team list]
> 
> Sorry, one more question: the tests seem to be mostly failing on wpt.fyi
> 
>  even with --enable-experimental-web-platform-features. Do you know why that 
> is? What's the status of the test suite?
> 
> On Tue, Nov 1, 2022 at 11:29 AM Rick Byers  > wrote:
> 
> Reading through the discussion on the Mozilla standards position
> thread  I
> share the concern about the continued increase in complexity we're
> adding to the web platform with all these different security /
> isolation knobs. I will be the first to admit that I don't
> understand them all and have to keep looking up documentation to
> recover a partial understanding. But looking at the feedback from
> real users and seeing how folks are still relying on the SAB reverse
> OT
> 
> ,
>  I don't see any better option, and it certainly seems the team here has done 
> their homework and is investing seriously in pragmatic measures to ease 
> adoption of origin-level isolation (which is pretty clearly the right 
> long-term architecture for the web). As is so often the case on the web, I 
> think we have to take a step to the adjacent pragmatic option and trust that 
> it'll lead to opportunities to simplify in the future as the ecosystem slowly 
> updates. Also, since this feature is built on top of existing storage 
> isolation primitives and is most useful for a small number of special cases 
> like ad networks, it doesn't seem to me like it adds that much new complexity 
> to the platform architecture.
> 
> I assume that at least one of the major customers (eg. Zoom, Google
> Display Ads, StackBlitz) has tried the OT and is satisfied with it's
> behavior and so is prepared to ramp up wide scale usage, is that
> right? Assuming so, then I think the benefit to shipping now
> outweighs the remaining interop risk and I trust the team to
> continue iterating in good faith in the standards community. LGTM1
> to ship.
> 
> Rick
> 
> 
> On Fri, Oct 28, 2022 at 4:20 PM 'Arthur Sonzogni' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> 
> Contact emails
> 
> arthursonzo...@chromium.org
> , cl...@chromium.org
> 
> 
> 
> Explainer
> 
> https://github.com/WICG/anonymous-iframe
> 
> 
> 
> Specification
> 
> https://wicg.github.io/anonymous-iframe/#specification
> 
> 
> 
> Design docs
> 
> 
> https://docs.google.com/document/d/1poI75BaQ9aqcMGJn_K01-QHsQQbEOwRWvg3Af4VWTmY/edit
>  
> 
> 
> 
> Summary
> 
> Anonymous iframes give developers a way to load documents in
> third party iframes using new and ephemeral contexts.
> 
> 
> Anonymous iframes are a generalization of COEP credentialless to
> support 3rd party iframes that may not deploy COEP. Like with
> COEP credentialless, we replace the opt-in of cross-origin
> subresources by avoiding to load non-public resources. This will
> remove the constraint that 3rd party iframes must support COEP
> in order to be embedded in a COEP page and unblock developers
> looking to adopt cross-origin-isolation.
> 
> 

Re: [blink-dev] Intent to Remove: -webkit-perspective-origin-[x,y]

[Manuel Rego Casasnovas]

Do we know how bad is the breakage in some of the pages that are hitting 
the new use counter?


On 28/10/2022 09:33, Anders Hartvoll Ruud wrote:



On Fri, Oct 28, 2022 at 2:04 AM Mike Taylor <mailto:miketa...@chromium.org>> wrote:


On 10/27/22 5:41 AM, Anders Hartvoll Ruud wrote:

On Thu, Oct 27, 2022 at 11:27 AM Manuel Rego Casasnovas
mailto:r...@igalia.com>> wrote:

What's the status in other browsers?

  * WebKit does not support it (anymore).


Could you point to a commit or a bug? I've only been able to find
https://bugs.webkit.org/show_bug.cgi?id=240271
<https://bugs.webkit.org/show_bug.cgi?id=240271>, which suggests
that the prefixed variants do exist (and devtools will autocomplete
them in the latest Safari Tech Preview 156).

I went to double-check, and found that /it is/ still supported. My first 
test was invalid, my mistake.


Could we file a bug or a signals request to see what's the plan from 
Apple regarding these?


Cheers,
  Rego



That said, I'm unaware of content that relies on these two
properties (cf.
https://compat.spec.whatwg.org/#propdef--webkit-perspective-origin
<https://compat.spec.whatwg.org/#propdef--webkit-perspective-origin>).

thanks,
Mike


--
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 
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUoo3Xv0iv3L9rX8BJ69TukS_eRkBsjWvhm1Yjd7d053eA%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUoo3Xv0iv3L9rX8BJ69TukS_eRkBsjWvhm1Yjd7d053eA%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 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/f6799f5b-711f-31a9-be0e-56683a8245ef%40igalia.com.

Re: [blink-dev] Intent to Remove: -webkit-perspective-origin-[x,y]

[Manuel Rego Casasnovas]

On 27/10/2022 11:11, Anders Hartvoll Ruud wrote:

Gecko: No signal


WebKit: No signal


What's the status in other browsers?

Cheers,
  Rego

--
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/108be604-0065-3ebc-e911-45588e63e9f3%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS 'lh' Length Unit

[Manuel Rego Casasnovas]

LGTM1

On 17/10/2022 15:52, Rune Lillesveen wrote:
> Asking for both lh and rlh:
> 
> https://github.com/WebKit/standards-positions/issues/75
> 
> https://github.com/mozilla/standards-positions/issues/699
> 

WebKit has shipped this and Firefox is positive.

Thanks for filling these.

Cheers,
  Rego

-- 
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/1e2caa8e-0871-23ec-4aa8-1612a8328064%40igalia.com.

Re: [blink-dev] Intent to Prototype: CSS Initial Letters

[Manuel Rego Casasnovas]

On 14/10/2022 18:03, Ian Kilpatrick wrote:
> 
> There are also a few CSSWG issues open, are them important? Should we
> try to resolve them before shipping?
> 
> 
> We haven't done an extensive review of the issues yet - but we didn't
> see too many that are concerning. A lot of the open issues are for
> additional features on top of the basic initial-letter support. Are
> there any issues which you feel are concerning at the moment?

This is an intent to prototype, so I guess it's not urgent or anything.
But if there are open issues and some could be closed as part of this
work, it'd be nice.

Cheers,
  Rego

-- 
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/0c6c4841-c254-bee7-aefe-0e0ae97aa6c4%40igalia.com.

Re: [blink-dev] Intent to Prototype: CSS Initial Letters

[Manuel Rego Casasnovas]

On 13/10/2022 06:39, Yoshifumi Inoue wrote:
> /Gecko/: Working  https://bugs.webkit.org/show_bug.cgi?id=136484
> 

Wrong link, this is a WebKit bug.

If the link is https://bugzilla.mozilla.org/show_bug.cgi?id=1223880 it
doesn't seem they are working working on it.
> /WebKit/: Shipped. "initial-letter" and "-webkit-initial-letter" properties

It looks it only shipped the prefixed version:
https://bugs.webkit.org/show_bug.cgi?id=229090

How is the interop between Blink and WebKit implenetations?
For example from a quick test of the MDN page, WebKit doesn't support
decimal values.

There are also a few CSSWG issues open, are them important? Should we
try to resolve them before shipping?

Cheers,
  Rego

-- 
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/139de614-bffe-e6a7-ba86-ff96c6c32e3d%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS 'lh' Length Unit

[Manuel Rego Casasnovas]

On 13/10/2022 16:10, Rune Lillesveen wrote:
> Summary
> 
> Support for expressing CSS lengths relative to the line-height


Is this only about "lh"? What about "rlh"?

> /Gecko/: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1310170
> )

Should we ask for official signals at
https://mozilla.github.io/standards-positions/ ? (Adding Emilio in CC
maybe he can share some thoughts).

> /WebKit/: In development (https://bugs.webkit.org/show_bug.cgi?id=195180
> ) Implemented behind a flag

WebKit implemented this in 2020 but it hasn't been shipped yet because
of bug: https://bugs.webkit.org/show_bug.cgi?id=211351
Have we asked about plans regarding that?
Is that bug an issue in Blink implementation?

There's also one open issue in the CSSWG:
https://github.com/w3c/csswg-drafts/issues/937
It seems something was agreed long time ago, but nothing was reflected o
the spec. I guess it'd be nice to clarify the status and if that implies
any change on the implementation before shipping.

Cheers,
  Rego

-- 
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/ccc75ad0-1dc5-4d41-46a8-53861b7c5fc7%40igalia.com.

Re: [blink-dev] Intent to Ship: MathML

[Manuel Rego Casasnovas]

On 14/10/2022 07:53, Frédéric Wang wrote:
> If I understand correctly [3], it is integrated in M108 (branched
> yesterday) and the feature freeze for M109 will be October 27. So we
> have two weeks to decide to enable MathML or not (if an issue with
> LayoutNGPrinting is detected) [4].

I believe "feature freeze" on that page is related to Chromium itself,
things like UI features and browser features. But not related to Blink
features, they sometimes get shipped just before the branch point, and
after the feature freeze date.

So we have some extra time to check if LayoutNGPrinting gets some
trouble or not. And if it sticks we could enable MathML too (maybe
adding a base feature [*] in case it needs to be disabled later).

Cheers,
  Rego

[*]
https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#generate-a-instance-from-a-blink-feature

-- 
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/ae4de693-d4fd-27bc-06d9-b71e4f9e3348%40igalia.com.

Re: [blink-dev] Re: Intent to Ship: CSS Values and Units Module Level 4: Small/Large/Dynamic/Logical viewport units

[Manuel Rego Casasnovas]

LGTM3

On 27/09/2022 08:34, Yoav Weiss wrote:
> LGTM2
> 
> Yay for interop!!
> 
> On Tue, Sep 27, 2022 at 8:09 AM Mike West  > wrote:
> 
> LGTM1.
> 
> It's great to see us following along with WebKit and Gecko's
> implementations of these viewport units. The coverage in WPT looks
> reasonably solid
> 
> (https://wpt.fyi/results/css/css-values?label=master=experimental=chrome=firefox=safari=interop=label%3Ainterop-2022-viewport
>  
> ),
>  and developer need is clearly demonstrated. Thanks for getting this out the 
> door!
> 
> -mike
> 
> On Monday, September 26, 2022 at 12:41:28 PM UTC+2 Anders Hartvoll
> Ruud wrote:
> 
> 
> Contact emails
> 
> andr...@chromium.org 
> 
> 
> Explainer
> 
> 
> https://github.com/w3ctag/design-reviews/issues/706#issuecomment-108242 
> 
> 
> https://www.bram.us/2021/07/08/the-large-small-and-dynamic-viewports/ 
> 
> 
> 
> Specification
> 
> https://drafts.csswg.org/css-values-4/#viewport-relative-lengths
> 
> 
> 
> Summary
> 
> Support for sv* units, lv* units, dv* units and the logical
> vi/vb units.
> 
> 
> Blink component
> 
> Blink>CSS
> 
> 
> 
> 
> Motivation
> 
> Mobile browsers today typically have UI elements which
> dynamically hide themselves when the user scrolls the page (e.g.
> the top URL bar on Android). This presents a challenge to
> authors wishing to size and position something relative to “the
> viewport”, since there can be multiple definitions of “the
> viewport” depending on the state of these dynamic UI elements.
> 
> 
> The new viewport units allow authors to size/position elements
> according to the viewport appropriate for their use-case:
> 
> 
>   *
> 
> Small: the viewport as it would be with dynamic UI fully
> expanded.
> 
>   *
> 
> Large: the viewport as it would be with dynamic UI fully
> contracted.
> 
>   *
> 
> Dynamic: the viewport as it is according to the current
> state of the dynamic UI.
> 
> 
> The new viewport units are also part of Interop 2022
> .
> 
> 
> TAG review
> 
> https://github.com/w3ctag/design-reviews/issues/706
> 
> 
> 
> TAG review status
> 
> Closed with no issues.
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> 
>   *
> 
> The viewport units are sized relative to the initial
> containing block
> 
> , and 
> different browsers resize the initial containing block in different 
> situations. In particular, opening/closing the virtual keyboardwill resize 
> the ICB in Chrome for Android and Firefox for Android, but not in Safari for 
> iOS nor in Chrome for ChromeOS.
> See also Intent to Ship: Android OSK resizes visual viewport
> by default +  opt-out
> 
> .
> 
> 
> Gecko: Shipped/Shipping
> (https://www.mozilla.org/en-US/firefox/101.0/releasenotes/
> )
> 
> 
> WebKit: Shipped/Shipping
> (https://webkit.org/blog/12669/new-webkit-features-in-safari-15-5 
> )
> 
> 
> Web developers: “Difficulties dealing with viewport sizing are
> prominent in both the MDN Browser Compatibility Report 2020 and
> the new State of CSS 2021 survey.” [1]
> 
> 
> 
> Other signals:
> 
> 
> WebView application risks
> 
> N/A
> 
> 
> 
> Debuggability
> 
> No special DevTools support is needed.
> 
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Everything that can be tested with 

Re: [blink-dev] Re: Intent to Ship: Variable COLRv1

[Manuel Rego Casasnovas]

LGTM3

On 09/09/2022 07:02, Mike Taylor wrote:

LGTM2

On Thursday, September 8, 2022 at 9:42:54 AM UTC-4 dr...@google.com wrote:

Hi Yoav,

On Thursday, September 8, 2022 at 4:35:58 PM UTC+3
yoav...@chromium.org  wrote:

OK, so sounds like there's urgency here, or at least we need to
coordinate shipping.

LGTM1 to ship in the same release as `tech()`.


Thanks!

Does that mean that if we'd want to ship a future enhancement to
colrv1, we'd need to give it its own tech() signifier? e.g.
"colrv1-foobar"?


Yes, either that or call an update to the format COLRv2 for example.
We have some requests for functionality as additoins to COLRv1, such
as mesh gradients,  blur filters (for shadows) and such, but none of
that is spec'ed as of today.

Dominik



On Monday, September 5, 2022 at 4:36:01 PM UTC+2 Dominik
Röttsches wrote:


Contact emails

dr...@chromium.org



Explainer


https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md#changes-to-off-5711---color-table
 



Specification


https://docs.microsoft.com/en-us/typography/opentype/otspec191alpha/colr 



Summary

COLRv1 color vector fonts have been previously
released in Chrome 98
https://developer.chrome.com/blog/colrv1-fonts/

but this release supported only static functionality
of the COLRv1 table. (Previous I2S

).


The COLRv1 specification defined integration with
OpenType Variations


 from the beginning. This allows modifying the color elements of a font, parameters of 
gradients and transforms by means of changing font variable axis parameters. This I2S here 
is for bringing implementation support and adding variations to COLRv1 in Blink (see demo 
video , or demo links below)


Blink component

Blink>Fonts




Search tags

colrv1
,
variations
,
variable fonts
, color 
, emoji 
, gradients 



TAG review

The COLRv1 specification is developed outside of
W3C, slated for inclusion in OpenType and ISO/MPEG
Open Font Format. Before the previous I2S

, 
I started a thread on blink-api-owners-discuss asking whether TAG review for such a font 
format would be needed. This discussion concluded that a TAG review is not required (thread 
).


TAG review status

Not applicable


Risks



Interoperability and Compatibility

I see an interoperability risk mainly by not
shipping variable COLRv1 support. Here's why:


Firefox is already in the process of shipping COLRv1
support (#1740530)
, and 
their initial release will immediately include COLRv1 variations support.


In the past few weeks, I've worked closely with
Jonathan Kew from the Mozilla side to ensure
interoperability of the resulting variable COLRv1
glyph renderings. To that end, I developed an
extensive variable 

Re: [blink-dev] Intent to Prototype & Ship: Client Hints persistency in Android WebView

[Manuel Rego Casasnovas]

LGTM3

On 09/08/2022 19:51, Daniel Bratell wrote:
> LGTM2
> 
> /Daniel
> 
> On 2022-08-09 19:43, Torne (Richard Coles) wrote:
>> On Tue, 9 Aug 2022 at 04:24, Mike West  wrote:
>>
>> LGTM1 to extend this already-approved feature to WebView.
>>
>> Presumably you'll be chatting with WebView experts about any
>> implications this might have for the API WebView exposed to
>> embedding apps?
>>
>>
>> Yes, we've discussed this. Clearing all cookies through the existing
>> WebView API will also clear persisted client hints, and that seems
>> sufficient for now. The WebView API doesn't have very effective ways
>> to manage most kinds of stored data (either in general or for specific
>> sites), so adding more specific ways to deal with this doesn't seem
>> worthwhile.
>>
>> -mike
>>
>>
>> On Wed, Aug 3, 2022 at 8:45 PM Ari Chivukula
>>  wrote:
>>
>> Contact emails
>>
>> aric...@chromium.org ,
>> miketa...@chromium.org ,
>> yoavw...@chromium.org 
>>
>>
>> Specification
>>
>> https://wicg.github.io/client-hints-infrastructure/
>> 
>>
>>
>> Explainer
>>
>> When a page is loaded, the first response from an origin may
>> include a signal (in HTTP headers) for Client Hints to be
>> included in future requests to that origin. Without persisting
>> this signal, Client Hints cannot be included in the next
>> request to load a page from this Origin. Android WebView does
>> not currently persist this signal.
>>
>>
>> Design Doc
>>
>> 
>> https://docs.google.com/document/d/1r1AKHex1_UKh3wIp4ITkU4-J9-tdNZSOmUDeDVWw_AU/
>> 
>> 
>>
>>
>> Summary
>>
>> We aim to add support for persistent Client Hints to Android
>> Webview for parity with the rest of the platform. For more
>> details on the Client Hints system see:
>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints
>> 
>>
>>  
>>
>> Blink component
>>
>> Blink>Network>ClientHints
>> 
>> 
>>
>>  
>>
>> Motivation
>>
>> Without persisting the list of Client Hints a page requests
>> the initial load of a website will never include Client Hints,
>> only subresources on a given page can receive them. This
>> undermines the use of the Client Hints system which is to
>> empower websites to adapt content to the User Agent. We should
>> add persistence in the interest of parity with the behavior of
>> Chrome on Android so that WebView stays viable as a platform.
>>
>>
>> TAG review
>>
>> N/A (this change enables a feature that we already ship on
>> desktop and Android)
>>
>>
>> Compatibility
>>
>> This expands persistent Client Hints to a platform that was
>> missing it, no existing implementation will change. The
>> persisted Client Hints can be cleared by clearing the Cookies
>> for a given WebView, the same way that Client Hints are
>> cleared in Chrome for Android.
>>
>>  
>>
>>
>> Interoperability
>>
>> Other engines haven’t shipped Client Hints so this doesn’t
>> increase interoperability risk.
>>
>>  
>>
>> Gecko: Client Hints
>> and
>> User Agent Client Hints
>> considered
>> non-harmful
>>
>>  
>>
>> WebKit: Mildly positive support for User Agent Client Hints
>> 
>>
>>  
>>
>> Web developers: Vendor interest from Huawei
>> 
>> ,
>> interest from Cloudinary
>> in
>> User Agent Client Hints
>>
>>
>> Debuggability
>>
>> N/A (developers can use Chrome for Android to debug client
>> hint requests, though the values for user-agent related
>> strings will differ within the WebView context)
>>
>>
>> Is this feature fully tested by web-platform-tests?
>>
>> Android WebView is not a WPT platform, so this will only have
>> chrome 

Re: [blink-dev] Intent to Ship: ContentVisibilityAutoStateChanged event

[Manuel Rego Casasnovas]

On 08/08/2022 20:48, Vladimir Levin wrote:
> Explainer
> 
> https://github.com/vmpstr/web-proposals/blob/main/explainers/cv-auto-event.md
> 

Should we update the explainer to update on the a11y concerns raised at
https://github.com/w3c/csswg-drafts/issues/7384#issuecomment-1189938042

The explainer explicitly mentions:
"For example, the developer may want to stop React updates in a subtree
that is not rendered by the user-agent."

Which seems not a good idea according to the discussion linked above.

Cheers,
  Rego

-- 
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/93e41d83-a388-44f4-4456-77aeb87f3821%40igalia.com.

Re: [blink-dev] Intent to Ship: Unprefix -webkit-hyphenate-character CSS property

[Manuel Rego Casasnovas]

Thanks for the clarifications.

LGTM2

On 10/08/2022 04:44, Joonghun Park wrote:
> Thank you for your LGTM, Yoav.
> 
> And thank you for the corrections for interop section in the chrome
> status entry, Manuel.
> I revised the section as you commented.
> 
> 1. FF: changed the link
> to https://bugzilla.mozilla.org/show_bug.cgi?id=1751024
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1751024>
> 2. Safari: changed it to 'In development'. The WebKit bug was assigned
> to me, and I'm planning to unprefix the property for WebKit too via the bug.
> 3. Web Developers: changed it to 'No Signal', removing the unrelated link.
> 
> The unprefixing change for this I2S
> is https://chromium-review.googlesource.com/c/chromium/src/+/3812328
> <https://chromium-review.googlesource.com/c/chromium/src/+/3812328>,
> and there are no difference between unprefixed and prefixed one, because
> as you commented,
> the prefixed one is just an alias of the unprefixed one.
> 
> 2022년 8월 10일 (수) 오전 12:14, Manuel Rego Casasnovas  <mailto:r...@igalia.com>>님이 작성:
> 
> Just an extra clarification, would the prefixed version be just an alias
> of the unprefixed one, or are there any difference in behavior?
> 
> I've added some comments on the interop section inline.
> 
> On 09/08/2022 16:00, Joonghun Park wrote:
> > Yes, this will ship the unprefixed version, not dropping -webkit-
> > prefixed one too.
> >
> > 2022년 8월 9일 (화) 오후 9:20, Yoav Weiss  <mailto:yoavwe...@chromium.org>
> > <mailto:yoavwe...@chromium.org <mailto:yoavwe...@chromium.org>>>님
> 이 작성:
> >
> >     Just to make sure I understand, this would ship the unprefixed
> >     version, but will not unship the prefixed one, correct?
> >
> >     On Mon, Aug 8, 2022 at 4:18 PM Joonghun Park
> mailto:pjh0...@gmail.com>
> >     <mailto:pjh0...@gmail.com <mailto:pjh0...@gmail.com>>> wrote:
> >
> >                 Interoperability and Compatibility
> >
> >
> >
> >         /Gecko/: Shipped/Shipping
> >         (https://bugzilla.mozilla.org/show_bug.cgi?id=1746187
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1746187>
> >         <https://bugzilla.mozilla.org/show_bug.cgi?id=1746187
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1746187>>)
> 
> That's a link to the implementation, but it was shipped later in version
> 98: https://bugzilla.mozilla.org/show_bug.cgi?id=1751024
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1751024>
> 
> >         /WebKit/: Shipped/Shipping
> >         (https://bugs.webkit.org/show_bug.cgi?id=243670
> <https://bugs.webkit.org/show_bug.cgi?id=243670>
> >         <https://bugs.webkit.org/show_bug.cgi?id=243670
> <https://bugs.webkit.org/show_bug.cgi?id=243670>>)
> 
> This is just a bug report, so it's not shipping in WebKit. At least
> not yet.
> 
> >         /Web developers/: Positive
> >         (https://codepen.io/bramus/pen/XWegmqv
> <https://codepen.io/bramus/pen/XWegmqv>
> >         <https://codepen.io/bramus/pen/XWegmqv
> <https://codepen.io/bramus/pen/XWegmqv>>)
> 
> This is a page to check support, that's not something related to web
> developers position. The comments on Mozilla bug show why this is
> useful.
> 
> Cheers,
>   Rego
> 

-- 
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/57ef4a57-a3bb-a964-c01a-1336fba2e934%40igalia.com.

Re: [blink-dev] Intent to Ship: Unprefix -webkit-hyphenate-character CSS property

[Manuel Rego Casasnovas]

Just an extra clarification, would the prefixed version be just an alias
of the unprefixed one, or are there any difference in behavior?

I've added some comments on the interop section inline.

On 09/08/2022 16:00, Joonghun Park wrote:
> Yes, this will ship the unprefixed version, not dropping -webkit-
> prefixed one too.
> 
> 2022년 8월 9일 (화) 오후 9:20, Yoav Weiss  >님이 작성:
> 
> Just to make sure I understand, this would ship the unprefixed
> version, but will not unship the prefixed one, correct?
> 
> On Mon, Aug 8, 2022 at 4:18 PM Joonghun Park  > wrote:
> 
> Interoperability and Compatibility
> 
> 
> 
> /Gecko/: Shipped/Shipping
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1746187
> )

That's a link to the implementation, but it was shipped later in version
98: https://bugzilla.mozilla.org/show_bug.cgi?id=1751024

> /WebKit/: Shipped/Shipping
> (https://bugs.webkit.org/show_bug.cgi?id=243670
> )

This is just a bug report, so it's not shipping in WebKit. At least not yet.

> /Web developers/: Positive
> (https://codepen.io/bramus/pen/XWegmqv
> )

This is a page to check support, that's not something related to web
developers position. The comments on Mozilla bug show why this is useful.

Cheers,
  Rego

-- 
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/9e294ca1-67dc-1ed4-f0cc-5a34c083a2a5%40igalia.com.

Re: [blink-dev] Intent to Remove: window.webkitStorageInfo

[Manuel Rego Casasnovas]

LGTM3

On 03/08/2022 10:12, Yoav Weiss wrote:
> LGTM2 to remove!
> 
> On Wed, Aug 3, 2022 at 3:41 AM Mike Taylor  > wrote:
> 
> Hi Ayu,
> 
> Thanks for digging into usage! I'm encouraged by the fact that
> browserfs (even if not actively maintained) does do internal feature
> detection
> 
> ,
> and supports multiple storage API backends
>  in case a site does
> run into trouble.
> 
> LGTM1 to remove window.webkitStorageInfo
> 
> 
> On 8/2/22 6:20 PM, Ayu Ishii wrote:
>> Hi Daniel,
>>
>> Looking through websites I was able to observe from HTTPArchive,
>> here are some usage patterns I was able to see.
>> Most were used via js libraries listed below. Most usages check if
>> window.webkitStorageInfo exists before usage.
>> Thanks!
>>
>> window.webkitStorageInfo.requestQuota (163 total urls)
>>
>>  *
>>
>> 90 urls - browserfs 
>> - not actively worked on
>>
>>  *
>>
>> 38 urls - dojo  - old
>> version / checks if exists first
>>
>>  *
>>
>> 12 urls - mymonero js
>>  - old version /
>> checks if exists first
>>
>>  *
>>
>> 6 urls - sencha ext js
>>  - old version?
>>
>>  *
>>
>> 16 urls remain (8 checks if exists first)
>>
>>
>> window.webkitStorageInfo.queryUsageAndQuota (285 total urls)
>>
>>  *
>>
>> 237 urls - twitter share js (example
>> )
>> - checks if exists first
>>
>>  *
>>
>> 38 urls - dojo  - checks if exists first
>>
>>  *
>>
>> 2 urls - meteor.js  - checks if
>> exists first
>>
>>  *
>>
>> 8 urls remain (6 checks if exists first)
>>
>>
>> On Wednesday, July 27, 2022 at 8:19:45 AM UTC-7 Daniel Bratell wrote:
>>
>> The low usage counters indicate that this is something that
>> could relatively safely be removed, though I wonder if you
>> have taken a look at any of the sites listed with the usage
>> counter?
>>
>> /Daniel
>>
>> On 2022-07-26 23:26, Ayu Ishii wrote:
>>> *Contact emails
>>> *a...@chromium.org  
>>>
>>> *Specification
>>> *https://storage.spec.whatwg.org/
>>> 
>>>
>>> *Summary
>>> *We propose to remove the following prefixed quota API,
>>> window.webkitStorageInfo in M106.
>>>
>>>  *
>>>
>>> window.webkitStorageInfo.queryUsageAndQuota()
>>>
>>>  *
>>>
>>> window.webkitStorageInfo.requestQuota()
>>>
>>> The deprecation thread predates the Intent process, but has
>>> been marked as deprecated since 2013
>>> (https://bugs.webkit.org/show_bug.cgi?id=88396
>>> ).
>>>
>>> *Blink component
>>> *Blink>Storage>Quota
>>> 
>>> 
>>>
>>> *Motivation
>>> *Chrome proposed and implemented
>>>  the prefixed quota API
>>> in 2011, which was immediately succeeded by the Quota API
>>>  which has
>>> since been deprecated as well. The legacy storage quota API
>>> was never implemented by any other browser, and has been
>>> showing a deprecation warning since 2013. Rather than
>>> investing more support on these legacy APIs, we propose to
>>> remove it entirely.
>>>
>>> *Search tags
>>> *legacy ,
>>> quota , storage
>>> 
>>>
>>> *TAG review
>>> *N/A
>>>
>>> *Risks
>>> *We previously made an attempt to remove
>>> window.webkitStorageInfo in 2017 (I2D
>>> 
>>> ).
>>> Since then, the modern quota API navigator.storage.estimate()
>>> shows increased adoption while window.webkitStorageInfo usage
>>> has decreased.
>>>
>>> The top level use counter (PrefixedStorageInfo
>>> )
>>> still reports 0.6% of page loads, but we think this can’t be
>>> trusted since enumeration of 

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Manuel Rego Casasnovas]

On 28/07/2022 16:33, 'Matt Menke' via Chromium-dev wrote:
> The assumption is not that they're no longer good owners, but that
> people shouldn't have to spend a week waiting on them to reply to a
> review before giving up and trying someone else.  Note that owners do
> not need to be nominated - no one is losing their committer status.

Just for completeness, there are some OWNERS files that require a
nomination process. At least third_party/blink/renderer/core/OWNERS
requires that:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/OWNERS

Cheers,
  Rego

-- 
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/7f52c766-8692-b906-78c5-20d263f23b1f%40igalia.com.

Re: [blink-dev] Intent to Ship: Custom Highlight API

[Manuel Rego Casasnovas]

One comment about this feature and legacy layout.

It seems ::highlight customization is only supported in LayoutNG for
most properties (only background-color works in legacy).

I'm wondering if we should add some kind of console warning message,
like for Container Queries [*], so if people see some differences in
some cases they can know the reason why.


Another thing that I noticed is that highlight pseudos are not being
printed, I guess that was on purpose for things like ::selection or
::target-text, but should we allow printing ::highlight? Should we open
a spec issue about that so it's properly defined (I didn't find anything
on the specs regarding printing)?

I don't mean this is a blocker for shipping, but if this is not properly
defined, maybe it's time to clarify things regarding printing.

Cheers,
  Rego

[*] https://chromium-review.googlesource.com/c/chromium/src/+/3706582

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> 
> Contact emails
> 
> dan...@microsoft.com , sa...@microsoft.com
> , ffi...@microsoft.com
> , lusan...@microsoft.com
> , pc...@microsoft.com
> ,
> 
> 
> Explainer
> 
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/explainer.md
> 
> 
> 
> Specification
> 
> https://drafts.csswg.org/css-highlight-api-1/
> 
> 
> 
> Design docs
> 
> 
> https://docs.google.com/document/d/1vaWiPLA9opz0AObbObuRj3P5zqzoM2ldy0pHkZkJyxo
> 
> 
> 
> Summary
> 
> The custom highlight API provides a way for web developers to style the
> text of arbitrary ranges. This is useful in a variety of scenarios,
> including editing frameworks that wish to implement their own selection,
> find-on-page over virtualized documents, multiple selections to
> represent online collaboration, or spellchecking frameworks.
> 
> 
> Blink component
> 
> Blink>Editing
> 
> 
> 
> Search tags
> 
> Custom Highlight API
> , Highlight
> API 
> 
> 
> TAG review
> 
> https://github.com/w3ctag/design-reviews/issues/584
> 
> 
> 
> TAG review status
> 
> Issues addressed
> 
> 
> Risks
> 
> 
> Interoperability and Compatibility
> 
> Low risk: This feature received positive support from Safari and Firefox
> at TPAC 2019. Safari is implementing it, Firefox has not yet made any
> clear indication on implementation.
> 
> 
> 
> /Gecko/: No clear signal
> (https://github.com/mozilla/standards-positions/issues/482
> )
> 
> /WebKit/: Positive. WebKit implemented the feature behind an
> experimental flag in 99:
> https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API
> .
> 
> /Web developers/: Strongly positive
> (https://github.com/w3c/csswg-drafts/issues/4307
> ). Multiple use cases
> have been pointed out in this issue. CKEditor has also shown support
> from the first highlight API explainer.
> 
> /Other signals/:
> 
> 
> Ergonomics
> 
> Highlight API will be the first use case for constructible StaticRanges,
> which the API permits as an alternative to Iive Ranges because they do
> not incur cost during DOM mutations.
> 
> 
> 
> 
> Activation
> 
> No. Web developers should be able to use the feature as-is. It is also
> easy to feature detect (checking for the existence of CSS.highlights).
> 
> 
> 
> 
> WebView application risks
> 
> None.
> 
> 
> Debuggability
> 
> DevTools shows ::highlight pseudo elements in the style pane. This
> includes inherited pseudos per the highlight inheritance model
>  used by
> custom highlights.
> 
> 
> 
> 
> 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://github.com/web-platform-tests/wpt/tree/master/css/css-highlight-api
> 

Re: [blink-dev] Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

[Manuel Rego Casasnovas]

LGTM2

On 11/07/2022 16:43, Yoav Weiss wrote:
> LGTM1 given the thorough analysis and my understanding based on it that
> the use counter is likely to be over-counting actual breakage. Thanks
> for running it! :)
> 
> On Thu, Jul 7, 2022 at 8:50 PM David Baron  > wrote:
> 
> 
> 
> On Thu, Jul 7, 2022 at 10:36 AM David Baron  > wrote:
> 
> Most relevant to this intent is the case on http://www.elster.de
>  where default is used (which is the only
> actual site that I'm aware of this change affecting):  it is a
> use in the animation-name property.  The relevant chunk of CSS
> is the following (with newlines added):
> 
> body{animation-name:default;animation-duration:1ms;content:'default'}
> @media screen and
> (min-width:20rem),print{body{animation-name:min;content:'min'}}
> @media screen and
> (min-width:30rem),print{body{animation-name:xs;content:'xs'}}
> @media screen and
> (min-width:48rem),print{body{animation-name:small;content:'small'}}
> @media screen and
> 
> (min-width:60rem),print{body{animation-name:content;content:'content'}}
> @media screen and
> (min-width:60rem),print{body{animation-name:medium;content:'medium'}}
> @media screen and
> (min-width:80rem),print{body{animation-name:large;content:'large'}}
> @media screen and
> (min-width:105rem),print{body{animation-name:xl;content:'xl'}}
> @media screen and
> (min-width:120rem),print{body{animation-name:max;content:'max(a,
> b)'}}
> @keyframes
> 
> default{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> 
> min{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> xs{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> 
> small{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> 
> content{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> 
> medium{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> 
> large{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> xl{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> 
> max{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> 
> This is rather a lot of CSS to apply the clip property to body
> for the first 1ms of the page's existence.  I'm not sure why
> it's there, but maybe it's a workaround for something.  In any
> case, this change would cause this chunk of CSS to no longer do
> whatever it does (which is likely not very much) for pages whose
> width is less than 20rem.
> 
> elster.de  has had
>  a
> bunch of webcompat issues with Firefox, but none of the ones in
> that list seem related to this issue.
> 
> 
> And one further point about www.elster.de 
> that I had forgotten about:  the clip property only applies to
> absolutely positioned elements, which their body element is not.  So
> whether or not default is valid as a custom-ident, the above CSS
> should be 18 lines of no-op.
> 
> -David
> 
> -- 
> 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/CAL5BFfUoDE6%3D8rZoC40022HAavqcEziTjTn8cO4vczWR1yGz3g%40mail.gmail.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/01aabf33-c19b-268a-2acb-fa1d7ffda983%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS :modal Pseudo Class

[Manuel Rego Casasnovas]

LGTM2 too with Philip's requests.

On 29/06/2022 17:48, Philip Jägenstedt wrote:
> LGTM1 to ship this with the latest spec changes applied, and WPT
> written and passing for that.
> 
> On Wed, Jun 29, 2022 at 5:27 PM Manuel Rego Casasnovas  
> wrote:
>>
>> Does Chromium implementation match the spec resolution, so :modal
>> applies to fullscreen too?
>>
>> Are there tests checking that?
>>
>> Cheers,
>>   Rego
>>
>> On 27/06/2022 15:20, Jihwan Kim wrote:
>>> I have updated the I2S contents including explainer, vendor signals
>>> those are commented.
>>> We may now progress this I2S.
>>> thanks.
>>>
>>> 2022년 6월 24일 금요일 오전 4시 2분 49초 UTC+9에 Chris Harrelson님이 작성:
>>>
>>> The CSSWG just resolved yesterday that :modal should apply to
>>> fullscreen, and that fullscreen should be modal. So I think this
>>> intent is unblocked.
>>>
>>> On Wed, Jun 8, 2022 at 4:50 PM Jihwan Kim  wrote:
>>>
>>> Thanks for Chris Harrelson.
>>> Once "should fullscreen be modal?" is resolved, I'll keep
>>> progress this.
>>> thanks.
>>>
>>> 2022년 6월 9일 목요일 오전 3시 0분 58초 UTC+9에 Chris Harrelson
>>> 님이 작성:
>>>
>>> I've also added "should fullscreen be modal?" to the CSSWG
>>> agenda. Once that is resolved this intent is ready to ship,
>>> in my view.
>>>
>>> On Wed, Jun 8, 2022 at 10:59 AM Chris Harrelson
>>>  wrote:
>>>
>>>
>>> On Tue, May 31, 2022 at 1:21 AM Arthur Sonzogni
>>>  wrote:
>>>
>>> Hello,
>>> It would be nice if there was some repository or
>>> documents were we could fill some security/privacy
>>> questions. I will do it here instead.
>>> How does this interacts with iframes? Do you know
>>> where it might be defined in the spec? I remember
>>> for the modal dialog, there was some "inertness"
>>> attribute propagated toward parent/iframes. It was
>>> shown it can be used to leak cross-site data, or it
>>> can be used to create new communication channel. It
>>> was found and fixed here: https://crbug.com/1293191
>>> <https://crbug.com/1293191>. I guess the two
>>> features relies on the same mechanism and Chrome
>>> might immune as result. Anyway, could you please
>>> make sure the behavior is specified and show how it
>>> doesn't create a cross-site leak?
>>>
>>>
>>> You are correct that the same mechanism
>>> prevented cross-site information leaks for "both". In
>>> other words, thet modal dialog feature doesn't
>>> propagate, due to the fix for issue 1293191.
>>>
>>> :modal is a pseudoclass state that only changes style
>>> for a  element in the same document as the style
>>> sheet using :modal. Therefore a cross-origin iframe
>>> won't be able to change its document's state based on
>>> :modal. So I don't see a way that this feature will
>>> introduce new security or privacy issues. Let me know if
>>> this doesn't fully answer your questions.
>>>
>>>
>>> Filling
>>> the https://w3ctag.github.io/security-questionnaire/
>>> <https://w3ctag.github.io/security-questionnaire/> is 
>>> often
>>> helpful as well ;-)
>>>
>>> On Thursday, May 26, 2022 at 6:51:19 PM UTC+2 Mike
>>> Taylor wrote:
>>>
>>> On 5/26/22 9:35 AM, Mike Taylor wrote:
>>>> On 5/26/22 2:42 AM, Jihwan Kim wrote:
>>>>>
>>>>> 4. Gecko vendor signal : I set gecko's signal
>>>>> to 'Shipped/Shipping' as the
>>>>>

Re: [blink-dev] Intent to Ship: CSS :modal Pseudo Class

[Manuel Rego Casasnovas]

Does Chromium implementation match the spec resolution, so :modal
applies to fullscreen too?

Are there tests checking that?

Cheers,
  Rego

On 27/06/2022 15:20, Jihwan Kim wrote:
> I have updated the I2S contents including explainer, vendor signals
> those are commented.
> We may now progress this I2S.
> thanks.
> 
> 2022년 6월 24일 금요일 오전 4시 2분 49초 UTC+9에 Chris Harrelson님이 작성:
> 
> The CSSWG just resolved yesterday that :modal should apply to
> fullscreen, and that fullscreen should be modal. So I think this
> intent is unblocked.
> 
> On Wed, Jun 8, 2022 at 4:50 PM Jihwan Kim  wrote:
> 
> Thanks for Chris Harrelson.
> Once "should fullscreen be modal?" is resolved, I'll keep
> progress this.
> thanks.
> 
> 2022년 6월 9일 목요일 오전 3시 0분 58초 UTC+9에 Chris Harrelson
> 님이 작성:
> 
> I've also added "should fullscreen be modal?" to the CSSWG
> agenda. Once that is resolved this intent is ready to ship,
> in my view.
> 
> On Wed, Jun 8, 2022 at 10:59 AM Chris Harrelson
>  wrote:
> 
> 
> On Tue, May 31, 2022 at 1:21 AM Arthur Sonzogni
>  wrote:
> 
> Hello,
> It would be nice if there was some repository or
> documents were we could fill some security/privacy
> questions. I will do it here instead.
> How does this interacts with iframes? Do you know
> where it might be defined in the spec? I remember
> for the modal dialog, there was some "inertness"
> attribute propagated toward parent/iframes. It was
> shown it can be used to leak cross-site data, or it
> can be used to create new communication channel. It
> was found and fixed here: https://crbug.com/1293191
> . I guess the two
> features relies on the same mechanism and Chrome
> might immune as result. Anyway, could you please
> make sure the behavior is specified and show how it
> doesn't create a cross-site leak?
> 
> 
> You are correct that the same mechanism
> prevented cross-site information leaks for "both". In
> other words, thet modal dialog feature doesn't
> propagate, due to the fix for issue 1293191.
> 
> :modal is a pseudoclass state that only changes style
> for a  element in the same document as the style
> sheet using :modal. Therefore a cross-origin iframe
> won't be able to change its document's state based on
> :modal. So I don't see a way that this feature will
> introduce new security or privacy issues. Let me know if
> this doesn't fully answer your questions.
>  
> 
> Filling
> the https://w3ctag.github.io/security-questionnaire/
>  is 
> often
> helpful as well ;-)
> 
> On Thursday, May 26, 2022 at 6:51:19 PM UTC+2 Mike
> Taylor wrote:
> 
> On 5/26/22 9:35 AM, Mike Taylor wrote:
>> On 5/26/22 2:42 AM, Jihwan Kim wrote:
>>>
>>> 4. Gecko vendor signal : I set gecko's signal
>>> to 'Shipped/Shipping' as the
>>> doc(bit.ly/blink-signals
>>> ) defines
>>> 'Shipped/Shipping' as 'Link to public
>>> documentation or bug/issue'. I'm not sure
>>> which signal would be right if there is an
>>> open issue.
>>
>> Thank for this feedback - I can see how that
>> is confusing. I updated the language to say
>> "Link to public documentation or bug/issue
>> that demonstrates the issue has shipped (i.e.,
>> an issue that links to patches that have been
>> merged, or a comment that a previously
>> disabled feature is not enabled by default)."
>>
> (this should read "now enabled by default",
> rather than "not"). 
> 
> -- 
> 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
> 

Re: [blink-dev] Intent to Ship: Custom Highlight API

[Manuel Rego Casasnovas]

I'm biased here as I've been working on this feature myself, so I cannot
give an official LGTM.

Thanks for all the work since the previous intent thread, I believe this
is now in a way better status to ship.

I'd be fine giving a LGTM with the following caveats:
* As mentioned at the end of the email, HighlightOverlayPainting flag
gets enabled before shipping this (that flag fixes lots of bugs
regarding paining of CSS highlight pseudos).
* The following CSSWG issue gets resolved:
  https://github.com/w3c/csswg-drafts/issues/6774
  It looks like there's an agreement already but it'd be nice to confirm
it, as this might change behavior if a different decision is made.

Other than that I've just some minor comments inline.

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> Risks
> 
> 
> Interoperability and Compatibility
> 
> Low risk: This feature received positive support from Safari and Firefox
> at TPAC 2019. Safari is implementing it, Firefox has not yet made any
> clear indication on implementation.
> 
> 
> 
> /Gecko/: No clear signal
> (https://github.com/mozilla/standards-positions/issues/482
> )

We could send a ping notifying that Chromium is planning to ship.

> /WebKit/: Positive. WebKit implemented the feature behind an
> experimental flag in 99:
> https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API
> .

I agree that it's positive WebKit has a WIP implementation. But just to
clarify the status Safari has an old version of this spec implemented,
and the implementation is not complete and not up to date regarding the
spec (e.g. https://bugs.webkit.org/show_bug.cgi?id=229797).

Cheers,
  Rego

-- 
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/46053910-a5af-bd87-60f9-f9ef21934fb7%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS :modal Pseudo Class

[Manuel Rego Casasnovas]

On 25/05/2022 08:52, Yoav Weiss wrote:
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Yes
> 
> 
> Link to the WPTs?

There are these tests for ":modal":
* http://http://wpt.live//css/selectors/modal-pseudo-class.html
*
http://http://wpt.live//css/selectors/invalidation/modal-pseudo-class-in-has.html

They are for , but it looks there are no tests for the
fullscreen case.

Cheers,
  Rego

-- 
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/64c52fb9-febb-9e08-cf2e-fd75d0ac696a%40igalia.com.

Re: [blink-dev] Re: Intent to Prototype and Ship: Support visual-box on overflow-clip-margin

[Manuel Rego Casasnovas]

LGTM3

On 18/05/2022 15:27, Mike Taylor wrote:
> LGTM2
> 
> On 5/18/22 9:16 AM, Daniel Bratell wrote:
>>
>> LGTM1
>>
>> It is a bit confusing with the TAG review mostly being negative, but I
>> think they didn't object to this particular part. Furthermore, it
>> seems useful, it's been reviewed and approved by the CSS working group
>> and though Mozilla's position is not official yet, they seem to agree
>> that this is a useful addition.
>>
>> /Daniel
>>
>> On 2022-05-04 17:22, Khushal Sagar wrote:
>>> Thanks for the review Yoav. Responses inline.
>>>
>>> On Wed, May 4, 2022 at 6:12 AM Yoav Weiss  wrote:
>>>
>>>
>>>
>>> On Monday, May 2, 2022 at 11:52:56 PM UTC+2 Khushal Sagar wrote:
>>>
>>>
>>> Contact emails
>>>
>>>
>>> khushalsa...@chromium.org
>>>
>>>
>>> Explainer
>>>
>>>
>>> 
>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow_on_replaced_elements.md
>>>
>>>
>>> Specification
>>>
>>>
>>> https://drafts.csswg.org/css-overflow/#overflow-clip-margin
>>>
>>>
>>> Summary
>>>
>>>
>>> overflow-clip-margin specifies how far an element's
>>> content is allowed to paint before being clipped.
>>> This feature allows using visual-box
>>> 
>>> values to configure the reference box that defines
>>> the overflow clip edge the content is clipped to.
>>>
>>>
>>> Blink component
>>>
>>>
>>> Blink>CSS
>>> 
>>> 
>>>
>>>
>>> TAG review
>>>
>>>
>>> The TAG review for the overflow-clip-margin property
>>> is
>>> here: https://github.com/w3ctag/design-reviews/issues/579
>>>
>>>
>>> TAG review status
>>>
>>>
>>> Issues addressed
>>>
>>>
>>> The TAG seem unhappy with this
>>> 
>>> ,
>>> and it doesn't seem like their concerns were addressed.
>>>
>>>
>>> The remaining concerns raised by TAG on that thread were about
>>> overflow:clip (which already shipped in Chrome and Firefox) so I
>>> wasn't sure if those are relevant for this intent.
>>>  
>>>
>>>
>>>
>>>
>>> Risks
>>>
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>> The feature has been reviewed and accepted by the
>>> cross-browser CSSWG.
>>>
>>>
>>> Gecko: In development
>>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1661582)
>>>
>>> WebKit: No signal
>>>
>>>
>>> Can we ask for a signal?
>>>
>>>
>>> Sure, I've sent an RFP for this here
>>> .
>>>  
>>>
>>>  
>>>
>>>
>>>
>>> Web developers: No signals
>>>
>>>
>>> Similarly, can you try to get signals here?
>>> https://goo.gle/developer-signals
>>>
>>>
>>> The bug which motivated this addition is here
>>>  (referenced
>>> in the CSSWG issue
>>> ). This bug is
>>> starred by 12 users, could we use that as a positive signal?
>>>  
>>>
>>>  
>>>
>>>
>>>
>>> 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?
>>>
>>>
>>> The feature supports a new keyword for an existing
>>> CSS property. There is no high risk for WebView.
>>>
>>>
>>> Debuggability
>>>
>>>
>>> No additional changes needed. overflow-clip-margin
>>> already surfaces in the devtools style panel.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>>
>>> Yes
>>>
>>>
>>> Requires code in //chrome?
>>>
>>>
>>> False
>>>
>>>
>>> Tracking bug
>>>
>>>
>>> 
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1320869
>>>
>>>
>>> Estimated milestones
>>>
>>> M103
>>>
>>>
>>> Anticipated spec changes
>>>
>>>
>>> Open questions about a feature may be a source of
>>> future web compat or interop issues. Please list open
>>> issues (e.g. links to known github issues in the
>>> project for the feature 

Re: [blink-dev] Intent to prototype and ship: CSS grid-template properties interpolation

[Manuel Rego Casasnovas]

Thanks for catching up on this. LGTM1

On 17/05/2022 18:44, 'Ana Sollano Kim' via blink-dev wrote:
> 
> Contact emails
> 
> ansol...@microsoft.com
> , dli...@microsoft.com
> 
> 
> 
> Explainer
> 
> None
> 
> 
> Specification
> 
> https://www.w3.org/TR/css-grid-1/#track-sizing
> 
> 
> 
> Summary
> 
> In CSS Grid, the grid-template-columns and grid-template-rows properties
> allow developers to define line names and track sizing of grid columns
> and rows, respectively. Supporting interpolation for these properties
> will allow grid layouts to smoothly transition between states, instead
> of snapping at the halfway point of an animation or transition. Web
> developers can use this functionality to achieve specific interactive
> effects without having to resort to driving animations via JavaScript.
> 
>  
> 
> 
> Blink component
> 
> Blink>Layout>Grid
> 
> 
> 
> TAG review
> 
>  
> 
> 
> TAG review status
> 
> Not applicable. We don’t believe this merits TAG review - it fits into
> the existing framework of CSS Animations/Transitions and it has been in
> the CSS Grid spec for years. But we’re happy to file a request if
> API_OWNERS feel this change should have one.
> 
> 
> Risks
> 
>  
> 
> 
> Interoperability and Compatibility
> 
> 
> /Gecko/: Shipped since 2019
> /WebKit/: Recently implemented in preview
> https://bugs.webkit.org/show_bug.cgi?id=204580
> 
> /Web developers/: Positive (383 stars)
> /Other signals/: N/A
> 
> 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
> 
> Existing grid support in devtools will allow inspection of the grid
> tracks created by the grid-template property values.
> 
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Yes.
> https://wpt.fyi/results/css/css-grid/animation?label=experimental=master
> 
> 
> 
> Flag name
> 
> --enable-blink-features=CSSGridTemplatePropertyInterpolation
> 
> 
> Requires code in //chrome?
> 
> False
> 
> Tracking bug
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=759665
> 
> 
> Estimated milestones
> 
> No milestones 

[blink-dev] Intent to Ship: ARIA Attribute Reflection for role attribute

[Manuel Rego Casasnovas]

**Contact emails**

r...@igalia.com

**Specification**

https://w3c.github.io/aria/#idl-interface

**Summary**

This is a kind of oversight from
https://chromestatus.com/feature/6643371200217088, at that time all
other ARIA attributes from the IDL
(https://w3c.github.io/aria/#idl-interface) were shipped, but this one
was missing.

This is a small change that will also include the role attribute as one
more of the reflection ARIA properties available.

**Motivation**

This should have shipped in M81
(https://groups.google.com/a/chromium.org/g/blink-dev/c/882iPcdnNQs/m/UP-PI8H2DwAJ)
together with the rest of attributes, by for some reason this wasn't
done (probably because it was originally developed under a different
runtime flag).

**Blink component**

Blink>Accessibility

**TAG review**

https://github.com/w3ctag/design-reviews/issues/134

**TAG review status**

Complete

**Risks**

  **Interoperability and Compatibility**

  This is just one more property that should had shipped originally.

  This has been shipped in Safari
(https://trac.webkit.org/changeset/234482/webkit) long time ago.

  And there's an implementation in Firefox behind a flag.

  **Gecko**: Under consideration
(https://github.com/mozilla/standards-positions/issues/211) Mozilla
position is still under consideration, but Firefox has an implementation
behind a runtime flag
(https://bugzilla.mozilla.org/show_bug.cgi?id=1628418). Last comment
from Anne on the bug, points to some spec issues but those are generic
issues for the whole feature (not particular issues with "role" property
itself).

  **WebKit**: Shipped/Shipping
(https://trac.webkit.org/changeset/234482/webkit)

**Debuggability**

This will work the same than the rest of properties already shipped.

**Is this feature fully tested by web-platform-tests?**

Yes

**Tracking bug**

https://bugs.chromium.org/p/chromium/issues/detail?id=1316801

**Link to entry on the Chrome Platform Status**

https://chromestatus.com/feature/5188935855636480

-- 
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/e0cb6f12-027f-e83e-e08e-8a35ff44642b%40igalia.com.

Re: [blink-dev] Intent to Implement and Ship: CSS Values Level 4 Calc Simplification and Serialization

[Manuel Rego Casasnovas]

LGTM3.

On 10/03/2022 05:47, Yoav Weiss wrote:
> LGTM2
> 
> On Thu, Mar 10, 2022 at 5:43 AM 박중헌  > wrote:
> 
> Yes, they are the right wpts. Besides, many other wpts'
> serialization results are affected to be in spec-compliant form
> so they are changed to be green too.
> E.g. 
> wpt/css/css-shapes/shape-outside/values/shape-margin-003.html
> wpt/css/css-shapes/shape-outside/values/shape-outside-ellipse-011.html
> wpt/css/css-shapes/shape-outside/values/shape-outside-inset-008.html
> wpt/css/css-shapes/shape-outside/values/shape-outside-inset-009.html
> wpt/css/css-values/calc-nesting-002.html
> and so on.
> 
> 
> 2022년 3월 10일 (목) 오전 10:27, Mike Taylor  >님이 작성:
> 
> Thanks. LGTM1
> 
> (Aside: Are these are the right WPTs
> 
> ?
> I'm excited for them to all be green if so).
> 
> On 3/9/22 6:14 PM, 박중헌 wrote:
>> Ok, I updated the links below and the chrome status entry.
>>
>>
>> Contact emails
>>
>>
>> pjh0...@gmail.com
>> , jh718.p...@samsung.com
>> 
>>
>>
>> Explainer
>>
>>
>> None
>>
>>
>> Specification
>>
>>
>> https://drafts.csswg.org/css-values-4/#calc-simplification
>> 
>> , 
>> https://drafts.csswg.org/css-values-4/#calc-serialize
>> 
>>
>>
>> Summary
>>
>>
>> CSS math functions are simplified and serialized per
>> spec. CSS calc simplification is a kind of constant
>> folding which evaluates css calculation tree to the
>> extent possible at parse time, so that evaluation at
>> computed/used-value time can be reduced. The
>> simplified result is serialized according to spec.
>>
>>
>>
>> Blink component
>>
>>
>> Blink
>> 
>> 
>>
>>
>> Search tags
>>
>>
>> css
>> , simplification
>> , 
>> serialization
>> 
>>
>>
>> TAG review
>>
>>
>> None
>>
>>
>> TAG review status
>>
>>
>> Not applicable
>>
>>
>> Risks
>>
>>
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>>
>> Gecko: Shipped/Shipping
>> (https://phabricator.services.mozilla.com/D61739
>> )
>>
>> WebKit: Shipped/Shipping
>> (https://bugs.webkit.org/show_bug.cgi?id=203442
>> )
>>
>> Web developers: No signals
>>
>>
>> Ergonomics
>>
>>
>> None
>>
>>
>>
>> Activation
>>
>>
>> None
>>
>>
>>
>> Security
>>
>>
>> None
>>
>>
>>
>> Debuggability
>>
>>
>> N/A
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>>
>> Yes
>>
>>
>>
>>
>> Requires code in //chrome?
>>
>>
>> False
>>
>>
>> Tracking bug
>>
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1253162
>> 
>> 
>>
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>>
>> https://chromestatus.com/feature/5730414630010880
>> 
>>
>> This intent message was generated by Chrome Platform
>> Status .
>>
>>
>> 2022년 3월 10일 (목) 오전 2:02, Mike Taylor
>> mailto:miketa...@chromium.org>>님이 작성:
>>
>> On 3/9/22 11:00 AM, 박중헌 wrote:
>>>
>>>
>>> Contact emails
>>>
>>>
>>> pjh0...@gmail.com
>>> , jh718.p...@samsung.com 
>>> 
>>>
>>>
>>> Explainer
>>>
>>>
>>> None
>>>
>>>
>>> Specification
>>>
>>>
>>> 

Re: [blink-dev] Re: Intent to Ship: Autofill in ShadowDOM

[Manuel Rego Casasnovas]

LGTM3.

Some comments inline.

On 16/02/2022 00:39, Mike Taylor wrote:
>> Interoperability and Compatibility
>>
>> I believe there is low compat risk. As far as I know, much
>> autofill behavior already diverges between browsers.
>>
>> Gecko: No signal
>>
>> WebKit: No signal

Does this works in other browsers? Have we reported bugs if it doesn't?

>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No. Autofill is not testable in WPT, as far as I know. In
>> order to test this feature, I had to make C++ browser tests.

Yeah, and there's already an issue about that:
https://github.com/web-platform-tests/wpt/issues/27118

Cheers,
  Rego

-- 
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/504ca0ae-6c4f-3c0e-3092-8b64e85fbc3f%40igalia.com.

Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

[Manuel Rego Casasnovas]

Overlay scrollbars have caused issues testing things in the past:
https://github.com/web-platform-tests/wpt/issues/10972

It'd be good to think about what we're going to do with these kind of
tests, and as Steve says maybe it'd be good to keep tests running with
overlay and non-overlay scrollbars to avoid regressions.

Cheers,
  Rego

On 01/02/2022 20:42, 'Rahul Arakeri' via blink-dev wrote:
> Re Steve: For Linux, we don't have a strong preference on the default
> scrollbar mode (and we don’t yet know the scope of work needed since we
> never tested this feature on Linux).
> 
> For Windows however, we recommend having minimal mode as the default as
> outlined in the visual spec
> .
> 
>  
> 
> Re all: Please let us know if we all have consensus on the visual
> styling
> 
> of the scrollbars. If you want to see the feature in action, please feel
> free to check out Microsoft Edge Canary
> .
> (Experimental flag /edge://flags/#edge-overlay-scrollbars-win-style/).
> 
>  
> 
> *From:* Steve Kobes 
> *Sent:* Monday, January 31, 2022 11:38 AM
> *To:* Rahul Arakeri 
> *Cc:* Chris Harrelson ; Ian Kilpatrick
> ; Mike Taylor ;
> blink-dev@chromium.org; Robert Flack ; wangxianzhu
> ; p...@chromium.org; input-...@chromium.org;
> Yaroslav Shalivskyy ; Olga Gerchikov
> ; Sahir Vellani ;
> Ben Mathwig 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent
> Scrollbars.
> 
>  
> 
> Keeping non-overlay by default on Linux would be one way to mitigate the
> risk that Ian mentions, namely that bugs specific to non-overlay mode
> may creep in and not be noticed quickly.  (This concern applies to some
> degree both to bugs in websites, and bugs in Chrome.)
> 
>  
> 
> On Mon, Jan 31, 2022 at 2:23 PM 'Rahul Arakeri' via input-dev
> mailto:input-...@chromium.org>> wrote:
> 
> Thanks Ian :)
> 
>  
> 
> Re Chris:
> 
> There will be some OS wiring missing (like switching between
> dark/light modes, "Always show scrollbars”, etc) but most of the
> code should just work. Note that we've never really tested this
> feature on Linux so we do not have an exhaustive list of stuff that
> will not work on Linux.
> 
>  
> 
> *From:* Chris Harrelson  >
> *Sent:* Friday, January 28, 2022 3:45 PM
> *To:* Ian Kilpatrick  >
> *Cc:* Rahul Arakeri  >; Mike Taylor  >; blink-dev@chromium.org
> ; Robert Flack  >; wangxianzhu  >; p...@chromium.org
> ; input-...@chromium.org
> ; Yaroslav Shalivskyy
> mailto:yshalivs...@microsoft.com>>; Olga
> Gerchikov mailto:gerch...@microsoft.com>>;
> Sahir Vellani  >; Ben Mathwig
> mailto:benjamin.math...@microsoft.com>>
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to implement:
> Fluent Scrollbars.
> 
>  
> 
> Re Linux: I'm hoping we can just use the same code on Linux so that
> we have overlay scrollbars everywhere. Rahul, would that work code-wise?
> 
>  
> 
> On Fri, Jan 28, 2022 at 3:40 PM Ian Kilpatrick
> mailto:ikilpatr...@chromium.org>> wrote:
> 
> Exciting!
> 
>  
> 
> Adding onto Rahul's answer here a little - overlay scrollbars (or
> scrollbars which take to zero space) already exist on other
> platforms (e.g. they are the default on OSX). It won't/shouldn't be
> a web compat concern as most websites handle this already.
> 
>  
> 
> An interesting side effect of this will likely be that we'll see
> more sites (who are built after this change goes in) assume that
> scrollbars are always zero width (as this is now the default on all
> platforms except linux?) and as a result more content going forward
> being broken for those users who opt-out.
> 
> (To be clear there isn't much we can do about this - but an
> interesting side effect).
> 
>  
> 
> Ian
> 
>  
> 
> On Fri, Jan 28, 2022 at 2:51 PM 'Rahul Arakeri' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> Hi Mike,
> 
>  
> 
> Sure, I’ve created a chromestatus entry here:
> https://chromestatus.com/feature/5693137379917824
> 
> 

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Manuel Rego Casasnovas]

On 02/02/2022 16:51, Rouslan Solomakhin wrote:
>> Rouslan, it looks to me like the API is designed to support multiple
> stores, right?
>> For example if Samsung decided that they wanted to support connecting
> it up to
>> both the Android Play Billing API (so SBrowser could provide
> equivalent user
>> experience to Chrome) AND to the Samsung store (so merchants could have
>> a choice in stores, perhaps competing on terms like commission rate) they
>> could do that with the current API shape, right?
> 
> That is correct. The API shape has been generalized enough to be
> store-agnostic and browser-agnostic. We have
> 
> been  pitching the
> API to other stores and browsers as well.

It'd be really nice to get some engagement from other browsers or
stores. There are lots of stores, and also several browsers based on
Chromium. Have we talked to them? Is anyone interested in adding support
for this?

There are also mentions to v2.0 and v2.1. Which one would be shipping?
Are you expecting more changes on the API in the short term? It might be
hard to implement those changes once it's shipped.

On the TPAC presentation there was this plan:
* Collect feedback from the origin trial.
* Publish draft spec in WICG.
* Iterate with more developer feedback.
* Collaborate with other user agents and app stores.
* Ship it.

It looks like the spec PR hasn't been merged yet
(https://github.com/WICG/digital-goods/pull/40), and I'd love to
understand better the efforts to convince other browsers and stores
about the benefits of this API.

> On Wed, Feb 2, 2022 at 10:31 AM Rick Byers  > wrote:
> 
> +1 to Yoav's perspective here. Our job is not to force
> interoperability but to create the conditions to make future
> interoperability as easy as possible. We have multiple examples of
> APIs where originally Chrome was the only interested browser, but
> once sites started to adopt them and demonstrate the value, other
> browsers decided they wanted to provide their users with that value
> too. I would hate to create a condition where, for example, Brave,
> Edge or Samsung browser felt compelled to support an API with
> 'Chrome' in it's name once there was clear user value to supporting
> the use case. Further, if we put Chrome in the name that could be
> perceived as indicating that we were actively trying to create such
> browser lock-in or otherwise create conditions for Chrome to have an
> unfair advantage over other browsers when nothing could be further
> from the truth.
> 
> Rouslan, it looks to me like the API is designed to support multiple
> stores, right? For example if Samsung decided that they wanted to
> support connecting it up to both the Android Play Billing API (so
> SBrowser could provide equivalent user experience to Chrome) AND to
> the Samsung store (so merchants could have a choice in stores,
> perhaps competing on terms like commission rate) they could do that
> with the current API shape, right?
> 
> We've fought hard to get away from the webkit-prefixed and "chrome
> apps" world and we know it's not possible to know up front that an
> API will never have interoperable implementations. I think the
> downside of potentially using up a small piece of the global API
> namespace for an API that fails to achieve interoperability is much
> smaller than the downside of disincentivizing other implementations
> or burning a Chrome/Play API name into the web for what may become
> more general.

I agree this is something we want to avoid. And I understand what Yoav
and your are explaining. It makes sense to create standard APIs not
attached to a single browser, so in the future they can be adopted by
others.

I just want to have a better picture of what we're doing to convince
others to adopt this.

> At the same time, the TAG has been clear that their time is best
> spent on the APIs that are most likely to become interoperable
> standards. Dan told me at one point that it might be best if we
> didn't even both asking for TAG review that didn't have engagement
> from a 2nd browser., so I don't think we should expect them to have
> any real interest in reviewing this API. They've already marked this
> review as closed, so I don't think we should expect a response.

TAG was closed with that feedback in July:
https://github.com/w3ctag/design-reviews/issues/571

A week ago there was a comment that this was going to ship without
following that feedback, and the TAG reopened the issue. That's what I
was suggesting to give them some time to reply.

> Rego, what do you think? I'll give my LGTM3 but also happy to keep
> discussing the tradeoffs here. I really appreciate having the
> 

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Manuel Rego Casasnovas]

TAG suggested back in July that this API something specific to Chrome or
Google Play Store. It looks like this hasn't been done, any good reason
to not doing that?

Also there's been an update on the TAG about the plan of shipping this
API without changing the name. But that was just 1 week ago, should we
give them some time to reply before shipping?

Cheers,
  Rego

On 01/02/2022 20:41, Yoav Weiss wrote:
> LGTM2
> 
> On Tue, Feb 1, 2022 at 8:00 PM Chris Harrelson  > wrote:
> 
> 
> LGTM1
> 
> On Tue, Feb 1, 2022 at 6:16 AM Rouslan Solomakhin
> mailto:rous...@chromium.org>> wrote:
> 
> Contact emails
> 
> mgi...@chromium.org ,
> rous...@chromium.org ,
> glen...@chromium.org 
> 
> 
> Explainer
> 
> https://github.com/WICG/digital-goods/blob/main/explainer.md
> 
> 
> 
> Spec
> 
> https://wicg.github.io/digital-goods/
> - Currently being
> reviewed by a spec mentor, so some details may change
> (hopefully, only formatting).
> 
> 
> Summary
> 
> An API for querying and managing digital products to facilitate
> in-app purchases from web applications, in conjunction with the
> Payment Request API (which is used to make the actual
> purchases). The API would be linked to a digital distribution
> service connected to via the user agent. In Chrome, this is
> specifically a web API wrapper around the Android Play Billing API.
> 
> 
> Origin trial analysis
> 
> DGAPI v2.0 is currently in an origin trial with M99 being the
> last milestone. So far, 40 people have responded to the origin
> trial survey. Notable data points:
> 
> 
> How easy was it to use the feature:4.1 out of 6.
> 
> (0 - extremely difficult … 6 - extremely easy.)
> 
> 
> How likely are you to keep using this feature:5.5 out of 6.
> 
> (0 - extremely unlikely … 6 - extremely likely.)
> 
> 
> The most common comments were about improving feature
> documentation and debuggability. That is being tracked in
> https://github.com/WICG/digital-goods/issues/33
> .
> 
> 
> Blink component
> 
> Blink>Payments
> 
> 
> 
> 
> Search tags
> 
> payments ,
> billing 
> 
> 
> TAG review
> 
> https://github.com/w3ctag/design-reviews/issues/571
> TAG
> recommends making a Chrome-specific API. Other issues addressed.
> 
> 
> TAG review status
> 
> Issues addressed
> 
> 
> Risks
> 
> Interoperability and Compatibility
> 
> Similar to Payment Request: this API is used to talk to specific
> store backends, and so its usage is tailored to the specific
> store. The reason it's a proposed web standard is so that the
> same code (which is specific to one store) is portable across
> browsers.
> 
> 
> Gecko: No signal
> (https://github.com/mozilla/standards-positions/issues/349
> )
> Requested 2020-05-27.
> 
> 
> WebKit: No signal
> 
> (https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html
> 
> )
> Requested 2021-10-08.
> 
> 
> Web developers: Positive
> 
> (https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
> 
> ).
> 
> 
> Other signals: rouslan@ presented DGAPI at 2021 TPAC
> (meeting
> notes ) and
> at a recent PWA Dev Sync
> 
> (meeting
> notes
> 
> ).
> Other browser implementers and app stores do not appear to have
> immediate plans to engage with DGAPI. There were some questions,
> no objections.
> 
> 
> Ergonomics
> 
> Digital Goods API is used in tandem with the Payment Request API.
> 
> 
> In order for another browser to implement Digital 

Re: [blink-dev] Re: Intent to Ship: mix-blend-mode: plus-lighter

[Manuel Rego Casasnovas]

LGTM3.

On 26/01/2022 15:50, Mike Taylor wrote:
> LGTM2, thanks for the very well written explainer-slash-blog-post.
> 
> On 1/26/22 9:42 AM, Yoav Weiss wrote:
>> LGTM1
>>
>> This seems like a useful small addition! Following WebKit here makes
>> sense.
>> On Wednesday, January 19, 2022 at 5:40:45 PM UTC+1 Vladimir Levin wrote:
>>
>>
>> Contact emails
>>
>> vmp...@chromium.org, khushalsa...@chromium.org
>> , jakearchib...@chromium.org
>> 
>>
>>
>> Explainer
>>
>> https://jakearchibald.com/2021/dom-cross-fade/
>> 
>>
>>
>> Specification
>>
>> https://drafts.fxtf.org/compositing-2/#mix-blend-mode
>> 
>>
>>
>> Summary
>>
>> This proposal adds a plus-lighter value to the mix-blend-mode
>> property. Plus-lighter adds the source and destination colors
>> multiplied by their respective alphas. This operation is useful
>> when cross fading between two elements that may contain common
>> pixels. In that case, plus-lighter ensures that the common pixels
>> do not change in appearance as opacity changes from 0 to 1 on one
>> element and from 1 to 0 on the other.
>>
>>
>>
>> Blink component
>>
>> Blink>CSS
>> 
>> 
>>
>>
>> Search tags
>>
>> plus-lighter 
>>
>>
>> TAG review
>>
>> N/A: this is a single value addition to an existing property, and
>> this value already exists in a canvas context, so the TAG review
>> seemed not necessary
>>
>>
>> TAG review status
>>
>> Not applicable
>>
>>
>> Risks
>>
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: No signal
>>
>> WebKit: Shipped/Shipping
>> (https://github.com/w3c/fxtf-drafts/issues/445#issuecomment-995022125
>> )
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>>
>> Ergonomics
>>
>> This adds a new value to an existing CSS property. The ergonomics
>> risk is minimal.
>>
>>
>>
>> Activation
>>
>> This adds a new value to an existing CSS property. The activation
>> risk is minimal. This property is straight-forward to use.
>>
>>
>>
>> Security
>>
>> There are no security risks associated with this property.
>>
>>
>>
>> Debuggability
>>
>> This relies on existing debuggability of CSS mix-blend-mode.
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1275782
>> 
>>
>>
>> Estimated milestones
>>
>> M100
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5677338286096384
>> 
>>
>>
>> Links to previous Intent discussions
>>
>> Intent to
>> prototype: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MsbYsCV57vZ-eVQem4WUudVTGT%3Djzpib0NzezYEAMP-g%40mail.gmail.com
>> 
>> 
>>
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> -- 
>> 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/1c4ffaa4-38dd-4dca-b60c-ec0393147f2an%40chromium.org
>> .
> 
> 
> -- 
> 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/e7c669a2-0896-9a19-948b-a8248bd9df11%40chromium.org
> 

Re: [blink-dev] Intent to Prototype: mix-blend-mode: plus-lighter

[Manuel Rego Casasnovas]

On 16/12/2021 21:44, Vladimir Levin wrote:
> Gecko: No signal

Have we asked for signals? https://bit.ly/blink-signals

> WebKit: Shipped/Shipping
> (https://github.com/w3c/fxtf-drafts/issues/445#issuecomment-995022125
> )

The issue resolution also mentions plus-darker, but that's not mentioned
on this intent. Do we support it already or have plans around it?

Thanks,
  Rego

-- 
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/885c9371-62b6-d00c-cc33-d8662fd14939%40igalia.com.

Re: [blink-dev] Intent to Ship: Unprefixed text-emphasis properties

[Manuel Rego Casasnovas]

On 16/12/2021 15:49, TAMURA, Kent wrote:
> I think so.  If the current implementation has interoperability issues,
> we should fix them before shipping the unprefixed properties.

LGTM3, if we fix the potential interop issues before shipping.

Cheers,
  Rego

-- 
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/e99a1321-256c-c59f-67e7-b8b3948e262a%40igalia.com.

Re: [blink-dev] Intent to Ship: Unprefixed text-emphasis properties

[Manuel Rego Casasnovas]

Some questions regarding interoperability.

On 16/12/2021 08:43, Yoav Weiss wrote:
> On Wed, Dec 15, 2021 at 4:59 PM TAMURA, Kent  > wrote:
> Gecko: Shipped/Shipping
> 
> WebKit: Shipped/Shipping

When has WebKit shipped this? WPT tests seem to be failing there.

> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Yes

Is there interop with the other unprefixed implementations?
Are all the tests passing in Chromium once we unprefix the properties?
https://wpt.fyi/results/css/css-text-decor?label=master=experimental=text-emphasis

Thanks,
  Rego

-- 
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/418d0662-bf9c-f474-2710-67db4091e9ef%40igalia.com.

Re: [blink-dev] Re: Intent to Ship: CSS cascade layers

[Manuel Rego Casasnovas]

On 08/12/2021 18:48, Xiaocheng Hu wrote:
> They are failing on wpt.fyi because the feature is not enabled there.
> The feature is not behind the "experimental web platform features" flag.

Isn't a bit strange to move a runtime feature from "test" to "stable",
without having been in "experimental" for a while?
Maybe it'd be nice to maybe mark it as "experimental" and see lots of
green tests in wpt.fyi.

It looks interoperability is not great yet, as Firefox and Safari fail a
bunch of tests here and there. It would be nice if we could fill bugs
(if they haven't been filled yet) for some of the biggest interop issues
we think web authors will find.

Cheers,
  Rego

-- 
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/4463ac0f-072c-5674-eaee-38a2dc0c7d14%40igalia.com.

Re: [blink-dev] Intent to Ship: Pickling for Async Clipboard API

[Manuel Rego Casasnovas]

On 18/11/2021 22:30, 'Anupam Snigdha' via blink-dev wrote:
> /WebKit/: Neutral
> (https://github.com/w3c/editing/issues/334#issuecomment-933939592
> )
> Webkit has a custom format implementation which isn't well documented.

I'd say: "No signal", as there's no reply to the mailing list request:
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031855.html

It would be nice to send a new email to notify the intention of shipping
in Chromium, to see if we can get any feedback there.

Cheers,
  Rego

-- 
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/b2c779c3-0361-689c-8285-cf267fd1b229%40igalia.com.

Re: [blink-dev] BlinkOn 15 is Today and Tomorrow

[Manuel Rego Casasnovas]

On 17/11/2021 11:38, 'Thomas Steiner' via blink-dev wrote:
> Does the event platform publish to YouTube in the background? If so,
> does anyone have the unlisted livestream links so I could follow up? Thanks!

It looks like the talks from yesterday are already in the usual YouTube
channel:
https://www.youtube.com/playlist?list=PL9ioqAuyl6UL_1DiG1tPRHbGJlGQ_gQJW

Cheers,
  Rego

> 
> On Tue, Nov 16, 2021 at 7:04 PM Vincent Scheib  > wrote:
> 
> https://www.chromium.org/events/blinkon-15
> 
> 
> -- 
> 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-EfX%3Dn%3DDd4UUyBJZ%2BRoaYhuWkutgO8zny-sNrB0i9h0BfSQA%40mail.gmail.com
> 
> .
> 
> 
> 
> -- 
> Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com
> , https://twitter.com/tomayac
> )
> 
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.3.2 (GNU/Linux)
> 
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
> 
> -END PGP SIGNATURE-
> 
> -- 
> 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/CALgRrLnUpmXn_3eY_Aux506O8FmPFacs2DDUYv9QS9rRDU8RFw%40mail.gmail.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/bcd7e21d-a784-2fd1-9d3e-d50470495156%40igalia.com.

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: forced-color-adjust: preserve-parent-color

[Manuel Rego Casasnovas]

On a similar note of what I mentioned in the new "only" keyword for
color-scheme property, I'm having a hard time getting the whole picture
of that spec: https://drafts.csswg.org/css-color-adjust/

Do we have a full explainer of the whole spec? The spec is about 2
different things color schemes and forced colors, but they have some
similarities. Then the properties names and values are quite different.
E.g. "color-scheme: light only" vs "forced-color-adjust: none" vs
"color-adjust: exact". They are somehow about opting out of something,
but the properties names and syntax is pretty different.

Cheers,
  Rego

On 04/11/2021 20:33, Chris Harrelson wrote:
> 
> 
> On Fri, Oct 29, 2021 at 1:13 PM Fernando Serboncini  > wrote:
> 
> 
> Great. It makes sense.
> 
> thank you :) 
> 
> On Fri, Oct 29, 2021 at 4:11 PM Sara Tang  > wrote:
> 
> Hi Fernando,
> 
> This I2S does #3.
> 
> Thanks!
> Sara
> 
> 
> *From:* Fernando Serboncini  >
> *Sent:* Friday, October 29, 2021 8:21 AM
> *To:* Sara Tang  >
> *Cc:* blink-dev@chromium.org 
> mailto:blink-dev@chromium.org>>; Alison
> Maher  >; Daniel Libby
> mailto:dli...@microsoft.com>>
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship:
> forced-color-adjust: preserve-parent-color
>  
> Could you clarify if thisI2S:
> 1. just adds the 'preserve-parent-color' value to
> forced-color-adjust and doesn't apply it anywhere by default.
> 2. adds it and changes the default value of forced-color-adjust
> to be "preserve-parent-color" on all SVG elements
> 3. adds it and changes the default value of forced-color-adjust
> to be "preserve-parent-color" only on the SVG root element(that
> then gets propagated down)
> 
> it seems that #3 was decided
> 
> on
> the CSSWG
> 
> ,
> but your summary and crbug's CL looks more like #1, while your
> motivation seems like #2.
>  
> 
> On Thu, Oct 28, 2021 at 5:45 PM 'Sara Tang' via blink-dev
> mailto:blink-dev@chromium.org>> wrote:
> 
> 
> Contact emails
> 
> sart...@microsoft.com
> , alison.ma...@microsoft.com
> 
> 
> 
> Explainer
> 
> 
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md
> 
> 
> 
> 
> Specification
> 
> https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop
> 
> 
> 
> 
> Summary
> 
> Adds the ‘preserve-parent-color' value to the
> ‘forced-color-adjust' CSS property. When Forced Colors Mode
> is enabled, the ‘color’ property is inherited, and we’ve 

Re: [blink-dev] Intent to Ship: auto keyword for contain-intrinsic-size

[Manuel Rego Casasnovas]

LGTM1 but please add WPT tests.

On 29/10/2021 21:19, 'Christian Biesinger' via blink-dev wrote:
> Is this feature fully tested by web-platform-tests?
> 
> No

I guess this is a mistake and you're actually adding WPT tests as part
of this.

Cheers,
  Rego

-- 
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/eecd661f-669b-0def-2a71-f13cd3404051%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[Manuel Rego Casasnovas]

LGTM2, it's nice we're catching up with WebKit.

I still miss the whole picture in the spec with all the properties and
different values: https://drafts.csswg.org/css-color-adjust/
Maybe a good explainer for the whole thing would be welcomed.

Cheers,
  Rego

On 04/11/2021 19:49, Daniel Bratell wrote:
> LGTM1
> 
> /Daniel
> 
> On 2021-10-29 21:09, Emilio Cobos Álvarez wrote:
>>
>>
>> On 10/28/21 13:14, Rune Lillesveen wrote:
>>> On Thu, Oct 28, 2021 at 12:11 PM Manuel Rego Casasnovas
>>> mailto:r...@igalia.com>> wrote:
>>>
>>>     Hi,
>>>
>>>     Some comments inline.
>>>
>>>     On 27/10/2021 16:09, Rune Lillesveen wrote:
>>>  >         Summary
>>>  >
>>>  > The 'only' keyword has been re-added to the specification for
>>>  > color-scheme as a way of per-element opt-out of color-scheme
>>> override
>>>  > like forced darkening.
>>>
>>>     I guess this is the CSSWG discussion about re-adding it:
>>>     https://github.com/w3c/csswg-drafts/issues/5089
>>>     <https://github.com/w3c/csswg-drafts/issues/5089>
>>>
>>>
>>> Correct.
>>>
>>>  > Previously, both declarations below would force the div
>>> element into
>>>  > color-scheme dark and apply forced darkening. With this
>>> change, the
>>>  > second declaration would opt-out of forced darkening and keep the
>>>     used
>>>  > color-scheme 'light'.
>>>  >
>>>  > div { color-scheme: light } div { color-scheme: only light } will
>>>     keep
>>>  > the color-scheme for the element light and opt-out of forced
>>>     darkening.
>>>
>>>     Let me clarify this comment, this is happening when we're in forced
>>>     darkening, am I right?
>>>     First I read it too quickly and "color-scheme: light" forcing the
>>> DIV
>>>     into color-scheme dark was weird.
>>>
>>> Correct, when we're in forced darkening, or color-scheme override
>>> which is the term used by the specification.
>>>
>>>  > This feature is already enabled as part of an original trial
>>> in M96:
>>>  > https://chromestatus.com/features/5672533924773888
>>>     <https://chromestatus.com/features/5672533924773888>
>>>  > <https://chromestatus.com/features/5672533924773888
>>> <https://chromestatus.com/features/5672533924773888>>
>>>
>>>     Do we have any results to comment from the origin trial? Or it was
>>>     mostly for auto dark mode and this was just a small bit of it?
>>>
>>>
>>> That was mostly for auto dark mode, but Peter can confirm.
>>>
>>>  > Gecko: In development
>>>  > (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
>>>     <https://bugzilla.mozilla.org/show_bug.cgi?id=1576289>
>>>  > <https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1576289>>) Development of
>>>  > the color-scheme property in progress. At least blocker issues
>>>     are being
>>>  > fixed.
>>>
>>>     Not sure if this is in development, as there seems to be not recent
>>>     activity on the bug; but they indeed look interested in implementing
>>>     color-scheme property. Do we have any feedback from Mozilla about
>>> this
>>>     "only" keyword?
>>>
>>>
>>> Emilio (added) has been fixing blocker issues, fixing tests, doing
>>> spec changes for , etc, which I took as a
>>> signal of Mozilla working on it.
>>
>> Yeah, indeed. I guess my only question about the only keyword is
>> whether it'd be applicable to printing as well.
>>
>> In particular, Chrome right now respects > content=dark> while printing, but it might be reasonable for UAs to
>> force it to light in that case, in order to save ink...
>>
>> I guess `only` could also serve as a hint for the UA to not do such
>> thing... But then again we already have a way to opt out of similar
>> adjustments with `color-adjust: exact`. Was extending / expanding the
>> scope of the `color-adjust` property for this, instead of adding an
>> `only` value to `color-scheme` considered?
>>
>>  -- Emilio
>>
>>> -- 
>>> Rune Lillesveen
>>>
>>> -- 
>>>

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Manuel Rego Casasnovas]

LGTM3

On 04/11/2021 20:04, Daniel Bratell wrote:
> LGTM2
> 
> /Daniel
> 
> On 2021-11-04 20:02, Chris Harrelson wrote:
>> LGTM1 to ship in parallel with landing the PR.
>>
>> On Thu, Nov 4, 2021 at 12:01 PM 'Aaron Krajeski' via blink-dev
>>  wrote:
>>
>> During a WHATWG spec meeting this morning we agreed to not throw
>> for malformed canvas filters. There are still a few editorial
>> changes to go through on that PR, but other than that everything
>> is settled for this launch.
>>
>> On Friday, October 29, 2021 at 1:53:20 PM UTC-4
>> dom...@chromium.org wrote:
>>
>> The usual definition of "breaking change" that we use when
>> shipping features is not "if web developers always do valid
>> things, then the change we are making avoids breakages". We
>> can't rely on web developers to write valid code all the
>> time... see e.g. stats about what percent of the web is valid
>> HTML.
>>
>> For example, while people might not write "asdf", they might
>> write "colourMatrix" (spot the typo), or similar.
>>
>> On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini
>>  wrote:
>>
>> yes, of course if you pass "asdf" one would throw and the
>> other wouldn't. There will be a potential behavior difference.
>>
>> My point is nobody would write "asdf" as a filter, because
>> "asdf" is not a spec'ed or implemented filter anywhere.
>> There are no possible mismatches at this point. If
>> CanvasFilter exists, the set of filters is well defined
>> everywhere.
>>
>> On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola
>>  wrote:
>>
>> I don't think that's true. If someone passes "asdf" to
>> the CanvasFilter constructor, changing from
>> not-throwing to throwing would be a breaking change.
>> We'd need to add use counters, etc. to find out if
>> anyone is passing such invalid values.
>>
>> Whereas, if we start off with throwing, we can always
>> remove the throwing behavior later, with no use
>> counters required.
>>
>> On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini
>>  wrote:
>>
>> Since the current implementation is not throwing,
>> we could reasonably launch as-is and the add
>> throwing if it is agreed to do so after.
>> The added risk is the exact same risk that we are
>> arguing to begin with (i.e., code that uses
>> not-implemented filters without try/catch would
>> break). But since there are no "not-implemented
>> filters" yet, it may not be a problem.
>>
>> On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola
>>  wrote:
>>
>> Yep. Reasonable people can disagree on the
>> tradeoffs here. The question is whether this
>> is something we want to deadlock over with
>> other implementers.
>>
>> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor
>>  wrote:
>>
>> On 10/29/21 1:23 AM, Yoav Weiss wrote:
>>> Hey Domenic! :)
>>>
>>> On Thu, Oct 28, 2021 at 11:00 PM Domenic
>>> Denicola  wrote:
>>>
>>>
>>> FWIW the two HTML editors on the
>>> thread (myself and Anne, with our
>>> HTML editor hats on), as well as
>>> Mozilla (via Anne with his Mozilla
>>> hat on), prefer the throwing
>>> behavior. I think in most cases to
>>> overcome that position we would need
>>> some really strong reasons why the
>>> Chromium project believes the
>>> non-throwing behavior is better. It's
>>> not clear to me how strong Chromium's
>>> position is on this issue, and
>>> whether it's worth delaying the
>>> feature over. (Or indeed, delaying
>>> all the features, since the plan
>>> seems to be to bundle them together?)
>>>
>>>
>>> My concerns with the throwing behavior
>>> are similar to the ones we have discussed
>>> 
>>> 

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

[Manuel Rego Casasnovas]

LGTM2

On 29/10/2021 06:56, Yoav Weiss wrote:
> LGTM1
> 
> On Thu, Oct 28, 2021 at 10:56 PM Andreu Botella
> mailto:and...@andreubotella.com>> wrote:
> 
> I don't think the differences are listed anywhere. I know there are
> some because of the failures in
> 
> https://wpt.fyi/results/html/infrastructure/safe-passing-of-structured-data?label=experimental=master
> 
> ,
> but there might be others that aren't tested. Although it seems like
> some of the failures in the shared-array-buffer folder seem to be
> bugs with the tests rather than with the implementations.
> 
> 
> OK, as these differences are already exposed, I don't think shipping
> this significantly increases risk. The fact that they're covered by WPTs
> makes it more likely we'd (eventually) converge on the specified behavior.
> 
> 
> On Wednesday, October 27, 2021 at 11:12:32 PM UTC+2
> fs...@chromium.org  wrote:
> 
> This is amazing! :)
> 
> I agree it shouldn't block this, but do we have anywhere written
> what are the browser's differences on structured clone
> algorithms? Is it a spec issue? Could we add WPT tests for it?
> 
> On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella
>  wrote:
> 
> *Contact emails*
> and...@andreubotella.com, jbr...@chromium.org,
> su...@chromium.org
> 
> *Explainer*
> https://github.com/whatwg/html/issues/793
> 
> 
> *Specification*
> https://html.spec.whatwg.org/#structured-cloning
> 
> 
> *Summary*
> Enables using the HTML structured clone algorithm
> synchronously for cloning and transferring objects within a
> single realm.
> 
> *Initial public proposal*
> https://github.com/whatwg/html/issues/793
> 
> https://github.com/whatwg/html/pull/3414
> 
> 
> *Blink component*
> Blink>Messaging
> 
> 
> 
> 
> *TAG review*
> This is just exposing existing browser functionality, with a
> two-line spec. It doesn’t seem like there’s much to discuss
> architecturally, but I’ll file for review if the community
> thinks it would help.
> 
> *TAG review status*
> Not applicable
> 
> *Risks*
> 
> *Interoperability and Compatibility*
> Low. There are some differences across the browsers’
> implementations of the structured cloning algorithm, but
> they are very minor and already present in other APIs that
> use it.
> 
> Gecko: Shipped/Shipping
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1722576
> )
> Edge: No signal
> WebKit: Shipped/Shipping
> (https://bugs.webkit.org/show_bug.cgi?id=228331
> )
> 
> Web developers: Positive
> (https://github.com/whatwg/html/pull/3414#issuecomment-854051942
> 
> and following comments). There seems to be a lot of demand
> for a built-in deep clone, and while structured clone is not
> exactly that, it fulfills many of the use cases.
> 
> *Debuggability*
> n/a
> 
> *Is this feature fully tested by web-platform-tests
> 
> ?*
> Yes
> 
> 
> 
> 
> *Requires code in //chrome?*
> False
> 
> *Tracking bug*
> https://bugs.chromium.org/p/chromium/issues/detail?id=1233571 
> 
> 
> 
> *Estimated milestones*
> No milestones specified
> 
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5630001077551104
> 
> 
> *Requesting approval to ship? *
> Yes. This is a relatively small feature which exposes
> existing functionality.
> 
> -- 
> You received this message because you are 

Re: [blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[Manuel Rego Casasnovas]

Hi,

Some comments inline.

On 27/10/2021 16:09, Rune Lillesveen wrote:
> Summary
> 
> The 'only' keyword has been re-added to the specification for
> color-scheme as a way of per-element opt-out of color-scheme override
> like forced darkening.

I guess this is the CSSWG discussion about re-adding it:
https://github.com/w3c/csswg-drafts/issues/5089

> Previously, both declarations below would force the div element into
> color-scheme dark and apply forced darkening. With this change, the
> second declaration would opt-out of forced darkening and keep the used
> color-scheme 'light'.
> 
> div { color-scheme: light } div { color-scheme: only light } will keep
> the color-scheme for the element light and opt-out of forced darkening.

Let me clarify this comment, this is happening when we're in forced
darkening, am I right?
First I read it too quickly and "color-scheme: light" forcing the DIV
into color-scheme dark was weird.

> This feature is already enabled as part of an original trial in M96:
> https://chromestatus.com/features/5672533924773888
> 

Do we have any results to comment from the origin trial? Or it was
mostly for auto dark mode and this was just a small bit of it?

> Gecko: In development
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
> ) Development of
> the color-scheme property in progress. At least blocker issues are being
> fixed.

Not sure if this is in development, as there seems to be not recent
activity on the bug; but they indeed look interested in implementing
color-scheme property. Do we have any feedback from Mozilla about this
"only" keyword?

Cheers,
  Rego

-- 
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/d0597dcb-b87a-cd31-8a2e-1650ae4f%40igalia.com.

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

[Manuel Rego Casasnovas]

This will ship in M97.

Cheers,
  Rego

On 27/10/2021 19:24, 'Joe Medley' via blink-dev wrote:
> Hi,
> 
> In which version of Chrome do you hope to ship?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com
>  | 816-678-7195
> /If an API's not documented it doesn't exist./
> 
> 
> On Thu, Oct 21, 2021 at 11:14 AM Daniel Bratell  > wrote:
> 
> Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on
> this thread.
> 
> /Daniel
> 
> On 2021-10-21 09:08, Yoav Weiss wrote:
>> LGTM2 to catch up here
>>
>> (Apparently we have 2 intent emails for this..)
>>
>> On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent > > wrote:
>>
>> LGTM1.  It's a small straight-forward change.
>>
>>
>>
>> On Thu, Oct 21, 2021 at 12:44 AM > > wrote:
>>
>> Contact emails
>> ssin...@igalia.com ,
>> fw...@chromium.org 
>>
>> Explainer:
>> The securitypolicyviolation event is already implemented
>> in all
>> browsers, one can find document on
>> 
>> MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
>> 
>> ,
>> 
>> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
>> 
>> ).
>> The securitypolicyviolation event is dispatched when there
>> is a Content
>> Security Policy violation. Typically, the JS code of the
>> web component
>> will listen to securitypolicyviolation events and react
>> with necessary
>> updates.
>>
>> One could just use addEventListener, but for convenience
>> and consistency
>> with other events (e.g. slotchange) it makes sense to add
>> a IDL
>> onsecuritypolicyviolation attribute which also reflect the
>> attribute on
>> elements. We recently shipped slotchange idl attriubte as well
>> 
>> (https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
>> 
>> )
>>
>> Developers are habitual to use EventTarget.onload = ...
>> and > onload="..."> , but if this does not work for all events,
>> it will be
>> surprising.
>>
>> Currently, the way to listen an event is:
>> target.addEventListener("securitypolicyviolation",
>> mylistener);
>>
>> After this addition an alternative attribute-based form
>> will be
>> availlable for the developers
>> element
>> 
>>
>> Doc Link(s):
>> -
>> https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
>> 
>> - https://github.com/whatwg/html/pull/2651
>> 
>> -
>> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>> 
>> 
>>
>> Specification
>> https://html.spec.whatwg.org 
>>
>> Summary
>> The securitypolicyviolation event is fired when a Content
>> Security
>> Policy is violated.One can listen to that event via the
>> EventTarget.addEventListener() API. The goal is now to
>> expose the
>> onsecuritypolicyviolation IDL attribute from the
>> GlobalEventHandlers
>> interface, so that one can register a listener by
>> attaching this
>> attribute to target elements.
>>
>> Blink component
>> Blink>DOM
>>
>> Motivation
>> The securitypolicyviolation event is fired when a Content
>> Security
>> Policy is violated.
>> One can naturally listen to that event via the
>> EventTarget.addEventListener() API. However, web
>> developers are also
>> familiar with the alternative attribute-based form (e.g.
>> element.addEventListener("securitypolicyviolation
>> ", ...) Vs on )
>> which is sometimes convenient for quick testing. For
>> consistency with
>> other events, an 

Re: [blink-dev] Intent to Ship: Late newline normalization in form submission

[Manuel Rego Casasnovas]

LGTM2

On 22/10/2021 12:58, Daniel Bratell wrote:
> Thanks for the clarification! My LGTM1 stands.
> 
> /Daniel
> 
> On 2021-10-22 12:51, Andreu Botella wrote:
>> Just to clarify: inspecting a FormData object isn't the only way to
>> observe this change. If you call fetch() with a FormData body, have a
>> form-associated custom element whose submission value is a FormData,
>> or modify a form's entry list through the FormData object passed in
>> the formdata event, before this change you could end up with
>> unnormalized entries in the form payloads, since early normalization
>> doesn't apply and the FormData methods don't normalize entries. Since
>> late normalization happens at the point of encoding the form payload
>> as the corresponding enctype, those cases will now be normalized. It's
>> still an extremely obscure case, though.
>>
>> Andreu
>>
>> On Friday, October 22, 2021 at 12:30:33 PM UTC+2 Daniel Bratell wrote:
>>
>> LGTM1
>>
>> If I understand correctly, this change would only be visible if
>> someone programmatically creates form data in javascript with the
>> FormData constructor, that data has non-CRLF newlines and the page
>> in one way or another depend on the interim value having been
>> normalized inside the FormData object before submit. I agree that
>> this is an obscure case and the presence of other browsers with
>> different behaviour makes this ok to ship.
>>
>> /Daniel
>>
>> On 2021-10-21 23:45, Mason Freed wrote:
>>>
>>>
>>> Contact emails
>>>
>>> and...@andreubotella.com, mas...@chromium.org
>>>
>>>
>>> Explainer
>>>
>>> None
>>>
>>>
>>> Specification
>>>
>>> 
>>> https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constructing-form-data-set
>>>
>>>
>>> Design docs
>>>
>>>
>>> https://blog.whatwg.org/newline-normalizations-in-form-submission
>>>
>>>
>>> Summary
>>>
>>> Before this change, newlines in form entries were normalized
>>> early in the form submission process (during the entry list
>>> construction), with an additional late normalization happening as
>>> the form payload was encoded with the
>>> application/x-www-form-urlencoded enctype. With this change, the
>>> early normalization is removed and the late normalization is
>>> extended to all enctypes.
>>>
>>>
>>>
>>> Blink component
>>>
>>> Blink
>>> 
>>>
>>>
>>> Search tags
>>>
>>> normalization
>>> , html
>>> , forms
>>> , newline
>>> , FormData
>>> 
>>>
>>>
>>> TAG review
>>>
>>>
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>>
>>> Risks
>>>
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> While this is a change in behavior, it should only affect very
>>> corner case situations. And the fact that both WebKit and Gecko
>>> have shipped this behavior should also mitigate the compat risk.
>>> For more detail, see the discussions on the spec PR:
>>> https://github.com/whatwg/html/pull/6287 This is an
>>> interop-related change: prior to this feature launching in
>>> Chromium, the browsers differed on behavior. They will now be the
>>> same.
>>>
>>>
>>>
>>> Gecko: Shipped/Shipping
>>>
>>> WebKit: Shipped/Shipping
>>>
>>> Web developers: No signals
>>>
>>>
>>> Debuggability
>>>
>>> No DevTools support required. This feature can be debugged
>>> directly via Javascript.
>>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>>
>>> Flag name
>>>
>>>
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1167095
>>>
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5654547184746496
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>> -- 
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit
>>> 
>>> 

Re: [blink-dev] Intent to Ship: Standardize existing client hint naming

[Manuel Rego Casasnovas]

LGTM2

On 21/10/2021 21:16, Daniel Bratell wrote:
> LGTM1
> 
> /Daniel
> 
> On Friday, 15 October 2021 at 14:41:44 UTC+2 ari...@chromium.org wrote:
> 
> Correct, they’ll behave the same as the other non-legacy hints.
> 
> On Fri, Oct 15, 2021 at 05:34 Yoav Weiss  wrote:
> 
> Thanks for working on this, Ari!
> 
> IIUC, this intent will add these new hint names, but would
> also ensure their behavior when it comes to 3P delegation would
> be different from the legacy hints (as they don't have the same
> legacy baggage). Is that correct?
> 
> 
> On Mon, Oct 11, 2021 at 8:09 PM Ari Chivukula
>  wrote:
> 
> Contact emails
> 
> ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
> 
> 
> Design Doc
> 
> 
> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
> 
> 
> 
> 
> Specification
> 
> https://wicg.github.io/client-hints-infrastructure/
> 
> 
> https://wicg.github.io/responsive-image-client-hints/
> 
> 
> https://wicg.github.io/savedata/#save-data-request-header-field
> 
> 
> https://wicg.github.io/netinfo/#networkinformation-interface
> 
> 
> 
> Summary
> 
> This proposal seeks to align our implementation with the
> Client Hint proposal
> by
> adding the `sec-ch-` prefix where it’s missing.
> 
> 
> Blink component
> 
> Privacy>Fingerprinting
> 
> 
> 
> 
> Motivation
> 
> Client Hints
> , a
> method to request information about the user's device or
> conditions, have been implemented in Chrome, but since the
> initial implementation the naming scheme has changed. If
> implemented, this proposal would add new client hints with a
> `sec-ch-` prefix to re-implement the following: `dpr`,
> `width`, `viewport-width`, and `device-memory`. The three
> network related client hints with legacy names, `rtt`,
> `downlink`, and `ect`, will not be updated as they may be
> replaced by different hints in an independent process.
> 
> 
> TAG review
> 
> Not needed
> 
> 
> Risks
> 
> Only Blink implements client hints and we are not (yet)
> removing any current ones, just re-implementing existing
> ones under the correct name. If usage permits, we will
> remove the legacy names in the future.
> 
>  
> 
> 
> Interoperability and Compatibility
> 
> Gecko: Client hints not implemented
> 
> WebKit: Client hints not implemented
> 
> Web developers: Positive interest from Cloudinary
> 
> 
> 
> 
> Is this feature fully tested by web-platform-tests?
> 
> Yes
> 
> 
> 
> 
> Tracking bug
> 
> https://crbug.com/1227043 
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://www.chromestatus.com/feature/6658223894429696
> 
> 
> 
> -- 
> 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+...@chromium.org.
> To view this discussion on the web visit
> 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com
> 
> .
> 
> -- 
> ~ Ari Chivukula (Their/There/They’re)
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group 

Re: [blink-dev] Intent to Ship: Independent/Individual Properties for CSS Transforms

[Manuel Rego Casasnovas]

LGTM3.

On 21/10/2021 19:53, Daniel Bratell wrote:
> LGTM2.
> 
> /Daniel
> 
> On 2021-10-21 08:19, Yoav Weiss wrote:
>> LGTM1
>> Seems important to catch up here, so thanks for working on this!!
>>
>> On Mon, Oct 18, 2021 at 11:05 PM David Baron  wrote:
>>
>>
>> Contact emails
>>
>>
>> dba...@chromium.org, kev...@chromium.org, fla...@chromium.org
>>
>>
>> Explainer
>>
>>
>> None
>>
>>
>> Specification
>>
>>
>> https://drafts.csswg.org/css-transforms-2/#individual-transforms
>>
>>
>> Summary
>>
>>
>> This adds three new CSS properties: translate, rotate, and
>> scale. This exposes a simple way for web developers to
>> access transforms in an intuitive way, without having to
>> think about how functions in the transform property
>> interact with each other. The properties are individually
>> animatable.
>>
>>
>>
>> Blink component
>>
>>
>> Blink
>> 
>> 
>>
>>
>> TAG review
>>
>>
>> Already shipped in two browser engines.
>>
>>
>> TAG review status
>>
>>
>> Not applicable (I think)
>>
>>
>> Risks
>>
>>
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>>
>> Gecko: Shipped/Shipping
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1424900)
>> Shipped in Firefox 72, January 2020.
>>
>> WebKit: Shipped/Shipping
>> 
>> (https://webkit.org/blog/11420/css-individual-transform-properties/)
>> Shipped in Safari 14.1 (desktop) / 14.5 (iOS), April 2021.
>>
>> Web developers: Positive: 25 stars
>> on https://bugs.chromium.org/p/chromium/issues/detail?id=496550 .
>> Notable early developer request for the feature (before WG
>> adoption)
>> in: https://twitter.com/rachelnabors/status/618266391993454592 
>> https://twitter.com/rachelnabors/status/618267483296825344 and
>> early reaction to WG adoption
>> in https://twitter.com/SaraSoueidan/status/613368671315054592 .
>> Positive developer reactions
>> to https://twitter.com/argyleink/status/1338907239990497280 .
>> Largely positive reactions to news of other engines
>> shipping the feature in responses
>> to https://twitter.com/jensimmons/status/1387870244392382468 , 
>> https://twitter.com/simevidas/status/627956718098485248 , 
>> https://twitter.com/dancwilson/status/121457225783989862 ,
>> and
>> in https://twitter.com/guerriero_se/status/1338468028804001796 , 
>> https://twitter.com/eladsc/status/1216286886697885696 , 
>> https://twitter.com/_zouhir/status/1389461399026294791 .
>> More recent developer interest
>> in https://twitter.com/anatudor/status/1377491818636587008 , 
>> https://twitter.com/anatudor/status/1309200388311199751 .
>>
>>
>> Debuggability
>>
>>
>> Has the standard exposure in devtools that all CSS
>> properties have.
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>>
>> Yes
>>
>>
>> Flag name
>>
>>
>> CSSIndependentTransformProperties
>>
>>
>> Requires code in //chrome?
>>
>>
>> False
>>
>>
>> Tracking bug
>>
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=496550
>>
>>
>> Estimated milestones
>>
>> The feature has been implemented behind a flag on
>> desktop/android/WebView since Chrome 45 (not a typo).
>>
>> For an estimated milestone for shipping, I think the feature is
>> close to being ready, so I'm still hoping for Chrome 97 but can't
>> promise that it will be ready in time.  It's waiting on a single
>> chain of dependencies, as described in the bug
>> , so
>> that more than one of the transform properties on a single element
>> can be simultaneously animated on the compositor.
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>>
>> https://chromestatus.com/feature/5705698193178624
>>
>>
>> Links to previous Intent discussions
>>
>>
>> Intent to
>> prototype: 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/-GfE73tlLX8/m/hv7Qitys6j8J
>>
>>
>> This intent message was generated by Chrome Platform
>> Status  and then
>> hand-edited a bit.
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> 

Re: [blink-dev] Intent to Ship: COLRv1 Color Gradient Vector Fonts

[Manuel Rego Casasnovas]

LGTM2

On 20/10/2021 11:30, Dominik Röttsches wrote:
> Hi Rego,
> 
> Thanks for the feedback. 
> 
> On Tue, Oct 19, 2021 at 9:01 PM Manuel Rego Casasnovas  <mailto:r...@igalia.com>> wrote:
> 
> Did we manage to get any further feedback from Apple after that email?
> Even if it was not directly on the webkit-dev mailing list but in some
> private conversations, working group discussions or whatever.
> 
> 
> I am afraid there's not much I can share here. We did have meetings with
> Apple before and after our request for a standards position and the
> discussion that ensued on webkit-dev, but there are no fundamentally new
> or different outcomes after those.

Ok, thanks for the clarifications. It's sad we didn't manage to engage
WebKit.

Cheers,
  Rego

-- 
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/4871259a-d8d6-fbd9-55de-2def1320b841%40igalia.com.

Re: [blink-dev] Intent to Ship: COLRv1 Color Gradient Vector Fonts

[Manuel Rego Casasnovas]

Hi Dominik,

On 19/10/2021 09:31, Yoav Weiss wrote:
> *WebKit:* Negative
> (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html 
> )
> 
> From the WebKit team, we received this negative response stating
> there's no real need for COLRv1 as OT-SVG exists, to which I
> responded extensively in this post
> . 
> Please
> refer to this thread for further details. Some API owners are
> already familiar with this discussion. My response sheds more light
> on some assertions and assumptions made by WebKit folks and provides
> a competitive analysis between OT-SVG and COLRv1 in terms of
> implementation complexity, file size and performance.
> Microsoft's Peter Constable responded as well
> 
> on behalf of Microsoft and Edge positively.
> 
> 
> I highly appreciate your measured and factful response on that thread as
> well as Peter's. Thanks for maintaining a high level of discourse.

Yeah really nice reply there.

Did we manage to get any further feedback from Apple after that email?
Even if it was not directly on the webkit-dev mailing list but in some
private conversations, working group discussions or whatever.

Cheers,
  Rego

-- 
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/ea58ab56-e39d-748b-1f99-8374dbed6d42%40igalia.com.

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Manuel Rego Casasnovas]

On 14/10/2021 23:06, Aaron Krajeski wrote:
> *Specification*
> Context Lost Event
> 
> Context Restored Event
> 
> Will Read Frequently
> 
> New Text Modifiers
> 
> Reset
> 
> RoundRect
> Conic
> Gradient
> Filters
>  (still in progress)

These are a bunch of features, so it'd be nice understand if other
parties are on board with all of them.

> *TAG review status
> *Resolution: satisfied
> 

Is the TAG on board with all the features we're shipping?

> *Interoperability and Compatibility*
> Gecko: In development (https://github.com/whatwg/html/issues/5431
> )
> Already implemented conic gradient. Okay with willReadFrequently,
> transforms and reset.

Any link to bugzilla?

> *Signals*
> Gecko: https://github.com/mozilla/standards-positions/issues/519
> 
> WebKit:
> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031833.html
> 

Both Gecko and WebKit have concerns about some of the features we asked
signals for.

Could you summarize if they agree on all the things shipped here, or
just a few. Or maybe they disagree in some of them.

Thanks,
  Rego

-- 
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/20b73a76-4495-cbcf-22b9-6a02f8738630%40igalia.com.

Re: [blink-dev] Intent to Implement and Ship: transform: perspective(none)

[Manuel Rego Casasnovas]

LGTM2

On 07/10/2021 08:07, Yoav Weiss wrote:
> LGTM1
> 
> On Mon, Oct 4, 2021 at 10:42 PM David Baron  > wrote:
> 
> 
> Contact emails
> 
> dba...@chromium.org 
> 
> 
> Explainer
> 
> None
> 
> 
> Specification
> 
> https://drafts.csswg.org/css-transforms-2/#funcdef-perspective
> 
> 
> 
> Summary
> 
> Implement support for a 'none' argument to the perspective()
> function within the syntax of the CSS transform property. This
> provides the perspective() function with a value that gives the
> identity matrix. Its effect is as though the perspective() function
> was given an argument that is infinite. This makes it easier (or, in
> some cases, possible) to do animations involving the perspective()
> function where one of the endpoints of the animation is the identity
> matrix.
> 
> 
> 
> Blink component
> 
> Blink>CSS
> 
> 
> 
> Search tags
> 
> css , transform
> , perspective
> 
> 
> 
> TAG review
> 
> Not needed for a single value addition to a single function within a
> CSS property.
> 
> 
> TAG review status
> 
> Not applicable
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> 
> 
> Gecko: Shipped/Shipping
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1725207
> ) Will ship
> very soon in Firefox 93.
> 
> WebKit: No signal
> (https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025
> )
> Safari developers participated in the CSS Working Group discussion
> about adding it and were ok with the addition. I recognize this
> isn't an official signal, but this seems perhaps too small a feature
> to ask for an explicit one.
> 
> 
> Can you file a webkit bug for this?
>   
> 
> 
> Web developers: Positive
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1723266#c2
> ) this is
> the one explicit signal from a developer that I could find
> 
> 
> Debuggability
> 
> Should be equally debuggable as existing values of the perspective()
> function.
> 
> 
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Yes
> 
> 
> Flag name
> 
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Tracking bug
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1253596
> 
> 
> 
> Estimated milestones
> 
> No milestones specified
> 
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://chromestatus.com/feature/5687325523705856
> 
> 
> This intent message was generated by Chrome Platform Status
> .
> 
> -- 
> 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/CAG0MU3iW8-GYebwN6TF8WCCKLcQNEVkqunuoPSL%2BkPrPW1u0qQ%40mail.gmail.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/CAL5BFfU%3D1-QAq_7pQnPDzMNz9BH0cc3cmYDbyinzcT15J8iv4g%40mail.gmail.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 

Re: [blink-dev] Intent to Ship: Do not invert selection background color when it matches text color

[Manuel Rego Casasnovas]

On 04/10/2021 14:24, Yoav Weiss wrote:
> Do we know the reasons why WebKit changed behavior?

Thanks for the question Yoav. This question lead to further
investigation to find out this is a total mess, so I abandon this intent
for now. Maybe in the future we could resend this.

For more details you can check this CSSWG issue (just found it today):
https://github.com/w3c/csswg-drafts/issues/6150

WebKit still changes the background color, but not in the same
situations than Chromium:
* Chromium inverts it here:
::selection { color: lime; background: lime; }
* While WebKit does this here:
::selection { color: rgba(0, 255, 0, .8); background: lime; }
  Because WebKit modifies the background set by the user to add 80%
opacity to it.

This code comes from an older commit than the one I pointed in the
intent: https://trac.webkit.org/changeset/1447/webkit (19 years ago).

And there was a funny comment on WebKit source code 17 years ago
(https://trac.webkit.org/changeset/7766/webkit):
// If the text color ends up being the same as the selection
// background, invert the selection background.  This should
// basically never happen, since the selection has transparency.

Like this only happens if the text color also has such transparency.

Anyway, we'll add this information on the CSSWG issue and see if there's
any kind of agreement.

So ignore this intent for now.

Cheers,
  Rego

> On Mon, Oct 4, 2021 at 1:34 PM Manuel Rego Casasnovas  <mailto:r...@igalia.com>> wrote:
> 
> 
> **Contact emails**
> r...@igalia.com <mailto:r...@igalia.com>, dazab...@igalia.com
> <mailto:dazab...@igalia.com>
> 
> **Specification**
> https://www.w3.org/TR/css-pseudo-4/#selectordef-selection
> <https://www.w3.org/TR/css-pseudo-4/#selectordef-selection>
> 
> **Summary**
> 
> Right now selection background color is inverted when it matches the
> text color in Chromium.
> So if you have a rule like this "::selection { color: cyan; background:
> cyan; }" the background gets inverted and a red background color is
> used.
> This is an old behavior inherited from WebKit but Safari doesn't do this
> anymore (and Firefox has never done this).
> The proposal is to stop inverting the background color for ::selection.
> 
> **Blink component**
> Blink>CSS
> 
> **TAG review**
> N/A
> 
> This is mostly a bug fix but we're sending the intent as a PSA and due
> to the potential compat risk.
> 
> **Risks**
> 
> **Interoperability and Compatibility**
> 
> The current Chromium behavior comes from WebKit
> (trac.webkit.org/changeset/52548/webkit
> <http://trac.webkit.org/changeset/52548/webkit>).
> WebKit has changed this behavior in the past and is no longer doing
> this.
> Firefox has never done this.
> This will align Chromium with the other browsers.
> 
> Use counter was added in M93 and it's around 0.0003%
> (https://chromestatus.com/metrics/feature/timeline/popularity/3934
> <https://chromestatus.com/metrics/feature/timeline/popularity/3934>).
> This change might make selected content impossible to read in some web
> pages (but that's already happening in Safari and Firefox).
> Or maybe this is making some webpages work as expected, if they were
> using selection colors to hide some content.
> 
> Gecko: Shipped/Shipping
> 
> WebKit: Shipped/Shipping
> 
> Web developers: No signals. This is mostly a bug fix, removing a quirk
> to improve interop; so it doesn't look like we need to ask for specific
> web developer signals.
> 
> **Is this feature fully tested by web-platform-tests?**
> 
> We're adding a new test specifically verifying this behavior in
> https://chromium-review.googlesource.com/c/chromium/src/+/3199752
> <https://chromium-review.googlesource.com/c/chromium/src/+/3199752>.
> 
> Apart from that css/css-pseudo/active-selection-018.html fails partially
> due to this issue if you enable HighlightInheritance runtime flag.
> 
> **Tracking bug**
> https://bugs.chromium.org/p/chromium/issues/detail?id=1217745
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1217745>
> 
> **Link to entry on the Chrome Platform Status**
> https://chromestatus.com/feature/5657973985640448
> <https://chromestatus.com/feature/5657973985640448>
> 
> -- 
> 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
> &

[blink-dev] Intent to Ship: Do not invert selection background color when it matches text color

[Manuel Rego Casasnovas]

**Contact emails**
r...@igalia.com, dazab...@igalia.com

**Specification**
https://www.w3.org/TR/css-pseudo-4/#selectordef-selection

**Summary**

Right now selection background color is inverted when it matches the
text color in Chromium.
So if you have a rule like this "::selection { color: cyan; background:
cyan; }" the background gets inverted and a red background color is used.
This is an old behavior inherited from WebKit but Safari doesn't do this
anymore (and Firefox has never done this).
The proposal is to stop inverting the background color for ::selection.

**Blink component**
Blink>CSS

**TAG review**
N/A

This is mostly a bug fix but we're sending the intent as a PSA and due
to the potential compat risk.

**Risks**

**Interoperability and Compatibility**

The current Chromium behavior comes from WebKit
(trac.webkit.org/changeset/52548/webkit).
WebKit has changed this behavior in the past and is no longer doing this.
Firefox has never done this.
This will align Chromium with the other browsers.

Use counter was added in M93 and it's around 0.0003%
(https://chromestatus.com/metrics/feature/timeline/popularity/3934).
This change might make selected content impossible to read in some web
pages (but that's already happening in Safari and Firefox).
Or maybe this is making some webpages work as expected, if they were
using selection colors to hide some content.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals. This is mostly a bug fix, removing a quirk
to improve interop; so it doesn't look like we need to ask for specific
web developer signals.

**Is this feature fully tested by web-platform-tests?**

We're adding a new test specifically verifying this behavior in
https://chromium-review.googlesource.com/c/chromium/src/+/3199752.

Apart from that css/css-pseudo/active-selection-018.html fails partially
due to this issue if you enable HighlightInheritance runtime flag.

**Tracking bug**
https://bugs.chromium.org/p/chromium/issues/detail?id=1217745

**Link to entry on the Chrome Platform Status**
https://chromestatus.com/feature/5657973985640448

-- 
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/d48df17c-160c-4b98-c77c-41f063891570%40igalia.com.