[whatwg] comments on Web Forms 2.0, 27 June 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 
> clock.

User stylesheets would be definitely be well suited for that sort of 
thing.


> * 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"

Fixed.


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

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 
> methods?

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"

"representation"?


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

Received on Sunday, 22 August 2004 15:02:47 UTC