- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Thu, 27 Jan 2005 10:57:42 -0500
Ian Hickson wrote:
> Ok, I read through the <format> discussion. As far as I can tell there are
> multiple different proposals being mixed into one.
>
> 1. A proposal to control the submission format for WF2 UAs.
>
> I disagree that this is desirable. The whole point of having a type is
> that it means we can all standardise on a single, reliable, unambiguous,
> easy to parse, standard submission format.
It also means that you can't simply whip up a page that uses WF2,
you have to alter the server to support ISO8601. This may not be
possible. Some people have control over the web pages but no control
over the server. This is especially true if your form submits to another
server (Google, Amazon, et cetera.)
> 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.
I fail to see why it would be so difficult to create a library that
converts an ISO8601 date or time into a custom time using a strftime
formatted string. If it's so bloody hard, I'll write it for you.
> 2. A proposal to control the display format for WF2 UAs.
>
> I agree that there might be some (rare) cases where you would want to
> override the UA's default rendering, but that is a presentation issue, and
> as such belongs in CSS or Web Controls 1.0, not Web Forms.
Yeah, that's my current position as well.
> 3. A proposal to display the format the server accepts, for pre-WF2 UAs.
>
> This seems to be a reasonable request -- the question is how to do it.
I think <format> does it nicely.
> The most common suggestion is an element that would not render in UAs that
> supported the new input controls but would in legacy UAs.
>
> Unfortunately, this makes some assumptions that I'm not sure we can make.
> 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.
Either it supports strftime formatting or it doesn't. That seems a
save assumption. Code for this sort of thing can be written once and
distributed under LGPL. What's the problem here?
> Given past experience with the way UAs implement specs a bit at a time, I
> really don't think this is a good assumption.
Please provide a use case for my most current proposal where this
would be a problem.
> 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.
It does more than just provide fallback content. For one, it
provides the submission format for WF2 user agents. Another thing is
that, in theory, a WF2 UA could use the submission format as the one
they display to the user, and either display the content in a manner
similar to legacy clients or simply display the content text as a tooltip.
> On Fri, 21 Jan 2005, Matthew Raymond wrote:
>
>>> http://whatwg.org/demos/date-01/
>>
>>1) It uses a page worth of Javascript to do the work of a single HTML tag.
>
> Most of the JS was added at Jim's insistence, so as to degrade gracefully
> in UAs with two or three users. 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.
I was under the impression I had sent a modified version of your
page that did exactly what you're talking about. (Then again, I didn't
really get to test it...) And that was based on an outdated version of
<format>.
> I can't really see how to achieve that with <format>.
| <format for="time1" value="%I:%M %p %z">
| Format: hh:mm am/pm TMZ
| </format>
>>2) It uses a fallback method of displaying formatting hints that forces
>>webmasters to learn Javascript, even when they may have little or no use
>>for it outside of the date/time formatting issue.
>
> Not really, the code is generic and can be cut-and-pasted.
So it's okay to make them use Javascript because someone else can do
the work for them? And what happens if they have special needs your
script doesn't address?
>>3) It requires that you add the ISO8601 date and time format to your
>>server's date/time parsing, regardless of whether you actually want
>>people to be able to submit data to the server in that format.
>
> And <input type="file"> requires that you support multipart/form-data, and
> using the <select data=""> feature requires that you use a particular
> format, etc. I don't really see why that is a problem.
<select data=""> doesn't require modifying the server in any significant
way. It merely requires that the file referenced in |data| be placed on
the server. The <input type="file"> element, so far as I know, is
already supported. I'm not really following you here.
>>4) On legacy user agents with Javascript disabled or unavailable, it requires
>>the user to delete the format hint when entering a new date.
>
> In most UAs the current value is selected when you tab into a control, so
> that doesn't seem like a serious problem.
Under Windows, if you're using the mouse to click the control, and
you click between characters, the text will not be highlighted, forcing
the user to perform further actions to delete the text.
> Also, as you say, it's only an
> issue when JS is disabled.
Which is entirely possible in some environments.
>>5) On legacy systems, the user can still input ISO8601 dates and times
>>and have them validate on the server, in spite of the fact that the
>>dates and times aren't in the listed format. This may encourage some
>>users to use random date/time formats that the server doesn't support.
>
> I don't follow this argument.
If the page says I should submit using A, but I successfully submit
using Z, I might assume that I can also submit with formats B through Y.
> Also, the demo in question supports most formats, it isn't a big problem
> (and can be abstracted into a library).
First of all, you're creating a scenario where someone could
potentially be using a native format your server scripts don't support.
"Most" may not be good enough. Second, you're making people use your
scripting again just so that they can support markup that was supposed
to make their lives easier.
>>6) It may increase the difficulty of training people to use certain web
>>apps within a corporation, because you must train them to use a
>>different date format on legacy and WF2 user agents.
>
> The Web app can easily be written to use whatever format the WF2 UA uses
> as its legacy format.
You mean the server can use ISO8601 as the legacy format. Again, you
assume that the webmasters not only have access to the server
configuration and scripts, but that they themselves would want to put in
that kind of work just to support WF2.
>>7) If a company has a specific internal date/time format, and they want
>>that format used on all company web apps, they have to configure every
>>WF2 user agent in the company to use that date/time format, since the
>><input type="datetime"> control doesn't provide a method of setting the
>>format the user must enter the date and time with.
>
> A company that requires that all its employees have the exact same date
> and time settings for display purposes has much bigger problems.
I really hate it when you contradict Me-a-week-ago when Me-today
doesn't even agree with Me-a-week-ago! ;)
>>Number 3 is the worst part, in my opinion. You shouldn't have to add
>>parsing on the server just to get a date/time control in WF2 clients,
>
> 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.
> (That's part of the problem we are trying to solve.)
Me have thought: Use multiple <format> elements to submit the
date/time as if it were from multiple controls:
| <label for="meetdate">New Meeting Date: </label>
| <input type="date" id="meetdate" name="meetdate" value="2005-01-30">
| <format name="meetmonth" for="meetdate" value="%m">
| <select name="meetmonth">
| <!-- Month stuff here. -->
| </select>
| </format>
| <format name="meetday" for="meetdate" value="%d">
| <select name="meetday">
| <!-- Day stuff here. -->
| </select>
| </format>
| <format name="meetyear" for="meetdate" value="%Y">
| <select name="meetyear">
| <!-- Year stuff here. -->
| </select>
| </format>
In the above, if the <format> elements have |name| attributes, and
there are no associated <format> elements that lack the |name|
attribute, then the value of the <input type="date"> element isn't
submitted under "meetdate". Rather, the value is formatted using the
formatting strings of each respective <format> element and submitted
under their |name|s. As a result, the WF2 UA user sees one control, but
it's submitted as if there were three.
Now if I could just figure out how to hide the <input type="date">
in legacy user agents, we'd be in business. Then again, perhaps multiple
methods of inputting the date is an acceptable fallback...
>>and you shouldn't have to add Javascript to get a simple format hint on
>>legacy systems. This is overhead that the webmaster really shouldn't
>>have to deal with.
>
> By supporting most formats automatically, like the demo does, I don't
> really see that there is a problem.
But that's just it. There is no automatic support. You used JS, DOM
and a <span> trick that's probably invalid under HTML 4.01 strict. A
hacked solution is NOT better than a markup solution, especially if it
doesn't work as soon as Javascript isn't available.
>>| <label>Start Date: <format value="MM/DD/YYYY">(MM/DD/YYYY)</format>
>>| <input type="date" id="startdate"/></label>
>
> What if the attribute doesn't match the contents?
What if you have a <ABBR> where the long name doesn't match the
abbreviation? What the heck is your point? This is like asking "What if
the webmaster is a moron?".
> What if the UA doesn't support <format> but does support type="date"?
My most recent version of <format> uses strftime formatting to
define the format. So as long as they can take native date and time
formats and convert them using that convention, there isn't a problem.
> What if the user is not a native speaker of English and doesn't understand
> the format, but would understand it if the UA used a native datepicker?
> (I myself have been in this situation when using Norwegian sites.)
I think this assumes forced use of the submission format, which I no
longer support in my recent posts.
> What if there are multiple <format> elements?
It would be incorrect markup, but I would presume that the first
associated <format> wins.
>>One of my concerns with the <format> element as previously defined is
>>that if the users sees a localized version of the date and time in their
>><input type="datetime"> controls, it may not match text dates and times
>>elsewhere on the page or website. As a result, there are only three
>>possible solutions:
>>
>>1) Force the date/time control to display the format of the <format>
>>element (applyon="entry").
>
> I think this would lead to inconsistent and poor UI (as mentioned by Olav,
> I believe).
Agreed.
>>2) Preconfigure the settings of the user agents to display a specific
>>format in all date/time controls.
>
> Obviously this is not under the control of the authors.
Even if it were, the users might override if they have any control
of their browser's configuration at all.
>>3) Require WF2 user agents to display dates and times in the text in a
>>localized format.
>
> Yes, I agree that this is the best solution.
>
>>| <p>
>>| The meeting is currently being held on <date>2005-1-30</date>
>>| at <time>11:00:00.0</time>.
>>| </p>
>>|
>>| <form>
>>| <label>New Meeting Date:
>>| <input type="date" value="2005-01-30">
>>| <format>Format: yyyy-mm-dd</format></label>
>>|
>>| <label>New Meeting Time:
>>| <input type="time" value="11:00:00.0Z">
>>| <format>Format: hh:mm</format></label>
>>| </form>
>>
>>Because the contents of <date> and <time> are already in ISO8601 format, no
>>|value| attributes have to be specified. The format to submit is ISO8601 as
>>well, so format doesn't require a |value| attribute.
>
> 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.
Which means using JS when you may not want to, bigger file sizes and
markup that's harder to read and understand by other webmasters. I
thought one of the points of WF2 was to replace cheap JS hacks.
> However, I don't really see how inventing a
> whole new element just to have legacy UAs handled here is the way to go.
>
> Effectively, <format> is the same as <nodateinput> (c.f. <noframe>). I've
> never been a fan of <noframe> (and <noscript>).
Not true. You can use format without any contents to simply define
the submission format. The contents are no different than the contents
of <object>.
>>| <form>
>>| <label for="meetdate">New Meeting Date: </label>
>>| <input type="date" id="meetdate" name="meetdate" value="2005-1-30">
>>| <format for="meetdate" min="2005-01-25" max="2006-01-30"
>>| value="%m/%d/%Y">
>>| Format: mm/dd/yyyy
>>| </format>
>
> This just seems way over the top, especially given that the only real
> reason to have it at all is for legacy UAs.
>
> At the end of the day, while backwards compatibility is key, there is a
> limit to exactly how many of the new features we add should be designed
> specifically to overcome migration issues.
I've already notices flaws in the example. See the new version of it
later in this message.
[Snip!]
> This has all the problems that I had raised when similar ideas where put
> forward for how to have <input type="date"> fallback on something other
> than a text box.
I never said it didn't. Unfortunately, I don't see how to make a
multi-control fallback without using something other than <input> for
the date, which would be confusing and inconsistent.
>>For people who want specific date formats displayed, perhaps we need
>>special CSS properties for this purpose. Perhaps something like this:
>>
>> date, input[type=date] { format-date: "%m/%d/%Y" }
>
> It's quite likely that the CSS working group will do something like this.
That was my thinking.
I notice you didn't comment on the use of <date>/<time>/<datetime>.
If the users see dates/times in the <input type="date"> control that
conflict with their native date/time formats, won't that cause confusion?
I need to make a few corrections to my most recent post regarding
<format> ("[WF2] The <format> Element II: The Wrath of <date>"). First,
the |max| and |min| attributes belong on the <input> element. Second,
the |value| attribute for the <input> value needs to be in the same
format as the one specified by the <format> element. It will be
converted by the UA to ISO8601, but it should initially be in the legacy
format so that the markup can gracefully degrade. Here's the "Complex
example" modified to address these mistakes:
| <p>
| The meeting is currently being held on
| <date value="2005-01-30">January 30, 2005</date>
| at <time value="11:00:00.0Z">11:00 PM</time>.
| </p>
|
| <form>
| <label for="meetdate">New Meeting Date: </label>
| <input type="date" id="meetdate" name="meetdate" value="01/30/2005"
| min="2005-01-25" max="2006-01-30">
| <format for="meetdate" value="%m/%d/%Y">Format: mm/dd/yyyy</format>
|
| <label for="meettime">New Meeting Time: </label>
| <input type="time" id="meettime" name="meettime" value="11:00 AM">
| <format for="meettime" value="%I:%M %p">Format: hh:mm AM/PM</format>
| </form>
Received on Thursday, 27 January 2005 07:57:42 UTC