Re: [whatwg] Support for page transitions
On Tue, 7 Jun 2011, Mikko Rantalainen wrote: > > I think that web application user experience could be improved if > transitions between pages were supported. This is more of a presentational issue, so it's probably best to first try to address it using CSS. I recommend suggesting it on www-style. I haven't added anything to the HTML spec for this at this time. > 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. I think the logical way to do it would be to annotate the link types (which you can do today using rel=""), and to then have the CSS-driven transition effects parameterised from those link annotations. On Thu, 9 Jun 2011, Mikko Rantalainen wrote: > > 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. If this is a use case that people want to address, the way to do it would be to demonstrate an interest from implementors and then to fix the definition on the wiki. The definitions don't have to be set in stone; they should evolve as needed while taking into account existing content. > 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. The relationship between a page and a page obtained through form submission is always "it's the page that was generated from the form submission"; I'm not sure it makes sense to have rel="" on buttons. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Support for page transitions
On 6/9/11, Mikko Rantalainen wrote: > 2011-06-07 18:07 EEST: Bjartur Thorlacius: >> Elaborate; they both refer to the next resource in a sequence of >> documents. Note that a document may be an element in multiple >> sequences of documents. > > 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". Wizards are inherently linear; their reason d'etre is links to subsequent forms for the user to fill in. If the wizard provides multiple links for the user to select one, they can use multiple rel="next" links. Forking wizards thus consist of multiple linear sequences of documents. Example: A -> B -> C A -> C A -> D -> B -> C A would link to B, C and D, D to B and B to C. IIUC this is valid. There may of course be more forking points. > Backup of form contest is one thing and I'm already using user agents > that allow this at least via extensions. However, submitting the draft > to the server instead allows additional application specific processing > / mutation for the form when user later returns to it. For static pages, > there's a less need for features like this. > It seems to me that such mutation would preferably be done client-side (using JavaScript), so the user can benefit sooner. It seems odd to make the user fill in a form partially, submit a draft, and then edit a mutation thereof. But only if he pauses his work to submit the draft, and only on the data he put in prior to submitting. And not give him the mutated version if he fills the form in without pause. If you really want the user to get the mutated version, you return another form prefilled with mutated values when the user submits the first one. That's possible using ordinary submits. Can you provide use cases for this server-side mutations of drafts? > Also note that currently rel="next" is not allowed on input type=submit, > unless I've understood incorrectly. Having an is far from straight-forward. You should have a document with hyperlinks of rel=next and rel=prev and forms. The forms themselves contain no links to subsequent forms. The user agent should fill in a form, submit it in another browsing context and proceed to the next one (allowing the user to select the next one when the document suggest multiple). There's nothing forbidding the user agent from showing fancy transitions while loading the next document, progressively rendering the form as it becomes available. [Current HTML draft, Form submission algorithm, step 15]
Re: [whatwg] Support for page transitions
On Thu, Jun 9, 2011 at 7:41 AM, Mikko Rantalainen 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.
Re: [whatwg] Support for page transitions
2011-06-07 18:07 EEST: Bjartur Thorlacius: > On 6/7/11, Mikko Rantalainen wrote:> >> 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 > Elaborate; they both refer to the next resource in a sequence of > documents. Note that a document may be an element in multiple > sequences of documents. See my other reply to this thread. > If I understand correctly, the feature you want that's not supported > by rel=next and rel=prev is sending a draft to a server when switching > forms. Even better than that would be saving a draft for every input > filled by a user. This draft can be written to a local disk, or stored > at networked servers for global access, for the user agent to refill > when the user revisits the form. Backup of form contest is one thing and I'm already using user agents that allow this at least via extensions. However, submitting the draft to the server instead allows additional application specific processing / mutation for the form when user later returns to it. For static pages, there's a less need for features like this. Also note that currently rel="next" is not allowed on input type=submit, unless I've understood incorrectly. -- Mikko
Re: [whatwg] Support for page transitions
2011-06-08 01:37 EEST: Aryeh Gregor:
> On Tue, Jun 7, 2011 at 7:45 AM, Mikko Rantalainen
> 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
Re: [whatwg] Support for page transitions
On Tue, Jun 7, 2011 at 7:45 AM, Mikko Rantalainen
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/
> 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?
> 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?
> 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. On the desktop, you don't usually have this sort of
next-page animation, so it would be weird if pages exhibited that
behavior unless the author specifically requested it. On Android or
other particular platforms, it might make sense as the default. But
it definitely makes sense to me to put this in CSS.
Re: [whatwg] Support for page transitions
On 6/7/11, Mikko Rantalainen wrote:> > 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 Elaborate; they both refer to the next resource in a sequence of documents. Note that a document may be an element in multiple sequences of documents. If I understand correctly, the feature you want that's not supported by rel=next and rel=prev is sending a draft to a server when switching forms. Even better than that would be saving a draft for every input filled by a user. This draft can be written to a local disk, or stored at networked servers for global access, for the user agent to refill when the user revisits the form. I think some user agents already implement the latter, so that leaves bells, whistles and transitions.
[whatwg] Support for page transitions
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
