[whatwg] [Web Forms 2.0] Last minute suggestion - The <format> element.

[Jim Ley]

On Thu, 27 Jan 2005 13:04:52 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> Having a single format means libraries can be written that can then just
> be used directly, instead of having to handle dates individually for each
> site as we do now.

Libraries can already have been written, indeed many have, but they've
never proved popular, the reasons aren't on the client-side, and
trying to change the behaviour of server-side authors is surely not
within the remit of WHAT-WG ?

> For example, it assumes that a UA either supports all of the new date/time
> input types as well as the <format> element, or it supports none of them.

Simply make a conformance requirement that any UA supports all
sections, much as the test requirements do, this would overcome this
problem.  Such a requirement would also help a lot in CSS, and make it
truly degradable (rather than the current situation where supporting
position:absolute, but not background-color say can have results which
do not degrade)

> Given past experience with the way UAs implement specs a bit at a time, I
> really don't think this is a good assumption.

but as all the likely implementors of the spec are members of the
group, that can be controlled pretty easily.

> I also am not too happy about the idea of introducing an element purely
> for the purpose of hiding content from new UAs -- effectively deprecating
> the element straight away.

Good point, using OBJECT for this would be much better, as we're
re-using an existing element with just the semantics we want...

> Most of the JS was added at Jim's insistence, so as to degrade gracefully
> in UAs with two or three users. 

Except you've still not done so, you're still using lots of code that
is used on browsers with significant user share, the use of toFixed is
particularly crazy.

> Also, the code takes care of the timezone
> problem (which <format> doesn't). It also handles hiding the format just
> for supported types so it works with incomplete WF2 UAs, and has graceful
> fallback in both WF2 and non-WF2 UAs when JS is disabled.

No it doesn't  it doesn't make any real attempt to see if the UA
already supports Web Forms 2.0.

> Not really, the code is generic and can be cut-and-pasted.

Not at all, that code relies on a particular html structure, it's
hardly generic.

> In most UAs the current value is selected when you tab into a control, so
> that doesn't seem like a serious problem. Also, as you say, it's only an
> issue when JS is disabled.

You've also still not addressed the fallback situation when you want
to pre-populate the fields with data, rather than the format,
something which is the default behaviour for a huge number of
usecases.

> A company that requires that all its employees have the exact same date
> and time settings for display purposes has much bigger problems.

The problem would not appear if a company did indeed mandate such,
that wasn't the issue raised though, they may want a common input
format, not a common display format.

> You'll almost certainly have to anyway, since without type="date", etc,
> authors are more likely to use a number of <select>s than a single field.

So we really should be looking at a method which can fallback to the
existing well understood, well supported format - there's even been
such proposals on the list.

> By supporting most formats automatically, like the demo does, I don't
> really see that there is a problem.

I can assume you've never done a lot of QA on javascript intensive
sites if you do not see lots of javascript as a problem.

> > | <label>New Meeting Time:
> > | <input type="time" value="11:00:00.0Z">
> > | <format>Format: hh:mm</format></label>
> > | </form>

A good example of where localisation is problematical.  You localise
that to my timezone, and I then book the meeting in Norway at the
wrong time, because I want to book it in local time.

> The <format> elements above could also, IMHO, be replaced by <span>
> elements that are removed by JS in WF2 UAs, or by a more comprehensive
> solution like in the demo.

No it couldn't, this suffers from the fact that there is no way to
identify if the UA is a WF2 one or not, since you cannot know that,
there is no way to make the javascript modify the page.  The WF2 UA is
the only entity which knows if it supports input type=date - it has to
be its respsonsibilty to remove stuff, you cannot leave it to the
author.

> This just seems way over the top, especially given that the only real
> reason to have it at all is for legacy UAs.

There are hundreds of millions of legacy UA's, and no WF2 UA's, legacy
UA's will be the main audience for WF2 pages for years to come.

> >    date, input[type=date] { format-date: "%m/%d/%Y" }
> 
> It's quite likely that the CSS working group will do something like this.

Could you point me at the CSS WG charter and where it's chartered for
things like formatting dates, I didn't believe it was?

Jim.