[whatwg] Form Validity Ambiguity - patternMismatch

[Ian Hickson]

On Mon, 19 Apr 2010, Joseph Pecoraro wrote:
>
> The section describing the pattern attribute does not explain that it 
> only applies to particular input types.
> 
> However, one of the tables showing which content attributes apply to 
> which input types shows the pattern attribute only applies to particular 
> input types. Namely text, search, url, telephone, email, and password 
> but not dates, times, numbers, hidden and others:
> 
> This disconnect could lead to ambiguous implementations of 
> ValidityState's patternMismatch which is simply described in multiple 
> places as:
> 
>   [[
>     When a control has a value that doesn't satisfy the pattern
>     attribute.
>   ]]
> 
>   [[
>     returns true if the element's value doesn't match the provided
>     pattern; false otherwise.
>   ]]
> 
> These two definitions of patternMismatch do not mention that they only 
> apply on input type's that the pattern attribute applies to.

These two definitions are non-normative. They're just meant to provide a 
basic introduction to the features in question.


> If that is the case then I recommend clarifying that constraint in the 
> description of the pattern attribute and when describing 
> patternMismatch.

I don't see what's ambiguous. The only place in the spec that has a 
normative statement regarding whether something is "Suffering from a 
pattern mismatch" is the section on the pattern="" attribute, and that 
section is a subsection of a section that says "These attributes only 
apply to an input element if its type attribute is in a state whose 
definition declares that the attribute applies. When an attribute doesn't 
apply to an input element, user agents must ignore the attribute, 
regardless of the requirements and definitions below.".


On Tue, 20 Apr 2010, Mounir Lamouri wrote:
> 
> Actually, if you are looking for something more normative (the table is 
> non-normative), at the end of each input element states description, you 
> can found the list of attributes which apply/don't apply. AFAIK, the 
> attributes/methods never mention in which states they apply. I suppose 
> it is to prevent mentioning things twice thus doubling the needed 
> changes and the chances of incoherence/mistakes.

Indeed.


On Tue, 20 Apr 2010, Joseph Pecoraro wrote:
> 
> You're correct! Thanks for pointing out that section. I still think this 
> could be clarified. I feel that a majority of the time someone is going 
> to read patternMismatch and say "oh, I just need a pattern attribute" 
> and not think to check that the pattern attribute only applies to 
> particular types.

The types for which it doesn't apply are types where it doesn't make much 
sense to apply it; basically anything where the user isn't going to be 
typing raw text. I guess we can add a non-normative note to the top of 
each attribute's section saying to what it applies, but doing that would 
be a pain... if anyone can provide a script that scrapes the source 
document to determine what states each attribute applies to, and then has 
some way to update the generated source to have the right information, I'd 
be happy to add it to the pipeline. Contact me off-list if you're 
interested in helping with this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'