- From: <bugzilla@jessica.w3.org>
- Date: Sat, 03 Dec 2011 08:34:38 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12687
Ian 'Hixie' Hickson <ian@hixie.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |WONTFIX
--- Comment #22 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-12-03 08:34:36 UTC ---
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:
(In reply to comment #20)
> I agree with Stefan. The current implementation is illogical.
HTML is illogical all over the place.
> It breaks the
> expected behavior without a good reason to do so (or at least none that i can
> see).
The element represents a coordinate. The expected behaviour, IMHO, is to send a
coordinate. Sending a coordinate and a value is unexpected.
> Every input element sends the name-value pair, beside this one. Is there a
> logical reason to do so?
No, not every input element does this. In fact, the behaviour of input elements
is highly inconsistent. type=file includes a file and a filename, checkbox and
radio buttons are included or not rather than having their value change, and
their value is defaulted to "on" rather than the empty string, <select>
elements can have multiple values for one name, the whole thing is completely
inconsistent.
> Input elements with type=image are not only used as imagemaps, they can also be
> used as simple graphical buttons where the X and Y coords are just irrelevant
> and what matters is only the name-value pair to say "yes, this button has been
> clicked"... more so because the user might not use a pointing device to click
> on it making the coords absolutely useless.
Sure, and that works fine, regardless of what we do here.
> but IMO, by doing so, you are leaving a logical inconsistency in your
> specs with an unmotivated exception
It's not unmotivated. I've explained the motivations.
> to the general rule "every input element
> sends the name-value pair" which you should at least make it clear in the HTML
> specification since, as i said, this is not what developers would expect.
I don't see how it's unclear. The value attribute is not conforming... how
could a value be included?
(In reply to comment #19)
> [quote]
> Looks like Gecko, IE, Opera, and the spec all agree. WebKit seems to be the
> lone dissenter;
> [/quote]
> Incorrect. Gecko migrated to the 'work in progress' spec, before, Firefox was
> also working in the described way.
It might have been incorrect in the past, but it's not incorrect now, which is
what I care about.
> I posted this bug because of the gazillion
> bug reports on the Mozilla bugtracker system, I don't see this as an incident
> of one intraset website.
Please list the pages affected by this problem. If it affects big sites, or
many small sites, then that is data that will affect the decision.
> Especially not considering this is a W3Schools example.
http://w3fools.com/
> Then just answer the trivial question: why is any input type button posting a
> name and a value, except for type=image.
The premise of the question is false; other types do things other than just
post name=value too.
But even if that were not true, the answer is "because a coordinate is two
numbers, so we return two numbers". Also, "because that's what most browsers
do".
> It is far from a logical decision,
Logic really doesn't factor into HTML's design. There's a reason the WHATWG tag
line is "Please leave your sense of logic at the door".
> which in this entire thread I am asking for. Why remove the feature and not
> complement it like happens for every other input-tag?
We didn't remove it. It has never existed except in two rendering engines (now
one) which were implementing a non-standard behaviour. Any page depending on
this, for example, would never have worked in IE.
--
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 Saturday, 3 December 2011 08:34:40 UTC