[Bug 20913] [Custom]: What does inheriting from existing HTML element really mean?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913

--- Comment #25 from Daniel Buchner <danieljb2@gmail.com> ---
(In reply to comment #16)

> It lets us to get rid of the creation callbacks, simplifies the spec, and
> basically lets the builder of a component do exactly what they need at
> creation time, instead of dealing with "created" and "shadowRootCreated".

I'm sorry if I've somehow clouded the issue here, I don't oppose ES6 or
extending DOM element objects via class/extends. I simply want the impact of
changing doc.register to only take generated constructors to be clearly spelled
out with a real example and realized. The above statement makes the current
document.register property object sound like *it* is the complex, obtuse choice
- what I'm saying is that it's the *opposite*. We're forcing constructors that
have more cumbersome ergonomics and polyfill surface on folks that prefer not
to use constructors for generating elements, as this survey shows:
https://docs.google.com/forms/d/16cNqHRe-7CFRHRVcFo94U6tIYnohEpj7NZhY02ejiXQ/viewanalytics

My contention is as follows: 

Developers rarely use element constructors - there are several reasons,
including: they're currently uncallable and throw (basically unusable, except
for Image, Option, etc), devs have document.createElement and don't need them,
they aren't programming Java.

Why it matters:

1) We are arguing to change the interface to take only a parameter type that is
largely irrelevant on the web today.

2) We lose easily defined callbacks to common actions - if we don't, *please
correct me* and show an example. For instance, inside the constructor will I
not be able to do: this.lifecycle.inserted = function(){...}? If so, yay, I am
less concerned!

3) I am worried about boilerplate and monotony. Without answering the
ergonomics questions about providing the functionality in the spec's current
property object in a way easily accessible to developers within their
user-generated constructor definitions, this concern persists.

Can someone please correct my fears that people will be forced to do this to
achieve parity with what the spec's property object provides currently? -->

(function(){

  var MutationObserver = window.MutationObserver ||
window.WebKitMutationObserver || window.MozMutationObserver;
  var list = this;

  var observer = new MutationObserver(function(mutations) {  
    mutations.forEach(function(record) {
      record.addedNodes.forEach(function(el){
        if (node.nodeName == 'super-list') {
            // do something when super-list elements are added
        }
      }
    });
  });

  observer.observe(document.body, {
    attributes: true, 
    childList: true, 
    characterData: true 
  });

  function SuperList() {
    this.setAttribute('super', true);
  }

  document.register('super-list', SuperList);

})();


As opposed to:

document.register('super-list', {
  prototype: Object.create(HTMLUListElement.prototype),
  lifecycle: {
    created: function(){
      this.setAttribute('super', true);
    },
    inserted: function(){
      // do something when super-list elements are added
    }
  }
});

Me thinks --> "Holy burgeoning boilerplate Batman!"

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 12 February 2013 17:46:52 UTC