[whatwg] Support for page transitions
Simetrical+w3c at gmail.com
Fri Jun 10 11:44:00 PDT 2011
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
> "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
More information about the whatwg