- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 28 Jan 2005 14:35:10 -0500
Max Romantschuk wrote:
>>Ian Hickson wrote:
>>>Supporting ISO8601 is pretty easy. It's one of the simplest date/time
>>>formats to parse.
>
> Matthew Raymond wrote:
>> It still means that the webmaster has to alter all server-side
>>scripting involving dates/times. What happens when you hired an outside
>>group to setup those scripts, but your HTML is in-house?
>
> There is no way we can accomplish new things without any growing pains.
> It's a far better tradeoff to force people to modify some scripts than
> complicate the model with client-driven formatting.
The client-side formatting is optional, it's easy to implement, and
if it doesn't support a certain format, then the worst that happens is
they have to change the server scripts anyway.
> Sticking to one date format makes the server side bits much simpler
> overall, and also eliminates possible ambiguation issues with the
> submitted format being misconfigured in the form.
Since ISO8601 is still the default, they still have that option.
> If we wanted everything to work for everyone without the need for
> changes we should still be coding table-based, CSS-free layouts for NS4.
Properly written HTML, even for WF2, will still be readable/usable
on NS4, so what's your point? New features need not mean destroying
existing infrastructure.
> PS. I do find your proposal attractive, but I still feel it wouln't be
> worth it.
My proposal for <date> still works without the client-side
formatting markup:
| <date value="2005-01-30" name="date">
| <input value="2005-01-30" name="date">
| </date>
Unfortunately, this dumps the support for three legacy <select>
elements...
Received on Friday, 28 January 2005 11:35:10 UTC