- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 13 Apr 2005 12:50:28 +0000 (UTC)
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 already. > - 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. > - the "javascript:" scheme in form submissions 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 > load 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 different. > 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 > specification. 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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 13 April 2005 05:50:28 UTC