I clicked on it and the form is submited, along with a query string appended like x=1&y=2 to the url targetted by the form's action.
Why?
The x and y values are the co-ordinates of the mouse pointer relative to the element when clicked.
From the HTML 4.02 specification:
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
It behaves like a mini imagemap. This is by design.
IMAGE is a TYPE attribute value to the INPUT element for FORMs. It specifies an image that can be clicked upon to pass information to the processing script. In implementation, this form TYPE acts much like the INPUT TYPE=SUBMIT field, but unlike the SUBMIT field, the coordinates of the image that were activated are sent back to the server in addition to the rest of the form data.
from eskimo.com
IE and Firefox will both create different variables when submitting from an image submit button. My advice is not to rely on any of them being present in your form processing. If you must (to determine which of multiple buttons was pressed) you will need to check for multiple variables.
I'll give you three guesses which browser causes the problem and the first two don't count. If you have an image button
<input type="image" name="restore" value="Restore" src="...">
when the user clicks, Mozilla will return the values
restore = Restore
restore_x = number of pixels from top of image
restore_y = number of pixels from left edge of image
IE, however, will not return the restore=Restore Template key/value. So you can get caught if you develop in one browser and then test in IE, because
isset($_POST['restore'])
will always return false in IE, but will work as expected in Mozilla (and probably Opera but I don't know off the top of my head).
From a 2004 webmasterworld.com forum post I just googled
Those are the coordinates that you clicked on an image, a property of the "image" type of input control. You can ignore those if you don't need them.
Related
We have UI widget that is a composite of input field and an icon. This widget is basically meant to be used as a form field to let users select a value from a huge list of values. Users can either type a value in the input field or click on the icon to launch a dialog with all the possible value list. Selecting a value in this dialog will set the value in the input field. Users can also type a partial value in the input field and tab-out in which case, the widget tries to autocomplete the value entered and if it doesn't succeed, it will launch the same dialog as user clicking on the icon.
How would I make such a widget accessible through screen readers? There doesn't seem any role or any other aria attribute which seems to be tailor made for my usecase. At the minimum, I would expect the users using screen readers to know that this widget has an helper icon from where a value can be selected.
I am reading this as an order database/form, where call takers can just select type in the customer number or fill out the 10+ fields. And if the caller doesn't know their ID or whatever, the call taker can do a search.
I recommend removing the autocomplete on tab functionality, because that wouldn't too fun for some. I'd code it like:
<p id="instr">Put instructions here</p>
<label for="user">Look Up User</label> <input id="user" aria-describedby="instr">
<input type="button" value="Populate Form">
<input type="button" value="Search">
I made an answer about modals quite some time ago, that should get you started. The listing in the dialog may not be the most fun to wade through. I'd recommend either updating this question or making a new one for that part.
Interesting and challenging.
To start with make sure icon has an alt text which explains its role - this is assuming it is an image. If not use title attribute to explain its role.
Add a title attribute to the input box and succinctly mention that user can also chose values using icon or partially type its value to autocomplete it.
If your form design allows instructions to be placed next to the form fields place a descriptive text right next to the widget.
These recommendations may not make it entirely accessible but will surelytake you close to where you want to be. I'm hoping that this widget will be used in more than one place in your project allowing user to get accustomed to it.
Last one to consider is to see if any aria role fits your widget controls in any way.
In Chrome, I noticed that undo does not work properly for input element after the contents of the element has been changed programmatically. Although I get different behaviours for different browsers, they're not as bad as Chrome.
FF20 good
IE9 some support (undo stack cleared when input loses focus)
Safari5 some support (undo stack cleared when input loses focus)
Chrome26 unreliable
For example, a script that trims spaces (see also jsfiddle below)
type some spaces before "hello!",
click outside the input element
click on the input element and press Ctrl-Z
now the text is gone (in Chome)
jsfiddle here
<input type="text" id="input1" value="hello!">
document.getElementById("input1").addEventListener('blur', function(evt){elementLosesFocus(evt, this);}, false);
function elementLosesFocus(evt, caller)
{
caller.value = caller.value.trim();
}
I think the best thing I can hope for is a method to somehow clear the undo history of the input when it loses focus (as is the case with IE and Safari).
Chrome doesn't store the field's states, but rather a diff or set of deltas for each undo/redo. It takes less memory, but causes the bug you're dealing with.
You can effectively simulate the user pasting a value into the field by using document.execCommand("insertText", false, "text to insert");.
For your particular case:
First, save the field's value to a variable. var temp = caller.value;
Next, clear the field's value or set its selectionStart to 0 and selectionEnd to the field's length. This way a simulated paste replaces the field's contents.
Next, make sure the field has the focus. caller.focus();
Finally, simulate the user pasting in the modified value. document.execCommand("insertText", false, temp.trim());
I found this solution in another SO question, https://stackoverflow.com/a/10345596/1021426
Take a look at this login page, specifically, the form in the section labeled Returning Members. As you can verify by looking at the HTML or by digging with a tool such as Firebug, the actual form contains four tags: one each for the email address and password, an invisible input called "memberAlready" that contains the value "yes", and a submit button in the form an image. So far, perfectly generic.
However, if you inspect the form data at the point at which the form is submitted (using Tamper Data or its equivalent on another browser, you'll see that two additional form fields have been sneaked into the response: ACTION(loginCheckout).x and ACTION(loginCheckout).y.
They both have two-digit integer values, which suggests that they're only there to verify that the submitter is an actual web browser and not a robot. Presumably, they are related somehow to the submit button, which is defined as follows:
<input type="image" name="ACTION(loginCheckout)" value="Login" src="/images/login/login.gif">
What's confusing to me is that these extra form fields appear even when JavaScript is disabled in the browser. So they presumably aren't just something inserted by an event handler somewhere.
Furthermore, if you submit the form programmatically (e.g., by running document.forms[1].submit() in the JavaScript console), the extra fields are not generated and the login attempt fails. That suggests to me that the insertion of the fields depends on something outside the basic HTML form submission mechanism. But what that "thing" could be if it's not JavaScript, I don't know.
Does anyone recognize this pattern or have a theory as to how the validation fields are inserted?
Take a look at the code you posted here:
<input type="image" name="ACTION(loginCheckout)" value="Login" src="/images/login/login.gif">
Notice that this is an image input type which is used to submit the login form. The additional values that appear to be injected on submission are simply the x and y coordinates where the you clicked on the image to submit the form. They are not additional values which are injected by JavaScript on form submission, they are added by the browser itself.
Try clicking on different areas of the images and see the values change.
When you use JavaScript to submit the form, you do not click on the image, which is why the x and y values are not included on form submission.
Replacing the image for an <input type="submit" /> element will remove the x and y coordinates.
Hope that helps.
The X and Y values you are seeing are because the submit button is an an input type=image. They correspond to the X and Y locations within the image where the cursor was when the image was clicked. They're added by the browser itself, as the HTML specification requires it. Section 17.4.1 states that for an image input type
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
You'll note it only mentions the use of a pointing device. If you submit by using the keyboard the values won't be created.
Web developers can use <input type="image" name="name"> to present their users a graphical submit button. The w3 standard on html forms regarding input controls states that
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
Now, I know that Firefox will generate a request that contains name itself, whereas Internet Explorer does not. my question, is Firefox providing additional functionality on top of the standard, does Internet Explorer not implement the full standard correctly (happened in the past …) or is the standard simply unclear regarding this aspect?
edit
It looks like Firefox creates a weird request (or it is parsed in a strange way by PHP). if the input name is an array (i.e. name[1]) the resulting $_POST variable will contain: ["name"] => array(1) { [1]=> string(2) "57" }. so the .x component is munged and the .y component is turned into the only value …
edit 2
Upon further investigation it looks like even Firefox does not send the control's name when it's of type image, even with the value attribute set …
addendum
It seems like that what I really want to know is how I can make use of <input type="image" name="el[]" /> elements when the name is an array, without messing up the POST request.
If for some reason it were mandatory to associate a <button> with more than one value, is there a good way to do it? For example ...
CSV:
<button value="Lancelot,Grail,blue">Answer</button>
JSON:
<button value="{'name':'Lancelot','quest':'Grail','color':'blue'}">Answer</button>
In the absence of a good way to do it, is there a traditional way?
Edit: another use case
Server M, the producer of the HTML, knows the user's current location and favorite genres, movie names, nearest theater, and next showtime. Server F knows how to query various 3rd party servers about how to get from point A to point B in order to arrive by time T. The user knows only the movie names: click Drag Me to Hell, and get the route. Server M could generate a form for each movie, with a single button showing the name of the movie and multiple hidden fields with the start and end locations and desired arrive-by time, but that would require a lot of repeated code. Every one of these one-button mini-forms would have the same method and action and the same hidden input field structure. Styling would be a collection of mini-forms rather than a collection of buttons, so FIELDSET and LEGEND are unavailable (because HTML forbids nested forms). Putting the parameters into the button's value attribute would be much tidier.
Well if you have to have a button element, why not use JavaScript to set a bogus property:
$('mybutton').compoundValue = { ... json ... };
and then reading the 'compoundValue's during form submit, etc.
Though really you might want to consider a group of checkboxes or some other form bits for what you're trying to accomplish.