Re: [css-nav-trans] RFC: Proposal for style rule to specify transitions between page navigations

On Thu, Jun 25, 2015 at 9:23 AM, Daniel Glazman <
daniel.glazman@disruptive-innovations.com> wrote:

> On 24/06/2015 09:46, Christopher Lord wrote:
>
> > Hi Daniel,
> >
> > Interesting - I think a major difference between those you illustrate
> > and what I've proposed, is that those implementations all consist of a
> > set of predefined transitions that a page can request, where as this
> > proposal lets you define a transition period per page and run your own
> > transition with CSS/JS. All of those effects would be possible except
> > for a curling page turn (unless you somehow render your page into a
> > WebGL texture... Via SVG perhaps?), but I think that's fine, that's more
> > a limitation of current page layout/features.
> >
> > The security question is worthy of thought - should a UA impose that
> > input is ignored until transitions finish? I've not currently specified
> > this, but it seems like perhaps it should - or perhaps if a user
> > provides input, that particular piece of input should be ignored and the
> > transition should be interrupted? Maybe either behaviour depending on
> > transition length and thresholds up to the UA? Curious of peoples'
> > thoughts on this.
>
> When I started that document, my point was to show there is a core set
> of page transitions that are already ubiquitous in applications offering
> such page transitions. So IMHO, a requirement for page transitions on
> the Web is to be able to cover, via pre-defined values or any other
> mechanism, these transitions. If we can define them through existing web
> tech (CSS transitions, filters, WebGL, etc), then fine. But otherwise,
> we may need pre-defined values. From a personal point of view, I think
> that having a set of core predefined values is way better than seeing
> loads of scripts copied everywhere... I'm not saying we should not have
> user-defined transitions too, don't misunderstand me.
>

I believe that all these situations can be covered through existing web
tech, as you say. I also think that predefined values wouldn't be useful as
there are too many situations where a user would want to make exceptions to
a particular animation, or when their markup may conflict in some way. I
also don't like the idea of having to strictly define such transitions, and
the inevitable differences there would be between browsers. We already have
well-understood and widely implemented animation and transition frameworks
(and more on the way?), I don't think we need to add to that.


>
> Page transitions are absolutely needed for the following
> implementations:
>
> 1. Ebooks. There are page transitions between pages inside a single
>    document but also page transitions between the last page of a
>    document and the first one of the next one
> 2. Slideshows. The lack of Page transitions remains one of the big
>    issues on the path to a pure web-based slideshow system, in the
>    case each slide is a standalone document (a quite common case)
> 3. Automotive industry. In-car entertainment systems really want to
>    show complex transition effects between their "pages". Since they
>    don't have real Page Transitions for the time being, they must
>    put all the data into one single document or use ugly hacks with
>    frames. Page Transitions would drastically help them in terms of
>    memory footprint and performance. It's a well-kown blocker
>    for the automotive industry.
> 4. Widgets. If we want true multi-page widgets, we need Page
>    Transitions. That's almost similar to the item above.
>
>
I believe the proposed specification allows for all of these situations,
and certainly we're using it in situations identical or very similar to 3
and 4. Please take a look at the examples[0], where you'll find simplified
demonstrations that can apply to practically all of these situations.


> Yes, the security issue is THE big thing here, and the reason why IE
> had site-* values for page transitions. A specification that would not
> address the case of data retrieval from one page to another one would
> be a serious problem. That has a rather important impact on the
> transitioning process itself: which page is triggering the transition,
> the old one or the new one? And so on.
>
>
I can propose what I think for this, but I'm interested in hearing what
others would say. My current thought would be to do this:

Immediately on navigation, the 'from' page stops receiving user input. If
the 'to' page is interacted with in any way, the transition is interrupted
(see section 3.3 on interrupting transitions[1]) and that particular
interaction is discarded. A UA may choose to ignore user input for a short
period of time during a transition to allow the transition to finish
without causing a jarring visual update.

In terms of which page is triggering the transition, the 'from' page is
always triggering, but each page sees it as a completely separate sequence
of events.

--Chris

[0] http://chrislord.net/files/mozilla/gaia-navigator/examples/
[1] http://cwiiis.github.io/gaia-navigator/#interrupting-transitions


> </Daniel>
>