[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working

[Matthew Raymond]

Jim Ley wrote:

> On Thu, 19 Aug 2004 13:07:17 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> 
>>On Thu, 22 Jul 2004, Jim Ley wrote:
>>
>>>Rather than the current situation where everything is an INPUT I don't
>>>see the difference there.
>>
>>"input" conveys that the data is a single field of data input.
> 
> Which isn't the case in any of these combined controls...  so I don't
> think that's a good argument.

    True, but there's still the "input" semantic value there, plus the 
|type| values are predefined in the markup rather than being the control 
being a external plug-in.

>>If it wasn't for IE, we wouldn't have to even _consider_ abusing <object>,
>>so I don't really see your point here anyway.
> 
> Wouldn't we?

    I don't think it matters, because, as stated, using <object> for new 
markup is abusive to <object> (because it's intended for 
document-external content), it's semantically abusive and, in all the 
examples I've seen, it requires duplication of information for graceful 
degradation.

>>>I much prefer it to overloading INPUT.
>>
>>One possibility that has been risen (and which will be considered to WF3
>>once we have more experience with the datetime controls in WF2) is to use
>>a new element for the date/time controls. That would be preferable to the
>><object> solution.
> 
> Perhaps, so why not do it now?  you're suggesting we create as a
> standard something now that we know is wrong, why not do it right in
> the first place?

    "Wrong" isn't the right word. What we have now may be suboptimal in 
some ways, though. It would be nice to have this for instance:

<date name="date1">
   <label>Day: <select id="day1" name="day1"> ... </select></label>
   <label>Month: <select id="month1" name="month1"> ... </select></label>
   <label>Year: <select id="year1" name="year1"> ... </select></label>
</date>

    It allows webmasters to decide how they want the input to be done in 
legacy browsers. This has some problems, though:

1) It has a higher learning curve.

2) It's tough to create a simple version of the above example without 
either duplicating information or making the markup to complicated.

3) I read in this mailing list earlier that new attributes and attribute 
values are easier in XHTML than new elements.

    I'm certainly open to this, though. Feel free to pitch some ideas.