On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren wrote:
> On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote:
> > I really believe that we should be allowed to name our elements with any
> > name we wish, and that they should override native elements (that is
> future
> > proof), and that overr
On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote:
> I really believe that we should be allowed to name our elements with any
> name we wish, and that they should override native elements (that is future
> proof), and that overriding should be on some type of encapsulated basis
> (for example, ove
Thanks for the link!
I really believe that we should be allowed to name our elements with any
name we wish, and that they should override native elements (that is future
proof), and that overriding should be on some type of encapsulated basis
(for example, override within a shadow root and it won
Just FYI, the idea of allowing non-hyphen elements if they contain
non-ASCII characters
which probably won't collide with future HTML elements was posted in the
discussion:
https://github.com/w3c/webcomponents/issues/239#issuecomment-190603674
On Fri, Apr 15, 2016 at 7:01 AM, /#!/JoePea wrote:
On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. wrote:
> That means we lose the lingua franca that HTML provides; two
> independent libraries can't ever depend on the core HTML elements,
> because the other library might have overridden some of them.
Based on my idea of registering elements on a
On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea wrote:
> What if custom Elements simply override existing ones then?
>
> ```js
> shadowRoot.registerElement('div', MyElement)
> ```
That means we lose the lingua franca that HTML provides; two
independent libraries can't ever depend on the core HTML el
What if custom Elements simply override existing ones then?
```js
shadowRoot.registerElement('div', MyElement)
```
If overriding native elements was documented, it'd be fine. By
default, a blank document or shadow root has no elements registered,
so would use the native DIV. But, why not let the
I personal don't mind the hyphenation requirement for custom elements. Tab
Atkins brings up a great point about ensuring that new elements will be
able to be added to spec without worry of name conflicts with existing
custom elements on the page. It's much more future proof, in my opinion.
On Wed,
On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea wrote:
> I personally don't like this limitation. I think Custom Elements would
> be better if we could create elements that have
> , with the possible exception that we can't override the
> native elements.
This would prevent us from ever adding a