W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] Re: BNF documentation for validated input types

From: Brian Wilson <brian@opera.com>
Date: Mon, 30 Aug 2004 12:46:03 +0200
Message-ID: <opsdjj61kq87i379@toshistation2.oslo.opera.com>

I wrote:
> When reading through the section on the new INPUT types, and trying to 
> follow the prose descriptions of what characters are allowed/notallowed,  
> I found myself wishing for a terse BNF string to reference.Perhaps  
> prose-alone was chosen for a reason, but implementers - as wellas some  
> of us spec monkeys - have gotten used to BNF notation for ano-nonsense  
> way of making sense of validity domains. Perhaps this can beadded to the  
> prose descriptions?

Then Ian replied:
> I've added this to the wishlist. I'm reluctant to do it right now since  
> itwould be quite a lot of work and might introduce contradictions.
> In general the allowed values are pretty obvious when you think about it.
>Would BNF-like syntax realy be that much better?
>   <number> ::= '-'? <integer> [ '.' <integer> ]? [ 'e' '-'? <integer> ]?
>   <integer> ::= [ '0' .. '9']+
>   <time> ::= <digit> <digit> ':' <digit> <digit>
>              [ ':' <digit> <digit> [ '.' <digit>+ ]? ]?

Ok. Point taken. 8-D I hadn't really reflected on how truly bulky strict  
BNF definitions would be.

As a possible alternative, since pattern attributes are defined using  
ecmascript-ish regexps, perhaps the strictly-patterned input types could  
be as well.

I'm pretty sure the following are correct for the time-related types. I'm  
not sure what the exact regexps would be for email and uri though, and the  
number/range ones will require some interesting expressions too:

If I've missed anything on these, someone please modify.

Hmm. Those aren't as "pretty" as I'd hoped they'd be (too many repeating  
regexp patterns can be confusing.)

Anyway, just a possible idea for an addition.


Brian Wilson
Opera Core QA
Received on Monday, 30 August 2004 03:46:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC