[whatwg] Re: several messages

[Matthew Raymond]

Jim Ley wrote:
> On Sat, 29 Jan 2005 00:57:57 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:
>>On Jan 28, 2005, at 20:57, Matthew Raymond wrote:
>>>   It still means that the webmaster has to alter all server-side
>>>scripting involving dates/times.
>>
>>Webmaster starts using a new version of forms and has to tweak the
>>server side. Isn't that expected? What's the big deal?
> 
> The problems isn't that they have to tweak the server, the problem is
> that for all of the legacy clients, which is the vast majority of
> people using your site for the next 2 years at least will not be WF2
> browsers, will get a severely degraded situation to what they
> currently get.
> 
> Far from improving the user experience WF2 will be severely harming
> it.  Whilst Ian managed to find a few sites that had plain text inputs
> for dates, the vast majority use multiple entry elements, simply
> because that is all that's usable.  The input type=date does not
> degrade usefully.  Ian hasn't even been able to make it degrade
> usefully with lots of javascript!

    I think I get what's going on here. We don't really need to worry 
about the format the server receives the date in, because we're going to 
assume that any webmaster worth his pay can figure that out for himself. 
  In that case, we don't need the formatting, but we do need ways of 
supporting a wide variety of legacy markup, like multiple <select> 
elements and formatting hints.

    For the three <select> control (3SC) problem, that would seem to 
leave a single logical solution:

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

    The idea would be that the browser sends the server either one value 
(WF2) or three values (legacy), then the server figures the rest out.

    For single-textbox solutions, we could just have <dateinput> 
automatically inherit its attribute values from the first child control 
if the |name| attribute isn't defined:

| <label>First Date:<br>
|  <dateinput>
|   <input type="text" name="d1" value="2005-01-30"><br>
|   Format: yyyy-mm-dd
|  </dateinput>
| </label>

    The power of this is that if your date format is already ISO8601, 
you can just wrap the the <input> control, its formatting hints and 
everything else with "<dateinput inherit></dateinput>". Another benefit 
of this simple inheritance is that the control doesn't have to be an 
<input>:

| <label>First Date:
|  <dateinput>
|   <select name="d1">
|    <option>2005-01-30</option>
|    <option>2005-02-01</option>
|    <option>2005-02-05</option>
|   </select>
|  </dateinput>
| </label>

    The above would produce a list of dates, like the select, but the 
dates would be displayed in the local format. Should this be a drop-down 
date list or a sort of datepicker combobox? I'm thinking the former. For 
the latter, people should probably use something like this:'

| <label>First Date:<br>
|  <dateinput list="d1_dates">
|   <input type="text" name="d1" value="2005-01-30">
|   Format: yyyy-mm-dd
|  </dateinput>
| </label>
| <datalist id="d1_dates">
|  <p>Or pick from the list...</p>
|  <select name="d1_dates">
|   <option>2005-01-30</option>
|   <option>2005-02-01</option>
|   <option>2005-02-05</option>
|  </select>
| </datalist>

> Comparing the situation to netscape 4 authoring is completely wrong,
> the situation was very different, there weren't over 500million
> existing UAs with no motivation to upgrade.

    Internet Explorer was (and still is) being installed on every new 
computer, so even if all the browsers at the time of NS4 were Netscape, 
Microsoft would have buried their marketshare based on new computer 
sales alone.