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

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.

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.

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.

</Daniel>

Received on Thursday, 25 June 2015 08:23:32 UTC