Firefox 30 ignores autocomplete="off"
for passwords, opting to prompt the user instead whether the password should be stored on the client. Note the following commentary from May 5, 2014:
- The password manager always prompts if it wants to save a password. Passwords are not saved without permission from the user.
- We are the third browser to implement this change, after IE and Chrome.
According to the Mozilla Developer Network documentation, the Boolean form element attribute autocomplete
prevents form data from being cached in older browsers.
<input type="text" name="foo" autocomplete="off" />
For HTML 4, the answer is technically:
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
HTML 5 is even more permissive, saying only that an id must contain at least one character and may not contain any space characters.
The id attribute is case sensitive in XHTML.
As a purely practical matter, you may want to avoid certain characters. Periods, colons and '#' have special meaning in CSS selectors, so you will have to escape those characters using a backslash in CSS or a double backslash in a selector string passed to jQuery. Think about how often you will have to escape a character in your stylesheets or code before you go crazy with periods and colons in ids.
For example, the HTML declaration <div id="first.name"></div>
is valid. You can select that element in CSS as #first\.name
and in jQuery like so: $('#first\\.name').
But if you forget the backslash, $('#first.name')
, you will have a perfectly valid selector looking for an element with id first
and also having class name
. This is a bug that is easy to overlook. You might be happier in the long run choosing the id first-name
(a hyphen rather than a period), instead.
You can simplify your development tasks by strictly sticking to a naming convention. For example, if you limit yourself entirely to lower-case characters and always separate words with either hyphens or underscores (but not both, pick one and never use the other), then you have an easy-to-remember pattern. You will never wonder "was it firstName
or FirstName
?" because you will always know that you should type first_name
. Prefer camel case? Then limit yourself to that, no hyphens or underscores, and always, consistently use either upper-case or lower-case for the first character, don't mix them.
A now very obscure problem was that at least one browser, Netscape 6, incorrectly treated id attribute values as case-sensitive. That meant that if you had typed id="firstName"
in your HTML (lower-case 'f') and #FirstName { color: red }
in your CSS (upper-case 'F'), that buggy browser would have failed to set the element's color to red. At the time of this edit, April 2015, I hope you aren't being asked to support Netscape 6. Consider this a historical footnote.
Best Answer
Support to
<input type=number>
is still very limited, incomplete, and buggy.For example, there is no support on IE 10 and Firefox 19. On them, the element falls back to an
<input type=text>
element, which means that any string is accepted as input and passed to the server as such, with no checking.On browsers that support it, such as Chrome, the behavior varies, and is expected to vary, since the HTML5 CR definition intentionally leaves it open: the browser is required to provide a widget for numeric input somehow and guarantee that the data eventually sent to the server is correct as per the attributes of the element (within the given range, etc.).
In practice, the implementation depends on the locale of the browser, and you cannot control that as an author. This means that a browser might accept 88.2, or it might accept 88,2 (and internally convert it to 88.2), or it might accept both, or it might, in principle, accept input in hieroglyphs only (and internally convert it to the canonical form). It might even parse the user input so that any extra characters are just discarded, which means that 88FOO as well as 88.2 might be truncated to 88 when comma is the decimal separator.
What happens in your case is difficult to decide, since the browsers and platforms have not been described, and it is unclear what the server gets. But the important thing is that
<input type=number>
cannot be relied on, at all. It can be used in a controlled environment where everyone uses the same version of the same browser in the same operating system, up to and including language version and locale settings. Otherwise, use<input type=text>
for numeric input and parse the input server-side and optionally pre-check it client-side, and make sure you inform the user of the expected format of input (such as decimal comma vs. decimal point).