[whatwg] Re: pattern attribute

[Malcolm Rowe]

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 
match). 

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 
highlighted immediately. 

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! 

Regards,
Malcolm