Writing HTML in HTML (2019)
ankarstrom.seHere is a better solution: You write your blog post md directly into the body and deploy a builtin minimal md engine.
<html>
<body>
# Blog Post Title
<br>
Welcome to this simple blog post
</body>
<js>
document.body.innerHTML = document.body.innerHTML.split('<br>').map((line) => line.trim().startsWith('# ') ? `<h1>${line}</h1>` : `<p>${line.split('# ')[1]}</p>`).join(''); // add more md features here if desired
<js/>
</html>
Obviously move the JavaScript to its own file and embed it to avoid repetition across blog entries. Plus, move it into 'DOMContentLoaded' event handler to be safe.
Could it get any more elegant and beautiful?
I do not understand peoples problem with writing HTML. You could use an editor that auto-completes elements if you find that they're too long to type. Also remember that there are a few common elements, like <p> and <li>, that you usually don't need to close.
I use Hugo and I actually prefer writing HTML over MD.
> You could use an editor that auto-completes elements if you find that they're too long to type.
Maybe, but why do things the hard way? Even if your editor autocompletes, typing the angle brackets is more cumbersome than Markdown.
> Also remember that there are a few common elements, like <p> and <li>, that you usually don't need to close.
Having to remember random trivia like this is exactly why writing HTML is awful.
> Maybe, but why do things the hard way?
Me and some others don't find it harder. Also, what we write doesn't need a parser to output what the browser needs.
> Having to remember random trivia like this is exactly why writing HTML is awful.
Would not call it “random trivia”, these are quite basic HTML facts[1]. HTML is not XML. My theory is that some people find HTML hard to write because they make make it harder than it has to be.
[1] https://html.spec.whatwg.org/multipage/syntax.html#optional-...
> Me and some others don't find it harder. Also, what we write doesn't need a parser to output what the browser needs.
If you need an editor with autocomplete to write it comfortably, that's a bigger hassle than a separate postprocessing step that can happen automatically.
> Would not call it “random trivia”, these are quite basic HTML facts[1].
It's absolutely random trivia. These particular four elements don't need closing, except this one might if it's not followed by one of this other long list of possible elements. Why would you ever know (or care about) that unless you enjoy memorizing random lists (I'll bet the reason it's those four is edge cases in a parser that someone wrote in a couple of hours 30 years ago, not any sensible logical classification), or already know the HTML spec because you work as a designer or something?
> These particular four elements don't need closing, except this one might if it's not followed by one of this other long list of possible elements.
That’s how it’s worded in the spec, because that’s targeted to browser implementors, not HTML authors. To someone authoring HTML, it’s much simpler: the tag is closed by any encountered opening or closing tag that the tag is not allowed to contain. That’s nothing new to memorize, because you already have to know what elements are allowed in that context. E.g., even in XHTML served with an XML MIME type and parsed with an XML parser, <p><p></p></p> is invalid XHTML, because <p> can’t contain <p>. I already have to know that rule when writing a webpage! Knowing that <p><p> is equivalent to <p></p><p> doesn’t require higher mental overhead.
> I'll bet the reason it's those four is edge cases in a parser that someone wrote in a couple of hours 30 years ago, not any sensible logical classification
Nope, the self‐closing behavior has been present in HTML since the very beginning (inherited from SGML). As for why these elements specifically, it’s because they are among the easiest and simplest to remember due to their definition. <li> can’t contain <li>—the concept doesn’t make sense—so it makes sense for <li><li> to implicitly close the first one. <td> can’t contain <td>—the concept doesn’t make sense—so it makes sense for <td><td> to implicitly close the first one. And so on.
> That’s nothing new to memorize, because you already have to know what elements are allowed in that context. E.g., even in XHTML served with an XML MIME type and parsed with an XML parser, <p><p></p></p> is invalid XHTML, because <p> can’t contain <p>. I already have to know that rule when writing a webpage! Knowing that <p><p> is equivalent to <p></p><p> doesn’t require higher mental overhead.
"It's no extra effort to memorize this piece of random trivia, because it's already implied by this other piece of random trivial that you already have to memorize" doesn't actually make it any better. I don't want to remember any of this stuff! And with Markdown I don't have to.
OP here and you know I'm with you, I actually love handwriting HTML. Auto-closing tags in VSCode comes in very handy too.
Just thought I'd post this "novel" idea since most people do love their MD.
> Also remember that there are a few common elements, like <p> and <li>, that you usually don't need to close.
<p> and <li> don’t ever need to be closed, do they? Closing would only be necessary if leaving them open would introduce ambiguity, but it never does.
Nope. But if you don't use a closing tag and put, say, an <img> tag below a <p>, the image will be child of the paragraph. Perhaps that's not always what you want.
Cries in XHTML
Close your tags, people. Make your intent non-ambiguous. It's basic hygiene.
It's a paragraph, not a div, the intent is clear by definition.
The intent at the beginning of the paragraph, but not at the end. Is an IMG meant to be in the paragraph? Is a SPAN? They are inline elements that can indeed be inside a P.
I honestly don't understand this level of laziness in 2023. Editors close tags automatically, ffs. For the sake of saving a keystroke or two we end up with unintuitive and ambiguous crap.
If I didn’t intend the img or span to be in the paragraph, I would have closed the <p>. The act of leaving the <p> open is what demonstrates that my intent is for the img to remain inside.
And now you have a tag that is sometimes closed and sometimes open, forcing me to scan the entire document to figure if you've ever closed this bloody thing - as opposed to knowing that you will eventually close it, and that anything I see until then is inside the P.
You won't need to scan the entire document because pretty much anything can make the P tag close, including closing the element containing it.
Do you always specify <tbody> in your tables?
I always have the right amount of well-formed (and well-spanned) TD and TR, making my markup actually logical and simple to understand. Which is not the result we get from open P.
I stopped closing <td> and <tr> because I found the (completely valid, completely unambiguous) practice of dropping the closing tags dramatically reduced the visual noise and clutter, making it easier for me to read my own tables.
If you say so, de gustibus. You might be making life marginally easier for you, to the detriment of any tool (or person) that has to parse your output.
I do.
Do you not??
You could use the parser from commonmark instead of diy'ing your own
Nah the idea is to stay minimalist.
5-10 lines of VanillaJS maximum for some basic (and custom!) MD features is all I need.
Actually, yes. You can eliminate the body and HTML tags.
Here is an example of the kind of pretty minimal but valid HTML5 that I usually write when I write html by hand:
Check it :)<!doctype html> <html lang=en> <meta charset=utf-8> <title>Hello</title> <style> /* css here */ </style> <header> <h1>Cool beanz</h1> </header> <nav> <ul> <li>Home <li><a href=/foo.htm>Foo</a> <li><a href=bar.htm>Bar</a> </ul> </nav> <article> <h2>The Life and Dreams of Irish Setters</h2> <p>Widely appreciated for their qualities, the Irish Setter is a breed of dog to behold. <p>Lorem ipsum and so on and so forth. </article> <footer> <p>Copyright © 2024, Bob Schmob </footer>> Document checking completed. No errors or warnings to show.
Don't forget Server Side Includes :)
<!--#include file="/includes/header1.html" --> The Page Title <!--#include file="/includes/header2.html" --> The Article Title <!--#include file="/includes/header3.html" --> <p>The article content</p> <!--#include file="/includes/footer.html" -->I've got to ask, the H1, why is the site name the main heading and not the title of the article?
Mainly because it is recommended [1] to have only one h1 on a page. And my pages sometimes contain multiple articles.
It feels natural to me to have h1 be the site name. And have h2 be the content title. And it happens to work well when multiple unrelated articles or other kinds of content are on the page because then I use h2 for each of those.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/He...
Every time you use innerHTML, a kitten dies. How dare you!?
Hehe- I read it's the fastest possible way to modify DOM
It is so hard not to feel REALLY SMUG reading stuff like this, as someone who has run my own website as the working primary source for my college instruction for the past 15 years or so using https://zim-wiki.org. (before Markdown was much of a thing!)
It's borderline bizarre to have watched this method of doing things kind of die out, and then also come back in the form of "static site generators" -- which, frankly, are still way clunkier than this.
Write in Zim, export to html, rsync to site. Easy.
My website started as html in 1995, vanilla html, not even css or Javascript. It has evolved to accommodate stats, and at some point (whenever it was that it was first released) I created an ASP template to manage headers, footers, contacts.
Used to update things whenever a new ASP version was released, but haven't bothered for years.
Process is simple - copy ASP template, rename, fill in the content, FTP to hosting Co and done.
Do you use the built in "theme" or style of the output html? Much as I love zim-wiki for my notes I really dislike the green on white coloring.
Funny you should mention!
I'm not much of a programmer or designer at all, but probably my most popular thing is the "EightFiveZero" theme I made for Zim, which the author of Zim linked to from the wiki and makes me almost feel like a real programmer or something.
Updated post from 2020: https://ankarstrom.se/~john/articles/html2/
Also, I don't want to dump on this dude but I've authored literally hundreds of entries on my 2 blogs since 2019 using Markdown. I doubt I'd ever bother to write that many using plain HTML.
I think what the author is arguing for is not so much about writing in pure HTML, but the fact the levels of indirections added by most existing site-generating frameworks restricts them from doing something that would have been possible with just pure HTML. This second article seem to argue for owning your own site generator that is a thin wrapper around HTML, to deal with more dynamic content while maintaining flexibility.
I have being doing the same for my website since ~20 years ago, where my input is mostly pure HTML, and I generate static HTML pages from those with a few scripts. My website does look rather antiquated, but I consider that a feature.
On the one hand, I think everyone should try to put together a simple website with a few pages in raw HTML, just to get an idea of how it works. And actual, semantic HTML is not terrible in this day and age, much better than it used to be. You don't have to learn a static generator to put up a website, because you're the static generator.
On the other hand, I've written a lot of HTML since the 90s. And there's a dirty secret behind why so many static generators exist--the effort of slapping together something that builds a site how you want it is similar to learning an existing system. Often, that's a short build script rather than some expansive framework.
I'm not sure I agree that HTML is unpleasant to write. Honestly, even when I'm writing blog posts or articles, I often fall back to writing the HTML myself. It feels about as simple/complex as writing markdown, or using a WYSIWYG editor.
Maybe I just don't like being limited by abstractions.
The main thing that bugs me about HTML is how it’s so easy to goof up closing tags and attributes. Yeah browsers can deal with malformations to some extent and modern editors help prevent them but it still feels not-great.
That’s why I like HTML for the site’s frame and markdown for the content. The amount of HTML is then finite and easy to keep correct and Markdown is harder to mess up due to its simplicity.
Funny, that’s a complaint I have about Markdown. Anytime I use superscript or subscript, or try to nest markup within a list or table or something, I always get the formatting wrong. Whereas in HTML it’s always easy to nest things properly, even when dropping implicit end tags (which I always do), because the rules are both self‐consistent and standardized across implementations.
I agree nesting is easier with HTML. Most of the content I write is not really nested though, particularly when writing notes, to-do lists, etc. the low ceremony of markdown is a huge win over HTML for simple content.
Luckily, I find that dropping implicit elements and closing tags does a lot to keep HTML competitive in that sense.
It helps for sure, but it's still at least 2x more verbose in the ceremony required.
Remember that there are a few common elements, like <p> and <li>, that you usually don't need to close.
I’m the same way. I find the abstractions rarely add much for me. They just add needless complexity and future maintenance I won’t want to do. HTML is easy, it works, and doesn’t need as much care and feeding. If I need to update a long neglected site, I can just do it, and don’t need to spend time re-learning whatever abstraction happened to be in vogue when the site was first written.
If I’m feeling really fancy, and the need is really there, I might add some PHP for something that needs to be done server side. It’s simple and it works.
When I remember to update https://build-100-websites.fun/ with my recent antics (whew it's been a while), I like to write it in raw HTML just so I remember why I never ever do that anywhere else.
My typical tool of choice for static sites and plain old prototyping remains Hugo, which rounds out at least half a dozen other websites I'm the sole contributor to right now, like https://hiandrewquinn.github.io/selkouutiset-archive/. Like everything you have to amortize the one time cost of learning it over the n times you use it. If you only ever make one website, raw HTML might be fine -- if you're trying to make 100, some experimentation might be worthwhile.
I did this for a time and had attempted to commit to staying “no build tools” but after writing a few blog posts and needing to move content of the post around as I was writing it, I gave up the masochism. I do think that it’s important to know HTML as a web developer, and to get your feet wet sometimes, but unless you’re really able to deal with the genuine annoyance of writing only HTML and are doing it for puritanical reasons I don’t think there’s any real reason not to use a tool, especially if you plan to add things to your website.
Dreamweaver was perfect for this. It has templates and libraries and you wrote in a split editor with html and wysiwyg. Why was it abandoned by many web developers?
Complexity comes gradually.
You will not find reasonable to reparse HTML spit out from Dreamweaver or Word to fit js/cgi parts in there but withstanding 5 years of work you may find perfectly sane to compile JSX. Plus most of the people in the field never wanted to mantain two very different stacks for work and play, it's also a good way to dogfood.
Also you can recover better in plain text when markup is messed up vs a wysiwyg editor.
Dreamweaver produced clean html what a lie
We abandoned this because it produced markup that was horrible to maintain.
Not true. Dreamweaver produces very clean HTML
In 2024, maybe. We stopped using Dreaweaver 20 years ago, totally different story then.
Yes in 2024 it is a perfect static site generator but nobody uses it because it was a mess in the past
I'm really liking writing HTML in markdown. Write the markdown, feed it to commonmark's parser, splice the text together in ad hoc sorts of ways. Robust, trivial.
Css on the other hand I hate more every day I look at it. Write some, see if it behaved as expected, it did not. Iterate until angry. There's something fundamentally wrong in my mental model for what the style text is likely to do to the appearance of the page.
For years, I had the same experience you're describing. Writing CSS felt more like guessing than anything else.
A few weeks ago I decided that enough's enough. After years of writing CSS, I decided to refresh my knowledge with an intermediary level course. It turns out, a lot of stuff got mixed out, a gaps formed and grew over time.
Now, I enjoy writing CSS again as I find it more predictable and behaves as expected.
What was the course you took?
I stopped looking at SSGs after this:
for file in .md; do pandoc --quiet --template template.html $file -o "${file%.}.html" done
reminds me of tundra.sh https://frainfreeze.github.io/tundra/ (https://github.com/frainfreeze/tundra/blob/master/tundra.sh#...)
just does a lil bit more ig
So no index or other listing of articles. No RSS.
I‘ve been tempted a few times, as well, but it‘s a little bit too sparse for me.
You guys trying to revive the FrontPage/Dreamweaver era?
Sure, when your site looks like it's from 1995. Client apps today have hundreds of custom features running simultaneously.
Of course you wouldn't use this if you're being paid to make an application for profit. You use less good technologies that make it easier to collaborate with other employees, or more importantly: whatever buzzword tech of the year gets you hired. But for personal sites where you get to choose? HTML.
The commercial app you write will last a few years before breaking. But the HTML site will last forever.
A blog is a blog. There's always CSS and the "class" attribute to make things look however you want. Reading text and images doesn't require interactivity or scripting.
Most sites don’t need 98% of the trash running on the site. If the goal of a site is to display information, all the modals, advanced analytics, parallax effects, video ads, etc distract from main goal, rather than enhance it.
> Sure, when your site looks like it's from 1995
Tail end of 96 at least, even the link uses CSS. In principal you can also write JS manually within HTML.
> Client apps today have hundreds of custom features running simultaneously.
How many of those features are adverts and user-unwanted tracking that you need a GDPR compliance team for?
The site could benefit enormously from these 10 lines of CSS: https://news.ycombinator.com/item?id=32972004
It makes the site look modern instantaneously.