User:Matthew Raymond/dataentry element: Difference between revisions
Jump to navigation Jump to search
m (SamB moved page User:Matthew Raymond:dataentry element to User:Matthew Raymond/dataentry element: Make actual subpage)
|(4 intermediate revisions by 2 users not shown)|
Latest revision as of 17:39, 7 March 2014
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.