[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working

[Matthew Raymond]

Jim Ley wrote:

> 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 don't have a problem with WF2 being expanded to handle specific 
date and/or time scenarios. What do you have in mind?

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

    When I mentioned WC1, I was referring to the creation of custom 
solutions that can't be accomplished with Web Forms 2.0. WF2 obviously 
can't handle all possible scenarios.

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

    You misunderstand. I was pointing out that some methods of date 
selection have a text box and a button next to it that brings up a date 
picker popup, which bares a conceptual similarity to a combo box. I was 
not suggesting that a pure combo box should be used as a date picker.

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

    Are you suggesting new input types, like "date-no-year" or 
"date-holiday"? Actually, while the "date-no-year" might be fine, the 
holiday thing would be difficult to do, since holidays vary from company 
to company, let alone between countries. I think the holiday situation 
is better left to <select> elements. Then again, perhaps you have an 
idea regarding this...

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

    ??? You're worried about products with non-standards-body features 
that degrade into supported standards?

> I would urge the WHAT WG to pick and take this to a standards
> organisation quickly, before releasing UA's.

    Don't some standards organizations require implementations before 
they release recommendations?

>>   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!)

    Well, this problem can be solved by labels or tooltips (via the 
|title| attribute), but then these clearly do not apply when using a 
WF2-compliant user agent. Then again, you could simply set the |value| 
attribute to the format hint string. A WF2 client could then simply 
ignore any |value| that isn't an actual date.

    Another solution is to use scripting to insert a label or tooltip 
for legacy user agents.

>>   They can do this with the aforementioned attributes, and also...
> 
> pattern and precision _do not_ suggest styling.

    No, instead they allow user agents to more intelligently handle 
specific situations. I do see your point that they are not 
presentational. However, they really shouldn't be, since they are HTML 
and thus shouldn't be used for styling anyway.

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

    CSS is in the charter, and CSS enhancements are also in some of the 
drafts. It's not like this wasn't a possibility. We're already adding 
stuff to DOM. CSS is also the appropriate place to introduce new styling.

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

    That's assuming there is no scripted validation on the client side. 
It also assumes that rejection of legacy client submissions will not be 
counterbalanced by a savings resulting from WF2 date selection and 
client-side validation on compliant user agents.

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

    There have been algorithms around to parse date strings since before 
the days of Infocom, so I don't see what the big problem is. The QJump 
link someone posted earlier even has such client-side validation.

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

    No, because as I stated before, you can't be sure that the server 
will receive a value contained in the original <select> elements sent to 
the client. As a matter of security, you must ALWAYS assume that the 
values may have been intercepted and changed, or that the client 
deliberately (or otherwise) changed the values.

 > The same is not true for what people enter into a text box.

    This is assuming there is no scripting for client-side validation. 
With client-side validation, there is no increase in bandwidth, because 
the scripting will not let the page submit an invalid date.

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

<input type="date" name="date1" value="MM/DD/YYYY" />

    The current date could also give formatting information. Also, 
scripting could inform the user of the correct format, such as with QJump.

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

    Why? Does Google not work on your machine? Besides, we can always 
ask Dean Edwards to write as script like this while he's sleeping. I'm 
not going to waste my time looking for free Javascript versions of date 
parsing algorithms that go all the way back to before I was born.

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

    Not sure what you mean. My point was that if you're picking date, 
month and year from <select> elements, a certain about of validation 
must occur to ensure you don't give a value for the date that can't 
occur for a specific month and year.

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

    Nice solution, although is doesn't account for the creation of 
"select", "month" and "year", and may not work in all implementations of 
Javascript because you assume that setDate will increment the month if 
given an out-of-range date value.

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

    By the time you read this, you've already seen examples of where it 
will get used posted in other messages.

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

    I addressed this above.

> And there's no way to suggest an
> appropriate control for the task, making desiging harder.

    I'm confused. Do you want MORE input types, or are you suggesting 
another attribute (which I believe some people on this mailing list 
would oppose). I would support the former. I have mixed feelings about 
the latter.