Note that closing </p> tags are optional<i>†</i>, so one can be an HTML purist and still write a decent HTML document with a relatively clean markup like this:<p><pre><code> <!DOCTYPE html>
<html lang="en">
<title>Lorem Ipsum</title>
<h1>Lorem Ipsum</h1>
<p>
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Duis id maximus tortor. Sed nisi ante, fermentum vel nunc
et, tincidunt sagittis magna. In ultrices commodo lacus, id
tristique ipsum euismod laoreet.
<p>
Maecenas at neque posuere, aliquet erat at, vehicula est.
Duis aliquet elit et arcu laoreet, id pulvinar eros pretium.
Quisque consectetur, enim semper facilisis feugiat, velit
sapien semper arcu, eu mollis libero est et odio.
<p>
Curabitur fringilla interdum ante vel ultricies. Mauris
volutpat nisi sed turpis elementum elementum. Mauris nec
eleifend lorem. Sed ac vulputate libero.
</code></pre>
A valid HTML5 document does not require<i>†</i> explicit <head>, <body>, or the closing </p>, </html> tags. See the spec for optional tags at <a href="https://html.spec.whatwg.org/multipage/syntax.html#optional-tags" rel="nofollow">https://html.spec.whatwg.org/multipage/syntax.html#optional-...</a> for more details. Similarly, the markup for lists and tables can be cleaned up too because the closing </li>, </tr>, </th>, </td> tags are optional<i>†</i>.<p>Note that the opening <html> tag is optional<i>†</i> too but I retained it in the above example to specify the lang attribute otherwise the W3 markup validator warns, "Consider adding a lang attribute to the html start tag to declare the language of this document."<p><i>† These tags are optional provided certain conditions are met. See the spec for full details. In practice, one rarely has to worry about these conditions.</i>
I think it's a bit of a shame that this discussion has focused on the tech and (slightly odd) HTML choices here. Those are probably the least interesting parts of any discussion around what a "next gen" blog platform might look like.<p>Where the author is correct about next-gen blogging (in my opinion anyway) is in the attempt to reduce the friction to publishing a new post. What tech stack you use, whether it's static, what your HTML looks like, are all entirely secondary to whether or not you actually use your blog to build a corpus of content that shows off your opinions, expertise, and insights over time. That's what a blog is. It isn't HTML tags and CSS. It's the content within the tags. For me any next-gen blog tech has to make 3 things trivially easy -<p>- it needs to be simple to set up and maintain. If my laptop dies and I can't just clone my blog's repo and run a couple of commands to get back to where I was it won't work.<p>- it needs to be <i>really</i> simple to publish a post. Most blogs use Markdown with either front matter or a specific file path. That's OK but it puts most of the cognitive load on me. I'm sure there's a better way but I don't know what it is. I use 11ty for my blog which is very good, and if I didn't worry about URLs as much as I do it would be could actually work. But I do.<p>- there's nothing that pushes me to write more. This is the kicker, and no one has ever solved it. I think a blog platform that recommends posts I should write, and that praises me for writing, would drive me to actually write far more than I do. So far the only blog platform I've seen come close is Hashnode, but even that doesn't do it very well.
It's funny that we've come full circle. The web had started with static web sites. Many of them had misused HTML tags to take shortcuts, and to achieve a certain look, including `<pre>`, `<table>`, etc. That had eventually caused so many compatibility issues that we thought malformed documents were a problem, so we defined a rigid structure for HTML called XHTML. We discovered the value of semantics and separated style from content with CSS. Then, we thought XHTML was too much work and just went back to loose style with HTML5 for ease of use. Then, people thought CSS was so much work that they applauded Tailwind for brining styling back into HTML. And three decades later, "next-gen static blogging" is about misusing HTML tags to take shortcuts, and to achieve a certain look. :)
So, instead of using semantic html and css like 'white-space: pre-line' and 'max-width: 40ch' author wrapped content of his blog post into 'code' tag and called it 'next-gen'. What is 'next-gen' about it? Either I am missing something or I'm not drunk enough. Worst thing it has 100 upvotes :/<p>>Simplicity is key<p>This isn't simplicity...<p>I need a beer.
Your site is too hard to read on. Make the color of the font darker or the background lighter please.<p>I had to copy to a notepad so I could read it.<p>Edit:<p>Apparently, dark mode users get this - <a href="https://i.imgur.com/5PHYac1.png" rel="nofollow">https://i.imgur.com/5PHYac1.png</a><p>I get this - <a href="https://i.imgur.com/5PHYac1.png" rel="nofollow">https://i.imgur.com/5PHYac1.png</a><p>Light mode is terrible, dark mode is okay. Please increase the contrast in both places.
Why is he bragging about being awful at web dev? <p> tags exist for a reason. You're not cool for omitting them, you're hurting your users.
I applaud that simplicity seems to be trending, but the benefits of not having paragraph tags don't seem to outweigh the downsides. It's not that big of a deal, and it enables reader mode.<p>Leaving as much as possible left to default is what I prefer; it supports the greatest number of browsers and assume is the fastest. <a href="https://www.quitfacebook.org/file/play.html" rel="nofollow">https://www.quitfacebook.org/file/play.html</a>
Many static site generators, including Hugo and Jekyll, have file watching support and even automatic page reloads, so their workflow is barely different from editing raw html. You have to jump through some more hoops for raw html, but I expect you save time overall.
I ran to my desktop to load this up and have a look. I'm ALWAYS looking for a more simple blogging solution. I was hoping for mostly plain text plus an em tag here or there. It's a little more involved than that, but it's given me some ideas.<p>Shameless plug, I created the NeatCSS framework to have this "simple" look and feel. On that, however, I didn't try to avoid your typical HTML code.<p><a href="https://neat.joeldare.com" rel="nofollow">https://neat.joeldare.com</a>
If the only thing being removed were <div> tags, which don't have structural or semantic meaning, it would probably be just as easy to parse for screen readers and robots.<p>Two problems I see:<p>1. Where you have a heading you may want it and its associated content wrapped in a <section>. Where you have a separated paragraph you really do probably want a <p>.<p>So these newlines aren't always just replacing <div>s. The page has no structure except what can be derived from headings.<p>2. Wrapping everything in a <code> tag seems like it could cause issues. It would probably be better to use <main> and apply the clever one line of CSS mentioned in the post.
How well is this handled from the accessibility point of view? I imagine that wrapping text in consecutive “p” tags is semantically clearer, however on the other side it shouldn’t be too hard for any accessibility software to recognize this pattern described in the article.<p>EDIT: some wording changes.
I like the white-space: pre-line trick and very much like the omission of unnecessary <html> and <head> tags as the parsing of such valid source is neatly prescibed.<p>But abusing <code>, <h4> and <h5> like that is a horrendous and pointless. Please use the proper tags to keep the web clean.
Is this better than my 2001 solution of wrapping everything in a <pre> tag?<p><a href="http://lumma.org/microwave/" rel="nofollow">http://lumma.org/microwave/</a>
Maybe an expert can confirm, but my understanding is that this would be poor from an SEO standpoint.<p>I don't really see how this can be next-gen when it strips out any semantic elements.
Author here: Sorry for not considering accessibility more. I use solarize everywhere - I’ll look into fixing the low contrast issue. As for whether my approach is correct from an SEO or HTML5 validation perspective - evidently not. But I do value the feedback and will take your comments into consideration when expanding my personal site. It’s still a WIP.
> No need for JavaScript or any other complicated backend or client-side frameworks. I can use PHP to introduce dynamic elements to the page, but that's optional.<p>This isn't the same "dynamic" - the author must know that JS can provide interaction without a page refresh; PHP (alone) cannot.
Excellent performance, sketchy accessibility. But I applaud the effort to look for simplicity, even if it wouldn't work for many production use cases.
This was my experience...<p>1. Read first sentence,<p><pre><code> Take a look at the source code of this page - I rely mostly on CSS for the rendering of this article.
</code></pre>
2. Right click, "View Page Source" on Firefox (`84.0.2 (64-)bit)`)<p><pre><code> Edit: adding that I do have `NoScript 11.1.8` and `uBlock origin 1.32.4` installed.
</code></pre>
3. Close source pop-up/tab.<p>4. It takes ~10 seconds to re-render the page (with spinner gif running, in the meanwhile).<p>5. Tab completely frozen.
it's like a, messy, non-standard semantic web... at this point, and i'm totally serious, why not starting again to work on XHTML 2.0 standard? We need it badly.
Agree that static blogging is nice, but I think this specific look needs some tweaking - for example, there's too low contrast in color between the links and the background at <a href="https://inoads.com/blog" rel="nofollow">https://inoads.com/blog</a>
Wow, never heard of that CSS property — cool!<p>Regarding medium, I think the biggest barrier is the network/promotion you get from medium. Discovery and sharing within the network brings audiences you'd otherwise have to work quite hard for on your own site.
Cool. Go one step further and render the CSS inline.<p>Of late, I have been writing with just MarkDown and dropping in some of the simplest tool (Pandoc, Jekyll) possible to render as HTML.
Anyone else found the color contrast absolutely terrible to read? i suspected this and then ran a lighthouse check and.. yup. contrast check fail. you can also use <a href="https://color.a11y.com/Contrast/" rel="nofollow">https://color.a11y.com/Contrast/</a><p>There's no point pontificating about the next generation of static blogging when you forget the basics - make the writing easy to read.
> The experience to writing this blog entry is very similar to using a dedicated word processor<p>Except for the fact that a word processor does more than break lines. For example, when you type ", your word processor will convert this to a left opening quote or a right closing quote based on context. But the " in this article are still ". I guess they could have used a word processor after all.
This is ridiculous, only two articles on this blog and one is about static blogging.<p>In the next generation, I implore people to focus on <i>content</i>, not the tech.
Running this site through an HTML validator generates quite a few errors.<p><a href="https://validator.w3.org/nu/?doc=https%3A%2F%2Finoads.com%2Farticles%2F2020-01-09-Next-Gen-Static-Blogging" rel="nofollow">https://validator.w3.org/nu/?doc=https%3A%2F%2Finoads.com%2F...</a>
<p><pre><code> <body style="white-space: pre-line">
The idea is that an extra newline within a block with style="white-space:
pre-line" acts like &lt;p&gt; paragraph elements.
This is a separate paragraph.
</body></code></pre>
Interesting concept. This seems to simplify the writing part. What about the rest? Is the list of posts generated automatically (if so, how?), or does it require manual management? Do you need the code tag, or could it be something more semantically relevant, such as article?
A neat little css property aside, isn't the separation of concerns a cornerstone of web pages?<p>Html - structure of the document
CSS - appearance
JS - interactivity<p>I could be wrong, but that's how I remember it. Is there an advantage to moving away from this fairly simple and unambiguous paradigm?
Build setups can get complicated and simple sites can send way to much javascript to the browser. But neither one of these are required outcomes.<p>I think it's ok to have build tools that do small automations to make writing more pleasant yet keep the markup semantic and accessible.
If I'm understanding correctly, here, the semantic value of the <code /> element is ignored to increase DX.<p>I personally wouldn't make that compromise, why is pre-processing not simple enough?
I've built the simplest static site generator. <a href="https://github.com/eguneys/jener" rel="nofollow">https://github.com/eguneys/jener</a>
I'm glad I'm not so blind that I need a screenreader for this site, because @mmackh doesn't seem to have given any consideration to accessibility.<p><a href="https://wave.webaim.org/report#/https://inoads.com/articles/2020-01-09-Next-Gen-Static-Blogging" rel="nofollow">https://wave.webaim.org/report#/https://inoads.com/articles/...</a><p>If this is "next gen", I think I'll stick to using emmet-mode in Emacs to write raw HTML, templating with m4 macros, validating with tidy, and doing the build and deployment with a makefile.