Re: [whatwg] Support for page transitions
On 6/9/11, Mikko Rantalainen mikko.rantalai...@peda.net 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 input type=submit rel=prev 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 mikko.rantalai...@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.
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 mikko.rantalai...@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
Re: [whatwg] Support for page transitions
2011-06-07 18:07 EEST: Bjartur Thorlacius: On 6/7/11, Mikko Rantalainen mikko.rantalai...@peda.net 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
[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
Re: [whatwg] Support for page transitions
On 6/7/11, Mikko Rantalainen mikko.rantalai...@peda.net 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.
Re: [whatwg] Support for page transitions
On Tue, Jun 7, 2011 at 7:45 AM, Mikko Rantalainen mikko.rantalai...@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/ 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.
