A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
User:Matthew Raymond/dataentry element
Jump to navigation Jump to search
The <dataentry> element is just like <input>, with three exceptions:
- It doesn't have the depreciated attributes.
- It has no |alt| attribute, but instead contains alternative contents as child nodes for legacy support.
- It requires a closing tag ("</dataentry>").
- It must contain at least one form control. If </dataentry> has a defined |name| attribute, then it must contain at least one form control with a defined |name| attribute.
Here's a simple example for the three <select> scenario:
<dataentry type="date" id="d1" name="d1" value="2005-02-09"> <select name="d1_day"><!-- Options --></select> / <select name="d1_month"><!-- Options --></select> / <select name="d1_year"><!-- Options --></select> </dataentry>
Here's an example for users of jscalendar:
<dataentry type="date" id="sel1_WF2" name="date1"> <input type="text" id="sel1" name="date1" size="30"> <input type="reset" value=" ... " onclick="return showCalendar('sel1', '%Y-%m-%d');"> YYYY-MM-DD </dataentry>
- The <dataentry> element can allow for a far greater range of legacy fallback than <input>.
- Because the |type| is defined in an attribute, <dataentry> can be used for input types in later specifications, or for vendor-specific input types.
- The element is designed in both semantics and structure to encourages the use of <input> in simple cases where legacy fallback needs are minimal.
- Because it has the same attributes as <input>, there's nothing new to learn except the inclusion of fallback content.
- When creating an <dataentry> element, you should be able to test for the correct element type by checking to see if it has a .type property, but I can't be 100% certain.
- CSS styling for <dataentry> can't be done directly because user agents that support unrecognized elements may use the styling instead of ignoring the <dataentry> as intended.
Solutions For Cons
- A simple method could be added to the DOM that would set whether a form control is include in the .elements collection. A function could then be run when the page loads to hide the <dataentry> elements from the collection.
- This is a general issue affecting all new elements we introduce.
- May not be an issue, but I'd like to hear from an expert.
- Ian seems to feel this is a non-issue, so I won't argue with him.
- I'm considering a pseudo-class (":controltype()" or ":dom(attr, val)"?) that should allow a web author to style <dataentry type="controltype"> when the control type is supported. I'm still working on this concept, though, and I'm wondering if a more general and more powerful pseudo-class can't be developed.