- <tag-name> are NOT unrecognized tags!
I blogged about this: https://dashed-html.github.io
◄ <tagname> = always an HTMLUnknownElement until the WHATWG adds it as new Element.
◄ <tag-name> = (No JS!) UNDEFINED Custom Element, valid HTMLElement, great for layout and styling
◄ Upgraded with the JavaScript Custom Elements API it becomes a DEFINED Custom Element
---
► This is standard behaviour in all browsers. Chrome (2016) Safari (2017) FireFox (2018) Edge (2020)
► The W3C HTML Validator accepts all <tag-name> Custom Elements with a dash as HTMLElement. It does not accept <tagname> (no dash), those are HTMLUnknownElement
► The UA - UserAgent StyleSheet (Browsers default stylesheet) defines CSS [hidden] { display:none }. But Custom Elements do not inherit the default stylesheet; so you have to add that behaviour yourself in your stylesheet.
► <DIV> is display:block only in the UA StyleSheet You have to set the display property on these Custom Elements yourself (You will forget this 20 times, then you never make the mistake again)
► The CSS :defined pseudo selector targets standard HTML tags and JavaScript defined Custom Elements
► Thus the CSS :not(:defined) pseudo selector targets the UNDEFINED Custom Elements; they are still valid HTMLElement, CSS applies like any element
► DSD - Declarative ShadowDOM: <template shadowrootmode="open"> creates the same undefined Custom Elements with a shadowDOM
- this.querySelector will return nothing when you define this Web Component before (light)DOM is parsed, because the connectedCallback fires on the opening tag.
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...
- Microsoft SharePoint version 2007 and 2010 where all XSLT. Used in just about every serious Intranet 15...20 years ago.
Developers deemed it too complex (or they were just stupid?)
SharePoint 2013 went the CSR (Microsofts "Client-Side-Rendering") path and SharePoint 2016 went the JSON/React path
Maybe with current AI aid XSLT would have had a chance... or we are still just too stupid.
Yes, XML/XSLT is a better technology, so was any Video Casette tape BUT VHS in the early 80s
- > there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to.
Ehm... define the Web Component render blocking in the head, because you want to prevent FOUCs. Then try to access the .innerHTML of your Web Component in the connectedCallback
https://dev.to/dannyengelman/web-component-developers-do-not...
- I would go all-in. Web Components is not (just) about technology, but about 4 companies working together on setting a standard. Companies that used to fight in the Browser Wars now work together on the standard. They are the WHATWG that took the role of the W3C HTML/Web workinggroup. 4 companies ... Apple, Google, Mozilla and Microsoft
And the WHATWG (for now) is "by invitation only"... note the big name missing.
- FYI: adoptedStyleSheets: https://developer.mozilla.org/en-US/docs/Web/API/Document/ad...
- for over 10 years now Apple has stated it won't implement Customized Built In Elements ( "is" extends )
If you want to dive in deep: https://stackoverflow.com/search?q=liskov
Here is Apple debating all non Liskov believers: https://lists.w3.org/Archives/Public/public-webapps/2013OctD...
*going back over 10 years to 2013, Who said Web Components was a fad*
- Only when you really want to encapsulate style or ensure GUI.
This should/could be part of a generic <app-footer) Web Component which ensures all that required is required.
We use a single <app-footer> for over 15 projects, it extracts domain namens to set the correct links.
Its value showed when we needed (basic) A/B tracking on all sites, we only had to edit this one <app-footer> file
- There are some issues with this code: https://gist.github.com/ceving/6e65886e04563ed9e6e42cc5f8d3f...
- https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...
Yet, they are all Tools, and you don't learn a Technology by learning a Tool, or do you become a Writer when you learn Word?
``::part`` is part [sic] of the Standard, it doesn't require any tooling.
CCS in JS is your choice
- why waste 28 minutes writing your own component? copy/paste takes 2 minutes https://dev.to/dannyengelman/load-file-web-component-add-ext...
- React supports Web Components, just some quirks to be aware of: https://custom-elements-everywhere.com/
- <textarea> <input> <video> ARE all Web Components, and have been for many moons so Browser vendors could implement their own UI. So everyone using a Browser *IS* using Web Components. It just took some years for the technology to be opened up with the Custom Elements API to us mortals here in Userland.
- To make that a fair comparison Andrew his native code should be refactored to: https://jsfiddle.net/WebComponents/ovtc5wpx/
Now, a shadowRoot is a bit wasteful here, as inheritable styles *will* style shadowDOM.customElements.define('like-button', class extends HTMLElement { static get observedAttributes() { return ['liked'] } get liked() { return this.hasAttribute('liked') } set liked(state) { this.toggleAttribute('liked', state) } constructor() { super().attachShadow({ mode:'open' }); } attributeChangedCallback() { this.connectedCallback(); } connectedCallback(){ this.onclick = (evt) => this.liked = !this.liked; this.shadowRoot.innerHTML = this.liked ? '<b>You liked this!</b>' : `<button>Like</button>`; } });So we remove shadowDOM:
To do that in Lit, you actually have to *ADD CODE*customElements.define('l1ike-button', class extends HTMLElement { static get observedAttributes() { return ['liked'] } get liked() { return this.hasAttribute('liked') } set liked(state) { this.toggleAttribute('liked', state) } attributeChangedCallback() { this.connectedCallback(); } connectedCallback(){ this.onclick = (evt) => this.liked = !this.liked; this.innerHTML = this.liked ? '<b>You liked this!</b>' : `<button>Like</button>`; } });
Making the Lit code LONGER than the Native codecreateRenderRoot() { return this; }
In real live projects you won't be nitpicking about these bytes and the 6K library/BaseClass Lit adds. Or the 7K lit-element.import {html, css, LitElement} from 'lit'; import {customElement, property} from 'lit/decorators.js'; @customElement('like-button') class LikeButton extends LitElement { @property({type: Boolean, reflect: true}) liked = false; render() { return this.liked ? 'You liked this.' : html`<button @click=${() => this.liked = true}>Like</button>`; } createRenderRoot(){ return this; } }Or would you? When those bytes are added for each! component if you develop truly self-contained web components...
Most Web Component Developers are still building Apps _with_ Components, not Apps _made of_ Components.
When doing Native you will *ofcourse* develop your own *BaseClass* (like Lit is) And for 95% of your time you will just be doing Plain Old JavaScript code.
Most Litters don't have a clue what is going on under the hood.
Most Native developers just silently do everything native, they are not the type to evangelize their choice on Social Media. Their code will run without any issues, upgrades, or breakin changes, for the next 25 JavaScript years
- 2017 to 2022, that is 5 years. But its 4 companies (Apple, Google, Microsoft & Mozilla) that all need to agree in setting this Web Components standard. So it can feel like slow progress. But.. once a standard, it will will last for another 27 JavaScript years. And anyone who has been in this "Internet" business for that long can tell you how valuable that is. Remember IE once had 90% market share.. guess how much market share Facebook will have in N years time. PS. The WHATWG is by invitation only, and we all wonder if those 4 companies will invite Facebook.
It is NOT about Technology, it is about Who creates Technology.
► execute <script> at bottom of file
► execute <script defer>
Both do the same; they execute script after DOM was parsed. When your JS creates GUI you now have to battle FOUCs.
► "import" loads your script async
so it _could_ load before _all_ DOM has parsed... but 9999 out of 10000 scenarios it won't