Intent to Implement: Navigation Transitions

[Tony Gentilcore]

My apologies, this email is belated.

Contact emails

oyst...@chromium.org, rsc...@chromium.org, simon...@chromium.org, to...@chromium.org, zh...@chromium.org

Spec

https://docs.google.com/a/chromium.org/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit?pli=1#

Summary

Enables the referring and destination page to coordinate on a visually seamless transition during a navigation.

Motivation

Other platforms may provide mechanisms for two applications to transition seamlessly without interrupting users' flow of thought (e.g., Android's upcoming Activity Transitions). Currently, the modern web provides no mechanism to avoid the full blank, white flash during navigations (fragment changes not withstanding).

We aim to allow web authors to both improve the perceived loading speed as well as provide visual polish by allowing two pages to coordinate on a transition animation (regardless of their origin).

Compatibility Risk

Compatibility risk with other vendors is unknown because we have not explicitly sought feedback yet. We plan to begin the conversation in the WHATWG shortly.

Compatibility risk with existing content is low because the proposed <link rel> type and <meta name> are ignored by browsers that don't understand them and are compatible with the HTML5 spec.

The compatibility risk of removing the feature is low because the animations are declarative and cannot be directly observed. So if we stop supporting it, the navigation would simply revert back to the old white-flash.

Ongoing technical constraints

None

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

Yes.

OWP launch tracking bug?

http://crbug.com/370696 tracks the implementation. We'll create an OWP launch tracking bug and mark it blocked on 370696.

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5169444246519808

Requesting approval to ship?

No

[Emil A Eklund]

Didn't realize that IE dropped support for "page transition effects" a
couple of releases ago. This sounds like a modern (and much improved
version of that).

Would be nice if we could coordinate with the other vendors as it
seems like something everyone would want.
FYI, MS supports something similar for WinJS,
http://msdn.microsoft.com/en-us/library/windows/apps/jj635239.aspx

[PhistucK]

Can you, please, seek advice from the W3C TAG regarding the meta or link tag usage for that?

Perhaps the TAG has a better architectural idea for such features (this and brand-color or theme-color).

Abusing meta tags this way seems hurtful.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Palmer]

Is there any way for origin A to learn anything about the content that
origin B displays as A transitions to B, or vice-versa?

[Oystein Eftevaag]

The transition elements (serialized from A) and the transition stylesheet (specified by B) form a new document in a new renderer (which we prefer to start in the same process as B). As both the transition elements and the transition stylesheet are also opt-in specified by content creators, there shouldn't be any cross-origin leakage.

[Adam Barth]

My understanding was that the elements that A selects to be part of the transition to B are effectively visible to B because B gets to supply some CSS that gets applied to them.  If you get to apply CSS to an element, you can extract a good deal of information about that element.

Adam

[Oystein Eftevaag]

Yes that's correct; I should've amended "beyond that". The idea being that if you designate some elements as transition elements, you're OK with cross-origin CSS being applied to a serialized copy of them.

[Chris Palmer]

On Fri, Jul 18, 2014 at 4:39 PM, Oystein Eftevaag <oyst...@google.com> wrote:

>> My understanding was that the elements that A selects to be part of the
>> transition to B are effectively visible to B because B gets to supply some
>> CSS that gets applied to them. If you get to apply CSS to an element, you
>> can extract a good deal of information about that element.
>

> Yes that's correct; I should've amended "beyond that". The idea being that
> if you designate some elements as transition elements, you're OK with
> cross-origin CSS being applied to a serialized copy of them.

Ahh, yes. So it's opt-in on an element-by-element basis — makes good
sense from a variety of perspectives (UX and graphic design,
performance, security).

It does still create a new type of web app vulnerability, and it's
easy for cynical me :) to imagine developers to opt elements into the
transition without fully realizing they are letting a potentially evil
origin read part of a user's emails or IMs or such. So, it'll be
important to at least call that risk out in big letters in the spec,
in the developer-facing documentation, and in developer relations.

[Addy Osmani]

Sorry to resurrect an old thread :) Chris Lord from Mozilla had some interesting ideas on Navigation Transitions that were just

published: http://chrislord.net/index.php/2015/04/24/web-navigation-transitions/. It may be worth having a chat with him about em'.

On Friday, July 18, 2014 at 9:00:06 PM UTC+1, Tony Gentilcore wrote:

My apologies, this email is belated.

Contact emails

oyst...@chromium.org, rsc...@chromium.org, simonhatc...@chromium.org, tonyg@chromium.org, zh...@chromium.org

[Alex Russell]

I'd love to see a world where multi-page apps with local SWs can feel as good as multi-page apps.

On Fri, Apr 24, 2015 at 8:35 AM, Addy Osmani <ad...@chromium.org> wrote:

Sorry to resurrect an old thread :) Chris Lord from Mozilla had some interesting ideas on Navigation Transitions that were just

published: http://chrislord.net/index.php/2015/04/24/web-navigation-transitions/. It may be worth having a chat with him about em'.

On Friday, July 18, 2014 at 9:00:06 PM UTC+1, Tony Gentilcore wrote:

My apologies, this email is belated.

Contact emails

oyst...@chromium.org, rsc...@chromium.org, simon...@chromium.org, to...@chromium.org, zh...@chromium.org

Spec

https://docs.google.com/a/chromium.org/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit?pli=1#

Summary

Enables the referring and destination page to coordinate on a visually seamless transition during a navigation.

Motivation

Other platforms may provide mechanisms for two applications to transition seamlessly without interrupting users' flow of thought (e.g., Android's upcoming Activity Transitions). Currently, the modern web provides no mechanism to avoid the full blank, white flash during navigations (fragment changes not withstanding).

We aim to allow web authors to both improve the perceived loading speed as well as provide visual polish by allowing two pages to coordinate on a transition animation (regardless of their origin).

Compatibility Risk

Compatibility risk with other vendors is unknown because we have not explicitly sought feedback yet. We plan to begin the conversation in the WHATWG shortly.

Compatibility risk with existing content is low because the proposed <link rel> type and <meta name> are ignored by browsers that don't understand them and are compatible with the HTML5 spec.

The compatibility risk of removing the feature is low because the animations are declarative and cannot be directly observed. So if we stop supporting it, the navigation would simply revert back to the old white-flash.

Ongoing technical constraints

None

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

Yes.

OWP launch tracking bug?

http://crbug.com/370696 tracks the implementation. We'll create an OWP launch tracking bug and mark it blocked on 370696.

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5169444246519808

Requesting approval to ship?

No

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Oystein Eftevaag]

Thanks for the heads up!

I'm not directly involved with this now, but it should be noted that the primary motivation behind the other proposal was to hide page-load time latency (giving the user something to look at while the new page is loading). This proposal doesn't start animating at all until the new page is fully loaded, which I'm worried will have the opposite effect.

On Fri, Apr 24, 2015 at 8:35 AM Addy Osmani <ad...@chromium.org> wrote:

Sorry to resurrect an old thread :) Chris Lord from Mozilla had some interesting ideas on Navigation Transitions that were just

published: http://chrislord.net/index.php/2015/04/24/web-navigation-transitions/. It may be worth having a chat with him about em'.

On Friday, July 18, 2014 at 9:00:06 PM UTC+1, Tony Gentilcore wrote:

My apologies, this email is belated.

Contact emails

oyst...@chromium.org, rsc...@chromium.org, simon...@chromium.org, to...@chromium.org, zh...@chromium.org

Spec

https://docs.google.com/a/chromium.org/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit?pli=1#

Summary

Enables the referring and destination page to coordinate on a visually seamless transition during a navigation.

Motivation

Other platforms may provide mechanisms for two applications to transition seamlessly without interrupting users' flow of thought (e.g., Android's upcoming Activity Transitions). Currently, the modern web provides no mechanism to avoid the full blank, white flash during navigations (fragment changes not withstanding).

We aim to allow web authors to both improve the perceived loading speed as well as provide visual polish by allowing two pages to coordinate on a transition animation (regardless of their origin).

Compatibility Risk

Compatibility risk with other vendors is unknown because we have not explicitly sought feedback yet. We plan to begin the conversation in the WHATWG shortly.

Compatibility risk with existing content is low because the proposed <link rel> type and <meta name> are ignored by browsers that don't understand them and are compatible with the HTML5 spec.

The compatibility risk of removing the feature is low because the animations are declarative and cannot be directly observed. So if we stop supporting it, the navigation would simply revert back to the old white-flash.

Ongoing technical constraints

None

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

Yes.

OWP launch tracking bug?

http://crbug.com/370696 tracks the implementation. We'll create an OWP launch tracking bug and mark it blocked on 370696.

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5169444246519808

Requesting approval to ship?

No

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Fady Samuel]

I'm in the early stages of forming an idea for cross-origin coordination across navigations. I'll share more information here once I work out a bit more of the details.

Thanks,

Fady

[Dimitri Glazkov]

I asked around, and it doesn't look like anybody is targeting to evolve or ship this particular incarnation of Navigation Transitions. While Fady is working on the next incarnation, I think we should remove this one.

:DG<

[Yoav Weiss]

On Wed, May 13, 2015 at 7:19 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

I asked around, and it doesn't look like anybody is targeting to evolve or ship this particular incarnation of Navigation Transitions. While Fady is working on the next incarnation, I think we should remove this one.

 

Any pointers or docs about the next incarnation? 

[Dimitri Glazkov]

I don't know. Fady may post when he wakes up :)

:DG< 

[Nat Duca]

Let me try a different angle. Yoav, what do you think we should do here?

The big thing about moz's is that it doesn't hide loading latency. Moz transitions actually begin after first paint of the new page. So if you have a long loading page, you dont get transitions.

Is that good? Bad? I dunno...

[Yoav Weiss]

Well, the use-cases that I have in mind for something like Nav transitions is definitely *all about* hiding load latency.

I think that single page Web apps, which is the direction a lot of developers are going, has distinct UX advantages over the traditional "click an internal link => White screen => Let us repaint a page that is 90% similar to the page your were in" model.

While single page Web apps are suitable for many applications, for content sites, they make little sense. Yet, people use them, because the user experience of transitioning between pages is significantly better. (Often to the detriment of progressive enhancement, load performance, accessibility, and reach, although that's not a must)

I'd love to see a future where this is not needed, because some form of Nav transitions (however defined, either with JS, CSS, or otherwise) enables the Web developer to create the illusion of a continuous flow when the user moves between internal pages in their app, while using regular HTML content pages.