Semantic form mark-up discussion
As part of the mircoformats meet up in Brighton this week a group of us took some time to discuss the semantic mark-up of forms. This was based on my previous thoughts on the subject. We also look at this issue in light of Tantek’s proposal for the version 2 of microformats.
Please forgive that fact that I have not noted everyone’s name who took part. The main people contributing were; Aral Balkan, Glenn Jones, Jeremy Keith, Josh Emerson and Tantek Çelik. The session was broken down into 7 small discussions of specific problem areas. I have summarised below.
Using the class attribute and hierarchies
There was full agreement for the use of the className attribute instead of the form field name attribute. The name attribute can only take a single value and does not give enough flexibility to the author of a form as the name maybe dictated by the server side code.
For the current version of microformats, the use of hierarchical structures was agreed upon. The structures will be flattened in version 2 of microformats. In principle, form mark-up should follow the hierarchical structure of the microformat. /> Examples used for the discussion:
[sourcecode language="html"] />
Defining types in the className attribute
There is a problem adding ‘type’ information i.e. home, work and pref to inputs that take telephone numbers or email addresses. There are many use cases where the author wants to define a specific ‘type’ of a property, such as a mobile telephone number, to a single input. To accommodate this we somehow have to add the ‘type’ metadata as well as the property name.
In the current version of microformats, most people at the meeting were happy with the type information being added into the className attribute. For version2 of microformts, Tantek suggested adding a prefix of ‘l’ standing for label.
There was some discussion of using the HTML label element to define the microformat property. But it was dropped as we could not think of an authoring use case and it would add complexity.
Tanteks microformats v2 idea: /> [sourcecode language="html"] /> /> /> [/sourcecode]
Example used for the discussion: /> [sourcecode language="html"] /> /> /> [/sourcecode]
Repeating microformat properties
This was generally agreed between everyone except Tantek. There are a large number of use cases where we find repeating patterns. These patterns allow a user to add multiples of one item. The most common example in hCard is the URL property. We discussed the use of a “repeatable” class that would cause an auto-fill application to duplicate the whole DOM node and append it as a sibling underneath the original.
The word “repeatable” was preferred over “repeat”. Although there are use cases to back up this type of functionally Tantek thought it broke the layers of abstraction and we could never be a 100% sure it would not damage the layout designed by the author. Tantek rejected this as a possible solution. No agreement/conclusions were reached about this point.
Example used for the discussion: /> [sourcecode language="html"] />
Repeating microformat structures within one form
This item is similar to the previous item and as such everyone took a similar point of view. Jeremy believed that he could see good real world uses for this pattern of mark-up. Again “repeatable” would be a better className. Tantek’s previous objections were carried forward to this pattern.
Example used for the discussion: /> [sourcecode language="html"] />
/> [/sourcecode]Logical operator “or”
There are times where an author may wish to use more than one property if it’s available. If we were to use this pattern the “or” is not required. Tantek pointed out that there is no order to the className attribute and we should not force one artificially to enable this feature.
Example used for the discussion: /> [sourcecode language="html"] /> /> /> /> /> [/sourcecode]
String concatenation
There are a number of circumstances where concatenating a plural microfromats property into a single string is required. The best example of this is a number of individual tags into a single string.
Jeremy suggested using the multiple attribute or a className multiple. As the multiple attribute can currently only be applied to a file input or a select element we will have to use the word ‘multiple’ in the class attribute. There was some discussion about dropping the formatting instructions.
Example used for the discussion: /> [sourcecode language="html"] /> /> [/sourcecode]
The group’s solution: /> [sourcecode language="html"] /> /> [/sourcecode]
Additional – Inputs inheriting parent className values
As we talked, it became apparent that it would be useful for a form element to inherit its parent className value. The form field would have to be the only form field of the parent. This type of structure would be required to ease the authoring of the ‘repeatable pattern’.
The group’s solution: /> [sourcecode language="html"] />
/> /> />
/> [/sourcecode]