[whatwg] [WF2] The <icomplex> element

[Matthew Raymond]

Ian Hickson wrote:
> 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.

    I don't see this as a big issue for the following reasons:

1) You yourself were stating that most WF2 content will be new content. 
Therefore, people can simply write scripts that avoid the problem from 
the beginning.

2) An author could always use an <input type="hidden"> and some 
scripting to ensure that a specific field is submitted to the server. 
The other controls could simple exclude the |name| attribute. In that 
manner, only one field name would ever be successfully submitted to the 
server.

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

    First of all, sending different fields is not a given. It depends on 
the fallback implementation. Secondly, if the fallback implementation 
does use multiple controls, then from the server side you'd have to deal 
with multiple field names in the first place in order to deal with WF2 
and legacy forms calling the same script at the same time. Can you 
explain exactly why it's so difficult to create server-side scripts to 
deal with this issue?

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

    The simplest thing to author would be to use <input>, so I don't see 
your point.

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

    This is your real argument, and it is weak. You're referring to 
authors' past history of doing things like this:

| <noframes>
|   This is a frames-based page. Get a browser that doesn't suck!
| </noframes>

    The problem here was that supporting <noframes> is a huge pain in 
the a$$, especially if you're a hand coder like myself. It involves a 
massive amount of copying content and it's a pain to test because you 
need a browser without frames support to check it. So most people just 
said, "Screw it, let them get a browser that supports frames!"

    So, in many cases there was a real disincentive for inclusion, 
whereas you're talking about and intentional attempt to exclude. Look here:

Example 1:
| <dataentry type="date">
|   <p>Go get a real browser, loser!</p>
| </dataentry>

Example 2:
| <input type="date">

    It doesn't take a rocket scientist to figure out that no serious 
professional would use Example 1 in favor of Example 2. In fact, someone 
could easily get fired for favoring Example 1, since it's obviously 
malicious. You can't say the same for something like <noframes> or 
<noscript>. Those elements *always require additional effort* to put 
something meaningful in them for legacy browsers, whereas with the use 
of <input>/<dataentry> (I renamed it a while ago), the author has a 
choice of using a simple or complex fallback method.

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

    I don't really feel you've made that point in any of the three above 
cases.

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

    For that matter, they could use Javascript to detect WF2 clients and 
disable a form on legacy clients. Or they could use browser detection to 
serve up a page that says "You cannot use this site without a 
WF2-compliant browser". You can't use markup to protect the entire world 
from a**holes, and guess what?!! People browsing the web don't 
necessarily need you to. If authors treat them like second-class 
citizens, they'll just go to a website that doesn't.

    And might I point out that detection of WF2 was part of your defense 
of the <input> element's poor fallback, by the way.

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

    Considering the fact that textboxes as date inputs are in the 
minority, and that many of those textboxes use formatting hints, I can't 
see how you could come to that conclusion.

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

    That's not what <dataentry> was intended for to begin with, since it 
was intended as a compliment to <input> in situations where complex 
fallback is needed.

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

    It would be up to the author in this case as to what he/she wants to 
do. There are many scenarios where <dataentry> would work fine here.

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

    Your first "Pro" ignores situations where an author adopts WF2 
before it is widely deployed and wants to use <select> elements as the 
fallback. In that situation, they have do deal with the "Con" without 
the benefit of the first "Pro".

    People use <select> elements for a reason. That reason doesn't go 
away just because you're using <select> elements as legacy markup.

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

    Here you're just ignoring the Cons all together. For instance, if 
you were using the jsCalendar script, you'd have to edit it to either 
delete the extra button on WF2 clients or add one on legacy clients. Any 
kind of script that depends on preexisting markup would probably have to 
be altered in some way, and it would have to be disabled entirely in 
some situations on WF2 clients to avoid conflicts with various WF2 features.

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

    The only real issue you've presented is scripting that uses the 
.elements array. Since you've already stated that it should be trivial 
to detect WF2, couldn't someone simply put in a switch that uses 
different code on a WF2 client?

    Might I also point out that it will be possible to use <dataentry> 
for future input types that may have far more demanding fallback needs 
than "date" or "time. In that situation, we may have to introduce 
something like <dataentry> anyway. (Well, we could probably bring XBL2 
into the conversation at this point, but I don't want to get into that 
right now...)

    End of line.