[whatwg] [WF2] The <icomplex> element
mattraymond at earthlink.net
Thu Feb 10 06:47:33 PST 2005
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.
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
> 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:
> 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!) ;)
that you can drive a truck through?
More information about the whatwg