[whatwg] [WF2] The <icomplex> element

[Matthew Raymond]

Hallvord Reiar Michaelsen Steen wrote:
> On 9 Feb 2005 at 11:06, Matthew Raymond wrote:
>>it's only used when complex legacy support is needed.
> 
> <X>

"<X>"???

    I was referring to how it would be presented in the spec. I don't 
expect we can enforce a specific use in any way. However, I don't think 
such enforcement is needed. See below.

>><input> will still be preferred by webmasters that don't want to 
>>include fallback. 
> 
> You can neither dictate nor predict such things. 
> Authors are going to use it however they like (not to mention that 
> their WYSIWYG editor will do things that they are not even aware of) 
> ;)

    True, but 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? Take a look:

| <input type="date" name="date1" value="2005-02-10">

| <icomplex type="date" name="date1" value="2005-02-10"></icomplex>

    So it's not a certainty, but it's pretty close. 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.)

>> Let me know if there are any other concerns to address. 
> 
> Not the prettiest tag name :)

    Other suggestions are welcome. Some possibilities:

  * <inputcomplex>
  * <inputc>
  * <cinput>
  * <ci>
  * <input1>
  * <ic>
  * <ilegacy>

> The .elements problem is not solved, since the indexes will still be 
> different depending on what type of UA you deal with. It is more 
> common to access elements by name but in this scenario we are dealing 
> with legacy content possibly including older scripts that do not use 
> getElementById et al.

    Well, one solution would be to provide an optional attribute that 
can exclude <icomplex> from the .elements collection:

| <icomplex domcloak="true" name="hideMe"><!-- Contents. --></icomplex>

    I'm not sure I like that solution though, and I'm almost certain Ian 
won't like it. Another solution would be that <icomplex> would never be 
included in the .elements collection at all. That seems like a better 
solution, and since the WF2 DOM extensions depend on DOM2 and 
getElementById is well supported. So there's no issues of being able to 
get a specific <icomplex> element on WF2 UAs.

> A DOM scripting issue if you want to add a new HTML element: what do 
> browsers do if you do document.createElement('icomplex')?  Will any
 > browsers choke and throw errors?

    This isn't actually a problem specific to <icomplex>. Elements such 
as <datalist>, <output> and any other new elements we introduce could 
have this problem. If this can't be addressed, it may be a serious 
problem for any WHATWG specification.

> If an element is created, can the script reliably detect if the
 > created element is the element type they expect?

    /me shrugs and offers this:

| if (myIcomplexElement.type) // Does the object has a .type property?

    Yeah, assuming an unrecognized element doesn't automatically have 
properties that aren't on most elements, I'd say that's pretty safe. 
Remember, though that IANAJSG. (Guess the acronym!) ;)

    Is it just me, or are there holes in the Javascript and DOM specs 
that you can drive a truck through?