from:"Khushal Sagar"

[blink-dev] Web-Facing Change PSA: View Transitions in iframes

2024-05-27 Thread 'Khushal Sagar' via blink-dev

Hey folks,

Starting in Chrome M127, there will be the following changes for View
Transitions in iframes:


   -

   Concurrent same-document View Transitions in a main frame and
   same-origin iframe will be available starting with 127.0.6499.3.

   Previously, running a View Transition using the
   `document.startViewTransition` in a same-origin iframe wouldn’t work if the
   main frame was running a transition at the same time. The iframe’s
   transition would be automatically skipped. Now, both transitions will
   execute.



   -

   View Transitions on same-origin cross-document navigations in an iframe
   will be available starting with 127.0.6500.0.

   View Transitions on same-origin cross-document navigations referenced in
   this intent
   
   was launched only for main frames in Chrome 126. This limitation has now
   been removed.


Please let me know if there are any questions.

Thanks.

Khushal

-- 
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/CAMLuWUyJy4MtqS%2B_QOz6orN7yNZFznKgVMKTnrFNosWOsDT%2BtQ%40mail.gmail.com.

[blink-dev] Intent to Ship: View Transitions Same-Origin Navigation

2024-04-30 Thread 'Khushal Sagar' via blink-dev

Contact emails

bo...@google.com, khushalsa...@google.com, nrosent...@google.com,
vmp...@google.com

Explainer

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

Specification

https://drafts.csswg.org/css-view-transitions-2

https://github.com/w3c/transitions/issues/595 tracks publishing a FPWD for
this spec based on the resolution here
.

Summary

The first phase of the View Transitions API, shipped here
,
allows authors to define visual transitions in SPAs (DOM state changes in
the same Document).

This intent is about expanding the API to support MPAs. MPA implies
same-origin navigations that replace the document with another document (in
the main frame or nested iframe).

This is a highly requested additional feature. Examples are:
https://chriscoyier.net/2022/11/08/astro-stands-to-benefit-highly-from-view-transitions/
, https://adactio.com/journal/19578.

Blink component

Blink>ViewTransitions>MPA

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

Issues addressed

RisksInteroperability and Compatibility

None. This feature is a progressive enhancement and authors can fallback to
the current UX if the feature is not available.

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

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

Web developers: Strongly 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?

None

Debuggability

The feature can be debugged using standard tooling in devtools.
Specifically the animation panel can be used to pause and scrub through the
default animations set by the browser.

The pseudo DOM structure generated by the UA can also be inspected and
targeted, like other DOM elements, in the style panel.

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

Flag name on chrome://flags

view-transition-on-navigation

Finch feature name

ViewTransitionOnNavigation

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1372584

Estimated milestones

Shipping on desktop

127

DevTrial on desktop

109

Shipping on Android

127

DevTrial on Android

109

Shipping on WebView

127

Note: We plan to roll out the feature via finch to monitor for stability
issues. 126 is the target milestone for roll out to beta; before shipping
to stable in 127.

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/511887463936?gate=5059113954836480

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUxMPaChgK0VH6cZNY_LE68zNQ-NTxA7DFzd-7PjyKi1Dw%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/CAMLuWUw7xrzZN0pKW%2BBFBvW7PStrX%3DvXEOr9zOSGWuFh6TJ_LQ%40mail.gmail.com.

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

2024-03-12 Thread 'Khushal Sagar' via blink-dev

Hey folks,

There's a minor change to the semantics of this event based on security
feedback: https://github.com/whatwg/html/issues/10196. Originally we
provided the activation info if the navigation is same-origin. The proposed
change is to limit it further to same-origin navigations with no
cross-origin redirects. I'll wait for this issue to be resolved before
shipping the feature.

Let me know if another review is needed for the proposed change or this
intent is still good to go.

Thanks.
Khushal

On Wed, Mar 6, 2024 at 11:27 AM Chris Harrelson 
wrote:

> LGTM3
>
> On Wed, Mar 6, 2024 at 8:21 AM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2024-03-06 16:58, 'Khushal Sagar' via blink-dev wrote:
>>
>>
>>
>> On Wed, Mar 6, 2024 at 6:32 AM Manuel Rego Casasnovas 
>> wrote:
>>
>>> What's going on with the tests?
>>>
>>>
>>> https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pageswap?label=master=experimental=chrome=firefox=safari
>>
>>
>> The code to dispatch this event is partly in the browser process, so
>> turning on experimental web features doesn't enable the flag there. We have
>> a virtual tests suite
>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/VirtualTestSuites;l=2762;drc=9bb588200a9667f2dbff27e490ad576558bf1d30>
>>  to
>> run the test on the bots, won't be necessary once we switch runtime feature
>> status to stable.
>>
>>
>>>
>>>
>>> Thanks,
>>>Rego
>>>
>>> On 06/03/2024 11:57, Yoav Weiss (@Shopify) wrote:
>>> > LGTM1
>>> >
>>> > On Wed, Mar 6, 2024 at 11:54 AM Noam Rosenthal <
>>> nrosent...@chromium.org
>>> > <mailto:nrosent...@chromium.org>> wrote:
>>> >
>>> >
>>> >
>>> > Summary
>>> >
>>> > The `pageswap` event is fired on a Document's window
>>> > object when a navigation will replace this Document
>>> with
>>> > a new Document. The event provides activation info
>>> about
>>> > the navigation (type, NavigationHistoryEntry for the
>>> new
>>> > Document). If the navigation has a cross-document
>>> > ViewTransition, the event is dispatched before
>>> capturing
>>> > state for the old Document. This allows the page-author
>>> > to configure the old state captured for the transition
>>> > based on the navigation's activation info and the
>>> > current visual state of the old Document. This feature
>>> > is split out from the larger
>>> > ViewTransition-on-Navigation project.
>>> >
>>> >
>>> > Why is it split out? Is there some utility for this regardless
>>> > of view transitions?
>>> >
>>> > Absolutely! For example it's a place where you can figure out that
>>> > you're navigating away to a different same-origin document (after
>>> > redirects), and act on it in some way, e.g. put something in
>>> > `sessionStorage` like a video playback position.
>>> > It's different from `pagehide` in that sense, because with
>>> > `pagehide` you don't know you're going to a new document.
>>> >
>>> > Also by having a generic event with an optional viewTransition
>>> > property, it can tell the author that a view transition *didn't*
>>> > take place, which we can't do with a view-transition event.
>>> >
>>> > The design for this (as for `pagerveal`) started from
>>> > view-transition-specific events and ended up gravitating towards
>>> > this kind of event with an optional attribute for this reason, and
>>> > also to avoid a situation where people create fake view transitions
>>> > for the purpose of getting these events.
>>> >
>>> >
>>> > Makes sense!
>>> >
>>> >
>>> > Blink component
>>> >
>>> > Blink>ViewTransitions
>>> > <
>>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EViewTransitions
>>> >
>>> >
>>> >
>>> >

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

2024-03-06 Thread 'Khushal Sagar' via blink-dev

On Wed, Mar 6, 2024 at 6:32 AM Manuel Rego Casasnovas 
wrote:

> What's going on with the tests?
>
>
> https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pageswap?label=master=experimental=chrome=firefox=safari


The code to dispatch this event is partly in the browser process, so
turning on experimental web features doesn't enable the flag there. We have
a virtual tests suite

to
run the test on the bots, won't be necessary once we switch runtime feature
status to stable.


>
>
> Thanks,
>Rego
>
> On 06/03/2024 11:57, Yoav Weiss (@Shopify) wrote:
> > LGTM1
> >
> > On Wed, Mar 6, 2024 at 11:54 AM Noam Rosenthal  > > wrote:
> >
> >
> >
> > Summary
> >
> > The `pageswap` event is fired on a Document's window
> > object when a navigation will replace this Document with
> > a new Document. The event provides activation info about
> > the navigation (type, NavigationHistoryEntry for the new
> > Document). If the navigation has a cross-document
> > ViewTransition, the event is dispatched before capturing
> > state for the old Document. This allows the page-author
> > to configure the old state captured for the transition
> > based on the navigation's activation info and the
> > current visual state of the old Document. This feature
> > is split out from the larger
> > ViewTransition-on-Navigation project.
> >
> >
> > Why is it split out? Is there some utility for this regardless
> > of view transitions?
> >
> > Absolutely! For example it's a place where you can figure out that
> > you're navigating away to a different same-origin document (after
> > redirects), and act on it in some way, e.g. put something in
> > `sessionStorage` like a video playback position.
> > It's different from `pagehide` in that sense, because with
> > `pagehide` you don't know you're going to a new document.
> >
> > Also by having a generic event with an optional viewTransition
> > property, it can tell the author that a view transition *didn't*
> > take place, which we can't do with a view-transition event.
> >
> > The design for this (as for `pagerveal`) started from
> > view-transition-specific events and ended up gravitating towards
> > this kind of event with an optional attribute for this reason, and
> > also to avoid a situation where people create fake view transitions
> > for the purpose of getting these events.
> >
> >
> > Makes sense!
> >
> >
> > Blink component
> >
> > Blink>ViewTransitions
> > <
> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EViewTransitions
> >
> >
> >
> > TAG review
> >
> >
> https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258
> <
> https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258
> >
> >
> >
> > TAG review status
> >
> > Pending
> >
> >
> > Risks
> >
> >
> > Interoperability and Compatibility
> >
> > None
> >
> >
> > /Gecko/: Positive
> > (
> https://github.com/mozilla/standards-positions/issues/969 <
> https://github.com/mozilla/standards-positions/issues/969>)
> >
> >
> > Is that the right position?
> >
> > Yes, the name was changed while iterating, but it's the same feature
> > and Gecko folks took active part in the design and reviews.
> >
> >
> > Ooh, got it!
> >
> > --
> > 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/CAOmohSKjwe8bHquJ09vUW%2BeSvXr3tuBASCOKh1SAk7ay4Fay4Q%40mail.gmail.com
> <
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKjwe8bHquJ09vUW%2BeSvXr3tuBASCOKh1SAk7ay4Fay4Q%40mail.gmail.com?utm_medium=email_source=footer
> >.
>

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

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

2024-02-29 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@chromium.org, nrosent...@chromium.org

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

Specificationhttps://html.spec.whatwg.org/#the-pageswapevent-interface

Summary

The `pageswap` event is fired on a Document's window object when a
navigation will replace this Document with a new Document. The event
provides activation info about the navigation (type, NavigationHistoryEntry
for the new Document). If the navigation has a cross-document
ViewTransition, the event is dispatched before capturing state for the old
Document. This allows the page-author to configure the old state captured
for the transition based on the navigation's activation info and the
current visual state of the old Document. This feature is split out from
the larger ViewTransition-on-Navigation project.

Blink componentBlink>ViewTransitions


TAG review
https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258

TAG review statusPending

Risks

Interoperability and Compatibility

None

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

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

*Web developers*: Strongly positive This is one of the building blocks for
cross-document View Transitions which has high developer demand.

*Other signals*:

WebView application risks

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

None


Debuggability

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/html/browsers/browsing-the-web/history-traversal/pageconceal?label=experimental=master.
A PR to rename the event to pageswap in WPTs is in flight.


Flag name on chrome://flagsPageSwapEvent

Finch feature namePageSwapEvent

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/41495176

Estimated milestones
Shipping on desktop 124
Shipping on Android 124
Shipping on WebView 124

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUyCjahhiLy_%2B3mXTfF9v8h0T7tuZRa2FujT1qn_%3DXfQpw%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/CAMLuWUx41iLjW2A7LuvQfv95EOrVGh_969kit4WjuGZiu0ZhbQ%40mail.gmail.com.

[blink-dev] Intent to Prototype: 'pageconceal' event

2024-02-02 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@chromium.org, nrosent...@chromium.org

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

Specificationhttps://github.com/whatwg/html/pull/10002

Summary

The `pageconceal` event is fired on a Document's window object when a
navigation will replace this Document with a new Document. The event
provides activation info about the navigation (type, NavigationHistoryEntry
for the new Document). If the navigation has a cross-document
ViewTransition, the event is dispatched before capturing state for the old
Document. This allows the page-author to configure the old state captured
for the transition based on the navigation's activation info and the
current visual state of the old Document. This feature is split out from
the larger ViewTransition-on-Navigation project.

Blink componentBlink>ViewTransitions

Motivation

Cross-document ViewTransition need an event on the old Document so authors
can set up view-transition-names (or any other DOM state) to influence how
the Document is captured. This event needs to be fired: - After the final
response is received which provides the post redirect URL committed by the
navigation. - Before the last rendering opportunity for the Document (which
draws the frame cached by the browser) that runs after the navigation is
ready to commit. There is no existing event which aligns with the timing
requirements above. See discussion on
https://github.com/whatwg/html/issues/9702 for details. The event fires for
all cross-document navigation commits, with a nullable ViewTransition. This
allows authors to detect whether a cross-document navigation had a
transition.

Initial public proposalhttps://github.com/whatwg/html/issues/9702

TAG review
https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258

TAG review statusPending

Risks

Interoperability and Compatibility

None

*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/969)

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

*Web developers*: Strongly 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?

None

Debuggability

None

Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified

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

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/CAMLuWUyCjahhiLy_%2B3mXTfF9v8h0T7tuZRa2FujT1qn_%3DXfQpw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Detect UA Transitions on same-document Navigations

2023-08-22 Thread 'Khushal Sagar' via blink-dev

Clarifying since the explainer mentions 2 APIs. This intent is limited to a
boolean so sites can detect whether there is a UA transition and suppress
their custom transition.

We've paused work on an API to let authors disable UA transitions.
Community feedback (see TAG review here
<https://github.com/w3ctag/design-reviews/issues/835>) was against
developers disabling useful browser UX. Long term thinking is to introduce
APIs that let authors customize navigation gestures (whenever possible)
which are favoured over UA transitions. For cases where that's not possible
(either because APIs to customize don't exist today or the UX makes
developer customization infeasible), this API ensures there are no "double
transitions".

Chrome plans to ship UA transitions for swipe gestures soon where this
boolean will be set. The behaviour aligns with Webkit based browsers.

On Thu, Aug 17, 2023 at 1:32 PM Khushal Sagar 
wrote:

> FYI, the spec PR has landed.
>
> On Wed, Aug 16, 2023 at 1:44 PM Mike Taylor 
> wrote:
>
>> LGTM2
>> On 8/16/23 6:38 PM, Chris Harrelson wrote:
>>
>> LGTM1 to ship once the spec PR has landed.
>>
>> On Mon, Aug 14, 2023 at 7:50 AM 'Khushal Sagar' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails khushalsa...@google.com, liuwill...@google.com,
>>> hvanops...@google.com
>>>
>>> Explainer
>>> https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md
>>>
>>> Specification https://github.com/whatwg/html/pull/9579
>>>
>>> Summary
>>>
>>> Smooth visual transitions as users navigate on the web can lower
>>> cognitive load by helping users stay in context. However, the user
>>> experience is bad if both the site author and the UA add these transitions:
>>> the transitions may conflict and cause confusion for the user. This API
>>> avoids such cases to ensure only one visual transition is executed at a
>>> time. The API adds a boolean on `PopStateEvent` and `NavigateEvent` to
>>> indicate whether the UA has executed a visual transition for this
>>> navigation. Authors can use this to skip their custom transition.
>>>
>>>
>>> Blink component Blink>DefaultNavigationTransitions
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDefaultNavigationTransitions>
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/834
>>>
>>> TAG review status Issues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This feature is a progressive enhancement. In the absence of the
>>> feature, the author has to either conservatively assume there is a UA
>>> transition (and not do a custom transition) or risk visual glitches from
>>> double transition. As such there is no interop risk.
>>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/783)
>>>
>>> *WebKit*: Positive (
>>> https://github.com/WebKit/standards-positions/issues/176)
>>>
>>> *Web developers*: Strongly positive Issues like this:
>>> https://stackoverflow.com/questions/66867737/iphone-safari-detect-swipe-navigation.
>>> This is likely to happen more as authors can now use ViewTransitions to add
>>> custom transitions in SPAs.
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> None
>>>
>>>
>>> Security
>>>
>>> None. The API is limited to same-document navigations.
>>>
>>>
>>> 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
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ? No. WPTs assert that the attribute is present but not the value. By
>>> design, when this is set is left to the UA.
>>>
>>> Flag name on chrome://flags
>>>
>>> Finch feature name None
>>>
>>> Non-finch justification None
>>>
>>> Requires code in //chrome? False
>>>
>>

Re: [blink-dev] Intent to Ship: Detect UA Transitions on same-document Navigations

2023-08-17 Thread 'Khushal Sagar' via blink-dev

FYI, the spec PR has landed.

On Wed, Aug 16, 2023 at 1:44 PM Mike Taylor  wrote:

> LGTM2
> On 8/16/23 6:38 PM, Chris Harrelson wrote:
>
> LGTM1 to ship once the spec PR has landed.
>
> On Mon, Aug 14, 2023 at 7:50 AM 'Khushal Sagar' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails khushalsa...@google.com, liuwill...@google.com,
>> hvanops...@google.com
>>
>> Explainer
>> https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md
>>
>> Specification https://github.com/whatwg/html/pull/9579
>>
>> Summary
>>
>> Smooth visual transitions as users navigate on the web can lower
>> cognitive load by helping users stay in context. However, the user
>> experience is bad if both the site author and the UA add these transitions:
>> the transitions may conflict and cause confusion for the user. This API
>> avoids such cases to ensure only one visual transition is executed at a
>> time. The API adds a boolean on `PopStateEvent` and `NavigateEvent` to
>> indicate whether the UA has executed a visual transition for this
>> navigation. Authors can use this to skip their custom transition.
>>
>>
>> Blink component Blink>DefaultNavigationTransitions
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDefaultNavigationTransitions>
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/834
>>
>> TAG review status Issues addressed
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This feature is a progressive enhancement. In the absence of the feature,
>> the author has to either conservatively assume there is a UA transition
>> (and not do a custom transition) or risk visual glitches from double
>> transition. As such there is no interop risk.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/783)
>>
>> *WebKit*: Positive (
>> https://github.com/WebKit/standards-positions/issues/176)
>>
>> *Web developers*: Strongly positive Issues like this:
>> https://stackoverflow.com/questions/66867737/iphone-safari-detect-swipe-navigation.
>> This is likely to happen more as authors can now use ViewTransitions to add
>> custom transitions in SPAs.
>>
>> *Other signals*:
>>
>> Activation
>>
>> None
>>
>>
>> Security
>>
>> None. The API is limited to same-document navigations.
>>
>>
>> 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
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ? No. WPTs assert that the attribute is present but not the value. By
>> design, when this is set is left to the UA.
>>
>> Flag name on chrome://flags
>>
>> Finch feature name None
>>
>> Non-finch justification None
>>
>> Requires code in //chrome? False
>>
>> Estimated milestones
>> Shipping on desktop 118
>> Shipping on Android 118
>> Shipping on WebView 118
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5204831477694464
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/UJMYZXoSQ4A/m/OkIvKVtlAAAJ
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.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/CAMLuWUyhcTn1%3D%3DxfV0i5tyLS-APwqfDpetBstDie_4uMyxB1xQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUyhcTn1%3D%3DxfV0i5tyLS-APwqfDpetBstDie_4uMyxB1xQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Gr

Re: [blink-dev] Intent to Prototype: Document Render-Blocking

2023-08-17 Thread 'Khushal Sagar' via blink-dev

Thanks for the review Camille. Excellent questions!

On Wed, Aug 16, 2023 at 8:21 AM Camille Lamy  wrote:

> Hi Khushal,
>
> I am reviewing this for security as part of the OWP S review process. I
> had a few questions regarding the API to make sure we're assessing
> it correctly.
>
>1. Is the render blocking attribute something that only applies to one
>particular document, and does not block rendering of other documents (e.g.
>child iframes, parent iframes?)?
>
> The spec is a bit ambiguous about it because it doesn't explain how
rendering opportunities (rAFs) between Documents are intertwined.
Implementation wise, we definitely don't allow a child iframe (which is
render-blocked) to block rendering of the parent Document.

A local child Document is also render-blocked if the parent is. The case
with OOPIFs is tricky. If the parent hasn't drawn a frame yet, the child
will be assumed to be invisible. We don't render embedded frames unless
they are visible. The flow is similar to an iframe starting offscreen and
eventually coming onscreen. I'm a bit uncertain whether the child will see
1 rAF (and then get throttled) or no rAFs at all.

Also note that render-blocking concept shipped in Chrome via this intent
<https://groups.google.com/a/chromium.org/g/blink-dev/c/Ydpc6Lfx_7k/m/hbUNmnyqAgAJ>.
This intent is not changing the behaviour in how this feature affects
embedded frames. It's adding parsing to the category of resources which can
block rendering.

>
>1. Can the render blocking attribute only be set by the document that
>will be render blocked?
>
> It's the same as accessing any other attribute on the Document object. If
script has access to the Document object, it can set/read this attribute.
For example, for a same-origin iframe the embedding Document can access the
iframe's Document object so it can set this.


> Thanks!
> Camille
>
> On Wed, Aug 9, 2023 at 11:08 PM 'Khushal Sagar' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailskhushalsa...@google.com
>>
>> Explainer
>> https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md
>>
>> SpecificationNone
>>
>> Summary
>>
>> This feature enables authors to block rendering of a Document until the
>> critical content has been parsed, ensuring a consistent first paint across
>> all browsers. Without this feature, the first paint's state depends on the
>> heuristics for parser yielding which can vary across browsers. This is
>> particularly important for View Transitions where the parsed DOM state on
>> the first frame can drastically change the transition created.
>>
>>
>> Blink componentBlink>ViewTransitions>MPA
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EViewTransitions%3EMPA>
>>
>> Motivation
>>
>> The Web is designed with a model for incremental rendering. When a
>> Document is loading, the browser can render its intermediate states before
>> fetching all the requisite sub-resources, executing all script or
>> fetching/parsing the complete Document. While this is great to reduce the
>> time for first paint, there is a tradeoff between showing a jarring flash
>> of intermediate Document state (which could be unstyled or have more CLS)
>> vs blocking rendering on high priority sub-resources within a reasonable
>> timeout. The render-blocking concept helps browsers in making this
>> tradeoff. It lets authors specify the set of stylesheets and script
>> elements which should block rendering. For example, a stylesheet with the
>> rules necessary to ensure a stable layout. But authors can’t specify which
>> nodes should be added to the DOM before first render. This proposal aims to
>> fill this gap.
>>
>>
>> Initial public proposalhttps://github.com/whatwg/html/issues/9332
>>
>> TAG reviewNone
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?No
>>
>> Flag name on chrome://flagsNo

[blink-dev] Intent to Ship: Detect UA Transitions on same-document Navigations

2023-08-14 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@google.com, liuwill...@google.com,
hvanops...@google.com

Explainer
https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md

Specificationhttps://github.com/whatwg/html/pull/9579

Summary

Smooth visual transitions as users navigate on the web can lower cognitive
load by helping users stay in context. However, the user experience is bad
if both the site author and the UA add these transitions: the transitions
may conflict and cause confusion for the user. This API avoids such cases
to ensure only one visual transition is executed at a time. The API adds a
boolean on `PopStateEvent` and `NavigateEvent` to indicate whether the UA
has executed a visual transition for this navigation. Authors can use this
to skip their custom transition.

Blink componentBlink>DefaultNavigationTransitions

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

TAG review statusIssues addressed

Risks

Interoperability and Compatibility

This feature is a progressive enhancement. In the absence of the feature,
the author has to either conservatively assume there is a UA transition
(and not do a custom transition) or risk visual glitches from double
transition. As such there is no interop risk.

*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/783)

*WebKit*: Positive (https://github.com/WebKit/standards-positions/issues/176
)

*Web developers*: Strongly positive Issues like this:
https://stackoverflow.com/questions/66867737/iphone-safari-detect-swipe-navigation.
This is likely to happen more as authors can now use ViewTransitions to add
custom transitions in SPAs.

*Other signals*:

Activation

None

Security

None. The API is limited to same-document navigations.

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

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

?No. WPTs assert that the attribute is present but not the value. By
design, when this is set is left to the UA.

Flag name on chrome://flags

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones
Shipping on desktop 118
Shipping on Android 118
Shipping on WebView 118

Anticipated spec changes

None

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/UJMYZXoSQ4A/m/OkIvKVtlAAAJ

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/CAMLuWUyhcTn1%3D%3DxfV0i5tyLS-APwqfDpetBstDie_4uMyxB1xQ%40mail.gmail.com.

[blink-dev] Intent to Prototype: Document Render-Blocking

2023-08-09 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@google.com

Explainer
https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md

SpecificationNone

Summary

This feature enables authors to block rendering of a Document until the
critical content has been parsed, ensuring a consistent first paint across
all browsers. Without this feature, the first paint's state depends on the
heuristics for parser yielding which can vary across browsers. This is
particularly important for View Transitions where the parsed DOM state on
the first frame can drastically change the transition created.

Blink componentBlink>ViewTransitions>MPA

Motivation

The Web is designed with a model for incremental rendering. When a Document
is loading, the browser can render its intermediate states before fetching
all the requisite sub-resources, executing all script or fetching/parsing
the complete Document. While this is great to reduce the time for first
paint, there is a tradeoff between showing a jarring flash of intermediate
Document state (which could be unstyled or have more CLS) vs blocking
rendering on high priority sub-resources within a reasonable timeout. The
render-blocking concept helps browsers in making this tradeoff. It lets
authors specify the set of stylesheets and script elements which should
block rendering. For example, a stylesheet with the rules necessary to
ensure a stable layout. But authors can’t specify which nodes should be
added to the DOM before first render. This proposal aims to fill this gap.

Initial public proposalhttps://github.com/whatwg/html/issues/9332

TAG reviewNone

TAG review statusPending

Risks

Interoperability and Compatibility

None

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

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

None

Debuggability

None

Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified

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

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

[blink-dev] Re: Intent to Prototype: Disabling UA transitions on same-document navigations

2023-04-25 Thread 'Khushal Sagar' via blink-dev

FYI, I added a visual example to the problem statement
<https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md#problem-statement>
to
clarify the current status.

On Fri, Apr 21, 2023, 7:54 PM Khushal Sagar  wrote:

> Contact emailskhushalsa...@google.com, liuwill...@google.com
>
> Explainer
> https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md
>
> SpecificationNone
>
> Summary
>
> Smooth visual transitions as users navigate on the web can lower cognitive
> load by helping users stay in context. It can also provide a visual cue
> about the destination before initiating the navigation. Both site authors
> and user-agents (UAs) add visual transitions to their navigations for these
> use-cases. However, the user experience is bad if both the site author and
> the UA add these transitions: the transitions may conflict and cause
> confusion for the user. The goal of this proposal is to avoid such cases to
> ensure only one visual transition is executed at a time.
>
> Blink componentBlink>DefaultNavigationTransitions
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDefaultNavigationTransitions>
>
> Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/8747
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/835
>
> TAG review statusPending
>
> Risks
>
> Interoperability and Compatibility
>
> The main interop risk with this proposal is whether UA transitions should
> be allowed by default or not. Allowing them by default has a compat risk of
> breaking sites which ship with custom transitions already. We could try to
> assess the impact with heuristics like "detect whether the Document is
> constantly animating for x seconds after firing popstate/navigate event"
> but it's likely to have false positives. Also note that Safari/Chrome on
> iOS already ship with UA transitions by default.
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/784)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/177)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> If an author chooses to disable UA transitions for a subset of
> navigations, they will need to use the API proposed here
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/UJMYZXoSQ4A> to
> detect whether a UA transition was executed for a navigation.
>
> Security
>
> The API lets the site author selectively disable UA transitions based on
> whether the navigation was predictive (swipe) vs atomic (button click). The
> author can then detect whether a transition occurred using the API proposed
> in https://chromestatus.com/feature/5204831477694464. This effectively
> means site authors can detect whether the navigation was swipe or atomic;
> and in turn whether the device supports a category of navigations. However,
> this information can already be derived using the UA string.
>
> 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
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?No
>
> Since the feature depends on whether the UA performs a visual transition
> on navigations (as a part of browser UX), it's difficult to write an
> interoperable WPT for this. The exact gesture which causes a UA transition
> is a browser's internal detail.
>
> Flag name
> Requires code in //chrome?False
>
> Estimated milestones
>
> No milestones specified
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5206595333521408
>
> Links to previous Intent discussions
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.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/CAMLuWUyxF-YoX-WVvyYGe8epS6bQ-FBg9dBvkJU6w2yHD7EYsw%40mail.gmail.com.

[blink-dev] Intent to Prototype: Disabling UA transitions on same-document navigations

2023-04-21 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@google.com, liuwill...@google.com

Explainer
https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md

SpecificationNone

Summary

Smooth visual transitions as users navigate on the web can lower cognitive
load by helping users stay in context. It can also provide a visual cue
about the destination before initiating the navigation. Both site authors
and user-agents (UAs) add visual transitions to their navigations for these
use-cases. However, the user experience is bad if both the site author and
the UA add these transitions: the transitions may conflict and cause
confusion for the user. The goal of this proposal is to avoid such cases to
ensure only one visual transition is executed at a time.

Blink componentBlink>DefaultNavigationTransitions

Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/8747

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

TAG review statusPending

Risks

Interoperability and Compatibility

The main interop risk with this proposal is whether UA transitions should
be allowed by default or not. Allowing them by default has a compat risk of
breaking sites which ship with custom transitions already. We could try to
assess the impact with heuristics like "detect whether the Document is
constantly animating for x seconds after firing popstate/navigate event"
but it's likely to have false positives. Also note that Safari/Chrome on
iOS already ship with UA transitions by default.

*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/784)

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

*Web developers*: No signals

*Other signals*:

Ergonomics

If an author chooses to disable UA transitions for a subset of navigations,
they will need to use the API proposed here
to
detect whether a UA transition was executed for a navigation.

Security

The API lets the site author selectively disable UA transitions based on
whether the navigation was predictive (swipe) vs atomic (button click). The
author can then detect whether a transition occurred using the API proposed
in https://chromestatus.com/feature/5204831477694464. This effectively
means site authors can detect whether the navigation was swipe or atomic;
and in turn whether the device supports a category of navigations. However,
this information can already be derived using the UA string.

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
Is this feature fully tested by web-platform-tests

?No

Since the feature depends on whether the UA performs a visual transition on
navigations (as a part of browser UX), it's difficult to write an
interoperable WPT for this. The exact gesture which causes a UA transition
is a browser's internal detail.

Flag name
Requires code in //chrome?False

Estimated milestones

No milestones specified

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

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/CAMLuWUyd%2B5sjatyU2BiqPD6RZXTemvn2o23BkbSkkvZu%3DpYhCw%40mail.gmail.com.

[blink-dev] Intent to Prototype: Detect UA Transitions on same-document Navigations

2023-04-21 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@google.com, liuwill...@google.com,
hvanops...@google.com

Explainer
https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md

SpecificationNone

Summary

Blink componentBlink>DefaultNavigationTransitions

Motivation

Initial public proposalhttps://github.com/whatwg/html/issues/8782

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

TAG review statusPending

Risks

Interoperability and Compatibility

*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/783)

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

*Other signals*:

Activation

None

Security

None. The API is limited to same-document navigations.

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
Is this feature fully tested by web-platform-tests

?No

Flag name
Requires code in //chrome?False

Estimated milestones

No milestones specified

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

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/CAMLuWUywo8jmzXBYViNwKjOvQNwvweP%2BZRZLZ_XnOaczZ%2BjJyw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

2023-01-23 Thread Khushal Sagar

On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor  wrote:

> Hi Khushal,
>
> On 1/19/23 3:12 PM, Khushal Sagar wrote:
>
> Contact emails
> bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
> khushalsa...@chromium.org, vmp...@chromium.org
>
> Explainer
>
> https://github.com/WICG/view-transitions/blob/main/explainer.md
> <https://github.com/WICG/shared-element-transitions/blob/main/explainer.md>
>
> Specification
>
> https://www.w3.org/TR/css-view-transitions-1
>
> Summary
>
> View Transitions
> <https://developer.chrome.com/docs/web-platform/view-transitions/> is an
> API that enables the creation of polished transitions. Web developers only
> need minimal effort to make transitions look nice. They can choose to use
> some default animation properties, or they can customize their own
> transition effects to achieve a desired transition experience.
>
> This is accomplished by leveraging user-agents’ ability to persist visual
> representations of rendered output (i.e. snapshots) and blend them with the
> live DOM state’s rendered output. The API also allows these animations to
> be customized via standard CSS animation properties.
>
> Note that while this intent is limited to shipping an API for
> same-document transitions (i.e. by using document.startViewTransition, as
> outlined in the spec), there is ongoing work to provide this feature for
> same-origin, cross-document navigations (MPA). MPA support will be added as
> a follow up via a separate intent to ship.
>
> Blink component
>
> Blink>ViewTransitions
> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EViewTransitions=2>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/748
>
> Can you confirm that all the follow-up issues
> <https://github.com/w3ctag/design-reviews/issues/748#issuecomment-1379517669>
> filed in response to feedback in this review are backwards-compatible with
> what you propose to ship now?
>

Yes, most follow-up issues filed based on TAG feedback are about
transitions initiated from navigations. This is part of the MPA work which
we plan to ship as a follow up and it can be shipped independently of the
same-document transitions covered by this intent.

The only issue on that review which concerns same-document transitions is
#8319 <https://github.com/w3c/csswg-drafts/issues/8319>, a syntax which
would allow selecting a subset of generated pseudo-elements. This syntax
addition can be made in a backwards-compatible way.

>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> Low. As a new feature, the primary risk is that other browsers do not
> implement it. But since this is a progressive enhancement, sites should be
> able to feature-detect and drop usage of the feature easily in browsers
> where it is not supported without breaking any site functionality.
>
> This feature can be feature-detected by checking the existence of the
> document.startViewTransition function:
>
> ```js
>
> if (!document.startViewTransition) {
>
>   /* feature is not available */
>
> } else {
>
>   /* start transition */
>
> }
>
> ```
>
> Gecko: Under consideration (
> https://github.com/mozilla/standards-positions/issues/677)
>
> WebKit: No signal (https://github.com/WebKit/standards-positions/issues/48
> )
>
> Web developers: Strongly positive interest in and developer
> experimentation with the API:
>
>-
>
>Updated developer.chrome article (Twitter)
><https://twitter.com/jaffathecake/status/1554460598980812809>
>-
>
>News about the new SET API (Twitter)
><https://twitter.com/jaffathecake/status/1524782819431555074>
>-
>
>Dev-built demo using SET (Twitter)
><https://twitter.com/jh3yy/status/1550675304280035328>
>-
>
>I/O Session (Youtube <https://www.youtube.com/watch?v=JCJUPJ_zDQ4>)
>-
>
>Dev-built demo using SET (Reddit)
>
> <https://www.reddit.com/r/webdev/comments/uyoit1/i_played_around_with_chromes_new_shared_element/>
>
>-
>
>Dev-built demo using SET (Twitter)
>
> <https://twitter.com/OliverJAsh/status/1530261401016705026?t=CXqW2yiIMbH6bLfn8ImINw=19>
>-
>
>Dev-built demo using SET (Twitter)
><https://twitter.com/charca/status/1561830946462384128>
>-
>
>Dev-built demo using SET (Twitter)
><https://twitter.com/AdrianBeceDev/status/1567177956199485450>
>-
>
>Dev-built demo using SET (Twitter)
><https://twitter.com/charca/status/1570835238359830529>
>-
>
>https://twitter.com/danny

[blink-dev] Intent to Ship: View Transitions: single-page apps

2023-01-19 Thread Khushal Sagar

Contact emails
bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
khushalsa...@chromium.org, vmp...@chromium.org

Explainer

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


Specification

https://www.w3.org/TR/css-view-transitions-1

Summary

View Transitions
 is an
API that enables the creation of polished transitions. Web developers only
need minimal effort to make transitions look nice. They can choose to use
some default animation properties, or they can customize their own
transition effects to achieve a desired transition experience.

This is accomplished by leveraging user-agents’ ability to persist visual
representations of rendered output (i.e. snapshots) and blend them with the
live DOM state’s rendered output. The API also allows these animations to
be customized via standard CSS animation properties.


Note that while this intent is limited to shipping an API for same-document
transitions (i.e. by using document.startViewTransition, as outlined in the
spec), there is ongoing work to provide this feature for same-origin,
cross-document navigations (MPA). MPA support will be added as a follow up
via a separate intent to ship.

Blink component

Blink>ViewTransitions


TAG review

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

TAG review status

Pending

Risks
Interoperability and Compatibility

Low. As a new feature, the primary risk is that other browsers do not
implement it. But since this is a progressive enhancement, sites should be
able to feature-detect and drop usage of the feature easily in browsers
where it is not supported without breaking any site functionality.

This feature can be feature-detected by checking the existence of the
document.startViewTransition function:

```js

if (!document.startViewTransition) {

  /* feature is not available */

} else {

  /* start transition */

}

```

Gecko: Under consideration (
https://github.com/mozilla/standards-positions/issues/677)

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

Web developers: Strongly positive interest in and developer experimentation
with the API:

   -

   Updated developer.chrome article (Twitter)
   
   -

   News about the new SET API (Twitter)
   
   -

   Dev-built demo using SET (Twitter)
   
   -

   I/O Session (Youtube )
   -

   Dev-built demo using SET (Reddit)
   


   -

   Dev-built demo using SET (Twitter)
   

   -

   Dev-built demo using SET (Twitter)
   
   -

   Dev-built demo using SET (Twitter)
   
   -

   Dev-built demo using SET (Twitter)
   
   -

   https://twitter.com/dannymoerkerke/status/1597187172783693824
   -

   The Shared Element Transition API is Flipping Cool | Chris Coyier
   

   -

   Every Transition is a Page Transition? | OddBird
   
   -

   https://twitter.com/derSchepp/status/1590709783807791104
   -

   Astro stands to benefit highly from View Transitions | Chris Coyier
   


   -

   Shared Element Transitions API Part 1 | Smashing Magazine
   



Ergonomics

None.

Activation

   Low.

As with interop/compat risks, the difficulty stems from this being a new
feature without support in other browsers. A polyfill for the SPA case
would be beneficial. That said, this feature is a progressive enhancement
for sites; they can easily use the API and  still function correctly on
browsers that do not support the feature.

Security

The primary security constraint is ensuring isolation of graphics resources
from multiple origins. The design achieves that by using Chromium's Viz
process, similar to site isolation for iframes.

See also the security and privacy self-review questionnaire that was
completed as part of the TAG review process:
https://github.com/WICG/view-transitions/blob/main/security-privacy-questionnaire.md

The following issues track review from security/privacy WGs:

[blink-dev] Intent to Prototype: View Transition Same-Origin Navigation

2022-11-09 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@google.com, vmp...@google.com

Explainer
https://github.com/WICG/view-transitions/blob/main/explainer.md#cross-document-same-origin-transitions

Specification

Summary

The ViewTransition API allows authors to define visual transitions between
2 DOM states. The first phase of the feature is limited to transitions
within the same Document initiated via a script API. This feature is to
support this API for DOM changes initiated via cross-document same-origin
navigations.

Blink componentBlink>ViewTransitions

Motivation

This feature allows developers to add polished visual transitions to
same-origin cross-document navigations. While creating this UX is possible
for DOM changes within the same Document (Single-Page App), i'ts impossible
for cross-Document navigations (Multi-Page App).

Initial public proposal
https://github.com/WICG/view-transitions/blob/main/explainer.md#cross-document-same-origin-transitions

TAG review

TAG review statusPending

Risks

Interoperability and Compatibility

None. This feature is a progressive enhancement and authors can fallback to
the current UX if the feature is not available.

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Strongly 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

The feature can be debugged using standard tooling in devtools.
Specifically the animation panel can be used to pause and scrub through the
default animations set by the browser. The pseudo DOM structure generated
by the UA can also be inspected and targeted, like other DOM elements, in
the style panel.

Is this feature fully tested by web-platform-tests

?Yes

Flag nameview-transition-on-navigation

Requires code in //chrome?False

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

Estimated milestones

No milestones specified

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

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/CAMLuWUxMPaChgK0VH6cZNY_LE68zNQ-NTxA7DFzd-7PjyKi1Dw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-10-13 Thread Khushal Sagar

vtools/devtools-frontend/+/3923677>
>>> up to add a debug message which points here
>>> <https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md>
>>>  for
>>> guidance on how to fix the deprecation. Please let me know if any other
>>> information would be helpful.
>>>
>>>
>>>>
>>>>>
>>>>> On Monday, September 12, 2022 at 8:26:29 PM UTC-4 andr...@google.com
>>>>> wrote:
>>>>>
>>>>>> CC @Cheney Tsai, @Una Kravets, @Kadir Topal
>>>>>>
>>>>>> From a DevRel perspective, the three questions in my mind are:
>>>>>>
>>>>>>- Are affected developers aware of the change?
>>>>>>   - I understand they were notified via a console warning /
>>>>>>   deprecation warning. It'd be great to get a sense of how effective 
>>>>>> the
>>>>>>   communication was (ie: has usage significantly decreased since the
>>>>>>   warnings?).
>>>>>>
>>>>>>
>>>>>>- Have we given them enough time for developers to react to the
>>>>>>change?
>>>>>>   - This is less about how complex a change is and more about
>>>>>>   ensuring developers can fit the change into their planning cycle 
>>>>>> (eg:
>>>>>>   quarterly OKRs) and avoiding generating unplanned/urgent work, if 
>>>>>> possible.
>>>>>>   It does seem to me the timelines described are short.
>>>>>>
>>>>>>
>>>>>>- Are developers somehow blocked in implementing the change?
>>>>>>   - The change seems quite straightforward, but sometimes
>>>>>>   developers are blocked in surprising ways. Is there a channel 
>>>>>> developers
>>>>>>   can provide feedback on?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andre
>>>>>>
>>>>>> On Mon, 12 Sept 2022 at 01:54, Mike Taylor 
>>>>>> wrote:
>>>>>>
>>>>>>> LGTM2
>>>>>>>
>>>>>>> On 9/9/22 12:16 PM, Khushal Sagar wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks for meticulously gathering that data!!
>>>>>>>>
>>>>>>>> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
>>>>>>>> is noticeable breakage but not necessarily an insurmountable one.
>>>>>>>> The numbers are a bit higher than I'd like, but at the same time,
>>>>>>>> this enables new capabilities and we're not walking this path alone
>>>>>>>> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-1182596173>
>>>>>>>> .
>>>>>>>>
>>>>>>>> Given the above, *LGTM1* for a careful and monitored rollout,
>>>>>>>> accompanied with DevRel folks supporting y'all in communicating this 
>>>>>>>> change
>>>>>>>> to developers.
>>>>>>>> What are the timelines you have in mind? Is there some way to use
>>>>>>>> Deprecation Reporting to help us here?
>>>>>>>>
>>>>>>>
>>>>>>> I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100%
>>>>>>> with a week before each progression in M107. The release will go to 
>>>>>>> stable
>>>>>>> ~October 25th (schedule <https://chromiumdash.appspot.com/schedule>
>>>>>>> ).
>>>>>>>
>>>>>>> In terms of outreach a console warning
>>>>>>> <https://chromiumdash.appspot.com/commit/97b80f4e3b9b742a8c44fa5cb96b6c753b29f3d2>
>>>>>>> and a deprecation warning
>>>>>>> <https://chromiumdash.appspot.com/commit/0d0d8e0a1862e689690a702a5c5295531d9a3a27>
>>>>>>>  was
>>>>>>> added in M105 for cases where the element's computed style can cause 
>>>>>>

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-09-28 Thread Khushal Sagar

On Tue, Sep 27, 2022 at 12:40 PM Yoav Weiss  wrote:

> Thanks so much for reporting this, Nic! :) (pun not intended)
>
> A few generic questions:
>
>- Do you have outreach channels to your customers where those
>deprecations are being reported? Are they presented as e.g. warnings in
>their dashboards?
>- What information would you find useful in the reports that would
>make it easier to communicate the issue and potential solutions to your
>customers?
>
> And finally, a more specific question: can you share numbers regarding the
> rough number of customer origins that are hitting this? Even an order of
> magnitude would be helpful.
>
> Cheers,
> Yoav
>
> On Tue, Sep 27, 2022 at 5:55 PM Nic Jansma  wrote:
>
>> Hi everyone!
>>
>> I've started seeing this deprecation being reported via Reporting API
>> (through a ReportingObserver and Reporting API pings) on a few sites that
>> are being measured for RUM.
>>
>> The actual deprecation report was very hard to decode, as all that was
>> included was the ID (4201) and a confusing message (which looks like an
>> internal error message). e.g.:
>>
>> {
>>   "body": {
>> "anticipatedRemoval": null,
>> "columnNumber": 12345,
>> "id": "4201",
>> "lineNumber": 1,
>> "message": "Deprecation messages are stored in the devtools-frontend
>> repo at front_end/models/issues_manager/DeprecationIssue.ts",
>> "sourceFile": null
>>   },
>>   "type": "deprecation",
>>   "url": "https://example.com;
>> }
>>
>> It took some help from Yoav to understand 4201 is this specific issue (I
>> think).  With the details here, I can begin to understand (as a developer)
>> how to address the reports.
>>
>> I filed a Chromium bug to ask for more details in the deprecation report:
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1368607
>>
>
Apologies for missing the message here. I have a change
<https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3923677>
up to add a debug message which points here
<https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md>
for
guidance on how to fix the deprecation. Please let me know if any other
information would be helpful.


>
>>
>> On Monday, September 12, 2022 at 8:26:29 PM UTC-4 andr...@google.com
>> wrote:
>>
>>> CC @Cheney Tsai, @Una Kravets, @Kadir Topal
>>>
>>> From a DevRel perspective, the three questions in my mind are:
>>>
>>>- Are affected developers aware of the change?
>>>   - I understand they were notified via a console warning /
>>>   deprecation warning. It'd be great to get a sense of how effective the
>>>   communication was (ie: has usage significantly decreased since the
>>>   warnings?).
>>>
>>>
>>>- Have we given them enough time for developers to react to the
>>>change?
>>>   - This is less about how complex a change is and more about
>>>   ensuring developers can fit the change into their planning cycle (eg:
>>>   quarterly OKRs) and avoiding generating unplanned/urgent work, if 
>>> possible.
>>>   It does seem to me the timelines described are short.
>>>
>>>
>>>- Are developers somehow blocked in implementing the change?
>>>   - The change seems quite straightforward, but sometimes
>>>   developers are blocked in surprising ways. Is there a channel 
>>> developers
>>>   can provide feedback on?
>>>
>>>
>>>
>>> Andre
>>>
>>> On Mon, 12 Sept 2022 at 01:54, Mike Taylor  wrote:
>>>
>>>> LGTM2
>>>>
>>>> On 9/9/22 12:16 PM, Khushal Sagar wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>> Thanks for meticulously gathering that data!!
>>>>>
>>>>> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
>>>>> is noticeable breakage but not necessarily an insurmountable one.
>>>>> The numbers are a bit higher than I'd like, but at the same time, this
>>>>> enables new capabilities and we're not walking this path alone
>>>>> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-11825961

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-09-12 Thread Khushal Sagar

On Mon, Sep 12, 2022 at 4:59 AM Andre Bandarra  wrote:

> CC @Cheney Tsai , @Una Kravets
> , @Kadir Topal 
>
> From a DevRel perspective, the three questions in my mind are:
>
>- Are affected developers aware of the change?
>   - I understand they were notified via a console warning /
>   deprecation warning. It'd be great to get a sense of how effective the
>   communication was (ie: has usage significantly decreased since the
>   warnings?).
>
> M105 stable rollout started around August 30th so it's been less than a
couple of weeks. The UMA for tracking usage of overflow:visible on these
elements is here
<https://uma.googleplex.com/p/chrome/timeline_v2?sid=8c9729c3d3cbd34802a511a89abeb22e>
and
there hasn't been any change. Note that this is higher than the use counter
since it tracks whether the element had a style that could cause overflow,
not whether it actually painted with overflow.

>
>- Have we given them enough time for developers to react to the change?
>   - This is less about how complex a change is and more about
>   ensuring developers can fit the change into their planning cycle (eg:
>   quarterly OKRs) and avoiding generating unplanned/urgent work, if 
> possible.
>   It does seem to me the timelines described are short.
>
> Do you have a suggestion for an appropriate time to wait after the email
notification to sites we discovered via CT? Given the use counter for
significant breakage is low (~0.006%), I was hoping 6 weeks targeting M107
would suffice. But we can push it out until M108 which gives it 10 weeks if
needed.

>
>- Are developers somehow blocked in implementing the change?
>   - The change seems quite straightforward, but sometimes developers
>   are blocked in surprising ways. Is there a channel developers can 
> provide
>   feedback on?
>
> The email notification directs developers to the chromium issue tracker.
That'll help in documenting a fix for any unforeseen issues and redirecting
developers in case we receive duplicate bugs.

>
>-
>
> Andre
>
> On Mon, 12 Sept 2022 at 01:54, Mike Taylor  wrote:
>
>> LGTM2
>>
>> On 9/9/22 12:16 PM, Khushal Sagar wrote:
>>
>>
>>
>> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss 
>> wrote:
>>
>>> Thanks for meticulously gathering that data!!
>>>
>>> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
>>> is noticeable breakage but not necessarily an insurmountable one.
>>> The numbers are a bit higher than I'd like, but at the same time, this
>>> enables new capabilities and we're not walking this path alone
>>> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-1182596173>
>>> .
>>>
>>> Given the above, *LGTM1* for a careful and monitored rollout,
>>> accompanied with DevRel folks supporting y'all in communicating this change
>>> to developers.
>>> What are the timelines you have in mind? Is there some way to use
>>> Deprecation Reporting to help us here?
>>>
>>
>> I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100% with a
>> week before each progression in M107. The release will go to stable
>> ~October 25th (schedule <https://chromiumdash.appspot.com/schedule>).
>>
>> In terms of outreach a console warning
>> <https://chromiumdash.appspot.com/commit/97b80f4e3b9b742a8c44fa5cb96b6c753b29f3d2>
>> and a deprecation warning
>> <https://chromiumdash.appspot.com/commit/0d0d8e0a1862e689690a702a5c5295531d9a3a27>
>>  was
>> added in M105 for cases where the element's computed style can cause this
>> behaviour change. I've also reached out to the dev rel folks for a targeted
>> email to affected sites that came up through our CT analysis.
>>
>>
>>>
>>> On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar 
>>> wrote:
>>>
>>>> We have UseCounter data from M105 stable to quantify the large breakage
>>>> for this feature. Large is a page load where any image, video or canvas
>>>> drawn on the page paints over 5k CSS pixels outside its content-box. The
>>>> precise numbers (with page load count) are here
>>>> <https://docs.google.com/document/d/1GC2wanCPtoboSujQVr5xoCDlpzzhspr0PHA-OBgGbEY/edit>
>>>>  (sorry
>>>> can't share the details externally).
>>>>
>>>> In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
>>>> large breakage category and Android had ~0.007%.
>>>>
>>>> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar 
>>&

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-09-09 Thread Khushal Sagar

On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss  wrote:

> Thanks for meticulously gathering that data!!
>
> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
> is noticeable breakage but not necessarily an insurmountable one.
> The numbers are a bit higher than I'd like, but at the same time, this
> enables new capabilities and we're not walking this path alone
> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-1182596173>
> .
>
> Given the above, *LGTM1* for a careful and monitored rollout, accompanied
> with DevRel folks supporting y'all in communicating this change to
> developers.
> What are the timelines you have in mind? Is there some way to use
> Deprecation Reporting to help us here?
>

I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100% with a
week before each progression in M107. The release will go to stable
~October 25th (schedule <https://chromiumdash.appspot.com/schedule>).

In terms of outreach a console warning
<https://chromiumdash.appspot.com/commit/97b80f4e3b9b742a8c44fa5cb96b6c753b29f3d2>
and a deprecation warning
<https://chromiumdash.appspot.com/commit/0d0d8e0a1862e689690a702a5c5295531d9a3a27>
was
added in M105 for cases where the element's computed style can cause this
behaviour change. I've also reached out to the dev rel folks for a targeted
email to affected sites that came up through our CT analysis.


>
> On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar 
> wrote:
>
>> We have UseCounter data from M105 stable to quantify the large breakage
>> for this feature. Large is a page load where any image, video or canvas
>> drawn on the page paints over 5k CSS pixels outside its content-box. The
>> precise numbers (with page load count) are here
>> <https://docs.google.com/document/d/1GC2wanCPtoboSujQVr5xoCDlpzzhspr0PHA-OBgGbEY/edit>
>>  (sorry
>> can't share the details externally).
>>
>> In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
>> large breakage category and Android had ~0.007%.
>>
>> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar <
>>>> khushalsa...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> Thanks Khushal! :)
>>>>>>
>>>>>> The breakage seems potentially significant (at worst, makes the site
>>>>>> visually broken and unusable), and the percentage of breakage seems above
>>>>>> the threshold we typically consider safe.
>>>>>> At the same time this seems like a positive change, and our friends
>>>>>> at Mozilla consider it "worth prototyping".
>>>>>>
>>>>>> Would it be possible to consider this as a deprecation of the old
>>>>>> behavior, and run the console issue (+deprecation warnings and outreach 
>>>>>> to
>>>>>> affected sites) for a few milestones, to try and drive the usage down
>>>>>> before flipping this change to be on by default? Maybe also get some
>>>>>> documentation out there and work with devrel folks to make sure folks are
>>>>>> aware of this coming change?
>>>>>>
>>>>>> Does that sound reasonable?
>>>>>>
>>>>>
>>>>> Thanks for the suggestion Yoav. This sounds reasonable. I've reached
>>>>> out to the devrel folks to do more outreach about this change. I'll update
>>>>> this thread with the plan for it. The console issue and deprecation
>>>>> warnings have been added in M105.
>>>>>
>>>>> I looked into adding a use counter for sites which have real breakage,
>>>>> since the current metric tracks whether the computed style *could* permit
>>>>> allow but not whether there is actual overflow at paint time. And
>>>>> unfortunately computing potential overflow is not easy to add. The CT
>>>>> analysis I ran earlier did this by turning the feature on and tracking
>>>>> actual overflow generated by the element. So a couple of questions for
>>>>> moving forward:
>>>>>
>>>>> - Would it be okay to turn the feature on in beta and 1% stable (in
>>>>> M105) to colle

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-09-09 Thread Khushal Sagar

We have UseCounter data from M105 stable to quantify the large breakage for
this feature. Large is a page load where any image, video or canvas drawn
on the page paints over 5k CSS pixels outside its content-box. The precise
numbers (with page load count) are here
<https://docs.google.com/document/d/1GC2wanCPtoboSujQVr5xoCDlpzzhspr0PHA-OBgGbEY/edit>
(sorry
can't share the details externally).

In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
large breakage category and Android had ~0.007%.

On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar 
wrote:

>
>
> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss  wrote:
>
>>
>>
>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss 
>>> wrote:
>>>
>>>> Thanks Khushal! :)
>>>>
>>>> The breakage seems potentially significant (at worst, makes the site
>>>> visually broken and unusable), and the percentage of breakage seems above
>>>> the threshold we typically consider safe.
>>>> At the same time this seems like a positive change, and our friends at
>>>> Mozilla consider it "worth prototyping".
>>>>
>>>> Would it be possible to consider this as a deprecation of the old
>>>> behavior, and run the console issue (+deprecation warnings and outreach to
>>>> affected sites) for a few milestones, to try and drive the usage down
>>>> before flipping this change to be on by default? Maybe also get some
>>>> documentation out there and work with devrel folks to make sure folks are
>>>> aware of this coming change?
>>>>
>>>> Does that sound reasonable?
>>>>
>>>
>>> Thanks for the suggestion Yoav. This sounds reasonable. I've reached out
>>> to the devrel folks to do more outreach about this change. I'll update this
>>> thread with the plan for it. The console issue and deprecation warnings
>>> have been added in M105.
>>>
>>> I looked into adding a use counter for sites which have real breakage,
>>> since the current metric tracks whether the computed style *could* permit
>>> allow but not whether there is actual overflow at paint time. And
>>> unfortunately computing potential overflow is not easy to add. The CT
>>> analysis I ran earlier did this by turning the feature on and tracking
>>> actual overflow generated by the element. So a couple of questions for
>>> moving forward:
>>>
>>> - Would it be okay to turn the feature on in beta and 1% stable (in
>>> M105) to collect metrics for the sites with real breakage and the extent of
>>> this breakage (how many pixels of overflow do we see). This should be lower
>>> than the counter of 0.017%.
>>>
>>
>> That sounds like a great way to gather data! (assuming the relevant
>> Chrome processes are followed)
>> Would be good to gather a histogram of overflowed pixels, to get a sense
>> of "small breakage" vs. "large breakage".
>>
>>
>>>
>>> - What's the number (in terms of page loads affected) we should be
>>> targeting before this would be safe?
>>>
>>
>> From my perspective, I'd be comfortable shipping this if we're seeing
>> less than 0.003% of page loads in the "large breakage" bucket (say more
>> than ~5000 overflowing pixels, assuming that number makes sense).
>>
>> +Andre Bandarra  - for devrel opinions on this.
>>
>
> Currently we're recording a UseCounter when any breakage would happen,
> i.e, there is any pixel overflow. If it helps to have a UseCounter for
> overflow above a threshold, I'm happy to add that too.
>
> We do have an UMA metric which measures the number of overflowing pixels
> when there is overflow but it's for all images rendered. I can tie it to
> the UseCounter so we can also know the number of affected page loads with
> large breakage. I'll wait till the end of the week for more feedback,
> otherwise assume 5k is a good threshold for large breakage.
>
>
>>
>>
>>>
>>>
>>>>
>>>> Cheers,
>>>> Yoav
>>>>
>>>> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:
>>>>
>>>>> Hey folks,
>>>>>
>>>>> I'm summarizing the steps to mitigate the compat risk with this
>>>>> feature based on the feedback:
>>>>>
>>>>>- Add a warning to the console when a developer style would permit
&g

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-08-02 Thread Khushal Sagar

On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss  wrote:

>
>
> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar 
> wrote:
>
>>
>>
>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss 
>> wrote:
>>
>>> Thanks Khushal! :)
>>>
>>> The breakage seems potentially significant (at worst, makes the site
>>> visually broken and unusable), and the percentage of breakage seems above
>>> the threshold we typically consider safe.
>>> At the same time this seems like a positive change, and our friends at
>>> Mozilla consider it "worth prototyping".
>>>
>>> Would it be possible to consider this as a deprecation of the old
>>> behavior, and run the console issue (+deprecation warnings and outreach to
>>> affected sites) for a few milestones, to try and drive the usage down
>>> before flipping this change to be on by default? Maybe also get some
>>> documentation out there and work with devrel folks to make sure folks are
>>> aware of this coming change?
>>>
>>> Does that sound reasonable?
>>>
>>
>> Thanks for the suggestion Yoav. This sounds reasonable. I've reached out
>> to the devrel folks to do more outreach about this change. I'll update this
>> thread with the plan for it. The console issue and deprecation warnings
>> have been added in M105.
>>
>> I looked into adding a use counter for sites which have real breakage,
>> since the current metric tracks whether the computed style *could* permit
>> allow but not whether there is actual overflow at paint time. And
>> unfortunately computing potential overflow is not easy to add. The CT
>> analysis I ran earlier did this by turning the feature on and tracking
>> actual overflow generated by the element. So a couple of questions for
>> moving forward:
>>
>> - Would it be okay to turn the feature on in beta and 1% stable (in M105)
>> to collect metrics for the sites with real breakage and the extent of this
>> breakage (how many pixels of overflow do we see). This should be lower than
>> the counter of 0.017%.
>>
>
> That sounds like a great way to gather data! (assuming the relevant Chrome
> processes are followed)
> Would be good to gather a histogram of overflowed pixels, to get a sense
> of "small breakage" vs. "large breakage".
>
>
>>
>> - What's the number (in terms of page loads affected) we should be
>> targeting before this would be safe?
>>
>
> From my perspective, I'd be comfortable shipping this if we're seeing less
> than 0.003% of page loads in the "large breakage" bucket (say more than
> ~5000 overflowing pixels, assuming that number makes sense).
>
> +Andre Bandarra  - for devrel opinions on this.
>

Currently we're recording a UseCounter when any breakage would happen, i.e,
there is any pixel overflow. If it helps to have a UseCounter for overflow
above a threshold, I'm happy to add that too.

We do have an UMA metric which measures the number of overflowing pixels
when there is overflow but it's for all images rendered. I can tie it to
the UseCounter so we can also know the number of affected page loads with
large breakage. I'll wait till the end of the week for more feedback,
otherwise assume 5k is a good threshold for large breakage.


>
>
>>
>>
>>>
>>> Cheers,
>>> Yoav
>>>
>>> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:
>>>
>>>> Hey folks,
>>>>
>>>> I'm summarizing the steps to mitigate the compat risk with this feature
>>>> based on the feedback:
>>>>
>>>>- Add a warning to the console when a developer style would permit
>>>>replaced elements to overflow. The patch to add that is here
>>>><https://chromium-review.googlesource.com/c/chromium/src/+/3763640> and
>>>>documentation to help developers debug, which is referenced in the 
>>>> console
>>>>warning, is here
>>>><https://github.com/WICG/shared-element-transitions/pull/166/files>.
>>>>We can pre-emptively add this warning to M105 and ship the feature in 
>>>> M106
>>>>to have a one release window before the behaviour changes.
>>>>
>>>>- Send an email to the webmaster of sites surfaced in the CT
>>>>analysis which already have the styles that trigger the warning above.
>>>>
>>>> In addition to the above, the feature can be turned off with a
>>>> server-side config using finch if there is any severe breakage.

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-07-14 Thread Khushal Sagar

Hey folks,

I'm summarizing the steps to mitigate the compat risk with this feature
based on the feedback:

   - Add a warning to the console when a developer style would permit
   replaced elements to overflow. The patch to add that is here
   <https://chromium-review.googlesource.com/c/chromium/src/+/3763640> and
   documentation to help developers debug, which is referenced in the console
   warning, is here
   <https://github.com/WICG/shared-element-transitions/pull/166/files>. We
   can pre-emptively add this warning to M105 and ship the feature in M106 to
   have a one release window before the behaviour changes.

   - Send an email to the webmaster of sites surfaced in the CT analysis
   which already have the styles that trigger the warning above.

In addition to the above, the feature can be turned off with a server-side
config using finch if there is any severe breakage.

Please let me know if the above suffices.

Thanks.
Khushal

On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar 
wrote:

>
>
> On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor 
> wrote:
>
>> On 7/13/22 3:04 PM, Khushal Sagar wrote:
>>
>>
>>
>> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:
>>>
>>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <
>>>>> khushalsa...@chromium.org> wrote:
>>>>>
>>>>>> Contact emails khushalsa...@chromium.org, vmp...@chromium.org
>>>>>>
>>>>>> Explainer
>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>>>>>> https://github.com/w3c/csswg-drafts/issues/7058
>>>>>>
>>>>>> Specification
>>>>>> https://drafts.csswg.org/css-overflow/#overflow-properties
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> This change allows developers to use the existing `overflow` property
>>>>>> with replaced elements that paint outside the content-box. Paired with
>>>>>> `object-view-box` this can be used to create an image with a custom glow 
>>>>>> or
>>>>>> shadow applied, with proper ink-overflow behavior like a CSS shadow would
>>>>>> have.
>>>>>>
>>>>>> Blink component Blink>CSS
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>
>>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/750
>>>>>>
>>>>>> TAG review status Pending
>>>>>>
>>>>>> Risks
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> This feature changes the behaviour of the existing overflow property
>>>>>> on replaced elements (img, video, canvas). Currently `overflow:visible` 
>>>>>> in
>>>>>> a developer stylesheet on such elements is ignored during paint and the
>>>>>> content is clipped to the element's content-box. With this feature,
>>>>>> `overflow:visible` will result in content outside the element's 
>>>>>> content-box
>>>>>> to paint as ink overflow. We've collected use counter data to measure the
>>>>>> number of sites which could be affected by this. The use counter data
>>>>>> collected over 1 week of a stable release (M102) is as follows. We
>>>>>> collected 2 different counters explained below. * The first measures any
>>>>>> instance where overflow is explicitly set from developer styles to 
>>>>>> visible.
>>>>>> The percentage of page loads with this is 2.16%. * The second measures 
>>>>>> the
>>>>>> above instances but only includes the cases with object-fit set to cover 
>>>>>> or
>>>>>> none or object-position set to any value other than the default (50% 
>>>>>> 50%).
>>>>>> The rationale behind this counter is to exclude cases which can not cause
>>>>>> overflow (such as object-fit:contain), even if overflow is set to 
>>>>>> visible.
>>>>>> The percentage of page loads with this is 0.017%.
>>>>>>
>>>>>
>>

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-07-13 Thread Khushal Sagar

On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor  wrote:

> On 7/13/22 3:04 PM, Khushal Sagar wrote:
>
>
>
> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss  wrote:
>
>>
>>
>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:
>>
>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar 
>>>> wrote:
>>>>
>>>>> Contact emails khushalsa...@chromium.org, vmp...@chromium.org
>>>>>
>>>>> Explainer
>>>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>>>>> https://github.com/w3c/csswg-drafts/issues/7058
>>>>>
>>>>> Specification
>>>>> https://drafts.csswg.org/css-overflow/#overflow-properties
>>>>>
>>>>> Summary
>>>>>
>>>>> This change allows developers to use the existing `overflow` property
>>>>> with replaced elements that paint outside the content-box. Paired with
>>>>> `object-view-box` this can be used to create an image with a custom glow 
>>>>> or
>>>>> shadow applied, with proper ink-overflow behavior like a CSS shadow would
>>>>> have.
>>>>>
>>>>> Blink component Blink>CSS
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>
>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/750
>>>>>
>>>>> TAG review status Pending
>>>>>
>>>>> Risks
>>>>> Interoperability and Compatibility
>>>>>
>>>>> This feature changes the behaviour of the existing overflow property
>>>>> on replaced elements (img, video, canvas). Currently `overflow:visible` in
>>>>> a developer stylesheet on such elements is ignored during paint and the
>>>>> content is clipped to the element's content-box. With this feature,
>>>>> `overflow:visible` will result in content outside the element's 
>>>>> content-box
>>>>> to paint as ink overflow. We've collected use counter data to measure the
>>>>> number of sites which could be affected by this. The use counter data
>>>>> collected over 1 week of a stable release (M102) is as follows. We
>>>>> collected 2 different counters explained below. * The first measures any
>>>>> instance where overflow is explicitly set from developer styles to 
>>>>> visible.
>>>>> The percentage of page loads with this is 2.16%. * The second measures the
>>>>> above instances but only includes the cases with object-fit set to cover 
>>>>> or
>>>>> none or object-position set to any value other than the default (50% 50%).
>>>>> The rationale behind this counter is to exclude cases which can not cause
>>>>> overflow (such as object-fit:contain), even if overflow is set to visible.
>>>>> The percentage of page loads with this is 0.017%.
>>>>>
>>>>
>>>> That's not nothing. Any idea what breakage may look like?
>>>> Can we maybe collect histograms on *how much* overflow would occur in
>>>> those cases? (maybe with ClusterTelemetry initially, to get a rough idea in
>>>> the lab)
>>>>
>>>
>>> I ran an analysis on CT using top 100k sites for desktop and top 10k
>>> sites on mobile. The raw numbers are here: desktop
>>> <https://docs.google.com/spreadsheets/d/1kKWq8kqZOfCXqiHaiamYNDdTs5x1_YJfDTnAgXOIwaE/edit#gid=0>
>>> and mobile
>>> <https://docs.google.com/spreadsheets/d/1SrNyrEe4yzCOIxqNOlNgCk8O58NqqoBlBTd4Wn_gKCc/edit#gid=0>,
>>> and the rough patch
>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3749485> to
>>> collect this data. The highlights from the analysis are below:
>>>
>>>- The number of sites which override the default CSS to allow
>>>overflow *and* also had overflow during painting was 13 out of 10k on
>>>mobile and 39 out of 63k on desktop (only 63k sites yielded results out 
>>> of
>>>100k).
>>>
>>>- I measured the percentage of area painted outside the content box
>>>out of the total painted area. The highest was 88% on desktop and 70% on
>>>mobile.
>>>
>>>
>> I'm not sure w

[blink-dev] Re: Intent to Prototype: CSS Overflow for replaced elements

2022-07-12 Thread Khushal Sagar

Your conclusion above is correct.

Apologies for not replying earlier. I assumed we were already on the same
page. :)

On Tue, Jul 12, 2022 at 4:41 AM Arthur Hemery  wrote:

> Hey Khushal,
> Just a friendly ping on that since I see you've sent the I2S already.
> Cheers,
> Arthur
>
> On Mon, Jul 4, 2022 at 2:56 PM Arthur Hemery  wrote:
>
>> Thanks for the reply!
>> Let me rephrase to see if my understanding is correct:
>> "To handle elements generated by shared element transition (images -
>> replaced elements), CSS overflow needs to be extended to replaced elements
>> that are usually not supported. Since iframes, embed, etc. are also
>> replaced elements, they need to be explicitly excluded from the extension.
>> This has been spec'd already".
>>
>> If that's the case then it's all good, sorry for the trouble :)
>> Cheers,
>> Arthur
>>
>> On Wed, Jun 29, 2022 at 5:33 PM Khushal Sagar 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 29, 2022 at 11:24 AM Arthur Hemery 
>>> wrote:
>>>
>>>>
>>>> Hi!
>>>> I've run through this as a security reviewer, and my understanding is
>>>> that previous discussions led to this issue
>>>> <https://github.com/w3c/csswg-drafts/issues/7143> being filed, to
>>>> restrict iframe overflow.
>>>> I see this is in the CSS working group so is this restriction planned
>>>> for all embedded content in general and not only shared elements? Also has
>>>> this been spec'd yet or was there any progress?
>>>>
>>>
>>> The restriction is planned for all embedded content. This change
>>> <https://github.com/tabatkins/html/commit/16943c6e9231a4f5fab89c65ae7ddbe49f40f01b#:~:text=iframe%2C%20object%2C%20embed,%7D%3C/code%3E%3C/pre%3E>
>>>  includes
>>> the UA CSS to enforce the restriction and has the specific elements that it
>>> will be applied to (iframe, object, embed). There is no such restriction on
>>> shared elements in the context of Shared Element Transitions
>>> <https://github.com/WICG/shared-element-transitions/blob/main/explainer.md> 
>>> or
>>> the new pseudo elements introduced for that feature.
>>>
>>> This has been spec'd. The specific edits are in these 2 changes: define
>>> overflow on replaced elements
>>> <https://github.com/w3c/csswg-drafts/commit/a679cd100dcf479af23b33b033bbe4c959d78258>
>>>  and
>>> new UA CSS
>>> <https://github.com/tabatkins/html/commit/16943c6e9231a4f5fab89c65ae7ddbe49f40f01b>
>>> .
>>>
>>>
>>>> The rest looked fine, thanks!
>>>> Arthur
>>>> On Friday, June 24, 2022 at 10:45:44 PM UTC+2 khusha...@chromium.org
>>>> wrote:
>>>>
>>>>> Contact emailskhusha...@chromium.org, vmp...@chromium.org
>>>>>
>>>>> Explainer
>>>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>>>>> https://github.com/w3c/csswg-drafts/issues/7058
>>>>>
>>>>> Specification
>>>>> https://drafts.csswg.org/css-overflow/#overflow-properties
>>>>>
>>>>> Summary
>>>>>
>>>>> This change allows developers to use the existing `overflow` property
>>>>> with replaced elements that paint outside the content-box. Paired with
>>>>> `object-view-box` this can be used to create an image with a custom glow 
>>>>> or
>>>>> shadow applied, with proper ink-overflow behavior like a CSS shadow would
>>>>> have.
>>>>>
>>>>>
>>>>> Blink componentBlink>CSS
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>
>>>>> Motivation
>>>>>
>>>>> This change allows developers to use the existing `overflow` property
>>>>> with replaced elements that paint outside the content-box. Paired with
>>>>> `object-view-box` this can be used to create an image with a custom glow 
>>>>> or
>>>>> shadow applied, with proper ink-overflow behavior like a CSS shadow would
>>>>> have. Note that the svg spec already respects this property and shared
>>>>> element transitions introduces a replaced element which also needs this
>>>>> functionality. One of the motivations of this feature is to apply this
>>>>> property and re

[blink-dev] Intent to Ship: CSS Overflow for replaced elements

2022-07-08 Thread Khushal Sagar

Contact emailskhushalsa...@chromium.org, vmp...@chromium.org

Explainer
https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058

Specificationhttps://drafts.csswg.org/css-overflow/#overflow-properties

Summary

Blink componentBlink>CSS

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

TAG review statusPending

Risks
Interoperability and Compatibility

This feature changes the behaviour of the existing overflow property on
replaced elements (img, video, canvas). Currently `overflow:visible` in a
developer stylesheet on such elements is ignored during paint and the
content is clipped to the element's content-box. With this feature,
`overflow:visible` will result in content outside the element's content-box
to paint as ink overflow. We've collected use counter data to measure the
number of sites which could be affected by this. The use counter data
collected over 1 week of a stable release (M102) is as follows. We
collected 2 different counters explained below. * The first measures any
instance where overflow is explicitly set from developer styles to visible.
The percentage of page loads with this is 2.16%. * The second measures the
above instances but only includes the cases with object-fit set to cover or
none or object-position set to any value other than the default (50% 50%).
The rationale behind this counter is to exclude cases which can not cause
overflow (such as object-fit:contain), even if overflow is set to visible.
The percentage of page loads with this is 0.017%.

*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/659)

*WebKit*: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html)

*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

This is a CSS property which can be debugged in the devtools style panel
similar to other CSS properties.

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 nameCSSOverflowForReplacedElements

*Note: Because of the compat risk with this feature, this flag can be
controlled via Finch. This will allow us to rollback with a server-side
config change if needed.*

Requires code in //chrome?False

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

Estimated milestones

M105

Anticipated spec changes

N/A

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUykJWEAqVzcUy15fpBNdA68508Mny_1z--FCBKXRTZOFQ%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/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com.

[blink-dev] Re: Intent to Prototype: CSS Overflow for replaced elements

2022-06-29 Thread Khushal Sagar

On Wed, Jun 29, 2022 at 11:24 AM Arthur Hemery  wrote:

>
> Hi!
> I've run through this as a security reviewer, and my understanding is that
> previous discussions led to this issue
>  being filed, to
> restrict iframe overflow.
> I see this is in the CSS working group so is this restriction planned for
> all embedded content in general and not only shared elements? Also has this
> been spec'd yet or was there any progress?
>

The restriction is planned for all embedded content. This change

includes
the UA CSS to enforce the restriction and has the specific elements that it
will be applied to (iframe, object, embed). There is no such restriction on
shared elements in the context of Shared Element Transitions
 or
the new pseudo elements introduced for that feature.

This has been spec'd. The specific edits are in these 2 changes: define
overflow on replaced elements

and
new UA CSS

.


> The rest looked fine, thanks!
> Arthur
> On Friday, June 24, 2022 at 10:45:44 PM UTC+2 khusha...@chromium.org
> wrote:
>
>> Contact emailskhusha...@chromium.org, vmp...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>> https://github.com/w3c/csswg-drafts/issues/7058
>>
>> Specificationhttps://drafts.csswg.org/css-overflow/#overflow-properties
>>
>> Summary
>>
>> This change allows developers to use the existing `overflow` property
>> with replaced elements that paint outside the content-box. Paired with
>> `object-view-box` this can be used to create an image with a custom glow or
>> shadow applied, with proper ink-overflow behavior like a CSS shadow would
>> have.
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> Motivation
>>
>> This change allows developers to use the existing `overflow` property
>> with replaced elements that paint outside the content-box. Paired with
>> `object-view-box` this can be used to create an image with a custom glow or
>> shadow applied, with proper ink-overflow behavior like a CSS shadow would
>> have. Note that the svg spec already respects this property and shared
>> element transitions introduces a replaced element which also needs this
>> functionality. One of the motivations of this feature is to apply this
>> property and related properties (like `overflow-clip-margin`) consistently
>> to all replaced elements.
>>
>> Note: This is a follow up to this previous intent
>> 
>>  to
>> support the same functionality. The proposal has been updated based on
>> feedback.
>>
>> Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/7144
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/750
>>
>> TAG review statusPending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This feature changes the behaviour of the existing overflow property on
>> replaced elements (img, video, canvas). Currently `overflow:visible` in a
>> developer stylesheet on such elements is ignored during paint and the
>> content is clipped to the element's content-box. With this feature,
>> `overflow:visible` will result in content outside the element's content-box
>> to paint as ink overflow. We've collected use counter data to measure the
>> number of sites which could be affected by this. The use counter data
>> collected over 1 week of a stable release (M102) is as follows. We
>> collected 2 different counters explained below. * The first measures any
>> instance where overflow is explicitly set from developer styles to visible.
>> The percentage of page loads with this is 2.16%. * The second measures the
>> above instances but only includes the cases with object-fit set to cover or
>> none or object-position set to any value other than the default (50% 50%).
>> The rationale behind this counter is to exclude cases which can not cause
>> overflow (such as object-fit:contain), even if overflow is set to visible.
>> The percentage of page loads with this is 0.017%.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/659)
>>
>> *WebKit*: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html)
>>
>> *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
>>
>> This is a

[blink-dev] Intent to Prototype: CSS Overflow for replaced elements

2022-06-24 Thread Khushal Sagar

Contact emailskhushalsa...@chromium.org, vmp...@chromium.org

Explainer
https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058

Specificationhttps://drafts.csswg.org/css-overflow/#overflow-properties

Summary

Blink componentBlink>CSS

Motivation

This change allows developers to use the existing `overflow` property with
replaced elements that paint outside the content-box. Paired with
`object-view-box` this can be used to create an image with a custom glow or
shadow applied, with proper ink-overflow behavior like a CSS shadow would
have. Note that the svg spec already respects this property and shared
element transitions introduces a replaced element which also needs this
functionality. One of the motivations of this feature is to apply this
property and related properties (like `overflow-clip-margin`) consistently
to all replaced elements.

Note: This is a follow up to this previous intent

to
support the same functionality. The proposal has been updated based on
feedback.

Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/7144

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

TAG review statusPending

Risks

Interoperability and Compatibility

*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/659)

*WebKit*: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html)

*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

This is a CSS property which can be debugged in the devtools style panel
similar to other CSS properties.

Is this feature fully tested by web-platform-tests

?Yes

Flag nameCSSOverflowForReplacedElements

Requires code in //chrome?False

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

Estimated milestones

No milestones specified

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

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

Re: [blink-dev] Re: Intent to Experiment: Shared Element Transitions

2022-06-21 Thread Khushal Sagar

Quick update, the feature is supported on WebView starting in M105.
Depending on the progress of OT support for WebView (here
<https://groups.google.com/a/chromium.org/g/blink-dev/c/ecfyEhQUbtc/m/qbMJOl0VEgAJ?utm_medium=email_source=footer=1>),
the feature will be available for OT on WebView for 105-106 (inclusive).

On Tue, Jun 14, 2022 at 10:29 AM Khushal Sagar 
wrote:

>
>
> On Mon, Jun 13, 2022, 1:26 PM Joe Medley  wrote:
>
>> Is the experiment 103 to 106 or 104 to 107.
>>
>
> It's 104-106 (inclusive). The last date is October 18, 2022.
>
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Jun 13, 2022 at 8:49 AM 'Hannah Van Opstal' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Hi Nicola,
>>>
>>> This experimentation is still for the same-origin case.
>>> The difference is in the shape of the API. The first intent was approved
>>> for the API when it was using Viz. With Viz Shared Element Transitions, we
>>> did an origin trial where we received some feedback that led us to change
>>> it to use the renderer. So this new intent would be intended for the newer
>>> shape - i.e. renderer SET.
>>>
>>> Please let me know if we can provide any more details.
>>>
>>> Hannah
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 13, 2022 at 7:16 AM Nicola Tommasi 
>>> wrote:
>>>
>>>> Hi API owners,
>>>>
>>>> This intent seems to be already approved in the past for same-origin
>>>> experimentation, is this launch intended for the cross-origin case?If not,
>>>> what's exactly in the scope for this particular launch?
>>>>
>>>> Thanks,
>>>> Nicola
>>>>
>>>> On Thursday, June 9, 2022 at 8:35:23 AM UTC Yoav Weiss wrote:
>>>>
>>>>> LGTM to experiment M103-M106
>>>>>
>>>>> Thanks for working on this! I'm super excited about the possibilities
>>>>> this will open!!
>>>>>
>>>>> On Wed, Jun 8, 2022 at 9:27 PM Khushal Sagar <
>>>>> khushalsa...@chromium.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 8, 2022 at 3:11 PM Khushal Sagar <
>>>>>> khushalsa...@chromium.org> wrote:
>>>>>>
>>>>>>> Contact emailskhushalsa...@chromium.org, vmp...@chromium.org,
>>>>>>> hvanops...@chromium.org
>>>>>>>
>>>>>>> Explainer
>>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>>>>>
>>>>>>> Specification
>>>>>>> https://tabatkins.github.io/specs/css-shared-element-transitions
>>>>>>>
>>>>>>> Design docs
>>>>>>>
>>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> Shared Element Transitions is a proposal for a new script API that
>>>>>>> allows a simple set of transitions in both Single-Page Applications 
>>>>>>> (SPAs)
>>>>>>> and Multi-Page Applications (MPAs). This feature enhances the visual 
>>>>>>> polish
>>>>>>> of pages without requiring a large development effort from developers to
>>>>>>> make transitions look nice. By selecting from a set of user-agent
>>>>>>> implemented transition effects, the developers can achieve a polished
>>>>>>> transition look with minimal effort.
>>>>>>>
>>>>>>>
>>>>>>> Blink componentBlink>Animation
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAnimation>
>>>>>>>
>>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631
>>>>>>>
>>>>>>> TAG review statusPending
>>>>>>>
>>>>>>> Link to origin trial feedback summary
>>>>>>> https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173
>>>>>>>
>>>>>>> Risk

Re: [blink-dev] Re: Intent to Experiment: Shared Element Transitions

2022-06-14 Thread Khushal Sagar

On Mon, Jun 13, 2022, 1:26 PM Joe Medley  wrote:

> Is the experiment 103 to 106 or 104 to 107.
>

It's 104-106 (inclusive). The last date is October 18, 2022.

> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Jun 13, 2022 at 8:49 AM 'Hannah Van Opstal' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi Nicola,
>>
>> This experimentation is still for the same-origin case.
>> The difference is in the shape of the API. The first intent was approved
>> for the API when it was using Viz. With Viz Shared Element Transitions, we
>> did an origin trial where we received some feedback that led us to change
>> it to use the renderer. So this new intent would be intended for the newer
>> shape - i.e. renderer SET.
>>
>> Please let me know if we can provide any more details.
>>
>> Hannah
>>
>>
>>
>>
>>
>> On Mon, Jun 13, 2022 at 7:16 AM Nicola Tommasi 
>> wrote:
>>
>>> Hi API owners,
>>>
>>> This intent seems to be already approved in the past for same-origin
>>> experimentation, is this launch intended for the cross-origin case?If not,
>>> what's exactly in the scope for this particular launch?
>>>
>>> Thanks,
>>> Nicola
>>>
>>> On Thursday, June 9, 2022 at 8:35:23 AM UTC Yoav Weiss wrote:
>>>
>>>> LGTM to experiment M103-M106
>>>>
>>>> Thanks for working on this! I'm super excited about the possibilities
>>>> this will open!!
>>>>
>>>> On Wed, Jun 8, 2022 at 9:27 PM Khushal Sagar 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 8, 2022 at 3:11 PM Khushal Sagar <
>>>>> khushalsa...@chromium.org> wrote:
>>>>>
>>>>>> Contact emailskhushalsa...@chromium.org, vmp...@chromium.org,
>>>>>> hvanops...@chromium.org
>>>>>>
>>>>>> Explainer
>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>>>>
>>>>>> Specification
>>>>>> https://tabatkins.github.io/specs/css-shared-element-transitions
>>>>>>
>>>>>> Design docs
>>>>>>
>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Shared Element Transitions is a proposal for a new script API that
>>>>>> allows a simple set of transitions in both Single-Page Applications 
>>>>>> (SPAs)
>>>>>> and Multi-Page Applications (MPAs). This feature enhances the visual 
>>>>>> polish
>>>>>> of pages without requiring a large development effort from developers to
>>>>>> make transitions look nice. By selecting from a set of user-agent
>>>>>> implemented transition effects, the developers can achieve a polished
>>>>>> transition look with minimal effort.
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>Animation
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAnimation>
>>>>>>
>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631
>>>>>>
>>>>>> TAG review statusPending
>>>>>>
>>>>>> Link to origin trial feedback summary
>>>>>> https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> Low. As a new feature, the risk here is that other browsers do not
>>>>>> implement it, but since this is a progressive enhancement, sites should 
>>>>>> be
>>>>>> able to drop usage of the feature easily in browsers where it is not
>>>>>> supported.
>>>>>>
>>>>>> *Gecko*: No signal
>>>>>>
>>>>>> *WebKit*: No signal
>>>>>>
>>>>>> *Web developers*: Strongly positive
>>>>>> Interest and developer experiments with the API:
>>>>>>
>>>>>> https://twitter.com/jaffathecake/status

[blink-dev] Re: Intent to Experiment: Shared Element Transitions

2022-06-08 Thread Khushal Sagar

On Wed, Jun 8, 2022 at 3:11 PM Khushal Sagar 
wrote:

> Contact emailskhushalsa...@chromium.org, vmp...@chromium.org,
> hvanops...@chromium.org
>
> Explainer
> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>
> Specification
> https://tabatkins.github.io/specs/css-shared-element-transitions
>
> Design docs
> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>
> Summary
>
> Shared Element Transitions is a proposal for a new script API that allows
> a simple set of transitions in both Single-Page Applications (SPAs) and
> Multi-Page Applications (MPAs). This feature enhances the visual polish of
> pages without requiring a large development effort from developers to make
> transitions look nice. By selecting from a set of user-agent implemented
> transition effects, the developers can achieve a polished transition look
> with minimal effort.
>
>
> Blink componentBlink>Animation
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAnimation>
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631
>
> TAG review statusPending
>
> Link to origin trial feedback summary
> https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173
>
> Risks
>
> Interoperability and Compatibility
>
> Low. As a new feature, the risk here is that other browsers do not
> implement it, but since this is a progressive enhancement, sites should be
> able to drop usage of the feature easily in browsers where it is not
> supported.
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Strongly positive
> Interest and developer experiments with the API:
>
> https://twitter.com/jaffathecake/status/1524782819431555074?t=itU6B0wo6SbjomGiSKLmGQ=19
>
> https://www.reddit.com/r/webdev/comments/uyoit1/i_played_around_with_chromes_new_shared_element/
>
> https://twitter.com/OliverJAsh/status/1530261401016705026?t=CXqW2yiIMbH6bLfn8ImINw=19
>
> https://css-tricks.com/spas-shared-element-transitions-and-re-evaluating-technology/
>
> *Other signals*:
>
> Ergonomics
>
> None.
>
> Activation
>
> Low. As with interop/compat risks, the difficulty stems from this being a
> new feature without support in other browsers. A polyfill for the SPA case
> would be beneficial, but it will not be possible to polyfill MPA behavior.
> That said, dropping the customized transition should not impact the
> usability of a site, fundamentally, so this can easily be dropped on
> browsers that do not support the feature.
>
> Security
>
> The primary security constraint is ensuring isolation of graphics
> resources from multiple origins. The design achieves that using Chromium's
> Viz process similar to OOPIFs.
>
> See also the security and privacy self-review questionnaire that was
> completed as part of the TAG review process:
> https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md
>
> 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
>
> Learning from the feedback from the previous OT, the API has been updated
> to layer on top existing animation systems on the platform. This allows the
> browser to provide a set of default transitions which developers can
> extensively customize. We want to learn that developers can easily adopt
> this API and build the desired UX using the customization options provided.
>
> Reason this experiment is being extended
> Ongoing technical constraints
>
> None.
>
> Debuggability
>
> The feature can be debugged using standard tooling in devtools.
> Specifically the animation panel can be used to pause and scrub through the
> default animations set by the browser. The pseudo DOM structure generated
> by the UA can also be inspected and targeted, like other DOM elements, in
> the style panel.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Currently no support for Android WebView. This is WIP.
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?Yes
>
> Flag nameDocumentTransition
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1328796
>
> Estimated milestones
> OriginTrial desktop last 107
> OriginTrial desktop first 104
> OriginTrial Android last 107
> OriginTrial And

[blink-dev] Intent to Experiment: Shared Element Transitions

2022-06-08 Thread Khushal Sagar

Contact emailskhushalsa...@chromium.org, vmp...@chromium.org,
hvanops...@chromium.org

Explainer
https://github.com/WICG/shared-element-transitions/blob/main/explainer.md

Specification
https://tabatkins.github.io/specs/css-shared-element-transitions

Design docs
https://github.com/WICG/shared-element-transitions/blob/main/explainer.md

Summary

Shared Element Transitions is a proposal for a new script API that allows a
simple set of transitions in both Single-Page Applications (SPAs) and
Multi-Page Applications (MPAs). This feature enhances the visual polish of
pages without requiring a large development effort from developers to make
transitions look nice. By selecting from a set of user-agent implemented
transition effects, the developers can achieve a polished transition look
with minimal effort.

Blink componentBlink>Animation

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

TAG review statusPending

Link to origin trial feedback summary
https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173

Risks

Interoperability and Compatibility

Low. As a new feature, the risk here is that other browsers do not
implement it, but since this is a progressive enhancement, sites should be
able to drop usage of the feature easily in browsers where it is not
supported.

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Strongly positive
Interest and developer experiments with the API:
https://twitter.com/jaffathecake/status/1524782819431555074?t=itU6B0wo6SbjomGiSKLmGQ=19
https://www.reddit.com/r/webdev/comments/uyoit1/i_played_around_with_chromes_new_shared_element/
https://twitter.com/OliverJAsh/status/1530261401016705026?t=CXqW2yiIMbH6bLfn8ImINw=19
https://css-tricks.com/spas-shared-element-transitions-and-re-evaluating-technology/

*Other signals*:

Ergonomics

None.

Activation

Low. As with interop/compat risks, the difficulty stems from this being a
new feature without support in other browsers. A polyfill for the SPA case
would be beneficial, but it will not be possible to polyfill MPA behavior.
That said, dropping the customized transition should not impact the
usability of a site, fundamentally, so this can easily be dropped on
browsers that do not support the feature.

Security

The primary security constraint is ensuring isolation of graphics resources
from multiple origins. The design achieves that using Chromium's Viz
process similar to OOPIFs.

See also the security and privacy self-review questionnaire that was
completed as part of the TAG review process:
https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md

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

Learning from the feedback from the previous OT, the API has been updated
to layer on top existing animation systems on the platform. This allows the
browser to provide a set of default transitions which developers can
extensively customize. We want to learn that developers can easily adopt
this API and build the desired UX using the customization options provided.

Reason this experiment is being extended
Ongoing technical constraints

None.

Debuggability

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

Currently no support for Android WebView. This is WIP.

Is this feature fully tested by web-platform-tests

?Yes

Flag nameDocumentTransition

Requires code in //chrome?False

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

Estimated milestones
OriginTrial desktop last 107
OriginTrial desktop first 104
OriginTrial Android last 107
OriginTrial Android first 104

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/7SMI3IklO4g/m/JS-JojxNAwAJ

This intent message was generated by Chrome Platform Status
.

Re: [blink-dev] Intent to Ship: CSS object-view-box

2022-05-30 Thread Khushal Sagar

On Wed, May 25, 2022 at 11:59 AM slightlyoff via Chromestatus <
admin+slightly...@cr-status.appspotmail.com> wrote:

> Reserved LGTM1. I'm concerned that the TAG review was filed late and has
> not resolved.
>

Sorry, this was an error on my part. I was waiting on a spec (after the
Intent to Prototype) and missed filing the TAG review once that was ready.
I'll make sure to file one as soon as possible going forward. Thanks for
the review!


>
>
Our process depends on folks getting good guidance from senior engineers
> with a wide view of the platform and the connections between parts. The
> only reason I'm not blocking this one until the TAG review finishes is the
> CSS-centric nature of the feature, but I would not expect to be approving
> another feature that doesn't have either an explainer by the proposers or a
> completed TAG review from this team in future.
>
> --
> 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/dfbfb705dfd828c2%40google.com
> 
> .
>

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

[blink-dev] Intent to Ship: CSS object-view-box

2022-05-19 Thread Khushal Sagar

Contact emailskhushalsa...@chromium.org, tabatk...@chromium.org,
vmp...@chromium.org

Explainerhttps://github.com/w3c/csswg-drafts/issues/7058

Specificationhttps://drafts.csswg.org/css-images-4/#the-object-view-box

Summary

object-view-box allows the author to specify a subset within an image that
should draw within the content box of the target replaced element. This
enables an author to create an image with a custom glow or shadow applied,
with proper ink-overflow behavior like a CSS shadow would have.

Blink componentBlink


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

TAG review statusPending

Risks

Interoperability and Compatibility


Gecko: Worth prototyping (
https://github.com/mozilla/standards-positions/issues/626)

WebKit: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2022-March/032166.html)

Web developers: Positive
This property is a pre-requisite for Shared Element Transitions () which
has positive feedback from developers (source
).
Multiple
customers who are excited about SET need this feature to achieve their
desired UX, since their designs have visual overflows such as shadows.

Other signals:

WebView application risks

None



Debuggability

The property can be debugged in the devtools style panel similar to other
CSS properties.


Is this feature fully tested by web-platform-tests

?Yes

Flag nameCSSObjectViewBox

Requires code in //chrome?False

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

Estimated milestones

M104

Anticipated spec changesNone

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz11QzapF4BEX_QTu2FKsT2CEhphkyq%2BnorFgWA_G4qQw%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/CAMLuWUzJ_U4NRn1sF-eBOYHKifZYYwL-Xisq2twHw6B%3D3-WdmA%40mail.gmail.com.

[blink-dev] Re: Intent to Prototype and Ship: Support visual-box on overflow-clip-margin

2022-05-04 Thread Khushal Sagar

Thanks for the review Yoav. Responses inline.

On Wed, May 4, 2022 at 6:12 AM Yoav Weiss  wrote:

>
>
> On Monday, May 2, 2022 at 11:52:56 PM UTC+2 Khushal Sagar wrote:
>
>> Contact emailskhushalsa...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/shared-element-transitions/blob/main/overflow_on_replaced_elements.md
>>
>> Specificationhttps://drafts.csswg.org/css-overflow/#overflow-clip-margin
>>
>> Summary
>>
>> overflow-clip-margin specifies how far an element's content is allowed to
>> paint before being clipped. This feature allows using visual-box
>> <https://drafts.csswg.org/css-box-4/#typedef-visual-box> values to
>> configure the reference box that defines the overflow clip edge the content
>> is clipped to.
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> TAG reviewThe TAG review for the overflow-clip-margin property is here:
>> https://github.com/w3ctag/design-reviews/issues/579
>>
>> TAG review statusIssues addressed
>>
>
> The TAG seem unhappy with this
> <https://github.com/w3ctag/design-reviews/issues/579#issuecomment-918681465>,
> and it doesn't seem like their concerns were addressed.
>

The remaining concerns raised by TAG on that thread were about
overflow:clip (which already shipped in Chrome and Firefox) so I wasn't
sure if those are relevant for this intent.


>
>
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The feature has been reviewed and accepted by the cross-browser CSSWG.
>>
>> Gecko: In development (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1661582)
>>
>> WebKit: No signal
>>
>
> Can we ask for a signal?
>

Sure, I've sent an RFP for this here
<https://lists.webkit.org/pipermail/webkit-dev/2022-May/032215.html>.


>
>
>>
>> Web developers: No signals
>>
>
> Similarly, can you try to get signals here?
> https://goo.gle/developer-signals
>

The bug which motivated this addition is here
<https://bugs.chromium.org/p/chromium/issues/detail?id=99364> (referenced
in the CSSWG issue <https://github.com/w3c/csswg-drafts/issues/5801>). This
bug is starred by 12 users, could we use that as a positive signal?


>
>
>>
>> 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?
>>
>>
>> The feature supports a new keyword for an existing CSS property. There is
>> no high risk for WebView.
>>
>> Debuggability
>>
>> No additional changes needed. overflow-clip-margin already surfaces in
>> the devtools style panel.
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1320869
>>
>> Estimated milestonesM103
>>
>> 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).
>> N/A
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5082351989161984
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.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/CAMLuWUwwqEfXtxqvPHiCm831%3DO5xcgFeZc8Jnc7Z1jvHe-YFkg%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype and Ship: Support visual-box on overflow-clip-margin

2022-05-03 Thread Khushal Sagar

On Mon, May 2, 2022 at 6:44 PM Emilio Cobos Álvarez 
wrote:

> On 5/2/22 23:52, Khushal Sagar wrote:
> > Gecko: In development
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1661582
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1661582>)
>
> We're not opposed to this feature, but having a bug on file isn't quite
> the same as in development :)
>

Fair point, thanks for clarifying the position. Here
<https://github.com/mozilla/standards-positions/issues/462> is the Mozilla
RFP issue for posterity (also updated on the chromestatus dashboard).


>
>   -- Emilio
>
> --
> 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/47162448-0264-c16d-636e-6e58213aa83e%40mozilla.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/CAMLuWUzFZ2Dwq%3Dj4vMtoBW2Jwy3DBO%2Bavt_fDVM1_kzuQ72iig%40mail.gmail.com.

[blink-dev] Intent to Prototype and Ship: Support visual-box on overflow-clip-margin

2022-05-02 Thread Khushal Sagar

Contact emailskhushalsa...@chromium.org

Explainer
https://github.com/WICG/shared-element-transitions/blob/main/overflow_on_replaced_elements.md

Specificationhttps://drafts.csswg.org/css-overflow/#overflow-clip-margin

Summary

overflow-clip-margin specifies how far an element's content is allowed to
paint before being clipped. This feature allows using visual-box
values to
configure the reference box that defines the overflow clip edge the content
is clipped to.

Blink componentBlink>CSS

TAG reviewThe TAG review for the overflow-clip-margin property is here:
https://github.com/w3ctag/design-reviews/issues/579

TAG review statusIssues addressed

Risks

Interoperability and Compatibility

The feature has been reviewed and accepted by the cross-browser CSSWG.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1661582)

WebKit: No signal

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?

The feature supports a new keyword for an existing CSS property. There is
no high risk for WebView.

Debuggability

No additional changes needed. overflow-clip-margin already surfaces in the
devtools style panel.

Is this feature fully tested by web-platform-tests

?Yes

Requires code in //chrome?False

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

Estimated milestonesM103

Anticipated spec changes

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

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/CAMLuWUzsUfBa_UVg-4j3KjjnpSVj1VxD3kExn4H%3DWwoCdW2i%2BQ%40mail.gmail.com.

[blink-dev] Intent to Prototype: CSS object-view-box and object-overflow

2022-03-07 Thread 'Khushal Sagar' via blink-dev

Contact emailskhushalsa...@chromium.org, tabatk...@chromium.org,
vmp...@chromium.org

Explainerhttps://github.com/w3c/csswg-drafts/issues/7058

SpecificationIn Progress

Summary

The object-view-box and object-overflow properties allow the content for
replaced elements to paint outside its content-box, similar to ink overflow
for other elements.

Blink componentBlink>CSS

Motivation

object-view-box and object-overflow allows the author to specify a subset
within an image that should draw within the content box of the target
replaced element. This enables an author to create an image with a custom
glow or shadow applied, with proper ink-overflow behavior like a CSS shadow
would have.

The property will also be used to draw ink overflow for snapshots generated
for shared element transitions
(issue
).

Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/7058

TAG reviewIn Progress (Will file one with a draft spec)

TAG review statusIn Progress

Risks

Interoperability and Compatibility

Risk is minimal. This is a new feature for which support can be detected by
developers.

Gecko: Positive (see comment here
).
Will file a request for position with a draft spec (see comment here

WebKit: No signal

Web developers: No signals

Other signals:

Debuggability

This is debuggable similar to other CSS object-* properties.

Is this feature fully tested by web-platform-tests

?Yes

Flag nameCSSObjectViewBox

Requires code in //chrome?False

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

Estimated milestones

No milestones specified

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

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/CAMLuWUz11QzapF4BEX_QTu2FKsT2CEhphkyq%2BnorFgWA_G4qQw%40mail.gmail.com.

Re: [blink-dev] Best point to detect regions of content area that are updated.

2022-01-03 Thread Khushal Sagar

On Mon, Jan 3, 2022 at 10:04 PM Ramin Halavati  wrote:

> I don't need the precise damaged region and unioned rect suffices.
> I'm still considering possibilities for the triggering mechanism and have
> not found a good one yet. It would be great if you suggest options that I
> take a closer look at.
>
>
Which process is managing the image processing module? I'm assuming it's
the browser so you'll need a mechanism for the browser process to be
notified when the web content updates and a new snapshot is available.

By default the browser doesn't receive such notifications, frames go
directly from the renderer to Viz/GPU and then the display. You'd need to
attach a listener to a FrameSink whose frames you want to capture. The sink
could be 1:1 with the web content for a particular tab, a browser window or
the whole display (in the case of CrOS). The closest use-case to this is
FrameSinkVideoCapturer
<https://source.chromium.org/chromium/chromium/src/+/main:services/viz/privileged/mojom/compositing/frame_sink_video_capture.mojom;l=95;drc=c8c461cb5a5714f0c529b07913511ee54d129e7b>.
It's worth looking through the source code for how it's used.

cc-ing some GPU folks who might have additional pointers.


> Thanks,
> Ramin
>
> On Mon, Jan 3, 2022 at 5:00 PM Khushal Sagar 
> wrote:
>
>> Are you looking for the precise damaged region (list of rectangles) or
>> would a unioned rect suffice? Damage tracking in the compositing stack
>> tracks the latter.
>>
>> Also, how is the snapshot getting triggered? That'll help in pointing out
>> the easiest way to get this information.
>>
>> On Thu, Dec 30, 2021 at 11:07 PM Ramin Halavati 
>> wrote:
>>
>>> Hi!
>>>
>>> I am working on a proposal for an accessibility module that takes
>>> snapshots of the screen and annotates them through a local image processing
>>> module.
>>>
>> To do so, I need to have triggers that say "this region of the screen is
>>> updated". I've looked into several positions for the trigger (like
>>> ui::Window::SchedulePaintInRect oand
>>> cc::AsyncLayerTreeFrameSink::SubmitCompositorFrame) but could not find a
>>> place that gives me the content area rectangles that are updated. I would
>>> appreciate any pointers on where to look.
>>>
>>> Thank you,
>>> Ramin
>>>
>>> --
>>> 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/CAMgMY8wzFGBpai2sX1bE5rjyZtM2B-NKtiACzr0V3GDRn9h6WQ%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMgMY8wzFGBpai2sX1bE5rjyZtM2B-NKtiACzr0V3GDRn9h6WQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

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

Re: [blink-dev] Best point to detect regions of content area that are updated.

2022-01-03 Thread Khushal Sagar

Are you looking for the precise damaged region (list of rectangles) or
would a unioned rect suffice? Damage tracking in the compositing stack
tracks the latter.

Also, how is the snapshot getting triggered? That'll help in pointing out
the easiest way to get this information.

On Thu, Dec 30, 2021 at 11:07 PM Ramin Halavati 
wrote:

> Hi!
>
> I am working on a proposal for an accessibility module that takes
> snapshots of the screen and annotates them through a local image processing
> module.
>
To do so, I need to have triggers that say "this region of the screen is
> updated". I've looked into several positions for the trigger (like
> ui::Window::SchedulePaintInRect oand
> cc::AsyncLayerTreeFrameSink::SubmitCompositorFrame) but could not find a
> place that gives me the content area rectangles that are updated. I would
> appreciate any pointers on where to look.
>
> Thank you,
> Ramin
>
> --
> 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/CAMgMY8wzFGBpai2sX1bE5rjyZtM2B-NKtiACzr0V3GDRn9h6WQ%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/CAMLuWUzfGXT6Qxqe7Hnv9RDuP6UfZaAg8%2B%2BY3XD3njjqY%3DcHMA%40mail.gmail.com.

Re: [blink-dev] Intent to Continue Experimenting: Shared Element Transitions

2021-10-25 Thread Khushal Sagar

Hello API-OWNERS,

We want to request an extension to the end date of this OT from December 14
(current
)
to Jan 4. An engaged partner is running field experiments and they can use
the extension to collect more data. The end milestone is still the same
(M96), the new date aligns with the stable release of the next milestone.

Please let me know if this requires a new Intent or if we could get a quick
LGTM here.

Thanks.
Khushal

On Tue, Sep 7, 2021 at 11:20 AM Vladimir Levin  wrote:

>
>
> On Tue, Sep 7, 2021 at 10:33 AM Arthur Sonzogni 
> wrote:
>
>> Hi Vladimir,
>> Could you confirm this is a continuation of the OriginTrial supporting
>> only Single-Page transitions? We weren't sure by reading this intent.
>> Arthur @arthursonzogni
>>
>
> Yes, I can confirm that this is a request for continuation of OT for
> Single-Page App transition API only.  We intend to file a separate origin
> trial request, if needed, for any version of the API that includes the
> Multi-Page transitions.
>
> Thanks!
> Vlad
>
>
>>
>> Le mer. 1 sept. 2021 à 16:33, Yoav Weiss  a
>> écrit :
>>
>>> *LGTM* to extend the experiment till M96 (inclusive)
>>>
>>> On Mon, Aug 30, 2021 at 7:09 PM Vladimir Levin 
>>> wrote:
>>>
 Contact emailsvmp...@chromium.org, chris...@chromium.org,
 voll...@chromium.org, khushalsa...@chromium.org

 Explainer
 https://github.com/vmpstr/shared-element-transitions/blob/main/README.md

 Summary

 Shared Element Transitions is a proposal for a new script API that
 allows a simple set of transitions in both Single-Page Applications (SPAs)
 and Multi-Page Applications (MPAs). This feature enhances the visual polish
 of pages without requiring a large development effort from developers to
 make transitions look nice. By selecting from a set of user-agent
 implemented transition effects, the developers can achieve a polished
 transition look with minimal effort.

 Blink componentBlink>Animation

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

 TAG review statusPending

 Risks

 Interoperability and Compatibility

 Low. As a new feature, the risk here is that other browsers do not
 implement it, but since this is a progressive enhancement, sites should be
 able to drop usage of the feature easily in browsers where it is not
 supported.

 Gecko: No signal

 WebKit: No signal

 Web developers: Positive Interest in the feature:
 https://twitter.com/jaffathecake/status/1386673316354797570 Main
 feedback is requests to provide more customizability and power:
 https://github.com/WICG/shared-element-transitions/issues/28
 https://github.com/WICG/shared-element-transitions/issues/9

 Ergonomics

 None.

 Activation

 Low. As with interop/compat risks, the difficulty stems from this being
 a new feature without support in other browsers. A polyfill for the SPA
 case would be beneficial, but it will not be possible to polyfill MPA
 behavior. That said, dropping the customized transition should not impact
 the usability of a site, fundamentally, so this can easily be dropped on
 browsers that do not support the feature.

 Security

 The current implementation handles transitions in Viz in anticipation
 of MPA scenarios. More details on this are outlined in the design doc. See
 also the security and privacy self-review questionnaire that was completed
 as part of the TAG review process:
 https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md

 Goals for experimentation

 The API shape is currently limited, providing only a stock set of
 transition types. We've already seen engagement on the WICG and a desire
 for more customization (see web developer response). We hope to learn more
 about the utility of the default transition types and experiences partners
 would like to create, but are unable to achieve with the limited API (we
 have two external partners who have indicated interest). Based on that
 feedback, we may make changes to the API to add more customization. We also
 want to know how easy it is to adopt this API on an existing site.

 Reason this experiment is being extended

 We have gathered feedback from partners, but some amendments to the
 feature are needed in order for them to utilize the feature. Specifically,
 easing function, duration, and delay controls for shared elements is needed
 to better animation control. We are working on adding the controls and
 would like to extend the experiment. Original experiment start date: M92
 Original

42 matches

Mail list logo