[whatwg] [Web Forms 2.0] Last minute suggestion - The <format> element.
mattraymond at earthlink.net
Fri Jan 28 05:32:31 PST 2005
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
> 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:
| 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
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:
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>
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.
More information about the whatwg