XML had it right with XSLT. It stands for Extensible Stylesheet Language Transformations. Because the language was clearly defined from the start for data not p

XML had it right with XSLT. It stands for Extensible Stylesheet Language Transformations. Because the language was clearly defined from the start for data not presentation the need for structure transformation was apparent. There’s absolutely no reason why HTML5 shouldn’t reinvent something similar. Make it much simpler, just reuse the existing Web Template spec, which simply defines new elements with slots and selectors. Example: [ was super long so I moved it: https://ipfs.io/ipfs/QmQUszZRdHfdVUZwvQL2tK12XrW54TdJJqXEkm1i7bqDkN https://ipfs.io/ipfs/QmQUszZRdHfdVUZwvQL2tK12XrW54TdJJqXEkm1... ] More complicated transformations, like the toc here (arguably not that complicated but whatever), are better handled by user Javascript. Because let’s be honest XSLT like transforms are too hard. Not immediately obvious is the fact that browsers could simply replace and rerun Javascript on page navigation, instead of rebuilding the entire page, if the templates match. There are in fact many optimizations possible with this scheme. You could mark some regions that share a template as shadow DOM etc. --- You can also provide polyfill for this TODAY using Service Workers. It’s not that crazy.