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

[Koji Ishii]

Hi Kagami,

Thank you for the information and sorry about the misunderstanding. Fixed
the chromestatus entry .

On Wed, Jan 31, 2024 at 8:30 PM Kagami Rosylight 
wrote:

>
> Hi Blink people,
>
> I think there was a misunderstanding while reading Mozilla's standards
> position issue; the issue currently has no response from Mozilla employee
> and thus should be understood as No Signal rather than Positive.
>
> I hope this makes sense.
> On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 ko...@chromium.org
> 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&label=master&aligned&q=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_1dJ8gGpY-LiVfeFwNa8q%3D%3Dv%3DSaSWuQWftcn-y98JehQyew%40mail.gmail.com.

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

[Kagami Rosylight]

Hello, Koji Ishii;

I think this post has a mistake about Mozilla's standards position. 
https://github.com/mozilla/standards-positions/issues/903 is empty without 
Mozilla employee's comment, so I think it should be treated as No Signal 
here.

Thanks!
On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 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&label=master&aligned&q=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/6f18c041-ba43-435f-8b1b-35ae917775c2n%40chromium.org.

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

[Kagami Rosylight]

Hi Blink people,

I think there was a misunderstanding while reading Mozilla's standards 
position issue; the issue currently has no response from Mozilla employee 
and thus should be understood as No Signal rather than Positive.

I hope this makes sense.
On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 ko...@chromium.org 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&label=master&aligned&q=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/f2665508-12c3-46c1-8b38-094aa9db320bn%40chromium.org.

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

[Kagami Rosylight]

Hello, Koji Ishii;

I think this post includes a mistake about Mozilla's standards position. 
https://github.com/mozilla/standards-positions/issues/903 does not have any 
comment from Mozilla employee so far, so I think it should be No Signal 
instead.
On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 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&label=master&aligned&q=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/dde957df-0f82-42ce-82b0-962b1cf67a6en%40chromium.org.

[blink-dev] Intent to Ship: Element Reflection

[alice]

Contact emails
al...@igalia.com, meredi...@chromium.org

Explainer
https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references

Specification
https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
https://w3c.github.io/aria/#ARIAMixin

Summary
This feature allows for ARIA relationship attributes to be reflected in
IDL as element references rather than DOMStrings.

Note: This intent specifically concerns the ARIA attributes using
Element Reflection, i.e. the attributes in the ARIAMixin interface with
a type of Element or FrozenArray. popoverTargetElement, which
also uses Element Reflection, is already shipping in Blink and WebKit.

Blink component
Blink>DOM

TAG review
https://github.com/w3ctag/design-reviews/issues/134

TAG review status
Issues addressed

Risks

Interoperability and Compatibility

Gecko: Under consideration 
https://github.com/mozilla/standards-positions/issues/200
https://bugzilla.mozilla.org/show_bug.cgi?id=1769586

WebKit: Shipped/Shipping
(https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151)
Mentioned in STP release notes:
https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
Was shipped in Safari 16.4 but wasn't mentioned in release notes there.

Web developers: Requested by Web Component authors in particular as a
means to implement ARIA relationships for elements inside of Shadow DOM.

Activation
This feature is not completely polyfillable; ID references across shadow
root boundaries are not possible to implement on top of existing APIs.

WebView application risks
None

Debuggability
Developers can use console.log to access the value for IDL attributes
set via this API, and the Accessibility pane to confirm that the
attributes are correctly reflected in the accessibility tree.

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?
https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
the reflection part of the API works correctly.
WPT doesn't yet offer a way to test the relevant accessibility tree
mappings.

Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://crbug.com/981423

Measurement
Per-attribute UseCounters: 
V8Element_AriaActiveDescendantElement_AttributeGetter 
V8Element_AriaActiveDescendantElement_AttributeSetter 
V8Element_AriaControlsElements_AttributeGetter 
V8Element_AriaControlsElements_AttributeSetter (etc) 

V8ElementInternals_AriaActiveDescendantElement_AttributeGetter 
V8ElementInternals_AriaActiveDescendantElement_AttributeSetter 
V8ElementInternals_AriaControlsElements_AttributeGetter 
V8ElementInternals_AriaControlsElements_AttributeSetter (etc)

Estimated milestones
123 or 124

Anticipated spec changes
None

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

Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ

-- 
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/865bf3bd2e6a58da9fc3424ed957ceee%40igalia.com.

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

[Kagami Rosylight]

Oops, the approved emails are now coming. Sorry for the spam, and thank you 
for fixing it 👍

On Wednesday, January 31, 2024 at 4:10:02 PM UTC+1 Kagami Rosylight wrote:

> Hello, Koji Ishii;
>
> I think this post has a mistake about Mozilla's standards position. 
> https://github.com/mozilla/standards-positions/issues/903 is empty 
> without Mozilla employee's comment, so I think it should be treated as No 
> Signal here.
>
> Thanks!
> On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 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&label=master&aligned&q=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/b13e70e9-7d27-4399-b11c-af75844a5554n%40chromium.org.

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

[Yoav Weiss (@Shopify)]

LGTM1

On Friday, January 26, 2024 at 10:27:50 AM UTC+1 Noam Rosenthal wrote:

Contact emailsjap...@chromium.org, nrosent...@chromium.org

Explainerhttps://github.com/WICG/view-transitions/blob/main/
navigation-activation-explainer.md

Specificationhttps://html.spec.whatwg.org/multipage/nav-history-apis.
html#navigation-activation-interface

Summary

navigation.activation stores state about when the current Document was 
activated (e.g., when it was initialized, or restored from the back/forward 
cache).


I was confused by "when" here (as we already shipped activationStart 
).
 
The explainer does a good job of explaining this though.



Blink componentBlink>History 


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

None


*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/928
)

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

*Web developers*: Positive

*Other signals*:

Security

This is a cross-document (navigation) feature, so designing it we needed to 
take care of cross-origin navigation related risks. Since 
`navigation.activation` is part of the navigation API, it uses the same 
semantics and protections. We only expose things that are otherwise exposed 
by the navigation API or in other means.


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/navigation-api/navigation-
activation?label=master&label=experimental&aligned&q=navigation%20activation


Flag name on chrome://flagsNavigationActivation

Finch feature nameNone

Non-finch justification

It's a web-API, exposing it gradually doesn't make sense.


Requires code in //chrome?False

Estimated milestonesShipping on desktop123Shipping on Android123Shipping on 
WebView123Shipping on WebView123

Anticipated spec changes

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

Link to entry on the Chrome Platform Statushttps://chromestatus.com/
feature/5076557983121408

Links to previous Intent discussionsIntent to prototype: https://groups.
google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LJa-_
9cEjMU3Ds660KmW0u_G_M9S1Ah-14gAfk9Qhrp2g%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/bda4f055-7c7a-4684-b8f3-42ee1cdd786cn%40chromium.org.

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

[Yoav Weiss (@Shopify)]

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 be more comprehensive feedback 
> once the Level 3 spec lands. Regarding your concern, the language is based 
> on that of PointerEvent.pointerId. The ultimate goal here is to 
> differentiate between devices, and like pointerId, the way the ids are 
> assigned has been left to the UA. I think web developers should be able to 
> rely on PointerEvent.pointerType to confirm whether the pointer event comes 
> from the primary mouse device. In Chromium, we transmit 1 for the mouse for 
> PointerEvent.deviceId.
>
> On Wednesday, January 17, 2024 at 7:39:48 AM UTC-8 yoav...@chromium.org 
> wrote:
>
> On Wednesday, January 17, 2024 at 3:51:59 PM UTC+1 vmp...@google.com 
> wrote:
>
> On Thu, Jan 11, 2024 at 6:08 PM 'Sahir Vellani' via blink-dev <
> blin...@chromium.org> wrote:
>
> Hi all, good news! 
>
> Reviving this thread because we have accomplished:
> 1. TAG Review Completion:  Extending the PointerEvent with Unique 
> DeviceId Attribute · Issue #880 · w3ctag/design-reviews (github.com) 
> 

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

[Mike Taylor]

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 fullscreen APIs have been available since Chrome M71.
>
> Experiment timeline 
>
> TBD, with a proposed 3 months duration
>
> Blink component 
>
> Blink>Fullscreen
> Blink>Media>Video
>
> TAG review 
>
> None
>
> TAG review status 
>
> Not applicable
>
> Risks 
> Interoperability and Compatibility 
>
> Web Compatibility:
>
> Removing non-standard APIs should overall help web compatibility, and 
> encourage web authors to use the unprefixed APIs. Some experiences might be 
> broken by this change, thus justifying this deprecation trial. The API has 
> been deprecated for a significant amount of time however, and usage has 
> gone down.
>
> This would only be an issue for websites that *only* support the prefixed 
> APIs.
>
>
> Interoperability:
>
>
> All browsers have shipped the new APIs, most of them using an unprefixed 
> version (Safari on iOS being the only remaining prefixed-only API). See 
> also 
> https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility
>
>
> Gecko: 
>
>
> WebKit: 
>
> Web developers:
>
> Other signals:
>
> Activation 
>
> Impact on the Ads ecosystem:
>
> N/A
>
>
> 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?
>
> Potentially. The deprecation trial should give a heads up and appropriate 
> time for apps to switch over to the unprefixed APIs.
>
>
>
> Ongoing technical constraints 
>
> None
>
>
> Debuggability 
>
> N/A
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)? 
>
> Yes - the prefixed API will be removed across all platforms.
>
> Is this feature fully tested by web-platform-tests 
> 
> ? 
>
> Yes
>
> WPTs testing the prefixes are removed: 
> https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html
>
> WPTs testing the new API: 
> https://github.com/web-platform-tests/wpt/tree/master/fullscreen/api
>
>
> Flag name on chrome://flags 
>
> None
>
> Finch feature name 
>
> PrefixedVideoFullscreen
>
> Non-finch justification 
>
> None
>
> Requires code in //chrome? 
>
> False
>
> Launch bug 
>
> None
>
> Estimated milestones 
>
> DevTrial on desktop
>
> 123
>
> DevTrial on Android
>
> 123
>
>
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/5259513871466496
>
> -- 
>
> You received this message because you are subscribed

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

[Chris Harrelson]

LGTM2

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

> LGTM1
>
> On Friday, January 26, 2024 at 10:27:50 AM UTC+1 Noam Rosenthal wrote:
>
> Contact emailsjap...@chromium.org, nrosent...@chromium.org
>
> Explainerhttps://github.com/WICG/view-transitions/blob/main/
> navigation-activation-explainer.md
>
> Specificationhttps://html.spec.whatwg.org/multipage/nav-history-apis.
> html#navigation-activation-interface
>
> Summary
>
> navigation.activation stores state about when the current Document was
> activated (e.g., when it was initialized, or restored from the back/forward
> cache).
>
>
> I was confused by "when" here (as we already shipped activationStart
> ).
> The explainer does a good job of explaining this though.
>
>
>
> Blink componentBlink>History
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/921
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (https://github.com/mozilla/
> standards-positions/issues/928)
>
> *WebKit*: No signal (https://github.com/WebKit/
> standards-positions/issues/282)
>
> *Web developers*: Positive
>
> *Other signals*:
>
> Security
>
> This is a cross-document (navigation) feature, so designing it we needed
> to take care of cross-origin navigation related risks. Since
> `navigation.activation` is part of the navigation API, it uses the same
> semantics and protections. We only expose things that are otherwise exposed
> by the navigation API or in other means.
>
>
> 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/navigation-api/navigation-
> activation?label=master&label=experimental&aligned&q=
> navigation%20activation
>
>
> Flag name on chrome://flagsNavigationActivation
>
> Finch feature nameNone
>
> Non-finch justification
>
> It's a web-API, exposing it gradually doesn't make sense.
>
>
> Requires code in //chrome?False
>
> Estimated milestonesShipping on desktop123Shipping on Android123Shipping
> on WebView123Shipping on WebView123
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5076557983121408
>
> Links to previous Intent discussionsIntent to prototype: https://groups.
> google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LJa-_
> 9cEjMU3Ds660KmW0u_G_M9S1Ah-14gAfk9Qhrp2g%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/bda4f055-7c7a-4684-b8f3-42ee1cdd786cn%40chromium.org
> 
> .
>

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

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

[Daniel Bratell]

LGTM3

/Daniel

On 2024-01-31 17:53, Chris Harrelson wrote:

LGTM2

On Wed, Jan 31, 2024 at 8:00 AM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

On Friday, January 26, 2024 at 10:27:50 AM UTC+1 Noam Rosenthal wrote:

Contact emailsjap...@chromium.org, nrosent...@chromium.org



Explainerhttps://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md





Specificationhttps://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-activation-interface



Summary

navigation.activation stores state about when the current
Document was activated (e.g., when it was initialized, or
restored from the back/forward cache).


I was confused by "when" here (as we already shipped
activationStart

).
The explainer does a good job of explaining this though.



Blink componentBlink>History



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


TAG review statusIssues addressed

Risks


Interoperability and Compatibility

None



/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/928
)

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/282
)

/Web developers/: Positive

/Other signals/:

Security

This is a cross-document (navigation) feature, so designing it
we needed to take care of cross-origin navigation related
risks. Since `navigation.activation` is part of the navigation
API, it uses the same semantics and protections. We only
expose things that are otherwise exposed by the navigation API
or in other means.



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/navigation-api/navigation-activation?label=master&label=experimental&aligned&q=navigation%20activation





Flag name on chrome://flagsNavigationActivation

Finch feature nameNone

Non-finch justification

It's a web-API, exposing it gradually doesn't make sense.



Requires code in //chrome?False

Estimated milestonesShipping on desktop123Shipping on
Android123Shipping on WebView123Shipping on WebView123

Anticipated spec changes

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

None

Link to entry on the Chrome Platform
Statushttps://chromestatus.com/feature/5076557983121408


Links to previous Intent discussionsIntent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LJa-_9cEjMU3Ds660KmW0u_G_M9S1Ah-14gAfk9Qhrp2g%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/bda4f055-7c7a-4684-b8f3-42ee1cd

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

[Philip Jägenstedt]

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 fullscreen APIs have been available since Chrome M71.
>>
>> Experiment timeline
>>
>> TBD, with a proposed 3 months duration
>>
>> Blink component
>>
>> Blink>Fullscreen
>> Blink>Media>Video
>>
>> TAG review
>>
>> None
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Web Compatibility:
>>
>> Removing non-standard APIs should overall help web compatibility, and
>> encourage web authors to use the unprefixed APIs. Some experiences might be
>> broken by this change, thus justifying this deprecation trial. The API has
>> been deprecated for a significant amount of time however, and usage has
>> gone down.
>>
>> This would only be an issue for websites that *only* support the prefixed
>> APIs.
>>
>>
>> Interoperability:
>>
>>
>> All browsers have shipped the new APIs, most of them using an unprefixed
>> version (Safari on iOS being the only remaining prefixed-only API). See
>> also
>> https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility
>>
>>
>> Gecko:
>>
>>
>> WebKit:
>>
>> Web developers:
>>
>> Other signals:
>>
>> Activation
>>
>> Impact on the Ads ecosystem:
>>
>> N/A
>>
>>
>> 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?
>>
>> Potentially. The deprecation trial should give a heads up and appropriate
>> time for apps to switch over to the unprefixed APIs.
>>
>>
>>
>> Ongoing technical constraints
>>
>> None
>>
>>
>> Debuggability
>>
>> N/A
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes - the prefixed API will be removed across all platforms.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> WPTs testing the prefixes are removed:
>> https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html
>>
>> WPTs testing the new API:
>> https://github.com/web-platfo

Re: [blink-dev] Intent to Ship: Element Reflection

[Philip Jägenstedt]

Hi Alice,

For testing of these in WPT, do you have some details on what's missing?
It's already possible to get the accessible name and role for an element:
https://web-platform-tests.org/writing-tests/testdriver.html#accessibility

I suspect that won't help, but there's an experimental/tentative API being
proposed for testdriver.js here:
https://github.com/web-platform-tests/wpt/pull/43773

Would that allow this feature to be tested more fully?

Best regards,
Philip

On Wed, Jan 31, 2024 at 4:10 PM alice  wrote:

> Contact emails
> al...@igalia.com, meredi...@chromium.org
>
> Explainer
>
> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>
> Specification
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
> https://w3c.github.io/aria/#ARIAMixin
>
> Summary
> This feature allows for ARIA relationship attributes to be reflected in
> IDL as element references rather than DOMStrings.
>
> Note: This intent specifically concerns the ARIA attributes using
> Element Reflection, i.e. the attributes in the ARIAMixin interface with
> a type of Element or FrozenArray. popoverTargetElement, which
> also uses Element Reflection, is already shipping in Blink and WebKit.
>
> Blink component
> Blink>DOM
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/134
>
> TAG review status
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Under consideration
> https://github.com/mozilla/standards-positions/issues/200
> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>
> WebKit: Shipped/Shipping
> (
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> )
> Mentioned in STP release notes:
>
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>
> Web developers: Requested by Web Component authors in particular as a
> means to implement ARIA relationships for elements inside of Shadow DOM.
>
> Activation
> This feature is not completely polyfillable; ID references across shadow
> root boundaries are not possible to implement on top of existing APIs.
>
> WebView application risks
> None
>
> Debuggability
> Developers can use console.log to access the value for IDL attributes
> set via this API, and the Accessibility pane to confirm that the
> attributes are correctly reflected in the accessibility tree.
>
> 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?
> https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
> the reflection part of the API works correctly.
> WPT doesn't yet offer a way to test the relevant accessibility tree
> mappings.
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/981423
>
> Measurement
> Per-attribute UseCounters:
> V8Element_AriaActiveDescendantElement_AttributeGetter
> V8Element_AriaActiveDescendantElement_AttributeSetter
> V8Element_AriaControlsElements_AttributeGetter
> V8Element_AriaControlsElements_AttributeSetter (etc)
>
> V8ElementInternals_AriaActiveDescendantElement_AttributeGetter
> V8ElementInternals_AriaActiveDescendantElement_AttributeSetter
> V8ElementInternals_AriaControlsElements_AttributeGetter
> V8ElementInternals_AriaControlsElements_AttributeSetter (etc)
>
> Estimated milestones
> 123 or 124
>
> Anticipated spec changes
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6244885579431936
>
> Links to previous Intent discussions
> Ready for Trial:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ
>
> --
> 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/865bf3bd2e6a58da9fc3424ed957ceee%40igalia.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/CAARdPYfUO1-g3wYvrvDw9oV9Hf%3DgHP9O%3DdKj5FsVu4OF4K%2BZeQ%40mail.gmail.com.

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

[Thomas Guilbert]

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 fullscreen APIs have been available since Chrome M71.
>>>
>>> Experiment timeline
>>>
>>> TBD, with a proposed 3 months duration
>>>
>>> Blink component
>>>
>>> Blink>Fullscreen
>>> Blink>Media>Video
>>>
>>> TAG review
>>>
>>> None
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Web Compatibility:
>>>
>>> Removing non-standard APIs should overall help web compatibility, and
>>> encourage web authors to use the unprefixed APIs. Some experiences might be
>>> broken by this change, thus justifying this deprecation trial. The API has
>>> been deprecated for a significant amount of time however, and usage has
>>> gone down.
>>>
>>> This would only be an issue for websites that *only* support the
>>> prefixed APIs.
>>>
>>>
>>> Interoperability:
>>>
>>>
>>> All browsers have shipped the new APIs, most of them using an unprefixed
>>> version (Safari on iOS being the only remaining prefixed-only API). See
>>> also
>>> https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility
>>>
>>>
>>> Gecko:
>>>
>>>
>>> WebKit:
>>>
>>> Web developers:
>>>
>>> Other sig

Re: [blink-dev] Intent to Ship: Element Reflection

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:

> Contact emails
> al...@igalia.com, meredi...@chromium.org
>
> Explainer
>
> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>
> Specification
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
> https://w3c.github.io/aria/#ARIAMixin
>
> Summary
> This feature allows for ARIA relationship attributes to be reflected in
> IDL as element references rather than DOMStrings.
>
> Note: This intent specifically concerns the ARIA attributes using
> Element Reflection, i.e. the attributes in the ARIAMixin interface with
> a type of Element or FrozenArray. popoverTargetElement, which
> also uses Element Reflection, is already shipping in Blink and WebKit.
>
> Blink component
> Blink>DOM
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/134
>
> TAG review status
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Under consideration
> https://github.com/mozilla/standards-positions/issues/200
> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>
> WebKit: Shipped/Shipping
> (
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> )
> Mentioned in STP release notes:
>
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>
> Web developers: Requested by Web Component authors in particular as a
> means to implement ARIA relationships for elements inside of Shadow DOM.
>

I wonder if you had any feedback from framework authors that use VDOM. For
context, we were considering using element references for a different
feature, and couldn't overcome the fact that when frameworks change DOM,
sometimes Nodes and Elements are removed or reused for a different purpose
than when initially constructed (ie the element that used to represent the
first item in the list is now used to represent the third item in the list).

I realize that this is asking a question very late in the design process,
but I'm just curious if that's a case that you considered and if so how you
reasoned about it.


> Activation
> This feature is not completely polyfillable; ID references across shadow
> root boundaries are not possible to implement on top of existing APIs.
>
> WebView application risks
> None
>
> Debuggability
> Developers can use console.log to access the value for IDL attributes
> set via this API, and the Accessibility pane to confirm that the
> attributes are correctly reflected in the accessibility tree.
>
> 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?
> https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
> the reflection part of the API works correctly.
> WPT doesn't yet offer a way to test the relevant accessibility tree
> mappings.
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/981423
>
> Measurement
> Per-attribute UseCounters:
> V8Element_AriaActiveDescendantElement_AttributeGetter
> V8Element_AriaActiveDescendantElement_AttributeSetter
> V8Element_AriaControlsElements_AttributeGetter
> V8Element_AriaControlsElements_AttributeSetter (etc)
>
> V8ElementInternals_AriaActiveDescendantElement_AttributeGetter
> V8ElementInternals_AriaActiveDescendantElement_AttributeSetter
> V8ElementInternals_AriaControlsElements_AttributeGetter
> V8ElementInternals_AriaControlsElements_AttributeSetter (etc)
>
> Estimated milestones
> 123 or 124
>
> Anticipated spec changes
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6244885579431936
>
> Links to previous Intent discussions
> Ready for Trial:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ
>
> --
> 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/865bf3bd2e6a58da9fc3424ed957ceee%40igalia.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/CADsXd2N%3DNU1EUUi6jSEwjoH6Vmo9qGOK82bpWMzB%2BniE4tC_3g%40mail.gmail.com.

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

[Mike Taylor]

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 fullscreen APIs have been available since
Chrome M71.


Experiment timeline

TBD, with a proposed 3 months duration


Blink component

Blink>Fullscreen
Blink>Media>Video



TAG review

Re: [blink-dev] Intent to Ship: Element Reflection

[Alice Boxhall]

On Thursday, February 1, 2024 at 4:01:32 AM UTC+11 Philip Jägenstedt wrote:

Hi Alice,

For testing of these in WPT, do you have some details on what's missing? 
It's already possible to get the accessible name and role for an element:
https://web-platform-tests.org/writing-tests/testdriver.html#accessibility


These attributes affect relationships between elements, which project into 
the accessibility tree in various ways. `aria-labelledby` does affect the 
accessible name, so we could write a test for that (which would actually go 
some way to demonstrating that these attributes affect the accessibility 
tree in general), but the remaining attributes affect things like 
accessible description computation (`aria-describedby`), accessibility tree 
structure (`aria-owns`), which element appears to have focus 
(`aria-activedescendant`), or how some assistive technology should provide 
hints to the user (`aria-flowto`, `aria-details`, `aria-owns`, 
`aria-errormessage`).
 

I suspect that won't help, but there's an experimental/tentative API being 
proposed for testdriver.js here:
https://github.com/web-platform-tests/wpt/pull/43773

Would that allow this feature to be tested more fully?


That would allow checking how tree structure is affected, so we could test 
at least one more attribute! I can't tell what other properties will be 
exposed in the tree, so I'm not sure about the rest.
 

Best regards,
Philip

On Wed, Jan 31, 2024 at 4:10 PM alice  wrote:

Contact emails
al...@igalia.com, mere...@chromium.org

Explainer
https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references

Specification
https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
https://w3c.github.io/aria/#ARIAMixin

Summary
This feature allows for ARIA relationship attributes to be reflected in
IDL as element references rather than DOMStrings.

Note: This intent specifically concerns the ARIA attributes using
Element Reflection, i.e. the attributes in the ARIAMixin interface with
a type of Element or FrozenArray. popoverTargetElement, which
also uses Element Reflection, is already shipping in Blink and WebKit.

Blink component
Blink>DOM

TAG review
https://github.com/w3ctag/design-reviews/issues/134

TAG review status
Issues addressed

Risks

Interoperability and Compatibility

Gecko: Under consideration 
https://github.com/mozilla/standards-positions/issues/200
https://bugzilla.mozilla.org/show_bug.cgi?id=1769586

WebKit: Shipped/Shipping
(
https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
)
Mentioned in STP release notes:
https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
Was shipped in Safari 16.4 but wasn't mentioned in release notes there.

Web developers: Requested by Web Component authors in particular as a
means to implement ARIA relationships for elements inside of Shadow DOM.

Activation
This feature is not completely polyfillable; ID references across shadow
root boundaries are not possible to implement on top of existing APIs.

WebView application risks
None

Debuggability
Developers can use console.log to access the value for IDL attributes
set via this API, and the Accessibility pane to confirm that the
attributes are correctly reflected in the accessibility tree.

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?
https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
the reflection part of the API works correctly.
WPT doesn't yet offer a way to test the relevant accessibility tree
mappings.

Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://crbug.com/981423

Measurement
Per-attribute UseCounters: 
V8Element_AriaActiveDescendantElement_AttributeGetter 
V8Element_AriaActiveDescendantElement_AttributeSetter 
V8Element_AriaControlsElements_AttributeGetter 
V8Element_AriaControlsElements_AttributeSetter (etc) 

V8ElementInternals_AriaActiveDescendantElement_AttributeGetter 
V8ElementInternals_AriaActiveDescendantElement_AttributeSetter 
V8ElementInternals_AriaControlsElements_AttributeGetter 
V8ElementInternals_AriaControlsElements_AttributeSetter (etc)

Estimated milestones
123 or 124

Anticipated spec changes
None

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

Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ

-- 
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+...@chromium.org.
To view this discussion on the web visit 

Re: [blink-dev] Intent to Ship: Element Reflection

[Alice Boxhall]

On Thursday, February 1, 2024 at 6:52:13 AM UTC+11 vmp...@google.com wrote:

On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:

Contact emails
al...@igalia.com, mere...@chromium.org

Explainer
https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references

Specification
https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
https://w3c.github.io/aria/#ARIAMixin

Summary
This feature allows for ARIA relationship attributes to be reflected in
IDL as element references rather than DOMStrings.

Note: This intent specifically concerns the ARIA attributes using
Element Reflection, i.e. the attributes in the ARIAMixin interface with
a type of Element or FrozenArray. popoverTargetElement, which
also uses Element Reflection, is already shipping in Blink and WebKit.

Blink component
Blink>DOM

TAG review
https://github.com/w3ctag/design-reviews/issues/134

TAG review status
Issues addressed

Risks

Interoperability and Compatibility

Gecko: Under consideration 
https://github.com/mozilla/standards-positions/issues/200
https://bugzilla.mozilla.org/show_bug.cgi?id=1769586

WebKit: Shipped/Shipping
(
https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
)
Mentioned in STP release notes:
https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
Was shipped in Safari 16.4 but wasn't mentioned in release notes there.

Web developers: Requested by Web Component authors in particular as a
means to implement ARIA relationships for elements inside of Shadow DOM.


I wonder if you had any feedback from framework authors that use VDOM. For 
context, we were considering using element references for a different 
feature, and couldn't overcome the fact that when frameworks change DOM, 
sometimes Nodes and Elements are removed or reused for a different purpose 
than when initially constructed (ie the element that used to represent the 
first item in the list is now used to represent the third item in the list).

I realize that this is asking a question very late in the design process, 
but I'm just curious if that's a case that you considered and if so how you 
reasoned about it.


To be honest, no, we didn't take VDOM into account. 

I'd be curious to hear what specific cases you were running into difficulty 
with, but it does seem like these paradigms are fundamentally at odds with 
one another - if elements are unpredictably destroyed and recreated, then 
it seems like using the string ID-based version is going to be a better 
fit. This API is, at least, designed to work with using the 
`setAttribute()` version, in that setting the content attribute will cause 
any value set via the IDL attribute to be discarded (and vice-versa).

(VDOM has always made me anxious for similar reasons - if elements are 
unpredictably moved or destroyed, what happens if an assistive technology 
was visiting those nodes in the accessibility tree when that happens? But I 
have essentially no experience actually using it, so presumably that can be 
managed in practice.)


Activation
This feature is not completely polyfillable; ID references across shadow
root boundaries are not possible to implement on top of existing APIs.

WebView application risks
None

Debuggability
Developers can use console.log to access the value for IDL attributes
set via this API, and the Accessibility pane to confirm that the
attributes are correctly reflected in the accessibility tree.

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?
https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
the reflection part of the API works correctly.
WPT doesn't yet offer a way to test the relevant accessibility tree
mappings.

Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://crbug.com/981423

Measurement
Per-attribute UseCounters: 
V8Element_AriaActiveDescendantElement_AttributeGetter 
V8Element_AriaActiveDescendantElement_AttributeSetter 
V8Element_AriaControlsElements_AttributeGetter 
V8Element_AriaControlsElements_AttributeSetter (etc) 

V8ElementInternals_AriaActiveDescendantElement_AttributeGetter 
V8ElementInternals_AriaActiveDescendantElement_AttributeSetter 
V8ElementInternals_AriaControlsElements_AttributeGetter 
V8ElementInternals_AriaControlsElements_AttributeSetter (etc)

Estimated milestones
123 or 124

Anticipated spec changes
None

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

Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ

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

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

['Thomas Guilbert' via blink-dev]

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 fullscreen APIs have been available since Chrome M71.

 Experiment timeline

 TBD, with a proposed 3 months duration

 Blink component

 Blink>Fullscreen
 Blink>Media>Video

 TAG review

 None

 TAG review status

 Not applicable

 Risks
 Interoperability and Compatibility

 Web Compatibility:

 Removing non-standard APIs should overall help web compatibility, and
 encourage web authors to use the unprefixed APIs. Some experi

Re: [blink-dev] Intent to Ship: Element Reflection

[Elsa Vega-Martinez]

Hello Alice,

I have no clue what you are talking about. This is all  technology and I
have no clue of what it is, ma’am, so if you can explain this in plain
English, I would appreciate it.

Just for your information someone is emailing all of you and it is not me.
Our you a Technology company are you guys hackers or are you guys helpers
because I am absolutely actually I’m scared to see all this technology
talk. Are you people tracking me I see there’s a thread and a lot of other
things but I do not understand it. I’m sorry, but I do need an explanation
because I am going to be turning in my phone to the police department
because I am being stuck and I don’t know if it’s you people or somebody
else so please if you can be kind and call me, I would appreciate it.

Thank you,
Elsa




On Wed, Jan 31, 2024 at 3:14 PM Alice Boxhall  wrote:

>
>
> On Thursday, February 1, 2024 at 6:52:13 AM UTC+11 vmp...@google.com
> wrote:
>
> On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:
>
> Contact emails
> al...@igalia.com, mere...@chromium.org
>
> Explainer
>
> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>
> Specification
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
> https://w3c.github.io/aria/#ARIAMixin
>
> Summary
> This feature allows for ARIA relationship attributes to be reflected in
> IDL as element references rather than DOMStrings.
>
> Note: This intent specifically concerns the ARIA attributes using
> Element Reflection, i.e. the attributes in the ARIAMixin interface with
> a type of Element or FrozenArray. popoverTargetElement, which
> also uses Element Reflection, is already shipping in Blink and WebKit.
>
> Blink component
> Blink>DOM
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/134
>
> TAG review status
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Under consideration
> https://github.com/mozilla/standards-positions/issues/200
> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>
> WebKit: Shipped/Shipping
> (
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> )
> Mentioned in STP release notes:
>
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>
> Web developers: Requested by Web Component authors in particular as a
> means to implement ARIA relationships for elements inside of Shadow DOM.
>
>
> I wonder if you had any feedback from framework authors that use VDOM. For
> context, we were considering using element references for a different
> feature, and couldn't overcome the fact that when frameworks change DOM,
> sometimes Nodes and Elements are removed or reused for a different purpose
> than when initially constructed (ie the element that used to represent the
> first item in the list is now used to represent the third item in the list).
>
> I realize that this is asking a question very late in the design process,
> but I'm just curious if that's a case that you considered and if so how you
> reasoned about it.
>
>
> To be honest, no, we didn't take VDOM into account.
>
> I'd be curious to hear what specific cases you were running into
> difficulty with, but it does seem like these paradigms are fundamentally at
> odds with one another - if elements are unpredictably destroyed and
> recreated, then it seems like using the string ID-based version is going to
> be a better fit. This API is, at least, designed to work with using the
> `setAttribute()` version, in that setting the content attribute will cause
> any value set via the IDL attribute to be discarded (and vice-versa).
>
> (VDOM has always made me anxious for similar reasons - if elements are
> unpredictably moved or destroyed, what happens if an assistive technology
> was visiting those nodes in the accessibility tree when that happens? But I
> have essentially no experience actually using it, so presumably that can be
> managed in practice.)
>
>
> Activation
> This feature is not completely polyfillable; ID references across shadow
> root boundaries are not possible to implement on top of existing APIs.
>
> WebView application risks
> None
>
> Debuggability
> Developers can use console.log to access the value for IDL attributes
> set via this API, and the Accessibility pane to confirm that the
> attributes are correctly reflected in the accessibility tree.
>
> 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?
> https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
> the reflection part of the API works correctly.
> WPT doesn't yet offer a way to test the relevant accessibility tree
> mappings.
>
> Flag name on chrome://flags
> N

Re: [blink-dev] Intent to Ship: Element Reflection

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 6:14 PM Alice Boxhall  wrote:

>
>
> On Thursday, February 1, 2024 at 6:52:13 AM UTC+11 vmp...@google.com
> wrote:
>
> On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:
>
> Contact emails
> al...@igalia.com, mere...@chromium.org
>
> Explainer
>
> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>
> Specification
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
> https://w3c.github.io/aria/#ARIAMixin
>
> Summary
> This feature allows for ARIA relationship attributes to be reflected in
> IDL as element references rather than DOMStrings.
>
> Note: This intent specifically concerns the ARIA attributes using
> Element Reflection, i.e. the attributes in the ARIAMixin interface with
> a type of Element or FrozenArray. popoverTargetElement, which
> also uses Element Reflection, is already shipping in Blink and WebKit.
>
> Blink component
> Blink>DOM
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/134
>
> TAG review status
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Under consideration
> https://github.com/mozilla/standards-positions/issues/200
> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>
> WebKit: Shipped/Shipping
> (
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> )
> Mentioned in STP release notes:
>
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>
> Web developers: Requested by Web Component authors in particular as a
> means to implement ARIA relationships for elements inside of Shadow DOM.
>
>
> I wonder if you had any feedback from framework authors that use VDOM. For
> context, we were considering using element references for a different
> feature, and couldn't overcome the fact that when frameworks change DOM,
> sometimes Nodes and Elements are removed or reused for a different purpose
> than when initially constructed (ie the element that used to represent the
> first item in the list is now used to represent the third item in the list).
>
> I realize that this is asking a question very late in the design process,
> but I'm just curious if that's a case that you considered and if so how you
> reasoned about it.
>
>
> To be honest, no, we didn't take VDOM into account.
>
> I'd be curious to hear what specific cases you were running into
> difficulty with, but it does seem like these paradigms are fundamentally at
> odds with one another - if elements are unpredictably destroyed and
> recreated, then it seems like using the string ID-based version is going to
> be a better fit. This API is, at least, designed to work with using the
> `setAttribute()` version, in that setting the content attribute will cause
> any value set via the IDL attribute to be discarded (and vice-versa).
>

The main use case for us was just matching elements automatically across
DOM mutations with a caveat that we were using CSS, not attributes. We
couldn't really get a sense of how stable our proposals were because of the
VDOM type of reordering. It might be worthwhile for us to revisit that
plan. I agree with you that I think your case is a lot better, since it
affects attributes being set, instead of being some ephemeral state that
the browser keeps track of.


>
> (VDOM has always made me anxious for similar reasons - if elements are
> unpredictably moved or destroyed, what happens if an assistive technology
> was visiting those nodes in the accessibility tree when that happens? But I
> have essentially no experience actually using it, so presumably that can be
> managed in practice.)
>

I also agree with this sentiment. It seems like we want to rely on the
persistence of elements and their identity, but at the same time there are
a lot of optimized frameworks that are fast because they don't.




>
>
> Activation
> This feature is not completely polyfillable; ID references across shadow
> root boundaries are not possible to implement on top of existing APIs.
>
> WebView application risks
> None
>
> Debuggability
> Developers can use console.log to access the value for IDL attributes
> set via this API, and the Accessibility pane to confirm that the
> attributes are correctly reflected in the accessibility tree.
>
> 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?
> https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
> the reflection part of the API works correctly.
> WPT doesn't yet offer a way to test the relevant accessibility tree
> mappings.
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>

Re: [blink-dev] Intent to Ship: Element Reflection

[Elsa Vega-Martinez]

Look I don’t know what you guys are talking about. This is gonna be the
last time I’m asking you give me a call right now or I am delivering this
to the police department. I’m not playing around anymore I do not know who
you people are. I don’t know if you guys are tracking something selling
something delivering something you don’t even know who I am ANNA and I
somebody is sending you these messages and it’s not me and I’m giving you
my phone number area code 559-871-6945.

On Wed, Jan 31, 2024 at 4:16 PM 'Vladimir Levin' via blink-dev <
blink-dev@chromium.org> wrote:

>
>
> On Wed, Jan 31, 2024 at 6:14 PM Alice Boxhall  wrote:
>
>>
>>
>> On Thursday, February 1, 2024 at 6:52:13 AM UTC+11 vmp...@google.com
>> wrote:
>>
>> On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:
>>
>> Contact emails
>> al...@igalia.com, mere...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>>
>> Specification
>>
>> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
>> https://w3c.github.io/aria/#ARIAMixin
>>
>> Summary
>> This feature allows for ARIA relationship attributes to be reflected in
>> IDL as element references rather than DOMStrings.
>>
>> Note: This intent specifically concerns the ARIA attributes using
>> Element Reflection, i.e. the attributes in the ARIAMixin interface with
>> a type of Element or FrozenArray. popoverTargetElement, which
>> also uses Element Reflection, is already shipping in Blink and WebKit.
>>
>> Blink component
>> Blink>DOM
>>
>> TAG review
>> https://github.com/w3ctag/design-reviews/issues/134
>>
>> TAG review status
>> Issues addressed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Under consideration
>> https://github.com/mozilla/standards-positions/issues/200
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>>
>> WebKit: Shipped/Shipping
>> (
>> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
>> )
>> Mentioned in STP release notes:
>>
>> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
>> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>>
>> Web developers: Requested by Web Component authors in particular as a
>> means to implement ARIA relationships for elements inside of Shadow DOM.
>>
>>
>> I wonder if you had any feedback from framework authors that use VDOM.
>> For context, we were considering using element references for a different
>> feature, and couldn't overcome the fact that when frameworks change DOM,
>> sometimes Nodes and Elements are removed or reused for a different purpose
>> than when initially constructed (ie the element that used to represent the
>> first item in the list is now used to represent the third item in the list).
>>
>> I realize that this is asking a question very late in the design process,
>> but I'm just curious if that's a case that you considered and if so how you
>> reasoned about it.
>>
>>
>> To be honest, no, we didn't take VDOM into account.
>>
>> I'd be curious to hear what specific cases you were running into
>> difficulty with, but it does seem like these paradigms are fundamentally at
>> odds with one another - if elements are unpredictably destroyed and
>> recreated, then it seems like using the string ID-based version is going to
>> be a better fit. This API is, at least, designed to work with using the
>> `setAttribute()` version, in that setting the content attribute will cause
>> any value set via the IDL attribute to be discarded (and vice-versa).
>>
>
> The main use case for us was just matching elements automatically across
> DOM mutations with a caveat that we were using CSS, not attributes. We
> couldn't really get a sense of how stable our proposals were because of the
> VDOM type of reordering. It might be worthwhile for us to revisit that
> plan. I agree with you that I think your case is a lot better, since it
> affects attributes being set, instead of being some ephemeral state that
> the browser keeps track of.
>
>
>>
>> (VDOM has always made me anxious for similar reasons - if elements are
>> unpredictably moved or destroyed, what happens if an assistive technology
>> was visiting those nodes in the accessibility tree when that happens? But I
>> have essentially no experience actually using it, so presumably that can be
>> managed in practice.)
>>
>
> I also agree with this sentiment. It seems like we want to rely on the
> persistence of elements and their identity, but at the same time there are
> a lot of optimized frameworks that are fast because they don't.
>
>
>
>
>>
>>
>> Activation
>> This feature is not completely polyfillable; ID references across shadow
>> root boundaries are not possible to implement on top of existing APIs.
>>
>> WebView application risks
>> None
>>
>> Debuggability
>> Developers can use console.log t

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

[David Dabbs]

Thank you for the reminder Joe.
My digest message does not include a full e-mail address:

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

Can you kindly please supply this so I can post a question?

Thanks,
dd

On Tuesday, January 30, 2024 at 3:27:59 PM UTC-6 jcgre...@google.com wrote:

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 secu...@chromium.org 
   - 
   
   P0 General bugs: email file...@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-trac...@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/29208990-3cb4-4fb7-91a7-09ad60d397dan%40chromium.org.

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

[Mason Freed]

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.


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

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

[Dave Tapuska]

It's issue-tracker-support at chromium.org

On Wed, Jan 31, 2024, 8:31 PM David Dabbs  wrote:

> Thank you for the reminder Joe.
> My digest message does not include a full e-mail address:
>
>You can reach out at any time to issue-trac...@chromium.org
>  with questions or concerns.
>
> Can you kindly please supply this so I can post a question?
>
> Thanks,
> dd
>
> On Tuesday, January 30, 2024 at 3:27:59 PM UTC-6 jcgre...@google.com
> wrote:
>
> 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 secu...@chromium.org
>-
>
>P0 General bugs: email file...@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-trac...@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/29208990-3cb4-4fb7-91a7-09ad60d397dan%40chromium.org
> 
> .
>

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

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

['Joe Gregorio' via blink-dev]

Hi all,

As we shared yesterday, 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.

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:


https://developers.google.com/issue-tracker/references/chromium-migration-announce


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/CAA6qSUBObT0UqEVWR0qfpkvLwyD_de6Z6-z%3DtPPb_0oYTxH4Nw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Element Reflection

[Domenic Denicola]

Very exciting to see this!

On Thu, Feb 1, 2024 at 12:10 AM alice  wrote:

> Contact emails
> al...@igalia.com, meredi...@chromium.org
>
> Explainer
>
> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>
> Specification
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
> https://w3c.github.io/aria/#ARIAMixin


These specs are incompatible with each other, because
https://github.com/w3c/aria/pull/1876 has not yet been merged. Do you think
it'll be possible to get that merged soon?


>
>
> Summary
> This feature allows for ARIA relationship attributes to be reflected in
> IDL as element references rather than DOMStrings.
>
> Note: This intent specifically concerns the ARIA attributes using
> Element Reflection, i.e. the attributes in the ARIAMixin interface with
> a type of Element or FrozenArray. popoverTargetElement, which
> also uses Element Reflection, is already shipping in Blink and WebKit.
>

Can you confirm whether the scope of this intent is element reflection
only? Or does it include ElementInternals support as well?

(Coincidentally, I saw you filed this bug
 which seems
to state that the ElementInternals support is currently not working.)


>
> Blink component
> Blink>DOM
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/134
>
> TAG review status
> Issues addressed
>

This tag review seems to be for AOM in general, as of its 2018 shape. I'm
not sure there's been a lot of discussion as to where it ended up, with
element reflection. Do you know of any TAG review or comments on the latest
API?

However, I think this qualifies for an exception
,
under "already specified and accepted by the relevant standardization
body", and "has already shipped in at least one other browser"


>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Under consideration
> https://github.com/mozilla/standards-positions/issues/200
> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>
> WebKit: Shipped/Shipping
> (
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> )
> Mentioned in STP release notes:
>
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>
> Web developers: Requested by Web Component authors in particular as a
> means to implement ARIA relationships for elements inside of Shadow DOM.
>
> Activation
> This feature is not completely polyfillable; ID references across shadow
> root boundaries are not possible to implement on top of existing APIs.
>
> WebView application risks
> None
>
> Debuggability
> Developers can use console.log to access the value for IDL attributes
> set via this API, and the Accessibility pane to confirm that the
> attributes are correctly reflected in the accessibility tree.
>
> 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?
> https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
> the reflection part of the API works correctly.
> WPT doesn't yet offer a way to test the relevant accessibility tree
> mappings.
>

>From what I understand, WPT allows some testing of accessibility tree
mappings these days, via WebDriver hooks. For example:

   - These tests appear to test the computed role
   
   - These tests appear to test the computed accessible name
   

IIUC, the above test shows that content attributes (like ) are reflected correctly in the accessibility tree. Would it
be possible to add similar tests for the corresponding JavaScript code?
Maybe that's not possible for most of the complex element relationships
that this I2S is about, but I think you should be able to use element
reflection to influence accessible name computation, at least? I don't
think they need to be exhaustive, but just some tests to catch issues like the
above-mentioned bug
.


> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>

I believe the recent guidance is that all new features should be guarded by
a base::Feature flag, which then generates a Finch feature automatically.


>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/981423
>
> Measurement
> Per-attribute UseCounters:
> V8Element_AriaActiveDescendantElement_AttributeGetter
> V8Element_AriaActiveDescendantElement_AttributeSetter
> V8Element_AriaControlsElements_AttributeGetter