W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2011

[whatwg] Support for page transitions

From: Mikko Rantalainen <mikko.rantalainen@peda.net>
Date: Tue, 07 Jun 2011 14:45:04 +0300
Message-ID: <4DEE0F40.3050100@peda.net>
I'm pretty sure that most people on this list have seen page transitions
in Internet Explorer 5.5+
(http://msdn.microsoft.com/en-us/library/ms532847%28v=vs.85%29.aspx#Interpage_Transition).

I think that web application user experience could be improved if
transitions between pages were supported. However, I'm also pretty sure
that the implementation in IE 5.5+ is not a good one because it gives
too much power to the page author and too little control for the user.

I'll start with a use case: I have a web service/application that has a
wizard for registration. The wizard consists of multiple forms (HTML
pages) that must be filled in a sequence. Each form has "Next" and
"Previous" submit buttons. I think that the user experience would
improve if I could attach transitions to these buttons. I'd like to have
"slide the next page from right" for the "Next" button and "slide the
next page from the left" for the "Previous" button. (If you have seen
Android Phone OS and it's system menus, this is very similar setup - it
slides the next screen from right when selecting a submenu item and it
slides previous screen from the left if one presses "back" button.
Android also uses zoom in and zoom out to represent opening an
application and returning to the home screen.)

The things I don't want to have in this specification (page author control):

- actual transition animation ("slide the next page from the left")
- transition duration
- ability to specify easing for transition movement

Instead there should be a method for defining that submitting a form
with a given button, the UA should use transition to "next page".
Hitting another button on the same form should use transition to
"previous page" and hitting some link should use "closing" transition.

The transition to use for "next page" is up to UA and user preferences.
I'd prefer that UA started the animation immediately instead of waiting
that the next page is ready. If the animation were slow, it could
re-render the next page on the fly during the animation as pieces of
next page come ready.

Note that the "next page" button may or may not match with rel="next"
and as such, I think that there should be additional method for
specifying this kind of relation. Perhaps the attribute should be called
"transition" with possible values such as:

* next (advance to next part of the sequence/drill down the menu system,
possible transition could be sliding the current page towards left and
the next page sliding in view from right)
* prev (go back to previous part/return upwards menu, possible
transition could be reverse of next)
* open (open a document e.g. open a google docs document from the list
of possible documents, possible animation could be zoom to the next page)
* close (close current document e.g. close currently edited document and
return to the list of possible documents, possible animation could be
reverse of open)
* swap (replace the current view with another view with some transition
that gives a hint that the previous view was not destroyed e.g. select
another "open" google document from some kind of quick menu, perhaps
some kind of 3d animation where page rotates around vertical axis and
another page is behind it)

I think that it would make sense to use "next page" transition for
rel="next" by default, but there's a need to attach "next page"
transition to interactive elements other than rel="next".

I think that this could be sensible to have in HTML instead of just in
the CSS (or some other method) because it's possible that other software
but just the styling system could use the information about target type
for links and buttons.

This needs to be implemented by the UA because transitions between
different URLs cannot be implemented with JavaScript unlike in-page
transition effects and animations.

-- 
Mikko
Received on Tuesday, 7 June 2011 04:45:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:06 UTC