[whatwg] [WF2] The <icomplex> element

[Matthew Raymond]

Ian Hickson wrote:
> On Thu, 10 Feb 2005, Matthew Raymond wrote:
>>...if you were used to using <input>, would you use a tag with then same 
>>attributes but a longer name and a required closing tag to do the exact 
>>same thing? Especially if the specs say to use <input> in simple cases? 
> 
> Please don't make the mistake of assuming authors are logical creatures. :-)
> 
> If you had the option of writing a document that was valid and didn't rely 
> on undefined error handling, or one that was invalid and might render 
> differently in different user agents, which would you use?
> 
> If you had the option of writing one line to change the fonts and colours 
> of your entire site, or of using one <font> element per bit of text, which 
> would you do?

    I could give examples of why people might do one or the other, many 
of which have to deal with the ignorance of the author. That said, the 
authors aren't ignorant of <input>. They're ignorant of <dataentry>. So, 
I don't see the point.

> Obviously, many authors "choose" to write invalid sites and "choose" to 
> use <font> instead of CSS.

    In all likelihood, they "choose" to do so because they either don't 
actually know anything about CSS or they're supporting some ancient 
browser that only supports <font>.

>>As for the editor, they can simply use <input> by default and give a 
>>warning before saving if <icomplex> has no contents. (Can we require 
>>contents??? My first guess would be no, but maybe someone knows more 
>>than I.)
> 
> The specs require editors to generate valid code, but they don't.
> 
> (This is not an argument against <icomplex>, though, since you are right, 
> we could require that editors do this. Editors that don't would just be 
> non-compliant.)

    You have a mild point, but don't forget that editors can also insert 
legacy contents into <dataentry> (formerly <icomplex>) depending on it's 
|type| attribute.

>>Well, one solution would be to provide an optional attribute that can 
>>exclude <icomplex> from the .elements collection:
> 
> That (or it simply not being in the array at all) would be bad since the 
> .elements array is used in other parts of the WF2 processing model. We 
> could define it otherwise but that would be awkward. (It's already a pain 
> for <input type="image"> for legacy reasons.)

    Yeah, I'm kinda leaning away from making <dataentry> cloaked to 
.elements by default. Perhaps we could offer a scripting method: create 
a method that allows people to remove elements from the .elements array. 
In that way, one could just write a function that goes through the array 
and removes the <dataentry type="something"> elements. A simple 
scripting solutions for a scripting problem. (Wait, can't you already do 
this with Javascript arrays?)