[blink-dev] Re: Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

2024-07-01 Thread Yoav Weiss (@Shopify) 


On Tuesday, July 2, 2024 at 12:38:50 AM UTC+2 Mason Freed wrote:

Contact emailsmas...@chromium.org, andr...@chromium.org

Specificationhttps://github.com/w3c/csswg-drafts/issues/10395#
issuecomment-2192127524

Summary

The CSSWG resolved to rename this property, because "fallbacks" more 
accurately describes what this property controls. The word "options" is a 
bit deceiving, since the styles outside of `position-try` blocks will be 
tested first, and if they result in a layout that fits within the 
containing block, none of the "options" will get used. So "fallbacks" is a 
better word to describe this behavior. https://github.com/w3c/csswg-
drafts/issues/10395#issuecomment-2192127524


Blink componentBlink>CSS 


Search tagsanchor positioning 


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This is a name change, which will result in the old name no longer 
functioning. So there is a risk of breakage. However, the anchor 
positioning feature was very recently shipped, and does not have 
implementation in other browsers. So we feel the risk is quite small 
currently, but will grow over time. Given that, we'd like to rename this 
property ASAP to avoid the risk getting too large. The use counter is 
currently quite low, around 0.01% in June: https://chromestatus.com/
metrics/css/timeline/popularity/784 An HTTP Archive search was performed, 
which showed that almost all usage comes from one Shopify CSS file 
(`spec-and-compare.css`), and we intend to reach out to Shopify (or hope 
for a response from one very special Blink API owner) to make sure this 
will not break Shopify.


"very special" :)

It seems like the source of usage is this 3P 
app: https://apps.shopify.com/spec-compare
I'll send you their contact email so that you can reach out to them 
directly.

Can you share the HTTP Archive analysis? Manual inspection of the hosts 
listed in the chromestatus counter didn't reveal much on my end.

Beyond that, I think this would require an intent and maybe a short 
deprecation period. Even if the only source is this single app, unless the 
breakage is insignificant, we'd need at least one release overlap between 
the new and the old values, to avoid a breakage period while users are 
upgrading from Chromium N to N+1.



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

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

None


Debuggability

None


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

Is this feature fully tested by web-platform-tests 

?Yes

https://wpt.fyi/results/css/css-anchor-position


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/349600667

Estimated milestonesShipping on desktop128Shipping on Android128Shipping on 
WebView128

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 Statushttps://chromestatus.com/
feature/5167414571696128?gate=5182169462079488

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/cf8a8c9d-9efa-4bff-9dd5-590809fe2877n%40chromium.org.

[blink-dev] Ready for Developer Testing: Intl.DurationFormat

2024-07-01 Thread Frank Tang 
Contact emailsft...@google.com

Explainerhttps://github.com/tc39/proposal-intl-duration-format

Specificationhttps://tc39.es/proposal-intl-duration-format

Design docs
https://docs.google.com/document/d/1UMwkeeiqVyVNhNW8CS1vwN9g2cIH0AryaU16DT-vGg0/edit

Summary

Intl.DurationFormat API is a TC39 ECMA402 proposal See
https://github.com/tc39/proposal-intl-duration-format for the proposal The
proposal advanced to Stage 3 on 2021-10 Spec:
https://tc39.es/proposal-intl-duration-format/


Blink componentBlink>JavaScript>Internationalization


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The spec is sync with Temporal . If Temporal dramatically change the
definition of Temporal Duration, we may need to adjust the implemetation


*Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1648139)

*WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=214794)
https://developer.apple.com/documentation/safari-release-notes/safari-16_4-release-notes

*Web developers*: Positive (https://github.com/tc39/ecma402-mdn/issues/22)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DurationFormat

*Other signals*:

Ergonomics

Temporal.Duration as defined in
https://tc39.es/proposal-temporal/#sec-temporal-maximumtemporaldurationroundingincrement


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?

low


Goals for experimentation



Ongoing technical constraints

None


Debuggability



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

Is this feature fully tested by web-platform-tests

?Yes

https://github.com/tc39/test262/issues/3305


Flag name on chrome://flagsharmony_intl_duration_format

Finch feature nameNone

Non-finch justification

v8


Requires code in //chrome?False

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

MeasurementUse Count CL is under review in
https://chromium-review.googlesource.com/c/chromium/src/+/5646725

Availability expectationFeature is available on Web Platform mainline
within 6 months of launch in Chrome.

Adoption expectationFeature is considered a best practice for some use case
within 6 months of reaching Web Platform baseline.

Adoption planintl dev team inside google will rewrite closure duration
format to use this feature with a thinner wrapper

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
The feature depend on ICU and therefore also CLDR project

Estimated milestones
DevTrial on desktop 128
DevTrial on Android 128

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).
https://github.com/tc39/proposal-intl-duration-format/issues

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL-vykLL8UDTG1QcKptGfyRPw8T6StP2%2BqMPFv09aUHPbg%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/CAOcELL_%2BO4nsuNmspoOr9fJx8YkV%2Bi1F%2BaNBvsLLGuriDBoGRA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Intl.DurationFormat

2024-07-01 Thread Domenic Denicola 
Hi Frank,

Can you use Chrome Status to generate an Intent to Ship email, and send
that? It appears instead you have copied and pasted the Chrome Status
webpage, which does not contain all the same information.

Thanks,
Domenic

On Tue, Jul 2, 2024 at 7:16 AM Frank Tang  wrote:

> https://chromestatus.com/feature/5193021205774336
>
>
> Intl.DurationFormat API is a TC39 ECMA402 proposal See
> https://github.com/tc39/proposal-intl-duration-format for the proposal
> The proposal advanced to Stage 3 on 2021-10 Spec:
> https://tc39.es/proposal-intl-duration-format/
> Motivation
>
> This TC39/ECMA402 proposal advanced to Stage 3 in Oct 2021. Users need all
> types of duration formatting depending on the requirements of their
> application. For example, to show how long a flight takes, the duration
> should be in Short or Narrow format "1 hr 40 min 60 sec" → Short "1h 40m
> 60s" → Narrow And such format are different in different locale. This API
> enacpsulate the details of such formatting and provide an unified API
> supporting multiple locales.
> Documentation
>
>- [image: icon]Intl.DurationFormat Design Doc
>
> 
>
> Specification
>
> https://tc39.es/proposal-intl-duration-format
>
> Spec status: Final published standard: Recommendation, Living Standard,
> Candidate Recommendation, or similar final form
> Status in Chromium
>
> Blink components: Blink>JavaScript>Internationalization
> 
>
> Implementation status: *No active development* tracking bug
> 
> Consensus & Standardization
> After a feature ships in Chrome, the values listed here are not guaranteed
> to be up to date.
>
>
>- Firefox:In development: [image: icon]1648139 - Implement
>Intl.DurationFormat
>
>- Safari:In development: [image: icon]214794 – [JSC] Implement
>Intl.DurationFormat 
>- Web Developers:Positive
>
> Owner
>
>- ft...@google.com
>
> Search tagsHistory
>
> Entry created on 2022-09-09 16:28:26 ( 2 years ago )
>
> Last updated on 2024-07-01 22:05:06 ( 6 minutes ago )
>
> All comments & activity
> 
>
>
>
> --
> 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/CAOcELL-sWzM%2B0F3M1Dod8phpu2W9GNaMabxSYqZRUFi-dQ%3DugA%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/CAM0wra8EzJUEan6heqTsmCcLLaLdftVxQG%3DEkB2xeR-7JaKgCw%40mail.gmail.com.

[blink-dev] Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

2024-07-01 Thread Mason Freed 
Contact emailsmas...@chromium.org, andr...@chromium.org

Specification
https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524

Summary

The CSSWG resolved to rename this property, because "fallbacks" more
accurately describes what this property controls. The word "options" is a
bit deceiving, since the styles outside of `position-try` blocks will be
tested first, and if they result in a layout that fits within the
containing block, none of the "options" will get used. So "fallbacks" is a
better word to describe this behavior.
https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524


Blink componentBlink>CSS


Search tagsanchor positioning


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This is a name change, which will result in the old name no longer
functioning. So there is a risk of breakage. However, the anchor
positioning feature was very recently shipped, and does not have
implementation in other browsers. So we feel the risk is quite small
currently, but will grow over time. Given that, we'd like to rename this
property ASAP to avoid the risk getting too large. The use counter is
currently quite low, around 0.01% in June:
https://chromestatus.com/metrics/css/timeline/popularity/784 An HTTP
Archive search was performed, which showed that almost all usage comes from
one Shopify CSS file (`spec-and-compare.css`), and we intend to reach out
to Shopify (or hope for a response from one very special Blink API owner)
to make sure this will not break Shopify.


*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

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

None


Debuggability

None


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

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/css/css-anchor-position


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/349600667

Estimated milestones
Shipping on desktop 128
Shipping on Android 128
Shipping on WebView 128

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/5167414571696128?gate=5182169462079488

This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjFGKppv77%2BXHZR-3L82LbroE_%2BPkmVrTooin0Tt5gAXA%40mail.gmail.com.

[blink-dev] Intent to Ship: Intl.DurationFormat

2024-07-01 Thread Frank Tang 
https://chromestatus.com/feature/5193021205774336


Intl.DurationFormat API is a TC39 ECMA402 proposal See
https://github.com/tc39/proposal-intl-duration-format for the proposal The
proposal advanced to Stage 3 on 2021-10 Spec:
https://tc39.es/proposal-intl-duration-format/
Motivation

This TC39/ECMA402 proposal advanced to Stage 3 in Oct 2021. Users need all
types of duration formatting depending on the requirements of their
application. For example, to show how long a flight takes, the duration
should be in Short or Narrow format "1 hr 40 min 60 sec" → Short "1h 40m
60s" → Narrow And such format are different in different locale. This API
enacpsulate the details of such formatting and provide an unified API
supporting multiple locales.
Documentation

   - [image: icon]Intl.DurationFormat Design Doc
   


Specification

https://tc39.es/proposal-intl-duration-format

Spec status: Final published standard: Recommendation, Living Standard,
Candidate Recommendation, or similar final form
Status in Chromium

Blink components: Blink>JavaScript>Internationalization


Implementation status: *No active development* tracking bug

Consensus & Standardization
After a feature ships in Chrome, the values listed here are not guaranteed
to be up to date.


   - Firefox:In development: [image: icon]1648139 - Implement
   Intl.DurationFormat
   
   - Safari:In development: [image: icon]214794 – [JSC] Implement
   Intl.DurationFormat 
   - Web Developers:Positive

Owner

   - ft...@google.com

Search tagsHistory

Entry created on 2022-09-09 16:28:26 ( 2 years ago )

Last updated on 2024-07-01 22:05:06 ( 6 minutes ago )

All comments & activity


-- 
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/CAOcELL-sWzM%2B0F3M1Dod8phpu2W9GNaMabxSYqZRUFi-dQ%3DugA%40mail.gmail.com.

[blink-dev] Re: Intent to Implement: GeometryUtils

2024-07-01 Thread 'Jochen Kühner' via blink-dev 
I found this old thread, cause I'm looking for an API wich I need in a 
designer. getBoxQuads would be exactly what I need.
It's sad it's not yet implemented, but the bigger issue, it is even not 
possible to polyfill. It would be possible for HTMLElement cause you could 
traverse back all elements and combine all Transformations and 
Positionings, and so you could calculate them, but it is not possible for 
SVG and MathML Elements, cause they are missing the offset... properties.
see my issue: https://github.com/w3c/csswg-drafts/issues/10514

I know, this thread is 8 years old, but maybe

act...@gmail.com schrieb am Mittwoch, 13. Juli 2016 um 22:21:32 UTC+2:

> And why not implemented?
>

-- 
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/2bddc293-05d0-4b06-9d0a-14a040a46aa2n%40chromium.org.

Re: [blink-dev] Fwd: Intent to Extend Experiment: Protected Audience Bidding & Auction Services

2024-07-01 Thread Mike Taylor 

I see - thanks for the info Paul. It seems like an unintentional mixup.

When I approved the previous extension I wrote: "I would like to see 
draft specifications and progress on making this testable via WPTs"


Russ thanks for linking to 
https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html 
- based on this draft PR 
. You wrote that it 
describes _some_ of the changes, can you speak to what is missing (that 
you will presumably spec ahead of an I2S)?


And thanks for beginning to land WPTs 
.


On 6/28/24 1:59 PM, Paul Jensen wrote:

Mike,

It looks like we did continue the OT during M122-124 before sending 
the first I2EE, despite initially only asking for approval for 
M119-121.  I wonder if someone went off of the current OT policy of 
"An initial origin trial or experiment for a feature may only run for 
6 milestones" 
 
without knowing my initial ask was for just 3 milestones.  I apologize 
for that and am going to seek updating internal processes to add a 
check to prevent this oversight from happening again, even if the 
initial I2EE is "fairly mechanical" as you said originally.


On Wednesday, June 26, 2024 at 1:53:56 PM UTC-4 Mike Taylor wrote:

Hi Russ,

I'm trying to refresh my memory on the history of this experiment.

Experiment first approved on 10/19/23 for M119 to M121,

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/BzI3_qoCAwAJ




Request on 4/4/24 to renew from M124 to M127,

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ




Approved 4/12/24 (“for another 3 milestones”),

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/Pm842qm_AAAJ




Requesting M127 to M130 on 6/20/24,

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/RigQFZilAgAJ




Question: what happened between M122 and M124? Was the experiment
not running?


On 6/20/24 2:52 PM, 'Russ Hamilton' via blink-dev wrote:

(Now *To* blink-dev instead of just CC)


Contact emails

pauljen...@chromium.org, behamil...@google.com


Explainer

Chrome:

https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md



Services:

https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md



Note that this explainer has a helpful onboarding section

for
setting up the services.


Specification

A work-in-progress pull request

on
the Protected Audience spec
describes some of the changes
to the W3C spec. We are reaching out to the IETF ART Area
Directors for assistance beginning the standardization process
for some of the server-side aspects of this API.


Summary

We propose extending the Bidding and Auction Services origin
trial currently operating on 1% stable.

Recent changes:

 *

Prompted by developer concerns about scalability, we have
recently added support in M127 for limiting the size of the
Bidding and Auction request payload

 *

We also added controls to enable sellers to select which
buyers are included in the payload when it doesn’t affect the
outwardly visible size of the encrypted data.

 *

Additionally the Bidding and Auction server has recently
added support for features such as buyerReportingId and bid
currency.

We have decided to extend the experiment to give developers time
to experiment with the new features. We would like to request
extending the end milestone from M127 to M130.


Blink component

Blink>InterestGroups




TAG review

For Protected Audience:
https://github.com/w3ctag/design-reviews/issues