4 ms·

> I like it and I don’t. I mean <b>bold</b> is a little simpler than <div class=“b”>bold</b> Of course in this example, semantic HTML makes sense. How do y

> I like it and I don’t. I mean <b>bold</b> is a little simpler than <div class=“b”>bold</b> Of course in this example, semantic HTML makes sense. How do you compose styles? Do you have a semantic element for every CSS property and every combination of every CSS property? Utility frameworks are used for much more than making text bold. The idea is to write as little CSS as possible, which reduces CSS bloat, collisions, specificity hell etc. > More generally you really ought to be able to pull some HTML out of page A and transcode it into page B and that means copying the styles and a lack of namespaces for id(s) and class(es) gets in the way of that. That is quite literally what tools such as tachyons/tailwind solve. > or frameworks that work on the DOM more imaginatively than React does I don’t really know what this means. But if you’re using React, you can leverage CSS Modules or one of the many CSS-in-JS frameworks. Both of these approaches solve your issue with namespacing.

PaulHoule 3y ago
Most back end systems do string templating, most of the exceptions compile templates ahead of time like Cold Fusion and .NET. An alternate approach is to work entirely at the DOM level, a bit of a manifesto for that https://ontology2.com/the-book/html5-the-official-document-language.html https://ontology2.com/the-book/html5-the-official-document-l... To take the common case, your "master template" could be an HTML page with a few "slots" in, say <div> elements with a certain id or class. The main content for a page is another HTML page, both of these are parsed to the DOM, the <body> of the donor page is extracted, grafted into the slot of the host page. More generally we can write functions that act on the DOM just as someone can write code that works on the AST of a programming language. One capability that ought to be possible is transclusion, in fact the "Real Semantics" system that was being designed at that time was a system for annotating documents and extracting knowledge from them and the first step of that is that a document is "fixated" an embedded in an another document, pinned down the way an entomologist pins down a butterfly. This is on the edge of possibility: cut-and-pasting an arbitrary fragment of HTML out of somebody else's document and also rewriting id and class names and relevant CSS styles such that the the donor HTML looks the same way it did in the host HTML. (Or better yet, the CSS is manipulated so as to maintain the intent of the donor document in a way consistent with the host document) Anyhow, one major barrier to this is that DOM parsing is pretty slow, a simple system based on DOM parsing can be two orders of magnitude slower than string templates. (No wonder ASP.NET compiles templates ahead of time) Another one is ubiquitous Javascript; from my viewpoint a static document that can be "pinned down" is dramatically more valuable than a changable document in that I can easily repurpose the static document. (In literary criticism is is notable that a document is "dead" and can't fight back against a hostile or inventive reader, say Derrida or Badiou.) You certainly can snapshot the DOM of a dynamic document the way that Google can index React-based sites, but it sure is a hassle.

PaulHoule 3y ago

Most back end systems do string templating, most of the exceptions compile templates ahead of time like Cold Fusion and .NET. An alternate approach is to work entirely at the DOM level, a bit of a manifesto for that https://ontology2.com/the-book/html5-the-official-document-language.html https://ontology2.com/the-book/html5-the-official-document-l... To take the common case, your "master template" could be an HTML page with a few "slots" in, say <div> elements with a certain id or class. The main content for a page is another HTML page, both of these are parsed to the DOM, the <body> of the donor page is extracted, grafted into the slot of the host page. More generally we can write functions that act on the DOM just as someone can write code that works on the AST of a programming language. One capability that ought to be possible is transclusion, in fact the "Real Semantics" system that was being designed at that time was a system for annotating documents and extracting knowledge from them and the first step of that is that a document is "fixated" an embedded in an another document, pinned down the way an entomologist pins down a butterfly. This is on the edge of possibility: cut-and-pasting an arbitrary fragment of HTML out of somebody else's document and also rewriting id and class names and relevant CSS styles such that the the donor HTML looks the same way it did in the host HTML. (Or better yet, the CSS is manipulated so as to maintain the intent of the donor document in a way consistent with the host document) Anyhow, one major barrier to this is that DOM parsing is pretty slow, a simple system based on DOM parsing can be two orders of magnitude slower than string templates. (No wonder ASP.NET compiles templates ahead of time) Another one is ubiquitous Javascript; from my viewpoint a static document that can be "pinned down" is dramatically more valuable than a changable document in that I can easily repurpose the static document. (In literary criticism is is notable that a document is "dead" and can't fight back against a hostile or inventive reader, say Derrida or Badiou.) You certainly can snapshot the DOM of a dynamic document the way that Google can index React-based sites, but it sure is a hassle.