Posted by todsacerdoti 9 hours ago
:where(:not(:defined)) {
display: block;
}That's the premise behind Lit (using the custom elements api)! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo.
It started at google and now is part of OpenJS.
It does! <https://lit.dev/docs/components/shadow-dom/>
By default, Lit renders into shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.
However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:
static styles = [themeStyles, componentStyles]
protected createRenderRoot() {
return this;
}
While you can easily turn rendering to shadow DOM off on a per-component basis, that removes the ability to use slots. It only really works for leaf nodes.
Pulling a stylesheet into every component is actually not bad though. Adopted stylesheets allow you to share the same stylesheet instance across all shadow roots, so it's quite fast.
My secondary concern with Lit is the additional complexity of using shadow and light DOM together in long lived React/Angular apps. Adding a new paradigm for 75+ contributors to consider has a high bar for acceptance.
And yes attempting to add a new paradigm for that many people is I am sure quite the task. More political than technical in many ways as well.
Thanks for sharing!
If there's no native semantic tag that fits my purposes, I'd much rather stick to a div or span as appropriate, and identify it with one (or more) classes. That's what classes are for, and always have been for.
Support for custom HTML elements seems more appropriate for things like polyfills for actual official elements, or possibly more complicated things like UX widgets that really make sense conceptually as an interactive object, not just CSS formatting.
Using custom element names as a general practice to replace CSS classes for regular formatting just feels like it creates confusion rather than creating clarity.
<div class=expander>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</div>
for (const expander of document.querySelectorAll('.expander')) {
const btn = expander.querySelector('button');
btn.addEventListener('click', () => {
btn.ariaExpanded = 'true';
});
}
Custom elements solve exactly this problem. You can now do:
<expander-elem>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</expander-elem>
customElements.define('expander-elem', class extends HTMLElement {
connectedCallback() {
const btn = this.querySelector('button');
btn.addEventListener('click', () => {
btn.ariaExpanded = 'true';
});
}
});
Above code will only work when the Web Component is defined after DOM has parsed; using "defer" or "import" makes your JS file execute after DOM is parsed, you "fixed" the problem without understanding what happened.
I blogged about this long time ago: https://dev.to/dannyengelman/web-component-developers-do-not...
Simply render your <element> (server-side is fine) and whenever the JavaScript downloads and executes your custom elements will mount and do their thing.
Doing this for syntax highlighting on https://janetdocs.org/ shrank the homepage's .html from from 51kb to 24kb, or 8kb to 6kb compressed (at the time).
``` <pre><code class="janet">(<special>defn</special> <symb>bench</symb> <str>`Feed bench a wrapped func and int, receive int for time in ns`</str> [<symb>thunk</symb> <symb>times</symb>] (<special>def</special> <symb>start</symb> (<built-in>os/clock</built-in> <keyword>:cputime</keyword> <keyword>:tuple</keyword>)) ```
The article states that anything with a dash is guaranteed not to be and another commenter here shared their strategy that involved a naming convention like <x-special>, <x-symb>, etc. Perhaps substituting x for j would make sense and alleviate the concern of possible future clashes with web standards
Which future version? Is there something I'm missing? I'd like to have html6 that has feature parity with native, but I'm afraid we got html5 and just stopped there. And if there will be an html6 why can't we just state "use version 5 in this document" so there won't be any name clashing between supported and custom tags?
They dropped numbered versions. Now it is just HTML which is continuously evolved in a backwards-compatible manner.
> And if there will be an html6 why can't we just state "use version 5 in this document"
Because browser vendors are opposed to explicit versioning, since it introduces multiple rendering modes.
But they'll never add new standard tags with hyphens.
https://github.com/h5bp/html5-boilerplate/blob/v0.9/css/styl...
I realized that I could just make up tags and style them and it was work.
One place I'd love to see this is in a classless html framework. My experience is you always wind up wanting something like cards, and then either writing classes, or having a slightly magic "use these elements in this order" incantation[1].
It would be great to have a minimal framework that peppers in a couple elements of the kind <card>, <accordian> etc.
[0] I did ask an LLM at one stage too, and it also didn't mention this behaviour exists.
[1] pico css does this.for.example for cards/accordians
With classes, I can do:
carList = document.querySelector('.carList')