Re: [blink-dev] Re: Intent to Ship: CSS supports() condition for @import

[Noam Rosenthal]

One open issue that I didn't see mentioned and is worth noting, is a
missing equivalent in  elements (similar to . This
creates an inconsistency where you can have conditional imports in CSS but
not directly from HTML. This is mentioned in
https://github.com/whatwg/html/issues/7540. Not saying it should block
shipping, but rather that it should be considered an open issue.

On Wed, Nov 22, 2023 at 5:47 AM Yoav Weiss  wrote:

> LGTM1
>
> While I'm not excited about @import in general and think no one should use
> it, this restricts it in potentially useful ways.
>
> On Wednesday, November 15, 2023 at 3:28:48 PM UTC+1 Daniil Sakhapov wrote:
>
>> Contact emailssakha...@chromium.org
>>
>> Specificationhttps://www.w3.org/TR/css-cascade-5/#conditional-import
>>
>> Summary
>>
>> It allows to import stylesheets and layers conditioned on supports(). If
>> the support() doesn't match, the import will not be fetched.
>>
>>
>> Example: @import "mystyle.css" supports(display: flex);
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/279)
>>
>> *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
>>
>> 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-cascade/import-conditions.html
>> https://wpt.fyi/css/cssom/cssimportrule.html
>>
>>
>> Flag name on chrome://flagsCSSSupportsForImportRules
>>
>> Requires code in //chrome?False
>>
>> Estimated milestones
>> DevTrial on desktop 121
>> DevTrial on Android 121
>>
>> 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/5899007704694784
>>
>> 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/13305766-65c8-427c-85a4-fc457c855bf0n%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/CAJn%3DMYYsLu_ndEd75PdsAeRZ%3DffHNb7zTufM_1mZRyHYRgTphw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: CSS supports() condition for @import

[Daniil Sakhapov]

Yes, thanks, I saw this discussion and will keep my eye on it. So, once the 
solution for back comp is found there, I'll work on it.

On Wednesday, November 22, 2023 at 12:40:27 PM UTC+1 Noam Rosenthal wrote:

> One open issue that I didn't see mentioned and is worth noting, is a 
> missing equivalent in  elements (similar to . This 
> creates an inconsistency where you can have conditional imports in CSS but 
> not directly from HTML. This is mentioned in 
> https://github.com/whatwg/html/issues/7540. Not saying it should block 
> shipping, but rather that it should be considered an open issue.
>
> On Wed, Nov 22, 2023 at 5:47 AM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> While I'm not excited about @import in general and think no one should 
>> use it, this restricts it in potentially useful ways.
>>
>> On Wednesday, November 15, 2023 at 3:28:48 PM UTC+1 Daniil Sakhapov wrote:
>>
>>> Contact emailssakha...@chromium.org
>>>
>>> Specificationhttps://www.w3.org/TR/css-cascade-5/#conditional-import
>>>
>>> Summary
>>>
>>> It allows to import stylesheets and layers conditioned on supports(). If 
>>> the support() doesn't match, the import will not be fetched.
>>>
>>>
>>> Example: @import "mystyle.css" supports(display: flex);
>>>
>>> Blink componentBlink>CSS 
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *Gecko*: Shipped/Shipping
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/279)
>>>
>>> *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
>>>
>>> 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-cascade/import-conditions.html 
>>> https://wpt.fyi/css/cssom/cssimportrule.html
>>>
>>>
>>> Flag name on chrome://flagsCSSSupportsForImportRules
>>>
>>> Requires code in //chrome?False
>>>
>>> Estimated milestones
>>> DevTrial on desktop 121
>>> DevTrial on Android 121
>>>
>>> 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/5899007704694784
>>>
>>> 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/13305766-65c8-427c-85a4-fc457c855bf0n%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/920ac2b2-1dba-41fb-b0c0-782878ee033an%40chromium.org.

[blink-dev] Re: Intent to Ship: Document picture-in-picture: require user gesture for resize APIs

['Tommy Steimel' via blink-dev]

On Tue, Nov 21, 2023 at 9:43 PM Yoav Weiss  wrote:

>
>
> On Friday, November 17, 2023 at 8:47:34 PM UTC+1 Tommy Steimel wrote:
>
> Contact emailsstei...@chromium.org, liber...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/WICG/document-picture-in-picture/pull/104
>
> Summary
>
> This adds a user gesture requirement for the resizeBy() and resizeTo()
> Window APIs for document picture-in-picture windows. This allows websites
> to make use of those APIs while mitigating much of the abuse potential of
> those APIs on an always-on-top window.
>
>
> Blink componentBlink>Media>PictureInPicture
> 
>
> TAG reviewN/A as this is a minor change to the behavior of an existing API
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> This added requirement would mean that calls to these API can now fail. Is
> that new? Or are developers already expected to handle failures?
> Do we expect developers to start checking the UserActivation API
>  before
> calling these methods?
>

Currently these APIs always fail on document picture-in-picture windows
regardless of user activation (to prevent really spammy always-on-top
windows). We don't expect developers to check the UserActivation API at
all, just to only call resizeTo()/resizeBy() in response to a user gesture.


>
>
> *Gecko*: No signal (https://github.com/mozilla/standards-positions/issues/
> 670#issuecomment-1786354361) Added comment to existing standards position
> issue for document picture-in-picture. No response yet
>
> *WebKit*: No signal (https://github.com/WebKit/
> standards-positions/issues/41#issuecomment-1786354016) Added comment to
> existing standards position issue for document picture-in-picture. No
> response yet
>
> *Web developers*: Positive The ability to programmatically resize the
> document picture-in-picture window is one of the most-requested features
> for document picture-in-picture
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> While being able to resize an always-on-top window at will is a
> security/annoyance risk, by making the API consume a user gesture, the
> website can only resize once per click, which limits the possible abuse
> vectors
>
>
> 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?
>
> N/A
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> The document picture-in-picture API is not supported on Android
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> document-picture-in-picture/resize-requires-user-gesture.https.html
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justification
>
> Small, low-risk change to existing API
>
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1354325
>
> Sample links
> https://steimelchrome.github.io/document-pip/click_to_resize.html
>
> Estimated milestonesShipping on desktop121
>
> 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).
> N/A
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5398995019235328
>
> 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/CAE-AwAqS29Q2%2BbV89rc8x%2B3BCVQVuLw5QEPnkbrJpy-2mq2bZA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: SpeechSynthesis and SpeechSynthesisVoice interface objects

[Philip Jägenstedt]

FYI, this ended up being reverted soon and never reached stable. After 2+
years, I've relanded it in
https://chromium-review.googlesource.com/c/chromium/src/+/5040561 and
expect it will be in Chrome 121.

On Wed, Jun 30, 2021 at 3:55 PM Rick Byers  wrote:

> LGTM3 - trivial, nearly just a bugfix
>
> On Wed, Jun 30, 2021 at 4:41 AM Daniel Bratell 
> wrote:
>
>> LGTM2
>> On 2021-06-30 01:40, TAMURA, Kent wrote:
>>
>> LGTM1.
>> They should have interface objects, and the Gecko status is a good signal.
>>
>> On Wed, Jun 30, 2021 at 1:52 AM Philip Jägenstedt 
>> wrote:
>>
>>> Contact emails foo...@chromium.org
>>>
>>> Specification https://wicg.github.io/speech-api/#tts-section
>>>
>>> Summary
>>>
>>> This is about the interface objects for SpeechSynthesis and
>>> SpeechSynthesisVoice, not about the functionality itself which was already
>>> supported. These interfaces should be exposed according to spec. Feature
>>> detection using window.speechSynthesis was already possible, but this makes
>>> feature detection using SpeechSynthesisVoice.prototype possible. Note that
>>> SpeechSynthesisEvent, SpeechSynthesisErrorEvent and
>>> SpeechSynthesisUtterance interface objects were already exposed.
>>>
>>>
>>> Blink component Blink>Speech
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> In general there is very little web compat risk by exposing a new
>>> interface. However, since these interfaces have previously only been
>>> exposed by Firefox, it's plausible some feature detection code involving
>>> them has accidentally only worked on Firefox, and that Chromium will now go
>>> down a new code path. This risk does not seem significant enough to do
>>> anything preemptively. This is a minor and trivial change, but moving in
>>> the direction of interoperability by matching Firefox and the spec.
>>>
>>>
>>> Gecko: Shipped/Shipping (
>>> https://github.com/mozilla/gecko-dev/blob/44e39a47b27313029460bada366c67ebe6d7c57e/dom/webidl/SpeechSynthesis.webidl#L14)
>>> Gecko's IDL does not have [LegacyNoInterfaceObject] here, and
>>> SpeechSynthesis was shipped in Firefox 49:
>>> https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesis#browser_compatibility
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/WebKit/blob/56da0c5837801eb031c7506672cd7c40cbed4063/Source/WebCore/Modules/speech/SpeechSynthesis.idl#L27)
>>> WebKit developers were not consulted, the FIXME is taken as evidence that
>>> this change would be acceptable in WebKit as well.
>>>
>>> Web developers: No signals
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes: https://wpt.fyi/results/speech-api/idlharness.window.html
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1224942
>>>
>>> MDN links
>>> https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesis
>>> https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesisVoice
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/4818803819020288
>>>
>>> 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/CAARdPYdEZTQOoAr5L%3D1xpBzV7Z_L0M%2BzOrTyEdbT88uPtUPMnQ%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>>
>>
>> --
>> 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/CAGH7WqGmffB4z0XGUM2jr%2BArS6x63NViUkiW-tTT862yCJY6xg%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/b2e84308-e934-f321-26bb-0c3e33491507%40gmail

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

[Yoav Weiss]

On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman  wrote:

> Note: This intent email spans three Chromestatus entries for different
> sub-features that we experimented with together and would like permission
> to ship together in M121.
>
> Contact emailsjbro...@chromium.org, adith...@chromium.org,
> isabo...@google.com, dome...@chromium.org, mc...@chromium.org
>
> Explainerhttps://github.com/WICG/nav-speculation/blob/main/triggers.md
>
> Specificationhttps://wicg.github.io/nav-speculation/speculation-rules.html
>
> Summary
>
> (1) An extension to speculation rules syntax that lets the browser obtain
> URLs for speculation from link elements in a page. They may include
> criteria which restrict which of these links can be used.
>

Any specific parts of the explainer/spec that cover this one?


>
> (2) Adding the eagerness field to the speculation rules will let the
> developers control how eagerly the browser preloads links in order to
> balance the performance advantage against resource overhead. This field
> accepts one of "conservative", "moderate", "eager", or "immediate" strings
> as the value, and it is applicable to both "prefetch" and "prerender"
> actions and both "list" or "document" sources. If not explicitly specified,
> list rules default to "immediate" and document rules default to
> "conservative".
>
>
> (3) Currently developers can only specify speculation rules using inline
> script tags.  The proposed feature provides an alternative through the
> "Speculation-Rules" header. Its value must be a URL to a text resource with
> "application/speculationrules+json" MIME type. The resource's rules will be
> added to the document's rule set.
>
>
> Blink componentInternals>Preload
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/721
>
> TAG review statusIssues addressed (TAG still has reservations)
>
> Chromium Trial NameSpeculationRulesPrefetchFuture
>
> Link to origin trial feedback summary
> https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing
>
> Origin Trial documentation link
> https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md
>
> WebFeature UseCounter nameSpeculationRulesDocumentRules
> SpeculationRulesSelectorMatches
> SpeculationRulesHeader
> SpeculationRulesExplicitEagerness
>
> Risks
>
>
> Interoperability and Compatibility
>
> Because authors cannot rely on document rules being evaluated (or
> preloading generally), applications which use them should function
> correctly in other browsers and should continue to function correctly were
> the feature to be deprecated. Of course, ideally other browsers do find it
> compelling to implement this feature.
>
>
> Similar reasoning applies to the response header and eagerness field.
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/620)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/54)
>
> *Web developers*: Positive (
> https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
> positive feedback from Akamai and use within Chrome on web.dev
>
> *Other signals*:
>
> Activation
>
> Some developers might not be immediately aware of which URLs they can
> prefetch or prerender without side effects; this risk is reduced if they
> primarily use the feature for same-origin URL patterns they are familiar
> with.
>
>
> Security
>
> See
> https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
> .
>
>
> 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
>
> Speculative loading which occurs is visible in the Network panel and the
> new Preloading panel. Console warnings are logged when several types of
> issues are encountered.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes (though some
> capabilities vary per platform)
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/speculation-rules?label=experimental&label=master&aligned
> Some tests cover behavior which isn't enabled by default (even if
> experimental web platform features are on).
>
>
> Flag name on chrome://flags
>
> Finch feature nameSpeculationRulesPrefetchFuture
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1371522
> https://bugs.chromium.org/p/chromium/issues/detail?id=1406595
> https://bugs.chromium.org/p/chromium/issues/detail?id=1366940
>
> Estimated milestones
> Shipping on desktop 121
> OriginTrial desktop last 120
> OriginTrial desktop first 110
> Shipping on Android 121
> Origin

Re: [blink-dev] Intent to Ship: View Transitions: transition types

[Yoav Weiss]

LGTM1

On Thursday, November 9, 2023 at 7:05:57 PM UTC+1 Vladimir Levin wrote:



On Thu, Nov 9, 2023, 12:54 Mike Taylor  wrote:

On 11/8/23 3:53 PM, Vladimir Levin wrote:

Contact emails vmp...@chromium.org, nrosent...@chromium.org

Explainer https://github.com/vmpstr/web-proposals/blob/main/
explainers/view-transition-types.md 

Specification https://drafts.csswg.org/css-view-transitions-2/#the-
active-view-transition-pseudo

Summary 

This feature allows View transition API use to be customized for different 
types of transitions. Specifically, this adds an ability to add "types" to 
`startViewTransition` call which will identify the types of the transition. 
As well, it will match a pseudo-class, called `:active-view-transitions(...)` 
with a parameter matching the type for the duration of the view transition. 
Combined these two features provide a way for the author to declare several 
view transitions once and only trigger one at a time. See example usage in 
the spec: https://drafts.csswg.org/css-view-transitions-2/#the-
active-view-transition-pseudo

Blink component Blink>ViewTransitions>SPA 


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

TAG review status Pending

Risks 


Interoperability and Compatibility 

There are minimal interop and copmat risks. This feature is an extension to 
the View Transitions API that makes it more ergonomic to specify multiple 
transitions declaratively, while triggering only one of them at a time.


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


Gecko are now positive! 


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

*Web developers*: No (strong) signals, the feature request came from a web 
developer: https://github.com/w3c/csswg-drafts/issues/8960

*Other signals*:

Ergonomics 

This feature would be used with the View Transitions API to be able to 
easier maintain a declarative set of multiple transitions that can be 
triggered. This solution uses a descendant combinator heavily to 
selectively style elements in the DOM, but this is not any different from 
the polyfill approach of toggling a class on :root. 


Activation 

This feature can be used directly and fairly easily.


Security 

There are no additional security considerations over the View Transitions 
API.


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 feature is debuggable in the same way as the View Transitions API, and 
also in the same way as other CSS properties.


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 

? No

Any reason why?


Oops, that should say "Yes". I'll update chromestatus


Flag name on chrome://flags ViewTransitionTypes

Finch feature name ViewTransitionTypes

Requires code in //chrome? False

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

Estimated milestones Shipping on desktop 121 Shipping on Android 121 Shipping 
on WebView 121 

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

Links to previous Intent discussions Intent to prototype: https://groups.
google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NjgR_%2BTbJbU5O%
2BiyhnqxypDAUh7LWHUCWy%3DNnaBCY%2B1g%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/CADsXd2PckO%3DXSq8HDCy4foC_
Xj3Nh3dBxzSCkZ5GEyD%2BjdMcFQ%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

Re: [blink-dev] Intent to Ship: View Transitions: transition types

[Mike Taylor]

LGTM2

On 11/22/23 11:15 AM, Yoav Weiss wrote:

LGTM1

On Thursday, November 9, 2023 at 7:05:57 PM UTC+1 Vladimir Levin wrote:



On Thu, Nov 9, 2023, 12:54 Mike Taylor  wrote:

On 11/8/23 3:53 PM, Vladimir Levin wrote:


Contact emails vmp...@chromium.org, nrosent...@chromium.org


Explainer

https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-types.md




Specification

https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo



Summary

This feature allows View transition API use to be customized
for different types of transitions. Specifically, this adds
an ability to add "types" to `startViewTransition` call which
will identify the types of the transition. As well, it will
match a pseudo-class, called `:active-view-transitions(...)`
with a parameter matching the type for the duration of the
view transition. Combined these two features provide a way
for the author to declare several view transitions once and
only trigger one at a time. See example usage in the spec:

https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo




Blink component Blink>ViewTransitions>SPA



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


TAG review status Pending

Risks


Interoperability and Compatibility

There are minimal interop and copmat risks. This feature is
an extension to the View Transitions API that makes it more
ergonomic to specify multiple transitions declaratively,
while triggering only one of them at a time.



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



Gecko are now positive!



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

/Web developers/: No (strong) signals, the feature request
came from a web developer:
https://github.com/w3c/csswg-drafts/issues/8960


/Other signals/:

Ergonomics

This feature would be used with the View Transitions API to
be able to easier maintain a declarative set of multiple
transitions that can be triggered. This solution uses a
descendant combinator heavily to selectively style elements
in the DOM, but this is not any different from the polyfill
approach of toggling a class on :root.



Activation

This feature can be used directly and fairly easily.



Security

There are no additional security considerations over the View
Transitions API.



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 feature is debuggable in the same way as the View
Transitions API, and also in the same way as other CSS
properties.



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

?
No

Any reason why?


Oops, that should say "Yes". I'll update chromestatus



Flag name on chrome://flags ViewTransitionTypes

Finch feature name ViewTransitionTypes

Requires code in //chrome? False

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


Estimated milestones Shipping on desktop 121 Shipping on
Android 121 Shipping on WebView 121

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 nami

Re: [blink-dev] Intent to Ship: CSS font-palette property animation

[Yoav Weiss]

https://github.com/w3c/csswg-drafts/issues/8922#issuecomment-1720930646 
indicates that some parts of this were resolved and other parts are still 
to be bikeshedded.

Can you expand on that? What's the issue around color space interpolation?

On Thursday, November 9, 2023 at 4:02:34 PM UTC+1 moo...@google.com wrote:

> Submitted:
>
>- TAG review: https://github.com/w3ctag/design-reviews/issues/915
>- Requested signals from the other vendors:
>- Gecko: https://github.com/mozilla/standards-positions/issues/925 
>   - Webkit: https://github.com/WebKit/standards-positions/issues/276
>
> Thank you, Daniel!
>
> On Wed, Nov 8, 2023 at 4:52 PM Daniel Bratell  wrote:
>
>> Hi, could you please request signals from the other vendors? 
>> https://bit.ly/blink-signals will tell you how they work.
>>
>> Also, you may want to file a TAG review, or give them a FYI or let us 
>> know why that is not necessary.
>>
>> /Daniel
>> On 2023-11-08 13:56, 'Munira Tursunova' via blink-dev wrote:
>>
>> Contact emails moon...@google.com, dr...@google.com
>>
>> Explainer 
>> https://docs.google.com/document/d/1XMTrKH003KBOes6hxzI-3E7LTwp5YwFC-rnzoFpFrfw/edit?usp=sharing
>>
>> Specification https://drafts.csswg.org/css-fonts-4/#font-palette-prop
>>
>> Summary 
>>
>> The CSS font-palette property allows selection of a specific palette used 
>> to render a font. The CSS Fonts 4 spec defines the animation behavior of 
>> this property as discrete, which is insufficient to achieve a smooth 
>> transition between two selected palettes. Instead, animating the 
>> font-palette property should happen by interpolating each of the colour 
>> record values from the defined palette, i.e. if the start or the end of the 
>> animation has a different colour value for some record in the palette, such 
>> colour value should be interpolated.
>>
>>
>> Blink component Blink>Fonts 
>> 
>>
>> Search tags font-palette 
>> , animation 
>> , transition 
>> , font-palette-values 
>> , color fonts 
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> Low, new feature, was resolved by W3C working group 
>> https://github.com/w3c/csswg-drafts/issues/8922#issuecomment-1720930646, 
>> but not yet implemented in other browsers.
>>
>> *Gecko*: No signal Not implemented.
>>
>> *WebKit*: No signal Not implemented.
>>
>> *Web developers*: Positive (
>> https://css-tricks.com/colrv1-and-css-font-palette-web-typography/#:~:text=Another%20limitation%3A%20animations%20and%20transitions%20from%20one%20font%2Dpalette%20to%20another%20don%E2%80%99t%20interpolate%20%E2%80%94%20meaning%20you%20can%20switch%20instantly%20from%20one%20palette%20to%20another%2C%20but%20can%E2%80%99t%20gradually%20animate%20between%20them.%20My%20dream%20of%20a%20luridly%20animated%20emoji%20font%20is%20sadly%20unrealized)
>>  
>> Ollie Williams expressed his interest in the feature in his article on CSS 
>> Tricks. Scott Kellum (of typetura.com) has also been suggesting it as a 
>> useful feature for the web (origin: a Twitter thread and email 
>> conversation, Scott in the meantime deleted their Twitter account).
>>
>> *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 
>>
>> Same as any other CSS property, font-palette property is inspectable in 
>> DevTools.
>>
>>
>> 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-fonts/palette-mix-computed.html 
>> https://wpt.fyi/results/css/css-fonts/animations/font-palette-interpolation.html
>>
>>
>> Flag name on chrome://flags FontPaletteAnimation
>>
>> Finch feature name None
>>
>> Non-finch justification None
>>
>> Requires code in //chrome? False
>>
>> Tracking bug 
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1400620
>>
>> Sample links 
>> https://drafts.csswg.org/css-fonts-4/images/nabla-animated.webp
>>
>> Estimated milestones 
>> Shipping on desktop 121 
>> DevTrial on desktop 119 
>> Shipping on Android 121 
>> DevTrial on Android 119 
>> Shipping on WebView 121 
>>
>> 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 issue

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

[Jeremy Roman]

On Wed, Nov 22, 2023 at 11:10 AM Yoav Weiss  wrote:

>
>
> On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman 
> wrote:
>
>> Note: This intent email spans three Chromestatus entries for different
>> sub-features that we experimented with together and would like permission
>> to ship together in M121.
>>
>> Contact emailsjbro...@chromium.org, adith...@chromium.org,
>> isabo...@google.com, dome...@chromium.org, mc...@chromium.org
>>
>> Explainerhttps://github.com/WICG/nav-speculation/blob/main/triggers.md
>>
>> Specification
>> https://wicg.github.io/nav-speculation/speculation-rules.html
>>
>> Summary
>>
>> (1) An extension to speculation rules syntax that lets the browser obtain
>> URLs for speculation from link elements in a page. They may include
>> criteria which restrict which of these links can be used.
>>
>
> Any specific parts of the explainer/spec that cover this one?
>

Sure:
https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules
https://wicg.github.io/nav-speculation/speculation-rules.html#document-rule-predicate-matching
https://wicg.github.io/nav-speculation/speculation-rules.html#find-matching-links


>> (2) Adding the eagerness field to the speculation rules will let the
>> developers control how eagerly the browser preloads links in order to
>> balance the performance advantage against resource overhead. This field
>> accepts one of "conservative", "moderate", "eager", or "immediate" strings
>> as the value, and it is applicable to both "prefetch" and "prerender"
>> actions and both "list" or "document" sources. If not explicitly specified,
>> list rules default to "immediate" and document rules default to
>> "conservative".
>>
>>
>> (3) Currently developers can only specify speculation rules using inline
>> script tags.  The proposed feature provides an alternative through the
>> "Speculation-Rules" header. Its value must be a URL to a text resource with
>> "application/speculationrules+json" MIME type. The resource's rules will be
>> added to the document's rule set.
>>
>>
>> Blink componentInternals>Preload
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/721
>>
>> TAG review statusIssues addressed (TAG still has reservations)
>>
>> Chromium Trial NameSpeculationRulesPrefetchFuture
>>
>> Link to origin trial feedback summary
>> https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing
>>
>> Origin Trial documentation link
>> https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md
>>
>> WebFeature UseCounter nameSpeculationRulesDocumentRules
>> SpeculationRulesSelectorMatches
>> SpeculationRulesHeader
>> SpeculationRulesExplicitEagerness
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Because authors cannot rely on document rules being evaluated (or
>> preloading generally), applications which use them should function
>> correctly in other browsers and should continue to function correctly were
>> the feature to be deprecated. Of course, ideally other browsers do find it
>> compelling to implement this feature.
>>
>>
>> Similar reasoning applies to the response header and eagerness field.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/620)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/54)
>>
>> *Web developers*: Positive (
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
>> positive feedback from Akamai and use within Chrome on web.dev
>>
>> *Other signals*:
>>
>> Activation
>>
>> Some developers might not be immediately aware of which URLs they can
>> prefetch or prerender without side effects; this risk is reduced if they
>> primarily use the feature for same-origin URL patterns they are familiar
>> with.
>>
>>
>> Security
>>
>> See
>> https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
>> .
>>
>>
>> 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
>>
>> Speculative loading which occurs is visible in the Network panel and the
>> new Preloading panel. Console warnings are logged when several types of
>> issues are encountered.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes (though some
>> capabilities vary per platform)
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>>
>> https://wpt.fyi/results/speculation-rules?label=experimental&label=master&aligned
>> Some tests cover behavior which isn't enabled by default (even if
>> experimental web platform features are on).
>>
>>
>> Flag name on chr

[blink-dev] Re: High Contrast Black mode in Chrome under Linux

['Jakub Pawlik' via blink-dev]

Hi,

I'm hoping to get in touch with someone who can provide some guidance on 
the issue. I'm still locked out and would really appreciate some help 
getting this resolved.
If you know anyone who might help please let me know.

Thanks!

On Wednesday, November 15, 2023 at 5:46:22 PM UTC Jakub Pawlik wrote:

> Hi Blink Dev Team,
>
> I hope you are doing well. I'm writing to follow up on the case I 
> described in my previous email, since I haven't received any response.
> I was wondering if you had the opportunity to take a look at it?
> I would appreciate any advice you can provide on this matter.
>
> Thank you in advance for your time.
>
> Best regards,
> Jakub
>
> On Mon, Nov 13, 2023 at 1:19 PM Jakub Pawlik  wrote:
>
>> Hello Blink Dev Team!
>>
>> I’m reaching out to the Google Web Accessibility Team. I’d like to ask 
>> your team for help with an issue I’ve been struggling to find a solution 
>> for.
>> I’m trying to find a way to emulate high contrast black (HCB) mode in web 
>> tests running under Linux using the Chrome browser.
>>
>> What I would like to achieve is a high contrast black mode, which 
>> normally I can easily activate in Dev Tools UI in the Rendering tab by 
>> activating "prefers-color-scheme: dark" and "forced-colors: active".
>> [image: image.png]
>> It would be great to know a set of command line flags that I can pass 
>> while opening Chrome so that it activates the same mode as by setting 
>> prefers-color-scheme and forced-colors via the UI.
>>
>> I have tried to achieve this using the following flags:
>> --force-high-contrast
>> --enable-features=ForcedColors
>> --blink-settings=preferredColorScheme=0,forceDarkModeEnabled=true
>> However, this does not give the desired effect.
>>
>> I would be very grateful for any advice on this.
>>
>> Thanks a lot in advance and regards!
>> Jakub Pawlik
>>
>

-- 
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/debd2594-eaf0-4cf0-a787-4e4cb47708b5n%40chromium.org.

Re: [blink-dev] Re: High Contrast Black mode in Chrome under Linux

[Mike Taylor]

Hi Jakub (moving blink-dev to bcc),

Let me reach out off-list to see if I can help connect the dots.

thanks,
Mike

On 11/22/23 11:59 AM, 'Jakub Pawlik' via blink-dev wrote:

Hi,

I'm hoping to get in touch with someone who can provide some guidance 
on the issue. I'm still locked out and would really appreciate some 
help getting this resolved.

If you know anyone who might help please let me know.

Thanks!

On Wednesday, November 15, 2023 at 5:46:22 PM UTC Jakub Pawlik wrote:

Hi Blink Dev Team,

I hope you are doing well. I'm writing to follow up on the case I
described in my previous email, since I haven't received any
response.
I was wondering if you had the opportunity to take a look at it?
I would appreciate any advice you can provide on this matter.

Thank you in advance for your time.

Best regards,
Jakub

On Mon, Nov 13, 2023 at 1:19 PM Jakub Pawlik 
wrote:

Hello Blink Dev Team!

I’m reaching out to the Google Web Accessibility Team. I’d
like to ask your team for help with an issue I’ve been
struggling to find a solution for.
I’m trying to find a way to emulate high contrast black (HCB)
mode in web tests running under Linux using the Chrome browser.

What I would like to achieve is a high contrast black mode,
which normally I can easily activate in Dev Tools UI in the
Rendering tab by activating "prefers-color-scheme: dark" and
"forced-colors: active".
image.png
It would be great to know a set of command line flags that I
can pass while opening Chrome so that it activates the same
mode as by setting prefers-color-scheme and forced-colors via
the UI.

I have tried to achieve this using the following flags:
--force-high-contrast
--enable-features=ForcedColors
--blink-settings=preferredColorScheme=0,forceDarkModeEnabled=true
However, this does not give the desired effect.

I would be very grateful for any advice on this.

Thanks a lot in advance and regards!
Jakub Pawlik

--
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/debd2594-eaf0-4cf0-a787-4e4cb47708b5n%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/4066686e-5b85-4c80-842e-84ee7869ca75%40chromium.org.