[whatwg] Re: pattern attribute
malcolm-what at farside.org.uk
Thu Jul 22 05:07:43 PDT 2004
Wrigley, Ave writes:
>> * Whole-pattern matches appears to be significantly more common.
>> * Forms-design applications that support patterns usually make the
>> pattern a whole-pattern rather than substring match.
> I take the point - but I am not sure I understand why the case for whole
> pattern over substring matched differs between when they appear in a
> form and when they appear in a script (where substring matching is more
> common). Is this just an historical artifact, or is there a more
> fundamental reason?
I'm not totally sure of what you're saying, but I think the answer is that
the two problem areas ('pattern matching in script' and 'form validation')
do have different requirements.
In the first case, you're matching a pattern to a string. It *might* be to
validate a form control, or it might not (you might be using a regexp to
remove whitespace, or something similar).
The way that regexps are designed is (to some extent) counter-intuitive - in
the sense that the pattern '1234' can match a string of any length. However,
this is well understood, and any semi-experienced programmer will
automatically add '^' and '$' assertions into their pattern as required.
However, in the 'form validation' case, you're providing a pattern that the
form control must match, completely, in order to be valid. There's a much
more common use case involving validation of the entire control, compared to
validating that part of the control matches a given pattern (a substring
Regarding the historical angle, there's certainly an argument that today's
HTML coders might have more familiarity with ECMAScript pattern matching
than with other 'forms designer' tools. However, the two operations -
'writing validation script' and 'writing HTML' - exist (in my mind, at
least) in different contexts, and so I don't think that using a different
method (substring vs. whole-pattern matching) for the two is particularly
confusing, especially when (with the current design) mistakes are
Consistency is a good argument, but in this case, I think specialising the
design to cover the problem area (and therefore introducing a lack of
consistency) makes for an easier-to-use (and less prone to failure) design.
I hope that's understandable - it's all a bit woolly, I'm afraid!
More information about the whatwg