[whatwg] Support for page transitions

[Mikko Rantalainen]

2011-06-08 01:37 EEST: Aryeh Gregor:
> On Tue, Jun 7, 2011 at 7:45 AM, Mikko Rantalainen
> <mikko.rantalainen at peda.net> wrote:
>> 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.
> 
> It would make sense for the author to be able to control this too.
> You can already do in-page transitions using CSS, and the same syntax
> could be reused for page transitions:
> 
> http://www.w3.org/TR/css3-transitions/

I'm fine with in-page transitions using CSS but I don't think that
current page should be able to apply all available in-page transitions
for transitioning to another page. (In addition, it could be a bit hard
to describe how current and next document should transition when
currently available transitions deal with one element at a time.) Or at
least, the transition should be allowed only for same-origin targets or
some other restriction.

Currently loaded page should not cause transitioning to a new page to
take as long as the current page wishes. For example, user could type
new address into location bar or load a bookmark. Of course, the UA
could totally skip transitions in such special cases. I see in-page
transitions less dangerous than inter-page transitions because such
transitions affect exactly one URL; the inter-page transition should
exists to provide additional user hint about the document change and as
such, that should be more balanced between author control and UA
control. Currently in-page transitions are totally author controlled.

>> 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.
> 
> What are cases where it wouldn't match?

For example, if I have a wizard that logically forks to two different
paths, then rel="next" should not be used. Or at least
http://microformats.org/wiki/existing-rel-values describes "next" as
following:

"Refers to the next document in a linear sequence of documents. User
agents may choose to preload the "next" document, to reduce the
perceived load time."

Notice the word "linear". I think rel="maybe-next" would describe what
I'm thinking. Or perhaps rel="next" should be changed to mean "maybe next".

The same applies to "prev" but a bit less so (usually there's only one
previous place to go). For example, a wizard could have a button to go
to the previous form and an another button to go back to the first (or
previous fork point) form in the currently taken path through forms.
Logically both are previous pages to current page but again, the series
is not linear.

Also note that rel="next" is not currently allowed for submit buttons at
all. So either rel="next" must be relaxed here, too, or we need a new
attribute. I'm fine with either choice.

>> 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".
> 
> What need?

See above. If the specification for rel="next" is relaxed, then this
need is no more (or at least I'm not aware of such a need).

>> 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.
> 
> Offhand, it seems sensible to reuse rel; let each platform work out
> the default transition animation for each link type (perhaps none in
> most cases); and allow authors to override the transition animation on
> a per-link basis.  Selectors like a[rel~=next] would be useful here
> for authors.

This sounds sensible to me.

-- 
Mikko