- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Sat, 1 Jan 2005 14:47:11 +1300
On 10 Dec, 2004, at 10:14 PM, Ian Hickson wrote:
>
> Comments on the second stable draft of the Web Forms 2.0 specification
> are encouraged.
> ...
These suggestions and questions are based on the 26 December 2004
working draft, rather than on the call for comments. Many of the
suggestions are editorial; in those I have tried to confine myself to
howlers and confusing language, rather than commenting on every
redundant phrase (e.g. "the context of the").
For easy reference, the non-editorial items are these:
7. Is <option> a "form control"?
8. Recommendation against noticably empty form controls
9. Nested <form>s, and <form>s in <head>, in HTML
10. <div> ancestor not allowing <form>'s children to be inline
13. Submitting a form as if there was an enabled default button
14. Support of accesskey= for <select>
26. autofocus= and platform variability of focusability
32. max="any"
40. Placement of newly-created repetition blocks
42. "move" instead of "move-up" and "move-down" (includes algorithm for
drag-and-drop of repetition blocks)
43. Optionally ignoring "add" and "remove" button contents
48. Filenames submitted for devices without filesystems
49. Dataloss of "+" vs. " " in form submission
51. stepUp() and stepDown() where step="any"
53. Use of term "deprecated"
55. JavaScript reference URI
> ...
> Previous versions:
>
> http://www.whatwg.org/specs/web-forms/2004-12-10-call-for-comments/
> (diffs)
1.
<http://www.whatwg.org/specs/web-forms/current-work/diff-2004-12-10-
call-for-comments> is an empty document.
> ...
> 1. Introduction
> ...
> Authors have long requested enhancements to HTML4 to support some of
> their more common needs. Such comments in mailing lists and other
> forums were examined, and from these sources a set of requirements and
> design goals were derived:
2. The misleading Slashdot post of yore lingers as HTML comments in the
spec for no apparent reason. And now that it is no longer in the
visible text, the final sentence refers to "such comments" not
previously introduced.
* "such comments" --> "such requests"
> ...
> * Dynamic addition of more fields (repeating structures) on the
> client side without scripting.
3. Grating redundancy.
* "addition of more" --> "addition of"
> ...
> * Few dependencies: this specification should stand alone and not
> require support for other technologies such as XPath, XMLSchema, or
> XML Events, as these are not implemented in typical Web browsers
> and requiring them would significantly delay the time required to
> deploy browsers supporting this specification.
4. You can delay an event, but you can't delay a time.
* "delay the time required to deploy" --> "delay the release of"
> ...
> Relationship to HTML
> ...
> Relationship to XHTML
> ...
> Relationship to XForms
> ...
> Relationship to XForms Basic
5. "relationship", "relationship0", relationship1", and
"relationship2" are poor IDs for these headings. If a Web Forms
2.1, 2.2, etc reorders, adds to, or removes some of these sections,
either the numbers will become out of order, or links to the other
sections from elsewhere on the Web will break.
> ...
> 1.7. Conformance requirements
> ...
> Diagrams, examples, notes, and sections marked as non-normative are
> non-normative. All other content in this specification is normative.
6. This could easily be misinterpreted distributively (diagrams marked
as non-normative + examples marked as non-normative + notes marked
as non-normative + sections marked as non-normative).
* "As well as those sections marked as non-normative, all
diagrams, examples, and notes in this specification are
non-normative. Everything else in the specification is
normative."
> ...
> 1.8. Terminology
> ...
> The term *form control* refers to input, output, select, textarea and
> button elements. It does not include form, label, datalist or fieldset
> elements.
7. <option> probably should be included in one of these lists.
> ...
> 2.3. Changes to existing controls
> ...
> Specifically, the form, legend, select, and optgroup elements may now
> be empty.
8. * "However, with the exception of the form element, authors should
avoid allowing any of these elements to be both empty and
visible for any noticable period, as it is likely to confuse
users."
> Also, as controls no longer need to be contained within their form
> element to be associated with it, authors may prefer to declare their
> forms in advance, at the top of their documents. The form element is
> therefore allowed in the head element of XHTML documents, although
> only when the form element is empty. (This does not apply to HTML.)
>
> Similarly, form elements in XHTML may now be nested (this does not
> apply to HTML).
9. Why don't these apply to HTML? The explanation of the former is
buried waaaay down in a parenthesis in section 2.18. There doesn't
seem to be an explanation of the latter at all. It would be nice if
these were explained more promptly.
> ...
> The children of a form element must be block-level elements, unless
> one of the ancestors of the form element is a td, th, li, dd, or
> block-level element other than div, in which case either block-level
> or inline-level content is allowed (but not both).
10. Why the exception of <div>?
> ...
> Authors are recommended to always have one radio button selected.
> Having no radio buttons selected, or more than one in a group
> selected, is considered very poor UI.
11. Why mention "or more than one in a group selected"? UAs don't even
allow that (at least, not in standard HTML), so there's no point
raising the possibility. In any case, these sentences belong at the
end of the previous paragraph.
> ...
> The first submit button in a form is the form's default button.
> ...
> If there is no default button, then the implicit submission mechanism
> must submit the form as if there was an enabled default button.
12. It would be more of a logical counterpart to the first sentence to
say "If there is no submit button".
13. To submit a GET form "as if there was an enabled default button",
the UA needs to include the value of the button in the submission
URI. But how is the UA to know the value of a button that doesn't
exist?
> ...
> 2.5. Extensions to existing attributes
> ...
> UAs must now support the accesskey attribute on select elements.
14. First, this renders the Web Applications 1.0 draft text "Support for
the accesskey attribute is optional" substantially irrelevant -- the
only way of implementing both Web Forms 2.0 and Web Applications 1.0
would be to support the accesskey attribute, making it not optional.
Second, this removes the ability of a UA implementor to implement
type-ahead find as a more reliable (since some authors will specify
accesskeys and some won't) and quicker (especially if the number of
items in the menu is large) way of selecting an item with the
keyboard. And third, this inhibits UAs from following platform
interface conventions; for example, while some Mac OS programs use
accesskeys for buttons, checkboxes, and radiobuttons, doing so for
menus is very non-standard behavior (I think I have only seen one
program ever do so).
> The accesskey attribute on label elements must act the same way as
> they would have if specified on the associated element directly.
15. * "they would have" --> "it would"
> disabled
>
> The disabled attribute applies to all form controls except the
> output element, as well as the fieldset element.
16. This could be interpreted as meaning that the disabled atribute
applies to <fieldset>, *or* that the disabled attribute does not
apply to <fieldset>.
* "as well as" --> "and also to"
> ...
> maxlength
> ...
> Authors are encouraged to only use maxlength on uri and email
> fields if the server side processor actually has a limit on the
> size of data fields it can usefully process.
17. "Only use maxlength" implies "use maxlength and no other
attributes", which is not what you mean.
* "only use maxlength on uri and email fields if" -->
"use maxlength on uri and email fields only if"
> ...
> The ERROR_TOO_LONG code is used when this attribute is specified on
> a text, password, uri, email or textarea control and the control
> has more than the specified number of characters, or when it is
> specifies on a file control and at least one of the selected files
> is longer than the specified number of bytes.
18. * "specifies" --> "specified"
> ...
> readonly
> ...
> Specifically, it does not apply to radio buttons, check boxes, file
> upload fields, range controls, select elements, or any of the
> button types; the interface concept of "readonly" values does not
> apply to button-like interfaces.
19. "Checkbox"/"checkboxes" and "check box"/"check boxes" are used
seemingly at random throughout the spec (sometimes both in the same
sentence). Pick one spelling and stick to it. (I don't remember
seeing "check box" previously, but maybe I hang out with the wrong
people.)
> ...
> 2.6. The pattern attribute
> ...
> For example, the following snippet:
> <label> Part number:
> <input pattern="[0-9][A-Z]{3}" name="part"
> title="The expected format is: a digit followed by three
> uppercase letters."/>
> </label>
>
> ...could cause the UA to display an alert such as:
>
> The expected format is: a digit followed by three uppercase
> letters.
20. I dread the thought of any author reading the spec (or reading a
tutorial written by someone who has read the spec, etc) and thinking
that "The expected format is:" should be standard text for their
title=s!
* "The expected format is:" --> "A part number is"
21. It should be clarified that UAs may still show the title= in
non-error situations (for example, as a tooltip when hovering over
the control), so a title= should not be worded as if an error has
necessarily occurred.
> 2.8. The form attribute
> ...
> The form attribute gives a space-separated list of IDs of form
> elements that the form control is to be associated with, and overrides
> the relationship between the form control and any ancestor form
> element.
>
> Any of the IDs in the space separated list that do not identify an
> element in the document, or that identify an element that is not an
> HTML form element, must be ignored.
22. Pick "space-separated" or "space separated", and stick to it. (I
find the former less ambiguous.)
> ...
> 2.8. The form attribute
> ...
> In other words, form controls must be associated with the forms given
> in their form attribute, or, if they don't have one, must be
> associated with the nearest ancestor form element or the forms given
> in the form attribute of the nearest fieldset element with a form,
> whichever is the nearest. If none of those apply, the form control is
> not associated with any form.
23. * "element with a form" --> "element with a form attribute"
24. I had a go at making this paragraph less brain-frazzling.
* "In other words, a form control belongs to the form or forms
given by its form attribute. If it doesn't have a form
attribute, it belongs to its nearest ancestor form element, or
to the form or forms given by the form attribute of its nearest
ancestor fieldset, whichever is the nearer ancestor. If the
control doesn't have such an ancestor either, it belongs to no
form at all."
> ...
> If a form is specified multiple times in the form attribute, all
> occurances but the first are ignored.
25. * "occurances" --> "occurrences"
> ...
> 2.10. 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, and if the control is
> not disabled, then the UA should focus the control, as if the
> control's focus() method was invoked.
26. What if the control is of a type that is not normally focusable on
the user's platform? For example, in OS X with "Full Keyboard
Access" turned off (as it is by default), only text fields (aka
<input type="text/password/date/time/etc"> and <textarea>) and
listboxes (aka <select multiple>) should be focused.
* "If it does, and if the control is not disabled," -->
"If it does, the control is not disabled, and it is of a type
normally focusable in the user's operating environment,"
* Perhaps further: "UAs with a viewport should also scroll the
document enough to make the control visible, even if it is not
of a type normally focusable."
> (When multiple elements are simultaneously inserted into the document,
> they must all perform this, in document order.)
>
> This implies that during document load, the last form control with
> this attribute set is the one that will have focus once the document
> is loaded.
> ...
> Authors should only mark one (non-disabled) control per document with
> the autofocus attribute.
27. All the sentences about multiple autofocused controls should be
together in their own paragraph.
* "Authors should avoid setting the autofocus attribute on
multiple elements in a document. If multiple non-disabled
elements with the autofocus attribute set *are* inserted into a
document, the UA should focus them sequentially in document
order. This means that during document load, for example, the
last form control with the attribute set will end up with
focus."
* If accepting suggestion 26 above, "last form control" --> "last
focusable form control".
> ...
> The value of the attribute, if set, should be autofocus.
28. "autofocus" here is linked to the attribute definition, which is
wrong, because you are referring here to the value rather than to
the attribute itself.
> ...
> 2.13. The output element
> ...
> Note the em element in the markup. It emphasises a part of the number.
29. Why is this notable? It doesn't seem at all relevant.
> 2.14. Extensions to the textarea element
>
> The rows and cols attributes of the textarea element are no longer
> required attributes. When unspecified, CSS-compliant browsers should
> lay the element out as specified by CSS, and non-CSS UAs may use
> UA-specific defaults, such as, for visual UAs, using the width of the
> display device and a height suitable for the device.
30. As I said previously
(<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-
July/001005.html> item 41), this appears to
recommend that UAs default textareas to being too wide to view
without scrolling (especially if there is something horizontally
adjacent to the textarea). If there is a way to remove this
implication without suggesting CSS support, please do so.
> ...
> hard
> The text is submitted with explicit line breaks, and in addition,
> line breaks added to wrap the text at the width given by the cols
> attribute.
31. * Either "line breaks added" --> "line breaks are added", or
"and in addition, line breaks" --> "and also with line breaks"
> ...
> 2.15. Extensions to file upload controls
> ...
> There is currently no way to specify an unlimited number of files may
> be uploaded. Authors are encouraged to consider what the practical
> limit actually is for their server-side script. For example, if the
> server uses an unsigned 16 bit integer to track file uploads, a
> suitable max value would be 65536.
32. Ehhhh. Why not just allow the value "any", as is done for step=?
> ...
> This is similar to straight-forward Web logging, or diary writing, but
> instead of submitting textual entries, one submits sound bites.
33. "Web logging"? Some old-fashioned newspapers refer to them as "Web
logs", but they're much more commonly "Weblogs". (See also
<http://en.wikipedia.org/w/index.php?
title=Talk%3AWeblog&diff=1399541&oldid=1283187>.)
> ...
> For textarea elements containing tags in HTML
> The tags should be parsed as character data, but entities and
> comments should be recognised and handled correctly. (This doesn't
> apply to XHTML.)
34. Why not?
> ...
> For option elements containing nodes other than text nodes
> ...
> How such markup should be rendered is undefined. Two possibilities
> are sensible: rendering the content normally, just as it would have
> been outside the form control; and rendering the initial value
> only, with the rest of the content not displayed (unless forced to
> appear through some CSS).
35. What does "initial value" mean? Does it mean "content preceding the
first non-text node"?
> While nesting a form inside a select control may look cool, it is
> extremely poor UI and must not be encouraged.
36. Offering a demo of it and saying it "may look cool" is perhaps not
the worst *possible* way of not encouraging it, but it's close. Post
it in your Weblog or something if you must, but it doesn't really
belong in a spec.
> ...
> 3.1. Introduction for authors
> ...
> In order to distinguish this row from a normal row, however, something
> needs to be added to the template to mark it as being a template.
> This is done using a repeat attribute:
> <tr id="order" repeat="template" >
> <td><input type="text" name="row[order].product" value=""></td>
> <td><input type="text" name="row[order].quantity" value="1"></td>
> </tr>
>
> To prevent an attribute from being processed in this way,
37. This note should be immediately after the description of the process
(i.e. before "In order to..."), otherwise "this way" is confusing.
38. * "an attribute" --> "a name or id attribute"
> put a non-breaking zero-width space character () at the
> start of the attribute.
39. * "attribute" --> "attribute value"
> ...
> The second way is by including an add button inside the template, so
> that when the template is replicated, the button is replicated into
> the resulting block. When such a button is pressed, the template is
> replicated, and inserted immediately before the block in which the
> button is found. For example, if there were add buttons in the rows of
> the example above, and someone pressed the button in the second row, a
> row would be inserted between the first row and the second row.
40. If the template is inserted before the block in which the button
is found, then the button itself (like the rest of its block) will
(in left-to-right text) move downward and/or rightward. This usually
won't matter mousewise, because a newly-created add button usually
will appear exactly where the just-clicked one was; but it will
still look odd in those environments where buttons are focusable --
because focus will appear to have jumped, as a result of a click, to
something that is nevertheless not under the cursor. If adding
several blocks consecutively, there may be more annoying effects for
accessibility aids, since the mouse is repeatedly encountering
newly-created buttons with identical text, rather than continuously
hovering over the same button.
Therefore, it would be better for the template to be inserted after
the block instead.
* "immediately before" --> "immediately after"
* "between the first row and the second" --> "after the second"
* "as the first argument, immediately before that node" -->
"as the first argument, immediately after that node"
> ...
> 3.2.2. Repetition blocks
> ...
> Repetition blocks that don't have an associated template are termed
> orphan repetition blocks. They can take part in the deletion and
> movement aspects of the repetition model, but not addition..
41. * "termed" --> "" (or why not "nouned"?)
* "addition.." --> "in addition."
> 3.3. New form controls
> ...
> move-up
> Moves the nearest ancestor repetition block up one.
> move-down
> Moves the nearest ancestor repetition block down one.
> ...
> 3.6.3. Movement of repetition blocks
>
> The two remaining button types, move-up and move-down, are used to
> move the current repetition block up or down the sibling repetition
> blocks.
>
> If a move-up or move-down button is activated, and the element has an
> ancestor that is a repetition block as defined above, then the
> nearest such ancestor's template movement behaviour is invoked in the
> relevant direction. (Specifically, in scripting-aware environments,
> the element's moveRepetitionBlock() method is called; for move-up
> buttons the argument is -1 and for move-down buttons the argument is
> 1).
> ...
> In addition, user agents must automatically disable move-up buttons
> (irrespective of the value of the disabled DOM attribute) when their
> repetition block could not be moved any higher according to the
> algorithm above, and when the buttons are not in a repetition block.
> Similarly, user agents must automatically disable move-down buttons
> when their repetition block could not be moved any lower according to
> the algorithm above, and when the buttons are not in a repetition
> block.
> ...
> 5.1. Successful form controls
> ...
> * Buttons of type button, reset, add, remove, move-up, or move-down.
> ...
> 7.7. Validation APIs
> ...
> * The control is not a button of type button, reset, add, remove,
> move-up, or move-down.
> ...
> 8.1. Relation to the CSS3 User Interface module
> ...
> :enabled
> ...
> (e.g. move-up buttons can be implicitly disabled in certain
> cases).
> :disabled
> ...
> (e.g. move-up buttons can be implicitly disabled in certain
> cases).
42. I propose that "move"
<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-
August/001634.html> be introduced now, instead of
"move-up" and "move-down". Unlike other late-proposed additions to
Web Forms 2.0, when "move" is introduced I am confident it will
rapidly make "move-up" and "move-down" obsolete, since they would be
both much less compact and much more annoying to use for moving a
block more than one place. It would be a shame if UAs had to support
permanently something which was used for such a short period.
<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-
August/001955.html>:
|
| Off hand, the main problem I see is how to define where the "row"
| is. For example, the template can just be an inline element. There
| could also be elements between the repeated rows.
Here is the UA algorithm for detecting whether a drag will move the
block "up" one place. Reverse and/or extend the appropriate elements
in this algorithm for dragging past the next block rather than the
previous one, and/or dragging over more than one place.
The usual case is vertically stacked blocks, as found (for example)
in iTunes playlists and in the Windows Start menu. Dragging above an
invisible line (C) running through the middle of the previous block
will move the dragged block up one place, while dragging below this
line will not. (It's slightly more complicated for the Start menu
where some items are folders that can be dragged into, but that
doesn't apply to repetition blocks.) A thick drop-line with reverse
arrowheads (D) is drawn while the drag is still happening, to
indicate what place the block will have once dropped if dropped at
the cursor's current position. Here, Block 3 is being dragged.
____________
[Block_1_____] [/] check (-)(+)##
>===============================< D area where dropping
____________ will move
---[Block-2-----]-[/]-------(-)(+)##---------------------------C
area where dropping
will not move
____________
[Block_3_____] [/] check (-)(+)##
Now, to generalize this for blocks that may be any shape, at any
position, possibly even overlapping. In the following, a block's
"center" has a naive definition of (x1+x2)/2,(y1+y2)/2, where
(x1,y1),(x2,y2) are the farthest extents of elements in the block.
Draw an invisible line from the center of the block being dragged
(A) to the center of the previous block (B). Draw another invisible
line perpendicular to this one (C), passing through the center of
the previous block (B). If the grippy (##) is dragged to the farther
side of this second line, dropping will move the block "up". As with
the previous example, the pending effect of the drag can be shown
with a drop-line (D). (Algorithm for placing the drop-line available
on request.)
Consider a diabolical example where each block is positioned to the
lower left of the previous block. Again, Block 3 is being dragged.
\
area where dropping \ ____________
will not move \ [Block_1_____] [/] foopy (-)(+)##
._______\_________________________,
______'""""""""\""""""""""""""""""""""""`D
[Block_2_____] [/B foopy (-)(+)##
__,--"' \
____________ __,--' \ area where dropping
[Block_3_____] [/A'foopy (-)(+)## \ will move
\C
This algorithm applies exactly as expected to the previous example
of vertically stacked blocks:
____________
[Block_1_____] [/] check (-)(+)##
>===============================< D area where dropping
____________ will move
---[Block-2-----]-[/B-------(-)(+)##---------------------------C
| area where dropping
| will not move
____________ |
[Block_3_____] [/A check (-)(+)##
And it applies to horizontally adjacent blocks just as well:
|
_________ v ________| _________
[Block_1__] (-)(+)## | [Block_2_B]-(-)(+)##---[Block-3-A] (-)(+)##
^ |
D |
area where dropping | area where dropping
will move | will not move
C
As a final bonus, replacing "move-up" and "move-down" with "move"
would make the spec simpler overall.
* "move-up
Moves the nearest ancestor repetition block up one.
move-down
Moves the nearest ancestor repetition block down one."
-->
"move
Allows reordering of the nearest ancestor repetition block
relative to its sibling blocks."
* "The two remaining button types, move-up and move-down, are used
to move the current repetition block up or down the [sic]
sibling repetition blocks." --> ""
* "If a move-up or move-down button is activated" -->
"If a repetition block is moved"
* "for move-up buttons the argument is -1 and for move-down
buttons the argument is 1" -->
"the argument is equal to the number of places the block is
being shifted -- negative if the block is being moved to precede
previous blocks, and positive if the block is being moved to
follow succeeding blocks"
* "In addition, user agents must automatically disable move-up
buttons (irrespective of the value of the disabled DOM
attribute) when their repetition block could not be moved any
higher according to the algorithm above, and when the buttons
are not in a repetition block. Similarly, user agents must
automatically disable move-down buttons when their repetition
block could not be moved any lower according to the algorithm
above, and when the buttons are not in a repetition block. This
automatic disabling does not affect the DOM disabled attribute.
It is an intrinsic property of these buttons."
-->
"In addition, user agents must automatically disable a move
control when it is not in a repetition block, or when its
repetition block can be moved in neither direction according to
the algorithm above. This disabling must occur irrespective of
the disabled DOM attribute, and does not change that attribute's
value."
* "button, reset, add, remove, move-up, or move-down" -->
"button, reset, add, remove, or move" (sections 5.1 and 7.7)
* "move-up buttons can be implicitly disabled" -->
"add buttons can be implicitly disabled" (two occurrences)
> ...
> When these new types are used with input buttons, the value attribute
> shall, if present, provide the button caption (although this may be
> further overridden by the stylesheet).
43. * "However, a user agent may ignore this attribute so as to render
buttons consistent with those performing equivalent functions in
the user's operating environment. For this reason, if nesting
repetition blocks, authors should position such buttons
carefully to make clear which block a button applies to."
That way, add and remove buttons can have their familiar rounded (+)
and (-) appearances on Mac OS X (probably using value+title combined
as a tooltip), while still having text captions on platforms where
add and remove buttons are less common.
> ...
> 3.4. The repeat-min and repeat-max attributes
> ...
> These two attributes have no effect on the repetition model when
> present on elements that do not have a repeat attribute with the value
> set to template.
44. "template" here is linked to the attribute definition, which is
wrong, because you are referring not to that attribute but to a
value of a different attribute.
> ...
> 3.7.1. Repeated rows
>
> The following example shows how to use repetition templates to
> dynamically add more rows to a form in a table.
45. Grating redundancy.
* "add more" --> "add"
> ...
> 5. Form submission
> ...
> 1. Step one: Dispatch the submit event.
46. * "event." --> "event"
> ...
> 5.2. Handling characters outside the submission character set
> ...
> ____________________________________________________
> || Warning |||||||||||||||||||||||||||||||||||||||||||
> | |
> | This form cannot handle some of the characters you |
> | have entered (including "?" and "?"). |
47. * '"?"). |' --> '"?"). |'
> ...
> 5.3. application/x-www-form-urlencoded
> ...
> 3. The values of file upload controls are the names (excluding path
> information) of the files selected by the user, *not* their
> contents.
48. In section 2.15, an accept= attribute is introduced for <input
type="file">, especially (but not solely) for "small devices that do
not have file systems and for which the only way of handling file
upload is to generate the content on the fly". What should such
devices use as a name for such a non-existent file?
> 4. Control names and values are escaped. Space characters are replaced
> by "+" (U+002B), and then non-alphanumeric characters are encoded
> in the submission character encoding and each resulting byte is
> replaced by "%HH", a percent sign (U+0025) and two uppercase
> hexadecimal digits representing the value of the byte.
49. Should this be written the other way around? This way round, space
characters and "+" characters will end up as the same "%HH" entity.
> ...
> 7.7. Validation APIs
> ...
> * The control does not have a repetition templates as an ancestor.
50. * "templates" --> "template"
> ...
> 7.9. Additions specific to the HTMLInputElement interface
> ...
> Two new methods, stepUp() and stepDown(), enable authors to write code
> that increases and decreases (respectively) the value of the control
> in integral increments of the given step value. The argument specifies
> the number of steps by which to increase or decrease the value. If the
> control's value is invalid or empty, then the methods shall raise an
> INVALID_STATE_ERR exception. If a particular invocation of the method
> would invalidate the value (for example, if stepUp(1) is called when
> the control's value is less than step from max), then the method shall
> raise an INVALID_MODIFICATION_ERR exception. If the argument passed is
> zero, then the method shall raise an INDEX_SIZE_ERR exception.
51. What if step="any"?
> ...
> A. XHTML module definition
> ...
> Warning. XML documents using the new repetition model with the index
> substitution feature on ID attributes cannot validate, as the "[" and
> "]" characters are not valid in IDs in XML.
52. This warning is a non-verbatim repetition of the note at the end of
section 3. Is this intentional, should they have the same text, or
should one of them be removed?
> ...
> C. Deprecated features
> ...
> Documents must not use deprecated features. User agents should support
> deprecated features.
53. In the HTML world, something that authors *must* not use, and which
UAs might not implement, is not "deprecated"; it is "obsolete".
<http://www.w3.org/TR/REC-html40/conform.html#deprecated>
> ...
> D. Requirements for declaring interoperability
54. The sections listed in this section should be hyperlinked.
> ...
> References
> ...
> [CSJSR]
> Client-Side JavaScript Reference (1.3). Netscape Communications
> Corporation, May 1999. The Client-Side JavaScript Reference (1.3)
> is available at
> http://devedge.netscape.com/library/manuals/2000/javascript/1.3/
> reference/index.html
55.
<http://devedge.netscape.com/library/manuals/2000/javascript/1.3/
reference/index.html> has been unavailable throughout the period I was
reviewing this spec. Perhaps
<http://web.archive.org/web/20040202050531/http://devedge.netscape.com/
library/manuals/2000/javascript/1.3/reference/> would be a better
reference.
56. The raw URIs in the JavaScript 1.3 reference, the RFC references,
and the XBL reference should all be hyperlinked.
--
Matthew Thomas
http://mpt.net.nz/
Received on Friday, 31 December 2004 17:47:11 UTC