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

[whatwg] Web Forms 2.0 Editorial [minor] Abstract -> Section 2

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 11 Jun 2004 19:10:15 +0200
Message-ID: <40C9E777.3090300@inkedblade.net>
Insertions and replacements marked with >new text<.
Deletions marked with <>.

Abstract
--------

# This specification defines Web Forms 2.0, an extension to the forms features
# found in HTML 4.01's forms chapter. Web Forms 2.0 applies to both HTML and
# XHTML user agents, and provides new strongly-typed input fields, new
# attributes for defining constraints, a repeating model for declarative
# repeating of form sections, new DOM interfaces, new DOM events for validation
# and dependency tracking, and XML submission and initialization of forms. This
# specification also standardises and codifies existing practice in areas that
# have not been previously documented.
#
# HTML4, XHTML1.1 and the DOM are thus extended in a manner which has a clear
# migration path from existing HTML forms, leveraging the knowledge authors
# have built up with their experience with HTML so far.

   This specification defines Web Forms 2.0, an extension >of< the forms features
   >defined< in HTML 4.01's >F<orms chapter. Web Forms 2.0 >extends< both HTML
   and XHTML >providing< new strongly-typed input fields, new attributes for
   defining constraints, a repeating model for declarative repeating of form
   sections, new DOM interfaces, new DOM events for validation and dependency
   tracking, and XML submission and initialization of forms. This specification
   also standardises and codifies existing practice in areas that have not been
   previously documented. <> Web Forms 2.0 thus extends HTML4, XHTML1.1>,< and
   the DOM in a manner >that< has a clear migration path from existing HTML
   forms, leveraging the knowledge authors have built up >in< their experience
   with HTML so far.

# This document is the result of a loose collaboration between interested
# parties in the context of the Web hypertext application technology working
# group.                            ^         ^           ^          ^
   ^

Capitalize.


1. Introduction
---------------

# This is an update to the forms features found in HTML 4.01's forms chapter

   >Web Forms 2.0< is an update to the forms features found in HTML 4.01's
   >F<orms chapter

# Requirements from such comments in mailing lists and other discussions have
# been examined and from these sources a set of requirements and design goals
# were derived

   Requirements from such comments in mailing lists and other discussions have
   been examined>,< and from these sources a set of requirements and design goals
   were derived

# Basic data typing, providing new controls for commonly used types, so that
# authors do not need

   Basic data typing, providing new controls for commonly used types<> so that
   authors do not need

# Simpler validation on the client side (while recognizing that server side
# validation will still be required), with declarative solutions for the common
# case but strong DOM support so that less common cases can easily be handled
# using scripting.

   Simple<> validation on the client side (while recognizing that server side
   validation will still be required), with declarative solutions for the common
   case>s and< strong DOM support so that less common cases can easily be handled
   >by< scripting.

# The ability to initialize forms from external data sources, so that authors do
# not have to dynamically rewrite the form content itself to prefill forms, but
# can instead use static pages with scripts that dynamically generate only the
# data part.

   Initialization from external data sources, so that authors do not have to
   dynamically rewrite the form content itself to prefill forms<> but can instead
   use static pages with scripts that dynamically generate only >a data block<.


1.3 Relationship to XForms
--------------------------

# due to its dependencies on technologies not widely supported by Web browsers,
# it has not been widely implemented by those browsers itself.

   due to its dependencies on technologies not widely supported by Web browsers,
   it has not been widely implemented by >them<.

# The majority of the features that XForms supports using declarative syntax
# are, in this specification, handled by using scripting.

   The majority of the features that XForms supports using declarative syntax
   are, in this specification, handled by <> scripting.


1.5 Missing Features
--------------------

# Again, however, this need may addressed in a future version of this
# specification.

   <> >T<his need may addressed in a future version of this specification.


1.6 Conformance Requirements
----------------------------

# All other content in this specification is intended to be normative.

   All other content in this specification is <> normative.

# Compliant UAs must implement all the semantics of those specifications
# to claim compliance to this one.

   Compliant UAs must implement all the >requirements< of those specifications
   to claim compliance to this one.

# Other aspects of this specification that are defined in terms of an events
# model

   Other >features in< this specification that are defined in terms of an
   events model

# there may be implementation specific limits

   there may be implementation>-<specific limits


1.7 Terminology
---------------

# Generally, when the specification states that a feature applies to HTML or
# XHTML, it also includes the other. When a feature specifically only applies
# to one of the two languages, it is called out explicitly, as in:

  Generally, when the specification states that a feature applies to HTML>, it
  also includes XHTML and vice versa<. When a feature specifically only applies
  to one of the two languages, it is called out explicitly, as in:

#   ...it is possible that authors would prefer to declare the page's forms in
#   advance, in the head element of XHTML documents (this does not apply to HTML
#   documents).

This example makes no sense in this context. Find another one.


2. Extensions to form control elements
--------------------------------------

# Also, as controls no longer need to be contained within their form element to
# be associated with it, it is possible that authors would prefer to declare
# the page's forms in advance, in the head element of XHTML documents (this
# does not apply to HTML documents). This is therefore allowed, although only
# when the form element is empty.

   Also, as controls no longer need to be contained >by< form element to be
   associated with it, it is possible <> to declare the page's forms in
   advance<>. >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.)<

# Forms are not related to ancestor forms in any way semantically,

   Forms are not >semantically< related to ancestor forms in any way<>,


2.1 Extensions to the input element
-----------------------------------

# UAs must not submit numbers in invalid formats (whatever the user might
# enter).

Delete this. It's covered by the type-checking requirements, same as with
all the other types.

# Although if they are required fields, they will stop submission

   Although if they are required fields, they will >block< submission


2.1.1 Ranges
------------

> To limit the range of values allowed by the above types, two new attributes 
> are introduced, which apply to the date-related, time-related, numeric, and 
> file upload types:
    ...
> For date, time and numeric fields, the values indicate the allowed range. For
>  file upload fields, the values indicate the allowed number of files.


   To limit the range of values allowed by the above types, two new attributes
   are introduced<>:
    ...
   For date, time and numeric fields, the values indicate the allowed range. For
   file upload fields, the values indicate the allowed number of files. >For all
   other types, the attributes must be ignored.<

2.1.2 Precision
---------------

# This specifies how many digits may come after the decimal point when the
# number is serialised with a zero exponent, ignoring trailing zeros. Zero
# itself is always valid (assuming it is within the range of min and max of
# course).

   This specifies >the maximum number of digits that< may come after the decimal
   point when the number is serialized with a zero exponent, ignoring trailing
   zeros. <>

# This specifies how many digits may come after the decimal point when the
# number is serialised with an exponent such that

   This specifies >the maximum number of digits that< may come after the decimal
   point when the number is serialised with an exponent such that

# If a UA needs to round a number to its nearest binary equivalent, for example
# when converting a user-supplied decimal

   If a UA needs to round a number to its nearest binary equivalent, >as, <for
   example>,< when converting a user-supplied decimal


2.2 The output element
----------------------

# The output element acts very much like a span element, except that
# it is considered to be a form control

   The output element acts very much like a span element<> except that
   it is considered to be a form control

# It has no attributes beyond the common attributes
                                   ^^^^^^^^^^^^^^^^^
Link to http://www.w3.org/TR/html40/sgml/dtd.html#attrs

# This is similar to the way textarea elements work, except that the
# contents of an element for output controls reflects the current value
# not the initial, or default, value.

   This is similar to the way textarea elements work, except that the
   contents of an >output element< reflects the current value>,< not the
   initial<> value >(defaultValue)<.

# Its value can be set dynamically via the value DOM attribute,
# thus replacing the contents of the element.

   Its value can be set dynamically via the value DOM attribute,
   >whose value then replaces< the contents of the element.


2.3 Extensions to the select element
------------------------------------

# Previous versions of Web Forms were inconsistent about whether the initial
# option element of a single-select select

   Previous versions of Web Forms were inconsistent about whether the >first<
   option element of a single-select select

# If the field doesn't match any of the other values, it should be treated as
# this value.

Delete. This is covered by the prose right after the value definitions.

# If the precision attribute's value does not match any of the allowed values
# given above, for example 0e, +1, or -2dp, then the value integer must be
# assumed.

   If the precision attribute's value does not match any of the allowed values
   given above, <> then the value integer must be assumed. For example 0e, +1,
   and -2dp are all treated as integer.

# User agents implementing this specification must select the initial option
# element of a single-select select element with no otherwise-selected items.

   If no other options are selected, user agents implementing this spec must
   select the first option element of a single-select element.


2.4 -> 2.6
----------

   No editorial comments (yet).


2.7 Extensions to the submit buttons
------------------------------------

# 2.7 Extensions to the submit buttons

   2.7 Extensions to <> submit buttons

# For this reason, the following attributes are allowed on submit buttons:
# action, method, enctype, replace, and target. **When not specified, their
# values default to the values given by their form element.**
#
# If a submit button is activated, then the submission uses the values as given
# by the button that caused the activation, **with missing attributes having
# their values taken from the form.**

Highlighted phrases should be reduced to just one. (Also, the remaining phrase
should be clear as to whether getting the attribute value from the DOM would do
a lookup on the form element or not.)


2.8 Extensions to existing attributes
-------------------------------------

# When applied to a fieldset element it overrides the disabled attributes of
# any descendent form controls

   When applied to a fieldset element it >disables all< descendent form controls

2.9 The pattern attribute
-------------------------

# In the case of the email, tel, and uri, the pattern attribute specifies

   In the case of the email, tel, and uri >types<, the pattern attribute
   specifies

# When the value doesn't match the field's type, a ERROR_TYPE_MISMATCH error
# occurs; when the value doesn't match the pattern, a ERROR_PATTERN_MISMATCH
# error occurs.

   When the value doesn't match the field's type, >an< ERROR_TYPE_MISMATCH error
   occurs; when the value doesn't match the pattern, >an< ERROR_PATTERN_MISMATCH
   error occurs.

# Additional information could also be included, so long as it assists the user
# in entering the field. Otherwise, assistive technology would be impaired.

   Additional information could also be included, >so< long as it assists the
   user in entering the field. Otherwise<> assistive technology would be
   impaired.

# For instance, if the title attribute contained the caption of the control,
# assistive technology could end up saying something like The text you have
# entered does not match the required pattern. Birthday which is not useful.

Insert an em dash before "which is not useful", and please make the <samp>
display: block.


2.11 The form attribute
-----------------------

# Setting an element's form attribute either to a non-existent ID, to the empty
# string, or to an ID that identifies an element that is not an HTML form
# element, disassociates the form control from its form, leaving it unassociated
# with any form.

   Setting an element's form attribute either to >an ID that does not identify an
   HTML form element or to the empty string< disassociates the form control from
   its form, leaving it unassociated with any form.

# unless they have form attributes of their own, or are contained inside forms

   unless they have form attributes of their own<> or are contained inside forms

# When forms are submitted, reset, or have their form controls enumerated

   When forms are submitted, >are< reset, or have their form controls enumerated

2.12 -> 2.15
------------

   No editorial comments (yet).


2.16 Handling unexpected elements and values
--------------------------------------------

# The value of the control, if not specified explicitly, is initialized using

I suspect that you can be a bit more precise than saying "the value of the
control". I'm not sure though. It just kinda stood out...

=== End of section 2 ===

~fantasai

-- 
http://fantasai.inkedblade.net/contact
Received on Friday, 11 June 2004 10:10:15 UTC

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