[whatwg] Re: several messages

[Matthew Raymond]

Ian Hickson wrote:
> On Mon, 31 Jan 2005, James Graham 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.
>>
>>In general, it is easy to make WF2 pages incompatible with older 
>>browsers.
> 
> Granted, but at least it's not the default.

    When using the inheritance feature of <idate>, incompatibility isn't 
the default either, and the only situation in which you can't use 
inheritance is when the first child control doesn't submit a complete 
date. You're arguing a "Rogue Webmaster" scenario.

>>>* The fallback and non-fallback controls have different names.
>>
>>Why is that a problem? Would it not be a simple if construct on the 
>>server side to deal with the two cases?
> 
> Having two different forms (as opposed to one form with just better 
> behaviour in newer UAs) is something that the current WF2 design has, by 
> and large, been striving for.

    I know has support for having multiple forms use the same controls, 
but what does that have to do with multiple controls being used for the 
same field?

>>>    2. <select> controls, which do not need to be replaced at all,
>>
>>If that's really true, then all the date types seem a little pointless. 
>>I thought that one of the advantages of the WF2 controls was allowing 
>>sites to present a consistent, OS-specific interface to form controls. 
>>If multiple select controls are as good a solution, there seems little 
>>point in implementing or using WF2.
> 
> Indeed. Three <select>s are reasonably good UI, although not as good as 
> type="date" on a supporting UA. While WF2 UAs are not in the majority, 
> there's not really a huge advantage to using the new types. (This applies 
> to <idate> et all as well, by the way.)

    Are you arguing against the use of <idate> or against the use of 
<input type="date">?  Most dates are entered via the three <select> 
scenario. Therefore, if there's a compelling reason to use <input> in 
those cases, then <idate> is even more compelling.

> Similarly, while XHTML is not supported in the majority of UAs, there's 
> not really any reason to use XHTML. That doesn't mean that XHTML is bad, 
> indeed, XHTML (and especially the ability to create compound documents by 
> mixing namespaces _with_ XHTML) is great. But there's no reason to rush 
> off and use XHTML in the meantime.

    I fail to see how this argument supports the use of <input 
type="date"> and doesn't support the use of <idate>.

> The difference is that if you _do_ want to use type="date", you can do so, 
> and legacy UAs will still work (albeit not as user-friendlyly).

   Same is true for <idate>, unless--EGADS!--Not the Rogue Webmaster!!!

 > With
> XHTML, it's an all-or-nothing deal. With <idate>, it doesn't have to be 
> all-or-nothing, but authors are likely to take the easy route and thus not 
> provide any fallback content. (Just look at how many authors provide good 
> fallback content for images.)

    The difference here is that text-base browsers, so far as I know, 
where NEVER the most popular type of browser, so there was little 
incentive for fallback. Not to mention the fact that IE corrupted the 
meaning of the |alt| attribute by using it for tooltips...

>>>    3. Complex JS widgets, for which declarative fallback is not needed.
>>
>>Why not? If one is replacing a javascript control with a WF2 control, 
>>one can improve the accessibility of one's page further by providing 
>>simple controls for legacy clients (this would be equivalant to say, 
>>producing a CSS based design and allowing old browsers to recieve 
>>unstyled content v using a table based design and blocking old browsers 
>>entirely).
> 
> I said _declarative_ fallback was not needed. If you're using JS, you can 
> easily implement the fallback yourself using JS.

    The <idate> element doesn't need JS at all. You're requiring 
webmasters to either learn scripting for legacy content, or depend on 
his Javascript programmer buddy to do the work for him.

>>>...not to mention the extra complexity and the implementation 
>>>difficulty compared to just using a new "type".
>>
>>Really? Obviously you're much more familiar with the browser engines 
>>than I am but I'm not sure that this is obviously difficult to 
>>implement. At least not obviously a lot more difficult than WF2 datetime 
>>controls are anyway. Is there something specific that browsers will 
>>struggle to cope with?
> 
> Nothing specific. Just every little added bit of complexity. I'm already 
> getting requests from implementors to drop the entire repetition model, 
> and to massively simplify the validity stuff, etc. And those aren't 
> particularly hard to implement.

    The repetition model is MORE complex than <idate>. Besides, isn't 
this what the implementation phase is for? Isn't the who point of the 
implementation phase to find out what people will actually implement and 
adjust the draft accordingly? Stick <idate> in, give the draft one more 
call before the implementation phase, and if people hate it, take it out 
before the implementation phase, or if people like it, but it's too hard 
to implement, it'll get dropped in the implementation phase.