dannye

<tag-name>

Browsers create ANY tag with at least one dash as a *Custom Element*

They come in TWO flavours, and since they ARE HTMLElement, can be used for layout AND styling with CSS.

The official names are:

► UNdefined Custom Elements (the article calls these "CSS Web Components")

  - shadowDOM optional with Declarative ShadowDOM

  - shadowDOM optional
  - A new Element, or an UPGRADED existing UNdefined Custom Element

### Good to know about UNDEFINED Custom Elements:

* Absolutely NO JavaScript required, it is only HTML and CSS

* This is STANDARD behaviour in all browsers for nearly a DECADE now: Chrome (2016) Safari (2017) FireFox (2018)

* 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

* Custom Elements do not inherit the standard [hidden] behaviour; so you have to add that behaviour yourself in your stylesheet.

* Same for DIVs display:block. 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 :defined pseudo selector targets standard HTML tags and JavaScript defined Custom Elements

* Thus :not(:defined) targets the UNdefined Custom Elements; again... they are still valid HTMLElement so CSS applies like any element

* <you-are-not-bound-to-one-dash>

* Declarative ShadowDOM <template shadowrootmode="open"> creates the same UNdefined Custom Elements WITH a shadowDOM

* The Custom Elements JavaScript API upgrades UNdefined Custom Elements TO defined Custom Elements.

* You can't UNdefine defined Custom Elements

* You can't REMOVE a set shadowRoot

* for now, only Safari supports multiple custom element registries (duplicating Custom Element names)

----

Why?

► Try to find that closing </div> in a long HTML page. </tag-name> is always just there.

► Built a UI that doesn't FOUC, and UPGRADE it lazy-loaded with more logic and interactivity... you can not do this with technologies that CREATE HTML AFTER DOM was parsed.

Custom Elements/Web Components ARE HTML; Frameworks CREATE HTML

We will forever call Custom Elements: Web Components, and vice versa...

One drawback.

► 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

<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

What the MDN documenation doesn't make clear, is the relationship between Inline Event Handlers and Event Handler Properties

<div id="DIV" onclick="console.log(1)">CLICK!</div>

<script>

    DIV.onclick = (evt) => console.log(2)

    DIV.addEventListener("click",()=>console.log(3))

The article isn't complete/correct. Something did change with HTML. Since 2018 every browser interprets ANY <tag-name> with a dash as a valid HTMLElement, not HTMLUnknownElement. Absolutly NO JavaScript required to turn the DIV-soup into <semantic-html> and CSS

Latest blogpost on that site is from 2018

I presume Web Components are so great they haven't had anything happen since 2018

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...

> On the positive side their use of web components is a nice bet.

Web Components are a JavaScript/ECMAscript standard.

So this is like saying: _Their use of Arrays is a nice bet_

Note: Everyone uses Web Components. WTF?! Why does the <VIDEO> tag has a shadowRoot???

Browser Vendors have been using Web Component technology for INPUT, TEXTAREA, VIDEO and the like, for many many many moons now.

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...

document.body.onclick=()=>"document.location='www.google.com'";

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

https://jsfiddle.net/WebComponents/znbgf726/

https://i.imgur.com/inJAbQW.png

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/

If Lit is equivalent to Svelte, then BASIC was equivalent to COBOL

Unless you are still in the IE world (which is challenging when using WCs), use one `append` instead of multiple `appendChild`

use: slotAssignment: 'manual'

<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/

    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:

    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>`;
      }
    });

    createRenderRoot() {
      return this;
    }

    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

Lit is a Tool, not the Technology

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.