[Bug 12561] Add the @action in the <form> so that there is a way to submit to the same page

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12561

--- Comment #20 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-07-19 20:59:17 UTC ---
(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?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 19 July 2011 20:59:25 UTC