Comments on XForms Transitional

   I have some notes on XForms Transitional. These notes are not
complete, but I felt I needed to get what I have out there. Here's the
URL for the XForms Transitional draft:

   http://www.w3.org/2007/03/XForms-Transitional/

=== 2.1 Labels ===

   Please note that this section gives absolutely no guidance to how
user agents should handle HTML 4.01 label focus passing for labels that
are associated with multiple controls. Also, the use of |name| values in
|for| to associate a label with a single control does not provide
adequate fallback for legacy user agents.

| Secondly, the name attribute is always required, and in many
| cases it is sufficient to uniquely identify the field.

   It's not clear if you are assuming that |name| is already required,
or if you're defining it as such. If the former, you are in error. HTML
4.01 does not require the |name| attribute for a control, it simply
states that controls without the attribute are not successful for form
submission. If you are truly redefining <input> to require |name| (which
would be odd to do in a section called "Labels"), then you need to make
this clear.

   It should also be pointed out that if you are trying to label a
column of inputs, you have a use case for semantic tabular markup and
should therefore be using <th> elements to label the columns.

| [...] the label may be shown distinctly in some manner when
| any of the associated fields are invalid or are required but
| not filled out.

   This could be done with tabular markup instead of labels. There's no
reason why a <th> element can't change its presentation based on whether
or not elements in the same row or column are valid, and this would
greatly increase the use of existing tabular attributes like |scope|.

=== 2.2 Extended Set of Data Types ===

   I see no reason to start with fewer data types than WF2. The data
types are already defined. Let's consider all of them and drop the ones
that don't hold up to scrutiny rather than starting with a subset. Data
types that have already survived one working group should not have to
start from scratch.

= type="number" =

   The |precision| attribute should be dropped. It is clearly indicated
in the spec that the value is presentational. I would suggest that this
value be converted into a CSS property and proposed separately to the
www-style mailing list. This is not to say that I oppose a mechanism for
formatting numbers. I simply feel that CSS would be a better place to do
that. (It also prevents people from getting the false impression that
the control is rounding the number to a specific precision when it's
just formatting.)

= type="date" =

| Showing an error when users type what for them is a perfectly
| normal data format is likely to lead to developers abandoning
| browser defined controls in favor of more flexible solutions.

   First of all, date pickers don't need to show errors because they can
simply prevent erroneous input to begin with. Also, the date picker can
accept input a user configured format. The format is only critical for
interoperability purposes when you're accessing the control value
through the DOM or submitting the value to the server.

   As for allowing people to enter localized date formats into the
markup, I oppose this for two reasons. First is that human readability
suffers. If the markup requires one format, then once every author
learns that one format, they can all read the dates in other authors'
markup. If you let everyone use whatever format they want, authors have
to learn every format that every other author might use in order to read
their markup. Of course, you could argue that everyone will be using
tools to edit the markup, but that brings me to my second point.

   The second problem is that it unnecessarily complicates parsing. With
all those formats, it's really easy to create bugs in the parser.
Furthermore, if you believe that people are just going to use tools
anyways, it would make more sense to just have the editor convert a
local format into ISO 8601 and write that to the markup than require
every editor and user agent to support every format imaginable.

= type="time" =

   ISO 8601 is fine for this as well. Abbreviations like "am" and "pm"
are not necessarily universal, whereas ISO 8601 is essentially "military
time" and reasonably readable for all.

=== 2.3 Field Validation ===

   The |pattern|, |min|, |max| and |step| attributes appear to be less
developed, but otherwise identical, versions of their WF2 counterparts.
I see no reason why we can't use the WF2 text directly for these attributes.

=== 2.4 Range Controls ===

   Also redundant to WF2 and underdefined. We can use the WF2 text for
this directly.

=== 2.5 Editable Select Controls ===

   This fails to allow any kind of fallback. Compare this to a WF2
example...

XForms Transitional:

| <label>
|   Enter a breed:
|   <select editable name="breed">
|     <option value=""> (none selected)
|     <option>Abyssinian
|     <option>Alpaca
|     <!-- ... -->
|   </select>
| </label>

Web Forms 2.0:

| <label>
|   Enter a breed:
|   <input type="text" name="breed" list="breeds">
| </label>
| <datalist id="breeds">
|   <label>
|     or select one from the list:
|     <select name="breed">
|       <option value=""> (none selected)
|       <option>Abyssinian
|       <option>Alpaca
|       <!-- ... -->
|     </select>
|   </label>
| </datalist>

Web Forms 2.0 (no fallback content):

| <label>
|   Enter a breed:
|   <input type="text" name="breed" list="breeds">
| </label>
| <datalist id="breeds">
|   <option value=""> (none selected)
|   <option>Abyssinian
|   <option>Alpaca
|   <!-- ... -->
| </datalist>

   In a legacy user agent, the XForms Transitional example doesn't allow
a custom input at all, so you've just limited the type of user input
that can be sent to the server. The first WF2 example allows the user of
a legacy user agents to enter both custom values and select from
predefined values, thus providing the same input methods by simply using
two controls instead of one. The second WF2 example only provides custom
values, but since the user can type in a value identical to one they
might select, you haven't really limited the input they can send to the
server. So, in the end, <select editable> places limitations on the
returned values that using |list| and <datalist> does not.

   Another problem with <select editable> is the fact that you can't
have data types. For instance, you can't have a numerical input that
allows you to select Pi or e from a list. WF2 doesn't have this limitation.

   Trust me, this has been discussed to death on the WHATWG mailing list
with me having once been the biggest opponent of the |list| / <datalist>
method. As much as I once hated it, I have yet to find a better solution.

=== 2.6 Calculated Field Values ===

   I think |calculate| is very useful, and it should be integrated into
WF2 with a detailed explanation of how it will interact with the WF2
event model.

   I've been considering the order of events for the various DOM events
in WF2 and the times at which the various declarative attributes are
calculated. These are my notes so far:

| input      (WF2 DOM Event)
| forminput  (WF2 DOM Event)
| change     (HTML 4.01 DOM Event)
| formchange (WF2 DOM Event)
|
| [Process a series of flags that turn attribute
| calculations on and off?]
|
| readonly   (XForms Transitional Attribute Calculation)
| disabled   (XForms Transitional Attribute Calculation)
| required   (XForms Transitional Attribute Calculation)
| calculate  (XForms Transitional Attribute Calculation)
| pattern    (XForms Transitional Attribute Calculation)
| valid      (XForms Transitional Attribute Calculation)
|
| invalid    (WF2 DOM Event)

   I'm not a Javascript or DOM expert, so take the above with a grain of
salt.

= Overriding Calculated Fields =

   While I do think that <input readonly> elements should be able to use
|calculate|, this does not make <input readonly> a replacement for
<output>. For one thing, <input> elements often use operating system
widgets that are not fully stylable. Also, we don't want to encourage
the practice of providing calculated data in a control that is
successful for submission. This may encourage authors to submit
calculated data without validating it on the server, which may lead to
exploits and other security problems.

=== 2.7 Required Field Values ===

   This can be integrated with WF2. So long as the attribute value
"required" evaluates to true, this feature is a superset of the WF2
|required| attribute.

=== 2.8 Read-only Fields ===

   Two things to note. First, can you post an example, because I don't
see the common use case. Second, "readonly" has to evaluate to true in
order for it to be backwards compatible with HTML 4.01. Otherwise,
people would have to change |readonly| to |readonly="true"| for HTML and
|readonly="readonly"| to |readonly="true"| in XHTML.

=== 2.9 Relevant Fields or Groups of Fields ===

   The |relevant| attribute is the functional equivalent to |disabled|
when it's value is set to true, except with a different styling
(invisible instead of greyed). Therefore, why not just allow |disabled|
to take an expression like |readonly|? For backwards compatibility, the
value "disabled" would simply evaluate to true.

=== 3.1 Field States ===

| The CSS3 Basic UI Module defines a range of properties,
| [pseudo]-classes and pseudo-elements that can be used to
| style user interfaces, but requires native support.

   Small note: I have issues with how :read-only and :read-write are
defined in that specification. They conflict with how "read-only" is
defined in HTML 4.01, and have more to do with user alterability than
control states. In fact, there may be a conflict with XForms when in an
editing context (such as when the parent containing the XForms markup
has a |contenteditable| attribute).

Received on Saturday, 31 March 2007 03:05:52 UTC