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 IRC (such as one of these permanent autoconfirmed members).

Difference between revisions of "User:Matthew Raymond/dataentry element"

From WHATWG Wiki
Jump to: navigation, search
(Initial page creation based on earlier mailing list posts.)
 
m (Made a minor addition regarding :controltype().)
Line 6: Line 6:
  
  
==EXAMPLES==
+
==Examples==
  
 
Here's a simple example for the three <select> scenario:
 
Here's a simple example for the three <select> scenario:
Line 25: Line 25:
  
  
==PROS==
+
==Pros==
  
 
# The <dataentry> element can allow for a far greater range of legacy fallback than <input>.
 
# The <dataentry> element can allow for a far greater range of legacy fallback than <input>.
Line 33: Line 33:
 
# Because it has the same attributes as <input>, there's nothing new to learn except the inclusion of fallback content.
 
# Because it has the same attributes as <input>, there's nothing new to learn except the inclusion of fallback content.
  
==CONS==
+
==Cons==
  
 
# The size of a form's elements collection in Javascript may differ between user agents.
 
# The size of a form's elements collection in Javascript may differ between user agents.
Line 41: Line 41:
 
# 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.
 
# 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==
+
==Solutions For Cons==
  
 
# We could just define <dataentry> as never showing up in the .elements collection, or provide an attribute to that effect. Neither are ideal, but if most of the WF2 content will be written from scratch, then .elements is only an issue for those trying to support browsers without support for getElementById.
 
# We could just define <dataentry> as never showing up in the .elements collection, or provide an attribute to that effect. Neither are ideal, but if most of the WF2 content will be written from scratch, then .elements is only an issue for those trying to support browsers without support for getElementById.
Line 47: Line 47:
 
# May not be an issue, but I'd like to hear from an expert.
 
# 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.
 
# Ian seems to feel this is a non-issue, so I won't argue with him.
# I'm still working on this one. I have some ideas, though. Stay tuned.
+
# I'm considering a pseudo-class (":controltype()"?) 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.
 
__NOTOC__
 
__NOTOC__

Revision as of 17:22, 10 March 2005

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>").


Examples

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>


Pros

  1. The <dataentry> element can allow for a far greater range of legacy fallback than <input>.
  2. Because the |type| is defined in an attribute, <dataentry> can be used for input types in later specifications, or for vendor-specific input types.
  3. The element is designed in both semantics and structure to encourages the use of <input> in simple cases where legacy fallback needs are minimal.
  4. The element is designed only to prevent the presentation of its child elements. It does not require user agents to delete contents from the DOM or suppress Javascript execution.
  5. Because it has the same attributes as <input>, there's nothing new to learn except the inclusion of fallback content.

Cons

  1. The size of a form's elements collection in Javascript may differ between user agents.
  2. There may be legacy Javascript issues that cause script failure when generating unrecognized elements.
  3. 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.
  4. Some unneeded Javascript overhead on WF2 clients.
  5. 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

  1. We could just define <dataentry> as never showing up in the .elements collection, or provide an attribute to that effect. Neither are ideal, but if most of the WF2 content will be written from scratch, then .elements is only an issue for those trying to support browsers without support for getElementById.
  2. This is a general issue affecting all new elements we introduce.
  3. May not be an issue, but I'd like to hear from an expert.
  4. Ian seems to feel this is a non-issue, so I won't argue with him.
  5. I'm considering a pseudo-class (":controltype()"?) 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.