[blink-dev] Intent to Implement and Ship

[Deepti Gandluri]

Contact emailsgdee...@chromium.org, z...@chromium.org, thiba...@chromium.org

Explainer
https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md

Specificationhttps://github.com/WebAssembly/relaxed-simd/tree/main/document

Summary

Relaxed SIMD extends the existing SIMD proposal to introduce vector
instructions that relax the strict determinism constraints of portable SIMD
to take better advantage of the underlying hardware. The operations
introduced in this proposal take advantage of widely available instruction
sets to accelerate compute workloads.

Blink componentBlink>JavaScript>WebAssembly


TAG reviewNot required as per: https://v8.dev/docs/feature-launch-process.
This introduces an additional set of vector operations to WebAssembly, and
makes no API changes.
Risks


Interoperability and Compatibility

*Gecko*: In development, enabled in nightly

*WebKit*: No signal as per request for position:
mail-archive.com/webkit-dev@lists.webkit.org/msg30574.html

*Web developers*: Strongly positive, Proposal in Phase 3 in the WebAssembly
CG the proposal was incubated to address some of the developer/user
requests from the previous SIMD proposal.

*Other signals*: Proposal voted to a provisional phase 4 as per meeting
notes in the February 14th CG meeting (notes:
https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-02-14.md).
The feature has consensus in the CG, but the vote is provisional till the
formal spec is up to date (Tracking issue:
https://github.com/WebAssembly/relaxed-simd/issues/134, PRs also in flight).

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

Supported instructions are enabled in Liftoff, and are visible to DevTools
for debuggability.


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

Is this feature fully tested by web-platform-tests

?Not applicable, tested by WebAssembly spec tests

Flag nameV8: --wasm-relaxed-simdChrome: Features::kWebAssemblyRelaxedSimd

Requires code in //chrome?False

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

Estimated milestones

114

Anticipated spec changes

No anticipated spec changes, but some potential for compat issues based on
hardware, more details in this Entropy.md
,
and the linked issues.

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

-- 
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/CALi9WK9bJKKMinnRGFw5PWQimoZBfHEcMjQ7CDOU4hdcWo%3DekQ%40mail.gmail.com.

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

[Traian Captan]

Thanks Daniel!


On Wed, Mar 8, 2023 at 2:39 PM Daniel Bratell  wrote:

> LGTM3 to ship image-set
>
> /Daniel
>
> On 2023-03-08 15:51, Manuel Rego Casasnovas wrote:
> > LGTM2
> >
> > Thank you very much for fixing the issues before shipping.
> >
> > On 08/03/2023 10:53, Yoav Weiss wrote:
> >> Even though wpt.fyi
> >> <
> https://wpt.fyi/results/css/css-images/image-set/image-set-computed.sub.html?label=experimental=master>
> is reddish, I'm seeing all the tests pass on ToT. Thank you!!
> > I guess that's because wpt.fyi is still using Chrome 112, when the last
> > patches have landed in 113.
> >
> > Cheers,
> >Rego
> >
>

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

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

[Daniel Bratell]

LGTM3 to ship image-set

/Daniel

On 2023-03-08 15:51, Manuel Rego Casasnovas wrote:

LGTM2

Thank you very much for fixing the issues before shipping.

On 08/03/2023 10:53, Yoav Weiss wrote:

Even though wpt.fyi

 is reddish, I'm seeing all the tests pass on ToT. Thank you!!

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

Cheers,
   Rego



--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c823b7e4-dd40-04db-7176-0f9a61bf4698%40gmail.com.

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

[Traian Captan]

Thanks Rego!


On Wed, Mar 8, 2023 at 6:51 AM Manuel Rego Casasnovas 
wrote:

> LGTM2
>
> Thank you very much for fixing the issues before shipping.
>
> On 08/03/2023 10:53, Yoav Weiss wrote:
> > Even though wpt.fyi
> > <
> https://wpt.fyi/results/css/css-images/image-set/image-set-computed.sub.html?label=experimental=master>
> is reddish, I'm seeing all the tests pass on ToT. Thank you!!
>
> I guess that's because wpt.fyi is still using Chrome 112, when the last
> patches have landed in 113.
>
> Cheers,
>   Rego
>

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

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

[Traian Captan]

Thanks Yoav!


On Wed, Mar 8, 2023 at 1:53 AM Yoav Weiss  wrote:

> My LGTM1 still stands! :)
>
> On Wed, Mar 8, 2023 at 8:40 AM Traian Captan  wrote:
>
>> Hi,
>>
>> Following the previous conversation, we worked on adding support for the
>> missing functionality that is currently described in the image-set spec
>> .
>>
>> Here is the updated intent:
>>
>> Contact emailstcap...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation
>>
>> Summary
>>
>> Unprefix -webkit-image-set to expose the current image-set functionality
>> without needing the '-webkit-' prefix, and add support for the
>> functionality currently described in the image-set spec.
>>
>>
>> Blink componentBlink
>> 
>>
>> Search tagsimage-set 
>>
>> TAG reviewSkipping because this is a straightforward interop fix.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The Interoperability Risk is Low. This change increases interop with
>> Gecko and WebKit which already support both '-webkit-' prefixed and
>> unprefixed image-set, and are also actively working on improving their
>> image-set implementations as part of Interop 2023 efforts. The
>> Compatibility Risk is Low.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)
>>
>> *WebKit*: Shipped/Shipping (
>> https://trac.webkit.org/changeset/202765/webkit)
>>
>> *Web developers*: Strongly positive This issue has been Starred by 55
>> users.
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>> Debuggability
>>
>>
>>
>> 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
>>
>
> Even though wpt.fyi
> 
> is reddish, I'm seeing all the tests pass on ToT. Thank you!!
>
>
>>
>> Flag nameCSSImageSet
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/630597
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5109745420075008
>>
>> Links to previous Intent discussionsIntent to Ship:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JXcRP4MJc9I
>>
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> Regards,
>> Traian
>>
>>
>> On Mon, Jan 23, 2023 at 2:57 PM Traian Captan 
>> wrote:
>>
>>> Thanks Noam!
>>>
>>> I'll add support for the other cases behind the feature flag and we'll
>>> ship it when we are "interoperable enough".
>>>
>>> Regards,
>>> Traian
>>>
>>>
>>> On Wed, Dec 14, 2022 at 6:41 AM Noam Rosenthal 
>>> wrote:
>>>


 On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas 
 wrote:

> If we have plans to fix issues on this feature later, why not fixing
> them before and then shipping when things look good?
>
> If we unprefix it, it'll kind of appear as a new Chromium feature that
> people can use, and they will expect it follows the spec.


 I agree, for example people might (wrongfully) rely on
 CSS.supports("background-image", "image-set(url(example.jpg) 1x)")
 to mean that the full set of image-set features is supported.
 I'm not sure people are more granular than that about feature detection
 but we probably have data about that.

 It might be wise to support the cases behind the prefix, and
 unprefix when the behavior is close to complete and interoperable enough.
 We don't need to rely on people posting bug reports when we know the
 issues today by looking at the WPT failures.

>>>

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

[blink-dev] Intent to Prototype: CapturedMouseEvent

['Elad Alon' via blink-dev]

Contact emailselada...@chromium.org

Explainerhttps://github.com/screen-share/mouse-events/blob/main/README.md

Specificationhttps://screen-share.github.io/mouse-events

Design document
https://docs.google.com/document/d/1FOvWG9WZlulMI9kEc5X0_sspqgdE28q3DFjeaHTmhGk/edit?usp=sharing=0-sQkZvVQUGk9uOkX37QDPYg

Summary

Web applications can use getDisplayMedia() to capture any display-surface -
tabs, windows or screens. When they do, they can also specify the cursor
constraint to control whether the cursor's pixels are captured or not. But
what if the application wishes to programmatically observe the location of
the cursor? That can be done by scanning each frame and employing
heuristics to detect the cursor. But that's neither simple, nor efficient,
nor robust. To that end, we define a mechanism for exposing mouse
coordinates over a captured surface to a capturing application.


Blink componentBlink>GetDisplayMedia


Motivation

Web applications can use getDisplayMedia() to capture any display-surface -
tabs, windows or screens. When they do, they can also specify the cursor
constraint to control whether the cursor's pixels are captured or not. But
what if the application wishes to programmatically observe the location of
the cursor? That can be done by scanning each frame and employing
heuristics to detect the cursor. But that's neither simple, nor efficient,
nor robust. To that end, we define a mechanism for exposing mouse
coordinates over a captured surface to a capturing application.


Initial public proposal
https://github.com/screen-share/meetings/blob/main/minutes/2023-02-16.md#exposing-mouse-coordinates

TAG reviewToo early; not yet sent.

TAG review statusPending

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Strongly positive (
https://github.com/screen-share/meetings/blob/main/minutes/2023-02-16.md#exposing-mouse-coordinates
)

*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



Is this feature fully tested by web-platform-tests

?No

Flag nameCapturedMouseEvent

Requires code in //chrome?False

Estimated milestones

No milestones specified


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

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/CAMO6jDOvS5XfO3oaJAUi7eg6QVE1H1iwuMovKbBVGOJx0Zp1NA%40mail.gmail.com.

[blink-dev] Re: Intent to Implement and Ship: WebUSB Interface Class Filtering

[Alexey Rodionov (Fluorescent Hallucinogen)]

Oh, I misread `getUserMedia` as `getDisplayMedia`. 臘‍♂️

четверг, 9 марта 2023 г. в 00:26:20 UTC+5, Reilly Grant: 

> On Wed, Mar 8, 2023 at 9:53 AM Alexey Rodionov (Fluorescent Hallucinogen) <
> fluorescent@gmail.com> wrote:
>
>> >  External cameras should be available through getUserMedia() on Android.
>>
>> Unfortunately, `getUserMedia()` doesn't work on Android. It's broken and 
>> crashes on Android 10+. See https://crbug.com/487935 for more info.
>>
>
> That issue is specific to screen capture and not cameras. It sounds like 
> the crash you are seeing is related to the unlaunched screen capture 
> feature. If you are seeing an issue with camera capture as well please file 
> a separate issue. 
>

-- 
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/2e34d49e-facb-4aba-80e6-29db5250fb73n%40chromium.org.

[blink-dev] Re: Intent to Implement and Ship: WebUSB Interface Class Filtering

[Reilly Grant]

On Wed, Mar 8, 2023 at 9:53 AM Alexey Rodionov (Fluorescent Hallucinogen) <
fluorescent.hallucino...@gmail.com> wrote:

> >  External cameras should be available through getUserMedia() on Android.
>
> Unfortunately, `getUserMedia()` doesn't work on Android. It's broken and
> crashes on Android 10+. See https://crbug.com/487935 for more info.
>

That issue is specific to screen capture and not cameras. It sounds like
the crash you are seeing is related to the unlaunched screen capture
feature. If you are seeing an issue with camera capture as well please file
a separate issue.

-- 
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/CAEmk%3DMYaZuNi-%3DwW29jGZG4th7Lteytf3wyGnHbhVfkFPZqvEQ%40mail.gmail.com.

[blink-dev] Re: Intent to Implement and Ship: WebUSB Interface Class Filtering

[Alexey Rodionov (Fluorescent Hallucinogen)]

>  External cameras should be available through getUserMedia() on Android.

Unfortunately, `getUserMedia()` doesn't work on Android. It's broken and 
crashes on Android 10+. See https://crbug.com/487935 for more info.

-- 
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/7d47f7a4-b473-4948-b3ea-3dfb6ca0bcd7n%40chromium.org.

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

[Yoav Weiss]

LGTM3

I wish we had a developer signal for this, but given we're following Gecko
here, that's not a blocker IMO.

On Wed, Mar 8, 2023 at 5:43 PM Rick Byers  wrote:

> Daniil, could you please file an issue on the spec saying that since it's
> in Firefox and now Chrome it should no longer be marked "at list"?
>
> Assuming so, LGTM2
>
> We discussed in API owners meeting that we don't need to block on
> standards positions in this case (Interop2023 feature) but will follow up
> off list to verify.
>
>
> On Wed, Mar 8, 2023 at 11:40 AM slightlyoff via Chromestatus <
> admin+slightly...@cr-status.appspotmail.com> wrote:
>
>> LGTM1
>>
>> --
>> 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/2c20d605f6662f73%40google.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY80%2BrZNaK4BOygwZCbJ8LYCCN4aiUo1veUygD71TUX3cg%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/CAL5BFfUa1UV8ah%2BKNUax8kvXOqOreJyC2%3DzK0HBF7uZYje8mdg%40mail.gmail.com.

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

[Yoav Weiss]

LGTM1 % filing a WebKit position

We discussed this intent at the API owner meeting (Rick, Chris, Daniel,
MikeT, Philip,, Alex and myself). We agreed that there's value in filing a
WebKit position issue here, if anything to put this on their radar (pun not
intended) and let them know we intend to ship this and that Gecko already
has.

I also wish we had some developer signal for this, but given the fact Gecko
already shipped, I won't block on it.

On Tue, Mar 7, 2023 at 12:37 PM Philip Jägenstedt 
wrote:

> I think this feature falls under Implementations of already-defined
> consensus-based standards
> 
> in our process, and Signals from other implementations in an
> intent-to-ship
> 
>  aren't
> part of that section.
>
> If this wasn't already shipped in Gecko I do agree with Alex that the spec
> status shouldn't carry a lot of weight and we should file standards
> positions, but I don't think our documented process backs up that
> preference.
>
> Anyway, this has already shipped in Gecko, and I don't think we need to
> file a standards position issue for WebKit.
>
> In other words, I'd be happy to LGTM this, but will abstain since Daniil
> is on my team.
>
> On Mon, Mar 6, 2023 at 6:49 PM Alex Russell 
> wrote:
>
>> Our history with the WebKit project suggests that imputations of implicit
>> consent are unwelcome, and so in addition to the general orientation of our
>> process towards explicit evidence, it is in the interest of respecting the
>> WebKitten's own preferences that we ask formally.
>>
>> Best,
>>
>> Alex
>>
>> On Friday, March 3, 2023 at 8:33:26 PM UTC-8 flo...@rivoal.net wrote:
>>
>>>
>>> On 4Mar 2023, at 5:59, Alex Russell  wrote:
>>>
>>> Our process does not pay much mind to arbitrary standards gates when
>>> others have not already shipped. If WebKit had (has?) implemented, that
>>> would shortcut our analysis, otherwise, it's still worth asking.
>>>
>>>
>>> The point is not about what the W3C Process say you can do at what
>>> stage, the point is that for a CSS spec to get to CR, there needs to be a
>>> sign off from the groups’ members that this is OK to ship. This is not as
>>> strong as “we want to ship this ourselves soon”, but this is stronger than
>>> “no signal”, as was stated earlier.
>>>
>>> This may be true in other groups, but it is especially true in the
>>> CSSWG, which includes all the browsers, and has an explicit policy that
>>> publishing something as a CR means we have consensus it is OK to ship it.
>>> https://www.w3.org/TR/css/#testing
>>>
>>> So my read of webkit’s position would be: “has indicated support for the
>>> feature being shipped in general, unclear when they intend to do so
>>> themselves”. It’s absolutely reasonable to ask webkit if you’re looking for
>>> something more firm that than (or more recent, or…), but I think it is
>>> worth noting you at least have that much.
>>>
>>> —Florian
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f709d52b-46ba-4390-b307-cda73990db1en%40chromium.org
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> 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/CAARdPYdxZ5_MvS-gB5mZKE8-zL8rr1FmH%2BghJwUR3iuQGjeiOA%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/CAL5BFfV5qJG%2BnyOnFNj9m3CikQCv-0T2EW1HCOofrhyXF1QURA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS headline balancing

[Philip Jägenstedt]

Hi Koji,

Looks like the tests are in
https://wpt.fyi/results/css/css-text/white-space?label=master=experimental=subtest=balance.
There's one failing test there, do you know why that is? And overall, are
you happy with the test coverage here, does it cover most important corner
cases?

Best regards,
Philip

On Sun, Mar 5, 2023 at 9:26 PM Tab Atkins Jr.  wrote:

> On Thu, Mar 2, 2023 at 6:59 PM fantasai 
> wrote:
> > On 3/2/23 17:48, Tab Atkins Jr. wrote:
> > > If you think there are specific issues that need to be fixed (that
> > > don't equally need to be fixed for text-wrap:wrap), could you list
> > > them?
> >
> > The 'text-wrap' property is a longhand of 'white-space'. If you don't
> > implement it as such, the way that 'text-wrap' and 'white-space'
> declarations
> > override each other will change if/when you do.
> >
> > This intent to ship just says that you will ship 'text-wrap'. It doesn't
> say
> > that you will also implement 'white-space-collapse' (the other longhand
> of
> > 'white-space') or the shorthanding relationship between 'text-wrap' and
> > 'white-space'. I therefore assume you're shipping 'text-wrap' as an
> > independent property, and this is not going to be spec-compatible.
>
> Koji will need to speak to this.
>
> > > We probably do want some type of control for orphan words, but it's an
> > > unrelated problem; *all* of the text-wrap options can want it. Likely
> > > it belongs in its own property.
> >
> > How is (a hypothetical) 'last-line-length: 100%' different from
> 'text-wrap:
> > balance'? If they're the same, does it make sense to have 'text-wrap:
> balance'?
>
> They're quite different. A balanced paragraph can very easily have the
> last line *not* fill 100% of the line box, because being balanced
> actually means averaging an 80% fill, for example; there's no way to
> predict what the ideal fill is in a whole-para balance. There's also
> perf concerns - a last-line control might very reasonably only try to
> adjust the last several lines, rather than the entire paragraph, so
> that it's generally usable on all text rather than just text short
> enough to be efficiently whole-para balanceable.
>
> ~TJ
>
> --
> 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/CAAWBYDAmKU3T-M-yyM5SywbSVj2iTUcdqWXCNSdSV6Xco3TGdw%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/CAARdPYdZTqRA5x2qpsBZq00Dzvv%3DW-y9cGT4UKxVZXKExfs0HA%40mail.gmail.com.

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

[Rick Byers]

Daniil, could you please file an issue on the spec saying that since it's
in Firefox and now Chrome it should no longer be marked "at list"?

Assuming so, LGTM2

We discussed in API owners meeting that we don't need to block on standards
positions in this case (Interop2023 feature) but will follow up off list to
verify.


On Wed, Mar 8, 2023 at 11:40 AM slightlyoff via Chromestatus <
admin+slightly...@cr-status.appspotmail.com> wrote:

> LGTM1
>
> --
> 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/2c20d605f6662f73%40google.com
> 
> .
>

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

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

[slightlyoff via Chromestatus]

LGTM1

-- 
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/2c20d605f6662f73%40google.com.

Re: [blink-dev] Intent to Ship: Support URLs with non-special schemes

[Mike Taylor]

Hi Jiacheng,

Friendly ping on Harald's and my questions. :)

thanks,
Mike

On 2/23/23 2:40 AM, Harald Alvestrand wrote:
Is there a blacklist of "special schemes" that this change won't 
touch? Who maintains that list?


This seems a bit dangerous, in that if a new scheme is deployed that 
is "special", code intended for handling non-special schemes will try 
to parse it.


Note that the term "special" in the URL specification 
(https://url.spec.whatwg.org/#special-scheme) refers strictly to ftp, 
file, http, https, ws and wss; there's nothing "special" about urn, 
turn, stun or any of the other standardized schemes that don't use the 
// syntax.





On Wed, Feb 22, 2023 at 5:08 PM Yoav Weiss  wrote:



On Wed, Feb 22, 2023 at 4:43 PM Mike Taylor
 wrote:


On 2/22/23 8:21 AM, 'Jiacheng Guo' via blink-dev wrote:



Contact emails

g...@google.com


Explainer

None



An explainer (even inline) would be helpful to get a better
understanding of what this change does.
Does it impact only URL() object construction? What is happening
today? What will happen after this change lands?




Specification

https://url.spec.whatwg.org/#url-parsing


Summary

URLs with non-special schemes will be supported in chrome.
`non-speicial://test.com:1234/path`
 will be become a valid URL. One
can access and set the URL properties such as host, port and
path via the URL class.



Blink component

Blink>JavaScript>API




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: Positive

/WebKit/: Positive


Any links to those positive signals?



/Web developers/: No signals

/Other signals/:


Ergonomics

No significant risks.



Activation

No significant risks.



Security

data:// and javascript:// URLs handling is not modified due
to their critical role.



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?


Do URLs with an intent:// scheme have any security
considerations, or implications for WebView? (I don't know,
hopefully someone who does can answer. :))




Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name

NonSpeicalSchemeURLParsing


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1416006


Sample links


https://chromium-review.googlesource.com/c/chromium/src/+/4273893


Estimated milestones

No milestones specified



Anticipated spec changes

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



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5201116810182656

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/CAJQw1Nzk847XL759vMSQaF3L5zvtykg6UfQvuss4diyU-h1%3Duw%40mail.gmail.com

.
-- 
You received this message because you are subscribed to the

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to 

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

[Alex Russell]

LGTM3

On Wednesday, March 8, 2023 at 7:12:42 AM UTC-8 Manuel Rego wrote:

> LGTM2.
>
> On 08/03/2023 14:00, Yoav Weiss wrote:
> > LGTM1
> > 
> > On Mon, Mar 6, 2023 at 12:39 PM Lutz Vahl  > > wrote:
> > 
> > 
> > Contact emails
> > 
> > manosk...@google.com 
> > 
> > 
> > Explainer
> > 
> > 
> https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/Overview.md
>  
> <
> https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/Overview.md
> > 
> > 
> > 
> > Specification
> > 
> > https://github.com/WebAssembly/extended-const
> > 
> > 
> > 
> > Summary
> > 
> > We implement the WebAssembly extended-const proposal according
> > tohttps://github.com/WebAssembly/extended-const
> > .
> > 
> > Specifically, we add i32.add, i32.sub, i32.mul, i64.add, i64.sub and
> > i64.mul to the list of constant instructions.
> > 
> > 
> > 
> > Blink component
> > 
> > Blink>JavaScript>WebAssembly
> > <
> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly
> >
> > 
> > 
> > TAG review
> > 
> > Not needed in our view, as this is a very small change to existing
> > functionality.
> > 
> > 
> > Risks
> > 
> > 
> > 
> > Interoperability and Compatibility
> > 
> > N/A. The WebAssembly spec
> > <
> https://github.com/WebAssembly/proposals#phase-4---standardize-the-feature-wg>reached
>  
> Phase 4, therefore engines will implement it.
> > 
> > 
> > 
> > Debuggability
> > 
> > 
> > 
> > Will this feature be supported on all six Blink platforms
> > (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
> > 
> > Yes
> > 
> > 
> > Is this feature fully tested by web-platform-tests
> > <
> https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md
> >?
> > 
> > WebAssembly Spec Tests:
> > https://github.com/WebAssembly/extended-const/tree/main/test
> >  
> > 
> > 
> > Flag name
> > 
> > Experimental WebAssembly
> > 
> > 
> > Requires code in //chrome?
> > 
> > False
> > 
> > 
> > Estimated milestones
> > 
> > M113 behind a flag, M114 as default
> > 
> > 
> > 
> > Tracking bug
> > 
> > https://bugs.chromium.org/p/v8/issues/detail?id=12089
> > 
> > 
> > 
> > Estimated milestones
> > 
> > DevTrial on desktop
> > 
> > 
> > 
> > 113
> > 
> > 
> > DevTrial on Android
> > 
> > 
> > 
> > 113
> > 
> > 
> > 
> > 
> > 
> > 
> > Anticipated spec changes
> > 
> > Open questions about a feature may be a source of future web compat
> > or interop issues. Please list open issues (e.g. links to known
> > github issues in the project for the feature specification) whose
> > resolution may introduce web compat/interop risk (e.g., changing to
> > naming or structure of the API in a non-backward-compatible way).
> > 
> > 
> > 
> > Link to entry on the Chrome Platform Status
> > 
> > https://chromestatus.com/feature/5131077456232448
> > 
> > 
> > 
> > This intent message was generated by Chrome Platform Status
> > .
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google
> > Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to blink-dev+unsubscr...@chromium.org
> > .
> > To view this discussion on the web visit
> > 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBN2UjgnumxjSWj0GX0GgKJL0mtEinbr-NRWHwpvjth8fA%40mail.gmail.com
>  
> <
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBN2UjgnumxjSWj0GX0GgKJL0mtEinbr-NRWHwpvjth8fA%40mail.gmail.com?utm_medium=email_source=footer
> >.
> > 
> > -- 
> > You received this message because you are subscribed to the Google
> > Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to blink-dev+unsubscr...@chromium.org
> > .
> > To view this discussion on the web visit
> > 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVgZCURALU28Q9%2BUL5mrSqT551wFSUZ0jpfvEkb_AGCrQ%40mail.gmail.com
>  
> <
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVgZCURALU28Q9%2BUL5mrSqT551wFSUZ0jpfvEkb_AGCrQ%40mail.gmail.com?utm_medium=email_source=footer
> >.
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/93f2c93e-9ba6-4c4f-a9b2-d5ee3be31c02n%40chromium.org.

Re: [blink-dev] Intent to Ship: Skip service worker no-op fetch handler

[slightlyoff via Chromestatus]

LGTM3

-- 
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/663c7705f666132c%40google.com.

Re: [blink-dev] Intent to Ship: Skip service worker no-op fetch handler

[Daniel Bratell]

LGTM2

/Daniel

On 2023-03-07 12:57, Yoav Weiss wrote:

LGTM1

On Tue, Mar 7, 2023 at 10:12 AM Yoshisato Yanagisawa 
 wrote:




2023年3月7日(火) 17:19 Yoav Weiss :



On Tue, Mar 7, 2023 at 1:03 AM 'Yoshisato Yanagisawa' via
blink-dev  wrote:


Contact emails

yyanagis...@google.com


Explainer


https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler




Specification

https://github.com/w3c/ServiceWorker/pull/1672



Glad to see the PR in almost-landing condition! :) Please follow up 
with any extra effort required to actually land it.



Summary

The feature makes the navigation of pages with no-op
service worker fetch handlers fast by skipping them.


Some sites have a no-op (no operation) fetch listener
(e.g. onfetch = () => {}).  Since having the fetch
listener was one of the requirements to be a progressive
web app (PWA), we assume they did that to make their site
recognized as PWA.  However, it only brings overheads to
start a service worker and execute a no-op listener
without bringing any feature benefits like caching or
offline capabilities because the code does nothing.  To
make the navigation to such pages faster, we would like to
omit the service worker start and the listener dispatch
from the navigation critical path if a user agent
identifies that all the service worker's fetch listeners
are no-ops.


From version 112, Chromium starts to show console warnings
if all the service worker’s fetch listeners are no-ops,
and encourages developers to remove the useless fetch
listeners.  Hopefully sites stop using the useless fetch
listeners and we can deprecate the feature in the future.


Blink component

Blink>ServiceWorker




TAG review

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



TAG review status

Issues addressed


Risks



Interoperability and Compatibility

We believe the change has very small compatibility risk.


Updating the no-op fetch handler in a service worker is
ignored, which was not allowed to ignore before.  Upon our
observation, this happens to a negligible amount
(https://chromestatus.com/metrics/feature/timeline/popularity/4453

).


It seems like we don't yet have data from this.
Can you explain this counter a bit more? Doesn't it also count
cases where an operational fetch handler is updated after
initialization?


Sure.  The counter has been added in
https://chromium-review.googlesource.com/c/chromium/src/+/4190509,
and cherry-picked in M111, which is now eary stable according to
https://chromereleases.googleblog.com/. There is the counter to
watch all event handler updates in service worker
https://chromium-review.googlesource.com/c/chromium/src/+/4259225,
and we can see some numbers.
https://chromestatus.com/metrics/feature/timeline/popularity/4469
Therefore, it might be safe to say that the number of run-time
fetch handler updates is too small and not observable.


Oh, ok. So after over a week in Stable, we see 0.00015% for the loose 
upper bound. That's reassuring! :)



https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler/#approaches-to-deal-with-the-handler-updates-after-the-initialization




Navigation Preload is ignored for the no-op fetch
handler.  The spec requires the same resource fetched
twice for no-op fetch handler due to lack of respondWith,
which could result in two different network requests in
rare situation, but this behavior only happens when they
are misconfigured (a page was set up to send a Navigation
Preload request they do not use).


https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler/#how-does-it-work-with-navigation-preload

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

[Manuel Rego Casasnovas]

LGTM2.

On 08/03/2023 14:00, Yoav Weiss wrote:
> LGTM1
> 
> On Mon, Mar 6, 2023 at 12:39 PM Lutz Vahl  > wrote:
> 
> 
> Contact emails
> 
> manosk...@google.com 
> 
> 
> Explainer
> 
> 
> https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/Overview.md
>  
> 
>  
> 
> 
> Specification
> 
> https://github.com/WebAssembly/extended-const
> 
> 
> 
> Summary
> 
> We implement the WebAssembly extended-const proposal according
> tohttps://github.com/WebAssembly/extended-const
> .
> 
> Specifically, we add i32.add, i32.sub, i32.mul, i64.add, i64.sub and
> i64.mul to the list of constant instructions.
> 
> 
> 
> Blink component
> 
> Blink>JavaScript>WebAssembly
> 
> 
> 
> 
> TAG review
> 
> Not needed in our view, as this is a very small change to existing
> functionality.
> 
> 
> Risks
> 
> 
> 
> Interoperability and Compatibility
> 
> N/A. The WebAssembly spec
> 
> reached
>  Phase 4, therefore engines will implement it.
> 
> 
> 
> Debuggability
> 
> 
> 
> Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
> 
> Yes
> 
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> WebAssembly Spec Tests:
> https://github.com/WebAssembly/extended-const/tree/main/test
>  
> 
> 
> Flag name
> 
> Experimental WebAssembly
> 
> 
> Requires code in //chrome?
> 
> False
> 
> 
> Estimated milestones
> 
> M113 behind a flag, M114 as default
> 
> 
> 
> Tracking bug
> 
> https://bugs.chromium.org/p/v8/issues/detail?id=12089
> 
> 
> 
> Estimated milestones
> 
> DevTrial on desktop
> 
>   
> 
> 113
> 
> 
> DevTrial on Android
> 
>   
> 
> 113
> 
> 
> 
> 
> 
> 
> Anticipated spec changes
> 
> Open questions about a feature may be a source of future web compat
> or interop issues. Please list open issues (e.g. links to known
> github issues in the project for the feature specification) whose
> resolution may introduce web compat/interop risk (e.g., changing to
> naming or structure of the API in a non-backward-compatible way).
> 
> 
> 
> Link to entry on the Chrome Platform Status
> 
> https://chromestatus.com/feature/5131077456232448
> 
> 
> 
> This intent message was generated by Chrome Platform Status
> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+unsubscr...@chromium.org
> .
> To view this discussion on the web visit
> 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBN2UjgnumxjSWj0GX0GgKJL0mtEinbr-NRWHwpvjth8fA%40mail.gmail.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+unsubscr...@chromium.org
> .
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVgZCURALU28Q9%2BUL5mrSqT551wFSUZ0jpfvEkb_AGCrQ%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9085bcd5-af51-9127-5493-d879c75783dd%40igalia.com.

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

[Manuel Rego Casasnovas]

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

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

Cheers,
  Rego

>>
>>
>>
>> Is this feature fully tested
>> by web-platform-tests
>> 
>> ?
>>
>> Yes
>> https://wpt.fyi/css/mediaqueries/update-media-feature.html
>>
>>
>> Flag name
>>
>> CSSUpdateMediaFeature
>>
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=791028
>>
>>
>> Estimated milestones
>>
>> DevTrial on desktop  113
>>
>> DevTrial on Android  113
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5154424982339584
>>
>> This intent message was generated by Chrome Platform
>> Status .
>>
>> -- 
>> You received this message because you are subscribed to the
>> Google Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z92_-FaTz7z9S-eiWGw-_ZOap32FcOVig3VMJLxguQpoq0Q%40mail.gmail.com
>>  
>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from 

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

[Manuel Rego Casasnovas]

This has been already approved.

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

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

Cheers,
  Rego

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

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

[Manuel Rego Casasnovas]

LGTM2

Thank you very much for fixing the issues before shipping.

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

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

Cheers,
  Rego

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6120b437-2cf9-db52-6a2b-b6a7eb34bda8%40igalia.com.

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

[Yoav Weiss]

LGTM1

On Mon, Mar 6, 2023 at 12:39 PM Lutz Vahl  wrote:

>
> Contact emails
>
> manosk...@google.com
>
> Explainer
>
>
> https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/Overview.md
>
>
> Specification
>
> https://github.com/WebAssembly/extended-const
>
> Summary
>
> We implement the WebAssembly extended-const proposal according to
> https://github.com/WebAssembly/extended-const.
>
> Specifically, we add i32.add, i32.sub, i32.mul, i64.add, i64.sub and
> i64.mul to the list of constant instructions.
>
>
> Blink component
>
> Blink>JavaScript>WebAssembly
> 
>
> TAG review
>
> Not needed in our view, as this is a very small change to existing
> functionality.
>
> Risks
>
> Interoperability and Compatibility
>
> N/A. The WebAssembly spec
> 
> reached Phase 4, therefore engines will implement it.
>
>
> Debuggability
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> WebAssembly Spec Tests:
> https://github.com/WebAssembly/extended-const/tree/main/test
>
> Flag name
>
> Experimental WebAssembly
>
> Requires code in //chrome?
>
> False
>
> Estimated milestones
>
> M113 behind a flag, M114 as default
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=12089
>
> Estimated milestones
>
> DevTrial on desktop
>
> 113
>
> DevTrial on Android
>
> 113
>
>
>
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5131077456232448
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBN2UjgnumxjSWj0GX0GgKJL0mtEinbr-NRWHwpvjth8fA%40mail.gmail.com
> 
> .
>

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

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

[Yoav Weiss]

My LGTM1 still stands! :)

On Wed, Mar 8, 2023 at 8:40 AM Traian Captan  wrote:

> Hi,
>
> Following the previous conversation, we worked on adding support for the
> missing functionality that is currently described in the image-set spec
> .
>
> Here is the updated intent:
>
> Contact emailstcap...@chromium.org
>
> ExplainerNone
>
> Specification
> https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation
>
> Summary
>
> Unprefix -webkit-image-set to expose the current image-set functionality
> without needing the '-webkit-' prefix, and add support for the
> functionality currently described in the image-set spec.
>
>
> Blink componentBlink
> 
>
> Search tagsimage-set 
>
> TAG reviewSkipping because this is a straightforward interop fix.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> The Interoperability Risk is Low. This change increases interop with Gecko
> and WebKit which already support both '-webkit-' prefixed and unprefixed
> image-set, and are also actively working on improving their image-set
> implementations as part of Interop 2023 efforts. The Compatibility Risk is
> Low.
>
>
> *Gecko*: Shipped/Shipping (
> https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)
>
> *WebKit*: Shipped/Shipping (
> https://trac.webkit.org/changeset/202765/webkit)
>
> *Web developers*: Strongly positive This issue has been Starred by 55
> users.
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> No
>
>
> Debuggability
>
>
>
> 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
>

Even though wpt.fyi

is reddish, I'm seeing all the tests pass on ToT. Thank you!!


>
> Flag nameCSSImageSet
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/630597
>
> Estimated milestones
>
> No milestones specified
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5109745420075008
>
> Links to previous Intent discussionsIntent to Ship:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/JXcRP4MJc9I
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> Regards,
> Traian
>
>
> On Mon, Jan 23, 2023 at 2:57 PM Traian Captan 
> wrote:
>
>> Thanks Noam!
>>
>> I'll add support for the other cases behind the feature flag and we'll
>> ship it when we are "interoperable enough".
>>
>> Regards,
>> Traian
>>
>>
>> On Wed, Dec 14, 2022 at 6:41 AM Noam Rosenthal 
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas 
>>> wrote:
>>>
 If we have plans to fix issues on this feature later, why not fixing
 them before and then shipping when things look good?

 If we unprefix it, it'll kind of appear as a new Chromium feature that
 people can use, and they will expect it follows the spec.
>>>
>>>
>>> I agree, for example people might (wrongfully) rely on
>>> CSS.supports("background-image", "image-set(url(example.jpg) 1x)")
>>> to mean that the full set of image-set features is supported.
>>> I'm not sure people are more granular than that about feature detection
>>> but we probably have data about that.
>>>
>>> It might be wise to support the cases behind the prefix, and
>>> unprefix when the behavior is close to complete and interoperable enough.
>>> We don't need to rely on people posting bug reports when we know the
>>> issues today by looking at the WPT failures.
>>>
>>

-- 
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/CAL5BFfXvN2tRMNn829HbZkSF%3D%2BOhgYXNvZPF_ctGKhvUA%2Br%3DEA%40mail.gmail.com.