[whatwg] comments on Web Forms 2.0, 27 June 2004
ian at hixie.ch
Sun Aug 22 15:02:47 PDT 2004
On Thu, 5 Aug 2004, Mark Nottingham wrote:
> * 1.6 Conformance Requirements -- Web Forms says that conformance is
> indicated by RFC2119 terms, but doesn't use any AFAICT; while there are
> many lower-case must, may and should's in the document, they need to be
> uppercase to qualify as requirements.
Why do they need to be uppercase?
> * 1.6 Conformance Requirements, paragraphs 7 and 8 -- What is the
> significance of "over HTTP" for the media types; does this imply that
> they may be served with different media types over other protocols?
Changed it to "over the wire (e.g. by HTTP)".
> * 2.1 Extensions to the input element (no impact on this specification)
> -- I understand the WG intends that CSS dictate the presentation of the
> various controls (e.g. a clock vs. a text field for date entry). When
> doing so, I'd ask that consideration be given to the possibility for
> alternate, user-selectable modes on the same form; e.g., I as a user may
> want to override the clock method of entry for a particular form, so
> that I can use the text field mode, even though the CSS specifies a
User stylesheets would be definitely be well suited for that sort of
> * 2.1 Extensions to the input element, last paragraph -- "The size
> attribute of the input element is deprecated in favour of using CSS to
> specify the layout of the form." This approach isn't used elsewhere
> (i.e., AFAICT, other similar situations don't result in deprecation).
I'm not aware of any similar situations.
> Also, what is the force of deprecation WRT conformance?
Nothing at this stage; however, it is presumed that a future version of
the specification (HTML6, maybe) would remove the attribute altogether.
> * 2.1.1 Ranges -- "values allowed by the above types" --> "values allowed by
> some of the above types"
> * 2.1.2 Precision -- "fractional number" --> "decimal number"?
A "decimal number" is just an number in base ten. The intent here is to
specifically allow numbers that are not integers.
> * 2.12 The autocomplete attribute -- Nothing is said about the scope of
> completion when the value is "on"; e.g., is a value on form on
> http://www.example.com/foo able to be used for completion for a form on /bar?
The exact mechanism is now explicitly undefined.
> * 2.16 Handling unexpected elements and values, second paragraph -- if
> you want this specification to be taken seriously, please act
Given the subject of that section, that _is_ serious, as any seasoned UA
implementor or QA engineer can attest.
> * 2.16 Handling unexpected elements and values, "For parsing errors in
> HTML" -- giving advice to reverse-engineer products may not be wise
> (IANAL) and certainly isn't good practice for specifications, even if it
> is realistic.
Being realistic is good practice for specifications. It's certainly better
than pretending that everything is well-defined or that UAs can do
whatever they want.
> * 2.16 Handling unexpected elements and values, last paragraph -- How should
> this be tested? Seems like a recipe for interoperability problems.
I'm not sure which paragraph you are referring to.
> * 2.4 Extensions to the textarea element -- it would be interesting if a
> media type for the textarea could be specified; e.g., if it were
> "text/html" the textarea would become a HTML editor, or a rich text
> editor for "text/rtf".
Good idea; we will look at this in more detail for Web Forms 3.0.
> * 5.6 Submitting the encoded form data set -- Have the consequences of
> making method fall back to GET been considered, WRT phasing in new
That's just describing existing behaviour, I think
> I don't have a strong preference here, but the issues may be subtle. In
> the event that the current approach is kept, it should be made explicit
> that the actual method remains what is specified, rather than changing
> to GET, so that no information is lost.
Not sure what you mean by this.
> * 5.6 Submitting the encoded form data set -- "resource is fetched" -->
> "representation is fetched"
> * 6.2 Seeding a form with initial values -- it's not good practice to
> put a requirement ("should not") in a note.
It's not a requirement, since it is in a note. It's just advice.
Maybe it should be made normative, though. Any preference?
Thanks for your input!
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg