So i wrote this elements collection. The Built-In Web Elements are part of the "Web Components" specs. They allow us to extend standard HTML compon...
For further actions, you may consider blocking this person and/or reporting abuse
Nice! I love seeing more folks dig into Custom Elements. As for accessibility, try googling "aria " and you'll usually find an official W3C page with lots of details about expected keyboard behaviors and
aria-attributes. For example, here's one about accordions: w3.org/TR/wai-aria-practices-1.1/e...Thanks Ken. lve been having a lot of fun coding Custom Elements.
Thanks for the appointments about the aria-, ive also been searching about it and will definitely apply the aria-attributes to this elements collection.
Is there any benefit to using that is attribute syntax over a tag name?
The main reason here is that:
When you are using a custom "tag name", that means you wrote an entire brand new element on the top of the HTML/JS. It takes different ways to construct the element, but a main one is: its an empty element at first, you will have to construct everything from scratch, or a "hyper class" with common patterns for you to extend.
When i use the "is" attribute syntax, that means im not creating a new element from scratch with all its complexity. Im really extending an existent HTML component and all its structure, and giving it new super powers.
Thats also the reason i can have so simple elements with rich behaviors and 50 lines of code.
I consider that as a benefit when construct simple components once because i dont have to re-invent the wheel. I use the HTML in favor. (Is something that you have to analyze: there are situations when is better to extend, sometimes is better to create a custom "tag" (element) from scratch. In my opinion, it depends on the complexity of what you're building)".
Another problem is that "The core of how browsers work with HTML continues to be the same as always", and extend an existent HTML component can be a benefit when thinking on that either.
Some reading i consider useful:
What is Web Components
developer.mozilla.org/pt-BR/docs/W...
Web Components and SEO
react-etc.net/entry/web-components...
Built-in Web Elements
hackernoon.com/extending-built-in-...
That lead to less code, but also you are more limited. As i said, depends on your needings and what you want to build. Another thing that differs from inherit using
is, and write a complete element is the presence of the Shadow DOM. In my case, i dont have a shadow DOM. Web Components can have a "scoped sub-DOM" inside your original DOM. That lead to pros and cons either. See:developer.mozilla.org/en-US/docs/W...
In my case i dont have a shadow DOM, the elements are on the same level as all others.
So it does lead to the writing last code? Less than if you were to create a class that inherits from div?
When you inherit from a
div, you use adivtag with theisattribute. So in this case Felippe is extending anHTMLDivElementto create his custom element. Hope that helped! This exactly confused me originally as well.The problem with
isis that Safari team will never implement it. From the beginning they opposed extended built ins and have not budged yet.Yep, thats true. Anyway, Andrea Giammarchi made an awesome Polyfill to take care of this problem, if you dont mind in add a polyfill. You can check some information here:
hackernoon.com/extending-built-in-...
How do I import / require? Unpkg? What about tree shaking to reduce size?
Lastly, what do you think about Parcel / Webpack / Snowpack to bundle this? Are they needed?
I added the UMDJS for the bundle and the single elements js files on the "elements" directory. This will allow you to import/require the bundle or a single element, once the elements are just a class and a simple registration. Thinking about the webpack suggestion.
Hey Pacharapol, you added some nice points here.
Didnt added an interface to import/require. This is the next step (gonna do it this week). Each element is a class that is added using customElements.define(). Im thinking in export the already defined element (ready to use).
Once i add the import/require interface the Unpkg and Tree Shaking can be a next step.
About bundlers: I tried to keep it as simple as it could be, so i decided to use Gulp. Here is why:
I need to:
With gulp i took 30 minutes to do it and wrote a "create" npm script to add new components. I didnt saw any benefit in add such complex thing as webpack to do some simple tasks at this point. Maybe webpack could give me some fun or freedom, as code the element in a single file (scss + js), i dont know. So i didnt overcomplicate the things.
Anyway, i could be wrong. Now i can scale the elements to a next step, and could be the points that you added. Thinking on the tree shaking, an interface to allow import/require and the package managers to add these elements, maybe webpack would be really useful.
I'd love to hear what you think about. Do you have any tips?
Thank you for your comment.
You can try hqjs.org to serve this and optimise your development experience. No need of configuring Parcel / Webpack, and it takes care of modules and polyfills despite of Unpkg
Ill take a look Yuri. Thanks for the tip ;)
These are really cool. I like the idea of having them be not too terribly complex.