[whatwg] Re: several messages

James Graham jg307 at cam.ac.uk
Mon Jan 31 09:44:52 PST 2005

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,

>     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 

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

More information about the whatwg mailing list