[whatwg] Support for page transitions

[Aryeh Gregor]

On Thu, Jun 9, 2011 at 7:41 AM, Mikko Rantalainen
<mikko.rantalainen at peda.net> wrote:
> 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.)

You could just have the transition apply to the root element.

> 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.

Certainly pages should only be allowed to control transitions when the
navigation is due to a link in the page or something else intrinsic to
the page, not when the user types in the URL bar.  I don't have a
strong opinion on whether such transitions should be restricted
further -- certainly browsers might want to cap the length, or allow
users to disable them, or similar.

> 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".

It's pretty vague, so I think you could use it anyway.  There's no
hard requirement there.

> 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.

Well, we could allow rel here in principle.  But more problematically,
there's no way to specify a relation *or* CSS when navigating the page
programmatically, like via document.location.  I don't have a good
answer here.