W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2005

[whatwg] [WF2] The <icomplex> element

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Wed, 09 Feb 2005 11:06:21 -0500
Message-ID: <420A34FD.5040705@earthlink.net>
INTRO:

    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> 
attributes.

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.

6) Suppression of Javascript within <icomplex> is not required. Controls 
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.

OUTDATED CONCEPTS:

    Note that all of the following concepts are outdated:

  * <format>
  * <date> (and it's siblings, AS A CONTROL)
  * <idate> (and it's siblings)

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>

ISSUES RESOLVED:

    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.
Received on Wednesday, 9 February 2005 08:06:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:21 UTC