- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 28 Jan 2005 15:31:52 +0000 (UTC)
On Thu, 27 Jan 2005, Matthew Raymond wrote:
> >
> > 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.
I find it very hard to believe that this would be a common problem.
Supporting ISO8601 is pretty easy. It's one of the simplest date/time
formats to parse.
And yes, it means you can't write a page and have it submit to someone
else's server if they don't support ISO8601 yet. That is an edge case. I
really don't think we need to support that. It certainly doesn't deserve
so much attention that all UAs should support it and the model should be
made more complicated for everyone else.
> > 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.
I'm not sure what you mean. I was referring to the fact that if all UAs
submit dates and times in ISO8601 format, then libraries like CGI.pm can
simply have methods that convert incoming dates and times into appropriate
types before the site-specific server-side code processes it.
> > 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.
Obviously I don't given the problems I listed with it. :-)
> > 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?
Nothing to do with strftime formatting (indeed I'm not sure where that
comes in). I meant cases such as:
<p> <input type="date"> <format>...</format> </p>
<p> <input type="time"> <format>...</format> </p>
<p> <input type="datetime"> <format>...</format> </p>
<p> <input type="month"> <format>...</format> </p>
<p> <input type="week"> <format>...</format> </p>
...in a UA that only supports type="date" and type="time". What will get
displayed?
> > 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.
<p>Please insert the date: <input type="date"> <format> DD MM YYYY </format> </p>
<p>Please insert the time: <input type="time"> <format> HH MM </format> </p>
...in a UA that only supports type="date".
The reason <format> is being proposed (as I understand it) is to help with
migration. Once all UAs support the new types, assuming we're lucky enough
to ever get there, <format> will no longer be useful. In the meantime,
though, we will have UAs that support some types and not others. So any
solution we have has got to be able to handle that -- and ideally, without
any work on the UA implementor's part, because it is the fact that the UA
hasn't finished his work that leads to this problem in the first place (so
we can't give him more work and expect that to address the 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.
If we were to have a way to change the submission format, it would be
using an attribute on the <input> element. It makes no sense to have it on
another element.
> 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.
"In theory" isn't really, IMHO, good enough reason to add a whole new
element at this stage in the process (if ever -- most of the elements that
we added at the start of the WF2 work which were added for theoretical
reasons have now been removed for practical reasons, in fact).
> > 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>.
It didn't handle hiding the format just for supported types, which was one
of the main issues I had with your proposal.
> > 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>
I hate to say this, but that's way too complicated. :-)
> > > 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?
They don't _have_ to use the JS. If they want to, they can.
Certainly I don't see that providing JavaScript like in the demo is any
worse than the JS people provide now to do pulldown menus, or, for that
matter, any worse than asking them to understand the <format> example you
gave above. :-)
> > > 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.
<input type="file"> is supported _now_, but it wasn't when it was
introduced.
Yes, supporting type="date" et al will require changes on the server side.
It will also require changes on the HTML side, and probably on the CSS
side, and various other places. New technologies tend to require changes.
The key is that those changes can be made without making the page
completely useless (as useless as IE asking you to download the file, for
instance, as with XHTML), so that users with new UAs can use the file and
benefit from new features, while users of legacy UAs can use the file,
albeit in a sub-optimal way.
> > > 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.
Like double-clicking before you type. True. Again, not a huge deal.
> > Also, as you say, it's only an issue when JS is disabled.
>
> Which is entirely possible in some environments.
Yes, but enough of an edge case that it shouldn't drive the development of
the spec, especially not to the point of adding a new element and all its
associated logic.
> > > 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.
Why would you even try Z? And why would it be a problem? The moment you
try B or Y, it tells you it doesn't work. Where is the problem?
> > 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.
No, I'm suggesting that supporting multiple formats is not a big problem,
in case they care enough to do so. The idea behind the date inputs is to
make it easier on the medium run, just like <object> makes things easier
on the medium run; not to solve the world's data entry problems overnight.
Many sites today just have a single text entry field without even
specifying the expected format (I listed some 30 or more a few months back
when we last discussed this in detail). These will be immediately helped
by the new input types, as the legacy case is not hurt at all, and new UAS
are helped.
In the middle complexity range we have sites that use groups of <select>s.
These are not likely to change to use the new types, as they don't offer a
great advantage over <select>s. Once most deployed UAs support WF2, then
medium-complexity sites like this may well start using the new date types.
At the high end of the complexity range we have people with massively
complex calendar widgets. These sites mainly target only the top tier of
Web browsers. Once the top tier of Web browsers support WF2, or can be
made to support WF2 through JS or similar tools, then such sites could
well switch to using the new inputs, which would help users that can't use
non-accessible widgets like custom calendar controls.
Authors of high-end sites won't switch to new features until they are
quite well understood. So immediate migration is not an issue.
Authors of medium-complexity sites might switch earlier, but their
switching is not a big deal because their widgets are already pretty
accessible.
Authors of low-end sites might switch as soon as tutorials are updated,
which would give an immediate improvement.
I don't really understand which level your <format> proposal is aimed at.
> > > 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.
No, I mean the server can support ISO8601 and whatever the legacy format
is, which can be explicitly set up to be whatever the WF2 UAs display, so
that you don't have to train users in two different formats.
> 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.
The amount of work we're talking about is as much as trying to understand
how <format> works, along with debugging it when it is handled differently
in different UAs, IMHO.
> > > 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>
Um... We've gone from:
<label>New meeting date:
<input type="date" name="meetdate" value="2005-01-30">
</label>
...to a multiple-dozen line monster, just to support backwards
compatibility in a case where most authors are just going to support one
or the other anyway?
I'm sorry, but the extra level of complexity there is completely out of
proportion with the problem you are trying to solve.
> > > 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.
Of course it's invalid HTML4 Strict. It uses new form types.
> A hacked solution is NOT better than a markup solution, especially if it
> doesn't work as soon as Javascript isn't available.
It does keep working, just slightly less well.
The important thing, though, is that it doesn't rely on implementors
having implemented the fallback element correctly.
> > 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.
The point is to replace JS hacks so that in newer UAs things can work
declaratively. We're specifically targetting older UAs here.
It's also quite clear from the Web that using JS is not a blocking problem
for most authors (especially when it can be done without looking at the
code and without anything breaking when JS is disabled).
> > 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.
If that was something we wanted to address, it would be addressed by an
attribute on <input>, not a new element (we don't have <min>, <max>,
<step>, etc, either).
> The contents are no different than the contents of <object>.
...except that once you remove the submission format thing, which IMHO is
trying to solve a different problem, you end up with never using the
fallback in a compliant UA, and the element being effectively
<nodateinput>.
> > 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.
Me neither. Not making a multi-control fallback seems fine to me.
Note that while <input type="date"> is a significant step up from either
<input type="text"> or the complex JS-based or image-map-based calendars
of today, it is _not_ a significant step up from <select>-based date
input, at least from an accessibility point of view.
If you are concerned enough to target legacy UAs with a multi-control
solution, then just use that for WF2 UAs as well.
> I notice you didn't comment on the use of <date>/<time>/<datetime>.
I think it's a good idea. It'll probably be in WA1.
> 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 don't follow.
> | 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>.
That seems fine.
> | <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>
Having value be in a different format that min and max seems confusing.
Having value not be in a single standard format seems bad (e.g. for
automated validation, not to mention implementation).
> 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?)
I thought about it but couldn't really find a case where I wanted a time
with a defined time zone but didn't want a date.
> So, really, we just need to specify in the formatting hint that the
> meeting time is Norway local time.
Meetings should be scheduled with input="datetime", not separate date and
time controls.
> | <dateinput id="date" value="2005-01-30">
> | <range min="2005-01-25" max="2006-01-25">
> | <submit name="month" format="%m">
> | <submit name="day" format="%d">
> | <submit name="year" format="%Y">
> | <!-- Fallback content -->
> | </dateinput>
>
> Or, for WF2-only solutions:
>
> | <dateinput id="date" value="2005-01-30">
> | <range min="2005-01-25" max="2006-01-25">
> | <submit name="date">
> | </dateinput>
>
> This provides PERFECT fallback content, and lacks most of the
> disadvantages of <object> while having all its strengths. In fact, I've
> half talked myself into using this format just having typed it right
> now...
...or, in current WF2:
<input type="date" value="2005-01-30" min="2005-01-25" max="2006-01-25"
name="date">
...with no fallback apart from a text field prefilled with a date in the
expected format.
Let's please keep things at least somewhat simple.
> Here's where we make a hard left turn into the Twilight Zone. Suppose,
> simply by adding a special <submit> child element, you can turn mild
> mannered <date> into a full-blown date control:
>
> | <label>Event Date: <date><submit name="date">2005-01-30</date></label>
>
> So if you wanted a date control with ISO8601-compliant fallback content,
> you'd do this:
>
> | <label>Event Date:
> | <date value="2005-01-30">
> | <submit name="date">
> | <input name="date" value="2005-01-30"><br>(Format: yyyy-mm-dd)
> | </date>
> | </label>
This means authors _must_ think of fallback content, instead of the form
control just turning into a text field when the author forgot about the
users stuck with old browsers.
It also means using at least two elements over three tags instead of just
one with a couple of attributes.
> PROS:
> * A single element is used for all dates/times in all circumstances.
I don't see why it's a good thing that inputs and outputs share one
element. (I originally had <input type="output">, which would have had
better backwards-compatibility, but now WF2 has <output> because
fundamentally the two things are different, even if one would be better
for back-compat.)
> * Near perfect graceful degradation, especially when you want multiple
> legacy controls.
Only if the author thinks about it. Otherwise you input control either
disappears or gets rendered as only text in legacy UAs.
> * Submission formatting for the server is highly flexible, eliminating
> the need for changes to the server to accommodate WF2 in most cases.
I'm not convinced that's a problem that needs solving.
> CONS:
> * Not quite as simple as <input type="date">.
This is, IMHO, a big problem. The current solution allows type="text" to
be changed to type="date" easily, to address usability issues on low-end
sites very quickly.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 28 January 2005 07:31:52 UTC