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

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

--- Comment #39 from Luke Plant <L.Plant.98@cantab.net> 2011-12-09 13:43:29 UTC ---


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

-- 
Configure bugmail: https://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 Friday, 9 December 2011 13:43:34 UTC