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]
