Comments (6)
The hybrids does not support extending built-in elements for two reasons:
- Safari won't implement it (I can't find URL with an article about it at the moment), so it is impossible to use them in Safari without polyfill.
- It requires using the proper base class, but hybrids definition is all about plain objects with properties. There is no place for setting for example
HTMLDivElement
rather thanHTMLElement
.
However, it doesn't mean that you are out of luck. Even though you can't create custom element using is
attribute, you can use built-in element inside of your definition:
const MyButton = {
render: () => html`
<button>...</button>
`,
};
A <button>
inside of the template still works correctly in accessibility terms, including not required aria attributes.
from hybrids.
@smalluban
Thank for your quick answer.
Yeah I know Safari is the only browser who refuses to support extending built-ins.
Indeed, the correct constructor has to be specified.
Though we need and use it for custom tables, so that we can benefit from rowspan
, colspan
, etc.
from hybrids.
If context object’s local name is not a valid custom element name, article, aside, blockquote, body, div, footer, h1, h2, h3, h4, h5, h6, header, main, nav, p, section, or span, then throw a NotSupportedError DOMException.
Using extended built-ins is limited. For example, table elements don't support Shadow DOM, so building custom tables using them is rather hard to implement. You can't change styles, internal structure, etc... The only thing that you can is adding custom JavaScript logic (new methods, event listeners, behaviors). It is not a real use case for hybrids library.
Also, the whole "is" idea is quite complex and creates a lot of edge cases. That is one of the reasons why Safari might refuse to implement it.
Closing issue. Fill free to re-open if you have any additional questions about the subject.
from hybrids.
Thanks for your quick answer.
Indeed, extended build-ins and the is
attribute has consequences for all DOM related API's like document.createElement
.
Though it's a living standard despite the fact that Safari refuses to implement it.
IMHO it's a super important feature to extend existing elements, not only in regards to SEO, accessibility, semantics, but also developer effort.
May I ask you to consider this feature and reopen this issue.
Please have a read on this article about extending built-ins:
https://hackernoon.com/extending-built-in-elements-9dce404b75b4
from hybrids.
I went through the article you provided, and only what I can see there is a lot of hate. I disagree with most of the arguments. V1 version of the Shadow DOM and Custom Elements API is widely supported, and polyfill for Shadow DOM V1 is working (look at the tests results), unlike the V0 version, where it was hard to implement, as for example, you could have multiple shadowRoots. Styling is not so complicated as he claims, and shadow DOM finally introduced real encapsulation, not a fake one - for example using [is="..."]
selector can be easily overwritten. Accessibility is still provided, by using built-in elements inside of the custom element. Of course, there are limitations, like building custom inputs, that will work with <form>
element. However, with extending built-in elements, you still can't create input, which renders custom content (like calendar or color picker).
The other thing is a hybrids architecture. It was my well-thought-out decision about using plain objects for the definition. It disallows extending custom constructor for the class definition.
Let's take simple composition example. If you have ElementA
definition, which you decide that extends <input>
, and ElementB
, which extends <div>
. The first one depends on the input API, so your properties require the HTMLInputElement
constructor. Now image, that you want to reuse one of the property from the first definition...
const ElementA = {
property: ...
};
const ElementB = {
...ElementA,
otherProperty: ...,
};
The composition is broken now - one of the principles of the hybrids. An object with property descriptors can't be related to the custom element base class. There is no place for that.
Custom Element API is very flexible, and if you stick to standards, you can create them with any library or even without them. They will still be able to work together. If you really need to extend built-in elements, you should find another tool for that.
from hybrids.
@smalluban
Thanks for reply.
I appreciate that you took the time to read above article.
I see your points of view.
And as I said, I really like your functional concept.
Though I'm convinced that extending built-ins is a valid concept too.
Nevertheless, it's your lib and so you rule it.
from hybrids.
Related Issues (20)
- How to compile statically? HOT 5
- Typing Issue When Redefining HTMLElement Built-In Properties HOT 2
- AsyncIterator HOT 2
- Initializing object properties with `undefined` no longer accepted in v8.0.0 HOT 4
- Feature Request: Custom Elements Manifest Analyzer HOT 1
- Class attribute mix-in _on_ the web-component HOT 12
- Extension for FLIP / Miotion Animations in planning? HOT 10
- Timing of connect during instantiation HOT 13
- Rendering components without the ShadowDOM? HOT 1
- Working with Chart.js HOT 1
- `class` attribute changes rendering in v8.1.7 HOT 4
- render function mutating host property breaks rendering in v8.1.6 HOT 5
- Properties assigned undefined when accessing them for the first time HOT 1
- Why don't store models leverage property descriptors too? HOT 7
- Storage-first/storage-only option for [store.connect] HOT 10
- React integration - Error while unmounting the component HOT 2
- Try render a table but encounter a problem HOT 3
- about destructured host parameter in render function HOT 2
- I'm trying to load a model on button click. Component does not update after loading model HOT 5
- A storage without an identifier loads data even before assigning an identifier HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hybrids.