- From: Ryosuke Niwa <notifications@github.com>
- Date: Sun, 19 Feb 2017 23:29:56 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/509/281006515@github.com>
The trouble is that the builtin elements aren't written to be extensible in browser engines. Any algorithm that appears in the HTML specification directly looks up the internal state of each element the browser engine holds. e.g. the associated form control element of a `label` element. As we've stated, if we're supporting a proper subclassing of HTML elements, at minimum, we would have to define what kind of things need to be overridable and provide hooks for authors to customize their behaviors. However, there is an alternative approach. Instead of looking builtin elements as some sort of a magic box which provides a bag of functionalities and capabilities, we can decompose them into a small set of primitive APIs that let each element provide such capabilities. For example, an input element uses the capability to make itself focusable, has a shadow tree with a contenteditable, and participates in a form submission process along with many other things. In our view, it is more fruitful to spec and introduce a small set of these primitives that authors can use to create components of their likings instead of forcing them to extend existing builtin elements, many of which have horrible API surface and surprising behaviors (e.g. value content attribute sets the default value and value IDL attribute sets/gets the current dirty value on an input element). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/509#issuecomment-281006515
Received on Monday, 20 February 2017 07:30:30 UTC