- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 22 Jun 2004 12:42:37 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 22 June 2004 05:42:37 UTC