[whatwg] Re: several messages

[Matthew Raymond]

Ian Hickson wrote:
> On Mon, 31 Jan 2005, Matthew Raymond wrote:
>>>It has problems, as mentioned elsewhere in the thread:
>>>
>>> * It is easy for authors to not include any fallback, which makes it
>>>   worse than the <input> equivalent.
>>
>>If the legacy fallback is simply an <input>, then inheritance handles it 
>>nicely. If you start with this:
>>
>>| <input name="date" value="2005-01-31"> Format: YYYY-MM-DD
> 
> But you don't. Many, if not most, WF2 documents will be new documents.

    There's nothing in WF2 that requires a fundamental rewrite of 
existing HTML documents. Assuming most WF2 documents will be created 
from scratch is not a safe assumption.

> There is no existing content. Authors would just do:
> 
>    <idate name="date"/>
> 
> ...or some such, and be done with it.

    First of all, why would they do such a thing unless they 
specifically didn't care about legacy browsers? Furthermore, WF2 user 
agents will have little initial marketshare, so why would someone target 
them and leave out legacy support? This is especially nonsensical when 
you notice that supporting legacy UAs in a manner similar to <input 
type="date"> really isn't that hard:

| <idate><input name="date"></idate>

    And they're going to have to know how to use <input> to create forms 
anyways. If anything, <input type="date"> is just as confusing because 
it requires you to set the |type| attribute when the webmaster may have 
only learned this:

| <input name="date">

    Furthermore, although the markup doesn't have a built-in fallback, 
neither does <datalist> or the |data| attribute. In both situations, you 
can have critical content that you potentially can't use in legacy browsers.

>>Therefore, I see no reason why a webmaster would choose to drop their 
>>legacy content when upgrading their websites to use <idate> and its 
>>siblings.
> 
> The problem is assuming the Web author is upgrading a Web site in the 
> first place. It could be a new one.

    If they're new websites, marketshare should force most webmasters to 
add legacy support. Anyone remotely serious about legacy browsers is 
going to put it in anyway (especially since it only takes one <input> 
element).

>>The only issue here is whether or not a grandfather or soccer mom who 
>>knows virtually nothing about legacy support would put in the proper 
>>legacy content. For these individuals, you simply write a tutorial that 
>>tells them to do something like this:
>>
>>| <idate><input name="date" value="2005-01-31"></idate>
>>
>>This can be explained to the user easily enough: "Pretend you're going 
>>to enter the date as text, then slap <idate> tags around it." It's not 
>>rocket surgery.
> 
> But it's more complicated than the current text, which works for both new 
> and old browsers.

    Assuming that the default for an <input> with an unidentified |type| 
attribute is text, which is not specified in the HTML 4.01 spec. So, in 
theory, there may be browsers out there that will drop <input 
type="date"> entirely, in which case there is no fallback.

> Sure, the fallback isn't as ideal when the author is 
> trying hard to provide fallback, but (as described elsewhere in this 
> thread) I simply don't see that these particular features (date) will be 
> interesting to authors of that caliber.

    I think I can come up with a few features:

1) Localization - Date is always formatted in a way the user understands.

2) Stability - Webmasters don't have to worry about DHTML date controls 
crashing on WF2 user agents.

3) No Javascript - The date control will still work, even when the 
browser has Javascript turned off.

4) Speed - A hardcoded widget will work faster than a DHTML version and 
require less memory on the host system.

>>> * The fallback and non-fallback controls have different names.
>>
>>This is only true of the 3SC scenario, and in that situation the server 
>>script can easily be rewritten to handle the situation.
> 
> I thought we had to assume the server couldn't be changed?

    I thought I'd already acknowledged in a previous message that most 
people on this mailing list felt client-side formatting was a bad idea. 
That's why I call it "<idate>" now instead of "<date>".

>>> * The datetime types don't really need comprehensive fallback, given
>>>   that the three cases that they could replace are:
>>>     1. Text inputs, which would be improved, not hurt, by the new
>>>        types,
>>
>>Except you never solved the formatting hints problem to anyone's 
>>satisfaction
> 
> I still don't understand what is wrong with the short amount of black-box 
> JavaScript I proposed.

    Another opportunity for a list!

1) It didn't deal with default date values. Where would the script get 
the format string from if it wasn't in |value| attribute?

2) It relied on a empty <span> element, which doesn't validate under 
HTML Strict.

3) With Javascript turned off, you have the problem of having to select 
and delete the format hint text in some situations.

4) New webmasters, who don't understand how the script works, will 
easily break it.

5) The script takes up nearly as much space as the HTML!

    By contrast, my modified version using <idate> probably cut the size 
of the demo web page in half and supports the same features.

 > It handles more cases than your proposals with no
> work on the UA implementor's behalf.

    Well, there's certainly not much of a case for that if you consider 
typing to be the work in question:

| <input type="date" name="date1">

| <idate><input name="date1"></idate>

    The best <input> can hope for is beating <idate> by three 
characters. If you add scripting into the picture, <input type="date"> 
immediately takes longer to type.

    Furthermore, the above code doesn't require the web author to know 
anything about the attributes of <idate> unless they specifically want 
to use three <select> elements or some similar scenario. Even then, the 
attributes are the same as <input>.

    So the real question is: How does the marginal added complexity of 
<idate> offset the benefit?

> Not to mention that many of the authors who fall into this "1" category 
> simply don't provide formatting hints at all.

    I want to see three URLs for examples of webmasters using textboxes 
for dates but not providing any kind of formatting hint anywhere on the 
site. All three examples of textboxes used for dates have had formatting 
hints of some kind. QJump has in recent times dropped them from their 
front page, but does include them when it asks you to verify your 
journey details. (And in other places they use <select> elements.)

 > The authors who are likely to care about fallback formatting hints
 > simply wouldn't use text inputs in current pages anyway, and therefore'
 > aren't, IMHO, part of this category.

    There are plenty of reasons for them to care, not the least of which 
is localization and client-side date validation. Plus, as I've pointed 
out in previous messages, Javascript is required for a three <select> 
solution because the number of days in a month changes month-to-month.

>>nor did you explain how to handle legacy sites that use <input> + DHTML 
>>solutions.
> 
> That would be category 3 below.

    What's your point? If <idate> easily handles category 3, then it's a 
more complete solution than you're offering.

>>Elements like <idate>, as seen above, solve this problem in a simple, 
>>straight-forward and effective manner.
> 
> IMHO it is neither simple, nor straight-forward, nor effective, and has 
> serious drawbacks, as I have described. It certainly isn't a bad solution, 
> but it isn't, IMHO, any better than what we have already.

    I don't feel you've made your case. It may not be as simple in the 
best case scenario as <input type="date>, but it's still pretty darn 
simple. It's a lot more straight-forward in handling formatting hints 
than your demo script. It's a lot more effective in allowing legacy 
fallback.

    The supposed drawbacks, in my opinion, aren't serious. People who 
can't understand the markup aren't likely to be smart enough to 
hand-code HTML anyways. For those who use editors that don't support 
WF2, it's just as easy to create a textbox control and slap two <idate> 
tags around it as it is to create a textbox control and change the 
|type| to "date". In fact, some editors can be easily configured so that 
you can simply select the <input> element and press a button.

    As for pages intentionally written without fallback, legacy browser 
users, who will remain in the majority for perhaps years to come, can 
simply elect to to visit such pages, thus decreasing their hit counts. 
So if the webmaster cares if people visit her/his site, he/she will 
support legacy clients.

>>>     2. <select> controls, which do not need to be replaced at all,
>>>        and
>>
>>Yes you do. In fact, if people prefer using <select> controls for legacy 
>>input, then failing to support it will drive people away from WF2, at 
>>least where the date/time markup is concerned.
> 
> Why would this be a problem? As I said before, we're not trying to get 
> people to use WF2 for the sake of using WF2 here.

    We want them to use it because it's a better solution. However, if 
it's a better solution only on a few new browsers, but a worse solution 
on legacy browsers, which are in the majority, that makes WF2 a worse 
solution over all.

>>It may even give some user agent vendors reason not to implement parts 
>>of the WF2 spec.
> 
> I highly doubt that use or lack of use of type="date" on sites will affect 
> whether UAs implement it or not. There are plenty of counter-examples. 
> (Nobody uses XForms, yet IBM implements it in Mozilla; lots of people use 
> XSLT, yet Opera isn't implementing that, etc.)

    XSLT is being used by Microsoft as one excuse for not supporting web 
standards. It also can just as easily be done on the server as the 
client, so there's no reason to put it in the browser. Therefore, Opera 
had a reason not to implement it.

    XForms has yet to come out of beta on the Mozilla platform, and as I 
recall, Opera isn't going to include support because it's so complex. 
That complexity has given vendors reason to delay or even decide against 
implementation.

    So I don't see how those example help your case. In both situations, 
problems with the technology limited UA support.

>>>     3. Complex JS widgets, for which declarative fallback is not
>>>        needed.
>>
>>Having a consistent, localized, canned date control is something 
>>webmasters are going to want even if they have complex DHTML widgets. 
>>However, they're not going to want to get rid of their DHTML widgets on 
>>legacy clients that are still bound to be around for many years. As a 
>>result, if you make it nigh impossible for them to use their widgets as 
>>a fallback, they're just going to continue using them because they know 
>>they'll still work on WF2 user agents.
> 
> If they have complex JS widgets, they can implement the fallback in JS 
> trivially. That's what I menat by "_declarative_ fallback is not needed".

    Javascript must be loaded and executed on all browsers unless it's 
content the browser recognizes as fallback. Therefore, with <input 
type="date">, a script will always have to be loaded and run regardless 
of whether or not the UA supports WF2. And you yourself have shot down 
any means of WF2 support detection.

    By contrast, <idate> can be used to prevent execution of a script:

| <idate name="date1">
|  <script type="text/javascript" src="datepicker.js">
| </idate>

>>>...not to mention the extra complexity and the implementation
>>>difficulty compared to just using a new "type".
>>
>>Elements like <idate> are identical to <input> with respect to the 
>>widget they use, and they have the same attributes that <input 
>>type="date"> would have without adding additional ones.
> 
> Yet they have a host of differences: They don't appear in the .elements 
> array in legacy clients, they don't automatically get support for things 
> like autofocus when UAs implement that, all kinds of event handling 
> happens differently for legacy UAs than new UAs, etc etc etc.

    I'm not following you. HTML 4.01 compliant legacy clients ignore 
unrecognized tags. WF2 clients will still be able to perform new event 
handling, et cetera, on <idate>. If <idate> isn't supported on a "WF2" 
client, then attributes can still be placed on the <input> (and, in 
fact, <input type="date"> could be used in fallback, with its WF2 
attributes being inherited by <idate> on fully-compliant WF2 browsers). 
Can you give me a specific problem or conflict?

>>Could you provide a use case where implementation would be an issue?
> 
> I have no idea what you mean by this.

    Can you give a specific situation where the way I've specified 
<idate> would cause a problem for implementation of <idate> as part of WF2?

>>If the user agent vendor doesn't want to implement the inheritance part 
>>of the spec
> 
> See, part of the problem is that it _has_ an "inheritance" part. It just 
> isn't simple.

    How so? I could write Javascript that could copy attributes for a 
child to a parent.

>>Now, I suppose a user agent might implement the non-inheritance version 
>>of <idate> without rendering the legacy content for inheriting markup, 
>>but why would any sane developer (aside from Microsoft, perhaps) do 
>>this? (I thought about an "inherit" attribute or something, but the only 
>>real use for this is to help user agents without inheritance support 
>>find elements that use inheritance.)
> 
> It has nothing to do with sanity. Why would any sane developer implement 
> the CSS parser incorrectly? Why would any sane developer screw up the 
> implementation of absolute positioning, or margin collapsing, or whatever?

    I was under the impression we were providing our own HTC solution 
for Internet Explorer. In that case, we'd implement it correctly. If WF2 
was to become popular enough for Microsoft to consider implementation, 
the breaking various sites caused by Microsoft's incorrect 
implementation would either result in an outcry that would force them to 
correct it, a major exodus from IE, or mass numbers of people refusing 
to upgrade their browsers to the newest IE version. It just doesn't make 
sense. If Microsoft wants to directly sabotage WF2, they could just 
implement a slightly different competing standard, and they would have 
to mess with the inheritance of <idate> at all.

>>Perhaps the best solution is to leave <input type="[timeunit]"> in the 
>>specification, add <idate> and it's siblings, and let the best element 
>>win in the implementation phase. Besides, there's no reason the two 
>>can't coexist, and they'd very likely share a lot of the same code.
> 
> That's tantamount to the way UI developers who can't make their mind up 
> throw in a pref. "Let the user figure it out."

    Or perhaps it's like <input type="button> and <button>. Two similar 
solutions that each have their own benefits under certain conditions.

>>Just thought of something. In XHTML, <idate> would actually take up less 
>>space than <input> when no legacy content is used:
>>
>>| <input type="date" name="date1"/>
>>
>>| <idate name="date1"/>
> 
> The _huge_ difference here being that the former has legacy fallback, and 
> the latter doesn't. That, for me, is a blocker.

    The problem is that the former provide next to no legacy fallback, 
where as the latter can provide whatever fallback you want. Ideal 
fallback for the least likely approach to date input is pointless. It's 
almost as bad as introducing a new element without the ability to 
provide fallback.