*At least somebody explain why this is conceptually wrong.
*
Nothing is conceptually wrong with what you've stated Scott. I could live
with a <prototype> element that is scoped to the <element> as long as there
was some sort of 'registeredCallback' (as you previously alluded to many
posts back) that would be executed with access to the global scope just
once before the 'DOMElementsUpgraded' event fired. This preserves the
ability to setup, with minimal effort and hackery, delegate listeners and
other useful top-level scaffolding a component may require. Is this pretty
or optimal in terms of developer ergonomics? No - but it meet the
requirements.
For what it's worth: I talked to Brendan about this quandary and he favored
the creation of a special tag specifically for defining a component's
interface.
On Mon, Apr 15, 2013 at 12:46 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>
>
> On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 4/15/13 10:45 AM, Rick Waldron wrote:
>>
>>> Sorry, I should've been more specific. What I meant was that:
>>>
>>> new HTMLButtonElement();
>>>
>>> Doesn't construct an HTMLButtonElement, it throws with an "illegal
>>> constructor" in Chrome and "HTMLButtonElement is not a constructor" in
>>> Firefox (I'm sure this is the same across other browsers)
>>>
>>
>> Oh, I see. That's not anything inherent, for what it's worth; making
>> this particular case work would be <10 lines of code. Less on a
>> per-element basis if we want to do this for most elements.
>>
>>
>> function Smile() {
>>> HTMLButtonElement.call(this);
>>> this.textContent = ":)";
>>> }
>>>
>>> Smile.prototype = Object.create(**HTMLButtonElement.prototype);
>>>
>>
>> Ah, so... This would not work even if "new HTMLButtonElement" worked,
>> right?
>
>
> I guess I assumed this would work if new HTMLButtonElement() could
> construct things
>
>
>> In particular, if HTMLButtonElement were actually something that could
>> construct things in Gecko, it would still ignore its argument when called
>> and always creates a new object. You can see the behavior with something
>> like XMLHttpRequest if you want.
>>
>
> What I was expecting the above to produce is a constructor capable of
> something like this:
>
> var smile = new Smile();
> smile.nodeType === 1;
> smile.outerHTML === "<button>:)</button>"; // true
> // (and so forth)
> document.body.appendChild(smile);
>
> results in something like this: http://gul.ly/de0
>
>
> Rick
>
>
>
>>
>> Hopefully that clarifies?
>>>
>>
>> Somewhat. Trying to understand what things we really need to support
>> here and in what ways, long-term...
>>
>> -Boris
>>
>
>