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

[Koji Ishii]

Contact emailsko...@chromium.org, lin...@chromium.org

ExplainerNone

Specificationhttps://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 this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dLUB%3D%3Dt8Qp102HDPUQiuM1qAG_da3bb44mG22FAVP%3Dk6A%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Call stacks in crash reports from unresponsive web pages

['Issack John' via blink-dev]

Hi all, 

Thank you for the great questions and insights. 

This feature will be restricted to only the execution stacks in the main 
world. As Rick described, extension code injected into the main world may 
be visible.

*How do you know from the IO thread what the main thread isolate is?*
Because blink::MainThreadIsolate is deprecated, I believe we have some 
options.
1. V8::PerIsolateData::MainThreadIsolate, unless that is also deprecated. 
(No code comment saying that it is.)
2. 
MainThreadSchedulerImpl::ForEachMainThreadIsolate(base::RepeatingCallback callback)
Currently, this function only calls the callback for a single isolate 
but IIUC, we can check if the isolate has a main world and that would be 
the main thread isolate?

The design document now includes the questions that I have received. I am 
working on getting more information to address the remaining technical 
questions.

Issack
On Thursday, January 25, 2024 at 8:05:14 AM UTC-8 Dave Tapuska wrote:

> Yes I was thinking of how the stack trace format was standardized as well. 
> How do wasm call stacks work with this proposal?
>
> dave.
>
> On Wed, Jan 24, 2024 at 8:27 PM Domenic Denicola  
> wrote:
>
>> I agree with Dave's take on the importance of not including extension 
>> scripts themselves, and Rick's take on how it is OK to include 
>> extension-injected main world scripts.
>>
>> One additional interop concern that's worth highlighting here is that the 
>> stack trace format itself is not compatible across browsers. However, I 
>> don't think that should block this intent. It is already exposed throughout 
>> the web platform (via the `error.stack` getter), and there is already a lot 
>> of software, both client- and server-side, which deals with parsing the 
>> different browsers' formats. I don't think this would make the situation 
>> any worse.
>>
>> I do wish that one day browsers would get together and standardize the 
>> stack trace format. https://github.com/tc39/proposal-error-stacks is one 
>> attempt at that, but it has been largely dormant for 3 years.
>>
>> On Thu, Jan 25, 2024 at 5:59 AM Rick Byers  wrote:
>>
>>> Not to distract from Dave's good technical questions. But I just wanted 
>>> to say that I'm quite excited about this work - I think it's an important 
>>> capability for any serious platform to have that app developers can get 
>>> actionable crash and hang reports, and this has been a gap. Thank you for 
>>> working on it! Don't hesitate to reach out if I can help unblock progress 
>>> in any way.
>>>
>>> What you have listed as a spec is more of a design doc so you'll 
>>> eventually need a formal spec. But the reporting spec editor @Ian 
>>> Clelland mentioned over breakfast to me today that he was helping to 
>>> support this work, so that's great to hear.
>>>
>>> Dave's question about extensions in the main thread and privacy 
>>> implications is a good one. My initial personal take is that we probably 
>>> shouldn't report from extension isolated worlds, but when an extension 
>>> injects script into the main world, I think I can argue that they're 
>>> explicitly informing the site developer about their presence. In practice I 
>>> believe sites can detect such extensions already if suitably motivated (eg. 
>>> hook into the prototype of various APIs and identify their calling patterns 
>>> or look at JS exception stack traces). I can see an argument for not giving 
>>> sites easy access to such information in real-time and wonder if this has 
>>> come up already for the self-profiling API proposal 
>>> ? But for an asynchronous 
>>> crash report sent only after the page has been shut down, I personally 
>>> don't think it's a threat we should be trying to defend against. I'd go 
>>> even further and say that if a site is hanging or crashing only under the 
>>> presence of extension-injected code in the main world, then that's critical 
>>> information for the site owner to know from a customer support perspective.
>>>
>>> Rick
>>>
>>> On Wed, Jan 24, 2024 at 3:10 PM Dave Tapuska  
>>> wrote:
>>>
 Just a few thoughts...

 I haven't seen a proposed implementation but I presume you are going to 
 restrict this only to execution stacks in the main world? 
 If you get an extension executing scripts in the main world how will 
 you prevent the endpoint from knowing about the agent's execution 
 environment such as what extensions they have installed?
 How do you know from the IO thread what the main thread isolate is? 
 (blink::MainThreadIsolate is deprecated, please don't use it).
 How do document policies work across same origin documents? What realms 
 are you checking that the policy applies, do you walk the stack looking at 
 realms and checking if the policies apply? Or is it the current realm or 
 incumbent realm or what? 

 dave.

 On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via 

[blink-dev] Chromium’s migration to the new issue tracker begins Feb 2

['Joe Gregorio' via blink-dev]

Hi all,

As we shared last year
,
Chromium is moving to a different issue tracker to provide a well-supported
user experience for the long term. Migration is on track to begin February
2, 2024 at 5pm PST, and we expect migration will be completed by the end of
day February 4, 2024 PST. There will be downtime during this period as
Chromium’s Monorail project will be marked as read-only and the new Issue
Tracker will not yet be available.

If any critical issues arise during this period, please follow the
escalation paths below:

   -

   P0 Security bugs: email secur...@chromium.org
   -

   P0 General bugs: email file-a...@chromium.org


For all non-critical issues, please wait until the migration is complete to
file in Chromium’s new Issue Tracker.

We will share daily updates through migration, as well as confirm via email
once the new Issue Tracker is ready for use. Also, emails later in the week
will include links to documentation on the new issue tracker.

You can reach out at any time to issue-tracker-supp...@chromium.org with
questions or concerns.

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

Re: [blink-dev] Intent to Ship: CSS light-dark() Color Function

[Daniel Bratell]

LGTM3

/Daniel

On 2024-01-30 21:23, Mike Taylor wrote:


LGTM2

On 1/30/24 1:11 PM, Chris Harrelson wrote:

LGTM1

On Tue, Jan 30, 2024 at 10:08 AM Rune Lillesveen 
 wrote:



Contact emails

futh...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-color-5/#light-dark


Summary

Allows authors to provide separate colors for light and dark
color-schemes on a per element basis. System colors and UA form
controls are rendered with different colors depending on the
color-scheme set on an element. Authors can have the same
possibility through the light-dark() function: #target {
background-color: light-dark(lime, green); } The #target element
will have a green background if the used color-scheme for the
element is 'dark'. Otherwise, the background will be lime.



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1856999) Shipped in 120

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=262914) Enabled by
default: https://github.com/WebKit/WebKit/pull/23364

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

Colors in the light-dark() function can be edited like it is
currently possible for the color-mix() function. No changes needed.



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

Existing tests:
https://wpt.fyi/results/css/css-color/light-dark-basic.html
https://wpt.fyi/results/css/css-color/light-dark-currentcolor.html
https://wpt.fyi/results/css/css-color/light-dark-inheritance.html
To be added by Chromium implementation:
https://wpt.fyi/results/css/css-color/light-dark-currentcolor-in-color.html

(https://chromium-review.googlesource.com/c/chromium/src/+/5245470/5/third_party/blink/web_tests/external/wpt/css/css-color/light-dark-currentcolor-in-color.html)




Flag name on chrome://flags

None


Finch feature name

CSSLightDarkColors


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1490618


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

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen


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

.

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

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To 

Re: [blink-dev] Intent to Ship: CSS light-dark() Color Function

[Mike Taylor]

LGTM2

On 1/30/24 1:11 PM, Chris Harrelson wrote:

LGTM1

On Tue, Jan 30, 2024 at 10:08 AM Rune Lillesveen 
 wrote:



Contact emails

futh...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-color-5/#light-dark


Summary

Allows authors to provide separate colors for light and dark
color-schemes on a per element basis. System colors and UA form
controls are rendered with different colors depending on the
color-scheme set on an element. Authors can have the same
possibility through the light-dark() function: #target {
background-color: light-dark(lime, green); } The #target element
will have a green background if the used color-scheme for the
element is 'dark'. Otherwise, the background will be lime.



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1856999) Shipped in 120

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=262914) Enabled by
default: https://github.com/WebKit/WebKit/pull/23364

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

Colors in the light-dark() function can be edited like it is
currently possible for the color-mix() function. No changes needed.



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

Existing tests:
https://wpt.fyi/results/css/css-color/light-dark-basic.html
https://wpt.fyi/results/css/css-color/light-dark-currentcolor.html
https://wpt.fyi/results/css/css-color/light-dark-inheritance.html
To be added by Chromium implementation:
https://wpt.fyi/results/css/css-color/light-dark-currentcolor-in-color.html

(https://chromium-review.googlesource.com/c/chromium/src/+/5245470/5/third_party/blink/web_tests/external/wpt/css/css-color/light-dark-currentcolor-in-color.html)




Flag name on chrome://flags

None


Finch feature name

CSSLightDarkColors


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1490618


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

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen


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

.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8UVSF9e0BeJE1dVaksDHJ4QGniGa8rqEkn401JtYDDjg%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 

Re: [blink-dev] Intent to Ship: CSS light-dark() Color Function

[Chris Harrelson]

LGTM1

On Tue, Jan 30, 2024 at 10:08 AM Rune Lillesveen 
wrote:

> Contact emailsfuth...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-color-5/#light-dark
>
> Summary
>
> Allows authors to provide separate colors for light and dark color-schemes
> on a per element basis. System colors and UA form controls are rendered
> with different colors depending on the color-scheme set on an element.
> Authors can have the same possibility through the light-dark() function:
> #target { background-color: light-dark(lime, green); } The #target element
> will have a green background if the used color-scheme for the element is
> 'dark'. Otherwise, the background will be lime.
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1856999) Shipped in 120
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=262914)
> Enabled by default: https://github.com/WebKit/WebKit/pull/23364
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> Colors in the light-dark() function can be edited like it is currently
> possible for the color-mix() function. No changes needed.
>
>
> 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
>
> Existing tests:
> https://wpt.fyi/results/css/css-color/light-dark-basic.html
> https://wpt.fyi/results/css/css-color/light-dark-currentcolor.html
> https://wpt.fyi/results/css/css-color/light-dark-inheritance.html To be
> added by Chromium implementation:
> https://wpt.fyi/results/css/css-color/light-dark-currentcolor-in-color.html
> (
> https://chromium-review.googlesource.com/c/chromium/src/+/5245470/5/third_party/blink/web_tests/external/wpt/css/css-color/light-dark-currentcolor-in-color.html)
>
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameCSSLightDarkColors
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1490618
>
> 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/4909742688567296
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> Rune Lillesveen
>
> --
> 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/CACuPfeRdn47UWS8NzHSxokHbkEwkyXbqqceBJg50QSGh3Q4sQg%40mail.gmail.com
> 
> .
>

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

[blink-dev] Intent to Ship: CSS light-dark() Color Function

[Rune Lillesveen]

Contact emailsfuth...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-color-5/#light-dark

Summary

Allows authors to provide separate colors for light and dark color-schemes
on a per element basis. System colors and UA form controls are rendered
with different colors depending on the color-scheme set on an element.
Authors can have the same possibility through the light-dark() function:
#target { background-color: light-dark(lime, green); } The #target element
will have a green background if the used color-scheme for the element is
'dark'. Otherwise, the background will be lime.


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1856999) Shipped in 120

*WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=262914)
Enabled by default: https://github.com/WebKit/WebKit/pull/23364

*Web developers*: No signals

*Other signals*:

WebView application risks

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

None


Debuggability

Colors in the light-dark() function can be edited like it is currently
possible for the color-mix() function. No changes needed.


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

Existing tests: https://wpt.fyi/results/css/css-color/light-dark-basic.html
https://wpt.fyi/results/css/css-color/light-dark-currentcolor.html
https://wpt.fyi/results/css/css-color/light-dark-inheritance.html To be
added by Chromium implementation:
https://wpt.fyi/results/css/css-color/light-dark-currentcolor-in-color.html
(
https://chromium-review.googlesource.com/c/chromium/src/+/5245470/5/third_party/blink/web_tests/external/wpt/css/css-color/light-dark-currentcolor-in-color.html)



Flag name on chrome://flagsNone

Finch feature nameCSSLightDarkColors

Requires code in //chrome?False

Tracking bughttps://crbug.com/1490618

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

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen

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

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

[Philip Jägenstedt]

Thanks Thomas, looking forward to being able to say LGTM to this :)

I agree that it would be ideal if the unprefixed API is supported on iOS
before we remove the video-specific prefixed APIs in Chrome, so that people
can have confidence their updated code will work in both Chrome and Safari.

On Mon, Jan 29, 2024 at 8:43 PM Thomas Guilbert 
wrote:

> Ok for a 6 months trial, with the possibility to extend it further. I will
> wait for the remaining security/privacy approvals and then update this
> thread again.
>
> Additionally, someone commented on the WebKit positions standards thread
> 
>  that
> the next version of Safari will have support for the fullscreen API (still
> subject to change before shipping). It would be great timing if the API
> ships on iOS, to minimize the work for web authors as they switch away from
> the API.
>
> On Fri, Jan 26, 2024 at 6:26 AM Philip Jägenstedt 
> wrote:
>
>> https://sites.google.com/a/chromium.org/dev/blink/launching-features
>> doesn't give any guidance on the timeline, so let's just pick a timeline
>> that makes sense for this case. It's been up to a year in other cases.
>>
>> Since feature detection is common, we have to remove the whole API
>> surface and let code that depends on it throw exceptions. We won't be able
>> to print anything helpful to the console informing developers that there is
>> a deprecation trial. From their point of view it will simply be removed,
>> and they might find out about the deprecation trial if they do some further
>> research.
>>
>> Since the cost of supporting these APIs is very low, I think we
>> should give developers plenty of time. But usage is already so low that
>> it's not a certainty that anyone will really use the trial. So how about we
>> start with 6 months, and if we see that there are sites using the trial to
>> re-enable the feature, then we extend it by another 6 months. Would that
>> work?
>>
>> On Thu, Jan 25, 2024 at 9:22 PM Thomas Guilbert 
>> wrote:
>>
>>> Thank you Wesley for the useful information!
>>>
>>> > What timeline do you have in mind?
>>> I'm not sure what reasonable timelines are, not having dealt with
>>> deprecations before. Is 3 months for a deprecation trial acceptable?
>>> Devtools should already have deprecation warnings
>>> ,
>>> but I don't see them in my console.
>>>
>>> I had looked at the only site listed for the
>>> https://chromestatus.com/metrics/feature/timeline/popularity/170
>>> use-counter. They are directly calling the API for their overlay welcome
>>> video, but the page seemed to work fine with the API disabled. I don't
>>> think the fullscreen actually happens, without the user interaction...
>>>
>>> This use counter shows a spike up from December to January
>>> https://chromestatus.com/metrics/feature/timeline/popularity/168. 5
>>> links are using https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js,
>>> one link is also playing an overlay video intro.
>>>
>>> On Thu, Jan 25, 2024 at 12:25 AM Philip Jägenstedt 
>>> wrote:
>>>
 I'm also happy to support a plan to deprecate and remove. The use
 counter that best represents worst-case user impact at
 https://chromestatus.com/metrics/feature/timeline/popularity/170 at
 ~0.001%. But that's only when fullscreen actually happens (on user
 interaction) and it's very hard to say what proportion of sites could
 *potentially* hit this code path, especially given the ubiquitous
 pattern of trying multiple API names that's been necessary forever with
 fullscreen, so that some sites will just fall back to a working API.

 What timeline do you have in mind?

 On Thu, Jan 25, 2024 at 2:19 AM Domenic Denicola 
 wrote:

> Thanks Thomas for all your work here! Your HTTP Archive survey seems
> promising to me: it sounds like there are no regressions, and you found
> some great places to perform outreach. (Hi Wesley!)
>
> I'm happy to LGTM this as soon as the privacy/security reviews are
> approved and you've picked a target experiment timeline.
>
> On Thu, Jan 25, 2024 at 10:00 AM Wesley Luyten 
> wrote:
>
>> Wesley from Mux here. I saw the issue come by.
>>
>> We'd be happy those API's could get deprecated and unified into the
>> new one.
>>
>> Our Media Chrome (library, not browser) implementation handles this
>> gracefully, some code here
>>
>> https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636
>>
>> The Vimeo player uses a variant of
>> https://github.com/bdougherty/BigScreen, a similar popular library
>> is https://github.com/sindresorhus/screenfull
>>
>> Just