[whatwg] [WF2] The <icomplex> element
mattraymond at earthlink.net
Wed Feb 9 08:06:21 PST 2005
Ian had some interesting points about element counts, dynamic issues
involving inheritance and the potential for empty legacy content in
previous messages regarding <idate>. While I don't entirely agree with
him, I feel it's better to change the concept to address some of his
concerns than trying to convert him to my own opinions. Thus, I'm making
the following changes to the <idate> concept:
1) I'm introducing a |type| attribute and combining all the various
chronological elements (<idate>, <idatetime>, <itime>, <iweek>, et
cetera) into a single element <icomplex>.
2) The new <icomplex> element will have all non-depreciated <input>
3) The <icomplex> element will now only be used in cases involving
complex fallback (that is, situations where <input> can't effectively
provide the desired fallback).
4) Inheritance is dropped.
5) Opening and closing tags should be required in both HTML and XHTML.
within <icomplex>, however, will not be successful for submission.
These changes reduce complexity for use as well as implementation,
help prevent inappropriate use and provide a more general method of
providing fallback that can be extended to non-chronological inputs and
input types that don't even exist yet.
Note that all of the following concepts are outdated:
* <date> (and it's siblings, AS A CONTROL)
* <idate> (and it's siblings)
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>
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');" >
Ian brought up some issues in a previous message regarding <idate>.
Let's take a look.
> * More complicated to implement:
> - more elements involved
> - interactions of elements and attributes that require
> dynamic updates (very bug prone)
The number of elements has been reduced to one, and that element has
a nearly identical list of attributes to <input>. The lack of
inheritance prevents problems with dynamic updates. So unless you're
really against adding a single additional element to HTML, this section
is no longer an issue.
> * More complicated to author for.
> - more elements involved
> - scripts have to be rewritten to handle the legacy content
> separately from the new content (elements array is different,
> event handling is different)
As previously stated, there is now only one additional element, and
it's only used when complex legacy support is needed.
If scripting using the form .elements collection is a problem for
webmasters, they have the option of falling back to <input>, but since
webmasters can either use getElementById or cycle through the elements
until an |id| is found (for DOM1 browsers), this largely looks like a
non-issue. Suggestions for improvement are welcome, of course.
> * Fallback needs author involvement
> - easiest to simply not support legacy
> - server typically needs to handle different names for controls,
> not just different format
Since <icomplex> is a compliment to <input>, and has the same
attributes but requires a closing tag, <input> will still be preferred
by webmasters that don't want to include fallback. The server handling
is a red herring, because <input> doesn't address the problem of
fallback to multiple controls.
So it looks like nearly all of his concerns have been addressed. Let
me know if there are any other concerns to address.
More information about the whatwg