[whatwg] Re: several messages

[Ian Hickson]

On Mon, 7 Feb 2005, James Graham wrote:
>
> 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. 

Sure. But when they do, we don't want them to be encouraged to drop 
support for the then-minority 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?
> > 
> > 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.

I don't think it's that limited. In fact I think that given the knock-on 
effects (different names on the server, different code paths in scripts, 
multiple variants to test, etc) it is quite important, at least as 
important as having a good legacy fallback story.


> > 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 depends what people would be using instead. If they would just be using 
a single text field (as many are) then using type="date" gives an 
immediate benefit. Similarly, if they are currently using complex 
JavaScript, then it makes sense to use type="date" and then have some 
script that detects whether or not that is supported (by comparing the 
input element's |type| DOM attribute to the value "date") and if it isn't, 
replacing it with what is being used today.

And other types -- type="time", "number", "uri", etc -- make sense today 
as well, with or without UA support. It's only really "date", "datetime", 
"datetime-local", and "range" that have poor fallback.


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

But DOM3 Load and Save was implemented first, despite that not being used 
anywhere.


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

The reasons for dropping MNG are far more complex than that.


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

Not always. Opera, Mozilla and Safari all support XHTML, but there's 
basically no real use of XHTML on the Web. Mozilla supports MathML, and 
there's even less MathML than XHTML. There's now an XForms plugin for 
Mozilla, and there's no XForms content.

Yet the same browsers don't support ActiveX, despite that being heavily 
used. Opera doesn't support XSLT, yet there is author demand for that 
(misguided as it may be).

In fact, I would say that in general, it is much more often the case that 
the UAs have to implement something before the authors use it. It's only 
when one UA is lagging behind on one particular feature that the authoring 
community can push for that UA to implement something (XmlHttpRequest 
being a good recent example here -- Opera was only forced to implement it 
because everyone else already had implemented it.)


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

Since most of the new types do not have this problem, I do not think that 
you need worry.

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