w3.org

HTML Forms - the Next Generation

wispy clouds in a blue sky

Google, Mountain View
5th March 2007
http://www.w3.org/2007/03/html-forms/

Outline of today's talk

W3C's plans for HTML
HTML4 Forms
XForms
Web Forms 2.0
XForms Transitional
Next Steps

Brief History of HTML

HTML versions:
- HTML 1.0 in 1990
- HTML 2.0 in 1994
- HTML 3.2 in 1996
- HTML 4.0 in 1997
- W3C workshop on the future of HTML in 1998
  - Decision to migrate from tag soup to XML (XHTML)
  - Work on forms later spun off into separate WG (XForms)
- XHTML 1.0 in 2000
- XHTML 2.0 in 2002 (1st Draft)
- W3C Workshop on Web Applications and Compound Documents in 2004
  - Rumblings of discontent
  - Formation of WhatWG (not part of W3C)

W3C's plans for HTML

XML has been a huge success, but not on the desktop
- XHTML 1.0 was insufficiently compelling
  - Failure to exploit flexibility of XML for compound documents
Demand for renewed work on text/html by browser developers and HTML evangelists
- Incremental improvements in a number of areas including forms
W3C is now planning new work on HTML
- New HTML working group to incrementally extend HTML4
- Two equivalent serializations: tag soup and XML
- Separate XHTML WG to continue work on XHTML2
- Forms working group for continuing work on XForms
Incremental extensions to HTML Forms
- Developed by Joint Task Force with HTML and Forms WGs

HTML4 Forms

An incomplete summary

Hugely important to success of the Web
Markup for form fields
- text, buttons, radio buttons, checkboxes, selection lists, field sets
- each field may be associated with one or more labels
Object Model for scripting
- One or more named forms: document.forms[n]
- Each form has collection of named fields: document.forms[0].quantity
- Arrays of fields with the same name: document.forms[0].quantity[2]
- Properties: name, type, value, readonly, disabled
- Events: onchanged, onfocus, onblur, onsubmit
Scripting required for client-side validation

XForms

Enterprise strength forms
- Multiple implementations including OpenOffice
- Popular in corporate and government environments
Applies Model-View-Controller Design Pattern
- Separates Presentation, Logic and Data
- Abstract UI controls offers device independence
- Can be used with XBL and SVG for rich graphical controls
- Requires XML Host language (XHTML or SVG)
- Form data is XML
- XPath for integrity constraints on data
Hasn't caught on for public websites
- Perception of steep learning curve
- Not backwards compatible with HTML Forms
- Lack of native browser implementations (except for Mozilla)

Web Forms 2.0

Increment extensions to HTML4 forms
- Developed by WhatWG (not W3C)
- Extended set of data types, e.g. date, time, number, range, email and uri
- Support for date pickers and sliders
- Regular expression for constraining value (pattern)
- Fields can be marked as required
- Input mode (e.g. kanji)
- Flag to suppress field autocompletion
- Output element for values set by scripts
- Relaxes requirement to nest fields in form element
- Repeated groups of fields (attributes on TR elements)
Implemented natively by Opera
- Script library for Internet Explorer (partial?)

W3C Forms Task Force

Joint membership HTML and Forms working group
- Diversity of experience will ensure a well thought out proposal and a strong standard
Expected to work from the ground up
- Clarify starting assumptions with respect to use cases
- Examine the key design choices that follow from these assumptions
- Define synthesis of ideas, taking current proposals into account
- No rubber stamp for an existing proposal
Starting assumptions
- Incremental extensions to HTML4 Forms markup and object model
- Must be capable of being deployed on majority of existing browsers via a compatibility library
- Should provide real value over current practice

Some Key Choices

Declarative treatment vs Scripted event handers (as now)
- Simple spreadsheet like expressions are much cheaper for web page developers than client-side scripting, and enable automated reasoning over form logic
- JavaScript vs XPath for expression language
Inline or separate description of validation and other features
- Analogous to style attributes and style sheets
Can you define the context in which fields must be filled out, or when a field or group of fields is relevant?
Separation between stored and presented values
- Present numbers with 2 digits after decimal point, but retain greater precision as basis for further calculations
Can users override the values of computed fields?
Repetition model - syntactic or object model based?

XForms Transitional

Started life as an experiment to explore design choices and provide input into standardization process
- Name has changed from forms lite to XForms Tiny and now XForms Transitional and may end up as HTML Forms as standards work proceeds
- Cross-browser JavaScript library size 6KBytes compressed
- Works on >99% of desktop browsers: IE 6/7, Firefox, Opera, Safari, Konqueror etc.
- Usability tweaks in pipeline for Opera Mobile and NetFront 3.4
Adds handful of new attributes plus extensions to object model
- Spreadsheet-like expressions using JavaScript for syntax
- Topological sort used for efficient calculation of computed fields
Aim for synthesis of existing proposals (work in progress)
- HTML syntax for aspects of XForms architecture as basis for easing transition to full power of XForms for enterprise strength forms

Field data types

Here is the markup for the above form:

<form name="form1" onsubmit="false">
<fieldset>
<legend>Typed fields</legend>
<label for="f1" title="must be a number">Number</label>
<input id="f1" name="x" type="number"/>
<label for="f2" title="must be a date">Date</label>
<input id="f2" name="y" type="date"/>
</fieldset>
</form>

Note: "datatype" may be used as alternative to "type" to work around Opera's use of fixed enumerations for attribute values, which prevents scripts from accessing unrecognized values.

Data types, images and dynamic classes

Date picker generated by script or natively
Browser doesn't remember the URI used to load each script
This causes problems for relative URIs for images
- when loading script from different web page locations
- work around is to use an absolute URI
- this is bad news for running demo's when offline!
Many other possibilities besides date and number
- time, email, URI, integer, etc.
- potential security and privacy issues
- disabling autocomplete on a per field basis
Dynamic CSS classes for styling according to field state
- focus, readonly, invalid, irrelevant, missing
- works nicely in existing browsers (c.f. new psuedo classes)

Regular Expressions

Here is the markup for the above form:

<form name="form2" onsubmit="false">
<fieldset>
<legend>Patterns</legend>
<label for="f1"
title="must resemble 1234-1234-1234">Card number</label>
<input id="f1" name="cardnum" value="1234-1234-1234"
pattern="^\d\d\d\d-\d\d\d\d-\d\d\d\d$"/>
</fieldset>
</form>

Prefer to use same attribute names as XForms for consistency where practical!

type, pattern, constraint, required, relevant, calculate

Computed Fields

Here is the markup for the above form:

<form name="form3" onsubmit="false">
<fieldset>
<legend>Simple calculation</legend>
<label for="f1">X</label>
<input id="f1" name="x" type="number"/>
<label for="f2">Y</label>
<input id="f2" name="y" type="number"/>
<label for="f3">X + Y</label>
<input id="f3" name="sum" calculate="x+y" type="number" readonly="readonly"/>
</fieldset>
</form>

Based upon JavaScript expressions with preprocessing for field references

"x + y" is rewritten as "form.x + form.y" for JavaScript eval()

Min and Max values

Here is the markup for the above form:

<form name="form4" onsubmit="false">
<fieldset>
<legend>Typed fields</legend>
<label for="f1"
 title="must be a number between -5 and 5">Number</label>
<input id="f1" name="x" type="number" size="2" min="1" max="5"/>
<label for="f2"
 title="must be a date not earlier than 7 Oct 2006">Date</label>
<input id="f2" name="y" type="date" min="7 Oct 2006"/>
</fieldset>
</form>

Exploits Date object for date calculations (mS since start 1 Jan 1970)

Emulate behavior of spreadsheets with normalized presentation

Range controls (sliders)

Here is the markup for the above form:

<form name="form5" onsubmit="false">
<fieldset>
<legend>Typed fields</legend>
<label for="f1"
 title="must be a number between 1 and 5">Number</label>
<input id="f1" name="x" type="range"
 size="2" min="1" max="5" step="1"/>
</fieldset>
</form>

Slider control is used when supported natively, e.g. Opera and Safari

Validation Constraints

Here is the markup for the above form:

<form name="form6" onsubmit="false">
<fieldset>
<legend>Validation expressions</legend>
<label for="f1" title="must be a number">X</label>
<input id="f1" name="x" type="number"/>
<label for="f2" title="must be a number greater than x">Y</label>
<input id="f2" name="y" type="number" constraint="y > x"/>
</fieldset>
</form>

Constraint uses same JavaScript syntax as calculate attribute.

Can use < > and & directly for text/html, but must be escaped as < > and & for delivery as XML

Determining when Fields must be filled out

Here is the markup for the above form:

<form name="form7">
<fieldset>
<legend>Conditionally required field</legend>
<label for="f1" title="optional">X</label>
<input id="f1" name="x" type="text"/>
<label for="f2" title="required if x is filled out">Y</label>
<input id="f2" name="y" type="text" required="x != ''"/>
<button type="submit">Submit</button>
<button type="reset">Reset</button>
</fieldset>
</form>

Required uses same JavaScript syntax as calculate attribute.

"needed" can be used as alternative to "required" to workaround Opera bug.

Relevant Field or Groups of Fields

Here is the markup for the above form:

<form name="form8" onsubmit="false">
<fieldset>
<legend>Relevant fields</legend>
<label title="try with 5 and then with 3"
for="f1">Number of years at current address?</label>
<input id="f1" name="x" type="number"/><br/>
<label title="Needed if years at current address is less than 4"
for="f2">Number of years at previous address?</label>
<input id="f2" name="y" type="number" relevant="x < 4"/>
</fieldset>
</form>

Relevant uses same JavaScript syntax as calculate attribute.

Repeating Sets of Fields

Here is the markup for the above form:

<form name="form9">
<fieldset name="lineItem" repeat-number="4">
<legend>Repeating groups of fields</legend>
<label for="item">Product Name</label>
<label for="quantity">Number Purchased</label>
<label for="unitprice">Price Per Unit</label>
<input name="item" type="text" title="product name"/>
<input name="quantity" type="number" title="number purchased"/>
<input name="unitprice" type="number" title="price per unit"/>
</fieldset>
<p><label for="total">Total price</label>
<input name="total" readonly="readonly"
 calculate="sumover(lineItem, quantity*unitprice)"/>
<button type="submit">Submit</button>
<button type="reset">Reset</button></p>
</form>

Fieldsets and Device Independence

Repeating fieldset uses a device independent syntax
- On desktops, implemented as dynamically generated tables
- On mobile, view one "row" at a time in vertical layout plus navigation controls
repeat-number determines minimum number of rows to display
Automatically add new row when last row is no longer empty
Script API and UI for adding/deleting/re-ordering rows
Note label "for" attribute binds to field "name" if no matching "id"
- This is used to bind labels to field "columns"
Expression execution context defnes "$" as local variable
- Provides array index for current row
- Field reference foo is re-written as form.foo[$]
- Expression preprocessor informed by object model

Initializing Fieldsets

Here is the markup for the above form:

<form name="form10">
<fieldset name="lineItem" repeat-number="4">
<legend>Repeating groups of fields</legend>
<label for="item">Product Name</label>
<label for="quantity">Number Purchased</label>
<label for="unitprice">Price Per Unit</label>
<!-- first row -->
<input name="item" type="text" title="product name" value="a"/>
<input name="quantity" type="number" title="number purchased" value="10"/>
<input name="unitprice" type="number" title="price per unit" value="1"/>
<!-- second row -->
<input name="item" type="text" title="product name" value="b"/>
<input name="quantity" type="number" title="number purchased" value="2"/>
<input name="unitprice" type="number" title="price per unit" value="3"/>
<!-- any remaining rows will be generated dynamically so that
 there is always at least the number of rows given by repeat-number -->
</fieldset>
<p><label for="total">Total price</label>
<input name="total" readonly="readonly"
 calculate="sumover(lineItem, quantity*unitprice)"/>
<button type="submit">Submit</button>
<button type="reset">Reset</button></p>
</form>

Radio Buttons

Here is the markup for the above form:

<form name="form11">
<fieldset>
<legend>Combining different kinds of fields</legend>
<label for="male">Male</label>
<input id="male" name="gender" type="radio" value="male" checked="checked"/>
<label for="female">Female</label>
<input id="female" name="gender" type="radio" value="female"/>
<label for="married">Married?</label>
<input id="married" name="married" type="checkbox" value="married"/>
<label for="maiden">Maiden name</label>
<input id="maiden" name="maiden" relevant="gender=='female' && married"/>
</fieldset>
</form>

Note that checkboxes evaluate as booleans whilst radio buttons evaluate as strings (value attribute).

Selection Lists

Here is the markup for the above form:

<form name="form12">
<fieldset name="lineItem" repeat-number="4">
<legend>Repeating groups of fields</legend>
<label for="item">Product Name</label>
<label for="quantity">Number Purchased</label>
<label for="unitprice">Price Per Unit</label>
<select name="item">
<option></option>
<option value="hammer">Hammer</option>
<option value="screwdriver">Screwdriver</option>
<option value="spanner">Spanner</option>
</select>
<input name="quantity" type="number" title="number purchased"/>
<input name="unitprice" type="number" title="price per unit"
calculate="price(item)" readonly="readonly"/>
</fieldset>
<p><label for="total">Total price</label>
<input name="total" readonly="readonly"
 calculate="sumover(lineItem, quantity*unitprice)"/>
<button type="submit">Submit</button>
<button type="reset">Reset</button></p>
</form>

Counting Checkboxes

<input name="total" readonly="readonly"
   calculate="crustPrice(size)+toppingPrice(size)*count(toppings)"/>

Note use of author supplied functions for price data

Here is the markup for the above form:

<form name="form13">
<fieldset>
<legend>Create your own pizza!</legend>
<fieldset class="size">
<legend>Size</legend>
<input id="size12" name="size" type="radio" value="12"/>
<label for="size12">12 inch (6 slices)</label>
<br />
<input id="size14" name="size" type="radio" value="14"/>
<label for="size14">14 inch (8 slices)</label>
<br />
<input id="size18" name="size" type="radio" value="18"/>
<label for="size18">18 inch (12 slices)</label>
</fieldset>
<fieldset class="crust">
<legend>Crust</legend>
<input id="crust1" name="crust" type="radio" value="regular"/>
<label for="crust1">Regular</label>
<br />
<input id="crust2" name="crust" type="radio" value="thin"/>
<label for="crust2">Thin</label>
<br />
<input id="crust3" name="crust" type="radio" value="thick"/>
<label for="crust3">Thick</label>
</fieldset>
<fieldset class="toppings" name="toppings">
<legend>Toppings</legend>
<input id="topping1" name="cheese" type="checkbox" value="cheese"/>
<label for="topping1">Extra cheese</label>
<br />
<input id="topping2" name="peperoni" type="checkbox" value="peperoni"/>
<label for="topping2">Pepperoni</label>
<br/>
<input id="topping3" name="salami" type="checkbox" value="salami"/>
<label for="topping3">Salami</label>
<br />
<input id="topping4" name="sausage" type="checkbox" value="sausage"/>
<label for="topping4">Sausage</label>
<br />
<input id="topping5" name="jalapenos" type="checkbox" value="jalapenos"/>
<label for="topping5">Jalapenos</label>
<br />
<input id="topping6" name="peppers" type="checkbox" value="peppers"/>
<label for="topping6">Bell peppers</label>
<br />
<input id="topping7" name="onions" type="checkbox" value="onions"/>
<label for="topping7">Onions</label>
</fieldset>
<p><span class="right">
<button type="submit">Add to my order</button>
<button type="reset">Reset</button></span>
<label for="total">Total price</label>
<!-- crustPrice and toppingPrice defined by webpage author -->
<input name="total" readonly="readonly"
  calculate="crustPrice(size)+toppingPrice(size)*count(toppings)"/></p>
</fieldset>
</form>

Referring to Fieldset Names

Here is the markup for the above form:

<form name="form14">
<fieldset class="address" name="billto">
<legend>Billing Address</legend>
<label for="f1">Street</label>
<input id="f1" name="street" value="1280 Buena Vista"/>
<br />
<label for="f2">City</label>
<input id="f2" name="city" value="Palo Alto"/>
<br />
<label for="f3">State</label>
<input id="f3" name="state" value="California"/>
<br />
<label for="f4">Zip code</label>
<input id="f4" name="zipcode"/>
<br />
</fieldset>
<p><input id="f5" name="difship" type="checkbox" value="needed"/>
<label for="f5">Ship to a different address</label>
<br clear="all"/></p>
<fieldset class="address" name="shipto" relevant="difship">
<legend>Shipping Address</legend>
<label for="f6">Street</label>
<input id="f6" name="street" value="46 Main Street"/>
<br />
<label for="f7">City</label>
<input id="f7" name="city" value="Redwood City"/>
<br />
<label for="f8">State</label>
<input id="f8" name="state" value="California"/>
<br />
<label for="f9">Zip code</label>
<input id="f9" name="zipcode"/>
<br />
</fieldset>
<p><label for="f10">Will be shipped to</label>
<input id="f10" name="shipCity" readonly="readonly"
 calculate="difship ? shipto.city : billto.city"/></p>
</form>

Comboboxes

Selection fields you can type into Favorite fruit

Here is the markup for the above form:

<form name="form15" onsubmit="false">
<fieldset>
<legend>Selection fields you can type into</legend>
<label for="f1">Favorite fruit</label>
<select name="fruit" id="f1" editable="12">
<option>apples</option>
<option>pears</option>
<option>bananas</option>
<option>pineapple</option>
</select>
</fieldset>
</form>

Use native combobox control when available.

Expense Claim

Travel Expense Claims

User overrides for calculated fields

Efficient computation of field values based upon topological sort
Detects cyclic dependencies
But what if user can override calculated value
Expense claim in foreign currency provides use case
- Payments made in cash at known exchange rate
- Credit card statments in own currency - exchange range unknown
Avoid cyclic dependencies via treatment as separate fields
- Treat overridden field distinctly from calculated field
This isn't yet supported by XForms

Summary of Experimental Extensions

Markup
- New attributes: pattern, constraint, calculate, required, relevant, min, max
- New values for type attribute, e.g. "date", "time", "number" and "range"
- Extend <label> "for" attribute to match on field name if no matching id
- Add name and repeat-number attributes to fieldset element
- New editable attribute for select element
Object Model
- Add new field properties for pattern, constraint, calculate, required, relevant, min and max, with booleans for invalid and missing
- Add collection of labels to each field
- Add collection of fields to each label
- Include fieldset in each form's collection of named fields
- Add collection of named fields to each fieldset object
- Small set of built-in methods for use in expressions, e.g. count and sumover
- Local variables "form" and "$" for expression execution context

Browser based editing

Markup + script + Ajax with pages saved on web server
designMode has too many flaws
I am developing new cross browser editing library that avoids designMode and execCommand
Uses DOM2 Range to locate mouse clicks (emulated on IE)
Uses empty span element and CSS to emulate editing caret
Toolbar + context pane + wysiwyg pane
- Context pane provides access to information that isn't visible in wysiwyg pane
- Focus on helping with tasks not element attributes
Beta released expected end of 2007 with application to slides, forms and device independent content

Spreadsheets 2.0

Current spreadsheet tools will be obsoleted by the Web!

Spreadsheet formulae based upon row/column names (letter + number)
HTML allows for logical names that are easier to deal with
Browser based editing will make it easier to create HTML forms than is currently possible with today's Spreadsheets
Web based solution integrates cleanly with workflow processes
Next version of HTML Forms could submit data as XML
Databinding mechanism for easy initialization of form contents
API support for dynamic save and load without page reload
Calls for participation in the new HTML/Forms/XHTML WGs expected in near future!

Questions?

HTML Forms - the Next Generation

Google, Mountain View 5th March 2007 http://www.w3.org/2007/03/html-forms/

Outline of today's talk

Brief History of HTML

W3C's plans for HTML

HTML4 Forms

XForms

Web Forms 2.0

W3C Forms Task Force

Some Key Choices

XForms Transitional

Field data types

Data types, images and dynamic classes

Regular Expressions

Computed Fields

Min and Max values

Range controls (sliders)

Validation Constraints

Determining when Fields must be filled out

Relevant Field or Groups of Fields

Repeating Sets of Fields

Fieldsets and Device Independence

Initializing Fieldsets

Radio Buttons

Selection Lists

Counting Checkboxes

Referring to Fieldset Names

Comboboxes

Expense Claim

Travel Expense Claims

User overrides for calculated fields

Summary of Experimental Extensions

Browser based editing

Spreadsheets 2.0

Google, Mountain View
5th March 2007
http://www.w3.org/2007/03/html-forms/