[whatwg] [WF2] The <icomplex> element

[Matthew Raymond]

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

    Correct. See my suggestions regarding the .elements collection later 
in this email.

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

         I only proposed this solution specifically for date entry by
multiple controls (i.e. <select> elements), and only because you seem so
opposed to the server-side scripting.

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

    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.

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

    This is untrue both because of the jscalendar example and the fact 
that you may want format hints or other enhancements.

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

    Only if you assume that handling multiple fields on the server is 
difficult, and as you will see later in this message, I don't believe
that to be the case.

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

    I was referring to a situation where two separate forms, one using 
legacy code and one using WF2 code. If the website is halfway through a 
conversion from legacy to WF2, and you have two similar forms that use 
the same server script where one had been converted and the other has 
not, it's entirely possible that the script would have to be changed to 
handle both legacy and WF2 fields.

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

    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.

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

>>>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 have taken my comment out of context. I was referring to a 
similar, related argument you where making before the quoted section, 
not to all your arguments in the email.

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

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

    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?

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

    There is no direct connection between Microsoft's anticompetitive 
practices regarding rival web browsers and an individual author's 
tendancey to make specific choices regarding markup.

    Microsoft may be able to interfere with WF2, but there's nothing 
special about <dataentry> that makes it easier in any significant way.

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

>>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's not equivalent. First of all, your Example 1 is more likely for
an author that doesn't know a web standard: CSS. By contrast, my example
one requires the author to actually know a completely new web standard:
WF2. So you've effectively reversed the ignorance factor, since people
are more likely to already know <input>.

     No one in their right mind who has experience with CSS would ever
code Example 1. As far as I know, NN4 supports all of the CSS properties
above. Furthermore, since you can CSS inside the HTML file, there's on
argument regarding failure to load a CSS file.

    You can dig up just about any kind of HTML source on the web, but 
that doesn't make it representative of what modern authors are doing 
with the latest web standards.

    However, there are measures we can take to make it less likely that 
people will abuse <dataentry>:

|    The <dataentry> element is semantically identical to a <span>
| element, and therefore should be treated as such by user agents,
| unless it meets the following criteria:
|
| a) Its |type| attribute must be a value that the user agent
|    supports.
|
| b) If the <dataentry> element has a defined |name| attribute, then it
|    must contain a form control with a defined |name| attribute. If
|    there is only one contained form control, it should have the same
|    value for its name attribute as the parent <dataentry> element.

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

    No, I assume that people who intentionally make a**es of themselves 
will find themselves without an audience.

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

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

    Considering the diversity of the Internet, I wouldn't be surprised 
if there were a few sites like that, just as I wouldn't be surprised if 
people hacked the sites of companies that were anti-GPL. That doesn't 
mean these sites represent the majority of the 'net any more than the 
script puppies represent the open source community. I don't think we 
should let such a minority dictate the future of HTML.

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

    Only up to a point. As some point, we end up gutting functionality 
for fear it will be misused. At some point you have to decide whether 
its worth it to cripple WF2 in order to avoid intentional misuse by a 
minority.

    (Minor note: Please don't misquote me by uncensoring material I have 
originally self-censored.)

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

    True, but this situation specifically lacks any justification people 
might have in similar situations.

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

    Again, you are requiring scripting to support non-scripted legacy 
solutions.

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

    Um, no, *you* wouldn't recommend it. Others (such as myself and Jim 
Ley) feel that the benefits of a date control are significant enough to 
justify conversion.

    Also, there's no requirement anyone use <input type="date">, no 
matter what they use for date input.

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

    They provide an effective way of avoiding the need for client-side 
validation without resorting to using scripting. It also makes it easier 
to change a specific value within the date (month, day or year), without 
having to select something and manually type. So the usability depends
on the situation, but using <select> elements is an easy way to do 
primitive client-side validation.

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

    Except for user empowerment, localized date display, better date 
ranges, improved client-side validation for days of the month, less 
screen real estate...

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

    Then simply provide a property for a control element that allows 
exclusion of a specific element from the .elements collection. The user 
could then detect <dataentry> instead of WF2 and use the property to 
remove them from the collection. No code paths involved, just a function 
you run when you load the page that checks for a specific element and 
sets the property on it. If you dynamically create <dataentry> elements, 
simply set the property when you create them.

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

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

    The <dataentry> element is all about alternatives. Excluding it is 
all about denying alternatives in favor of a solution you personally 
feel is adequate.