- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 11 Jul 2005 03:28:54 +0000 (UTC)
On Sun, 10 Jul 2005, Boris Zbarsky wrote: > > It's not clear what happens in XHTML when a non-empty form is placed in > the head. That is, is emptyness a conformance requirement for authors > or UAs, and what are UAs expected to do about it? Already defined in section 2.18. It seems clear that this is an authoring requirement, since it says that the form element "is allowed", not "user agents must" or similar. > It's not clear what should happen if the constraint in the paragraph > starting with "The children of a form element must be block-level > elements" is violated. Is this constraint to be enforced by UAs (if so, > how), or by authors (if so, what are UAs expected to do if it's not?). Again, the statement seems to me to be clearly an authoring requirement (it's a statement made about the content model of the element), not a user agent requirement. There is no user agent requirement here. The user agent processing requirements are independent of whether the document is valid or not. (This is, or will be, made much clearer in HTML5.) Added a section to 2.18 to cover this vaguely. > The specification says: "In any case, events targeted at form controls > within a label must not be handled by the label itself." What about > links within a label? What about nested labels? Added a section to 2.18 to cover nested labels. Rephrased the quoted text above to cover links as well. > The section on implicit submission does not talk about firing click > events, if any, on the submit button. IE does this in some cases > (though not others), and web sites depend on them being fired when IE > does fire them.... Can you elaborate? > 2.4: > > ISO8601 claims to be a "Withdrawn standard". Is this an issue? What is it withdrawn in favour of? Do you know? > If I understand correctly, Week 1 of a year may contain some days from > the previous year, right? If the last day of a year is a Monday, will > the week containing it be considered Week 1 of the next year, or Week 53 > of the current year, or both? None of this is very clear to me from the > text... Clarified. > Controls with no default value specified are supposed to have no value > selected. At the same time, the widget types recommended for rendering > the control (eg the clock recommended for time) do not lend themselves > well to having no value selected. They lend themselves even less to > having a value unselected (the equivalent of a user clearing a text > control completely), and it's not clear whether UAs may, should, must, > should not, or must not allow form control values to be cleared by the > user. Added a paragraph regarding this. > The terms "no value selected" and "left blank" are used interchangeably > here, it seems. Perhaps it would be good to settle on one of the terms > (and define it somewhere)? Changed the one occurance of "blank" in this context to "no value selected" and defined the term. > "Empty fields (those with no value) do not need to match their type." -- > it's not clear what this means. Does "no value" mean the same as "no > value selected" or "left blank"? Clarified. > What does it mean for a field to "match its type"? Clarified. > What happens to selected values when the type of a form control is > changed? Should the UA attempt to perform some sort of conversion to the > new type? Clarified. > What happens to selected values when the min/max/step attributes of a > form control are changed? Should they be coerced to the closest valid > value? Note that there may be cases when the selected value can no > longer be shown using the widget that shows the control's value (eg a > range control's max may be changed to be less than the current slider > position). This is already covered by 2.18, but added a parenthetical in 2.18 to be explicit about that case, and made earlier sections link to it. > What happens if the 'value' DOM attribute is set to a string that's not > in a valid format for the control type? Covered by 2.18. > What happens if the 'value' DOM attribute is set to a string that's out > of range given the min/max attributes on the control or isn't an > integral number of steps from the min or max? Note that there may be > cases when the widget being used for the control can't show the > out-of-bounds value (eg it's a range slider). Covered by 2.18. > 2.4.1: > > "A field with a max less than its min can never be satisfied when it has > a value" -- there is no definition of "satisfied" in this specification. Changed the words "be satisfied" here to "fulfill both conditions". > What happens to the default min/max values if the form control type is > changed? Clarified. > 2.4.2: > > Description of 1970-W01 should probably talk about 1970-01-04, not 1970-01-01. The key point is that it contains 1970-01-01. If it had been 1969-W53 that contained it, then that would have been the zero point instead. It's just lucky that the 1970-W01 week contains both 01-01 and 01-04. > What happens if the step of a number or range control is set to a > nonpositive number? Is this treated as if step were not set? If so, > that's not obvious from the text here. It is explictly stated: "For numeric controls (number and range), ... the value must be greater than zero. The default value is 1. ... If the given step value is not one of the allowed values, then the default is used." > If the UA rounds to the nearest allowed value, does that mean "allowed > by step and within the min/max constraints"? In other words, given > <input type="number" min="0" max="99" step="15">, what should 98 be > rounded to? 105, 90, or something else? Clarified. > I'm not sure what to make of the recommendation for doing comparisons in > string form when dealing with number types or with step. It sounds > pretty complicated to get right for those cases... It's not a requirement, merely a suggestion (albeit a "recommended" one). > If a fieldset is disabled, does that affect the value of the DOM > attribute disabled on descendant form controls? Or just their visual > appearance and behavior? Defined in 7.8. > Implementing maxlength efficiently on textarea as described (esp. for > the wrap=hard case) is likely to be somewhat difficult. I don't really > have a decent suggestion on how this can be improved, but I fully expect > uses to start complaining that typing in textareas with maxlength set is > slow (with the display lagging behind the user), especially if the > maxlength and the total text are both large. The number of characters N in the value is easy to determine O(1). The number of newlines M in the value is easy to determine O(N), easily caching to O(1). The number of lines L in the output is something you have to know anyway to render it (or to render the scrollbar). The number of characters in the submission is N - M + L*2. I don't see the problem. > There have been repeated bugs filed on Mozilla to support readonly on > radio and checkbox inputs (authors want the inputs to be successful but > not allow the user to modify the value). This is not to say that Web > Forms should allow this, necessarily, but it's worth considering.... It has been raised many, many times. The concept of a read-only radio button is something that makes no sense, IMHO. I have been considering saying that if you have a read-only radio button it should render as a completely different thing, though (e.g. render as an obviously non-interactive non-control label). This won't make WF2, however. Maybe WA1 or WF3. > I'm not sure what the clause "the interface concept of 'readonly' values > does not apply to button-like interfaces." means. It means that having a read-only button makes no sense. I don't understand what you don't understand. :-) > I'm not sure what the sentence "The DOM readonly attribute ([DOM2HTML]) > obviously applies to the same set of types as the HTML attribute." means > -- the DOM attribute simply reflects the current HTML attribute value, > no? Or is this sentence trying to say something stronger? Good question. I've commented it out for now. Does "foo.readonly" really just reflect the content attribute in implementations or does it only return true for controls that can be disabled? Updated spec at: http://whatwg.org/specs/web-forms/current-work/ There is a diff between this version and the version from a week ago at: http://whatwg.org/specs/web-forms/current-work/diff-2005-07-03 Thanks for your comments so far! -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 10 July 2005 20:28:54 UTC