[whatwg] [Web Forms 2.0] Last minute suggestion - The <format> element.

[Matthew Raymond]

Jim Ley wrote:
> On Thu, 27 Jan 2005 12:33:33 -0500, Matthew Raymond wrote:
>>I'm not certain that every browser supports the form control aspect
>>of <object>.
> 
> I'm almost certain no browser supports the datetime proposals :-)

    The use of <object> is semantically abusive, since <object> is meant 
for use a means of embedding/including external objects:

http://www.w3.org/TR/html4/struct/objects.html#edef-OBJECT
| The OBJECT element allows authors to control whether data should be
| rendered externally or by some program, specified by the author, that
| renders the data within the user agent.

    Why would you use external object embedding markup for internally 
implemented HTML? And why would you want to piggyback the semantics of a 
host of new date/time controls on a semantically weaker, more generic 
element? Sure, <input> does something similar, but <input> is already 
specified that way in at least one approved specification. Even if the 
WHATWG approved an <object>-based solution, the chances of it getting 
through a standards body are nil. It doesn't matter if Ian accepts the 
idea or not.

>> There's also the question as to why we can't just do this instead:
>>| <dateinput id="date" value="2005-01-30">
> 
> Absolutely no reason, I'd be happy with this too, but Ian, without
> really giving his reasons, has been very opposed to introducing new
> elements, I assume he has good ones, hence the reason why I've been
> suggesting re-using existing ones that come with the exact ability we
> want.

    I'm pretty sure Ian would never pick an <object>-based solution over 
a superior one that uses new elements. Just because he's resistant to 
one solution doesn't mean he'll embrace another, weaker one.

>>In fact, I've half talked myself into using this format just having
 >> typed it right now...
>  
> I'd be happy with it, the current fallback of date means I could never
 > use it.

    Actually, the <dateinput> idea has evolved and merged with my 
previous <date> concept:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-January/003017.html

    This new idea introduces fewer elements than <dateinput>, and it 
allows near perfect graceful degradation. For example, here's how to 
tackle the dreaded three-<select> date input problem:

| <label for="date">Event Date:</label>
| <date id="date" value="2005-01-30" min="2005-01-25" max="2006-01-25">
|  <submit name="month" format="%m">
|  <submit name="day" format="%d">
|  <submit name="year" format="%Y">
|
|  <select name="month"><!-- Option elements. --></select>
|  <select name="day"><!-- Option elements. --></select>
|  <select name="year"><!-- Option elements. --></select>
| </date>

    A legacy client sees three controls. The server sees three controls. 
A WF2-compliant browser user sees a datepicker with the local date 
format. There's still some minor date duplication with this approach, 
and <label> is a pain (as it would be with <object> as well), but it 
just solves so many problems so well that these minor issues seem 
trivial. (Is it really a major issue on legacy browsers if the labels 
are unassociated? The |accesskey| attribute can always be added to the 
control element instead of the <label>.)

    If you figure out a way to fix the <label> issue, though, or the 
data duplication issue, please let me know.