Re: [blink-dev] Re: Intent to Experiment: COOP: restrict-properties

['Arthur Hemery' via blink-dev]

Couldn't fit in everything we wanted in 107 so moving again to 108-112

On Tue, Aug 9, 2022 at 2:12 PM Arthur Hemery  wrote:

> Implementation work was delayed, we're now targeting 107-111.
>
> On Wed, Jul 27, 2022 at 11:45 PM Lia Martinez 
> wrote:
>
>> Mira tú Arturo como te llames pendejo de mierda deja de estar mandado
>> mensajes a este número ya le pegue su putisa a esta pura por inrespetosa
>> todos usted que pantera que verga vallan a chingar así pura madre pedaso de
>> mierda enfermos sexuales
>>
>> El mié., 27 jul. 2022 9:20, Mike Taylor 
>> escribió:
>>
>>> LGTM to experiment from M106 to M110.
>>>
>>> On 7/27/22 9:00 AM, 'Arthur Hemery' via blink-dev wrote:
>>>
>>> Please note that a TAG issue was just filed:
>>> https://github.com/w3ctag/design-reviews/issues/760
>>>
>>> On Tue, Jul 26, 2022 at 4:59 PM Arthur Hemery 
>>> wrote:
>>>
 Contact emails ahem...@chromium.org

 Explainer
 https://github.com/hemeryar/explainers/blob/main/coop_restrict_properties.md

 Specification https://github.com/whatwg/html/issues/6364

 Summary

 Cross-Origin-Opener-Policy is used to sever the relationship between
 popup and openers, to increase security. "restrict-properties" is a
 proposed value that restricts the relationship instead of completely
 severing it. It would enable crossOriginIsolated when paired with COEP.


 Blink component Blink>SecurityFeature>COOP
 

 Search tags COOP ,
 restrict-properties
 


 Risks


 Interoperability and Compatibility

 It could fail to become an interoperable part of the web platform if
 other browsers do not implement it. The OT is intended to gather user
 feedback to get support from Mozilla.


 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*: Have a few partners interested in trying this out
 like Zoom and Facebook, as well as at least one internal partner (altimin@
 for perfetto dashboards).

 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?


 Goals for experimentation

 The goal for this experiment is to give partners the possibility to try
 the new value at scale and to discover potential deployment blockers that
 were not anticipated (e.g. external dependency, same-origin communications
 required, etc.)

 Debuggability

 COOP reporting will support restricted cross-origin properties
 reporting, similar to what exists for other COOP values.

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

 COOP is parsed on all platforms, but the process model implied might
 vary.


 Is this feature fully tested by web-platform-tests
 
 ? Yes under
 wpt/html/cross-origin-opener-policy/tentative/restrict-properties.

 Flag name
 --enable-features='CoopRestrictProperties'

 Requires code in //chrome? False

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

 Launch bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=1347385

 Estimated milestones
 OriginTrial desktop last 110
 OriginTrial desktop first 106
 OriginTrial Android last 110
 OriginTrial Android first 106


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

 Links to previous Intent discussions Intent to prototype:
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF07A2Uw-Oh0d7ktTPnV%3D8TTrr%2BNcTgfiLxzFd2P2QLD18qNsw%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/CAF07A2Uj8%3DeUzcs8-o4RxAJnJN8%2BGCpPZNY3ky5Y88-UvhFtiA%40mail.gmail.com
>>> 
>>> .
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic

Re: [blink-dev] Re: Intent to Experiment: User Agent Reduction Origin Trial

[Nir M]

Hi Mike, 
Nir from Meta and Noah's peer.

would it be possible to give an estimate or a guideline on the permissible 
magnitude of usage for the Opt-In trial (the one that forces the full 
reduction of the UserAgent) available? 
As we would like to conduct an experiment on that, and not deviate from the 
0.5% restriction of global page loads, we need an idea of how many users 
will be able to be getting this experimental behavior.
would love to hear more details on that if you could provide. 

Link to the limitation reference on Origin-Trial: 
https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md#6-is-there-any-restriction-on-which-websites-can-sign-up-to-use-experimental-features



thanks, 
Nir


On Tuesday, July 26, 2022 at 9:27:20 PM UTC+3 mike...@chromium.org wrote:

> Hi Noah,
>
> Thanks for reaching out - we've received a request just yesterday from 
> another partner who also expressed interest in an extension, so I will work 
> on an Intent to Extend Experiment in the next few days and we'll see what 
> the Blink API Owners think. :)
>
> thanks,
> Mike
>
> On 7/26/22 1:40 PM, Noah Lemen wrote:
>
> Are there any plans to extend this Origin Trial? We (Meta) are considering 
> using it to test the impact of UA reduction, but just noticed that its "end 
> date" is tomorrow, and was marked with availability ending after version 
> 103.
> On Thursday, October 14, 2021 at 5:29:45 PM UTC-4 abe...@chromium.org 
> wrote:
>
>> Just an FYI, the blog post has been updated to give instructions on how 
>> to participate in the User-Agent Reduction Origin Trial as a third-party 
>> embed: 
>> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/#how-to-participate-in-the-origin-trial-as-a-third-party-embed
>>
>> On Tue, Sep 14, 2021 at 9:39 AM Ali Beyad  wrote:
>>
>>> A blog post just went out for this OT: 
>>> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/
>>>
>>> On Thu, Aug 12, 2021 at 9:47 AM Ali Beyad  wrote:
>>>
 An update on this: it will be too rushed to get the User-Agent 
 Reduction OT into the M94 branch cutoff (this Thursday), so we moved this 
 OT for the M95 release.

 On Wed, Aug 11, 2021 at 4:02 PM Ali Beyad  wrote:

> An update on this: it will be too rushed to get the User-Agent 
> Reduction OT into the M94 branch cutoff (this Thursday), so we moved this 
> OT for the M95 release.
>
> On Thu, Jul 15, 2021 at 6:39 PM Ali Beyad  wrote:
>
>> Thanks for the feedback and the LGTMs, everyone!
>>
>> On Thu, Jul 15, 2021 at 6:30 PM Rick Byers  
>> wrote:
>>
>>> I agree this OT is quite different from a regular OT, there's not 
>>> really a "burn-in risk" to be worried about since this isn't really 
>>> about 
>>> any new functionality sites want access to. So LGTM3 for a longer 
>>> trial. 
>>>
>>> If necessary I'd also be supportive of expanding usage limits 
>>> arbitrarily. The more usage we can get of this trial, the lower the 
>>> compat 
>>> risk will be of making the breaking change later. So in this case it 
>>> makes 
>>> no sense to worry about excessive usage of the OT. 
>>>
>>> I'm glad to hear the inherited JS semantics will match that of the 
>>> header. Like for the header, I'd otherwise be worried about masking 
>>> potential compat issues if that JS APIs were unaffected.
>>>
>>> Rick
>>>
>>> On Thu, Jul 15, 2021 at 11:18 AM Ali Beyad  
>>> wrote:
>>>


 On Thu, Jul 15, 2021 at 4:02 AM Mike West  
 wrote:

> Thanks for the clarifications, Ali. This looks pretty reasonable 
> to me. LGTM1 % the below:
>
> I would recommend that you adjust the design doc to remove the 
> reference to "a client hint token that will reduce the User-Agent 
> header", 
> as it doesn't sound like that's what you're aiming to experiment 
> with. My 
> understanding of your response is that you'll only adjust the UA in 
> the 
> presence of the Origin Trial token.
>

 I updated 
 
  
 the design doc to make the point clear that the UA will only be 
 reduced in 
 the presence of the OT token, and I clarified the role of the new 
 client 
 hint in all this.  Thanks for the feedback!
  

>
> With regard to the OT schedule, ~6 months from M94 would take us 
> more or less through M100. In 
> https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/dhfejxAtj84/m/vr889GowAgAJ,
>  
> we agreed (but I don't think documented... I'll fix that) that we'd 
> be 
> taking ~4 milestones as a typical OT length as 

[blink-dev] PSA: runtime_enabled_features.json5 improvements

[TAMURA, Kent]

** blink::WebRuntimeFeatures methods generation*

You can generate methods of blink::WebRuntimeFeatures for a feature entry
in runtime_enabled_features.json5 by adding `public: true,`.

** base::Feature generation*

You can generate a base::Feature instance in blink::features namespace for
a feature entry in runtime_enabled_features.json5 by adding `base_feature: "
*feature-name*",`.

You can't use it for a base::Feature not in blink::features.

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


-- 
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/CAGH7WqEYU-6yXomZa%2BAp31SypGK0nH4%2BuqXYYfeAsq%2BxT-BWtQ%40mail.gmail.com.

[blink-dev] Intent to Prototype: Last Baseline Item Alignment

[Ian Kilpatrick]

Contact emailsikilpatr...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-align-3/#baseline-rules

Summary

This feature allows developers to align items within either flex or grid
layout by their last baseline, instead of their first. This is done via the
following properties: align-items: last baseline; /* flex/grid container */
justify-items: last baseline; /* grid container */ align-self: last
baseline; /* flex/grid item */ justify-self: last baseline; /* grid item */


Blink componentBlink>Layout


Motivation

Currently in Blink we only support aligning grid/flex-items via. their
first baseline. This feature allows web developers to align these items by
their last baseline.
We previously supported *parsing* of these values, however disabled due to
lack of layout support. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=885175#c4

This intent does not cover the "align-content: last baseline" feature.

Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



*Gecko*: Shipping (
https://developer.mozilla.org/en-US/docs/Web/CSS/align-items)

*WebKit*: Supports parsing of the property value - but doesn't currently
support these in layout.

*Web developers*: No signals

*Other signals*:

WebView application risks

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

No.



Debuggability

This will show up as a valid value for these properties. A potential
devtools feature would be to display where these baselines appear for each
fragment.

Is this feature fully tested by web-platform-tests

?No. There are some WPT tests however they are incomplete (e.g. lack
detailed testing). We'll add additional tests in the css-grid/css-flexbox
directories as we implement.
There are multiple outstanding spec issues which we'll work through while
implementing this feature. E.g.
https://github.com/w3c/csswg-drafts/issues/7660
https://github.com/w3c/csswg-drafts/issues/7656
https://github.com/w3c/csswg-drafts/issues/7655
https://github.com/w3c/csswg-drafts/issues/7641
https://github.com/w3c/csswg-drafts/issues/7639

Flag name
Likely --enable-blink-features=CSSLastBaseline will be available under
--experimental-web-platform-features

Requires code in //chrome?False

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

Estimated milestones

Likely M108

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

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/CAJL3UpT5eVmfB6e-adc8exG1ouse25C_0A_2tn3fEVTwh-SetQ%40mail.gmail.com.

[blink-dev] Re: Intent to Prototype: Isolated Web Apps

[Hyojin Song]

This would be quite required for webOS platform as well, so I 
proposed https://github.com/WICG/isolated-web-apps/pull/6.
I'm wondering if there is any major consideration or difficulty to be 
discussed with other stakeholders in this subject.

On Tuesday, April 26, 2022 at 1:13:35 AM UTC+9 sligh...@chromium.org wrote:

> This is incredibly exciting. Congrats on getting this design to a place 
> where it can be implemented.
>
>
>
> On Monday, April 18, 2022 at 2:48:28 PM UTC-7 Reilly Grant wrote:
>
>> Contact emails
>>
>> rei...@chromium.org, pjmcl...@chromium.org
>>
>> Explainer
>>
>> https://github.com/reillyeon/isolated-web-apps/blob/main/README.md
>>
>> Specification
>>
>> Still at the explainer stage.
>>
>> Summary
>>
>> Isolated Web Apps extend Progressive Web App 
>>  installation and Web Packaging 
>> to provide stronger protection against server compromise and other 
>> tampering.  A small set of security-sensitive applications require this to 
>> migrate from Chrome Apps, Electron, or other web-adjacent solutions.
>>
>> Rather than being hosted on live web servers and fetched over HTTPS, 
>> these applications are packaged into Web Bundles, signed by their 
>> developer, and distributed to end-users through one or more of the 
>> potential methods described in the explainer.
>>
>> Blink component
>>
>> UI>Browser>WebAppInstalls>Isolated (component request filed 
>> )
>>
>> Motivation
>>
>> Content Security Policy (CSP) provides strong protection against 
>> cross-site scripting (XSS) vulnerabilities. Transport Layer Security (TLS) 
>> and Subresource Integrity (SRI) provide protection against resources being 
>> tampered with in transit or when hosted on third-party servers. However, 
>> the threat model for some particularly security sensitive applications 
>> includes the main application server itself being compromised and serving 
>> malicious content. This goes beyond the protections that current policies 
>> can provide and requires exploring alternative ways that these applications 
>> could be distributed and validated.
>>
>> TAG review
>>
>> Not yet filed.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: No signals on this proposal but we’ve seen concerned 
>> developers looking for solutions in this space. See the explainer for 
>> details.
>>
>> 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?
>>
>> As this concept only applies to installed web applications it won’t be 
>> available in WebViews.
>>
>>
>> Debuggability
>>
>> For the most part all the existing features to support debugability of 
>> PWAs and Web Bundles will apply. However, we are considering adding 
>> additional diagnostic messages to help developers understand when their 
>> application is misbehaving due to the stricter policies.
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>>
>> No, web application installation is a //chrome concept which can’t be 
>> exercised by web-platform-tests. Browser test infrastructure is in 
>> isolated_app_test_utils.h 
>> 
>> .
>>
>> Flag name
>>
>> Developers can add an origin to --isolated-app-origins to enable 
>> isolation when installing a web app. Eventually this will support a real 
>> “developer mode” more similar to how Extensions development works.
>>
>> Requires code in //chrome?
>>
>> Yes, while much of the implementation will live in Blink and //content 
>> the web app installation infrastructure is implemented in //chrome. 
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5146307550248960
>>
>> This intent message was generated by Chrome Platform Status 
>> .
>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome 
>> 
>>
>

-- 
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/e2b03073-fb6d-4252-91d3-299c3933919cn%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: PaymentInstruments

[Mike Taylor]

Hi Rouslan,

Usage is indeed low - do we have any reason to believe there are 
consumers of this API who have disabled telemetry, i.e. maybe in 
enterprise contexts? And do we know how these few sites who are using 
the API... are using the API? Does any real-world usage show up in HTTP 
Archive?


thanks,
Mike

On 9/14/22 8:55 AM, Chris Harrelson wrote:

LGTM1

On Wed, Sep 14, 2022 at 8:05 AM Rouslan Solomakhin 
 wrote:



Contact emails

rous...@chromium.org, smcgr...@chromium.org



Summary

PaymentInstruments

is the Web API that backs non-JIT install of payment apps (see
https://w3c.github.io/payment-handler/). It was designed with the
assumption that the browser would store the actual payment
instrument details, which has not turned out to be true, and has
some privacy leaks. It also has not shipped on any other browser,
not have we seen any interest from other browser vendors. As such,
we are interested in deprecating and removing the API.


Blink component

Blink>Payments




Motivation

The PaymentInstruments.set() method allows an attacker website to
store arbitrary data, which can later be retrieved via
PaymentInstruments.get() potentially in a third-party context. For
example, the user visits https://tracker.example, which generates
and stores a UUID for that user via PaymentInstruments.set(key,
UUID). Later, the user visits https://site.example, which opens an
iframe for https://tracker.example. That iframe calls
PaymentInstruments.get(key) and can retrieve the UUID, thus
allowing https://tracker.example to know which user it is. Given
the lack of uptake in PaymentInstruments.set(), versus the more
common JIT-install path, as well as the overly powerful nature of
the API, we propose to remove PaymentInstruments entirely.
(PaymentInstruments was designed with the belief that the browser
would know about individual payment methods (e.g., credit cards)
rather than payment apps, hence the need to store/retrieve
arbitrary information.)


TAG review status

Not applicable


Risks


Interoperability and Compatibility

/Gecko/: Does not implement the Payment Handler API.
/WebKit/: Does not implement the Payment Handler API.
/Web developers/: No signals

/Other signals/:  Metrics of API usage show little to no uptake (<
0.00010 % page loads)
PaymentInstruments -
https://chromestatus.com/metrics/feature/timeline/popularity/4229
PaymentInstruments.clear -
https://chromestatus.com/metrics/feature/timeline/popularity/4230
PaymentInstruments.delete -
https://chromestatus.com/metrics/feature/timeline/popularity/4231
PaymentInstruments.get -
https://chromestatus.com/metrics/feature/timeline/popularity/4232
PaymentInstruments.has -
https://chromestatus.com/metrics/feature/timeline/popularity/4233
PaymentInstruments.keys -
https://chromestatus.com/metrics/feature/timeline/popularity/4234
PaymentInstruments.set -
https://chromestatus.com/metrics/feature/timeline/popularity/4235


WebView application risks

Payment Handler API is not implemented in WebView.


Debuggability

Standard DevTools debugging.


Is this feature fully tested by web-platform-tests

?

Yes -
https://wpt.fyi/results/payment-handler/payment-instruments.https.html


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1327265


Launch bug

https://crbug.com/1363633


Estimated milestones

Would like to remove in M108.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5099285054488576

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/CAMMzaWGzus%3DU48U06m-gk7_2G6Wnhn59UJXLi9xW9uz5%2BEWQuA%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+un

Re: [blink-dev] Intent to ship: Sec-CH-Prefers-Reduced-Motion client hint header

[Yoav Weiss]

On Sunday, September 11, 2022 at 7:20:45 AM UTC+2 fbea...@google.com wrote:

> On Fri, Sep 9, 2022 at 5:49 PM Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Sep 9, 2022 at 4:21 PM 'Thomas Steiner' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> fbeauf...@chromium.org, to...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md
>>>
>>> Specification
>>>
>>>
>>> https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-motion
>>>
>>
>> It seems worthwhile to properly specify that the hints in question are 
>> high-entropy hints that are not sent without an opt-in.
>> Based on https://github.com/WebKit/standards-positions/issues/15, it 
>> doesn't seem like that is clear.
>>
>
> Thank you!
> I've updated the spec to make it clear. See 
> https://github.com/WICG/user-preference-media-features-headers/pull/7
>

Thanks, but that doesn't define that the hint is a high entropy one.
Talking to Mike Taylor, it seems we can improve the CH Infra spec to make 
it clearer that any hint that's not low-entropy is a high entropy hint.
Then your spec can get that definition for free.


>  
>
>>  
>>
>>>
>>> API spec
>>>
>>> Yes
>>>
>>> Summary
>>>
>>> The Sec-CH-Prefers-Reduced-Motion client hint is modeled after the 
>>> prefers-reduced-motion user preference media feature as defined in 
>>> Media Queries Level 5. This headers follows Sec-CH-Prefers-Color-Scheme, 
>>> which was described in 
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/tEZ4RVsP1ms. 
>>>
>>> Blink component
>>>
>>> Blink>CSS
>>>
>>> Motivation
>>>
>>> CSS media queries, and specifically user preference media features like 
>>> prefers-reduced-motion, have a potentially significant impact on the 
>>> amount of CSS that needs to be delivered by a page, and on the experience 
>>> the user is going to have when the page loads.
>>>
>>> It is a best practice to not load CSS responsible for animations in the 
>>> critical rendering path if the user prefers reduced motion, but to instead 
>>> only load said CSS if the user doesn't mind motion. One way of doing so is 
>>> via . However, high-traffic sites like Google Search that 
>>> wish to honor user preference media features like prefers-reduced-motion 
>>> and that inline CSS for performance reasons, need to know about the motion 
>>> preferences (or other user preference media features respectively) ideally 
>>> at request time, so that the initial HTML payload already has the right CSS 
>>> inlined.
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/632 
>>>
>>> TAG review status
>>>
>>> Unsatisfied
>>>
>>> Demo link
>>>
>>> https://sec-ch-prefers-reduced-motion.glitch.me/
>>>
>>> Debuggability
>>>
>>> Developers can change the Sec-CH-Prefers-Reduced-Motion client hint 
>>> header value by emulating motion preferences via DevTools in the Rendering 
>>> panel like they can do with the Sec-CH-Prefers-Color-Scheme client hint 
>>> header today.
>>>
>>> Measurement
>>>
>>> The kClientHintsPrefersReducedMotion WebFeature tracks 
>>> Sec-CH-Prefers-Reduced-Motion client hint usage.
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>> There are no particular compatibility risks.
>>>
>>> Interoperability is still pending on other browser vendors replying. 
>>> Support for Client Hints in general is not enthusiastic though.
>>>
>>>
>>> Signals from other implementations (Gecko, WebKit): 
>>>
>>> Gecko: Pending (
>>> https://github.com/mozilla/standards-positions/issues/526)
>>>
>>> WebKit: Pending (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031856.html, now 
>>> migrated to https://github.com/WebKit/standards-positions/issues/15) 
>>>
>>> Web / Framework developers: Positive (WICG proposal Issue: 
>>> https://github.com/WICG/proposals/issues/30 with feedback from 
>>> developers working for Facebook 
>>>  
>>> and Magento 
>>> . 
>>> Twitter: https://twitter.com/kilianvalkhof/status/1392404416335056896. 
>>> The proposal was initially discussed in 
>>> https://github.com/w3c/csswg-drafts/issues/4162 and received positive 
>>> feedback via 16 Likes and 3 supportive comments: 
>>> https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-621047333, 
>>> https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-631400330, 
>>> and 
>>> https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-645742958). 
>>> Google Search is interested in this header, too.
>>>
>>> Ergonomics:
>>>
>>> N/A
>>>
>>> Activation:
>>>
>>> Developers will include Sec-CH-Prefers-Reduced-Motion in the response 
>>> headers Accept-CH and Critical-CH to let the browser know that they’re 
>>> interested in the motion preferences. If supported, the request header 
>>> Sec-CH-Prefers-Reduced-Motion will be populated with 

Re: [blink-dev] Intent to Ship: AudioContext.setSinkId()

[Hongchan Choi]

The original proposal didn't work out well because of the type confusion in
the union (DOMString or AudioSinkCategory) - they are both DOMString in the
end. So we are considering two options:
https://github.com/WebAudio/web-audio-api/issues/2400#issuecomment-1239704445

There's no disagreement. We just need to make a decision, and that is
planned during this TPAC.

Let me know if you have any questions!

Thanks,
Hongchan


On Wed, Sep 14, 2022 at 8:43 AM Yoav Weiss  wrote:

>
>
> On Tuesday, September 13, 2022 at 4:16:15 PM UTC+2 ajayra...@google.com
> wrote:
>
>> Please let us know of any other questions, concerns or observations.
>>
>> Thanks in advance.
>>
>> -Ajay
>>
>> On Wednesday, August 31, 2022 at 2:54:14 PM UTC-7 Ajay Rahatekar wrote:
>>
>>> We have filed requests for position. Please see below:
>>>
>>> Mozilla: https://github.com/mozilla/standards-positions/issues/683
>>> Webkit: https://github.com/WebKit/standards-positions/issues/53
>>>
>>> On Wed, Aug 31, 2022 at 8:54 AM Chris Harrelson 
>>> wrote:
>>>
>> Thanks for filing the TAG review. Could you also file for official
 positions from Mozilla and Webkit also? Thanks. I'm sure you're right about
 Mozilla, but they've requested going through the process in the past for
 other intents.

 On Wed, Aug 31, 2022 at 8:08 AM Hongchan Choi 
 wrote:

>>> 1. Yes. The lack of implementation is one issue, but the relationship
> between selectAudioOutput() and Web Audio API is not really specified or
> documented.
> 2. Since AudioElement.setSinkId() has been used for years, we believe
> it makes more sense to use the same pattern for its low-level counterpart 
> -
> Web Audio API's AudioContext. This approach is more specific and focused.
>
>
> On Tue, Aug 30, 2022 at 10:46 PM Philipp Hancke <
> philipp...@googlemail.com> wrote:
>
 the ID of the sink needs to be obtained from
>> navigator.mediaDevices.enumerateDevices because
>> https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/selectAudioOutput
>> is not implemented anywhere?
>>
>> Am Di., 30. Aug. 2022 um 19:02 Uhr schrieb 'Ajay Rahatekar' via
>> blink-dev :
>>
> Contact emails
>>>
>>> hong...@chromium.org, alv...@chromium.org, mjwi...@chromium.org
>>>
>>> Explainer
>>>
>>> None
>>>
>>> Specification
>>>
>>> https://github.com/WebAudio/web-audio-api/pull/2498
>>>
>>
> The PR hasn't landed yet, and Mozilla's (positive) position states that
> there are some details to be determined still.
> Can you expand on that? What's holding the PR from landing?
>
>
>>> Summary
>>>
>>> AudioContext.setSinkId sets the ID of the audio device to use for
>>> output. This allows the AudioElement to route audio to a connected 
>>> output
>>> device of user's choosing.
>>>
>>>
>>> Blink component
>>>
>>> Blink>WebAudio
>>> 
>>>
>>> TAG review
>>>
>>> This is a small API change within Web Audio API. The WG was advised
>>> that this is too small for the TAG review.
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: Positive (
>>> https://github.com/WebAudio/web-audio-api/issues/2400) Mozilla is
>>> co-developing the spec change.
>>>
>>> WebKit: No signal
>>>
>>> Web developers: Positive (
>>> https://github.com/WebAudio/web-audio-api/issues/2400) Many
>>> developers chimed in the spec issue and the implementation crbug entry (
>>> crbug.com/1216187). Also several partners expressed the need for
>>> this API. We have not seen any negative feedback on this.
>>>
>>> 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 adds a new method to AudioContext; the WebIDL change will be
>>> addressed by the DevTools automatically.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows,
>>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes
>>>
>>> This is a part of Web Audio API, which is available on all platforms.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes. The WPT will be added for this feature.
>>>
>>> Flag name
>>>
>>> –enable-blink-features=AudioContextSetSinkId
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://crbug.com

Re: [blink-dev] Intent to Deprecate and Remove: PaymentInstruments

[Chris Harrelson]

LGTM1

On Wed, Sep 14, 2022 at 8:05 AM Rouslan Solomakhin 
wrote:

> Contact emailsrous...@chromium.org, smcgr...@chromium.org
>
> Summary
>
> PaymentInstruments
>  is
> the Web API that backs non-JIT install of payment apps (see
> https://w3c.github.io/payment-handler/). It was designed with the
> assumption that the browser would store the actual payment instrument
> details, which has not turned out to be true, and has some privacy leaks.
> It also has not shipped on any other browser, not have we seen any interest
> from other browser vendors. As such, we are interested in deprecating and
> removing the API.
>
> Blink componentBlink>Payments
> 
>
> Motivation
>
> The PaymentInstruments.set() method allows an attacker website to store
> arbitrary data, which can later be retrieved via PaymentInstruments.get()
> potentially in a third-party context. For example, the user visits
> https://tracker.example, which generates and stores a UUID for that user
> via PaymentInstruments.set(key, UUID). Later, the user visits
> https://site.example, which opens an iframe for https://tracker.example.
> That iframe calls PaymentInstruments.get(key) and can retrieve the UUID,
> thus allowing https://tracker.example to know which user it is. Given the
> lack of uptake in PaymentInstruments.set(), versus the more common
> JIT-install path, as well as the overly powerful nature of the API, we
> propose to remove PaymentInstruments entirely. (PaymentInstruments was
> designed with the belief that the browser would know about individual
> payment methods (e.g., credit cards) rather than payment apps, hence the
> need to store/retrieve arbitrary information.)
>
> TAG review statusNot applicable
>
> Risks
> Interoperability and Compatibility*Gecko*: Does not implement the Payment
> Handler API.
> *WebKit*: Does not implement the Payment Handler API.
> *Web developers*: No signals
>
> *Other signals*:  Metrics of API usage show little to no uptake (<
> 0.00010 % page loads)
> PaymentInstruments -
> https://chromestatus.com/metrics/feature/timeline/popularity/4229
> PaymentInstruments.clear -
> https://chromestatus.com/metrics/feature/timeline/popularity/4230
> PaymentInstruments.delete -
> https://chromestatus.com/metrics/feature/timeline/popularity/4231
> PaymentInstruments.get -
> https://chromestatus.com/metrics/feature/timeline/popularity/4232
> PaymentInstruments.has -
> https://chromestatus.com/metrics/feature/timeline/popularity/4233
> PaymentInstruments.keys -
> https://chromestatus.com/metrics/feature/timeline/popularity/4234
> PaymentInstruments.set -
> https://chromestatus.com/metrics/feature/timeline/popularity/4235
>
> WebView application risksPayment Handler API is not implemented in
> WebView.
>
>
> Debuggability
>
> Standard DevTools debugging.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> Yes -
> https://wpt.fyi/results/payment-handler/payment-instruments.https.html
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1327265
>
> Launch bughttps://crbug.com/1363633
>
> Estimated milestones
>
> Would like to remove in M108.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5099285054488576
>
> 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/CAMMzaWGzus%3DU48U06m-gk7_2G6Wnhn59UJXLi9xW9uz5%2BEWQuA%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/CAOMQ%2Bw8_gN61x4ijCz_Dz433Lf8B-Vbi0rrtKjUFnXJ1Lw__SQ%40mail.gmail.com.

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

[Mike Taylor]

LGTM3

On 9/14/22 8:37 AM, Yoav Weiss wrote:

LGTM2 with the above plan, assuming printing sticks.

On Wednesday, September 14, 2022 at 5:36:11 PM UTC+2 Chris Harrelson 
wrote:


Printing NG looks like it will ship in M108.

LGTM1 to ship MathML in M109 (just in case there is an issue that
causes printing to be reverted).

On Mon, Aug 8, 2022 at 12:25 PM Daniel Herr
 wrote:

There are some new css properties included in MathML, correct?
Then one possibility for feature detection could be to provide
developers the ability to use CSS @supports inside print media
stylesheets to determine whether MathML is available in that
context.


@supports (display: math) { /* or other MathML property */
  /* not applied in Chromium */
}


@supports (display: math) { /* or other MathML property */
  /* applied in Chromium and other browsers */
}

On Friday, July 8, 2022 at 2:54:36 PM UTC-4 Neil Soiffer wrote:

I don't mean to diminish the importance of print -- I'm
old enough that I /occasionally /print things out.
However, the situation now is that neither display nor
print of MathML works natively in Chromium. In turning on
MathML display, 99.99% (or more?) people will be happy to
have fast display of math; some small number of people
won’t be happy when they try to print it out.

For that group and the publishers that put out material
that tests whether MathML is available in the browser,
this would be a regression. It would be interesting to
know if any sites sniff for MathML support, or whether
they simply look at the browser and decide based on their
knowledge of support. I know of at least one site that
does the latter and so they wouldn’t suffer a regression.
Maybe all the sites do this because it is easy and
reliable? Even if there is no regression, please don't put
printing math on the back burner in terms of priorities.

Benjamin mentioned Wikipedia. I can’t speak for what
Wikipedia would do, but as long as they know that printing
is broken in Chromium, any decision to turn on direct
MathML rendering is their call, not Chromium’s. I suspect
given their concern that Wikipedia renders properly almost
everywhere, it will be a long time before they make a
switch. Right now, despite Firefox’s long support for
MathML, they still use SVG with hidden MathML on it.

On the supposition that there are some sites that sniff
for MathML, I think Benjamin’s suggestions are good. I
don’t know how feasible it is to put up a dialog stating
that printing math is not currently supported in Chromium,
but doing that with some suggested workarounds would I
think be a viable alternative until print is supported.
One workaround would be to suggest they download an
extension (that would need to be written) that loads
MathJax into the page in question when clicked. Another
suggestion could be to read the page with Firefox ;-). I’m
sure there are many more clever people on this list than I
am who might have other suggestions for workarounds.

My suggestion is to follow the somewhat worn out but still
very true trope: "don't let perfect be the enemy of the
good". People have been waiting years and years to get
math to display natively in Chromium and now it is ready
to happen. Please try to find a simple stopgap and get
this long awaited feature turned on.

-- 


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/cc2a4fab-823d-467f-949e-385a150fa5fen%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/260d7448-c8cf-4503-99bb-8918bda112bbn%40chromium.org 

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 CO

Re: [blink-dev] Intent to Ship: AudioContext.setSinkId()

[Yoav Weiss]

On Tuesday, September 13, 2022 at 4:16:15 PM UTC+2 ajayra...@google.com 
wrote:

> Please let us know of any other questions, concerns or observations. 
>
> Thanks in advance.
>
> -Ajay
>
> On Wednesday, August 31, 2022 at 2:54:14 PM UTC-7 Ajay Rahatekar wrote:
>
>> We have filed requests for position. Please see below:
>>
>> Mozilla: https://github.com/mozilla/standards-positions/issues/683
>> Webkit: https://github.com/WebKit/standards-positions/issues/53
>>
>> On Wed, Aug 31, 2022 at 8:54 AM Chris Harrelson  
>> wrote:
>>
> Thanks for filing the TAG review. Could you also file for official 
>>> positions from Mozilla and Webkit also? Thanks. I'm sure you're right about 
>>> Mozilla, but they've requested going through the process in the past for 
>>> other intents.
>>>
>>> On Wed, Aug 31, 2022 at 8:08 AM Hongchan Choi  
>>> wrote:
>>>
>> 1. Yes. The lack of implementation is one issue, but the relationship 
 between selectAudioOutput() and Web Audio API is not really specified or 
 documented.
 2. Since AudioElement.setSinkId() has been used for years, we believe 
 it makes more sense to use the same pattern for its low-level counterpart 
 - 
 Web Audio API's AudioContext. This approach is more specific and focused.


 On Tue, Aug 30, 2022 at 10:46 PM Philipp Hancke <
 philipp...@googlemail.com> wrote:

>>> the ID of the sink needs to be obtained from 
> navigator.mediaDevices.enumerateDevices because 
> https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/selectAudioOutput
>  
> is not implemented anywhere?
>
> Am Di., 30. Aug. 2022 um 19:02 Uhr schrieb 'Ajay Rahatekar' via 
> blink-dev :
>
 Contact emails
>>
>> hong...@chromium.org, alv...@chromium.org, mjwi...@chromium.org 
>>
>> Explainer
>>
>> None
>>
>> Specification
>>
>> https://github.com/WebAudio/web-audio-api/pull/2498
>>
>
The PR hasn't landed yet, and Mozilla's (positive) position states that 
there are some details to be determined still.
Can you expand on that? What's holding the PR from landing?


>> Summary
>>
>> AudioContext.setSinkId sets the ID of the audio device to use for 
>> output. This allows the AudioElement to route audio to a connected 
>> output 
>> device of user's choosing.
>>
>>
>> Blink component
>>
>> Blink>WebAudio 
>> 
>>
>> TAG review
>>
>> This is a small API change within Web Audio API. The WG was advised 
>> that this is too small for the TAG review.
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Positive (
>> https://github.com/WebAudio/web-audio-api/issues/2400) Mozilla is 
>> co-developing the spec change.
>>
>> WebKit: No signal
>>
>> Web developers: Positive (
>> https://github.com/WebAudio/web-audio-api/issues/2400) Many 
>> developers chimed in the spec issue and the implementation crbug entry (
>> crbug.com/1216187). Also several partners expressed the need for 
>> this API. We have not seen any negative feedback on this.
>>
>> 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 adds a new method to AudioContext; the WebIDL change will be 
>> addressed by the DevTools automatically.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, 
>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> This is a part of Web Audio API, which is available on all platforms.
>>
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>>
>> Yes. The WPT will be added for this feature.
>>
>> Flag name
>>
>> –enable-blink-features=AudioContextSetSinkId
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://crbug.com/1355977
>>
>> Launch bug
>>
>> https://crbug.com/1216187
>>
>> Estimated milestones
>>
>> 108
>>
>>
>> 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 e

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

[Yoav Weiss]

LGTM2 with the above plan, assuming printing sticks.

On Wednesday, September 14, 2022 at 5:36:11 PM UTC+2 Chris Harrelson wrote:

> Printing NG looks like it will ship in M108.
>
> LGTM1 to ship MathML in M109 (just in case there is an issue that causes 
> printing to be reverted).
>
> On Mon, Aug 8, 2022 at 12:25 PM Daniel Herr  
> wrote:
>
>> There are some new css properties included in MathML, correct? Then one 
>> possibility for feature detection could be to provide developers the 
>> ability to use CSS @supports inside print media stylesheets to determine 
>> whether MathML is available in that context.
>>
>> 
>> @supports (display: math) { /* or other MathML property */
>>   /* not applied in Chromium */
>> }
>>
>> 
>> @supports (display: math) { /* or other MathML property */
>>   /* applied in Chromium and other browsers */
>> }
>>
>> On Friday, July 8, 2022 at 2:54:36 PM UTC-4 Neil Soiffer wrote:
>>
>>> I don't mean to diminish the importance of print -- I'm old enough that 
>>> I *occasionally *print things out. However, the situation now is that 
>>> neither display nor print of MathML works natively in Chromium. In turning 
>>> on MathML display, 99.99% (or more?) people will be happy to have fast 
>>> display of math; some small number of people won’t be happy when they try 
>>> to print it out.
>>>
>>> For that group and the publishers that put out material that tests 
>>> whether MathML is available in the browser, this would be a regression. It 
>>> would be interesting to know if any sites sniff for MathML support, or 
>>> whether they simply look at the browser and decide based on their knowledge 
>>> of support. I know of at least one site that does the latter and so they 
>>> wouldn’t suffer a regression. Maybe all the sites do this because it is 
>>> easy and reliable? Even if there is no regression, please don't put 
>>> printing math on the back burner in terms of priorities.
>>>
>>> Benjamin mentioned Wikipedia. I can’t speak for what Wikipedia would do, 
>>> but as long as they know that printing is broken in Chromium, any 
>>> decision to turn on direct MathML rendering is their call, not Chromium’s. 
>>> I suspect given their concern that Wikipedia renders properly almost 
>>> everywhere, it will be a long time before they make a switch. Right now, 
>>> despite Firefox’s long support for MathML, they still use SVG with hidden 
>>> MathML on it.
>>>
>>> On the supposition that there are some sites that sniff for MathML, I 
>>> think Benjamin’s suggestions are good. I don’t know how feasible it is to 
>>> put up a dialog stating that printing math is not currently supported in 
>>> Chromium, but doing that with some suggested workarounds would I think be a 
>>> viable alternative until print is supported. One workaround would be to 
>>> suggest they download an extension (that would need to be written) that 
>>> loads MathJax into the page in question when clicked. Another suggestion 
>>> could be to read the page with Firefox ;-). I’m sure there are many more 
>>> clever people on this list than I am who might have other suggestions for 
>>> workarounds.
>>>
>>> My suggestion is to follow the somewhat worn out but still very true 
>>> trope: "don't let perfect be the enemy of the good". People have been 
>>> waiting years and years to get math to display natively in Chromium and now 
>>> it is ready to happen. Please try to find a simple stopgap and get this 
>>> long awaited feature turned on.
>>>
>> -- 
>>
> 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/cc2a4fab-823d-467f-949e-385a150fa5fen%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/260d7448-c8cf-4503-99bb-8918bda112bbn%40chromium.org.

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

[Chris Harrelson]

Printing NG looks like it will ship in M108.

LGTM1 to ship MathML in M109 (just in case there is an issue that causes
printing to be reverted).

On Mon, Aug 8, 2022 at 12:25 PM Daniel Herr 
wrote:

> There are some new css properties included in MathML, correct? Then one
> possibility for feature detection could be to provide developers the
> ability to use CSS @supports inside print media stylesheets to determine
> whether MathML is available in that context.
>
> 
> @supports (display: math) { /* or other MathML property */
>   /* not applied in Chromium */
> }
>
> 
> @supports (display: math) { /* or other MathML property */
>   /* applied in Chromium and other browsers */
> }
>
> On Friday, July 8, 2022 at 2:54:36 PM UTC-4 Neil Soiffer wrote:
>
>> I don't mean to diminish the importance of print -- I'm old enough that I 
>> *occasionally
>> *print things out. However, the situation now is that neither display
>> nor print of MathML works natively in Chromium. In turning on MathML
>> display, 99.99% (or more?) people will be happy to have fast display of
>> math; some small number of people won’t be happy when they try to print it
>> out.
>>
>> For that group and the publishers that put out material that tests
>> whether MathML is available in the browser, this would be a regression. It
>> would be interesting to know if any sites sniff for MathML support, or
>> whether they simply look at the browser and decide based on their knowledge
>> of support. I know of at least one site that does the latter and so they
>> wouldn’t suffer a regression. Maybe all the sites do this because it is
>> easy and reliable? Even if there is no regression, please don't put
>> printing math on the back burner in terms of priorities.
>>
>> Benjamin mentioned Wikipedia. I can’t speak for what Wikipedia would do,
>> but as long as they know that printing is broken in Chromium, any
>> decision to turn on direct MathML rendering is their call, not Chromium’s.
>> I suspect given their concern that Wikipedia renders properly almost
>> everywhere, it will be a long time before they make a switch. Right now,
>> despite Firefox’s long support for MathML, they still use SVG with hidden
>> MathML on it.
>>
>> On the supposition that there are some sites that sniff for MathML, I
>> think Benjamin’s suggestions are good. I don’t know how feasible it is to
>> put up a dialog stating that printing math is not currently supported in
>> Chromium, but doing that with some suggested workarounds would I think be a
>> viable alternative until print is supported. One workaround would be to
>> suggest they download an extension (that would need to be written) that
>> loads MathJax into the page in question when clicked. Another suggestion
>> could be to read the page with Firefox ;-). I’m sure there are many more
>> clever people on this list than I am who might have other suggestions for
>> workarounds.
>>
>> My suggestion is to follow the somewhat worn out but still very true
>> trope: "don't let perfect be the enemy of the good". People have been
>> waiting years and years to get math to display natively in Chromium and now
>> it is ready to happen. Please try to find a simple stopgap and get this
>> long awaited feature turned on.
>>
> --
> 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/cc2a4fab-823d-467f-949e-385a150fa5fen%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/CAOMQ%2Bw_TJC2bLMwq9EaJh%2BJ5Ki6fhuAQ-LgLRQErYdSp%3DTg7Eg%40mail.gmail.com.

[blink-dev] Intent to Deprecate and Remove: PaymentInstruments

[Rouslan Solomakhin]

Contact emailsrous...@chromium.org, smcgr...@chromium.org

Summary

PaymentInstruments
 is
the Web API that backs non-JIT install of payment apps (see
https://w3c.github.io/payment-handler/). It was designed with the
assumption that the browser would store the actual payment instrument
details, which has not turned out to be true, and has some privacy leaks.
It also has not shipped on any other browser, not have we seen any interest
from other browser vendors. As such, we are interested in deprecating and
removing the API.

Blink componentBlink>Payments


Motivation

The PaymentInstruments.set() method allows an attacker website to store
arbitrary data, which can later be retrieved via PaymentInstruments.get()
potentially in a third-party context. For example, the user visits
https://tracker.example, which generates and stores a UUID for that user
via PaymentInstruments.set(key, UUID). Later, the user visits
https://site.example, which opens an iframe for https://tracker.example.
That iframe calls PaymentInstruments.get(key) and can retrieve the UUID,
thus allowing https://tracker.example to know which user it is. Given the
lack of uptake in PaymentInstruments.set(), versus the more common
JIT-install path, as well as the overly powerful nature of the API, we
propose to remove PaymentInstruments entirely. (PaymentInstruments was
designed with the belief that the browser would know about individual
payment methods (e.g., credit cards) rather than payment apps, hence the
need to store/retrieve arbitrary information.)

TAG review statusNot applicable

Risks
Interoperability and Compatibility*Gecko*: Does not implement the Payment
Handler API.
*WebKit*: Does not implement the Payment Handler API.
*Web developers*: No signals

*Other signals*:  Metrics of API usage show little to no uptake (< 0.00010
% page loads)
PaymentInstruments -
https://chromestatus.com/metrics/feature/timeline/popularity/4229
PaymentInstruments.clear -
https://chromestatus.com/metrics/feature/timeline/popularity/4230
PaymentInstruments.delete -
https://chromestatus.com/metrics/feature/timeline/popularity/4231
PaymentInstruments.get -
https://chromestatus.com/metrics/feature/timeline/popularity/4232
PaymentInstruments.has -
https://chromestatus.com/metrics/feature/timeline/popularity/4233
PaymentInstruments.keys -
https://chromestatus.com/metrics/feature/timeline/popularity/4234
PaymentInstruments.set -
https://chromestatus.com/metrics/feature/timeline/popularity/4235

WebView application risksPayment Handler API is not implemented in WebView.


Debuggability

Standard DevTools debugging.


Is this feature fully tested by web-platform-tests

?
Yes - https://wpt.fyi/results/payment-handler/payment-instruments.https.html

Requires code in //chrome?False

Tracking bughttps://crbug.com/1327265

Launch bughttps://crbug.com/1363633

Estimated milestones

Would like to remove in M108.

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

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/CAMMzaWGzus%3DU48U06m-gk7_2G6Wnhn59UJXLi9xW9uz5%2BEWQuA%40mail.gmail.com.