[whatwg] [WF2] The <icomplex> element

[Ian Hickson]

On Mon, 21 Mar 2005, Matthew Raymond wrote:
> > > 
> > > | <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.
> 
> 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.

Just because a lot of content will be new doesn't mean we can ignore the 
existing content. _You_ have been arguing that the <icomplex> element is 
needed so that people can use it in existing pages; if use on existing 
pages is a requirement, then not changing the "elements" array is too.


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

If scripting is allowed as a solution, then you don't need declarative 
fallback at all, and the existing solution is fine.


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

If it uses scripting, <icomplex> isn't needed.

If it doesn't, and yet it only has one field, then it's no better than 
<input> fallback.

If it has no scripting and has more than one field, then it sends 
different fields, and the problem I mentioned exists.


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

WF2 and legacy forms (assuming they're the same page, which is the idea 
here) would have the same fields, using the current WF2 proposal.


> Can you explain exactly why it's so difficult to create server-side 
> scripts to deal with this issue?

It's not, particularly; certainly no harder than supporting multiple date 
formats. The problem is mostly that it involves having multiple codepaths, 
which means more likelihood of errors (authors frequently only test in 
their UA), as well as opportunities for vulnerabilities (e.g. if the 
script doesn't expect to receive both date arguments at once).


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

My point is it would be possible (and therefore, by Murphy's law, common) 
for authors to do:

   <icomplex .../>


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

It is one of several arguments that I mentioned.


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

Frames, scripting, alt text on images, fallback on <object>, "best viewed 
at 800x600", "optimised for IE", "Your browser is not supported", there 
are any number of examples of this mentality. And it isn't always lack of 
resources: MSN is well known for excluding a raft of browsers for a long 
time simply because they "didn't support XHTML" (even though XHTML support 
was not required and in fact several of those browsers _did_ support 
XHTML, while IE, which was of course allowed in, didn't).

Murphy's law strongly applies to Web authoring. If there are two ways to 
do something, people _will_ pick the bad one. It is our responsibility, as 
designers of Web standards, to make it as hard as possible for authors to 
do the wrong thing.


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

Example 1:

  <table border=0 cellpadding=0 cellspacing=0><tr><td>
   <table border=0 cellpadding=0 cellspacing=0><tr><td bgcolor=blue>
    <font color=yellow size=+3>Welcome</font>
   </table>
   <table border=0 cellpadding=0 cellspacing=0><tr><td bgcolor=blue>
    <font color=yellow size=+0>This is my Web site.<br><br>
    Isn't it nice?</font>
   </table>
  </table>


Example 2:

   h1, p { background: blue; color: yellow; }
   h1 { font-size: 2em; }

   <h1>Welcome</h1>
   <p>This is my Web site.</p>
   <p>Isn't it nice?</p>


> It doesn't take a rocket scientist to figure out that no serious 
> professional would use Example 1 in favor of Example 2.

Ah! I see your mistake. You are assuming that WF2 will only be used by 
serious professionals.

HTML (including WF2, we can hope) is used by millions of people, only a 
small fraction of which can be called "professionals". (And even many of 
those would probably pick the example 1 versions of our examples above.)


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

Indeed. I fully expect that to happen, just as it happens today with 
similar things.


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

Not necessarily, sure. But we can try to design the specs so that 
"assholes" (and also simply misguided souls, which are much more common) 
have a harder time breaking things.


> If authors treat them like second-class citizens, they'll just go to a 
> website that doesn't.

Sadly, that's not always possible.


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

I described how I came to that conclusion in subsequent paragraphs of that 
e-mail:

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

Sure, I was just enumerating all the cases.


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

Notwithstanding the various issues I raised, sure. So would <input>, with 
a little scripting (and even without, it would still work).


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

But nobody is requiring people to do this. Indeed I wouldn't recommend it.

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

My understanding is that they use <select>s because they believe that they 
are a good usable solution (although it should be pointed out that people 
on this mailing list have suggested that free-form input is a better 
solution -- and that is the solution simple <input> fallback provides).

If they believe <select>s are good, then they have no immediate reason to 
use WF2 before it is widely deployed.


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

Fair point; "Con: Scripts need to be updated".


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

Having multiple codepaths is never a good solution. While it is indeed 
easy to detect WF2 UAs, I wouldn't recommend doing so.


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

While that is true, I'd rather avoid introducing <dataentry> until there 
is no alternative.

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