[whatwg] Web Forms 2.0 Editorial [minor] Abstract -> Section 2
fantasai
fantasai.lists at inkedblade.net
Fri Jun 11 10:10:15 PDT 2004
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
More information about the whatwg
mailing list