date:20230712

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

2023-07-12 Thread Domenic Denicola

Also, checking the tests, it seems like the currently-implemented reasons
don't match the spec. E.g. this test

requires
the reason to be "WebSocket", but the specification says "websocket"
(lowercase). I couldn't find tests for the other three reasons...

On Thu, Jul 13, 2023 at 12:04 PM Domenic Denicola 
wrote:

> I have some questions about how well the implementation here matches up
> with the spec.
>
> First, there doesn't appear to be any NotRestoredReasons interface defined
> in Chromium? The relevant attribute on PerformanceNavigationTiming
> returns object?
> .
> That seems like a problematic mismatch...
>
> Second, I can't find exactly where the list of script-exposed not restored
> reasons are. But, I'll note that Chromium seems to have ~50 such reasons
> ,
> whereas you've only specified 4 (fetch, navigation-failure, parser-aborted,
> websocket). Can you confirm that you're only shipping the specified four?
>
> Thanks!
>
> On Thu, Jul 13, 2023 at 12:11 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> yu...@google.com, yu...@chromium.org, fer...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
>>>
>>> Specification
>>>
>>> https://github.com/whatwg/html/pull/9360
>>>
>>> Design docs
>>>
>>>
>>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
>>>
>>> Summary
>>>
>>> NotRestoredReason API will report the list of reasons why a page is not
>>> served from BFcache in a frame tree structure, via
>>> PerformanceNavigationTiming API.
>>>
>>>
>>> Blink component
>>>
>>> UI>Browser>Navigation>BFCache
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/739
>>>
>>> TAG review status
>>>
>>> Issues addressed
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: Defer (https://github.com/mozilla/standards-positions/issues/766)
>>> Once issues (standardized reasons & unsalvageable documents), they would
>>> switch to positive.
>>>
>>
>> It seems like the "standardized reasons" part is addressed in your PR. Is
>> the same true for the second point?
>>
>>
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/154)
>>>
>>> Web developers: Positive (
>>> https://github.com/w3c/navigation-timing/issues/171#issuecomment-1062672989
>>> )
>>>
>>> Other signals: Positive from Origin Trial users:
>>>
>>> How likely are you to keep using this feature?
>>>
>>> 92% answered likely, 8% (1 vote) is unsure
>>>
>>> Security
>>>
>>> We do not report detailed information about cross-origin iframes. See 
>>> Security
>>> and Privacy section
>>> 
>>> in the explainer.
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> No.
>>>
>>>
>>> Debuggability
>>>
>>> In DevTools console, try:
>>>
>>> performance.getEntriesByType('navigation')[0].notRestoredReasons;
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes.
>>>
>>> NotRestoredReasons API is available on all platforms including WebView,
>>> but back/forward cache is not enabled on WebView. So on WebView,
>>> NotRestoredReasons API should always say that the page is blocked from
>>> being restored from bfcache with the reason being something like “not
>>> supported”.
>>>
>>> (Currently it reports null due to a bug
>>> )
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes.
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/
>>>
>>> DevTrial instructions
>>>
>>>
>>> https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/HowToTest.md
>>>
>>> Flag nameblink RunTimeEnabledFeature:
>>> BackForwardCacheSendNotRe

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

2023-07-12 Thread Domenic Denicola

I have some questions about how well the implementation here matches up
with the spec.

First, there doesn't appear to be any NotRestoredReasons interface defined
in Chromium? The relevant attribute on PerformanceNavigationTiming returns
object?
.
That seems like a problematic mismatch...

Second, I can't find exactly where the list of script-exposed not restored
reasons are. But, I'll note that Chromium seems to have ~50 such reasons
,
whereas you've only specified 4 (fetch, navigation-failure, parser-aborted,
websocket). Can you confirm that you're only shipping the specified four?

Thanks!

On Thu, Jul 13, 2023 at 12:11 AM Yoav Weiss  wrote:

>
>
> On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> yu...@google.com, yu...@chromium.org, fer...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
>>
>> Specification
>>
>> https://github.com/whatwg/html/pull/9360
>>
>> Design docs
>>
>>
>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
>>
>> Summary
>>
>> NotRestoredReason API will report the list of reasons why a page is not
>> served from BFcache in a frame tree structure, via
>> PerformanceNavigationTiming API.
>>
>>
>> Blink component
>>
>> UI>Browser>Navigation>BFCache
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/739
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Defer (https://github.com/mozilla/standards-positions/issues/766)
>> Once issues (standardized reasons & unsalvageable documents), they would
>> switch to positive.
>>
>
> It seems like the "standardized reasons" part is addressed in your PR. Is
> the same true for the second point?
>
>
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/154)
>>
>> Web developers: Positive (
>> https://github.com/w3c/navigation-timing/issues/171#issuecomment-1062672989
>> )
>>
>> Other signals: Positive from Origin Trial users:
>>
>> How likely are you to keep using this feature?
>>
>> 92% answered likely, 8% (1 vote) is unsure
>>
>> Security
>>
>> We do not report detailed information about cross-origin iframes. See 
>> Security
>> and Privacy section
>> 
>> in the explainer.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No.
>>
>>
>> Debuggability
>>
>> In DevTools console, try:
>>
>> performance.getEntriesByType('navigation')[0].notRestoredReasons;
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes.
>>
>> NotRestoredReasons API is available on all platforms including WebView,
>> but back/forward cache is not enabled on WebView. So on WebView,
>> NotRestoredReasons API should always say that the page is blocked from
>> being restored from bfcache with the reason being something like “not
>> supported”.
>>
>> (Currently it reports null due to a bug
>> )
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes.
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/
>>
>> DevTrial instructions
>>
>>
>> https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/HowToTest.md
>>
>> Flag nameblink RunTimeEnabledFeature:
>> BackForwardCacheSendNotRestoredReasons
>> 
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1326344
>>
>> Launch bug
>>
>> https://launch.corp.google.com/launch/4200848
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 116
>>
>> OriginTrial desktop last
>>
>> 114
>>
>> OriginTrial desktop first
>>
>> 109
>>
>> DevTrial on desktop
>>
>> 108
>>
>> Shipping on Android
>>
>> 116
>>
>> OriginTrial Android last
>>
>> 114
>>
>> OriginTrial

Re: [blink-dev] Re: Intent to Deprecate and Remove Web SQL

2023-07-12 Thread Ayu Ishii

WebSQL Deprecation Trial registration is now available 
at https://developer.chrome.com/origintrials/#/view_trial/494270059103911937

On Friday, June 30, 2023 at 6:48:09 AM UTC-7 tste...@google.com wrote:

> Timeline updated in developer-facing comms: 
> https://github.com/GoogleChrome/developer.chrome.com/pull/6725. 
>
> On Mon, Jun 26, 2023 at 10:57 PM Ayu Ishii  wrote:
>
>> Hi blink owners,
>>
>> With request from partners, we are planning to update the timeline to 
>> enable deprecation trial from M117 (previously M118) to provide a larger 
>> window to integrate with the trial before full removal in M119.
>> The rest of the timeline will stay the same.
>>
>> NEW - Target timeline:
>>
>> M101 - 123 - Enterprise Policy 
>> 
>>
>> M115 - Add deprecation message
>>
>> M117-123  - Deprecation trial
>>
>> M119 - Ship removal OLD - Target timeline: 
>>
>> M101 - 123 - Enterprise Policy 
>> 
>>
>> M115 - Add deprecation message
>>
>> M118-123  - Deprecation trial
>>
>> M119 - Ship removal
>>
>> Thanks, Ayu
>>
>> On Tuesday, May 16, 2023 at 1:36:24 AM UTC-7 tste...@google.com wrote:
>>
>>> On Tue, May 16, 2023 at 10:29 AM Asier Lostalé <
>>> asier.lost...@openbravo.com> wrote:
>>>
 Hi Thomas,

 Thanks for your reply.

 If possible, I'd like to clarify a couple of topics:

 - I see there is already an "Allows access to WebSQL APIs" flag that 
 can be used to force access to WebSQL. For how long is this flag planned 
 to 
 be kept? Will it be available from M119 to M123? What about after M123?

>>>
>>> Since the code is going to be removed, the flag will be removed as a 
>>> consequence as well. Given the current timeline 
>>> , 
>>> I 
>>> would *not* count for the code to exist after 123. 
>>>  
>>>
 - As a site owner, how can I take part of the deprecation trial?

>>>
>>> Please see this article on origin trials 
>>> .
>>>  
>>> A deprecation trial works just the other way round: rather than granting 
>>> your site early access to a future feature, it grants you late access to a 
>>> past feature.
>>>
>>> Cheers,
>>> Tom
>>>
>>
>
> -- 
> Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com
> , https://twitter.com/tomayac)
>
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
> Geschäftsführer: Paul Manicle, Liana Sebastian
> Registergericht und -nummer: Hamburg, HRB 86891
>
> - BEGIN PGP SIGNATURE -
> Version: GnuPG v2.3.4 (GNU/Linux)
>
>
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
> hTtPs://xKcd.cOm/1181/
> - END PGP SIGNATURE -
>

-- 
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/da9c64db-ac8e-4507-9b10-8089c2e698fbn%40chromium.org.

Re: [blink-dev] Intent to Prototype: Insert CJK Inter-script Spacing: the CSS `text-autospace` property

2023-07-12 Thread Koji Ishii

Thank you for the feedback.

For Canadian French, there is an open issue at csswg#8657
, great if you can add
there..

On Thu, Jul 13, 2023 at 4:25 AM PhistucK  wrote:

> Hopefully French is fr-FR, because fr-CA (Canadian French) has much fewer
> cases of adding a space character before punctuation...
>
> ☆*PhistucK*
>
>
> On Wed, Jul 12, 2023 at 8:00 PM Koji Ishii  wrote:
>
>> Contact emailsko...@chromium.org, lin...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-text-4/#text-autospace-property
>>
>> Design docs
>>
>> https://docs.google.com/document/d/10G1uasooKpKjNeyr1wtLV85wFMlc_TK4-vb9LG_3Fzw/edit#bookmark=id.t5tzxbvnz8gg
>>
>> Summary
>>
>> Inserts small spacings to match the established typographic rules
>> automatically. The spec currently defines one rule for Han ideographic
>> characters and one for French. The initial implementation focuses on the
>> Han ideographic characters rule. Text written in Han ideographic writing
>> systems often mixes multiple scripts, usually the Han ideographic script, a
>> Latin script, and Arabic digits. Small spacings when switching from and to
>> non-Han ideographic scripts often help readability. This property lets
>> browsers insert such spacings automatically. This property has several
>> values, including values for other writing systems. The initial
>> implementation will choose a subset of the defined values, but which subset
>> is TBD.
>>
>>
>> Blink componentBlink>Layout>Inline
>> 
>>
>> Motivation
>>
>> None
>>
>>
>> Initial public proposalNone
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: Positive (
>> https://github.com/w3c/csswg-drafts/issues/4246#issuecomment-1397831533)
>>
>> *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?
>>
>>
>>
>> Debuggability
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No. We plan to add tests.
>>
>> Flag name on chrome://flags
>>
>> Finch feature name
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463890
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5202578236768256
>>
>> Links to previous Intent discussions
>>
>> 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_1dLULX9bM8FqXiTRg47GmvC5-cQTZ_s6yvB7OMuQe8ZAxg%40mail.gmail.com
>> 
>> .
>>
>

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

Re: [blink-dev] Intent to Prototype: Insert CJK Inter-script Spacing: the CSS `text-autospace` property

2023-07-12 Thread PhistucK

Hopefully French is fr-FR, because fr-CA (Canadian French) has much fewer
cases of adding a space character before punctuation...

☆*PhistucK*


On Wed, Jul 12, 2023 at 8:00 PM Koji Ishii  wrote:

> Contact emailsko...@chromium.org, lin...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-text-4/#text-autospace-property
>
> Design docs
>
> https://docs.google.com/document/d/10G1uasooKpKjNeyr1wtLV85wFMlc_TK4-vb9LG_3Fzw/edit#bookmark=id.t5tzxbvnz8gg
>
> Summary
>
> Inserts small spacings to match the established typographic rules
> automatically. The spec currently defines one rule for Han ideographic
> characters and one for French. The initial implementation focuses on the
> Han ideographic characters rule. Text written in Han ideographic writing
> systems often mixes multiple scripts, usually the Han ideographic script, a
> Latin script, and Arabic digits. Small spacings when switching from and to
> non-Han ideographic scripts often help readability. This property lets
> browsers insert such spacings automatically. This property has several
> values, including values for other writing systems. The initial
> implementation will choose a subset of the defined values, but which subset
> is TBD.
>
>
> Blink componentBlink>Layout>Inline
> 
>
> Motivation
>
> None
>
>
> Initial public proposalNone
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
>
> *WebKit*: Positive (
> https://github.com/w3c/csswg-drafts/issues/4246#issuecomment-1397831533)
>
> *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?
>
>
>
> Debuggability
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No. We plan to add tests.
>
> Flag name on chrome://flags
>
> Finch feature name
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463890
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5202578236768256
>
> Links to previous Intent discussions
>
> 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_1dLULX9bM8FqXiTRg47GmvC5-cQTZ_s6yvB7OMuQe8ZAxg%40mail.gmail.com
> 
> .
>

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

[blink-dev] Intent to Prototype: Insert CJK Inter-script Spacing: the CSS `text-autospace` property

2023-07-12 Thread Koji Ishii

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

ExplainerNone

Specificationhttps://drafts.csswg.org/css-text-4/#text-autospace-property

Design docs
https://docs.google.com/document/d/10G1uasooKpKjNeyr1wtLV85wFMlc_TK4-vb9LG_3Fzw/edit#bookmark=id.t5tzxbvnz8gg

Summary

Inserts small spacings to match the established typographic rules
automatically. The spec currently defines one rule for Han ideographic
characters and one for French. The initial implementation focuses on the
Han ideographic characters rule. Text written in Han ideographic writing
systems often mixes multiple scripts, usually the Han ideographic script, a
Latin script, and Arabic digits. Small spacings when switching from and to
non-Han ideographic scripts often help readability. This property lets
browsers insert such spacings automatically. This property has several
values, including values for other writing systems. The initial
implementation will choose a subset of the defined values, but which subset
is TBD.

Blink componentBlink>Layout>Inline

Motivation

None

Initial public proposalNone

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Gecko*: No signal

*WebKit*: Positive (
https://github.com/w3c/csswg-drafts/issues/4246#issuecomment-1397831533)

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

Debuggability

Is this feature fully tested by web-platform-tests

?No. We plan to add tests.

Flag name on chrome://flags

Finch feature name

Non-finch justificationNone

Requires code in //chrome?False

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

Estimated milestones

No milestones specified

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

Links to previous Intent discussions

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_1dLULX9bM8FqXiTRg47GmvC5-cQTZ_s6yvB7OMuQe8ZAxg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Daniel Bratell


LGTM3

/Daniel

On 2023-07-12 17:26, Yoav Weiss wrote:

LGTM2

On Wed, Jul 12, 2023 at 5:21 PM Mike Taylor  
wrote:


LGTM1 - seems like an obvious interop win.

On 7/12/23 4:31 AM, Frédéric Wang wrote:



Hello,

This is actually an intent to ship (sorry for sending email with
the wrong title).

To summarize a bit conversations, columnspan/rowspan was
something that was requested by web developers and is used in
existing documents. We cannot just say "use CSS instead" as they
are no equivalent properties.

Initially, we wanted to have this in the initial MathML
implementation but things were postponed because we needed to
decide between "make things more compatible with HTML" (i.e.
colspan/rowspan names) or "make things backward compatible with
MathML3" (i.e. columnspan/rowspan names). Given the latter is
already implemented by Firefox/WebKit and used in existing
documents and tools we decided to go with the latter (Mozilla
also positioned negatively about changing the name).



-



Contact emails

fw...@chromium.org


Explainer

None


Specification

https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd


Summary

Implement attributes to specify the number of columns and rows
that a MathML table cell is to span. This is similar to HTML
colspan/rowspan attributes and does not have equivalent CSS
properties.



Blink component

Blink>MathML





TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: Shipped/Shipping

(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)
Mozilla positioned negatively about renaming
https://github.com/mozilla/standards-positions/issues/74

(Note: this should be
https://github.com/mozilla/standards-positions/issues/743)



/WebKit/: Shipped/Shipping

(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)


/Web developers/: Positive

/Other signals/:


WebView application risks

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



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes
Tests are added in
https://chromium-review.googlesource.com/c/chromium/src/+/4061476
However, advanced parsing such as checking the max limits 1000
and 65534 defined in HTML is a bit tedious as MathML does not
have an IDL for tables yet (
https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093


) so for now they are written as internal tests.


Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes

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



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157467960377344


Links to previous Intent discussions

Intent to Experiment:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com



This intent message was generated by Chrome Platform Status
.


-- 
Frédéric Wang
-- 
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/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%40igalia.com

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Yoav Weiss

LGTM2

On Wed, Jul 12, 2023 at 5:21 PM Mike Taylor  wrote:

> LGTM1 - seems like an obvious interop win.
>
> On 7/12/23 4:31 AM, Frédéric Wang wrote:
>
> Hello,
>
> This is actually an intent to ship (sorry for sending email with the wrong
> title).
>
> To summarize a bit conversations, columnspan/rowspan was something that
> was requested by web developers and is used in existing documents. We
> cannot just say "use CSS instead" as they are no equivalent properties.
>
> Initially, we wanted to have this in the initial MathML implementation but
> things were postponed because we needed to decide between "make things more
> compatible with HTML" (i.e. colspan/rowspan names) or "make things backward
> compatible with MathML3" (i.e. columnspan/rowspan names). Given the latter
> is already implemented by Firefox/WebKit and used in existing documents and
> tools we decided to go with the latter (Mozilla also positioned negatively
> about changing the name).
>
>
> -
>
> Contact emails fw...@chromium.org
>
> Explainer None
>
> Specification
> https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd
>
> Summary
>
> Implement attributes to specify the number of columns and rows that a
> MathML table cell is to span. This is similar to HTML colspan/rowspan
> attributes and does not have equivalent CSS properties.
>
>
> Blink component Blink>MathML
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> *Gecko*: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)
> Mozilla positioned negatively about renaming
> https://github.com/mozilla/standards-positions/issues/74
>
> (Note: this should be
> https://github.com/mozilla/standards-positions/issues/743)
>
>
>
> *WebKit*: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)
>
>
> *Web developers*: Positive
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
> Debuggability
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
> Tests are added in
> https://chromium-review.googlesource.com/c/chromium/src/+/4061476
> However, advanced parsing such as checking the max limits 1000 and 65534
> defined in HTML is a bit tedious as MathML does not have an IDL for tables
> yet (
> https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093
> 
>  )
> so for now they are written as internal tests. Flag name on chrome://flags
>
> Finch feature name
>
> Non-finch justification None
>
> Requires code in //chrome? False
>
> Estimated milestones
> Shipping on desktop 117
> Shipping on Android 117
> Shipping on WebView 117
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5157467960377344
>
> Links to previous Intent discussions Intent to Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com
>
>
> This intent message was generated by Chrome Platform Status
> .
>
>
> --
> Frédéric Wang
>
> --
> 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/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%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/8a331320-cb6b-e102-05f9-d38abcb80a7a%40chromium.org
>

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Mike Taylor


LGTM1 - seems like an obvious interop win.

On 7/12/23 4:31 AM, Frédéric Wang wrote:



Hello,

This is actually an intent to ship (sorry for sending email with the 
wrong title).


To summarize a bit conversations, columnspan/rowspan was something 
that was requested by web developers and is used in existing 
documents. We cannot just say "use CSS instead" as they are no 
equivalent properties.


Initially, we wanted to have this in the initial MathML implementation 
but things were postponed because we needed to decide between "make 
things more compatible with HTML" (i.e. colspan/rowspan names) or 
"make things backward compatible with MathML3" (i.e. 
columnspan/rowspan names). Given the latter is already implemented by 
Firefox/WebKit and used in existing documents and tools we decided to 
go with the latter (Mozilla also positioned negatively about changing 
the name).




-



Contact emails

fw...@chromium.org


Explainer

None


Specification

https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd


Summary

Implement attributes to specify the number of columns and rows that a 
MathML table cell is to span. This is similar to HTML colspan/rowspan 
attributes and does not have equivalent CSS properties.




Blink component

Blink>MathML 
MathML> 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 
Mozilla positioned negatively about renaming 
https://github.com/mozilla/standards-positions/issues/74
(Note: this should be 
https://github.com/mozilla/standards-positions/issues/743)



/WebKit/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 



/Web developers/: Positive

/Other signals/:


WebView application risks

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




Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes
Tests are added in 
https://chromium-review.googlesource.com/c/chromium/src/+/4061476 
However, advanced parsing such as checking the max limits 1000 and 
65534 defined in HTML is a bit tedious as MathML does not have an IDL 
for tables yet ( 
https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093 
 
) so for now they are written as internal tests.



Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes

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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157467960377344


Links to previous Intent discussions

Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com 




This intent message was generated by Chrome Platform Status 
.



--
Frédéric Wang
--
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/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%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/8a331320-cb6b-e102-05f9-d38abcb80a7a%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

2023-07-12 Thread Daniel Bratell


Make that LGTM3

(What are the chances of three people looking at the same intent in the 
same minute? Well it seem to have happened)


/Daniel

On 2023-07-12 17:19, Daniel Bratell wrote:


LGTM2

/Daniel

On 2023-07-12 17:19, Yoav Weiss wrote:

LGTM1 - thanks for catching us up here!

On Thursday, July 6, 2023 at 1:33:39 PM UTC+2 f...@opera.com wrote:


Contact emails


f...@opera.com


Explainer


None (see summary)


Specification


https://www.w3.org/TR/css-transforms-1/#transform-box



Summary


Allows changing how the reference box for the 'transform'
property is computed. This adds additional capabilities
that will allow creating transforms/graphical effects
where - for example - the width of the border of an
element does not influence the result (e.g rotation
around a point in the content box) or the stroke of an
(SVG) element should influence the result (e.g rotating a
stroked shape around its center - including the stroke).


Blink component


Blink>SVG




TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Low interoperability risk. The feature being part of
Interop2023 gives it a decent chance of becoming
interoperable - at least within the subset that is tested
in that scope.



/Gecko/: No signal This is small change that is in scope
of Interop2023

/WebKit/: Shipped/Shipping
(https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1
)
Implemented since TP 96

/Web developers/: Positive (https://crbug.com/924472) 9+
stars in the bug tracker

/Other signals/:


WebView application risks


Minimal (adds a couple of new keywords to an existing
property)



Debuggability




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


Yes


Is this feature fully tested by web-platform-tests

?


Yes


Flag name on chrome://flags




Finch feature name


CSSTransformBoxAdditionalKeywords


Requires code in //chrome?


False


Sample links


https://developer.mozilla.org/en-US/docs/Web/CSS/transform-box



Estimated milestones


Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes


None


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/6208828575580160



Links to previous Intent discussions


Original I2S for the transform-box property:

https://groups.google.com/a/chromium.org/g/blink-dev/c/4ZWHz8tCONI/m/XBTvQtw2BAAJ



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/2c2df193-d602-4b6e-9cf8-5658dd0ffd43n%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/92ec16e1-5db2-03fb-1936-f46832a1619e%40gmail.com 
.


--
You received this me

Re: [blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

2023-07-12 Thread Daniel Bratell


LGTM2

/Daniel

On 2023-07-12 17:19, Yoav Weiss wrote:

LGTM1 - thanks for catching us up here!

On Thursday, July 6, 2023 at 1:33:39 PM UTC+2 f...@opera.com wrote:


Contact emails


f...@opera.com


Explainer


None (see summary)


Specification


https://www.w3.org/TR/css-transforms-1/#transform-box



Summary


Allows changing how the reference box for the 'transform'
property is computed. This adds additional capabilities
that will allow creating transforms/graphical effects
where - for example - the width of the border of an
element does not influence the result (e.g rotation around
a point in the content box) or the stroke of an (SVG)
element should influence the result (e.g rotating a
stroked shape around its center - including the stroke).


Blink component


Blink>SVG




TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Low interoperability risk. The feature being part of
Interop2023 gives it a decent chance of becoming
interoperable - at least within the subset that is tested
in that scope.



/Gecko/: No signal This is small change that is in scope
of Interop2023

/WebKit/: Shipped/Shipping
(https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1
)
Implemented since TP 96

/Web developers/: Positive (https://crbug.com/924472) 9+
stars in the bug tracker

/Other signals/:


WebView application risks


Minimal (adds a couple of new keywords to an existing
property)



Debuggability




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


Yes


Is this feature fully tested by web-platform-tests

?


Yes


Flag name on chrome://flags




Finch feature name


CSSTransformBoxAdditionalKeywords


Requires code in //chrome?


False


Sample links


https://developer.mozilla.org/en-US/docs/Web/CSS/transform-box



Estimated milestones


Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes


None


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/6208828575580160



Links to previous Intent discussions


Original I2S for the transform-box property:

https://groups.google.com/a/chromium.org/g/blink-dev/c/4ZWHz8tCONI/m/XBTvQtw2BAAJ



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/2c2df193-d602-4b6e-9cf8-5658dd0ffd43n%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/92ec16e1-5db2-03fb-1936-f46832a1619e%40gmail.com.

Re: [blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

2023-07-12 Thread Mike Taylor


LGTM2

On 7/12/23 11:19 AM, Yoav Weiss wrote:

LGTM1 - thanks for catching us up here!

On Thursday, July 6, 2023 at 1:33:39 PM UTC+2 f...@opera.com wrote:


Contact emails


f...@opera.com


Explainer


None (see summary)


Specification


https://www.w3.org/TR/css-transforms-1/#transform-box



Summary


Allows changing how the reference box for the 'transform'
property is computed. This adds additional capabilities
that will allow creating transforms/graphical effects
where - for example - the width of the border of an
element does not influence the result (e.g rotation around
a point in the content box) or the stroke of an (SVG)
element should influence the result (e.g rotating a
stroked shape around its center - including the stroke).


Blink component


Blink>SVG




TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Low interoperability risk. The feature being part of
Interop2023 gives it a decent chance of becoming
interoperable - at least within the subset that is tested
in that scope.



/Gecko/: No signal This is small change that is in scope
of Interop2023

/WebKit/: Shipped/Shipping
(https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1
)
Implemented since TP 96

/Web developers/: Positive (https://crbug.com/924472) 9+
stars in the bug tracker

/Other signals/:


WebView application risks


Minimal (adds a couple of new keywords to an existing
property)



Debuggability




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


Yes


Is this feature fully tested by web-platform-tests

?


Yes


Flag name on chrome://flags




Finch feature name


CSSTransformBoxAdditionalKeywords


Requires code in //chrome?


False


Sample links


https://developer.mozilla.org/en-US/docs/Web/CSS/transform-box



Estimated milestones


Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes


None


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/6208828575580160



Links to previous Intent discussions


Original I2S for the transform-box property:

https://groups.google.com/a/chromium.org/g/blink-dev/c/4ZWHz8tCONI/m/XBTvQtw2BAAJ



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/2c2df193-d602-4b6e-9cf8-5658dd0ffd43n%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/dd96b694-a5d0-b477-43ee-eb6283d77676%40chromium.org.

[blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

2023-07-12 Thread Yoav Weiss

LGTM1 - thanks for catching us up here!

On Thursday, July 6, 2023 at 1:33:39 PM UTC+2 f...@opera.com wrote:

> Contact email...@opera.com
>
> ExplainerNone (see summary)
>
> Specificationhttps://www.w3.org/TR/css-transforms-1/#transform-box
>
> Summary
>
> Allows changing how the reference box for the 'transform' property is 
> computed. This adds additional capabilities that will allow creating 
> transforms/graphical effects where - for example - the width of the border 
> of an element does not influence the result (e.g rotation around a point in 
> the content box) or the stroke of an (SVG) element should influence the 
> result (e.g rotating a stroked shape around its center - including the 
> stroke).
>
> Blink componentBlink>SVG 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Low interoperability risk. The feature being part of Interop2023 gives it 
> a decent chance of becoming interoperable - at least within the subset that 
> is tested in that scope.
>
>
> *Gecko*: No signal This is small change that is in scope of Interop2023
>
> *WebKit*: Shipped/Shipping (
> https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1) 
> Implemented since TP 96
>
> *Web developers*: Positive (https://crbug.com/924472) 9+ stars in the bug 
> tracker
>
> *Other signals*:
>
> WebView application risks
>
> Minimal (adds a couple of new keywords to an existing property)
>
>
>
> Debuggability
>
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> Flag name on chrome://flags
>
> Finch feature nameCSSTransformBoxAdditionalKeywords
>
> Requires code in //chrome?False
>
> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/transform-box
>
> Estimated milestones
> Shipping on desktop 117
> Shipping on Android 117
> Shipping on WebView 117
>
> Anticipated spec changes
>
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6208828575580160
>
> Links to previous Intent discussionsOriginal I2S for the transform-box 
> property: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/4ZWHz8tCONI/m/XBTvQtw2BAAJ
>
> 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/2c2df193-d602-4b6e-9cf8-5658dd0ffd43n%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS text-wrap: pretty

2023-07-12 Thread Yoav Weiss

LGTM3

On Tuesday, July 4, 2023 at 10:15:12 AM UTC+2 Koji Ishii wrote:

> Thank you Larry for the feedback.
>
> By "typographic styling efforts" do you mean other CSS features? If yes, 
> thank you for pointing that out, I'll look into them for possible 
> relationships with this feature.
>
> When I wrote "other implementations", I meant "other browsers," as they 
> may take different tradeoffs and get different feedback from their users. 
> Sorry for not being clear, but I agree both should be investigated for 
> improving typography more. Thank you.
>
> On Tue, Jul 4, 2023 at 4:04 AM 'Larry LACa' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> @ko..  Re: other implementations. 
>> There are a number of typographic styling efforts.  E.g. CSS-Pseudo-4
>> CSS-Pseudo-4 | w3.org 
>>
>> On Sunday, July 2, 2023 at 11:44:54 PM UTC-7 ko...@chromium.org wrote:
>>
>>> Thank you Alex for the feedback. Replied to the doc.
>>>
>>> In short, I'm supportive of giving more controls to authors, to achieve 
>>> a more similar level of the typography as LaTeX. There are multiple ideas 
>>> how to do it in a world where multiple implementations exist. I think it 
>>> will need further author feedback, experiences from other implementations, 
>>> and discussions at the CSSWG.
>>>
>>> On Thu, Jun 29, 2023 at 12:58 AM Alex Russell  
>>> wrote:
>>>
 Have followed up again in the design doc. Would like to make sure that 
 multiple (potentially competing) values for `text-wrap` have clear 
 precedence and that we have a plan for adding new values (e.g., for full 
 LaTeX flow for printing).

 Thanks again.

 Best,

 Alex

 On Wednesday, June 28, 2023 at 8:49:36 AM UTC-7 Daniel Bratell wrote:

>>> LGTM2
>
> /Daniel
> On 2023-06-28 16:57, Rick Byers wrote:
>
 LGTM1
>
> On Wed, Jun 21, 2023 at 10:51 AM Koji Ishii  
> wrote:
>
> Contact emails ko...@chromium.org
>>
>> Explainer None
>>
>> Specification 
>> https://drafts.csswg.org/css-text-4/#valdef-text-wrap-pretty
>>
>> Design docs 
>>
>> https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yTsvg8IuAq7oFrNQxPeqI/edit?usp=sharing
>>
>> Summary 
>>
>> Adjusts line breaking to avoid a short single word on the last line 
>> (also known as typographic orphans.) When `text-wrap: pretty` is 
>> specified, 
>> paragraphs that will end up with a short single word on the last line 
>> are 
>> adjusted so that the last line has two or more words. The algorithm is 
>> based on the Knuth-Plass algorithm, as used by TeX. It computes scores 
>> for 
>> all candidates, and chooses the best one. To balance between the 
>> typographic benefits and the performance impacts, it adjsuts the last 4 
>> lines of paragraphs that meet certain conditions.
>>
>>
>> Blink component Blink>Layout>Inline 
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> Low. This value only sets a bias for better layout over speed, 
>> without any particular requirements. Browsers that don't support this 
>> value 
>> will fall back to their default line breaking algorithm, but both the 
>> exact 
>> line breaking results for this value and for the default value are not 
>> defined.
>>
>>
>> *Gecko*: Positive (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=630181)
>>
>> *WebKit*: Positive (https://github.com/w3c/csswg-drafts/issues/672) 
>> This property is originally requested by an WebKit engineer.
>>
>> *Web developers*: Positive (
>> https://clagnut.com/blog/2424#:~:text=the%20specification%20is-,text%2Dwrap%3Apretty,-.%20If%20it%E2%80%99s%20ever)
>>  
>> When Blink shipped `text-wrap: balance` that improved headlines, many 
>> tweets and articles are seen on the web, wanting the feature to avoid a 
>> single word on the last line (typographic orphans) for body text. 
>> https://medium.com/swlh/typographic-orphans-on-the-web-266e32f756fe has 
>> a simple JS solution to avoid typographic orphans. 
>> https://github.com/robertknight/tex-linebreak is a JS implementation 
>> of the Knuth-Plass algorithm, has 111 stars.
>>
>> *Other signals*:
>>
>> Ergonomics 
>>
>> Another related value of this property `text-wrap: balance` improves 
>> line breaking for headlines, while this value improves typography for 
>> body 
>> text.
>>
>>
>> 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

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

2023-07-12 Thread Yoav Weiss

On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> yu...@google.com, yu...@chromium.org, fer...@chromium.org
>
> Explainer
>
>
> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
>
> Specification
>
> https://github.com/whatwg/html/pull/9360
>
> Design docs
>
>
> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md
>
> Summary
>
> NotRestoredReason API will report the list of reasons why a page is not
> served from BFcache in a frame tree structure, via
> PerformanceNavigationTiming API.
>
>
> Blink component
>
> UI>Browser>Navigation>BFCache
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/739
>
> TAG review status
>
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Defer (https://github.com/mozilla/standards-positions/issues/766)
> Once issues (standardized reasons & unsalvageable documents), they would
> switch to positive.
>

It seems like the "standardized reasons" part is addressed in your PR. Is
the same true for the second point?


>
> WebKit: No signal (
> https://github.com/WebKit/standards-positions/issues/154)
>
> Web developers: Positive (
> https://github.com/w3c/navigation-timing/issues/171#issuecomment-1062672989
> )
>
> Other signals: Positive from Origin Trial users:
>
> How likely are you to keep using this feature?
>
> 92% answered likely, 8% (1 vote) is unsure
>
> Security
>
> We do not report detailed information about cross-origin iframes. See Security
> and Privacy section
> 
> in the explainer.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> No.
>
>
> Debuggability
>
> In DevTools console, try:
>
> performance.getEntriesByType('navigation')[0].notRestoredReasons;
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
> NotRestoredReasons API is available on all platforms including WebView,
> but back/forward cache is not enabled on WebView. So on WebView,
> NotRestoredReasons API should always say that the page is blocked from
> being restored from bfcache with the reason being something like “not
> supported”.
>
> (Currently it reports null due to a bug
> )
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes.
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/
>
> DevTrial instructions
>
>
> https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/HowToTest.md
>
> Flag nameblink RunTimeEnabledFeature:
> BackForwardCacheSendNotRestoredReasons
> 
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1326344
>
> Launch bug
>
> https://launch.corp.google.com/launch/4200848
>
> Estimated milestones
>
> Shipping on desktop
>
> 116
>
> OriginTrial desktop last
>
> 114
>
> OriginTrial desktop first
>
> 109
>
> DevTrial on desktop
>
> 108
>
> Shipping on Android
>
> 116
>
> OriginTrial Android last
>
> 114
>
> OriginTrial Android first
>
> 109
>
> DevTrial on Android
>
> 108
>
>
> Shipping on WebView
>
> 116
>
> OriginTrial WebView last
>
> 114
>
> OriginTrial WebView first
>
> 109
>
> DevTrial on WebView
>
> 108
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues.
>
> https://github.com/whatwg/html/pull/9360
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5684908759449600
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoGAzjUjzv3WmxcRpUSBgnA-AHQ05kh9gXc%2BQB8pRM6%2BfA%40mail.gmail.com
> Intent to Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHe391sAB2PdbEVw9uiSPFxTB_EYsRizcPpZ7-pg16O0A%40mail.gmail.com
>
> Intent to Extend Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698QcKZSthm%3Dz_4pi8cOzi4kfbx-AXveC%2BAKimUh-tMycA%40mail.gmail.com
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google

Re: [blink-dev] Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

2023-07-12 Thread Yoav Weiss

LGTM3 for a careful rollout!

On Wed, Jul 12, 2023 at 3:53 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2023-07-10 21:55, Mike Taylor wrote:
>
> LGTM1
> On 7/10/23 11:23 AM, Dominic Farolino wrote:
>
> The niche-ness of these changes plus the fact that they've been rolled out
> on Canary+Dev for some time *and* that we've already smoked out some
> compat issues at that level of experimentation for the adjacent work the
> team looked into (censoring the base URL for sandboxed about:srcdoc
> Documents) makes me fairly comfortable that we have a good grip on the
> compat implications of this, IMO.
>
> On Fri, Jul 7, 2023 at 12:01 PM W. James MacLean 
> wrote:
>
>> At present there is no mechanism I'm aware of for tracking when baseURIs
>> are accessed in scenarios where the behavior might be different from what
>> is expected. I'm not quite sure what that would look like exactly, as at
>> the document level we don't expect to know if initiator = parent or not. We
>> expect the compat risk to be quite low, as the initiator != parent case
>> seems likely to be rare. But it might not be zero and we don't have any
>> numbers on what it might actually be.
>>
>> As Dominic mentioned, we think the risk is low enough that a careful &
>> gradual deployment (with a killswitch available, and an enterprise policy
>> in place to allow disabling the new behavior at the enterprise level)
>> should be safe. But if there's concern that might not be safe enough, we
>> can look into it further. I've held off releasing this to beta for now,
>> though it's been active on canary+dev for quite a while now.
>>
>> On Mon, 3 Jul 2023 at 00:03, Yoav Weiss  wrote:
>>
>>> A couple of questions:
>>>
>>>- Should we wait until the PR matures a bit and gets reviewed?
>>>WebKit's position is encouraging, but it'd be an even better signal to be
>>>able to land the PR.
>>>- How can we evaluate the compat risk here?
>>>
>>> RE the latter, is there a way to usecount how often the baseURI is
>>> accessed in places that will change behavior here? That can give us an
>>> upper bound on potential breakage.
>>>
>>> On Mon, Jul 3, 2023 at 4:00 AM Domenic Denicola 
>>> wrote:
>>>
 Let me just say, with my HTML Standard editor hat on, that I am very
 excited for these changes. This area is currently a wasteland of
 non-interoperable behavior, broken specifications, and
 web-developer-expectations violations. The team has done some amazing work
 to figure out a model that works well, is conceptually elegant, and has
 minimal compat concerns. And although I haven't done my editor review yet,
 I'm excited to see that they've sent spec PRs and a good number of web
 platform tests for this area.

 There may still be compat risks here, but I think the benefits of
 getting a reasonable model for base URL inheritance are worth pushing
 forward (with careful deployment and a kill-switch). Thanks so much to the
 team for this work.

 On Sat, Jul 1, 2023 at 3:41 AM W. James MacLean 
 wrote:

> Intent to Ship: Inherit Base URL snapshot for about:blank and
> about:srcdoc, with about:blank inheriting from initiator, not parent.
>
> Contact emails
>
> wjmacl...@chromium.org
>
> cr...@chromium.org
>
> d...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://github.com/whatwg/html/pull/9464 (original proposal
> )
>
> Summary
>
> This work aims to fix issues and improve the compatibility of
> Chromium's implementation of fallback base URL
>  specifically for
> about:srcdoc and about:blank frames. The base URL can be accessed
> directly with document.baseURI, and indirectly when resolving relative
> URLs.  Chromium's current behavior differs from Safari & Firefox in 
> several
> ways. Chromium and Safari only partially snapshot the base URL for an
> about:blank/srcdoc document from its creator document, and the
> about:blank/srcdoc document usually does not observe later changes to
> its creator document's base URL. Still, such changes may become visible in
> corner cases (e.g., if the child makes and then reverses changes to its
> own  element, its partial snapshot gets updated from its
> creator).
>
>
>
> We propose that the base URL supplied to about:srcdoc and about:blank
> frames and popups are snapshotted from their initiator at the time the
> navigation begins. The implementation will also allow base URL to work
> correctly for about:srcdoc frames when those frames are in a
> different process from their parent (e.g., sandboxed srcdoc iframes).
>
>
> Web-Visible Changes in Chrome
>
>-
>
>Inherit Base URL from Initiator: We propose to change

Re: [blink-dev] Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

2023-07-12 Thread Daniel Bratell


LGTM2

/Daniel

On 2023-07-10 21:55, Mike Taylor wrote:


LGTM1

On 7/10/23 11:23 AM, Dominic Farolino wrote:
The niche-ness of these changes plus the fact that they've been 
rolled out on Canary+Dev for some time /and/ that we've already 
smoked out some compat issues at that level of experimentation for 
the adjacent work the team looked into (censoring the base URL for 
sandboxed about:srcdoc Documents) makes me fairly comfortable that we 
have a good grip on the compat implications of this, IMO.


On Fri, Jul 7, 2023 at 12:01 PM W. James MacLean 
 wrote:


At present there is no mechanism I'm aware of for tracking when
baseURIs are accessed in scenarios where the behavior might be
different from what is expected. I'm not quite sure what that
would look like exactly, as at the document level we don't expect
to know if initiator = parent or not. We expect the compat risk
to be quite low, as the initiator != parent case seems likely to
be rare. But it might not be zero and we don't have any numbers
on what it might actually be.

As Dominic mentioned, we think the risk is low enough that a
careful & gradual deployment (with a killswitch available, and an
enterprise policy in place to allow disabling the new behavior at
the enterprise level) should be safe. But if there's concern that
might not be safe enough, we can look into it further. I've held
off releasing this to beta for now, though it's been active on
canary+dev for quite a while now.

On Mon, 3 Jul 2023 at 00:03, Yoav Weiss 
wrote:

A couple of questions:

  * Should we wait until the PR matures a bit and gets
reviewed? WebKit's position is encouraging, but it'd be
an even better signal to be able to land the PR.
  * How can we evaluate the compat risk here?

RE the latter, is there a way to usecount how often the
baseURI is accessed in places that will change behavior here?
That can give us an upper bound on potential breakage.

On Mon, Jul 3, 2023 at 4:00 AM Domenic Denicola
 wrote:

Let me just say, with my HTML Standard editor hat on,
that I am very excited for these changes. This area is
currently a wasteland of non-interoperable behavior,
broken specifications, and web-developer-expectations
violations. The team has done some amazing work to figure
out a model that works well, is conceptually elegant, and
has minimal compat concerns. And although I haven't done
my editor review yet, I'm excited to see that they've
sent spec PRs and a good number of web platform tests for
this area.

There may still be compat risks here, but I think the
benefits of getting a reasonable model for base URL
inheritance are worth pushing forward (with careful
deployment and a kill-switch). Thanks so much to the team
for this work.

On Sat, Jul 1, 2023 at 3:41 AM W. James MacLean
 wrote:

Intent to Ship: Inherit Base URL snapshot for
about:blank and about:srcdoc, with about:blank
inheriting from initiator, not parent.


Contact emails

wjmacl...@chromium.org 

cr...@chromium.org 

d...@chromium.org 


Explainer

None


Specification

https://github.com/whatwg/html/pull/9464
(original
proposal

)


Summary

This work aims to fix issues and improve the
compatibility of Chromium's implementation of
fallback base URL
specifically
for about:srcdoc and about:blank frames. The base URL
can be accessed directly with document.baseURI, and
indirectly when resolving relative URLs.  Chromium's
current behavior differs from Safari & Firefox in
several ways. Chromium and Safari only
partiallysnapshot the base URL for an
about:blank/srcdoc document from its creator
document, and the about:blank/srcdoc document usually
does not observe later changes to its creator
document's base URL. Still, such changes may become
visible in corner cases (e.g., if the child makes and
then reverses changes to its own element, its
partial snapshot gets updated from its cr

[blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Frédéric Wang



   Hello,

This is actually an intent to ship (sorry for sending email with the 
wrong title).


To summarize a bit conversations, columnspan/rowspan was something that 
was requested by web developers and is used in existing documents. We 
cannot just say "use CSS instead" as they are no equivalent properties.


Initially, we wanted to have this in the initial MathML implementation 
but things were postponed because we needed to decide between "make 
things more compatible with HTML" (i.e. colspan/rowspan names) or "make 
things backward compatible with MathML3" (i.e. columnspan/rowspan 
names). Given the latter is already implemented by Firefox/WebKit and 
used in existing documents and tools we decided to go with the latter 
(Mozilla also positioned negatively about changing the name).




   -



   Contact emails

fw...@chromium.org


   Explainer

None


   Specification

https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd


   Summary

Implement attributes to specify the number of columns and rows that a 
MathML table cell is to span. This is similar to HTML colspan/rowspan 
attributes and does not have equivalent CSS properties.




   Blink component

Blink>MathML 
MathML>



   TAG review

None


   TAG review status

Not applicable


   Risks



   Interoperability and Compatibility



/Gecko/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 
Mozilla positioned negatively about renaming 
https://github.com/mozilla/standards-positions/issues/74


/WebKit/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 



/Web developers/: Positive

/Other signals/:


   WebView application risks

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




   Debuggability



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

Yes


   Is this feature fully tested by web-platform-tests
   
?

Yes


Tests are added in 
https://chromium-review.googlesource.com/c/chromium/src/+/4061476 
However, advanced parsing such as checking the max limits 1000 and 65534 
defined in HTML is a bit tedious as MathML does not have an IDL for 
tables yet ( 
https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093 
 
) so for now they are written as internal tests.



   Flag name on chrome://flags



   Finch feature name



   Non-finch justification

None


   Requires code in //chrome?

False


   Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



   Anticipated spec changes

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




   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157467960377344


   Links to previous Intent discussions

Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com 




This intent message was generated by Chrome Platform Status 
.



--
Frédéric Wang

--
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/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%40igalia.com.

[blink-dev] Intent to Experiment: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Frédéric Wang



   Contact emails

fw...@chromium.org


   Explainer

None


   Specification

https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd


   Summary

Implement attributes to specify the number of columns and rows that a 
MathML table cell is to span. This is similar to HTML colspan/rowspan 
attributes and does not have equivalent CSS properties.




   Blink component

Blink>MathML 
MathML>



   TAG review

None


   TAG review status

Not applicable


   Risks



   Interoperability and Compatibility



/Gecko/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 
Mozilla positioned negatively about renaming 
https://github.com/mozilla/standards-positions/issues/74


/WebKit/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 



/Web developers/: Positive

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




   Goals for experimentation



   Ongoing technical constraints



   Debuggability



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

Yes


   Is this feature fully tested by web-platform-tests
   
?

Tests are added in 
https://chromium-review.googlesource.com/c/chromium/src/+/4061476 
However, advanced parsing such as checking the max limits 1000 and 65534 
defined in HTML is a bit tedious as MathML does not have an IDL for 
tables yet ( 
https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093 
 
) so for now they are written as internal tests.



   Flag name on chrome://flags



   Finch feature name



   Non-finch justification

None


   Requires code in //chrome?

False


   Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157467960377344


   Links to previous Intent discussions

--
Frédéric Wang

--
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/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com.

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

Re: [blink-dev] Re: Intent to Deprecate and Remove Web SQL

Re: [blink-dev] Intent to Prototype: Insert CJK Inter-script Spacing: the CSS `text-autospace` property

Re: [blink-dev] Intent to Prototype: Insert CJK Inter-script Spacing: the CSS `text-autospace` property

[blink-dev] Intent to Prototype: Insert CJK Inter-script Spacing: the CSS `text-autospace` property

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

Re: [blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

Re: [blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

Re: [blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

[blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

Re: [blink-dev] Intent to Ship: CSS text-wrap: pretty

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

Re: [blink-dev] Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

Re: [blink-dev] Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

[blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

[blink-dev] Intent to Experiment: MathML columnspan/rowspan attributes on element

19 matches

Site Navigation

Mail list logo

Footer information