dannye

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

► 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

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

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

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

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

<script>

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

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

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

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

Web Components are a JavaScript/ECMAscript standard.

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

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

And the WHATWG (for now) is "by invitation only"... note the big name missing.

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*

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

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

    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

It is NOT about Technology, it is about Who creates Technology.