[whatwg] [WF2] <icomplex> Recap

    Here's a quick recap of <icomplex>...


QUICK DESCRIPTION:

    It's just like <input>, with three exceptions:

  * It doesn't have the depreciated attributes.
  * It should contain alternative contents for legacy support.
  * It requires a closing tag ("</icomplex>").


EXAMPLES:

     Here's a simple example for the three <select> scenario:

| <icomplex 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>
| </icomplex>

     Here's an example for users of jscalendar:

| <icomplex 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
| </icomplex>


PROS:

1) The <icomplex> element can allow for a far greater range of legacy 
fallback than <input>.

2) Because the |type| is defined in an attribute, <icomplex> 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 <icomplex> 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 <icomplex> can't be done directly because user agents 
that support unrecognized elements may use the styling instead of 
ignoring the <icomplex> as intended.

6) The name sucks?


SOLUTIONS FOR CONS:

1) We could just define <icomplex> 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) Simply style <icomplex type="something"> as if it were <input 
type="something"> in WF2 user agents. Therefore, on a system that uses 
the following CSS...

| input[type=date] { /* Some styling here. */ }

...The above styling would apply to both <input type="date"> and 
<icomplex type="date">.

6) Someone should suggest a new name if they don't like the current one.

Received on Sunday, 13 February 2005 11:26:54 UTC