This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The HTML5 spec clearly states: Section 4.10.19.6 Form submission, http://dev.w3.org/html5/spec/Overview.html#attr-fs-action: "The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces." The specification does not estate a way to submit to the page where the form exists so I'd like it to be specified. I have some options but I don't really know which one is best. 1: "_self" 2: "" (empty string, some browsers already implement what I stated with the empty string) 3: "?" Examples of application: If the url of the page that has the <form> tag is: http://the.web.org/path/to/the/thing I want the form to submit to: http://the.web.org/path/to/the/thing If the url of the page that has the <form> tag is: http://the.web.org/index.pl I want the form to submit to: http://the.web.org/index.pl If the url of the page that has the <form> tag is: http://the.web.com/wierdplace/place I want the form to submit to: http://the.web.com/wierdplace/place I'm asking this for some reasons: The filenames are not something something that is that constant as some think. With this there is no need for the server to process the page it should submit (even it it's easy). With that, the form would be completely portable. Less mess with the server code as (for example) <?php echo ... ?>. Personally I already had problems when tried to reuse code and when I change filenames. I usually have to spend time trying to find that form that has the action to the same file (ex: "index.php") and change it (ex: "applicationform.php") so that the form works again. Something I could have avoided if I used server side scripting (works but not the best solution) or if the browser had already implemented this natively (best option).
Furthermore it's unclear why "" is considered invalid. It's a relative reference which refers to the current document.
(In reply to comment #1) > Furthermore it's unclear why "" is considered invalid. It's a relative > reference which refers to the current document. I agree with that. That's why I proposed the "" to be the option (even if I think that the other ones can be taken in account).
For legacy compatibility, an empty action is processed in an unexpected way: "If action is the empty string, let action be the document's address of the form document." http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm It ignores <base>. As such, it's better if authors avoid it and use an equivalent URL like "#" instead, so that it behaves the same as other URLs. I assume this is the reason it's invalid. ("_self" will not work at all -- it will submit to the current URL with the last part of the path replaced by the string "_self". "?" will also submit to a different URL than the current one, namely the current URL with the character "?" appended, even though this usually will make no difference to the resulting resulting. "#" will submit to the current URL exactly, with base processing.)
(In reply to comment #3) > For legacy compatibility, an empty action is processed in an unexpected way: > > "If action is the empty string, let action be the document's address of the > form document." > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm > > It ignores <base>. As such, it's better if authors avoid it and use an > equivalent URL like "#" instead, so that it behaves the same as other URLs. I > assume this is the reason it's invalid. > > ("_self" will not work at all -- it will submit to the current URL with the > last part of the path replaced by the string "_self". "?" will also submit to > a different URL than the current one, namely the current URL with the character > "?" appended, even though this usually will make no difference to the resulting > resulting. "#" will submit to the current URL exactly, with base processing.) In firefox 3.6/3.7 # makes it submit to the same page but not to the same URL so... not a good idea as the form isn't submitted to the internet. Submitting a ? really makes sense, if specified. Having a ? action does submit to the same page and does not send any new variables (just that ? is appended to the URL). A spec could be made so that if the action is ?, then it means to submit to the same URL. Even with that, I'm still inclined to the "" as the option to submit to itself.
Okay, wait a sec. <form action=""> is the same as just <form>. So if you want to submit to "", just omit the action attribute entirely. This will in fact ignore <base>, but that's usually not an issue. I now assume that the reason action="" isn't allowed is because it's redundant, although I'm not sure. (In reply to comment #4) > In firefox 3.6/3.7 # makes it submit to the same page but not to the same URL > so... not a good idea as the form isn't submitted to the internet. Hmm, good point. This doesn't actually cause an HTTP request, so it's not very useful. > Submitting a > ? really makes sense, if specified. Having a ? action does submit to the same > page and does not send any new variables (just that ? is appended to the URL). Actually, this will strip any existing query string, so it's not an acceptable solution at all. > A spec could be made so that if the action is ?, then it means to submit to the > same URL. No, it cannot. Browsers' behavior here is well-established and cannot be changed without really, really, really good reason.
(In reply to comment #5) > Okay, wait a sec. <form action=""> is the same as just <form>. So if you want > to submit to "", just omit the action attribute entirely. This will in fact > ignore <base>, but that's usually not an issue. I now assume that the reason > action="" isn't allowed is because it's redundant, although I'm not sure. Redundant or not, submitting to the page that has the form, nowadays, makes a lot of sense. The page with the form may be php, asp or any other server side script and it will handle the query and could even show the errors in a better way. > Actually, this will strip any existing query string, so it's not an acceptable > solution at all. ... > No, it cannot. Browsers' behavior here is well-established and cannot be > changed without really, really, really good reason. True... forget that one, then. The empty string is the way to go, then!!!
(In reply to comment #5) > Okay, wait a sec. <form action=""> is the same as just <form>. So if you want > to submit to "", just omit the action attribute entirely. This will in fact > ignore <base>, but that's usually not an issue. I now assume that the reason > action="" isn't allowed is because it's redundant, although I'm not sure. > ... So exactly why then is "" non-conforming? Note that missing @action was invalid in HTML4, so what was allowed in HTML4 is now non-conforming, and the workaround is to use something that's invalid in HTML4.
FWIW http://html5.org/tools/web-apps-tracker?from=5783&to=5784
(In reply to comment #8) > FWIW http://html5.org/tools/web-apps-tracker?from=5783&to=5784 Why not define explicitly what does the empty string mean, then?
(In reply to comment #9) > Why not define explicitly what does the empty string mean, then? It *is* defined explicitly: "If action is the empty string, let action be the document's address of the form document." http://dev.w3.org/html5/spec/association-of-controls-and-forms.html#form-submission-algorithm The question is about what is conforming markup for authors to use. HTML5 conformance rules are designed to help avoid author errors. action="" is being marked non-conforming because it is handled differently than other empty URL values.
I think disallowing action="" is not very helpful. There is likely existing content that uses action="" and no <base> and there it's a waste of time to change it, and moreover missing attribute is processed the same but is conforming. Seems arbitrary. If we want to inform authors of the weirdness with <form action=""> and <base>, we should say that validators should issue a warning for <form> and <form action> when there's also a <base href> in the document.
HTML5 shouldn't be inventing the way to specify the base URL. RFC 1808 does this, and it clearly states (section 4, step 2a, and 5.1/5.2) that the empty URL means the base URL. There is in fact no other way to specify "the base URL" as a relative URL in that RFC. The only complication is the legacy fact that browsers ignore the <base href> in this case. But use of base is relatively rare, and validators could issue a warning in that case. Forcing authors/tools to change the value of 'action' to avoid a problem they didn't have anyway, because they weren't using <base>, is just silly - they didn't have a problem before, but they do now. Saying "omit the attribute if you want to specify the empty URL" has various problems: 1 It makes it harder to produce valid HTML for tools that generate HTML. The tool has to special case the empty URL and omit the @action attribute entirely if an empty URL was specified, even though an empty URL is not a special case - it is a perfectly valid relative URL. 2. I makes it impossible for such tools to generate HTML that is compatible with HTML4 and HTML5 in the case of the empty URL. HTML4 requires the attribute, HTML5 requires it to be absent in this case. 3. You cannot apply this to the @formaction attribute, because for that, omitting the attribute means the @action on the form is used. This problem produces an arbitrary and completely unnecessary limitation. The following (simplified) form is quite sensible: <form action="/foo/" method="POST"> <input type="submit" name="post" value="post"> <input type="submit" name="preview" value="preview" formaction=""> </form> The result would be that the default action for the form is to go to one specifed URL, but one button should result in posting to the base URL. However, under current spec, it should be rejected, and there is *no other way* to produce the same effect. For some reason, you cannot specify that a certain button should target the base URL. This is a clear bug in the spec, AFAICS. Now, browsers are going to continue to treat @action as they currently do (i.e. allow the empty URL) for backwards compatibility. If and when they support @formaction, it is extremely unlikely they will apply different rules, because 1) this would require more work 2) it would produce less usefulness. Therefore, the de-facto standard will be to allow @formaction to be empty, just like @action, and treat it in the same way. To fix this, you could allow @formaction to be empty. But if that is allowed, it makes no sense to treat @action any different - that would be very confusing.
(In reply to comment #12) > To fix this, you could allow @formaction to be empty. But if that is > allowed, it makes no sense to treat @action any different - that would > be very confusing. Even after reading your post I still wonder... Why is it confusing?
(In reply to comment #13) > Even after reading your post I still wonder... Why is it confusing? It would be confusing and inconsistent if "" was valid for @formaction and not for @action. (It's not currently valid for either, but in that point of my argument I was saying that we must at least change it for @formaction).
action="" and formaction="" should be consistent with each other for sanity. action="" (empty) is not the same as action=" " (single space) for historical reasons and as this is very confusing, it is made non-conforming to not specify a non-empty URL. If you just want to submit to the current page, ignoring base URLs, then you can just use <form> without an action URL. If you want to submit to the current page, following the base URL and blowing away any current query parameters, then use <form action="?">. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: no spec change Rationale: The use cases listed are already possible.
(In reply to comment #15) > Rationale: The use cases listed are already possible. Couldn't it just be specified in the spec so that no browser maker remembers that the meaning could be different? Something that makes the action="" valid among validators.
(In reply to comment #15) > Rationale: The use cases listed are already possible. I think you may have missed one I described: I want a form to have action="some-url", but I want a single button to target the current URL, and so want to set formaction="". This is not allowed under the current spec. > action="" (empty) is not the same as action=" " (single space) for historical > reasons and as this is very confusing, it is made non-conforming to not specify > a non-empty URL. I do not understand this reason at all, because it is fixing confusion by adding worse confusion and difficulty. I, for one, despite developing web sites for many years, and being a core developer of a fairly prominent web framework (Django), had no idea about the difference between action=" " and action="", presumably because I'd never needed to use the <base> element - AFAICS the difference only kicks in at that point. But now I've been forced to find out about it! All, apparently, to stop me being confused by a situation I would, most likely, have never found myself in. All I want to do is set a form's action to a perfectly valid URL, but instead I end up having a history lesson and being told I've got to do some other strange thing instead. How is this helping me? If using <base> was the norm, this might make some sense, but as it is extremely rare, it is still rather difficult to understand why this change has been made. (I can't find any stats on the use of <base> - I've only got my anecdotal evidence that I don't think I've *ever* come across it in the wild, and I'm still looking for one live example. I presume this is because it is basically not very useful - it only really helps you if all your relative links are going to the same sub-directory, which seems less and less like with modern web development).
We could forbid or warn about action=""/formaction="" if <base> is present maybe?
To add some stats to my last message, I set up a crawler to do a broad search on as many domains as possible, with these results: On 6192 URLs, across 4303 domains, containing 10520 forms, it found: 233 pages with 'base' ( 3.8%) containing 672 forms, of which: - 25 had action="" ( 3.7%) - 0 had action=" " ( 0.0%) 5959 pages with no 'base' (96.2%) containing 9848 forms, of which - 386 had action="" ( 3.9%) - 0 had action=" " ( 0.0%) So, we're seeing about 4% of forms having action="" or action=" ", whether there is 'base' or not. (My own experience is that having action="" is actually much more common - it is the normal case for most forms I write, because you very often want to validate and display any errors on the same form as was submitted). For all of these pages, with the current HTML5 spec the author would have a problem to fix if they wanted to move to HTML5, or would have confusion caused by the current decision to disallow the empty URL, despite it being a perfectly valid relative URL according to RFC 1808. In a much smaller set of cases - the 0.2% of all forms that have 'base' and also have either action="" or action=" " (25/10520), the new spec could *potentially* save some confusion. I say potentially, because they might not actually have any problem, and if they did it would only help if they run their page through a checker. If they do run it through a checker, however, a warning, as suggested above, would be just as useful as an error. In addition to the confusion and problems caused for both new and existing documents, there are worse problems for tool authors, and I don't think that Ian Hixie's comment took this into account: Many tools produce HTML that targets either HTML4 and HTML5 doctypes, or XHTML 1.0 and HTML5 doctypes. It is entirely possible to do this successfully in many cases. For example, currently the 'admin' application of the Django web framework generates HTML which is entirely compatible with both XHTML and HTML5 - with the one exception of *this* change to @action. With the change, it is impossible to satisfy both XHTML and HTML5 (or HTML4 and HTML5), as pointed out by Julian Reschke above. Since we *cannot* fix this in Django (in any feasible way), our only option is to ignore validity, with the result that validity checking will increasingly become irrelevant since pages will very often have errors. This, of course, works in the direction of defeating the whole purpose of this change. Thanks for taking the time to read this.
(In reply to comment #16) > > Couldn't it just be specified in the spec so that no browser maker remembers > that the meaning could be different? Something that makes the action="" valid > among validators. I don't understand this suggestion. (In reply to comment #17) > > I want a form to have action="some-url", but I want a single button to target > the current URL, and so want to set formaction="". This is not allowed under > the current spec. Just use formaction="?" instead. > > action="" (empty) is not the same as action=" " (single space) for historical > > reasons and as this is very confusing, it is made non-conforming to not specify > > a non-empty URL. > > I do not understand this reason at all, because it is fixing confusion by > adding worse confusion and difficulty. I don't see how it is fixing confusion or adding confusion. It's just putting a fence around something that is confusing. (In reply to comment #18) > We could forbid or warn about action=""/formaction="" if <base> is present > maybe? The problem is that that would make it harder to take a valid page and move it to a different URL by adding <base>, since now you'd have to go in and make other changes too. (In reply to comment #19) > To add some stats to my last message, I set up a crawler to do a broad search > on as many domains as possible, with these results: > > On 6192 URLs, across 4303 domains, containing 10520 forms, it found: > > 233 pages with 'base' ( 3.8%) > containing 672 forms, of which: > - 25 had action="" ( 3.7%) > - 0 had action=" " ( 0.0%) > > 5959 pages with no 'base' (96.2%) > containing 9848 forms, of which > - 386 had action="" ( 3.9%) > - 0 had action=" " ( 0.0%) Thank you, this is exactly the kind of data that is helpful in these situations. > So, we're seeing about 4% of forms having action="" or action=" ", whether > there is 'base' or not. (My own experience is that having action="" is actually > much more common - it is the normal case for most forms I write, because you > very often want to validate and display any errors on the same form as was > submitted). > > For all of these pages, with the current HTML5 spec the author would have a > problem to fix if they wanted to move to HTML5, or would have confusion caused > by the current decision to disallow the empty URL, despite it being a perfectly > valid relative URL according to RFC 1808. > > In a much smaller set of cases - the 0.2% of all forms that have 'base' and > also have either action="" or action=" " (25/10520), the new spec could > *potentially* save some confusion. I say potentially, because they might not > actually have any problem, and if they did it would only help if they run their > page through a checker. If they do run it through a checker, however, a > warning, as suggested above, would be just as useful as an error. Note that 0.2% is a really high amount given that there are trillions of pages out there. 0.2% is the volume we found for <image> (vs <img>) and it was sufficient to require that we support <image> in the parser. > Many tools produce HTML that targets either HTML4 and HTML5 doctypes, or XHTML > 1.0 and HTML5 doctypes. It is entirely possible to do this successfully in many > cases. For example, currently the 'admin' application of the Django web > framework generates HTML which is entirely compatible with both XHTML and HTML5 > - with the one exception of *this* change to @action. With the change, it is > impossible to satisfy both XHTML and HTML5 (or HTML4 and HTML5), as pointed out > by Julian Reschke above. You don't need to satisfy HTML4 or HTML5 or XHTML1. You only need to worry about the latest HTML; what is implemented by browsers (or what they're converging onto). Using action="" is not safe, due to the <base> problem. So we should discourage tools from outputting it. > Since we *cannot* fix this in Django (in any feasible way), our only option is > to ignore validity, with the result that validity checking will increasingly > become irrelevant since pages will very often have errors. This, of course, > works in the direction of defeating the whole purpose of this change. Why can't you fix it?
(In reply to comment #20) > (In reply to comment #17) > > > > I want a form to have action="some-url", but I want a single button to target > > the current URL, and so want to set formaction="". This is not allowed under > > the current spec. > > Just use formaction="?" instead. That would be an option, if it was. With the current spec, if the program uses the ? to identify the page where to redirect to (SMF style, where everything passes through index.php) that is no longer an option. I'm requested to make (still simple but are getting more and more complex) websites that includes forms of this kind. So, an url to the form like: /file?path=path-to-myself if I use "?" I lose the get var. if I use "?path=path-to-myself", if the path changes, the path Get var stops working. How to solve this? - Give special meaning to "?" (alone) which means to submit to the same page -> might have some implications. - Give special meaning to "" which means to submit to the same page -> already many browsers consider this "submit to the same url".
(In reply to comment #20) > Just use formaction="?" instead. This will not work for POST forms where the current URL has a query component, because it will strip the query component. (BTW, I have actually tested this, and can confirm that with at least one browser, Chrome, specifying '?' as the relative URL will cause the query component to be removed, for both form@action and input@formaction). > I don't see how it is fixing confusion or adding confusion. It's just putting a > fence around something that is confusing. It is adding confusion by adding a special rule. In the case of having no <base> (the more common case by 20 to 1), there is nothing confusing about an empty URL. But now I have to remember to do something other than the obvious thing - instead of specifying an empty URL, I must omit the attribute. > You don't need to satisfy HTML4 or HTML5 or XHTML1. You only need to worry > about the latest HTML; what is implemented by browsers (or what they're > converging onto). That is a good suggestion for document authors, but in this case I was writing as a tool author, and decisions about doctype are made by our users, not us. We don't have the authority to tell people to switch from XHTML doctypes. > > Since we *cannot* fix this in Django (in any feasible way), our only option is > > to ignore validity, with the result that validity checking will increasingly > > become irrelevant since pages will very often have errors. This, of course, > > works in the direction of defeating the whole purpose of this change. > > Why can't you fix it? Because we have 1) users who expect our output to be valid XHTML (since it has been historically), and may well have requirements of document validity and 2) users who want to use our output in HTML5 documents, and may also want document validity. We cannot please both (with the current HTML5 spec), since fixing our output for HTML5 by omitting @action breaks it for XHTML. Thanks, Luke
Compatibility with XHTML validators is not a design goal of HTML5. If you want to maintain an XHTML mode, you can use a mode switch, which outputs valid XHTML in XHTML mode and valid HTML5 in HTML5 mode. MediaWiki has done this since 1.16, released a year ago: http://www.mediawiki.org/wiki/Manual:$wgHtml5 I don't think we're realistically going to make extra markup valid just to support the use-case of pages that want to validate as XHTML 1.x as well as HTML5.
(In reply to comment #23) > I don't think we're realistically going to make extra markup valid just to > support the use-case of pages that want to validate as XHTML 1.x as well as > HTML5. I think that is a fair point. I might add that this isn't a case of making 'extra' markup valid - rather, it seems that is the HTML5 spec that has gone to extra lengths to define a perfectly sensible combination of markup as *invalid*. However, I don't consider this the main argument against the current spec, just an additional nuisance.
Sorry for the noise, but I also meant to say that the problem with compatibility applies to HTML4/HTML5 as well as XHTML/HTML5 (as already mentioned above). The current spec makes it impossible to generate a form that targets the same URL, and have that form be both valid HTML4 and valid HTML5. Section 2.5 of the HTML design goals - http://dev.w3.org/html5/html-design-principles/#compatibility - says this: "implementations should be able to add new features to existing code, rather than having to develop whole separate modes." It seems to violate the design goal of 'evolution not revolution' to add something to the spec that requires a doctype switch to specify between HTML4 and HTML5, when all I want to do is use a subset of the capabilities provided by both HTML4 and HTML5.
(In reply to comment #25) > Sorry for the noise, but I also meant to say that the problem with > compatibility applies to HTML4/HTML5 as well as XHTML/HTML5 (as already > mentioned above). The current spec makes it impossible to generate a form that > targets the same URL, and have that form be both valid HTML4 and valid HTML5. Again, allowing the same markup to be both valid HTML5 and valid something-else is not a design goal here. > Section 2.5 of the HTML design goals - > http://dev.w3.org/html5/html-design-principles/#compatibility - says this: > > "implementations should be able to add new features to existing code, rather > than having to develop whole separate modes." > > It seems to violate the design goal of 'evolution not revolution' to add > something to the spec that requires a doctype switch to specify between HTML4 > and HTML5, when all I want to do is use a subset of the capabilities provided > by both HTML4 and HTML5. That design goal says that browsers have to be able to process all pages the same. They do: they process all pages as HTML5, without regard for other standards. The question at hand is whether authors can write pages that are both valid HTML5 and valid something-else. That's not a design goal. If you only want to use a subset of features, just pick one or the other.
mass-move component to LC1
See comment #26. This bug is waiting for a reply from brunoais and/or Luke Plant.
(In reply to comment #28) > See comment #26. This bug is waiting for a reply from brunoais and/or Luke > Plant. I don't know which kind of reply do you want. I want this feature to be applied using the option no 2. "2: "" (empty string, some browsers already implement what I stated with the empty string)". I'm still waiting for request for more info or to accept this. I'm not expecting this to be refused at all.
(In reply to comment #28) > See comment #26. This bug is waiting for a reply from brunoais and/or Luke > Plant. I also don't know what kind of comment is expected. Ayreh Gregor's comment #26 is well taken, but it only addresses one argument of many, as already stated. The following arguments still stand, as far as I can see: 1) The combination of specifying @action=something but wanting an individual button to target the same URL, using @formaction="", cannot be achieved, which is a bizarre restriction. The suggestion of using formaction="?" does not work for reasons already described. 2) Many web authors and tools would be affected by this change if they wanted to make pages HTML5 compliant (my crawler results showed approx 4% of all pages using @action=""), and far fewer (approx 0.2% use @action=" " or @action="" with base element present) are potentially helped by this change. 3) The current spec is going out of its way to ban a value for a URL that is explicitly allowed by the relevant RFCs, thereby introducing its own standard and increasing confusion. 4) An alternative solution has been proposed - that HTML5 validators issue a warning for the problematic case of a specified 'base' element and @action="" or @action=" ". The solution appears to address the problem that exists for the '0.2%' without any of the disadvantages that banning an empty @action attribute would cause the '4%'. Thanks.
(In reply to comment #30) > 4) An alternative solution has been proposed - that HTML5 validators issue a > warning for the problematic case of a specified 'base' element and @action="" > or @action=" ". The solution appears to address the problem that exists for the > '0.2%' without any of the disadvantages that banning an empty @action attribute > would cause the '4%'. Sorry, I forgot one point that Ian Hixie made in comment #20 - that if you only issue the warning about @action="" when <base> is present, the author may be unaware that simply adding a <base> could be problematic. Therefore, perhaps the validator should issue a warning whenever it finds @action="". This warning might be nuisance for the many legitimate cases of @action="" with no <base>, but it is much better than issuing an error IMO. Thanks again.
(In reply to comment #31) > (In reply to comment #30) > > > 4) An alternative solution has been proposed - that HTML5 validators issue a > > warning for the problematic case of a specified 'base' element and @action="" > > or @action=" ". The solution appears to address the problem that exists for the > > '0.2%' without any of the disadvantages that banning an empty @action attribute > > would cause the '4%'. > > Sorry, I forgot one point that Ian Hixie made in comment #20 - that if you only > issue the warning about @action="" when <base> is present, the author may be > unaware that simply adding a <base> could be problematic. Therefore, perhaps > the validator should issue a warning whenever it finds @action="". This warning > might be nuisance for the many legitimate cases of @action="" with no <base>, > but it is much better than issuing an error IMO. > > Thanks again. Why not specify that the problem is the empty @formaction and not the @formaction? State that if you show an empty @action with an empty @formaction is wrong and you should write something in @formaction.
I don't see the problem here. Just use formaction="?". You're not supposed to POST to a URL with query parameters anyway, that doesn't make sense. The query arguments are the form data in GET form submissions, the HTTP request body is the form data in POST form submissions.
(In reply to comment #33) > I don't see the problem here. Just use formaction="?". You're not supposed to > POST to a URL with query parameters anyway, that doesn't make sense. The query > arguments are the form data in GET form submissions, the HTTP request body is > the form data in POST form submissions. Actually, that does make sense in some context I have already encountered. Also, I've been trying to find and I can't find anything in the spec that states that you may not send GET data if method is POST. This may work as an example (I need better ones. This1 I just made up): In PHP, the $_REQUEST variable is there mostly for historical reasons. Most programmers state that relying a lot on it is not a good idea. Your script uses urls in this way: /index.php?page=a&something=b. if you use the "?" in the @action, it'll become(by the rules): /index.php? Now the script will have to have a way to send those 2 variables through POST. For that, just use hidden inputs with that key (@name) value (@value) association. Now if I want to use another GET variable (for any reason) I have to update the HTML also (But that's just a detail). The problem is in the server. If you want to do things right you'll need to check the $_GET and the $_POST variables if you want to do things right just because the variables that identify where is the page the user wants is usually inside the url. Just by having, example, @action="", the browser would always reuse the whole url that made the page to appear. So if the url is: /index.php?page=a&something=b. the POST will go to: /index.php?page=a&something=b. if the url is: /something.php the POST will go to: /something.php if the url is: /index.php?page=a&deletation#forme the POST will go to (and the page will actually reload): /index.php?page=a&deletation#forme Does that make sense to you? Do you need a better example?
(In reply to comment #33) > I don't see the problem here. Just use formaction="?". You're not supposed to > POST to a URL with query parameters anyway, that doesn't make sense. The query > ... What?
(In reply to comment #33) > You're not supposed to POST to a URL with query parameters anyway, Can you please provide a reference for this assertion? > that doesn't make sense. This use can make perfect sense in many applications. I will give one that doesn't use any PHP for the sake of generality. Suppose you have a page that is showing some records. The records have a UI that has filters, and it uses GET forms (or links) and query parameters to specify the filters, as you would expect. The page also has a batch update feature that operates on the records shown on the screen. The form is POST, as it should be, and the fields included are the values to be updated, and only those. As it happens, Trac (bug software, http://trac.edgewall.org/) with the batch modification plugin (http://trac-hacks.org/wiki/BatchModifyPlugin) does exactly this for its ticket listing page. So also do some parts of the Django web framework. There are no doubt countless other examples in real life. In this example, every feature of the URL and HTTP is being used as intended - query parameters used to specify a query, and POST parameters used to provide data for updating. This is a completely natural way to do things, and the alternative - putting the query in hidden fields in the form, as well as in the URL, would be unnatural, and lead to confusion due to duplication. It is entirely possible that the GET parameters and POST parameters may even contain the same values: POST /records?foo=1&bar=2 HTTP/1.1 foo=10 To me, it is difficult to imagine a more natural translation of the SQL "UPDATE records SET foo=10 WHERE foo=1 AND bar=2" into HTTP. More to the point, it is *not forbidden*. It certainly wasn't forbidden in HTML4 or any HTTP spec I can find, and even if it was, browsers implement the behaviour and applications depend on it. > The query > arguments are the form data in GET form submissions, the HTTP request body is > the form data in POST form submissions. That is true, but says nothing about whether URL query parameters are allowed in POST requests.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Let's cut to the chase here. We can't allow action="" with no value because it's too confusingly similar to action=" " with a space which has different behaviour. We can't make action="" and formaction="" different because that would be ridiculously confusing. For almost all purposes, if you want to target the same page you can use target="?" or formaction="?". Sure, there might be cases where that isn't quite as convenient as you might like, e.g. because you're POSTing to a URL with query parameters. So don't do that. Put the data in the POST payload, or in the path, or don't use both action="" and formaction="" in such situations.
(In reply to comment #37) > Rationale: Let's cut to the chase here. We can't allow action="" with no value > because it's too confusingly similar to action=" " with a space which has > different behaviour. We can't make action="" and formaction="" different > because that would be ridiculously confusing. For almost all purposes, if you > want to target the same page you can use target="?" or formaction="?". Sure, > there might be cases where that isn't quite as convenient as you might like, > e.g. because you're POSTing to a URL with query parameters. So don't do that. > Put the data in the POST payload, or in the path, or don't use both action="" > and formaction="" in such situations. It appears that each approach has different drawbacks, and that it's far from clear what the best approach is. For instance, why does action=" " *need* to have a different behavior?
Perhaps we could approach this another way. For browser authors, forbidding action="" has no effect - the spec tells them what to do when a document has action="" anyway, which is the same as what browsers do already. For page authors, if the author doesn't care about validation, the restriction has no effect, whether for good or bad. For page authors who do care about validation, we have the following cases (assuming the stats I found above): 1) 0.2% of page authors will be helped by avoiding the gotcha with base. However, these people would have been *equally* helped by the validator emitting a warning for them. 2) 6% of page authors (30 times the above number) will have a headache on their hands. They might decide to fix it in any number of wrong ways (see below), in which case their problem could get worse. If they are depending on 3rd party components or tools, they might not be able to fix their problem at all. Please note that for some of these people, document validity can be a matter of law. Specifically, some bodies are required by law to have websites meet accessibility standards, the first requirement of which is that HTML must be valid. A restriction like this is legally binding on them. (I have worked in places like that in the past). Could you explain why you rejected the option of emitting a warning for action="" or action=" "? That would help anyone potentially affected by the 'base' gotcha, without hindering other people. In response to your suggestions: (In reply to comment #37) > For almost all purposes, if you > want to target the same page you can use target="?" or formaction="?". This is a Really Bad Idea. Specifying formaction="?" does not mean "the same page", it means "strip the query parameter" (at least in the browsers I've tested). Confusing these two ideas is bad in itself. Further, for the form author, it often won't be known whether this is a safe thing to do or not. It can be easy to assume it will be safe, and it may indeed work in some circumstances, so you won't catch the problem immediately, but it will cause mysterious bugs in others cases. Given the way that in typical modern web development, forms will be reused and web frameworks will use query parameters for various things, the suggestion is likely to cause serious bugs. This is *not* a hypothetical problem. In the Django web framework, due to the need for HTML5 validity, I changed some forms to use action="." (which did exactly the same as action="?" in the circumstances used - it strips the query parameters and posts to the same path). [1] (It never occurred to me to *omit* the @action attribute, BTW, but it wouldn't have been a solution anyway, for reasons described previously). This, unfortunately, introduced a serious and insidious *data loss* bug [2], that was fortunately caught before the next release. That bug is the primary reason why I am here on this bug report. Of course I can't blame the HTML5 spec for my bug. However, it did make it more likely, and the fact that putting action="?" or formaction="?" is such a tempting - but BAD - solution to the problem is another reason the spec should be changed. Your second suggestion: > Sure, > there might be cases where that isn't quite as convenient as you > might like, e.g. because you're POSTing to a URL with query > parameters. So don't do that. Put the data in the POST payload, > or in the path, or don't use both action="" and formaction="" > in such situations. Are you seriously suggesting that when a developer finds they need an input with formaction="", and then discover this curious hole in the spec that doesn't allow what they need to do, they should then *rewrite* their request handling (and form generation, since they will now need a dynamically created form that can convert GET parameters into POST parameters, avoiding any potential clashes), *just* to get a valid HTML5 document? Do I really need to explain the *many* reasons why that is a bad solution, or might be totally impractical in many situations? Quite honestly, I think this is more than a little insulting to web developers - as if they have nothing better to do with their time than to rewrite their apps to avoid a perfectly sensible technique when no decent rationale for doing so has been given. (You have not given any reasons why POSTing to a URL with query parameters is incorrect or bad practive). The amount of work required to make such a changes could be vast. So, the fact remains that the spec has a clear bug in it - you cannot use the combination of a form that has a non-empty @action and a single input that needs a @formaction to specify the document's URL or the base URL. Given that 94% of forms have non-empty @action, and 6% have empty @action, if @formaction sees any use at all, it doesn't seem at all unlikely that you will want to use non-empty @action with empty @formaction. But even if it would be a rare combination, it still doesn't seem sensible to exclude it, because specs should allow features to compose naturally. Imagine an HTML spec where it ended up that if you had the specific combination of an <ins> inside a <span> inside an <li>, there was no legal way to specify the @class attribute on the <ins>, for example. A spec like that would be a bad spec, no matter how rare the combination was, and "don't do that" would hardly be a satisfying answer, despite the multiplicity of potential workarounds. This is especially the case since these days it is extremely rare for a single party to be in control of all the HTML in a page, and all the HTTP handling of the requests. Rather, pages are usually composed using 3rd party tools, or using 3rd party components. These components should just "play nice", and for the reasons I've given above, the current spec stands in the way of that. Thanks for reading all that! [1] https://code.djangoproject.com/changeset/16051 [2] https://code.djangoproject.com/ticket/16154
I didn't understand correctly... Why won't fix? What's the problem that you don't want to fix?
(In reply to comment #15) > action="" (empty) is not the same as action=" " (single space) for historical > reasons and as this is very confusing, it is made non-conforming to not specify > a non-empty URL. I'm inclined to agree with Comment 11. Could we not allow action="" (which is common) and prohibit action=" " (single space)?
(In reply to comment #41) > (In reply to comment #15) > > action="" (empty) is not the same as action=" " (single space) for historical > > reasons and as this is very confusing, it is made non-conforming to not specify > > a non-empty URL. > > I'm inclined to agree with Comment 11. > > Could we not allow action="" (which is common) and prohibit action=" " (single > space)? Isn't not allow and prohibit the same? Did you write it right?
(In reply to comment #42) > (In reply to comment #41) > > (In reply to comment #15) > > > action="" (empty) is not the same as action=" " (single space) for historical > > > reasons and as this is very confusing, it is made non-conforming to not specify > > > a non-empty URL. > > > > I'm inclined to agree with Comment 11. > > > > Could we not allow action="" (which is common) and prohibit action=" " (single > > space)? > > Isn't not allow and prohibit the same? Did you write it right? Sorry, to be clear, I'm asking why we cannot: a) allow action="" (empty string) AND b) prohibit action=" " (single space)
action="" is the non-conforming one because it's the one that has behaviour inconsistent with every other place in the language that handles the empty string as a URL.
(In reply to comment #44) > action="" is the non-conforming one because it's the one that has behaviour > inconsistent with every other place in the language that handles the empty > string as a URL. What's the meaning of the empty string, then? Isn't it to load a page with the same url than this one (including the hash)?
(In reply to comment #45) > What's the meaning of the empty string, then? Isn't it to load a page with the > same url than this one (including the hash)? Contrast Step 9 at: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm with the base URL treatment when other URLs are resolved: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#resolving-urls
(In reply to comment #46) > (In reply to comment #45) > > What's the meaning of the empty string, then? Isn't it to load a page with the > > same url than this one (including the hash)? > > Contrast Step 9 at: > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm > > with the base URL treatment when other URLs are resolved: > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#resolving-urls I must be reading something wrong... I can't find the problem, actually.
(In reply to comment #47) > I must be reading something wrong... I can't find the problem, actually. Roughly speaking, href="" resolves to the base URL (e.g. from the <base> element or the document address) but action="" resolves against the document address only.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: No new information since comment 37. (I disagree with comment 11 because <base> elements are most often added by automated processes long after the page has been authored and validated, so validator warnings when you add <base> wouldn't help. I disagree with comment 41 because action="" meaning something different than href="" is just vastly too confusing, IMHO.)