3 ms·
I love plain HTML. The chief problem I have with it is just dealing with templates--stuff like navigation. Lots of other people have the same problem. So they a
by klodolph 5y ago
I love plain HTML. The chief problem I have with it is just dealing with templates--stuff like navigation. Lots of other people have the same problem. So they add some simple templating system, where they stick some text around the HTML. Ok, and then they want to automatically generate navigation, maybe add a few other features here and there. Add width/height to <img>, syntax highlighting for code snippets, etc.
It's really easy for this kind of endeavor to get out of hand. The hardest part of plain HTML is sticking with it and writing just enough automation to keep you sane.
It's also far too easy to get sloppy when working on something that does some basic preprocessing. My personal preference is to keep the pages as HTML, and write a processor that does minor modifications to the HTML DOM, using a proper HTML5 library.
If done carefully, you can keep the experience close to the experience of editing pure HTML. For example, rather than some custom "shortcodes", you can use custom HTML elements. Custom HTML elements are a more verbose, but come with major advantages over terser shortcodes (use existing tooling, you don't need a parser). You can do simple stuff like automatically add alt="" or srcset="" to your <img> based on image metadata, or automatically generate breadcrumbs using site structure.
The general idea is to keep it as close to plain HTML as possible. If possible, make it so the page is plain HTML.