[whatwg] Web Forms 2.0 Substantial - Section 2

[Ian Hickson]

On Tue, 15 Jun 2004, fantasai wrote:
>
> # The formats described below are those that UAs must use when submitting the
> # data. They do not necessarily represent what the user is expected to type.
> # User agents are expected to show suitable user interfaces for each of these
> # types. It is the UA's responsibility to convert the user's input into the
> # specified format.
>
> Add a note about local-specific time and number formats, so UAs don't
> overlook that as part of the "suitable user interface" expectation.

Added.


> # expdate
>
> Should be more generic, e.g. 'month'. Here's an example of a non-expiration
> date using that same format:
>
> http://admissions.rutgers.edu/html/preview/preview8.htm

Changed.


> 2.2. The output element
> -----------------------
>
> You need to explain the interaction of textContent, defaultValue, value, and
> the actual element contents better.

Done. Let me know if that is better.


> Also, note somewhere that resetting the form doesn't *exactly* reset the output
> to its original state.

Done.


> 2.3. Extensions to the select element
> -------------------------------------
>
> # UAs must not use a UI that artificially restricts the allowed characters.
> # For example, commas should be allowed in the submission text.
>
> UA should be allowed to use a UI which prevents the input of newlines.
> Otherwise it's just *really awkward* -- and selects can't handle newlines
> now anyway.

I've removed that entire paragraph. It was a remenant of the text talking
about editable multiselects.


> 2.5. Extensions to file upload controls
> ---------------------------------------
>
> # The maxlength attribute applies to file upload controls.
>
> How? (Yes, I know this is defined elsewhere, but it belongs here, too.)

There's a hyperlink in that sentence for a reason. Equivalents of that
sentence appear in several places, specifically so that I could define it
all in one place.


> 2.7. Extensions to the submit buttons
> -------------------------------------
>
> I think I mentioned this under Editorial, but it belongs here, too.
>
> # For this reason, the following attributes are allowed on submit buttons:
> # action, method, enctype, replace, and target. When not specified, their
> # values default to the values given by their form element.
>
> Explain what exactly you mean by the verb "default".

I can't find "values default" in the text anymore so I assume I already
fixed this.


> 2.9. The pattern attribute
> --------------------------
>
> # If the attribute is empty or omitted then it is equivalent to .*  (which,
> # with the implied start and end characters, becomes ^.*$), which matches
> # anything.
>
> I'm not too familiar with the details of ECMA regex, but I believe that
> pattern excludes newlines, which you do not want to do for <textarea>.

Good point. I used a regular expression pattern you hate instead...


> 2.12. The autocomplete attribute
> --------------------------------
>
> # All form controls except the various push button controls and hidden and
> # output controls
>
> Might want to define the "various push button controls" category somewhere.

I just listed the appropriate controls explicitly.


> 2.13.  The autofocus attribute
> ------------------------------
>
> # When a form control is inserted into a document, the UA must check to see if
> # it has this attribute set. If it does, then the UA must focus the control, as
> # if the control's focus() method was invoked. (When multiple elements are
> # simultaneously inserted into the document, they must all perform this, in
> # document order.)
> #
> # During document load, the last form control with this attribute set is the
> # one that should have focus once the document is loaded.
>
> I'm wondering if the last paragraph is implied by the first.

Yes. Clarified.


> Also, you should put something to the effect that
>    There should only be one [non-disabled] form control with "autofocus"
>    per document.
> to discourage authors from having multiple autofocus elements. IMO, the
> multiple elements handling should be considered error-handling.

Fair point.


> Also, support for this attribute should be optional, and ignoring it
> based on what the user is currently doing (e.g. typing into another form
> field) should be allowed. "Autofocus" should be a hint, not a mandate.

It's only a "should", and ignoring in specific scenarios is allowed.


> 2.16. Handling unexpected elements and values
> ---------------------------------------------
>
> # Unless otherwise forced to appear by a stylesheet, other child nodes are
> # never visible.
> ...
> # rendering the initial value only, with the rest of the content not displayed
> # (unless forced to appear through some CSS)
>
> Forced to appear how? By what CSS?

CSS3 'content', for instance.

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