W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2004

[whatwg] Suggestions and questions for Web Forms 2.0, 2004-12-26 working draft

From: Matthew Thomas <mpt@myrealbox.com>
Date: Sat, 1 Jan 2005 14:47:11 +1300
Message-ID: <0DD6662D-5B97-11D9-9AB6-000A95AD3972@myrealbox.com>
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 (&#xFEFF;) 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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:38 UTC