- From: <andyh@collegenet.com>
- Date: Mon, 15 Dec 2003 15:44:29 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-forms@w3.org, www-forms-request@w3.org
> > The problem with saying that a <html:select> can be presented as a > > radio group and <html:input type="radio"> as a drop down selection > > list through a stylesheet is that it makes the maintainance so much > > harder and obtuse. > > I don't understand why it is any harder than in XForms. Could you > expand on this? The HTML elements describe the exact representation of a control and therefore the code sets up a certain expectation. If you then have a style sheet that in effect says "this orange is really an apple", it makes it so much harder to understand the code because the source does not match the final rendition. People in a project change and so earlier design decisions get lost and the use of "clever" tricks impede the learning of new project members. Yes it is technically possible to provide any presentation to any HTML tag, as is the case in XForms, but the level of development within HTML is much lower because you are specifically indicating the type of control. You are the one always arguing that the abilities of HTML authors cannot handle the abstraction of XForms and yet you are arguing for such flexibility in the presentation level. You cannot have it both ways. > They are still not structurally together. [snip] > I'm arguing that the XForms <select> or <select1> > controls are not able to structurally represent the UIs mentioned, whereas > the HTML4 controls are. Err, so this XForms fragment is not what you want? <xf:select1 ref="task" appearance="full"> <xf:label>Select the hardware task you want to perform, and then click Next.</xf:label> <xf:item> <xf:value>A</xf:value> <xf:label>Add/Troubleshoot a device</xf:label> <xf:hint>Choose this option if you are adding a new device to your computer or are having problems getting a device working.</xf:hint> </xf:item> <xf:item> <xf:value>U</xf:value> <xf:label>Uninstall/Unplug a device</xf:label> <xf:hint>Choose this option to uninstall a device or to prepare the computer to unplug a device.</xf:hint> </xf:item> </xf:select1> Add a bit of styling (for a graphical UA) for the <hint> and you have a pretty good facsimile to the original dialog box. Everything is structurally related and in a neater package than the HTML equivalent. > HTML <select multiple> and XForms <select> are both equivalent to checkboxes, Yes, <html:select multiple> and <xforms:select> are equivalent. But they are _not_ equivalent to checkboxes. The use of a checkbox in a multiple selection list is just a (relatively recent) presentation style that is friendlier to the user. Under Windows, the check boxes are controlled through the LVS_EX_CHECKBOXES style on a List-view control and appear _within_ the border of the list box widget. There is no way to separate them out. Individual checkboxes (as in the W2K Display Properties panel) are separate and distinct controls equivalent to <html:input type="checkbox"> and <xforms:input xsi:type="xsd:boolean">. > Your implication appears to be is that HTML is presentational HTML forms are presentational because they are focused on widgets, you have to specify the type of control on the input tag. The 2.3.2 section talks about presentation elements and attributes and I think you would be hard-pressed to say the <input type=""> falls into that grouping. I would guess that the comments in the 2.3 section are aimed at getting people away from <font> and other elements described in chapter 15 and into CSS, which was the big new thing at that time. Anyway your original example uses the very presentational aspects (<DL></DL>) that this statement is guarding against. There is absolutely no purpose for using <DL><DT><DD> in your document other than as shorthand for achieving a certain look. Your form is not a definition list. > The Web Forms one uses ECMAScript imperative scripting associated with > the controls: The problem with scripting is that anything _is_ possible and it cannot be guaranteed that the @onformchange does something as simple as your example. Therefore are UAs expected to be supremely clever, or are they more likely to stick this in the too hard-to-handle pile and move on. For example, you could just have easily have written: <select multiple="multiple" name="toppings" onformchange="disabled = dish[1].checked"> ... <select multiple="multiple" name="fillings" onformchange="disabled = dish[0].checked"> or <select multiple="multiple" name="toppings" onformchange="set_disabled()"> ... <select multiple="multiple" name="fillings" onformchange="set_disabled()"> All of which makes it harder, if not practically impossible, for a UA to determine the relationships and dependencies between controls. XForms processors are more spreadsheet like in that they can determine the dependencies between controls and hence questions are presented in the flow when they become relevant. > Indeed, as was just pointed out to me, most phone Web browsers don't > even support XML, let alone XPath, yet they support HTML, ECMAScript > and the DOM. I would suspect that this is historical because the latter three are older and display a more immediate need. If the history of our industry shows anything then it will only be a matter of time before XML and XPath and other technologies are implemented, so I'm not sure what your argument is here. I am well aware of the current XForms implementations. The issue is that there are no major browser vendors on that list. I fully appreciate MS is not going to do anything but follow their own agenda. And other browser vendors punting on W3C recommendations only reinforces their approach. A "Web Forms 2.0" proposal has no more chance of being implemented by MS than XForms, so again the same argument applies: "why bother?". > The problem with XForms is that it is totally unsuitable for the > simple non-business related forms. > I have spoken to people who have told me they tried to look at > XForms and were actually scared by its complexity. This is a topic I would like to explore further, but probably in another thread, and probably after the holidays as I'm going to be offline for a couple of weeks. In the footnote, in theHTML example you are using <fieldset> to group a single radio button and a corresponding <select>. But those inner <fieldset>s cannot be treated as individual and automonous blocks. A non-graphical browser would have to go down into each block to find all of the "dish" radio buttons in order to present a meaningful prompt. So I'm not sure what is really gained. Nor is it a model that lends itself to further relationships, eg. what if there was another later question that was dependant on an answer of "pizza", or what if there was a follow up question on the type of cheese? You don't have to scale very far before you hit the limitations of HTML forms. In the XForms version, only the relevant toppings/fillings block would typically be displayed, and hence the additional group labels would probably be dispensed with. (Also your first <group> is in the wrong place, it should be between </model> and <select1>). -- Andy Heydon
Received on Monday, 15 December 2003 18:44:32 UTC