- From: Jim Ley <jim.ley@gmail.com>
- Date: Fri, 9 Jul 2004 11:12:22 +0100
On Thu, 08 Jul 2004 22:07:07 -0400, Matthew Raymond
<mattraymond at earthlink.net> wrote:
> Jim Ley wrote:
> > Matthew Raymond wrote:
> > I simply don't think the two tasks can be sovled by a single UI.
>
> So what you're say is that you oppose the inclusion of a date picker
> in WF2 because you can't personally envision a control that meets with
> your approval.
NO! I'm not against a datetime input type, I'm against an input
datetime time that does not provide the author with the ability to
suggest the type of entry widget that is most appropriate for their
users task. I'll be told no doubt that'll be part of Web Controls
1.0 or something as I have been before, but as others other than me
have said, it's very difficult to use any of these if they're not
unified together.
> A combo box. It allows you to both select from a list and enter
> text. In fact, there are Javascript-based date pickers that are very
> similar to a combo box.
A single combo box? with the 40,000 possible days someone can have
been born on? That would work pretty well for perhaps the last 30
sundays, but I don't think it would work well for date of birth.
> Why can't controls specific to these cases be coded by UA developers
> based on the |pattern| and |precision| attributes? Nothing says they
> can't provide different controls based on these values.
because I don't believe pattern and precision provide the information
- for example I want a date and I want it precise to a day is the
same, but doesn't deal with the different tasks of choosing holiday
dates, and entering your date of birth.
> By the time we submit WF2 to a standards organization, we'll already
> have implementations, so authors will know exactly if they want to use
> it or not.
Will the implementations be shipped to users? If so then I'm very
worried about the idea of shipping browsers with non-standard
features, test implementations sure.
I would urge the WHAT WG to pick and take this to a standards
organisation quickly, before releasing UA's.
> I suggest that you use this time to define what you think are the
> best and worst cases of date pickers
The worst date picker is a text box without any information on the
format of date to enter. (exactly what datetime degrades into!) the
best as I've repeatedly said depends on the task.
> They can do this with the aforementioned attributes, and also...
pattern and precision _do not_ suggest styling.
>> What exactly CSS
>> properties did you have in mind for styling date pickers?
>
> If necessary, CSS properties can be developed specifically for the
> date picker and other controls.
Oh right so we're extending CSS aswell as HTML and XHTML, great, I've
been involved in other coups before, glad to see I'm in on another.
> However, what you're really talking about here is poor UI decisions
> on the part of a specific UA.
NO! I'm talking about tasks being different.
> >> The cost of legacy clients is related to the cost of the legacy
> >>markup you use.
> >
> > What do you mean? if I use <input type="datetime"> I don't get the
> > option of legacy markup I just get a text input, or am I misreading
> > something?
>
> With regard to this, we were originally talking about server load.
> You stated that the WF2 date input would somehow increase bandwidth or
> markup.
No we were talking about _server load_ not just bandwidth or markup,
processing random dates is expensive, especially if you're not just
going to reject everything not in a certain format, and if you do
reject a lot, then your bandwidth certainly does go up.
> > This means my server must deal with a random date entry.
>
> You are attempting to argue that <select> controls eliminate the
> need for server-side validation.
I'll quote again what I wrote:
|| I didn't mention validation, I mentioned parsing, particular things
|| like 3/5/4 - what does that mean in the context of a date?
I'm talking about PARSING, not validation, what does the above (and
that's a simple date format, people enter all sorts of things)
Select entries arrive on the server in say 3 entries Day Month Year.
To convert this into a date to get a date object for validation it's
simple. The same is not true for what people enter into a text box.
> It's the same problem as with phone numbers, social security numbers
> and other formatted numerical date, and it has the same solution: post
> an example format. Example: MM/DD/YYYY.
Could you show me an example WF2 page using datetime that degrades to
that please? Since the example format solution makes no sense if the
datetime element is rendered by a WF-2 user agent.
> Thank you for completely ignoring the following text I included in
> my last message: "I'm not suggesting this is the best solution, BTW. I'm
> just making a point." I did, in fact, see better examples of date format
> checkers,
great give me some URI's - remember you're claiming these are common
and free, I don't believe it is remotely possible (hint the best ones
will be on Dr. John Stocktons pages)
> First of all, there is more than one month that has only 30 days,
Er, so? I'm missing the relevance of this statement to what went before.
> Second, it would probably take more than 10 lines of code to both
> determine how many days are in a single month in a single year AND
> change the values in the day drop-down to reflect that.
I didn't ask anything about changing drop downs, I simply want date
validation of a text box - but incidently it would be about 6.
(although obviously to use this on the web you'd need more error
checking)
var d=new Date(1,month-1,year);
select.options.length=0;
while (d.getMonth()==month) {
select.options[d.getDate()-1]=new Option(d.getDate()));
a.setDate(a.getDate()+1);
}
(completely untested, but the method is sound)
> However, is the fact that text box isn't always the PERFECT
> degradable solution really so significant that it offsets the benefits
> of a date picker for WF2-compliant UAs?
I believe it is so yes, or at least it's such a bad degradation that
it won't get used, it suffers two problems you can't deal with leagacy
clients effectively unless you add extra text to the page which will
just confuse datetime picker people. And there's no way to suggest an
appropriate control for the task, making desiging harder.
Jim.
Received on Friday, 9 July 2004 03:12:22 UTC