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 components and give them new super powers. I wrote them in a way that i don't need to keep repeating common UI elements. I focused on the elements behavior, keeping a minimalistic approach:
Almost no style (behavior driven style), letting you free to add your visual identity.
Single purpose elements. Every element must do only one thing. Commonly it encapsulates complex behaviors.
Simplicity. The code is very simple. The largest component source has 100 lines of code. There is no complex multi-purpose largely configurable element.
Agnostic. That means no frameworks required. You can use them anywhere, just add the
is="el-name"attribute to give new powers to a standard HTML element.
As said by MDN: "Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps".
Documentation and Usage
I put some effort in documenting the Collection and each element separately. The elements are really EASY to use. You load the CSS and JS files, then use the 'is' attribute to specify which behavior you want to give to your tag.
For example
<div is="el-accordion" data-summary="Hello World">
<p>Im an accordion that shows this message when expanded</p>
</div>
You can check live examples and docs here:
https://felippe-regazio.github.io/web-elements
And here:
https://github.com/felippe-regazio/web-elements
All elements has a rich API with events and methods.
I still need to add accessibility (needing help here).
Element List
- ⚡️ Accordion
Extends the div element giving it an Accordion structure and behavior.
- ⚡️ Card
Extends the div element giving it a Card structure and behavior.
- ⚡️ Header
Extends the header element giving it a set of features as fixed on top and auto hide on scroll.
- ⚡️ Image Viewer
Extends the img element giving it a full screen view, the image will be showed on a lightbox when clicked.
- ⚡️ Lazy Load IMG
Extends the img element giving it a lazy load behavior. The images will be only loaded when visible.
- ⚡️ Lightbox
Extends the div element giving it a Lightbox behavior.
- ⚡️ Mustache Template Div
Extends the div element giving it a template engine capabilities. The div will be capable to parse json to fill its content.
- ⚡️ Read More
Extends the div element giving the content inside a Read More feature.
- ⚡️ Sidebar
Extends the div element giving it a Sidebar structure and behavior.
- ⚡️ Spinner
Extends the div element giving it different configurations to act like a loading spinner.
Contributions, critics, appointments, hints... are VERY welcome!
:)
Top comments (15)
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.