Re: [whatwg] Targetting different anchors after submitting the form
Ian Hickson wrote: On Mon, 6 Mar 2006, Mikko Rantalainen wrote: Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form With WF2 you can just do: form action=url input name=foo type=submit action=url#xfoo input name=bar type=submit action=url#xbar /form indeed: 2.17. Extensions to the submit buttons ... In some cases, authors would like to be able to submit a form to different processors, using different submission methods, or not replacing the form but just updating the details with new data. For this reason, the following attributes may be used on submit buttons: action, method, enctype, replace, and target. ... if only i could figure our how to compile the firefox source (i've tried on three seperate occasions it's just far too complicated with all the extra garbage you have to install and configure first!) i could see this as something i could put in a local version to assist with making test-cases of the spec. ric hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Targetting different anchors after submitting the form
Ric Hardacre wrote: Ian Hickson wrote: On Mon, 6 Mar 2006, Mikko Rantalainen wrote: Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form With WF2 you can just do: form action=url input name=foo type=submit action=url#xfoo input name=bar type=submit action=url#xbar /form indeed: 2.17. Extensions to the submit buttons ... In some cases, authors would like to be able to submit a form to different processors, using different submission methods, or not replacing the form but just updating the details with new data. For this reason, the following attributes may be used on submit buttons: action, method, enctype, replace, and target. ... I did check the spec but somehow I missed that. Thanks for pointing it out. I just hit the problem yesterday and I was wondering which kind of support for this kind of feature I should be expecting in the future, so I can make our internal application framework to be ready for it. -- Mikko
Re: [whatwg] Targetting different anchors after submitting the form
Quoting Ric Hardacre [EMAIL PROTECTED]: if only i could figure our how to compile the firefox source (i've tried on three seperate occasions it's just far too complicated with all the extra garbage you have to install and configure first!) i could see this as something i could put in a local version to assist with making test-cases of the spec. Feel free to download a weekly build of Opera 9.0: http://my.opera.com/desktopteam/ ... and test how it works. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Targetting different anchors after submitting the form
Le Mon, 06 Mar 2006 16:25:12 +0200, Mikko Rantalainen [EMAIL PROTECTED] a écrit: Currently it's possible to do stuff like this form action=url#anchor input name=foo type=submit input name=bar type=submit /form and the UA scrolls down to element with id anchor on the page returned by the server. It would be nice to be able to set target anchor on per-submit-button basis. Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form would result to action urls url#xfoo and url#xbar respectively. Perhaps even if the above example had action=url#xzoo, in which case the new anchor attribute would override the fallback behavior. Is it too much to add a new attribute for something like this? Note that the server cannot see any of these anchor urls. Only the UA is able to scroll to correct position after receiving output from the server. Maybe adding an attribute for this sole purpose is too much to ask for. There are isolated cases where this is needed (I myself didn't need this ever). You can, however, modify the action of the form via DOM, by having an event listener for the submit event. I suppose you've used this. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Targetting different anchors after submitting the form
ROBO Design wrote: Is it too much to add a new attribute for something like this? Note that the server cannot see any of these anchor urls. Only the UA is able to scroll to correct position after receiving output from the server. Maybe adding an attribute for this sole purpose is too much to ask for. There are isolated cases where this is needed (I myself didn't need this ever). You can, however, modify the action of the form via DOM, by having an event listener for the submit event. I suppose you've used this. I've used multiple submit buttons myself in a couple of ways, most recently this has been used in an order enquiry search form where the admin can list orders by order no, customer order no, by customer or by product code. i do this by having one text input box and multiple submit buttons, and the client likes it that way very much indeed. a more everyday use i can think of off of the top of my head is this: form action=order_place.asp input type=submit value=PLACE ORDER input type=submit value=SAVE QUOTE action=quote_add.asp#thanks input type=submit value=RECALCULATE TOTALS action=#here /form where the first button invokes the default form action (user hands over their cash) the second overrides it with it's own target page (converting the user's basket into a quote that they can refer to later and place as an order) the third submits the page back to itself (as per action=) but specifies an anchor to jump to (e.g. if the basket and totaliser is at the foot of the page) as an aside, if i could go back in time i would change the original spec so that the text displayed on a submit button is separate from the value submitted, thus: input type=submit name=ordertype value=sales text=PLACE SALES ORDER input type=submit name=ordertype value=sample text=PLACE SAMPLE ORDER input type=submit name=ordertype value=pro text=REQUEST PRO RATA INVOICE ric hardacre www.cyclomedia.co.uk
Re: [whatwg] Targetting different anchors after submitting the form
Quoting ROBO Design [EMAIL PROTECTED]: ... form action=order_place.asp input type=submit value=PLACE ORDER input type=submit value=SAVE QUOTE action=quote_add.asp#thanks input type=submit value=RECALCULATE TOTALS action=#here /form What's wrong with using the form attribute to point to multiple forms? One submits to one place, the other submits to another place. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Targetting different anchors after submitting the form
Anne van Kesteren wrote: Quoting ROBO Design [EMAIL PROTECTED]: ... form action=order_place.asp input type=submit value=PLACE ORDER input type=submit value=SAVE QUOTE action=quote_add.asp#thanks input type=submit value=RECALCULATE TOTALS action=#here /form What's wrong with using the form attribute to point to multiple forms? One submits to one place, the other submits to another place. that might do it. can the data in my hypothetical cart belong to all the forms at once? ric hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Targetting different anchors after submitting the form
Anne van Kesteren wrote: Quoting ROBO Design [EMAIL PROTECTED]: ... form action=order_place.asp input type=submit value=PLACE ORDER input type=submit value=SAVE QUOTE action=quote_add.asp#thanks input type=submit value=RECALCULATE TOTALS action=#here /form What's wrong with using the form attribute to point to multiple forms? One submits to one place, the other submits to another place. whoops, sent my last reply from the wrong from address, mod might ignore it but i've read the spec. if i want all the data in my basket to associate with my multiple forms i have to specify, for each and every one (unless there's some default=all forms possibility as opposed to default=none) the form thus input type=hidden id=prod_00_name value=pie form=saveform quoteform totalform input type=hidden id=prod_00_ea value=1.99 form=saveform quoteform totalform input type=hidden id=prod_00_qty value=4 form=saveform quoteform totalform input type=hidden id=prod_01_name value=beer form=saveform quoteform totalform [several dozen other elements along the lines of the above] input type=submit value=PLACE ORDER form=saveform input type=submit value=SAVE QUOTE form=quoteform input type=submit value=RECALCULATE TOTALS form=totalform now obviously this is an extreme example; i could just associate all three forms with a fieldset and house my cart/basket within that. but the fieldset is a block element and it may well end up presenting a similar problem that moving the form definition to the head was meant to solve. (though in my first example i did use a block-level form). ric hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Targetting different anchors after submitting the form
On Mon, 6 Mar 2006, Mikko Rantalainen wrote: Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form With WF2 you can just do: form action=url input name=foo type=submit action=url#xfoo input name=bar type=submit action=url#xbar /form -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Targetting different anchors after submitting the form
Mikko Rantalainen wrote: Currently it's possible to do stuff like this form action=url#anchor input name=foo type=submit input name=bar type=submit /form and the UA scrolls down to element with id anchor on the page returned by the server. It would be nice to be able to set target anchor on per-submit-button basis. Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form would result to action urls url#xfoo and url#xbar respectively. You could get the server to send a 303 See Other response and set Location: http://example.com/url#foo. RFC 2616: 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. -- Lachlan Hunt http://lachy.id.au/
