W3C home > Mailing lists > Public > www-archive@w3.org > July 2008

[wbs] response to 'Web Forms Features'

From: WBS Mailer on behalf of samaxes@gmail.com <webmaster@w3.org>
Date: Sat, 05 Jul 2008 02:55:01 +0000
To: samaxes@gmail.com,www-archive@w3.org
Message-Id: <wbs-5650e984655bc5003740a300c91637b3@cgi.w3.org>


The following answers have been successfully submitted to 'Web Forms
Features' (HTML Working Group) for .



---------------------------------
Should the design in "2. Extensions to form control elements" be included
in HTML 5?
----
Section 2 has extensions to the input/@type attribute such as dates, as
well as a @pattern attribute etc. Should it be included in HTML 5?

If you prefer that specific parts of this design be changed, please note
that in a comment (perhaps by reference to email archives, bugzilla
entries, etc.)

Note that the design in section 2 depends on material from various other
sections, e.g. "4. The forms event model", "7. Extensions to the HTML
Level 2 DOM interfaces". Integrating the extensions to form control
elements into the HTML 5 specification will naturally include material
from these other sections.


 * (x) Yes
 * ( ) No
 * ( ) Concur (cast vote with the majority)
 * ( ) Blank vote

Rationale: 
HTML 4 was really in need of these changes.
Comments (or a URI pointing to your comments): 
In section "2.3. Changes to existing controls" it is stated that "User
agents may establish a button in each form as being the form's default
button. (This should be the first submit button in the form, but UAs may
pick another button if another would be more appropriate for the
platform.) If the platform supports letting the user submit a form
implicitly (for example, on some platforms hitting the "enter" key while a
text field is focused implicitly submits the form), then when doing so the
form's default submit button must be the one used to initiate form
submission (and it will therefore probably be successful). To initiate for
submission in such a case, the user agent must fire a click event at the
button's element, as if the user had clicked the button himself.".

I think this behaviour is wrong, let's look at this example:

[form]
[input text]   | [input image]
[table with search results]
[input submit] | [input submit]
[/form]

my [input image] is a search icon to submit my search form and my two
[input submit] buttons are for exporting the search results to PDF and
Excel.

In this case if the user presses the "enter" key in my [input text], I
want to be my [input image] button to submit the form.
FF2 already has this behaviour but IE7 uses the first [input submit]
button.

The section "2.17. Extensions to the submit buttons" supports my comments,
and is contradictory to that is stated in section 2.3.


In section "2.4. Extensions to the input element" it is stated that "The
formats described below are those that UAs must use in the DOM and when
submitting the data. They do not necessarily represent what the user is
expected to type. User agents are expected to show suitable user
interfaces for each of these types (e.g. using the user's locale
settings). It is the UA's responsibility to convert the user's input into
the specified format."

I think a developer should be allowed to change the format to have a
consistent presentation across the entire application (e.g. if the
developer formats a date within a text using a specified pattern, he
probably wants the same pattern to be used in a <input type="datetime">
even if it's different from the user's locale). This means that the user's
locale settings must be used only when the pattern attribute is not
specified or if it's invalid.

In the same section, the new type "number" defines the point (U+002E, ".")
as the fractional separator. In some locales the fractional separator is a
comma (U+002C, ","). Will the number "500,39" be considered as invalid?


Other issues related to the <input type="file"> can be found in these two
threads:
http://lists.w3.org/Archives/Public/public-html/2008Jan/0104.html
http://lists.w3.org/Archives/Public/public-html/2008May/0309.html




---------------------------------
Should the design in "3. The repetition model for repeating form controls"
be included in HTML 5?
----
Section 3 has a design for repeated sections.

If you prefer that specific parts of this design be changed, please note
that in a comment (perhaps by reference to email archives, bugzilla
entries, etc.)


 * (x) Yes
 * ( ) No
 * ( ) Concur (cast vote with the majority)
 * ( ) Blank vote

Rationale: 
Very useful additions to HTML 5.
Comments (or a URI pointing to your comments): 





---------------------------------
Should the design in "6. Fetching data from external resources" be
included in HTML 5?
----
Section 6 has a mechanism for fetch from an external file to fill forms.
Should it be included in HTML 5?

If you prefer that specific parts of this design be changed, please note
that in a comment (perhaps by reference to email archives, bugzilla
entries, etc.)


 * (x) Yes
 * ( ) No
 * ( ) Concur (cast vote with the majority)
 * ( ) Blank vote

Rationale: 
Useful for filling select elements but not so useful for seeding a form
with initial values.
Comments (or a URI pointing to your comments): 





---------------------------------
Should the design in "5.4. application/x-www-form+xml: XML submission" be
included in HTML 5?
----
Section 5.4 has a XML submission mechanism. Should it be included in HTML
5?

If you prefer that specific parts of this design be changed, please note
that in a comment (perhaps by reference to email archives, bugzilla
entries, etc.)


 * ( ) Yes
 * ( ) No
 * ( ) Concur (cast vote with the majority)
 * (x) Blank vote

Rationale: 
This form content type can be useful when seeding a form with initial
values, but is there any other use case where it can be helpful?
Comments (or a URI pointing to your comments): 



These answers were last modified on 5 July 2008 at 02:53:31 U.T.C.
by Samuel Santos

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/40318/wfreq/ until 2008-07-10.

 Regards,

 The Automatic WBS Mailer
Received on Saturday, 5 July 2008 02:55:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:18 GMT