[whatwg] Re: several messages

[James Graham]

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.
>  
>
True and I'll grant that such a situation is less than ideal. But given 
the high penetration of non-WF2 browsers, it is unlikely that anyone 
will be producing WF2-only content for some considerable time to come. 
Comparisons with missing alt-text and with sites requiring javascript 
are rather misleading. Alt text suffers because graphical browsers have 
such high penetration that many designers believe that everyone will see 
their graphics (and at the 98 or 99% level, they are probably right). 
Good alt text is also *very* hard (and sometimes impossible) to write 
since one has to replace the often complex content of a picture with a 
few words. There is also the historic problem of alt-text-as-tooltips 
which produced significant confusion as to the point of alt text. With 
WF2 date types, none of these points apply.
Javascript is also a poor comparison since javascript allows 
fundamentally new features to be implemented by the website compared to 
those allowed with pure markup. This means it is often difficult for 
designers to envision how their carfully designed interaction model for 
a site should work without the extra scripting features. Then since the 
javascript-enabled population is currently a significant majority of web 
users.

>>>* 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.
>  
>
Which is easy to achieve when the WF2 control is well represented as a 
single HTML4 control. There seems to be some agreement that this isn't 
the case for date controls (single textboxes are much harder than 
necessary to use). It seems a shame to sacrifice a useful feature for a 
design ideal that is of limited practical benefit.

>
>  
>
>>>    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.)
>  
>
So are we planning to suggest that people not use the new date types 
until the uptake of WF2 reaches some magic value (what value?). I think 
taking the position that people should hold off using new features until 
they are supported everywhere rather diminishes the point of having 
backward compatibility, considering the extra trauma that specifying a 
backward compatible syntax for everything creates. It also ignores the 
feedback between users and UA authors. Opera are implementing 
XmlHttpRequest as a direct result of a site (GMail) using a feature that 
they didn't support. Mozilla dropped MNG because it wasn't being used 
anywhere (if MNG was used on even 1% of websites, the codesize issue 
would never have come up). One can't simply wait on all browser makers 
to implement something and then certify it as OK for general use. One 
needs actual adoption on the real web to force browser makers to 
implement something.

Given that the new date types will produce a significant improvement in 
UI, I want every site to be using them as soon as possible - long before 
WF2 browsers have 99% of the market. If they're designed in such a way 
that the fallback content is a much worse UI than whatever those sites 
are using at the moment, that won't happen and browser makers will be 
much slower to implement the types at-all.

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