[whatwg] Re: several messages

[Ian Hickson]

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.


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


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

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.

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


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


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

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