Tag: custom elements

A secure, LLM-powered Web Component that generates and renders interactive HTML or SVG images on the fly using Google Gemini or Chrome's built-in AI.

While searching for a markdown editor on webcomponents.org to simplify blog posting, I discovered a useful collection of web components by Github. I was already familiar with their but was pleasantly surprised to find such a comprehensive and easy-to-use set of elements.

I couldn't find an easier way, so I built it myself

Possibly the world's best airhorn now as a custom element

Custom Elements need clear and parsable API documentation.

This little doozey hit me, so I'm documenting incase anyone else has the same issue

My adventures in creating resuable web components around sharing.

I'm exploring the best way to load web components, focusing on how to include styles and templates without creating uncontrolled blocking requests. I've experimented with using a single JavaScript file that encapsulates everything, including styles and a dynamically created template element. This approach avoids external requests but raises questions about extensibility and best practices. Should we revive HTML imports, embrace ES modules, or find a common model for handling templates and styles? Is inlining templates a reasonable solution? I'm looking for community input on how to balance performance and developer experience when deploying web components.

Web Components, specifically Custom Elements, offer exciting possibilities for web development. However, the current ecosystem is still evolving and has potential downsides. The practice of namespacing custom elements (e.g., <amp-*>, <iron-*>) creates "walled gardens" that can lock developers into specific frameworks. While understandable in the early stages, this approach hinders interoperability and leads to duplicated functionality. Ideally, we should move towards a shared vocabulary of elements (like <aspect-image>) where developers choose the implementation, not the vendor-specific element name. This requires a standardized process for defining element names, interfaces, and functionality. Imagine a world where component creators define the contract (e.g., class ShareButton extends HTMLElement { ... }) and users choose their preferred implementation. This model puts developers in control and fosters a more open and interoperable web. Furthermore, meta platforms (like Facebook or WeChat) could play a role by intercepting customElements.define calls and replacing JavaScript elements with native implementations when possible. This approach requires careful consideration, but it could lead to a more streamlined and integrated user experience.

Do we need a browser in the future?