[whatwg] [WF2] The <icomplex> element

[Ian Hickson]

On Wed, 9 Feb 2005, Matthew Raymond wrote:
> 
> EXAMPLES:
> 
>    Here's a simple example for the three <select> scenario:
> 
> | <icomplex type="date" id="d1" name="d1" value="2005-02-09">
> |  <select name="d1_day"><!-- Options --></select> /
> |  <select name="d1_month"><!-- Options --></select> /
> |  <select name="d1_year"><!-- Options --></select>
> | </icomplex>

This still breaks the .elements array, because the <icomplex> element 
will be present in .elements in the WF2 UAs but not the legacy UAs.

It doesn't solve the problem of having "two forms": legacy UAs and WF2 UAs 
would send different fields, which is a pain for servers and a potential 
source of problems (e.g. hostile users could try sending both, which is 
unlikely to have been tested, and is likely to have unexpected effects).

It doesn't solve the problem of the default (simplest authoring) being 
zero fallback for legacy UAs.

It also introduces the possibility of being abused in a semantically 
incorrect way which would IMHO be much too tempting and would miss the 
point of the idea of graceful fallback, namely:

   <icomplex type="hidden">
    <p>You don't have a WF2 UA. Sucks to be you.</p>
   </icomplex>

Any one of these problems is, in my opinion, more critical than the 
suboptimal (although still functional) fallback of <input>.


> >  * Fallback needs author involvement
> >     - easiest to simply not support legacy
> >     - server typically needs to handle different names for controls,
> >       not just different format
> 
> Since <icomplex> is a compliment to <input>, and has the same attributes
> but requires a closing tag, <input> will still be preferred by webmasters that
> don't want to include fallback.

I think you are giving authors way too much credit. The point is that 
authors wouldn't _think_ about including fallback, or if they did they 
would do something dumb like:

   <icomplex type="date">
    <p>You need a WF2 UA to enter a date.</p>
   </icomplex>

Given two options, one which allows this and one which does not, I 
strongly, strongly favour the one that does not.


My biggest problem with this proposal, though, is that it is trying to 
solve a problem that I haven't been convinced exists. I just don't see 
that the simple fallback is a problem.

As I've said before, I see these cases, with the given pros and cons for 
converting (in all cases you also have to update the server):

1. Authors who currently use type="text" with no format help.
   Pro: Better user experience in new UAs.
   Pro: Conversion of page is easy.

2. Authors who currently use type="text" with format help.
   Pro: Better user experience in new UAs.
   Con: Worse user experience in legacy UAs without scripting.

3. Authors who currently use <select>s.
   Pro: No need to update this until WF2 UAs are wide spread.
   Pro: Better user experience in new UAs.
   Con: Worse user experience in legacy UAs.

4. Authors who currently use scripted solutions.
   Pro: Better user experience in new UAs.

The only thing that providing fallback really does is cater for the users 
of non-WF2 scripting-disabled UAs on group two pages (something like 25% 
at most, less as WF2 UAs become widespread) and the users of non-WF2 UAs 
on group three pages (25% or whatever the percentage of non-WF2 UAs is 
when those authors start switching, and again less as WF2 UAs become more 
widespread).

It seems like a very small number of people to be catering for, given the 
complexity of the proposed solution and the issues it has.

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