support native properties

[wkeese]

Currently you can't setup a custom setter or watch() a property like tabIndex, even if tabIndex is defined in the widget itself, trying to override the one in the HTMLElement base class.

On Chrome, the custom setter will never be called because the DOMNode object itself, produced by document.createElement(), will have it's own tabIndex property that overrides the one on our prototype.

On IE and FF we hit an issue that dcl will eventually work around.

I'm actually not sure if we can support native properties or not. What I want is for mySlider.tabIndex="3" to set the tab index of the slider's handles, but to leave the root node without a tabindex setting. But DOMNodes have a magic mapping between properties and attributes, so perhaps it isn't possible.

If worse comes to worse we'll have to use a different name, like widgetTabIndex.

[wkeese]

Which properties?

I went through the native properties as listed by Object.getOwnPropertyNames(document.createElement("div")), and I think the only property we need to worry about is tabIndex, setting the tabIndex on the root node instead actually sets the tab index on a sub node.

There were also some other properties of interest, but I think we can ignore them:

• dir - Setting the dir, a.k.a. GUI direction, affects which icons are loaded and CSS layout like whether a ComboBox's drop down arrow appears to the left or the right of the <input>. It also affects javascript code (search for code currently calling isLeftToRight()), such as how _HasDropDown handles "after" and "before" positioning. I don't think though that we need to support watch() or custom setters for this property. We might need some special code in startup() or refreshRendering() though since its value may not be available when buildRendering() is called.
• id - The idea would be that setting the id of the root node of a ComboBox widget would actually set the id of the <input> child. But that seems like a bad idea because it will confuse users that call document.getElementById("myComboBox"). Instead we can just make ComboBox.focus() change focus to the <input>. Having the id on the non-focusable root node will upset the a11y folks that worry about markup like <label for=xyz>name:</label><my-combobox id=xyz/>. However in that case I think we just need to make the app do <label for=xyz_input>name:</label><my-combobox id=xyz/> or something like that.
• lang - There will be one locale setting for the entire page (the one that the i18n! plugin uses), so we'll just ignore any lang setting on DOMNodes.
• title - Traditionally we used this for various things like a TitlePane's title, or the tab label of a ContentPane inside a TabContainer, but instead we should use some non-reserved word like "label".

About properties that have meaning on special DOMNodes like HTMLButtonElement.type and HTMLInputElement.value: those properties don't have any meaning to plain DOMNodes (like <div>), and conversely for an HTMLInputElement, we shouldn't mess with the value attribute because then we couldn't ever see what value the user typed in.

Implementation notes

Doug worked around the IE and FF problem by redefining dcl.mix() to use Object.defineProperty() instead of direct assignment.

As for the problem where the Object's tabIndex etc. masks the custom setter in the prototype, you can seemingly work around it by calling delete this.tabIndex etc., on the instance. You also need a removeAttribute() call for declarative instantiation.

[cjolif]

"Doug worked around the IE and FF problem by redefining dcl.mix() to use Object.defineProperty() instead of direct assignment."

Did we go back to Eugene and asked him to see if that would make sense to include that in dcl?

[wkeese]

Eugene has already said that dcl will switch to using Object.defineProperty(). See the link mentioned in the original description, uhop/dcl#9.

Not yet. Bill and I are still working out the dui/ changes to make sure we
don't have to go back and ask for additional changes later.

From: Christophe Jolif notifications@github.com
To: ibm-dojo/dui dui@noreply.github.com,
Date: 11/04/2013 07:59 AM
Subject: Re: [dui] support native properties (#34)

"Doug worked around the IE and FF problem by redefining dcl.mix() to use
Object.defineProperty() instead of direct assignment."

Did we go back to Eugene and asked him to see if that would make sense to
include that in dcl?

—
Reply to this email directly or view it on GitHub.

[wkeese]

Tentatively fixed by ac351b5.

[wkeese]

As shown in the test case above, this is really only half worked around. It works when tabIndex is declared in a mixin, but not when it's in the properties passed to register().