8 ms·

It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit

It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired down in arguments, and we end up with Frankenstein monsters like Web Components, Shadow DOMS etc. Web shouldn't be this hard. but the html governing bodies and the browsers have done a horrible of taking it forward.

staticvar 6y ago
I appreciate how Web Components are not opinionated meanwhile Component libraries are free to innovate and build on the Web Component foundation.
- staticvar 6y ago
  There are also simpler ways to write vanilla Web Components. Here's an example of the counter component written in what I find a simpler fashion. https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f56beecd https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f...
  - akersten 6y ago
    Wow, that's so much cleaner - why don't they just do it like this in the example? I'd be much happier learning standard web components if they were all a breath of fresh air like this. Personally I'd miss the JSX syntax, but this more than makes up for it by removing the entire whacky state vs. props thing. Although- how do you represent custom props here - arguments to the constructor? That'd be really elegant. Do those styles and query selectors leak out of the component? I'm assuming they don't since that's the entire point of the idea of a component, but just want to be sure.
    - tshaddox 6y ago
      This probably works fine for a simple leaf component like this, but this won’t compose well either, right? If every render completely overrides innerHTML then won’t all DOM state of child components get wiped? My understand is that this is a primary reason for e.g. React’s virtual DOM.
      - allover 6y ago
        Exactly - the innerHTML approach doesn't work for component composition and it completely fails for things like forms, where you will blow away form input focus/cursor state etc. This was a stumbling-block of the fairly simplistic predecessors to the React/Angular generation - like in Backbone.js if you chose to implement 'render()' in such a naive way.
  - rishav_sharan 6y ago
    Is there no Shadow DOM involved? love your way btw. Here is my no-class implementation from the vanillajs spa that I am working on https://github.com/rishavs/Verdin/blob/master/src/views/components/LikePost.js https://github.com/rishavs/Verdin/blob/master/src/views/comp... I just wish that one of these days I will get off my ass and actually finish something that I start :D
  - fuubi 6y ago
    That looks very clean - cool! I applied the redux pattern to WebComponents a while ago https://gitlab.com/f.parrillo/web-components/-/tree/master/src/counter https://gitlab.com/f.parrillo/web-components/-/tree/master/s... .
    - wolco 6y ago
      Is gitlabs down?
      - dmix 6y ago
        No, broken link, the linked code isnt publicly accessible on Gitlab apparently.
  - no_wizard 6y ago
    I like that this illustrates how easy it is to make a web component. What I don't like is this also shows (via the render method) how you can foot gun yourself if you aren't careful. Just slabbing in everything via `this.innerHTML` will lead to gross performance problems, among other things. There's also no real diffing (only matters on more complex concerns, in a way) so you're replacing everything just to update the count. I know we're all suppose to know better (I doubt you did this except for the express purpose of showing just how simple the Web Component API can be), but I've seen example code end up in production more times than I can count, from all over the web, so be forewarned stewards!
  - sergeykish 6y ago
    CSS pollutes global without <style scoped> or shadow root. Even simpler variant: <form> <button onclick="form.counter.value -= 1;return false">-</button> <input name="counter" value="0"> <button onclick="form.counter.value = 1 + +form.counter.value;return false">+</button> </form> Custom elements is just a mutation observer with callbacks, can be used with DOM 0 as well: class MyCounter extends HTMLElement { connectedCallback() { this.attachShadow({mode: 'open'}).innerHTML = `<style>...</style><form>...</form>` } } customElements.define('my-counter', MyCounter)
- georges_gomes 6y ago
  I also love this aspect. You can experiment new things on some components without affecting the entire application.
  - georges_gomes 6y ago
    https://webcomponents.dev https://webcomponents.dev is actually partly build with Vanilla WCs, LitElement and StencilJS. No big deals ;)
- dmitriid 6y ago
  Web Components are opinionated. You can't have an API that's not opinionated. And the opinion has shifted from "this is the future" to "Web Component specs is aimed primarily at library authors, we don't expect people to author them by hand"
blitmap 6y ago
SVG has the concept of re-usable components. Maybe in 10 years we can replace HTML with SVG. hides I'm sure that would make it much, much harder for people with accessible needs.
- paulryanrogers 6y ago
  Accessibility is key IMO. And why it's sad the standard components don't get more love. Like why in 2020 can't select dropdowns do basic matching on any part of optiond instead of only leading characters? Or show filtered results as one types?
- hinkley 6y ago
  Reusing SVG elements isn't as easy as they claim either, and they seem to have taken some of the options away in SVG 2.0
  - hutzlibu 6y ago
    Also SVG has also some very ugly things in the spec. And you would have to build up every UI-Element by yourself. It would have nothing to do with SVG, if it would be like HTML.
- kreetx 6y ago
  Years ago I heard someone saying that SVG should have replaced what CSS does nowdays, i.e use it for anything graphical. Not sure how well it would have worked though. But it is vector graphics so maybe very well?
deleted 6y ago
[deleted]
pierrebeaucamp 6y ago
You're looking for XHTML
- bdcravens 6y ago
  I don't recall components being in the XHTML spec.
  - pierrebeaucamp 6y ago
    Not in the 1.0 spec, but 1.1 brought modules. For example, MathML can be used as an XHTML module. Mind you, there isn't exactly a 1:1 mapping between modules & web-components, with the former being 20 years old at this point.
  - sergeykish 6y ago
    XML: ... <counter xmlns="my" /> XSLT: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:my="my"> ... <xsl:template match="//my:counter"> <form> <button onclick="form.counter.value -= 1;return false">-</button> <input name="counter" value="0"> <button onclick="form.counter.value = 1 + +form.counter.value;return false">+</button> </form> </xsl:template> </xsl:stylesheet> XSLT looks ugly but only because we should not edit plain text XML (same for markup). <template> is a limited version of XSLT.
Existenceblinks 6y ago
It was different way of thinking though. It started with just a bunch of text lines. And then SGML is about to tag those text with .. tags. It's content-first layout. Now we think about layout first, then putting text in it. Html is so old back then when browsers did not even have sense of having standard. Html tag is already good though, we now see it as sort of function, attributes are params. Turns out it started with really good design, but different way of thinking.
spankalee 6y ago
The web components set of specs and proposals includes HTML Modules, Declarative Custom Elements, and Template Instantiation, the combination of which would give you exactly what you're asking for.
- jhk4 6y ago
  HTML Modules never shipped which is the biggest hole in the current Custom Elements ecosystem.
  - spankalee 6y ago
    HTML, CSS, and JSON Modules are currently blocked by Import Conditions, which is going for stage 3 at the next TC39.
    - jhk4 6y ago
      TIL, that's awesome. I was under the impression they'd stalled out entirely.
    - dmix 6y ago
      Link to proposals: https://github.com/tc39/proposal-import-conditions https://github.com/tc39/proposal-import-conditions https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-modules-proposal.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
      - sergeykish 6y ago
        With type="module" and need to set ContentType they've invented new attribute and alias <script src="foo.wasm" type="module" iftype="webassembly"> but there is no need <script src="foo.wasm" type="application/wasm"> is not executed, so it can be used as is. And "if" keyword means make a request with ContentType: "/", discard if result ContentType does not match. Which is ... strange?
non-entity 6y ago
I could have sworn several years ago, before React, Vue, Angular X started to pick up, that WebComponents were supposed to be that. That people were talking about how browsers would have built-in support for WebclComponents. I could be remembering wrong though.
- spankalee 6y ago
  Browsers do have built-in support for web components. You can extend HTMLElement in every current major browser.
  - jfkebwjsbx 6y ago
    And such extension is a major PITA to do. The API is atrocious, like most of the DOM API is.
    - spankalee 6y ago
      What's your suggestion for a better API? You can't just say "React" though, you have to show how it actually integrates with the DOM that we have. "Throw away the DOM we have" isn't a realistic option either.
      - dmitriid 6y ago
        React integrates with the DOM we have. How dow you suppose it works? How is React different from any of the libs and frameworks you are supposed to use for WebComponents? [1] As for the API. How about a declarative API lime the one Polymer uses? [2] [1] https://twitter.com/dmitriid/status/987771666846699520?s=20 https://twitter.com/dmitriid/status/987771666846699520?s=20 [2] https://twitter.com/dmitriid/status/865518972380237825?s=20 https://twitter.com/dmitriid/status/865518972380237825?s=20
    - no_wizard 6y ago
      How is it atrocious exactly? I mean it’s decidedly not React to be clear, but I’m not sure what makes it atrocious
crazygringo 6y ago
Your frustration is understandable, but so too is why they never were -- HTML was never intended to be a programming language or component-based. HTML was originally meant to be page-based. And pretty much everything added to it (CSS, JavaScript) is scoped to the page. (Some data storage like cookies is scoped to the domain.) So shoehorning a "component" model to what is fundamentally page-based is essentially an impossible task to do elegantly. Either you wall components off in sandboxes and break the entire premise of the page having control ("why can't I modify the style of my component anymore with the page's CSS?!"), or your components are extremely leaky and accidentally stop working because of page-level CSS and JavaScript interfering. So we have a ton of different component models that use different tradeoffs. Obviously if HTML/CSS/JavaScript were being built from scratch today as a platform for apps, it would probably be designed extremely differently, very much around contained components. But that's not what it grew out of historically.
- frozenlettuce 6y ago
  The sad thing about HTML is that its original markup was designed for academic texts (h1,h2, p), but now it is unused because every publisher uses PDF for that end
  - ezequiel-garzon 6y ago
    But now? Publishers, even independent self publishers, have overwhelmingly never left PDF as output of choice, as it is superior in terms of typography, consistency and layout. Take any (non-Print Replica; i.e., reflowable) Kindle book that has just a few logical symbols, and you’ll see they soon become sufficiently ugly to be distracting, and in some cases just unclear due to poor typography. I celebrate projects such as MathJax, but what is sad is that 30 years on MathJax should be necessary at all, and here the typography is better but still doesn’t feel completely natural as in PDF documents. And from a practical, layman’s standpoint, now that we’re all becoming “mobile first”, while it’s natural to complain when a web link points to a PDF file, the resulting app makes the experience more immersive and self-contained, enabling any average user to save that document. Just saving an HTML document with all its linked material using your phone requieres a l337 browser, Evernote, Notion, or wget from a terminal emulator with the right flags... undoubtedly it’s a chore. I agree this is all sad, but by now I don’t see this changing anytime soon.
deergomoo 6y ago
I would 100% be in favour of an alternative to the DOM designed specifically for building rich application UIs. With upcoming features like portals it could even be embedded within existing HTML documents, or vice versa. I’ve griped about this before, but I firmly believe that the trope of JavaScript developers needing a million dependencies and constantly reinventing the wheel stems from the fact that you have to do every damn thing yourself (else install a package or 50). The platform provides almost nothing (except, of course, the most remarkable distribution platform we’ve ever seen). The amount of hoops we all jump through to make building web app UIs tolerable is insane. Want a filterable select that doesn’t make you type the first exact n characters really fast to find what you’re looking for? Gotta build it yourself. Hope you remembered to make it accessible and responsive! There isn’t even an in-built option for pop-out menus, a feature of GUIs as old as GUIs themselves. At the end of day the web is now as much an application platform as it is a hypermedia platform. We need better tools.
- temp42 6y ago
  Not that it diminishes your general point, but are you aware of the datalist element? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
  - deergomoo 6y ago
    Damn, I actually didn’t know about that! Looks like it doesn’t enforce values like a select does, but I think that would be a lot less work to patch over with JS than implementing a whole custom component.
hutzlibu 6y ago
Doing this with Adobe's Flex, was very easy. And at least for some time, fully integrated in their Flex Builder. But flash died, so did flex. (that means, the apache foundation still tries to reanimate flex with a js/html exporter, but I doubt it ever gets stable)
unabst 6y ago
In other words, HTML is unabstractable. I've been wishing to be able to type this since 1997. <let mytag> <p>my tag!</p> </let> <mytag/> Same with css. There are workarounds we use because abstraction is a requirement to code. Somehow the web components spec even seems like a workaround, for which we have many workarounds... and around and around we go :)
- Izkata 6y ago
  The first step of that kinda exists, <template> is for HTML that shouldn't be rendered immediately. However, you need javascript to grab it and actually make it reusable.

staticvar 6y ago

I appreciate how Web Components are not opinionated meanwhile Component libraries are free to innovate and build on the Web Component foundation.

staticvar 6y ago
There are also simpler ways to write vanilla Web Components. Here's an example of the counter component written in what I find a simpler fashion. https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f56beecd https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f...
- akersten 6y ago
  Wow, that's so much cleaner - why don't they just do it like this in the example? I'd be much happier learning standard web components if they were all a breath of fresh air like this. Personally I'd miss the JSX syntax, but this more than makes up for it by removing the entire whacky state vs. props thing. Although- how do you represent custom props here - arguments to the constructor? That'd be really elegant. Do those styles and query selectors leak out of the component? I'm assuming they don't since that's the entire point of the idea of a component, but just want to be sure.
  - tshaddox 6y ago
    This probably works fine for a simple leaf component like this, but this won’t compose well either, right? If every render completely overrides innerHTML then won’t all DOM state of child components get wiped? My understand is that this is a primary reason for e.g. React’s virtual DOM.
    - allover 6y ago
      Exactly - the innerHTML approach doesn't work for component composition and it completely fails for things like forms, where you will blow away form input focus/cursor state etc. This was a stumbling-block of the fairly simplistic predecessors to the React/Angular generation - like in Backbone.js if you chose to implement 'render()' in such a naive way.
- rishav_sharan 6y ago
  Is there no Shadow DOM involved? love your way btw. Here is my no-class implementation from the vanillajs spa that I am working on https://github.com/rishavs/Verdin/blob/master/src/views/components/LikePost.js https://github.com/rishavs/Verdin/blob/master/src/views/comp... I just wish that one of these days I will get off my ass and actually finish something that I start :D
- fuubi 6y ago
  That looks very clean - cool! I applied the redux pattern to WebComponents a while ago https://gitlab.com/f.parrillo/web-components/-/tree/master/src/counter https://gitlab.com/f.parrillo/web-components/-/tree/master/s... .
  - wolco 6y ago
    Is gitlabs down?
    - dmix 6y ago
      No, broken link, the linked code isnt publicly accessible on Gitlab apparently.
- no_wizard 6y ago
  I like that this illustrates how easy it is to make a web component. What I don't like is this also shows (via the render method) how you can foot gun yourself if you aren't careful. Just slabbing in everything via `this.innerHTML` will lead to gross performance problems, among other things. There's also no real diffing (only matters on more complex concerns, in a way) so you're replacing everything just to update the count. I know we're all suppose to know better (I doubt you did this except for the express purpose of showing just how simple the Web Component API can be), but I've seen example code end up in production more times than I can count, from all over the web, so be forewarned stewards!
- sergeykish 6y ago
  CSS pollutes global without <style scoped> or shadow root. Even simpler variant: <form> <button onclick="form.counter.value -= 1;return false">-</button> <input name="counter" value="0"> <button onclick="form.counter.value = 1 + +form.counter.value;return false">+</button> </form> Custom elements is just a mutation observer with callbacks, can be used with DOM 0 as well: class MyCounter extends HTMLElement { connectedCallback() { this.attachShadow({mode: 'open'}).innerHTML = `<style>...</style><form>...</form>` } } customElements.define('my-counter', MyCounter)
georges_gomes 6y ago
I also love this aspect. You can experiment new things on some components without affecting the entire application.
- georges_gomes 6y ago
  https://webcomponents.dev https://webcomponents.dev is actually partly build with Vanilla WCs, LitElement and StencilJS. No big deals ;)
dmitriid 6y ago
Web Components are opinionated. You can't have an API that's not opinionated. And the opinion has shifted from "this is the future" to "Web Component specs is aimed primarily at library authors, we don't expect people to author them by hand"

blitmap 6y ago

SVG has the concept of re-usable components. Maybe in 10 years we can replace HTML with SVG. hides I'm sure that would make it much, much harder for people with accessible needs.

paulryanrogers 6y ago
Accessibility is key IMO. And why it's sad the standard components don't get more love. Like why in 2020 can't select dropdowns do basic matching on any part of optiond instead of only leading characters? Or show filtered results as one types?
hinkley 6y ago
Reusing SVG elements isn't as easy as they claim either, and they seem to have taken some of the options away in SVG 2.0
- hutzlibu 6y ago
  Also SVG has also some very ugly things in the spec. And you would have to build up every UI-Element by yourself. It would have nothing to do with SVG, if it would be like HTML.
kreetx 6y ago
Years ago I heard someone saying that SVG should have replaced what CSS does nowdays, i.e use it for anything graphical. Not sure how well it would have worked though. But it is vector graphics so maybe very well?

deleted 6y ago

[deleted]

pierrebeaucamp 6y ago

You're looking for XHTML

bdcravens 6y ago
I don't recall components being in the XHTML spec.
- pierrebeaucamp 6y ago
  Not in the 1.0 spec, but 1.1 brought modules. For example, MathML can be used as an XHTML module. Mind you, there isn't exactly a 1:1 mapping between modules & web-components, with the former being 20 years old at this point.
- sergeykish 6y ago
  XML: ... <counter xmlns="my" /> XSLT: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:my="my"> ... <xsl:template match="//my:counter"> <form> <button onclick="form.counter.value -= 1;return false">-</button> <input name="counter" value="0"> <button onclick="form.counter.value = 1 + +form.counter.value;return false">+</button> </form> </xsl:template> </xsl:stylesheet> XSLT looks ugly but only because we should not edit plain text XML (same for markup). <template> is a limited version of XSLT.

Existenceblinks 6y ago

It was different way of thinking though. It started with just a bunch of text lines. And then SGML is about to tag those text with .. tags. It's content-first layout. Now we think about layout first, then putting text in it. Html is so old back then when browsers did not even have sense of having standard. Html tag is already good though, we now see it as sort of function, attributes are params. Turns out it started with really good design, but different way of thinking.

spankalee 6y ago

The web components set of specs and proposals includes HTML Modules, Declarative Custom Elements, and Template Instantiation, the combination of which would give you exactly what you're asking for.

jhk4 6y ago
HTML Modules never shipped which is the biggest hole in the current Custom Elements ecosystem.
- spankalee 6y ago
  HTML, CSS, and JSON Modules are currently blocked by Import Conditions, which is going for stage 3 at the next TC39.
  - jhk4 6y ago
    TIL, that's awesome. I was under the impression they'd stalled out entirely.
  - dmix 6y ago
    Link to proposals: https://github.com/tc39/proposal-import-conditions https://github.com/tc39/proposal-import-conditions https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-modules-proposal.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
    - sergeykish 6y ago
      With type="module" and need to set ContentType they've invented new attribute and alias <script src="foo.wasm" type="module" iftype="webassembly"> but there is no need <script src="foo.wasm" type="application/wasm"> is not executed, so it can be used as is. And "if" keyword means make a request with ContentType: "/", discard if result ContentType does not match. Which is ... strange?

non-entity 6y ago

I could have sworn several years ago, before React, Vue, Angular X started to pick up, that WebComponents were supposed to be that. That people were talking about how browsers would have built-in support for WebclComponents. I could be remembering wrong though.

spankalee 6y ago
Browsers do have built-in support for web components. You can extend HTMLElement in every current major browser.
- jfkebwjsbx 6y ago
  And such extension is a major PITA to do. The API is atrocious, like most of the DOM API is.
  - spankalee 6y ago
    What's your suggestion for a better API? You can't just say "React" though, you have to show how it actually integrates with the DOM that we have. "Throw away the DOM we have" isn't a realistic option either.
    - dmitriid 6y ago
      React integrates with the DOM we have. How dow you suppose it works? How is React different from any of the libs and frameworks you are supposed to use for WebComponents? [1] As for the API. How about a declarative API lime the one Polymer uses? [2] [1] https://twitter.com/dmitriid/status/987771666846699520?s=20 https://twitter.com/dmitriid/status/987771666846699520?s=20 [2] https://twitter.com/dmitriid/status/865518972380237825?s=20 https://twitter.com/dmitriid/status/865518972380237825?s=20
  - no_wizard 6y ago
    How is it atrocious exactly? I mean it’s decidedly not React to be clear, but I’m not sure what makes it atrocious

crazygringo 6y ago

Your frustration is understandable, but so too is why they never were -- HTML was never intended to be a programming language or component-based. HTML was originally meant to be page-based. And pretty much everything added to it (CSS, JavaScript) is scoped to the page. (Some data storage like cookies is scoped to the domain.) So shoehorning a "component" model to what is fundamentally page-based is essentially an impossible task to do elegantly. Either you wall components off in sandboxes and break the entire premise of the page having control ("why can't I modify the style of my component anymore with the page's CSS?!"), or your components are extremely leaky and accidentally stop working because of page-level CSS and JavaScript interfering. So we have a ton of different component models that use different tradeoffs. Obviously if HTML/CSS/JavaScript were being built from scratch today as a platform for apps, it would probably be designed extremely differently, very much around contained components. But that's not what it grew out of historically.

frozenlettuce 6y ago
The sad thing about HTML is that its original markup was designed for academic texts (h1,h2, p), but now it is unused because every publisher uses PDF for that end
- ezequiel-garzon 6y ago
  But now? Publishers, even independent self publishers, have overwhelmingly never left PDF as output of choice, as it is superior in terms of typography, consistency and layout. Take any (non-Print Replica; i.e., reflowable) Kindle book that has just a few logical symbols, and you’ll see they soon become sufficiently ugly to be distracting, and in some cases just unclear due to poor typography. I celebrate projects such as MathJax, but what is sad is that 30 years on MathJax should be necessary at all, and here the typography is better but still doesn’t feel completely natural as in PDF documents. And from a practical, layman’s standpoint, now that we’re all becoming “mobile first”, while it’s natural to complain when a web link points to a PDF file, the resulting app makes the experience more immersive and self-contained, enabling any average user to save that document. Just saving an HTML document with all its linked material using your phone requieres a l337 browser, Evernote, Notion, or wget from a terminal emulator with the right flags... undoubtedly it’s a chore. I agree this is all sad, but by now I don’t see this changing anytime soon.

deergomoo 6y ago

I would 100% be in favour of an alternative to the DOM designed specifically for building rich application UIs. With upcoming features like portals it could even be embedded within existing HTML documents, or vice versa. I’ve griped about this before, but I firmly believe that the trope of JavaScript developers needing a million dependencies and constantly reinventing the wheel stems from the fact that you have to do every damn thing yourself (else install a package or 50). The platform provides almost nothing (except, of course, the most remarkable distribution platform we’ve ever seen). The amount of hoops we all jump through to make building web app UIs tolerable is insane. Want a filterable select that doesn’t make you type the first exact n characters really fast to find what you’re looking for? Gotta build it yourself. Hope you remembered to make it accessible and responsive! There isn’t even an in-built option for pop-out menus, a feature of GUIs as old as GUIs themselves. At the end of day the web is now as much an application platform as it is a hypermedia platform. We need better tools.

temp42 6y ago
Not that it diminishes your general point, but are you aware of the datalist element? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
- deergomoo 6y ago
  Damn, I actually didn’t know about that! Looks like it doesn’t enforce values like a select does, but I think that would be a lot less work to patch over with JS than implementing a whole custom component.

hutzlibu 6y ago

Doing this with Adobe's Flex, was very easy. And at least for some time, fully integrated in their Flex Builder. But flash died, so did flex. (that means, the apache foundation still tries to reanimate flex with a js/html exporter, but I doubt it ever gets stable)

unabst 6y ago

In other words, HTML is unabstractable. I've been wishing to be able to type this since 1997. <let mytag> <p>my tag!</p> </let> <mytag/> Same with css. There are workarounds we use because abstraction is a requirement to code. Somehow the web components spec even seems like a workaround, for which we have many workarounds... and around and around we go :)

Izkata 6y ago
The first step of that kinda exists, <template> is for HTML that shouldn't be rendered immediately. However, you need javascript to grab it and actually make it reusable.