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

Jim Ley wrote:
> On Thu, 27 Jan 2005 13:04:52 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
[Snip!]
>>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...

    Let's not start with the object stuff again. Any control defined 
with  <object> has absolutely no semantics beyond those of <object>. 
It's also an abuse of <object> semantics, since <object> is intended for 
embedding external and potentially non-HTML content, and not to act as 
new markup. Also, it's nigh impossible to use your <object> approach 
with an HTC implementation.

    That doesn't mean we can't take ideas from <object> and put them in 
another, new element. It simply means we can't use <object> itself.

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

    Ah! Forgot about that. Thanks for reminding me. That's another 
reason I didn't like it.

>>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 have somewhat of a point, but the problem is that how the date 
is displayed on the page is also how we'd want it to be inputted in 
legacy user agents, effectively making the display format and the input 
format the same thing.

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

    At least some of those examples create situations that require 
fallback content in order to work in legacy user agents. In theory, 
<input type="date"> and the like can still be used to input date in 
legacy UAs, where as many other suggestions rely on their fallback 
contents to do this.

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

    Actually, under the current WF2 draft, I don't think it does 
localize to your timezone, so the "11:00:00.0Z" should be "11:00:00.0". 
The "time" input type doesn't send time zone information.

    (Should there be a "time" and a "time-local" to address this? Is 
there even a use case that makes this necessary?)

    So, really, we just need to specify in the formatting hint that the 
meeting time is Norway local time.

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

    Correct. Within reason, fallback should be optimal.

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

    If all dates and times are in the local format when the user views 
the page, this isn't an issue. (See my <date>/<time>/<datetime> idea.) 
I'm personally split on whether we need the CSS or not. I could live 
without it.

Received on Thursday, 27 January 2005 08:39:33 UTC