[whatwg] Web Forms 2.0 Substantial - Section 2

Ian Hickson ian at hixie.ch
Tue Jun 22 05:42:37 PDT 2004

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.


> # 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


> 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.


> 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.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list