- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 30 Mar 2007 23:07:14 -0400
- To: HTML WG Public List <public-html@w3.org>
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