HTML and CSS Reference
In-Depth Information
Now our regular expression has become much more compli-
cated and it can be quite tricky to test this pattern on a big form
in a web page. Since the pattern's regular expression matches
the syntax of a JavaScript regular expression, we can test this
in a browser console such as Firebug or Opera Dragonfly, using
pure JavaScript to determine whether the pattern will work. In
the example below, I'm just testing the UK post code match, and
using the JavaScript test method to experiment. Note that I've
also wrapped my tests with the leading ^(:? and trailing )$ as
the HTML5 spec states:
¬ (“bn14 8px”)
> true
¬ (“bn149 8px”)
> false
Those results are correct, since “bn149” isn't a legal part of a
post code (or certainly not for this contrived example!). Finally,
it's worth noting that the pattern attribute is case sensitive, and
since we have no way to switch to case insensitive mode, we
need to match on lowercase and uppercase explicitly in this
example (hence the [a-zA-Z]).
The autocomplete attribute
Most browsers have some kind of autocomplete functionality.
HTML has an autocomplete attribute which lets you control how
this works. Although it's newly standardized in HTML5, it's not a
new feature; it was a non-standard feature of IE5.
The default state is for the input to inherit the autocomplete
state of its form owner. Forms have autocomplete on by default.
If the autocomplete attribute of a form element is set to on, the
field is fine for autocompletion.
I'll quote the wry humour of the specification's description of the
off state: “The off state indicates either that the control's input
data is particularly sensitive (for example, the activation code for
a nuclear weapon); or that it is a value that will never be reused
(for example, a one-time-key for a bank login) and the user will
therefore have to explicitly enter the data each time.”
Search WWH ::

Custom Search