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

[Domenic Denicola]

LGTM1

On Fri, Feb 2, 2024 at 6:53 AM David Bokan  wrote:

> Contact emailsbo...@chromium.org, khushalsa...@chromium.org,
> nrosent...@chromium.org, vmp...@chromium.org
>
> Explainer
> https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md
>
> Specificationhttps://html.spec.whatwg.org/#reveal
>
> Design docs
> https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md
>
> Summary
>
> The `pagereveal` event is fired on a Document's window object at the first
> render opportunity after a Document is: initially loaded, restored from the
> back-forward cache, or activated from a prerender. It can be used by a page
> author to set up a page entry UX - such as a ViewTransition from a previous
> state. This feature is split out from the larger Cross Document View
> Transition project.
>
>
> Blink componentBlink>ViewTransitions
> 
>
> Search tagstransition 
> , firstrender , reveal
> , event
> , viewtransition
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/851
>
> Note: TAG review was for Cross-Document View Transitions which included
> this event as a piece. I asked TAG whether they'd like to do a separate
> review but didn't receive a response.
>

I'll note that the ask was in 2023-09-28, with two other pings since then,
so I think this is very fair. (And I also agree that this was covered by
the original review request.)

>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> This is a new event so shouldn't have any compatibility risks. Usual
> interop risk of other engines not adopting it exists but this should be low
> since it's had input and discussion[1] from engineers of both WebKit and
> Mozilla and is a dependency of cross-document view transitions which has
> received a positive signal from at least Mozilla[2] (waiting to hear from
> Apple[3]). [1] https://github.com/whatwg/html/issues/9315 [2]
> https://github.com/mozilla/standards-positions/issues/677
>
> [3] https://github.com/WebKit/standards-positions/issues/302
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/677) See:
> https://github.com/mozilla/standards-positions/issues/677#issuecomment-1904541389
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/303) Awaiting
> response.
>
> *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
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> This is a standard HTML event applicable to all platforms
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pagereveal?label=experimental=master
>

Can you un-tentative these tests?


>
>
> Flag name on chrome://flags
> chrome://flags/#enable-experimental-web-platform-features
>
> Finch feature namePageRevealEvent
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1466250
>
> Estimated milestones
> Shipping on desktop 123
> DevTrial on desktop 120
> Shipping on Android 123
> DevTrial on Android 120
> Shipping on WebView 123
>
> 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/5205586941837312
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0f76584-ea3f-43ab-946c-b920fc064344n%40chromium.org
>
> 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/CANMmsAvhWAzVrHCudjLgQRtePgqEHucNqb27Wkn9r4dCKeUTWg%40mail.gmail.com
> 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Domenic Denicola]

LGTM2. Please be sure to update Chrome Status with the deprecation trial
timelines and removal milestones so that data gets fed into the feature
dashboard, beta blog posts, etc.

On Fri, Feb 2, 2024 at 7:35 AM Thomas Guilbert 
wrote:

> Thank you!
>
> I will be adding an enterprise policy to re-enable the APIs if necessary,
> as part of the enterprise review. Deprecating the enterprise policy will
> become the new objective after the proper amount of time has elapsed,
> before the code can be deleted for good.
>
> I will keep updating this thread as I make it further in the launch
> process.
>
> On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt 
> wrote:
>
>> Thank you Thomas!
>>
>> As far as I'm aware that's all of the paperwork completed, so LGTM1 to
>> disable the APIs by default and at the same time start a reverse origin
>> trial to re-enable them for 6 months. If you hear feedback requesting an
>> extension towards the end of those 6 months, please request an extension
>> for another 6 months.
>>
>> On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
>> wrote:
>>
>>> Thanks for marking it for review!
>>>
>>> I submitted a request to review this change to the chromium enterprise
>>> mailing list.
>>>
>>> Thanks,
>>> Thomas
>>>
>>> On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
>>> wrote:
>>>
 Yep - seems that's the cause of confusion. In your first email,
 https://chromestatus.com/feature/5259513871466496 is linked from the
 bottom, so our review tooling is presenting that to us. But I've just
 flagged the new one so it will show up as well.

 thanks!
 On 1/31/24 2:41 PM, Thomas Guilbert wrote:

 I requested privacy/security/debuggability on the video element
 fullscreen API deprecation feature
  
 last
 week. Privacy and debuggability are approved, just waiting on security.

 Mike, are you talking about requesting those gates on the original
 Prefixed Fullscreen API feature
 ? I don't have edit
 rights on that Chrome status entry, and upon closer look, it relates to
 `webkitRequestFullscreen`, which is not covered by this deprecation intent.

 > [...] requesting enterprise signoff [...]
 Is this a field on the chrome status entry? It doesn't show up for me.
 Or is this about emailing the list mentioned here
 
 ?

 Thanks,
 Thomas



 On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
 wrote:

> Apologies in advance for excessive paperwork, but can you also put
> https://chromestatus.com/feature/5111638103687168 through the
> process, requesting enterprise signoff in particular? Enterprise folks
> could depend on this and might need to take some extra action, and a
> "Feature deprecation" entry is the only way we can flag that.
>
> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
> wrote:
>
>> Gentle reminder to follow up on requesting
>> privacy/security/debuggability approvals in chromestatus (which is
>> currently blocking LGTMs).
>>
>> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>>
>>> Would you mind requesting reviews for the various gates (privacy,
>>> security, debuggability) for an OT/DT in your chromestatus entry?
>>> On 1/19/24 10:43 PM, Thomas Guilbert wrote:
>>>
>>> Contact emails
>>>
>>> tguilb...@chromium.org
>>>
>>> Explainer
>>>
>>> None
>>>
>>> Specification
>>>
>>> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled
>>>
>>> Summary
>>> There was an attempt in 2014
>>> 
>>> to deprecate and remove the HTMLVideoElement-specific Prefixed 
>>> Fullscreen
>>> APIs. This meant removing the following APIs from HTMLVideoElement:
>>>
>>> readonly attribute boolean webkitSupportsFullscreen;
>>> readonly attribute boolean webkitDisplayingFullscreen;
>>> void webkitEnterFullscreen();
>>> void webkitExitFullscreen();
>>> // Note the different capitalization of the "S" in FullScreen.
>>> void webkitEnterFullScreen();
>>> void webkitExitFullScreen();
>>>
>>> The overall usage of these APIs is low, and has trended downwards
>>> over time. Here are the latest usage numbers, as a % of total page
>>> loads:
>>>
>>> PrefixedVideoSupportsFullscreen: 0.025%
>>> PrefixedVideoDisplayingFullscreen: 0.082%
>>> PrefixedVideoEnterFullscreen: 0.001%
>>> PrefixedVideoExitFullscreen: 0.010%
>>> PrefixedVideoEnterFullScreen: 0.001%
>>> PrefixedVideoExitFullScreen: 0.000%
>>>
>>>
>>> There has been an unfortunate uptick in the past 

[blink-dev] Chromium Issue Tracker migration begins in less than 24 hours!

['Joe Gregorio' via blink-dev]

Hi all,

Less than 24 hours until we begin the migration to the new Chromium Issue
Tracker! (On track to begin Feb 2 @ 5pm PST and conclude by end of day Feb
4 PST)

There will be downtime during this period as Chromium’s Monorail project
will be marked as read-only and Chromium’s new Issue Tracker will not yet
be available.

Please visit this page for updates on the migration and what to do if you

need to raise issues during the read-only migration window:

g.co/dev/chromium-migration

We will confirm via email once the new issue tracker is ready for use.

Please note: Any CLs merged during the migration during downtime will not
have their corresponding bugs updated by GitWatcher. This will have to be
done manually.


   Thanks,

   -joe, on behalf of the Chromium Issue Tracker team

-- 
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/CAA6qSUCPqzY%2Bnfh%2B%3DA2B6HqkUHRWMktVJfspJYzvMM16r4ZBvw%40mail.gmail.com.

Re: [blink-dev] Request for Deprecation Trial: Deprecate Mutation Events

[Mason Freed]

On Thu, Feb 1, 2024 at 7:12 AM Vladimir Levin  wrote:

> This is very exciting! Thank you for working on this.
>

Thanks!


> Do you know whether the existing usage is feature checked? 1.58% seems
> very high, but if it's feature checked and fallback is something like
> mutation observer, then it would be a lot more safe imho. Also, do you have
> a sense of where the usage is coming from (a few large frameworks vs a ton
> of smaller sites)?
>

Unfortunately, I haven't seen a lot of feature checking around mutation
events directly. I have definitely seen feature checks on MutationObserver
that then avoids trying to use mutation events. But obviously those aren't
part of the use counter data, since they don't attach mutation
event listeners.

I've been looking into UKM data to see if I can suss out any large usage
patterns. I've found a few, e.g. QuillJS
, which contribute a
significant chunk of usage to many sites. Thankfully in the cases I've
seen, the (large) deprecation warnings I've added to Chrome seem to be doing
their thing
.
My hope is that direct outreach (which I've done in a few cases), heavy
warnings, and eventually the start of the removal effort (plus this OT to
give sites an extension) will nudge the remaining users to migrate.


>  The npm package you listed, for example, would use the actual events if
> available, so sites using that polyfill would also count towards the event
> usage if the browser supports those even though that's "safe", right?
>

This is an excellent point that I hadn't thought of. I'm going to modify
the polyfill right now to *always* run. That way polyfilled usage will no
longer be counted. I'm used to writing polyfills for features that are
getting *added*, where you want to avoid using the polyfill when the
feature is supported. This is the opposite.

Thanks,
Mason



>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/807) "very strong
>> positive position"
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/192)
>>
>> *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
>>
>>
>> Goals for experimentation
>>
>>
>>
>> Ongoing technical constraints
>>
>>
>>
>> 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
>> 
>> ?No
>>
>> Flag name on chrome://flags
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1446498
>>
>> Estimated milestones
>> Shipping on desktop 115
>> OriginTrial desktop last 134
>> OriginTrial desktop first 124
>> Shipping on Android 115
>> OriginTrial Android last 134
>> OriginTrial Android first 124
>> Shipping on WebView 115
>> OriginTrial webView last 134
>> OriginTrial webView first 124
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5083947249172480
>>
>> Links to previous Intent discussionsIntent to Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/isA1mZ_aAAAJ
>>
>>
>> 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%3DNeDjevtANjMn1NUK83UGyJyv4HrLCFkjs9fhL6UVov_uAkA%40mail.gmail.com
>> 
>> .
>>
>

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

Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Chris Harrelson]

On Thu, Feb 1, 2024 at 2:43 PM Evan Stade  wrote:

> My understanding is that SVG support got lost in a personnel shuffle and
> that we would like to ship it in theory. This comment
>  has
> some more context, the takeaways being that:
>
>- we need to be more sure of the implementation
>- we need partner confirmation, i.e. addressing "LGTM3 with the caveat
>that we should only flip this flag to ship if big customers like Sean's
>team are able to use this successfully to minimally cover their needs."
>
> From my perspective the LGTMs are no longer caveated. I think there is
enough evidence of demand to just do it.


> No one has done that outreach as of yet.
>
> -- Evan Stade
>
>
> On Thu, Feb 1, 2024 at 2:35 PM Chris Harrelson 
> wrote:
>
>> Hi,
>>
>> From my perspective, you still have 3 LGTMs to ship from the API owners.
>> However, please fill out the cross-functional reviews for privacy,
>> security, etc that have been added to the process since this intent was
>> created. If that doesn't seem possible with your existing chromestatus
>> entry, let me know or just create a new one and I'll LGTM it after those
>> reviews have started.
>>
>> On Thu, Feb 1, 2024 at 1:38 PM Anupam Snigdha 
>> wrote:
>>
>>> Thanks Chris!
>>> cc'ing estade@.
>>> I think Darwin and Victor are not working on clipboard anymore so this
>>> feature was stalled.
>>>
>>> Recently another bug was opened (
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1410321) where
>>> support for copying/pasting svg images is needed. More discussions:
>>> https://boxy-svg.com/ideas/268/paste-images-from-the-system-clipboard#comment-2313
>>> Since this I2S was LGTM'd with the caveat that Adobe is able to use this
>>> format, and I'm not sure if there is any update on that, is it possible to
>>> reconsider this I2S if there are other customers like Keynote and Cleanshot
>>> X interested in this feature?
>>> cc'ing Josh as well to see if there were any internal discussions with
>>> Adobe for SVG image support. Thanks!
>>>
>>> -Anupam
>>>
>>> On Mon, Nov 13, 2023 at 4:50 PM Chris Harrelson 
>>> wrote:
>>>
 Thanks for the interest! I agree it would be good to ship this if
 possible.

 On Tue, Oct 31, 2023 at 1:22 AM 一丝  wrote:

> Unfortunately, three LGTMs obtained here did not ship. Can anyone
> re-continue this process?
>
> With Keynote 13.1 supporting the SVG format, this API seems to be the
> only way to copy and paste SVGs into Keynote in a browser.


 Could you test with the experimental-web-platform-features chrome flag
 turned on, and see if it works as intended for copy and paste from Keynote?


>
> 在2021年8月20日星期五 UTC+8 03:15:56 写道：
>
>> LGTM3 with the caveat that we should only flip this flag to ship if
>> big customers like Sean's team are able to use this successfully to
>> minimally cover their needs.
>>
>> On Thursday, August 19, 2021 at 11:57:00 AM UTC-7 Chris Harrelson
>> wrote:
>>
>>> LGTM2
>>>
>>> On Thu, Aug 19, 2021 at 11:46 AM Mike West 
>>> wrote:
>>>
>> LGTM1.

 I think it's important that we address the TAG's concerns about
 gesture requirements and other mechanisms which might reduce the 
 surprise
 associated with some uses of the clipboard API, but I agree with Darwin
 that shipping SVG support doesn't need to block on that conversation. 
 That
 said, I'd encourage y'all to engage more closely with those questions.
 Marijn, you and +Victor Costan are on an internal thread on that
 topic that we should follow up on.

 Regarding style, this intent is the most conservative approach to
 sanitization, which has been approved by the security team. Ideally, we
 could find a way to allow style safely via the sanitization API work 
 that's
 underway separately, as Anne suggested on Mozilla's standards
 position thread
 .
 I also note that Apple's response on
 https://lists.webkit.org/pipermail/webkit-dev/2021-August/031940.html
 seems generally positive.

 -mike


 On Fri, Aug 13, 2021 at 11:54 PM Sean Voisen 
 wrote:

>>> On Thursday, August 12th, 2021 at 12:22 PM, Alex Russell <
> sligh...@chromium.org> wrote:
>
> There's a recurring debate here about the stripping of inline
> style information; Sean, how much worse is it for styles to be 
> stripped in
> your use-cases? If we wait for styles to be re-added (if they can be 
> at
> all) to ship this, how much worse is that?
>
>
> Just so I'm clear, is the debate about 

Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Evan Stade]

My understanding is that SVG support got lost in a personnel shuffle and
that we would like to ship it in theory. This comment
 has
some more context, the takeaways being that:

   - we need to be more sure of the implementation
   - we need partner confirmation, i.e. addressing "LGTM3 with the caveat
   that we should only flip this flag to ship if big customers like Sean's
   team are able to use this successfully to minimally cover their needs."

No one has done that outreach as of yet.

-- Evan Stade


On Thu, Feb 1, 2024 at 2:35 PM Chris Harrelson 
wrote:

> Hi,
>
> From my perspective, you still have 3 LGTMs to ship from the API owners.
> However, please fill out the cross-functional reviews for privacy,
> security, etc that have been added to the process since this intent was
> created. If that doesn't seem possible with your existing chromestatus
> entry, let me know or just create a new one and I'll LGTM it after those
> reviews have started.
>
> On Thu, Feb 1, 2024 at 1:38 PM Anupam Snigdha 
> wrote:
>
>> Thanks Chris!
>> cc'ing estade@.
>> I think Darwin and Victor are not working on clipboard anymore so this
>> feature was stalled.
>>
>> Recently another bug was opened (
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1410321) where
>> support for copying/pasting svg images is needed. More discussions:
>> https://boxy-svg.com/ideas/268/paste-images-from-the-system-clipboard#comment-2313
>> Since this I2S was LGTM'd with the caveat that Adobe is able to use this
>> format, and I'm not sure if there is any update on that, is it possible to
>> reconsider this I2S if there are other customers like Keynote and Cleanshot
>> X interested in this feature?
>> cc'ing Josh as well to see if there were any internal discussions with
>> Adobe for SVG image support. Thanks!
>>
>> -Anupam
>>
>> On Mon, Nov 13, 2023 at 4:50 PM Chris Harrelson 
>> wrote:
>>
>>> Thanks for the interest! I agree it would be good to ship this if
>>> possible.
>>>
>>> On Tue, Oct 31, 2023 at 1:22 AM 一丝  wrote:
>>>
 Unfortunately, three LGTMs obtained here did not ship. Can anyone
 re-continue this process?

 With Keynote 13.1 supporting the SVG format, this API seems to be the
 only way to copy and paste SVGs into Keynote in a browser.
>>>
>>>
>>> Could you test with the experimental-web-platform-features chrome flag
>>> turned on, and see if it works as intended for copy and paste from Keynote?
>>>
>>>

 在2021年8月20日星期五 UTC+8 03:15:56 写道：

> LGTM3 with the caveat that we should only flip this flag to ship if
> big customers like Sean's team are able to use this successfully to
> minimally cover their needs.
>
> On Thursday, August 19, 2021 at 11:57:00 AM UTC-7 Chris Harrelson
> wrote:
>
>> LGTM2
>>
>> On Thu, Aug 19, 2021 at 11:46 AM Mike West 
>> wrote:
>>
> LGTM1.
>>>
>>> I think it's important that we address the TAG's concerns about
>>> gesture requirements and other mechanisms which might reduce the 
>>> surprise
>>> associated with some uses of the clipboard API, but I agree with Darwin
>>> that shipping SVG support doesn't need to block on that conversation. 
>>> That
>>> said, I'd encourage y'all to engage more closely with those questions.
>>> Marijn, you and +Victor Costan are on an internal thread on that
>>> topic that we should follow up on.
>>>
>>> Regarding style, this intent is the most conservative approach to
>>> sanitization, which has been approved by the security team. Ideally, we
>>> could find a way to allow style safely via the sanitization API work 
>>> that's
>>> underway separately, as Anne suggested on Mozilla's standards
>>> position thread
>>> .
>>> I also note that Apple's response on
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031940.html
>>> seems generally positive.
>>>
>>> -mike
>>>
>>>
>>> On Fri, Aug 13, 2021 at 11:54 PM Sean Voisen 
>>> wrote:
>>>
>> On Thursday, August 12th, 2021 at 12:22 PM, Alex Russell <
 sligh...@chromium.org> wrote:

 There's a recurring debate here about the stripping of inline style
 information; Sean, how much worse is it for styles to be stripped in 
 your
 use-cases? If we wait for styles to be re-added (if they can be at 
 all) to
 ship this, how much worse is that?


 Just so I'm clear, is the debate about stripping style attributes
 or style elements or both?
 We would want at least one of those. Illustrator allows for
 exporting SVG with either, though by default (including when copying to
 clipboard) it uses style elements like so:

 

Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Chris Harrelson]

Hi,

>From my perspective, you still have 3 LGTMs to ship from the API owners.
However, please fill out the cross-functional reviews for privacy,
security, etc that have been added to the process since this intent was
created. If that doesn't seem possible with your existing chromestatus
entry, let me know or just create a new one and I'll LGTM it after those
reviews have started.

On Thu, Feb 1, 2024 at 1:38 PM Anupam Snigdha 
wrote:

> Thanks Chris!
> cc'ing estade@.
> I think Darwin and Victor are not working on clipboard anymore so this
> feature was stalled.
>
> Recently another bug was opened (
> https://bugs.chromium.org/p/chromium/issues/detail?id=1410321) where
> support for copying/pasting svg images is needed. More discussions:
> https://boxy-svg.com/ideas/268/paste-images-from-the-system-clipboard#comment-2313
> Since this I2S was LGTM'd with the caveat that Adobe is able to use this
> format, and I'm not sure if there is any update on that, is it possible to
> reconsider this I2S if there are other customers like Keynote and Cleanshot
> X interested in this feature?
> cc'ing Josh as well to see if there were any internal discussions with
> Adobe for SVG image support. Thanks!
>
> -Anupam
>
> On Mon, Nov 13, 2023 at 4:50 PM Chris Harrelson 
> wrote:
>
>> Thanks for the interest! I agree it would be good to ship this if
>> possible.
>>
>> On Tue, Oct 31, 2023 at 1:22 AM 一丝  wrote:
>>
>>> Unfortunately, three LGTMs obtained here did not ship. Can anyone
>>> re-continue this process?
>>>
>>> With Keynote 13.1 supporting the SVG format, this API seems to be the
>>> only way to copy and paste SVGs into Keynote in a browser.
>>
>>
>> Could you test with the experimental-web-platform-features chrome flag
>> turned on, and see if it works as intended for copy and paste from Keynote?
>>
>>
>>>
>>> 在2021年8月20日星期五 UTC+8 03:15:56 写道：
>>>
 LGTM3 with the caveat that we should only flip this flag to ship if big
 customers like Sean's team are able to use this successfully to minimally
 cover their needs.

 On Thursday, August 19, 2021 at 11:57:00 AM UTC-7 Chris Harrelson wrote:

> LGTM2
>
> On Thu, Aug 19, 2021 at 11:46 AM Mike West  wrote:
>
 LGTM1.
>>
>> I think it's important that we address the TAG's concerns about
>> gesture requirements and other mechanisms which might reduce the surprise
>> associated with some uses of the clipboard API, but I agree with Darwin
>> that shipping SVG support doesn't need to block on that conversation. 
>> That
>> said, I'd encourage y'all to engage more closely with those questions.
>> Marijn, you and +Victor Costan are on an internal thread on that
>> topic that we should follow up on.
>>
>> Regarding style, this intent is the most conservative approach to
>> sanitization, which has been approved by the security team. Ideally, we
>> could find a way to allow style safely via the sanitization API work 
>> that's
>> underway separately, as Anne suggested on Mozilla's standards
>> position thread
>> .
>> I also note that Apple's response on
>> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031940.html
>> seems generally positive.
>>
>> -mike
>>
>>
>> On Fri, Aug 13, 2021 at 11:54 PM Sean Voisen 
>> wrote:
>>
> On Thursday, August 12th, 2021 at 12:22 PM, Alex Russell <
>>> sligh...@chromium.org> wrote:
>>>
>>> There's a recurring debate here about the stripping of inline style
>>> information; Sean, how much worse is it for styles to be stripped in 
>>> your
>>> use-cases? If we wait for styles to be re-added (if they can be at all) 
>>> to
>>> ship this, how much worse is that?
>>>
>>>
>>> Just so I'm clear, is the debate about stripping style attributes or
>>> style elements or both?
>>> We would want at least one of those. Illustrator allows for
>>> exporting SVG with either, though by default (including when copying to
>>> clipboard) it uses style elements like so:
>>>
>>> .cls-1{fill:url(#radial-gradient);}.
>>>
>>> If both were to be sanitized away then the feature would be of more
>>> limited value for our use cases.
>>>
>>> Sean
>>>
>>> On Wednesday, August 11, 2021 at 9:23:33 PM UTC-7 Marijn
>>> Kruisselbrink wrote:
>>>
 API Owners: any further thoughts on this intent? Are there any
 open/pending questions for us?

 On Thu, Jul 15, 2021 at 3:23 PM Sean Voisen 
 wrote:

> On Wednesday, July 7, 2021 at 1:30:51 AM UTC-7
> yoav...@chromium.org wrote:
>
>>
>>> Web developers: Positive
>>>
>>>
>>> Any links?
>>>
>>
> We have interest in using SVG support on the clipboard for web
> 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Thomas Guilbert]

Thank you!

I will be adding an enterprise policy to re-enable the APIs if necessary,
as part of the enterprise review. Deprecating the enterprise policy will
become the new objective after the proper amount of time has elapsed,
before the code can be deleted for good.

I will keep updating this thread as I make it further in the launch process.

On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt 
wrote:

> Thank you Thomas!
>
> As far as I'm aware that's all of the paperwork completed, so LGTM1 to
> disable the APIs by default and at the same time start a reverse origin
> trial to re-enable them for 6 months. If you hear feedback requesting an
> extension towards the end of those 6 months, please request an extension
> for another 6 months.
>
> On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
> wrote:
>
>> Thanks for marking it for review!
>>
>> I submitted a request to review this change to the chromium enterprise
>> mailing list.
>>
>> Thanks,
>> Thomas
>>
>> On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
>> wrote:
>>
>>> Yep - seems that's the cause of confusion. In your first email,
>>> https://chromestatus.com/feature/5259513871466496 is linked from the
>>> bottom, so our review tooling is presenting that to us. But I've just
>>> flagged the new one so it will show up as well.
>>>
>>> thanks!
>>> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>>>
>>> I requested privacy/security/debuggability on the video element
>>> fullscreen API deprecation feature
>>>  
>>> last
>>> week. Privacy and debuggability are approved, just waiting on security.
>>>
>>> Mike, are you talking about requesting those gates on the original
>>> Prefixed Fullscreen API feature
>>> ? I don't have edit
>>> rights on that Chrome status entry, and upon closer look, it relates to
>>> `webkitRequestFullscreen`, which is not covered by this deprecation intent.
>>>
>>> > [...] requesting enterprise signoff [...]
>>> Is this a field on the chrome status entry? It doesn't show up for me.
>>> Or is this about emailing the list mentioned here
>>> 
>>> ?
>>>
>>> Thanks,
>>> Thomas
>>>
>>>
>>>
>>> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
>>> wrote:
>>>
 Apologies in advance for excessive paperwork, but can you also put
 https://chromestatus.com/feature/5111638103687168 through the process,
 requesting enterprise signoff in particular? Enterprise folks could depend
 on this and might need to take some extra action, and a "Feature
 deprecation" entry is the only way we can flag that.

 On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
 wrote:

> Gentle reminder to follow up on requesting
> privacy/security/debuggability approvals in chromestatus (which is
> currently blocking LGTMs).
>
> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>
>> Would you mind requesting reviews for the various gates (privacy,
>> security, debuggability) for an OT/DT in your chromestatus entry?
>> On 1/19/24 10:43 PM, Thomas Guilbert wrote:
>>
>> Contact emails
>>
>> tguilb...@chromium.org
>>
>> Explainer
>>
>> None
>>
>> Specification
>>
>> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled
>>
>> Summary
>> There was an attempt in 2014
>> 
>> to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen
>> APIs. This meant removing the following APIs from HTMLVideoElement:
>>
>> readonly attribute boolean webkitSupportsFullscreen;
>> readonly attribute boolean webkitDisplayingFullscreen;
>> void webkitEnterFullscreen();
>> void webkitExitFullscreen();
>> // Note the different capitalization of the "S" in FullScreen.
>> void webkitEnterFullScreen();
>> void webkitExitFullScreen();
>>
>> The overall usage of these APIs is low, and has trended downwards
>> over time. Here are the latest usage numbers, as a % of total page
>> loads:
>>
>> PrefixedVideoSupportsFullscreen: 0.025%
>> PrefixedVideoDisplayingFullscreen: 0.082%
>> PrefixedVideoEnterFullscreen: 0.001%
>> PrefixedVideoExitFullscreen: 0.010%
>> PrefixedVideoEnterFullScreen: 0.001%
>> PrefixedVideoExitFullScreen: 0.000%
>>
>>
>> There has been an unfortunate uptick in the past 2 years for the two
>> following APIs, which means that it's best to remove them now, before 
>> they
>> see a wider adoption. These numbers might be going up because the 
>> prefixed
>> APIs are also present on iOS.
>>
>> https://chromestatus.com/metrics/feature/timeline/popularity/166
>> 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Philip Jägenstedt]

Thank you Thomas!

As far as I'm aware that's all of the paperwork completed, so LGTM1 to
disable the APIs by default and at the same time start a reverse origin
trial to re-enable them for 6 months. If you hear feedback requesting an
extension towards the end of those 6 months, please request an extension
for another 6 months.

On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
wrote:

> Thanks for marking it for review!
>
> I submitted a request to review this change to the chromium enterprise
> mailing list.
>
> Thanks,
> Thomas
>
> On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
> wrote:
>
>> Yep - seems that's the cause of confusion. In your first email,
>> https://chromestatus.com/feature/5259513871466496 is linked from the
>> bottom, so our review tooling is presenting that to us. But I've just
>> flagged the new one so it will show up as well.
>>
>> thanks!
>> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>>
>> I requested privacy/security/debuggability on the video element
>> fullscreen API deprecation feature
>>  
>> last
>> week. Privacy and debuggability are approved, just waiting on security.
>>
>> Mike, are you talking about requesting those gates on the original
>> Prefixed Fullscreen API feature
>> ? I don't have edit
>> rights on that Chrome status entry, and upon closer look, it relates to
>> `webkitRequestFullscreen`, which is not covered by this deprecation intent.
>>
>> > [...] requesting enterprise signoff [...]
>> Is this a field on the chrome status entry? It doesn't show up for me. Or
>> is this about emailing the list mentioned here
>> 
>> ?
>>
>> Thanks,
>> Thomas
>>
>>
>>
>> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
>> wrote:
>>
>>> Apologies in advance for excessive paperwork, but can you also put
>>> https://chromestatus.com/feature/5111638103687168 through the process,
>>> requesting enterprise signoff in particular? Enterprise folks could depend
>>> on this and might need to take some extra action, and a "Feature
>>> deprecation" entry is the only way we can flag that.
>>>
>>> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
>>> wrote:
>>>
 Gentle reminder to follow up on requesting
 privacy/security/debuggability approvals in chromestatus (which is
 currently blocking LGTMs).

 On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:

> Would you mind requesting reviews for the various gates (privacy,
> security, debuggability) for an OT/DT in your chromestatus entry?
> On 1/19/24 10:43 PM, Thomas Guilbert wrote:
>
> Contact emails
>
> tguilb...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled
>
> Summary
> There was an attempt in 2014
> 
> to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen
> APIs. This meant removing the following APIs from HTMLVideoElement:
>
> readonly attribute boolean webkitSupportsFullscreen;
> readonly attribute boolean webkitDisplayingFullscreen;
> void webkitEnterFullscreen();
> void webkitExitFullscreen();
> // Note the different capitalization of the "S" in FullScreen.
> void webkitEnterFullScreen();
> void webkitExitFullScreen();
>
> The overall usage of these APIs is low, and has trended downwards over
> time. Here are the latest usage numbers, as a % of total page loads:
>
> PrefixedVideoSupportsFullscreen: 0.025%
> PrefixedVideoDisplayingFullscreen: 0.082%
> PrefixedVideoEnterFullscreen: 0.001%
> PrefixedVideoExitFullscreen: 0.010%
> PrefixedVideoEnterFullScreen: 0.001%
> PrefixedVideoExitFullScreen: 0.000%
>
>
> There has been an unfortunate uptick in the past 2 years for the two
> following APIs, which means that it's best to remove them now, before they
> see a wider adoption. These numbers might be going up because the prefixed
> APIs are also present on iOS.
>
> https://chromestatus.com/metrics/feature/timeline/popularity/166
> https://chromestatus.com/metrics/feature/timeline/popularity/167
>
> There is an alternative set of APIs supported by all browsers that web
> authors can use.
>
> The full history of the removal attempt is here: crbug.com/346236
>
>
> Goals for experimentation
>
> The primary goal of the deprecation trial is to reduce the amount of
> broken user-visible experiences as the prefixed fullscreen APIs are
> removed, and to give time to web authors to transition to the modern API
> (which has been available for 5 years).
>
>
> The un-prefixed 

[blink-dev] Intent to Ship: 'pagereveal' event

[David Bokan]

Contact emailsbo...@chromium.org, khushalsa...@chromium.org,
nrosent...@chromium.org, vmp...@chromium.org

Explainer
https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md

Specificationhttps://html.spec.whatwg.org/#reveal

Design docs
https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md

Summary

The `pagereveal` event is fired on a Document's window object at the first
render opportunity after a Document is: initially loaded, restored from the
back-forward cache, or activated from a prerender. It can be used by a page
author to set up a page entry UX - such as a ViewTransition from a previous
state. This feature is split out from the larger Cross Document View
Transition project.


Blink componentBlink>ViewTransitions


Search tagstransition ,
firstrender , reveal
, event
, viewtransition


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/851

Note: TAG review was for Cross-Document View Transitions which included
this event as a piece. I asked TAG whether they'd like to do a separate
review but didn't receive a response.

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

This is a new event so shouldn't have any compatibility risks. Usual
interop risk of other engines not adopting it exists but this should be low
since it's had input and discussion[1] from engineers of both WebKit and
Mozilla and is a dependency of cross-document view transitions which has
received a positive signal from at least Mozilla[2] (waiting to hear from
Apple[3]). [1] https://github.com/whatwg/html/issues/9315 [2]
https://github.com/mozilla/standards-positions/issues/677

[3] https://github.com/WebKit/standards-positions/issues/302


*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/677)
See:
https://github.com/mozilla/standards-positions/issues/677#issuecomment-1904541389

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

*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

None


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

This is a standard HTML event applicable to all platforms


Is this feature fully tested by web-platform-tests

?Yes

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


Flag name on chrome://flags
chrome://flags/#enable-experimental-web-platform-features

Finch feature namePageRevealEvent

Requires code in //chrome?False

Tracking bughttps://crbug.com/1466250

Estimated milestones
Shipping on desktop 123
DevTrial on desktop 120
Shipping on Android 123
DevTrial on Android 120
Shipping on WebView 123

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0f76584-ea3f-43ab-946c-b920fc064344n%40chromium.org

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

Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Anupam Snigdha]

Thanks Chris!
cc'ing estade@.
I think Darwin and Victor are not working on clipboard anymore so this
feature was stalled.

Recently another bug was opened (
https://bugs.chromium.org/p/chromium/issues/detail?id=1410321) where
support for copying/pasting svg images is needed. More discussions:
https://boxy-svg.com/ideas/268/paste-images-from-the-system-clipboard#comment-2313
Since this I2S was LGTM'd with the caveat that Adobe is able to use this
format, and I'm not sure if there is any update on that, is it possible to
reconsider this I2S if there are other customers like Keynote and Cleanshot
X interested in this feature?
cc'ing Josh as well to see if there were any internal discussions with
Adobe for SVG image support. Thanks!

-Anupam

On Mon, Nov 13, 2023 at 4:50 PM Chris Harrelson 
wrote:

> Thanks for the interest! I agree it would be good to ship this if possible.
>
> On Tue, Oct 31, 2023 at 1:22 AM 一丝  wrote:
>
>> Unfortunately, three LGTMs obtained here did not ship. Can anyone
>> re-continue this process?
>>
>> With Keynote 13.1 supporting the SVG format, this API seems to be the
>> only way to copy and paste SVGs into Keynote in a browser.
>
>
> Could you test with the experimental-web-platform-features chrome flag
> turned on, and see if it works as intended for copy and paste from Keynote?
>
>
>>
>> 在2021年8月20日星期五 UTC+8 03:15:56 写道：
>>
>>> LGTM3 with the caveat that we should only flip this flag to ship if big
>>> customers like Sean's team are able to use this successfully to minimally
>>> cover their needs.
>>>
>>> On Thursday, August 19, 2021 at 11:57:00 AM UTC-7 Chris Harrelson wrote:
>>>
 LGTM2

 On Thu, Aug 19, 2021 at 11:46 AM Mike West  wrote:

>>> LGTM1.
>
> I think it's important that we address the TAG's concerns about
> gesture requirements and other mechanisms which might reduce the surprise
> associated with some uses of the clipboard API, but I agree with Darwin
> that shipping SVG support doesn't need to block on that conversation. That
> said, I'd encourage y'all to engage more closely with those questions.
> Marijn, you and +Victor Costan are on an internal thread on that
> topic that we should follow up on.
>
> Regarding style, this intent is the most conservative approach to
> sanitization, which has been approved by the security team. Ideally, we
> could find a way to allow style safely via the sanitization API work 
> that's
> underway separately, as Anne suggested on Mozilla's standards
> position thread
> .
> I also note that Apple's response on
> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031940.html
> seems generally positive.
>
> -mike
>
>
> On Fri, Aug 13, 2021 at 11:54 PM Sean Voisen  wrote:
>
 On Thursday, August 12th, 2021 at 12:22 PM, Alex Russell <
>> sligh...@chromium.org> wrote:
>>
>> There's a recurring debate here about the stripping of inline style
>> information; Sean, how much worse is it for styles to be stripped in your
>> use-cases? If we wait for styles to be re-added (if they can be at all) 
>> to
>> ship this, how much worse is that?
>>
>>
>> Just so I'm clear, is the debate about stripping style attributes or
>> style elements or both?
>> We would want at least one of those. Illustrator allows for exporting
>> SVG with either, though by default (including when copying to clipboard) 
>> it
>> uses style elements like so:
>>
>> .cls-1{fill:url(#radial-gradient);}.
>>
>> If both were to be sanitized away then the feature would be of more
>> limited value for our use cases.
>>
>> Sean
>>
>> On Wednesday, August 11, 2021 at 9:23:33 PM UTC-7 Marijn
>> Kruisselbrink wrote:
>>
>>> API Owners: any further thoughts on this intent? Are there any
>>> open/pending questions for us?
>>>
>>> On Thu, Jul 15, 2021 at 3:23 PM Sean Voisen 
>>> wrote:
>>>
 On Wednesday, July 7, 2021 at 1:30:51 AM UTC-7 yoav...@chromium.org
 wrote:

>
>> Web developers: Positive
>>
>>
>> Any links?
>>
>
 We have interest in using SVG support on the clipboard for web
 applications at Adobe. While this can be achieved to some extent by 
 placing
 SVG content in text/plain, proper SVG support would definitely be
 preferable.

 Cheers,
 Sean

>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "blink-dev" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send
>> an email to blink-dev+unsubscr...@chromium.org.
>
>
>> To view this discussion on the web visit
>> 

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

['Sahir Vellani' via blink-dev]

Thanks for the update Robert! That makes sense. 

What about deviceProperties? That would place the emphasis on the device 
generating the pointer event; with "properties" being generic enough to 
include different supported functions of the device. So we would have 
something like 
PointerEvent.deviceProperties.deviceId/PointerEvent.deviceProperties.preferredInkingColor
 
etc.

Would you be able to clarify the next steps once the structure name has 
been agreed upon? I believe we'll need to update the explainer, spec PR and 
change the chromium implementation. Anything else?



On Thursday, February 1, 2024 at 12:33:46 PM UTC-8 fla...@chromium.org 
wrote:

> We just discussed this yesterday where the consensus was that we thought 
> it would be pragmatic to put this new device specific identifier into a 
> common structure on the pointer event where other device specific 
> customizations could later be added (e.g. those from the pen 
> customizations proposal ). 
> This avoids needing to have new properties on the pointer event for each 
> device specific customization attribute added.
>
> Another question that came up was how universal this customization was, 
> i.e. whether there would be support for this on other platforms.
>
> @Sahir Vellani would you be able to suggest what you think the best 
> structure name / property name for pointer specific identifier properties 
> might be?
>
> I do agree with @Rick Byers that this is likely a niche API which we'll 
> likely be able to change, I'm just trying to get ahead of breaking changes 
> early.
>
> On Wed, Jan 31, 2024 at 11:33 AM Yoav Weiss (@Shopify) <
> yoav...@chromium.org> wrote:
>
>> Thanks for chiming in, Robert!
>>
>> Sahir - can you let us know once the PEWG has discussed this and you feel 
>> this is good to go?
>>
>> On Tuesday, January 23, 2024 at 8:26:32 PM UTC+1 sahir@microsoft.com 
>> wrote:
>>
>>> Thanks Rick and Robert! 
>>>
>>> Rick, I agree that it would be relatively easy to change/deprecate 
>>> deviceId. There are not too many devices at the moment that support 
>>> multiple pens, and not many web apps either. I think the cost to the 
>>> websites of not having Chrome support this for the foreseeable future is 
>>> greater than changing where the deviceId gets read from. The Pen 
>>> Customizations api looks quite cool, although deviceId is more generic.
>>>
>>> Robert, I'm happy to wait a week or two more for the PEWG to discuss 
>>> this further. Thanks for putting deviceId in the agenda, and of course we 
>>> can rework this if a more appropriate alternative is proposed. :)
>>>
>>> On Tuesday, January 23, 2024 at 11:01:05 AM UTC-8 fla...@chromium.org 
>>> wrote:
>>>
>>> On Tue, Jan 23, 2024 at 1:00 PM Robert Flack  
>>> wrote:
>>>
>>> FWIW, in the PEWG call 
>>>  last 
>>> week there was some question of how this relates to the pen 
>>> customizations proposal 
>>> . I suppose the 
>>> general question is whether this should be an additional part of some 
>>> hardware specific device customization in 
>>> pointerEvent.penCustomizationsDetails. I think there is a risk of 
>>> shipping this without consensus on the general shape, as it will make it 
>>> harder to change if it's decided there's a better way to expose the 
>>> information without breaking existing uses. We should probably take the API 
>>> that has been incubated and bring it back for discussion in the working 
>>> group.
>>>
>>>
>>> I've raised this for discussion 
>>>  
>>> to 
>>> try to reach consensus on the general idea. I also realize my comment comes 
>>> across more critical than I meant it to be. There is risk to locking in the 
>>> current proposal, but I also suspect we'd be able to make a breaking change 
>>> if needed, so I did not intend my comment to be blocking. Apologies!
>>>
>>> On Tue, Jan 23, 2024 at 12:15 PM 'Sahir Vellani' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>> Hi all, any more questions or concerns?
>>>
>>> On Thursday, January 18, 2024 at 8:44:58 PM UTC-8 Sahir Vellani wrote:
>>>
>>> Just to clarify, I've made the change in the deviceId verbiage in the 
>>> spec, not pointerId :)
>>>
>>> On Thursday, January 18, 2024 at 8:40:00 PM UTC-8 Sahir Vellani wrote:
>>>
>>> I can't say what the reasoning is for that behavior in 
>>> PointerEvent.pointerId, as I was not involved. However, I will make a 
>>> change in the spec to only use the value of 1 for primary mouse device.
>>> There may be a scenario where PointerEvent.deviceId is unsupported by 
>>> the UA (separate from an invalid id of -1); e.g, on platforms where the 
>>> feature is unimplemented. In that case, developers might have a check like 
>>> if(event.deviceId) {...}. If the deviceId is 0 for a valid reason, it will 
>>> fail that 

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Robert Flack]

We just discussed this yesterday where the consensus was that we thought it
would be pragmatic to put this new device specific identifier into a common
structure on the pointer event where other device specific customizations
could later be added (e.g. those from the pen customizations proposal
). This avoids needing to
have new properties on the pointer event for each device specific
customization attribute added.

Another question that came up was how universal this customization was,
i.e. whether there would be support for this on other platforms.

@Sahir Vellani  would you be able to suggest
what you think the best structure name / property name for pointer specific
identifier properties might be?

I do agree with @Rick Byers  that this is likely a
niche API which we'll likely be able to change, I'm just trying to get
ahead of breaking changes early.

On Wed, Jan 31, 2024 at 11:33 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Thanks for chiming in, Robert!
>
> Sahir - can you let us know once the PEWG has discussed this and you feel
> this is good to go?
>
> On Tuesday, January 23, 2024 at 8:26:32 PM UTC+1 sahir@microsoft.com
> wrote:
>
>> Thanks Rick and Robert!
>>
>> Rick, I agree that it would be relatively easy to change/deprecate
>> deviceId. There are not too many devices at the moment that support
>> multiple pens, and not many web apps either. I think the cost to the
>> websites of not having Chrome support this for the foreseeable future is
>> greater than changing where the deviceId gets read from. The Pen
>> Customizations api looks quite cool, although deviceId is more generic.
>>
>> Robert, I'm happy to wait a week or two more for the PEWG to discuss this
>> further. Thanks for putting deviceId in the agenda, and of course we can
>> rework this if a more appropriate alternative is proposed. :)
>>
>> On Tuesday, January 23, 2024 at 11:01:05 AM UTC-8 fla...@chromium.org
>> wrote:
>>
>> On Tue, Jan 23, 2024 at 1:00 PM Robert Flack  wrote:
>>
>> FWIW, in the PEWG call
>>  last week
>> there was some question of how this relates to the pen customizations
>> proposal . I suppose
>> the general question is whether this should be an additional part of some
>> hardware specific device customization in
>> pointerEvent.penCustomizationsDetails. I think there is a risk of
>> shipping this without consensus on the general shape, as it will make it
>> harder to change if it's decided there's a better way to expose the
>> information without breaking existing uses. We should probably take the API
>> that has been incubated and bring it back for discussion in the working
>> group.
>>
>>
>> I've raised this for discussion
>>  to
>> try to reach consensus on the general idea. I also realize my comment comes
>> across more critical than I meant it to be. There is risk to locking in the
>> current proposal, but I also suspect we'd be able to make a breaking change
>> if needed, so I did not intend my comment to be blocking. Apologies!
>>
>> On Tue, Jan 23, 2024 at 12:15 PM 'Sahir Vellani' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>> Hi all, any more questions or concerns?
>>
>> On Thursday, January 18, 2024 at 8:44:58 PM UTC-8 Sahir Vellani wrote:
>>
>> Just to clarify, I've made the change in the deviceId verbiage in the
>> spec, not pointerId :)
>>
>> On Thursday, January 18, 2024 at 8:40:00 PM UTC-8 Sahir Vellani wrote:
>>
>> I can't say what the reasoning is for that behavior in
>> PointerEvent.pointerId, as I was not involved. However, I will make a
>> change in the spec to only use the value of 1 for primary mouse device.
>> There may be a scenario where PointerEvent.deviceId is unsupported by the
>> UA (separate from an invalid id of -1); e.g, on platforms where the feature
>> is unimplemented. In that case, developers might have a check like
>> if(event.deviceId) {...}. If the deviceId is 0 for a valid reason, it will
>> fail that check. I see no harm in limiting the deviceId from primary mouse
>> to 1. It will avoid this interop issue and make the feature more friendly
>> to web developers.
>>
>>
>> 0 was originally reserved to mean a non-pointer device. This was
>> discussed in https://github.com/w3c/pointerevents/issues/343 where we
>> discovered that Firefox has, and continues to use 0 for mouse pointer
>> events where chrome and safari use 1.
>>
>> On Thursday, January 18, 2024 at 6:26:20 PM UTC-8 mike...@chromium.org
>> wrote:
>>
>> Forgive my ignorance around this API generally, but is there any reason
>> the spec can't require a single value? If not, why not?
>> On 1/18/24 3:05 PM, 'Sahir Vellani' via blink-dev wrote:
>>
>> Appreciate the feedback! Yes the PR was reviewed by WG members for any
>> major concerns; but I believe there will 

[blink-dev] Intent to Prototype: Automatic Fullscreen Content Setting

[Mike Wasserman]

Contact emails

m...@chromium.org


Explainer

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

Specification

https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

Design docs

Internal; will expand Explainer during prototyping.

https://docs.google.com/document/d/1yO5Ixgp6VNfYpGrqxezUmLaM-g_ZPGb16bxQ6_q9ln4

Summary

A new "Automatic Fullscreen" content setting permits
Element.requestFullscreen() without a user gesture [1].

The setting is blocked by default. Users can allow Isolated Web Apps [2],
and enterprise admins can allow additional origins.

Combined with Window Management permission [3] and unblocked popups [4],
this unlocks valuable fullscreen capabilities:

- Open a fullscreen popup on another display, from one gesture

- Show fullscreen content on multiple displays from one gesture

- Show fullscreen content on a new display, when it's connected

- Swap fullscreen windows between displays with one gesture

- Show fullscreen content after user gesture expiry or consumption

[1] Also window.open()'s experimental 'fullscreen' feature; see
https://chromestatus.com/feature/6002307972464640


[2] User control is initially scoped to security-sensitive apps; see
https://chromestatus.com/feature/5146307550248960


[3] For multi-screen window placement features; see
https://chromestatus.com/feature/5252960583942144


[4] To waive window.open()'s own user gesture requirements; see
chrome://settings/content/popups

Blink component

Blink>Fullscreen


Motivation

Some web apps (e.g. finance, gaming, point-of-sale, signage, and
presentation) require multi-screen fullscreen from one gesture.

Virtual Desktop Infrastructure (VDI) clients also require fullscreen
without a gesture to:

- Automatically extend a fullscreen desktop session onto a newly connected
display

- Request fullscreen after transient activation expiry, e.g. slow remote
host response

- Apply remote app fullscreen state locally, e.g. on app launch or system
events

- Restore fullscreen on local display changes, local user session unlocks,
other local OS Window Manager interruptions

Initial public proposal

https://github.com/whatwg/fullscreen/issues/234

Search tagsFullscreen ,
requestFullscreen 
, transient activation
, user
gesture , content
setting 
TAG review

N/A; this is not proposing a new or changed web API, but a browser-specific
permission configuration.

RisksInteroperability and Compatibility

Element.requestFullscreen() may now succeed instead of rejecting without
transient activation. The design doc considers some nuanced windowing
corner cases. This feature is initially only available to
security-sensitive apps and enterprise allow-listed origins.

Gecko & WebKit: N/A; this is not proposing a new or changed web API, but a
browser-specific permission configuration.

Web developers: Positive.

Requested by 1st and 3rd party partners, particularly around VDI:

https://github.com/w3c/window-management/issues/7
https://github.com/w3c/window-management/issues/98
https://github.com/w3c/window-management/issues/92

ErgonomicsThe explainer discusses potential feature detection methods.
Activation

Users or admins must grant the new Automatic Fullscreen content setting,
plus the Popups & Redirects content setting and the Window Management
permission, and to take full advantage of fullscreen windowing features.

Security

This capability exacerbates preexisting fullscreen usable security
concerns, so sites cannot show a permission prompt, and user controls are
initially scoped to IWA contexts.

WebView application risks

None

Debuggability

Sites can debug via Element.requestFullscreen()'s promise, which may reject
with a TypeError containing a message, supplemented by devtools console
messages. Transient activation state is exposed via
navigator.userActivation.isActive. Script can check the
window.location.href's scheme for `isolated-app:` to assess initial
availability of user control for the current context.

Is this feature fully tested by web-platform-tests

?

No. WPT coverage is not yet available, and necessitates test driver
controls for this new content setting.

DevTrial instructions
https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture/blob/main/HOWTO.md
Flag name on chrome://flags

chrome://flags/#automatic-fullscreen-content-setting

Finch feature name

Re: [blink-dev] Request for Deprecation Trial: Deprecate Mutation Events

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 8:54 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/uievents/#legacy-event-types
>
> Summary
>
> Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`,
> `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`,
> `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite
> bad for page performance, and also significantly increase the complexity of
> adding new features to the Web. These APIs were deprecated from the spec (
> https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were
> replaced (in 2012) by the much better-behaved Mutation Observer API. Usage
> of the obsolete Mutation Events must be migrated to Mutation Observer.
> Mutation events are deprecated starting in Chrome 115, and support will be
> disabled by default starting in Chrome 127, around July 30, 2024. A
> Deprecation Trial will be available starting in Chrome 124, and extending
> through Chrome 134, which can be used to extend the time a site has to
> migrate by ~9 months, until March 25, 2025.
>

>
> Blink componentBlink>DOM
> 
>
> Search tagsMutationEvent
> , DOMSubtreeModified
> ,
> DOMNodeInserted ,
> DOMNodeRemoved ,
> DOMNodeRemovedFromDocument
> ,
> DOMNodeInsertedIntoDocument
> ,
> DOMCharacterDataModified
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Chromium Trial NameMutationEvents
>
> Origin Trial documentation link
> https://developer.chrome.com/blog/mutation-events-deprecation
>
> WebFeature UseCounter namekDOMNodeRemovedEvent
>
> Risks
>
>
> Interoperability and Compatibility
>
> There are technically 9 Mutation Events, but Chromium only implements 6 of
> them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument:
> 0.006% - DOMNodeRemovedFromDocument: 0.012% - DOMCharacterDataModified:
> 0.016% - DOMNodeRemoved: 0.77% - DOMSubtreeModified: 0.81% -
> DOMNodeInserted: 1.58% The DOMNodeInsertedIntoDocument and
> DOMNodeRemovedFromDocument events are not fired by Gecko. That, plus the
> low use counters for those two plus DOMCharacterDataModified, mean that
> these three could likely be fairly easily removed after some time. The last
> three have quite significant usage, and more study and outreach will be
> required to bring this usage down below safe removal limits, which will
> take significant time. Tentatively, we're aiming for M126 as the last
> version of Chrome that supports the events above, ending July 30, 2024.
> This npm package attempts to polyfill Mutation Events using Mutation
> Observer: https://www.npmjs.com/package/mutation-events.
>

This is very exciting! Thank you for working on this.

Do you know whether the existing usage is feature checked? 1.58% seems very
high, but if it's feature checked and fallback is something like mutation
observer, then it would be a lot more safe imho. Also, do you have a sense
of where the usage is coming from (a few large frameworks vs a ton of
smaller sites)? The npm package you listed, for example, would use the
actual events if available, so sites using that polyfill would also count
towards the event usage if the browser supports those even though that's
"safe", right?


>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/807) "very strong
> positive position"
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/192)
>
> *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
>
>
> Goals for experimentation
>
>
>
> Ongoing technical constraints
>
>
>
> 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
> 
> ?No
>
> Flag name on chrome://flags
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1446498
>
> Estimated milestones
> Shipping on desktop 115
> OriginTrial desktop last 134
> OriginTrial desktop first 124
> Shipping on Android 115
> OriginTrial Android last 134
> OriginTrial Android first 124
> Shipping on WebView 115
> OriginTrial webView last 134
> OriginTrial webView 

Re: [blink-dev] Intent to Ship: CJK punctuation kerning: the CSS `text-spacing-trim` property

[Koji Ishii]

Hi Philip, thanks for the questions. Please see replies inline:

Thanks for linking the tests, judging just by the test names it looks like
> many combinations of languages and fonts are tested.
>

Yes, many combinations are to ensure they test different branches in our
code.

Some of the tests are failing though, is that expected?
>

Yes, this current implementation supports subset (see below), and failing
tests are for values that are not supported yet.

Also, I see that some of the tests don't actually use text-spacing-trim,
> are those just testing default behaviors or what's the reason?
>

Yes, the initial value `normal
`
applies the pair-kerning (adjacent) and line-end (the table below the value
list might be easier to know which value affects where). Tests without
`text-spacing-trim` are testing these behaviors.

The design doc says "This version implements a subset of the values defined
> in the spec", is that still accurate, or is there support for all
> of space-all | normal | trim-auto | trim-start | space-first | trim-all?
>

It's still accurate. The current implementation supports 4 values: normal |
trim-start | space-all | space-first. I added this to the chromestatus entry
 (I thought I did this
but it looks like it's gone somehow).

Finally, since text-spacing-trim and text-autospace are longhands
> for text-spacing, what is the plan for text-spacing? Will we introduce the
> shorthand later together with text-autospace? That should mean that
> something like `text-spacing: trim-all` won't work initially, even though
> it doesn't involve text-autospace. But on the other hand shipping the
> shorthand without text-autospace would break `text-spacing: punctuation`
> and similar. I don't have a suggestion here, but can you clarify what the
> overall plan is?
>

The current plan is to ship the shorthand when both properties ship.
Shipping the shorthand only for `text-spacing-trim` is technically
possible, but it complicates the code and tests. I think it's prudent to
defer until both properties ship.

Originally we thought the `text-autospace` could ship before
`text-spacing-trim` or together, but a blocking spec issue was found
recently. Given its complexity, it's likely to take a few quarters.

As a data point, I see that the flag in STP is called "CSS text-spacing
> property", which suggests all 3 properties behind a single flag. It might
> not ship together, but it's a good guess.


Right, the current code in WebKit under the flag isn't ready to ship yet,
but this is one of their 2024 plans discussed at the WebKit contributor
meeting. I'm talking to WebKit engineers about our status, they're
interested in seeing web developer feedback to Chromium. This is one of the
reasons I think we should ship `text-spacing-trim` first, without waiting
for `text-autospace` to be ready.

-- 
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/CAHe_1dK8uf9%3DGeK-PPx5YV7DaPBLpsyL%2BLuZXs%2BjraPMfC9F3w%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CJK punctuation kerning: the CSS `text-spacing-trim` property

[Philip Jägenstedt]

As a data point, I see that the flag in STP is called "CSS text-spacing
property", which suggests all 3 properties behind a single flag. It might
not ship together, but it's a good guess.

On Thu, Feb 1, 2024 at 12:02 PM Philip Jägenstedt 
wrote:

> Hi Koji,
>
> Thanks for linking the tests, judging just by the test names it looks like
> many combinations of languages and fonts are tested. Some of the tests are
> failing though, is that expected?
>
> Also, I see that some of the tests don't actually use text-spacing-trim,
> are those just testing default behaviors or what's the reason?
>
> The design doc says "This version implements a subset of the values
> defined in the spec", is that still accurate, or is there support for all
> of space-all | normal | trim-auto | trim-start | space-first | trim-all?
>
> Finally, since text-spacing-trim and text-autospace are longhands
> for text-spacing, what is the plan for text-spacing? Will we introduce the
> shorthand later together with text-autospace? That should mean that
> something like `text-spacing: trim-all` won't work initially, even though
> it doesn't involve text-autospace. But on the other hand shipping the
> shorthand without text-autospace would break `text-spacing: punctuation`
> and similar. I don't have a suggestion here, but can you clarify what the
> overall plan is?
>
> Best regards,
> Philip
>
> On Wed, Jan 31, 2024 at 6:38 AM Koji Ishii  wrote:
>
>> Contact emailsko...@chromium.org, lin...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
>>
>> Design docs
>>
>> https://docs.google.com/document/d/146Bupkg3nrNALL3bm8UElRd0vsLVH5807xubsnrthDw/edit?usp=sharing
>>
>> Summary
>>
>> Applies the kerning to CJK punctuation characters to produce the visually
>> pleasing typography as defined by JLREQ (Requirements for Japanese Text
>> Layout) and CLREQ (Requirements for Chinese Text Layout). Many CJK
>> punctuation characters include glyph-internal spacing. For example, the CJK
>> full stop and the CJK close parenthesis usually have glyph-internal
>> spacings on the right half of their glyph spaces, to give them a constant
>> advance as other ideographic characters. But when they appear in a row, the
>> glyph-internal spacings become excessive. This feature adjusts such
>> excessive spacing. This feature adjusts the glyph-internal spacing for 1)
>> adjacent characters (pair kerning), 2) at the line start, and 3) at the
>> line end, by using the font data.
>>
>>
>> Blink componentBlink>Layout>Inline
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/907
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/903)
>>
>> *WebKit*: Positive (https://github.com/w3c/csswg-drafts/issues/4246) A
>> flag is available in Safari Technology Preview.
>>
>> *Web developers*: Positive (
>> https://twitter.com/fontplus/status/1405020633600233479) This tweet
>> about a web font provider in Japan providing this feature in fonts got 485
>> likes as of Aug 2023.
>>
>> *Other signals*: Parts of the feature is shipping in Android 13,
>> ChromeOS 90, iOS 17, MS Word 6.0, and LibreOffice.
>>
>> 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-text?label=experimental=master=text-spacing-trim
>>
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463891
>>
>> Sample links
>> https://output.jsbin.com/figixaq
>>
>> Estimated milestones
>> Shipping on desktop 123
>> Shipping on Android 123
>> Shipping on WebView 123
>>
>> 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/5170044014690304
>>
>> Links to previous Intent discussionsIntent to prototype:
>> 

Re: [blink-dev] Intent to Ship: CJK punctuation kerning: the CSS `text-spacing-trim` property

[Philip Jägenstedt]

Hi Koji,

Thanks for linking the tests, judging just by the test names it looks like
many combinations of languages and fonts are tested. Some of the tests are
failing though, is that expected?

Also, I see that some of the tests don't actually use text-spacing-trim,
are those just testing default behaviors or what's the reason?

The design doc says "This version implements a subset of the values defined
in the spec", is that still accurate, or is there support for all
of space-all | normal | trim-auto | trim-start | space-first | trim-all?

Finally, since text-spacing-trim and text-autospace are longhands
for text-spacing, what is the plan for text-spacing? Will we introduce the
shorthand later together with text-autospace? That should mean that
something like `text-spacing: trim-all` won't work initially, even though
it doesn't involve text-autospace. But on the other hand shipping the
shorthand without text-autospace would break `text-spacing: punctuation`
and similar. I don't have a suggestion here, but can you clarify what the
overall plan is?

Best regards,
Philip

On Wed, Jan 31, 2024 at 6:38 AM Koji Ishii  wrote:

> Contact emailsko...@chromium.org, lin...@chromium.org
>
> ExplainerNone
>
> Specification
> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
>
> Design docs
>
> https://docs.google.com/document/d/146Bupkg3nrNALL3bm8UElRd0vsLVH5807xubsnrthDw/edit?usp=sharing
>
> Summary
>
> Applies the kerning to CJK punctuation characters to produce the visually
> pleasing typography as defined by JLREQ (Requirements for Japanese Text
> Layout) and CLREQ (Requirements for Chinese Text Layout). Many CJK
> punctuation characters include glyph-internal spacing. For example, the CJK
> full stop and the CJK close parenthesis usually have glyph-internal
> spacings on the right half of their glyph spaces, to give them a constant
> advance as other ideographic characters. But when they appear in a row, the
> glyph-internal spacings become excessive. This feature adjusts such
> excessive spacing. This feature adjusts the glyph-internal spacing for 1)
> adjacent characters (pair kerning), 2) at the line start, and 3) at the
> line end, by using the font data.
>
>
> Blink componentBlink>Layout>Inline
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/907
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/903)
>
> *WebKit*: Positive (https://github.com/w3c/csswg-drafts/issues/4246) A
> flag is available in Safari Technology Preview.
>
> *Web developers*: Positive (
> https://twitter.com/fontplus/status/1405020633600233479) This tweet about
> a web font provider in Japan providing this feature in fonts got 485 likes
> as of Aug 2023.
>
> *Other signals*: Parts of the feature is shipping in Android 13, ChromeOS
> 90, iOS 17, MS Word 6.0, and LibreOffice.
>
> 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-text?label=experimental=master=text-spacing-trim
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463891
>
> Sample links
> https://output.jsbin.com/figixaq
>
> Estimated milestones
> Shipping on desktop 123
> Shipping on Android 123
> Shipping on WebView 123
>
> 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/5170044014690304
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKP6u%2BXJ5Vi9aH_AVHJiFPoUM7BhSTYX-oRTPxz87c5XQ%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 

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions

[Domenic Denicola]

On Thu, Feb 1, 2024 at 5:18 PM Guido Urdaneta  wrote:

> To clarify about TAG reviews, there is no written policy prohibiting TAG
> reviews. The policy (or rather the recommended practice) in a case like
> this is to wait until there is consensus in the WG (i.e., the proposed
> changes have landed in the official spec) before requesting the TAG review.
>

I see. To be clear, this is against the recommended practice for Chromium
developers, which is to file for early TAG review as soon as code is landed
behind a flag

.

But as noted, that's only a recommendation, and not a requirement, so as
long as you file for TAG review at least 1 month before the Intent to Ship
,
that shouldn't be a problem.


>
> BTW, can you send the LGTM again? I forgot to cc blink-dev in my initial
> reply and the LGTM was sent only to my email address.
>

LGTM!


> On Thu, Feb 1, 2024 at 8:14 AM Domenic Denicola 
> wrote:
>
>> Thanks for updating the explainer!
>>
>> I'm uneasy about this working group policy prohibiting TAG reviews. Can
>> you link to where this policy is stated? If it's indeed not possible for
>> WebRTC WG members to request TAG review due to Working Group restrictions,
>> then that's probably something the API Owners need to discuss more broadly,
>> and consider for the list of acceptable exceptions
>> 
>> .
>>
>> Nevertheless, given that the design here has changed significantly over
>> the course of the Origin Trial, I think it's reasonable to delay TAG review
>> until there's been more developer and community feedback on the new API.
>> Just be aware that this could be a blocker when it comes time for Intent to
>> Ship, and please file for review early enough that we can get a reply
>> before then!
>>
>> So, LGTM to extend.
>>
>> On Mon, Jan 29, 2024 at 5:40 PM Guido Urdaneta 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 29, 2024 at 8:35 AM Domenic Denicola 
>>> wrote:
>>>
 It's exciting to see the Origin Trial system working as intended,
 giving us time to get in-the-field feedback but also stay responsive to
 ongoing standards discussions about changing the shape of the API.

 Recalling the requirements for extending an origin trial
 , we
 need to see substantial progress demonstrated in all of the following
 areas: draft spec, TAG review, signals requests, outreach for feedback from
 the spec community, and WPT tests. I think these have mostly been met, with
 the exception of TAG review. Do you think it'd be reasonable to start the
 TAG review on the constructor proposal now, or do you think there's still a
 significant chance it might change due to WG feedback, such that we're
 better of continuing to delay the review?

 I think it's too early for a TAG review because the proposal hasn't
>>> landed in the spec yet and the WebRTC WG policy nowadays is to wait for
>>> specs to be complete before requesting a TAG review.
>>>
>>>
>>>
 Also, a question on the explainer below.

 On Fri, Jan 26, 2024 at 8:27 PM Guido Urdaneta 
 wrote:

> Contact emails
>
> gui...@chromium.org, he...@google.com, agpa...@chromium.org
>
>
> Explainer
>
>
> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>

 Is this explainer up to date with the newest specification proposal? The
 specification PR you link below introduces RTCEncodedVideoFrame
 and RTCEncodedAudioFrame constructors, but the explainer doesn't seem to
 reference either of those.

>>> It is updated now :)
>>> For simplicity, the explainer uses only the RTCEncodedVideoFrame
>>> constructor.
>>>
>>>
 Additionally, the explainer seems to talk about a clone "operator" (is
 that a way of saying method?), but I don't see that in the spec PR.


>>> That part is now removed because a clone operation is already part of
>>> the spec via structuredClone() and is no longer part of this proposal.
>>>
>>>
>>>

> Specification
>
> https://github.com/w3c/webrtc-encoded-transform/pull/223/files
>
> Original I2E
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yqwA-jXv6VY/m/fCkBkclxAAAJ
>
>
>
> 

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions

[Guido Urdaneta]

To clarify about TAG reviews, there is no written policy prohibiting TAG
reviews. The policy (or rather the recommended practice) in a case like
this is to wait until there is consensus in the WG (i.e., the proposed
changes have landed in the official spec) before requesting the TAG review.

BTW, can you send the LGTM again? I forgot to cc blink-dev in my initial
reply and the LGTM was sent only to my email address.

On Thu, Feb 1, 2024 at 8:14 AM Domenic Denicola 
wrote:

> Thanks for updating the explainer!
>
> I'm uneasy about this working group policy prohibiting TAG reviews. Can
> you link to where this policy is stated? If it's indeed not possible for
> WebRTC WG members to request TAG review due to Working Group restrictions,
> then that's probably something the API Owners need to discuss more broadly,
> and consider for the list of acceptable exceptions
> 
> .
>
> Nevertheless, given that the design here has changed significantly over
> the course of the Origin Trial, I think it's reasonable to delay TAG review
> until there's been more developer and community feedback on the new API.
> Just be aware that this could be a blocker when it comes time for Intent to
> Ship, and please file for review early enough that we can get a reply
> before then!
>
> So, LGTM to extend.
>
> On Mon, Jan 29, 2024 at 5:40 PM Guido Urdaneta 
> wrote:
>
>>
>>
>> On Mon, Jan 29, 2024 at 8:35 AM Domenic Denicola 
>> wrote:
>>
>>> It's exciting to see the Origin Trial system working as intended, giving
>>> us time to get in-the-field feedback but also stay responsive to ongoing
>>> standards discussions about changing the shape of the API.
>>>
>>> Recalling the requirements for extending an origin trial
>>> , we
>>> need to see substantial progress demonstrated in all of the following
>>> areas: draft spec, TAG review, signals requests, outreach for feedback from
>>> the spec community, and WPT tests. I think these have mostly been met, with
>>> the exception of TAG review. Do you think it'd be reasonable to start the
>>> TAG review on the constructor proposal now, or do you think there's still a
>>> significant chance it might change due to WG feedback, such that we're
>>> better of continuing to delay the review?
>>>
>>> I think it's too early for a TAG review because the proposal hasn't
>> landed in the spec yet and the WebRTC WG policy nowadays is to wait for
>> specs to be complete before requesting a TAG review.
>>
>>
>>
>>> Also, a question on the explainer below.
>>>
>>> On Fri, Jan 26, 2024 at 8:27 PM Guido Urdaneta 
>>> wrote:
>>>
 Contact emails

 gui...@chromium.org, he...@google.com, agpa...@chromium.org


 Explainer


 https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md

>>>
>>> Is this explainer up to date with the newest specification proposal? The
>>> specification PR you link below introduces RTCEncodedVideoFrame
>>> and RTCEncodedAudioFrame constructors, but the explainer doesn't seem to
>>> reference either of those.
>>>
>> It is updated now :)
>> For simplicity, the explainer uses only the RTCEncodedVideoFrame
>> constructor.
>>
>>
>>> Additionally, the explainer seems to talk about a clone "operator" (is
>>> that a way of saying method?), but I don't see that in the spec PR.
>>>
>>>
>> That part is now removed because a clone operation is already part of the
>> spec via structuredClone() and is no longer part of this proposal.
>>
>>
>>
>>>
 Specification

 https://github.com/w3c/webrtc-encoded-transform/pull/223/files

 Original I2E


 https://groups.google.com/a/chromium.org/g/blink-dev/c/yqwA-jXv6VY/m/fCkBkclxAAAJ



 Summary

 Add a feature to the WebRTC Encoded Transform API that allows
 manipulating audio and video frame metadata.

 Background: A number of use cases have been identified that require the
 manipulation of the metadata of WebRTC encoded frames without decoding them
 first.

 These include:

 - Receiving data in encoded form and forwarding it.

 - Sending data that has been encoded previously

 - Sending data that has been received in encoded form

 In particular, we want to support the use case of glitch-free
 forwarding of media coming from multiple redundant peer connections that
 provide the same media payloads but with different metadata.

 Issue links:  

 https://github.com/w3c/webrtc-nv-use-cases/issues/77

 https://github.com/w3c/webrtc-nv-use-cases/issues/122

 https://github.com/w3c/webrtc-encoded-transform/issues/211



 Blink component

 Blink>WebRTC