[whatwg] Re: several messages

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 is no existing content. Authors would just do:

   <idate name="date"/>

...or some such, and be done with it.


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


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



> >  * 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?


>>  * 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. It handles more cases than your proposals with no 
work on the UA implementor's behalf.

Not to mention that many of the authors who fall into this "1" category 
simply don't provide formatting hints at all. 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.



> nor did you explain how to handle legacy sites that use <input> + DHTML 
> solutions.

That would be category 3 below.


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


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


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


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


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


> Could you provide a use case where implementation would be an issue?

I have no idea what you mean by this.



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


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


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


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 3 February 2005 05:59:44 UTC