[whatwg] [wf2] 2.3. Changes to existing controls

On Sun, 23 Oct 2005, Anne van Kesteren wrote:
>
> # Form controls by default associate with their nearest form
> # ancestor.
> 
> Could this sentence be made more normative? That it actually is a 
> requirement unless the control has a 'form' attribute specified. That in 
> that case the rules for that apply.

The sentence is a definition, not a conformance criteria. The conformance 
criteria are the ones that state what should happen to form controls 
relative to their forms.

There are three kinds of statements in specifications that use RFC2119:

 1. Normative requirements.
 2. Definitions that make the normative requirements easier to read.
 3. Informative statements that make the definitions easier to read.

The first set are the ones that say MUST, SHOULD, OPTIONAL, SHALL, etc.

The second set are the ones that make statements of the form "X is Y when 
Z" or some such. The sentence above is of this form (sort of): The "X" is 
"a form control", the "Z" is "not specified otherwise (by default)" and 
the "Y" is "associated with its nearest form ancestor".

The third set are statements that explicitly state the result of following 
normative criteria, as well as examples and notes.


> # The label element's exact default presentation and behaviour
> # should match the platform's label behaviour. For example, on
> # platforms where clicking a checkbox label checks the
> # checkbox, clicking a label element must cause a click event
> # to be synthesised and fired at the checkbox.
> 
> First 'should', later 'must'. Please change either one of them.

Fixed.


> # No click event is fired in this case.
> 
> "must be fired"?

This is, using my categories above, a "type 3" statement. It is stating a 
fact. If you follow the specification, then nothing causes you to fire a 
click event, thus, no click event is fired in that case.

Specifications don't use normative criteria to say what UAs should _not_ 
do because if they did they would be full of statements like "and on the 
third full moon of a year, the UA must not ignore the foopy attribute. And 
on the fourth full moon of a year...".

Basically, unless a spec says to do something, the UA musn't do it.


> # so that if the value content attribute is not specified then
> # the value DOM attribute (and the value used for submission
> # when the controls are checked) is "on".
> 
> Could you perhaps add that setting the value content attribute to the 
> empty string must not be considered differently from setting the value 
> content attribute?
> 
> Note that in order to do that you would also have to change section 2.4 
> which states that setting value to the empty string means "no value 
> selected". That would result in the value used for submission being "on" 
> which is not what user agents currently do, or are supposed to do. 
> value="" should not result in the value DOM attribute being "on", but 
> "".

Your two requests here seem to contradict each other. Could you clarify?


> # Whitespace must also not be trimmed from any other attributes
> # (e.g. the value attribute).
> 
> Could you add a note that there is some form of normalization applied to 
> these attributes in XML documents as described here: 
> <http://www.w3.org/TR/REC-xml/#AVNormalize>. This could be helpful and 
> would prevent confusion.

That XML rule only applies to validating parsers and to parsers exposed to 
internal subsets, IIRC. Since it is not expected that WF2 documents will 
be exposed to DTDs of any kind, that does not seem a helpful note. Could 
you expand on why it would be helpful?

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

Received on Sunday, 23 October 2005 12:04:15 UTC