[whatwg] Support for page transitions

[Bjartur Thorlacius]

On 6/9/11, Mikko Rantalainen <mikko.rantalainen at 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]