[whatwg] [WF2] The <icomplex> element

[Ian Hickson]

To summarise my position: <icomplex> solves some problems, and introduces 
others. Just like <input>, it is not perfect. Since I do not consider the 
problems that it solves to be serious problems, and since I do not 
consider the problems it introduces to be any less important than the ones 
it sets out to solve, I do not see the advantage of introducing it.


On Tue, 29 Mar 2005, Matthew Raymond wrote:
> > 
> > If it uses scripting, <icomplex> isn't needed.
> 
> Not true. See the jscalendar example. In that situation, it's far and 
> away easier to use <dataentry> (formerly <icomplex>) than it is to 
> modify the script, especially if the author knows little or nothing 
> about Javascript and is simply using someone else's work.

I wouldn't expect people to try to go from jscalendar to jscalendar + 
icomplex. I would expect them to go from jscalendar1 to jscalendar2, the 
second of which provides for WF2 UAs.


> > > 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).
> 
>    Nonsense. Here's the pseudocode:
> 
> | if (exists(WF2_date_string)) {
> |   date1 = WF2_date_string;
> | } else {
> |   date1 = select_year + "-" + select_month + "-" + select_day;
> | }

Sure. I've also seen code like:

 if (exists(WF2_date_string))
   date1 = WF2_date_string;
 if (exists(select_year))
   date1 = select_year + "-" + select_month + "-" + select_day;

 // later in the script

 if (exists(select_year))
   date1 = select_year + "-" + select_month + "-" + select_day;
 if (exists(WF2_date_string))
   date1 = WF2_date_string;


> Then you just validate "date1" as if it where coming from a WF2 client. 
> This is the kind of problem they give programmers at a job interview for 
> people fresh out of college.

Many Web developers are self-employed, or employed by people who hired 
them based on the fact that the demo Web page they were shown has a cool 
<blink> bit and funky use of <marquee>. Sure, the professionals won't do 
this kind of mistake.


> > > > 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:
> > 
> > [    <dataentry .../>]
> 
> Exactly how would that work? In WF2-compliant HTML, nothing in the page 
> would show up after the <dataentry> element. Are you saying it's a 
> problem because XHTML parsers allow the more compact form even when a 
> closing tag is *required*?

Eh? In XML, <foo/> and <foo></foo> are equivalent.


> > > 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>,
> 
> All of which require additional effort on the part of the author.
> 
> > "best viewed at 800x600",
> 
> Additional effort required for testing on multiple devices and 
> resolutions.
> 
> > "optimized for IE",
> 
> The page may, in fact, use features that only exist in IE, or it may 
> have been designed before competing W3C standards were implemented on IE 
> and other browsers. It also indicates ignorance on the part of the 
> author regarding other methods.
>
> > "Your browser is not supported",
> 
> Nonspecific. I have no way of knowing the context of the message above.
> 
> > there are any number of examples of this mentality.
> 
> The mentality you describe is simply a matter of laziness. To drop 
> <font>, an author has to learn CSS. To make a page work with multiple 
> screen sizes requires additional testing. If an author sees a sample 
> script that uses MS-proprietary stuff, they just stick it in and you get 
> "This site only works with IE".

Lazyness and ignorance, and copy-and-pasting from other sites, yes.


> The use of <dataentry> over <input> represents more than laziness. It 
> represents a conscious choice to avoid providing fallback. Even if you 
> were to assume that people believed <input type="unknown"> had no 
> fallback (<input type="text">), it would be trivial, a simple cut and 
> paste job, to add textbox fallback:
> 
> | <dataentry type="unknown" [attributes to copy/paste]>
> |   <input type="text" [attributes to copy/paste]>
> | </dataentry>
> 
> Can you come up with even one scenario that excludes all malicious 
> intent on that part of all parties involved?

One of my mottos is: don't blame on malice what can be blamed on 
incompetence. People who understand the specs will do the right thing, of 
course. But the majority won't and we have to at least reduce the chances 
of them screwing things up.

This isn't a huge point -- see the first paragaph of this e-mail. But if 
the main concern of <dataentry> is to allow for decent fallback for legacy 
UAs, then it should most definitely _not_ allow _no_ fallback, IMHO. It 
should make things better in all cases, not potentially better and also 
potentially a lot worse.


> > 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.
> 
> You aren't arguing for sound architecture. You're arguing for an end to 
> freedom of choice. If we're going to put limitations on people, we have 
> to have minimal justification. Can you suggest any criteria for that 
> threshold?

Um, let's keep things in proportion. Arguing that not having a feature is 
a limitation on people and is an end to freedom of choice is a slippery 
slope to including everything in the spec. Let's please not go _there_.


> > Ah! I see your mistake. You are assuming that WF2 will only be used by
> > serious professionals.
> 
> No, I assume that people who intentionally make a**es of themselves will 
> find themselves without an audience.

The markup of most of the Web would tend to disagree with you. (Look at 
the source of Yahoo, MSN, and Google, the three most popular sites.)


> > 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.)
> 
> If you honestly believe that, then you're screwed, because the people 
> you describe would willingly use Microsoft-proprietary solutions instead 
> of WF2.

They would also willingly use WF2 instead of Microsoft-proprietary 
solutions -- the source is irrelevant. We have to make the standards-based 
solutions more appealing, that's all. (That and marketing.)


> By the way, if you don't recommend WF2 UA detection, how are people 
> supposed to add those wonderful scripting enhancements on legacy clients 
> that are supposed to make up for the fallback shortcomings of <input>?

I recommend feature detection, not WF2 UA detection.

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