[whatwg] Re: several messages

[James Graham]

Ian Hickson wrote:

>On Mon, 31 Jan 2005, James Graham wrote:
>  
>
>>>| <label for="d1">First Date:</label>
>>>| <dateinput id="d1" name="d1" value="2005-01-30">
>>>|  <select name="d1_month"><!-- Options --></select>
>>>|  <select name="d1_day"><!-- Options --></select>
>>>|  <select name="d1_year"><!-- Options --></select>
>>>| </dateinput>  
>>>      
>>>
>>I haven't been following all the discusion about date formats but, 
>>subject to that proviso, this construct alone (without any inheritance 
>>of attributes) seems to address the major concern that has been raised 
>>about the datetime types (lack of a decent way of providing fallback). A 
>>WF2 UA would simply display:none all children of the dateinput element. 
>>    
>>
>
>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.

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

> * The datetime types don't really need comprehenive fallback, given
>   that the three cases that they could replace are:
>     1. Text inputs, which would be improved, not hurt, by the new types,
>  
>
True.

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

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

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

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs