[whatwg] Re: several messages

[Matthew Raymond]

Ian Hickson wrote:
 >On Mon, 31 Jan 2005, James Graham wrote:
 >>>
 >>> | <label for="d1">First Date:</label>
 >>> | <dateinput id="d1" name="d1" value="2005-01-30">
 >>> |  <select name="d1_month"><!-- Options --></select>
 >>> |  <select name="d1_day"><!-- Options --></select>
 >>> |  <select name="d1_year"><!-- Options --></select>
 >>> | </dateinput>

    This is virtually identical to the example in the HTML5 Chronology 
draft I posted recently:

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

    Just change the "dateinput" to "idate".

 >> I haven't been following all the discussion about date formats but,
 >> subject to that proviso, this construct alone (without any
 >> inheritance of attributes) seems to address the major concern that
 >> has been raised about the datetime types (lack of a decent way of
 >> providing fallback). A WF2 UA would simply display:none all children
 >> of the dateinput element.
 >
 > It has problems, as mentioned elsewhere in the thread:
 >
 >  * It is easy for authors to not include any fallback, which makes it
 >    worse than the <input> equivalent.

    If the legacy fallback is simply an <input>, then inheritance 
handles it nicely. If you start with this:

| <input name="date" value="2005-01-31"> Format: YYYY-MM-DD

    ...Then you need only add <idate> tags:

| <idate>
|  <input name="date" value="2005-01-31"> Format: YYYY-MM-DD
| </idate>

    In all the cases where <input type="date"> applies, this makes 
<idate> nearly as easy to use without giving up legacy formatting hints 
and DHTML. Unless you use of multiple form controls for date/time input 
(such as with 3SC), using <idate> is always as simple as this:

| <idate><!-- Legacy Markup with at least one form control --></idate>

    Therefore, I see no reason why a webmaster would choose to drop 
their legacy content when upgrading their websites to use <idate> and 
its siblings. The only issue here is whether or not a grandfather or 
soccer mom who knows virtually nothing about legacy support would put in 
the proper legacy content. For these individuals, you simply write a 
tutorial that tells them to do something like this:

| <idate><input name="date" value="2005-01-31"></idate>

    This can be explained to the user easily enough: "Pretend you're 
going to enter the date as text, then slap <idate> tags around it." It's 
not rocket surgery.

 >  * The fallback and non-fallback controls have different names.

    This is only true of the 3SC scenario, and in that situation the 
server script can easily be rewritten to handle the situation. In fact, 
in the 3SC situation, you can more easily reject incorrectly formatted 
date strings because you shouldn't be receiving them from either a WF2 
or fallback user agent. (Unless there's a serious bug in how a UA 
submits ISO 8601 dates and times, wouldn't this be a rogue UA scenario? 
Why worry about user agents that have "gone off the reservation"?)

    (Now the fact that they have different |id| attributes is a pain, 
but I don't consider this a serious problem, especially when many sites 
don't even use <label>.)

 >  * The datetime types don't really need comprehensive fallback, given
 >    that the three cases that they could replace are:
 >      1. Text inputs, which would be improved, not hurt, by the new
 >         types,

    Except you never solved the formatting hints problem to anyone's 
satisfaction, nor did you explain how to handle legacy sites that use 
<input> + DHTML solutions. Elements like <idate>, as seen above, solve 
this problem in a simple, straight-forward and effective manner.

 >      2. <select> controls, which do not need to be replaced at all,
 >         and

    Yes you do. In fact, if people prefer using <select> controls for 
legacy input, then failing to support it will drive people away from 
WF2, at least where the date/time markup is concerned. It may even give 
some user agent vendors reason not to implement parts of the WF2 spec.

 >      3. Complex JS widgets, for which declarative fallback is not
 >         needed.

    Having a consistent, localized, canned date control is something 
webmasters are going to want even if they have complex DHTML widgets. 
However, they're not going to want to get rid of their DHTML widgets on 
legacy clients that are still bound to be around for many years. As a 
result, if you make it nigh impossible for them to use their widgets as 
a fallback, they're just going to continue using them because they know 
they'll still work on WF2 user agents.

 > ...not to mention the extra complexity and the implementation
 > difficulty compared to just using a new "type".

    Elements like <idate> are identical to <input> with respect to the 
widget they use, and they have the same attributes that <input 
type="date"> would have without adding additional ones. As someone 
already pointed out, the child contents can simply be ignored in 
WF2-compliant user agents for the purposes of rendering and script 
execution. (In fact, CSS could handle the presentation aspect of this: 
"idate * { display: none }".) For inheritance, all the UA needs to do is 
copy attributes from the first form control at load time.

    Could you provide a use case where implementation would be an issue? 
If the user agent vendor doesn't want to implement the inheritance part 
of the spec, they can simply ignore <idate> tags without |name| 
attributes and render the child contents instead. Handling of the legacy 
contents isn't an issue like it is with <object>, because if the user 
agent doesn't support <idate>, it simply ignores the <idate> tags. By 
contrast, the fallback for <object> might be needed, even on an ideally 
compliant UA because the user agent may not have the right plug-in.

    Now, I suppose a user agent might implement the non-inheritance 
version of <idate> without rendering the legacy content for inheriting 
markup, but why would any sane developer (aside from Microsoft, perhaps) 
do this? (I thought about an "inherit" attribute or something, but the 
only real use for this is to help user agents without inheritance 
support find elements that use inheritance.)

    Perhaps the best solution is to leave <input type="[timeunit]"> in 
the specification, add <idate> and it's siblings, and let the best 
element win in the implementation phase. Besides, there's no reason the 
two can't coexist, and they'd very likely share a lot of the same code.

    Just thought of something. In XHTML, <idate> would actually take up 
less space than <input> when no legacy content is used:

| <input type="date" name="date1"/>

| <idate name="date1"/>

    However, HTML is a different story:

| <input type="date" name="date1">

| <idate name="date1"></idate>

    Oh, wait, no it's not! ;)