[whatwg] RE: pattern attribute

[Wrigley, Ave]

> 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! 

Yes - entirely, and I think I broadly agree with you. I suppose my
discomfort is that the value of the pattern attribute is essentially
defined as "a regex, but not quite ...". This is probably because I have
a strong preconception of what a regex is, and a feeling that there are
too many variants on regexes already (not to mention what is happening
with pattern matching in Perl 6)! Still, I think your use case example
probably overcomes this.

Incidentally - do you have any views on regex modifiers?

Ave.
This email (and any attachments) is intended solely for the individual(s) to whom addressed. It may contain confidential and/or legally privileged information. Any statement or opinions therein are not necessarily those of ITN unless specifically stated. Any unauthorised use, disclosure or copying is prohibited. If you have received this email in error, please notify the sender and delete it from your system. Security and reliability of the e-mail and attachments are not guaranteed. You must take full responsibility for virus checking.



Independent Television News Limited, 

Registered No. 548648 England,

VAT Reg. No: GB 756 2995 81, 

200 Gray's Inn Road, London WC1X 8XZ,

Telephone: 020 7833 3000.