Call four comments 4 is out (Was: [whatwg] Web Forms 2.0 submission to W3C)
ian at hixie.ch
Wed Apr 13 05:50:28 PDT 2005
On Wed, 13 Apr 2005, Olav Junker Kjær wrote:
> Some feature in WF2 for which the use cases are not immediately obvious:
> - the output element and the readonly attribute. Its not obvious why we
> need both, and when you should use which.
I have added a usage note in the <output> section to help answer this.
> - the form attribute. (The use case in the spec seem a little contrived)
I agree that the second example is contrived, it's just showing edge
cases. The first example, however, is the use case for the form=""
attribute. I don't see what I could add to the spec to make this clearer.
> - the _charset_ field
Added a section with a brief paragraph explaining this.
> - step attribute on range
This seems obvious. It has the same use case as on other inputs: it
changes the allowed numbers. So for example if you want your <input
type="range"> control to return numbers that are multiples of 2, you can
set step="2". I've added this example to the spec.
> - step attribute on date
Again, this seems obvious. Say you want only Mondays. You set the min=""
to a Monday, then set step="7". There is an example of this in the spec
> - list attribute on range
This could be useful if there are values along the full range of the
control that are especially important, such as preconfigured light levels
or typical speed limits in a range control used as a speed control.
I've added this sentence to the spec.
> - the data-scheme in form submission (debugging has been mentioned as a
> use case, but its not obvious from the spec)
Added a usage note saying debugging is the main use case.
Added a usage note.
> - the "file:" scheme; post, put and delete methods
Added a usage note.
> - file upload
This is to make PUT actually work, mainly. Added a parenthetical comment
to the bit that first mentions this.
> - changing data attribute on a select element several times during page
There's no use case for this. It just has to be defined so that we get
interoperable behaviour, otherwise every UA will end up doing something
> Use cases are useful not just to justify features, but also as
> documentation of the intention of the spec. Often I understand a feature
> better by reading the use case, rather than by reading the precise
That makes sense. Let me know if there are any parts of the spec you still
think could do with more of this explanatory text. (Or if any of the text
I mentioned above is not enough.)
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg