[whatwg] Re: several messages

[Ian Hickson]

On Thu, 3 Feb 2005, Matthew Raymond wrote:
> > > >
> > > > * 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.
> 
> When using the inheritance feature of <idate> [...]

Doing so is not the default. The default is for there to be no contents in 
the <idate>.


> > > > * 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.
> 
> I know has support for having multiple forms use the same controls, but 
> what does that have to do with multiple controls being used for the same 
> field?

Sorry, my sentence got very confused. What I meant to say was:

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

By "two different forms" I meant two different sets of controls for the 
same submission, based on whether you are submitting from a legacy UA or a 
WF2 UA (I am not referring to multiple <form> elements).

For example, this:

   <form>
    <input type="foo" name="s">
   </form>

...vs:

   <form>
    <foo name="s">
     <input name="s1">
     <input name="s2">
    </foo>
   </form>

In the first, the submission will always be the same, for new UAs like old 
UAs. For the second, the old UAs will submit two different values and new 
UAs will submit just one.


> > > >    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.)
> 
> Are you arguing against the use of <idate> or against the use of <input 
> type="date">?  Most dates are entered via the three <select> scenario. 
> Therefore, if there's a compelling reason to use <input> in those cases, 
> then <idate> is even more compelling.

There isn't a compelling reason to move away from three <select>s 
(whatever the replacement). There are reasons (better UI, better 
validation, more semantic) but at the end of the day, three <select>s 
perform quite adequately and are quite accessible. Moving from three 
<select>s to something new would mean either:

   * more complexity on the author side (two sets of controls which must
     be maintained togother) _and_ on the server side (two codepaths to 
     receive dates), or

   * less usable interface for users of legacy UAs.

Given that the advantages are quite small in both cases, I do not see why 
most authors would want to make the switch. Given that, it is logical to 
use the simplest possible solution in WF2, namely just a new type and 
nothing more.


> > 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).
> 
> Same is true for <idate>, unless--EGADS!--Not the Rogue Webmaster!!!

You seem to be downplaying the likelihood of Web authors being, as you 
say, "rogue". However, my experience with existing Web content strongly 
supports the view that most authors would fall into that category.


> > 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.)
> 
> The difference here is that text-base browsers, so far as I know, where 
> NEVER the most popular type of browser, so there was little incentive 
> for fallback.

Image fallback is needed for a lot more than just text browsers: blind 
users, mobile users and users on dial-up connections (who have images 
disabled), search engines, etc.

And yet it is still inadequately catered for by authors.


> Not to mention the fact that IE corrupted the meaning of the |alt| 
> attribute by using it for tooltips...

This is another very good example of why we have to be _very_ wary of UA 
implementors when designing fallback mechanisms, by the way.


> > > > 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.
> 
> The <idate> element doesn't need JS at all. You're requiring webmasters 
> to either learn scripting for legacy content, or depend on his 
> Javascript programmer buddy to do the work for him.

Here, we're talking about a case where the author _already uses 
JavaScript_. So requiring JS is not a problem.


> > > > ...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.
> 
> The repetition model is MORE complex than <idate>.

I beg to differ. The repetition model, to implement, requires very little 
except a few click event handlers and a modest DOM API. As far as I can 
tell implementing it is little more than translating the spec's text into 
C++ or whatever the UA is written in.

On the other hand, <idate> has element interdependencies. Change an 
attribute here, and something else has to change, etc. Move an element, 
and the entire validity of the control might change. Based on how UAs have 
screwed up this kind of thing before, I would say it is *significantly* 
harder to implement.


> Besides, isn't this what the implementation phase is for? Isn't the who 
> point of the implementation phase to find out what people will actually 
> implement and adjust the draft accordingly?

No. The implementation phase is to have people implement the spec. 
Ideally, without the spec changing at all, so that all implementations can 
then ship to consumers. If the implementation phase was guarenteed to 
result in the spec changing, then there would be no incentive in investing 
the scarce resources involved, since it would be risking that the code 
would have to be thrown out.


> Stick <idate> in, give the draft one more call before the implementation 
> phase, and if people hate it, take it out before the implementation 
> phase, or if people like it, but it's too hard to implement, it'll get 
> dropped in the implementation phase.

<idate> has at least as many problems as <input type="date">, and in my 
opinion the problems are worse on several fronts. I do not see it being 
worth adding to the spec, sorry.

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