- From: Jim Ley <jim.ley@gmail.com>
- Date: Wed, 30 Jun 2004 16:28:41 +0100
On Wed, 30 Jun 2004 15:18:39 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote: > On Wed, 30 Jun 2004, Martin Kutschker wrote: > > Well, now what? I see the problem. Do I understand it correctly that we > > simply say getting locale and time zone is outside the spec, so browser > > developers must deal with it. > > Pretty much. That's what ECMAScript says. Yes, but the scope of the two are rather different, one is in a general purpose scripting language, where the dependency on the accuracy of such information is purely up to the application developer. Whereas in WF2 it's raised to be something where it's absolutely critical that the user and client are in agreement about the time and timezone - how many times on usenet do you see people who in the UK with their clocks 9 hours wrong, but appearing right to themselves as they are in a +9 timezone? This requirement simply isn't workable on the web. > > Sure. Anyway web/gtraphics designers loath everything they cannot > > control. If it cannot be controlled at least to some degree it simply > > won't be used. > > Eventually XBL will be able to fully control this stuff. Right, what rendering language does this XBL have that gives us this complete control over how things look? Why would we use the rather hobbled to be backwards compatible WF2 proposals in an XBL environment? > I'm not convinced that we need this on the date controls themsevles. Those > should automatically adapt to the user's locale, why would the author want > to control that further at the format level? Because designers feel the need to place some control on what the user sees, they like to be able to say "20em" for the width of an input control, once the rendering is no longer in their hands, they no longer know if 20em is appropriate to show the entire date in a particular format. Jim.
Received on Wednesday, 30 June 2004 08:28:41 UTC