Note that closing </p> tags are optional†, so one can be an HTML purist and still write a decent HTML document with a relatively clean markup like this:
<!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.
A valid HTML5 document does not require† explicit <head>, <body>, or the closing </p>, </html> tags. See the spec for optional tags at https://html.spec.whatwg.org/multipage/syntax.html#optional-... 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†.
Note that the opening <html> tag is optional† 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."
† 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.
Trailing slashes on HTML tags are useless. They’re allowed on void elements, for XML compatibility, but are by definition simply ignored. I recommend against including them, because they’re simple visual noise, and misleading because they don’t actually close tags—you can only use them on on elements that are defined as having no children.
(Note that I say HTML tags; on foreign elements—meaning inline SVG and MathML—trailing slashes do make tags self-closing, XML-style.)
Also since I’m writing, that viewport declaration is wonky. It should have device-width, and it should not have maximum-scale which is user-unfriendly.
Although you could omit the closing tags, I don't see the benefit of doing so. If you know HTML, nesting is fundamental and not explicitly closing dom nodes would lead to confusion. You would also need to concern yourself with the "certain conditions" that must be met for it to work. Consistency and clarity over brevity!
That's right, but it's probably more interesting that HTML 5 simply hard-coded these rules based on the tag inference features of SGML and the particular per-element tag omission indicators of HTML 4 and earlier SGML DTDs for HTML (see links on how head and body elements in your example document are inferred by SGML in detail).
Not having valid XML in the first place complicates any further processing quite a lot. Also you're going to run into annoying and / or strange issues with tooling.
Those HTML shortcuts are just not worth it. Their value is "questionable" (to put it kindly) but down the road their cost can become surprisingly high.
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.
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 -
- 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.
- it needs to be really 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.
- 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.
Author created static website where he manually links to each page and he claims this is 'next-gen' of blogging. You know what's next gen of blogging? Substack. You know why? It's because for most people rss is "hard" to use (mostly because they aren't familiar with it, thanks Google!), meanwhile everyone is familiar with email clients.
Author says:
> Managing this blog is a little more involved than dynamically generating everything.
and
> Simplicity is key.
If he will blog for long enough that simplicity might become a technical debt. Right know this 'next-gen' blog doesn't even have an rss feed.
It's great that the content area is simpler, but if I just typey-typey for the blog post and then have to manually create backlinks and the RSS feed item then forget it.
IMHO blogs are documents, and HTML is no longer designed for documents but web applications.
Blogs need to go back to document publishing formats. It doesn't get more user-friendly than 1. WYSIWYG word processor; 2. Save As PDF; 3. Dump the file on a web host.
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. :)
Given that we're paying per CPU-seconds and MBs transmitted while running our stuff again on mainframes (The Cloud) this makes perfect sense, doesn't it?
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 :/
I wholeheartedly agree with you but there isn't any amount of beer or misuse of standard HTML tags that could fix this. It kind of anti-resonates a lot with the other post currently on the front page "Woo for its own sake". It also shows how the HN crowd is split in two, those who like this kind of stuff and those who don't. For my part and in my day job these are the kind of things that I actively fight against.
As a fun exercise I still appreciate OP's effort for trying out something new, it's always welcomed and I think this forum is all about that. However, I don't agree with the clickbaity title techniques. I hope it doesn't normalize the practice here otherwise I'd throw in some Vodka as well :)
HN content and discussion quality has gone down drastically over the last few years. And future also looks bleak. These days I spend more time on lesswrong.com community because articles and discussions quality are way better than HN.
You can do that yourself as a one-off change using the web tools. On Chrome, just right click on some whitespace and click inspect. On the bottom right, you'll find an option to the change the background color of the body section. There's something similar on firefox as well.
(ideally, the website should get the fix rather than you doing it... but this works better than notepad!)
Lower the contrast? Strongly disagree. Its use of gray text on a dark blue background is pretty common. If anything, the contrast is too low; I'd brighten the text if I were the designer. But it's readable.
In my opinion, what makes it a bit difficult to read is the use of a fixed-width font for body text. Fixed width is great for code, but proportional-width fonts are easier for reading prose.
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.
Leaving as much as possible left to default is what I prefer; it supports the greatest number of browsers and assume is the fastest. https://www.quitfacebook.org/file/play.html
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.
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.
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.
Two problems I see:
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>.
So these newlines aren't always just replacing <div>s. The page has no structure except what can be derived from headings.
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.
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.
But abusing <code>, <h4> and <h5> like that is a horrendous and pointless. Please use the proper tags to keep the web clean.
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.
Note that when people speak of colour contrast ratios, they’re looking at a painfully simplified model that is useful, but nowhere near sufficient. The most significant way in which it is insufficient is the consideration of font weights: thinner fonts need higher contrast to be legible. This is particularly seriously demonstrated here by the use of the monospace font-family: some platforms have a default monospaced font that is way thinner than others (like, weight 250–300 instead of 400), and so Solarized, which I find unpleasantly low-contrast even with a fairly heavy font, becomes positively awful.
I'm also a huge fan of solarized, so I know from some styling
experiments with LaTeX documents that solarized just has a bit
too little contrast for normal text documents. Which is why I'd
recommend adjusting the text brightness - it still looks
relatively similar but helps significantly.
> 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.
This isn't the same "dynamic" - the author must know that JS can provide interaction without a page refresh; PHP (alone) cannot.
[+] [-] susam|5 years ago|reply
Note that the opening <html> tag is optional† 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."
† 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.
[+] [-] chrismorgan|5 years ago|reply
(Note that I say HTML tags; on foreign elements—meaning inline SVG and MathML—trailing slashes do make tags self-closing, XML-style.)
Also since I’m writing, that viewport declaration is wonky. It should have device-width, and it should not have maximum-scale which is user-unfriendly.
All up:
And for completeness, https://html.spec.whatwg.org/multipage/syntax.html#elements-... defines void and foreign elements.[+] [-] cwackerfuss|5 years ago|reply
Although you could omit the closing tags, I don't see the benefit of doing so. If you know HTML, nesting is fundamental and not explicitly closing dom nodes would lead to confusion. You would also need to concern yourself with the "certain conditions" that must be met for it to work. Consistency and clarity over brevity!
[+] [-] tannhaeuser|5 years ago|reply
[1]: https://www.youtube.com/watch?v=jy-b4jeJSas&list=PLQpqh98e9R...
[2]: http://sgmljs.net/blog/blog1701.html (the "Talk" link for slides)
[+] [-] kubanczyk|5 years ago|reply
> <html lang="en">
Yeah, no. The text is in Latin (la), not in English (en).
[+] [-] still_grokking|5 years ago|reply
Not having valid XML in the first place complicates any further processing quite a lot. Also you're going to run into annoying and / or strange issues with tooling.
Those HTML shortcuts are just not worth it. Their value is "questionable" (to put it kindly) but down the road their cost can become surprisingly high.
[+] [-] galaxyLogic|5 years ago|reply
[+] [-] simonebrunozzi|5 years ago|reply
Could you explain the use of that "cross" symbol, versus what I use normally, [0] [1] etc. ?
[+] [-] fsiefken|5 years ago|reply
[+] [-] onion2k|5 years ago|reply
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 -
- 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.
- it needs to be really 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.
- 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.
[+] [-] rayrag|5 years ago|reply
Author says: > Managing this blog is a little more involved than dynamically generating everything.
and
> Simplicity is key.
If he will blog for long enough that simplicity might become a technical debt. Right know this 'next-gen' blog doesn't even have an rss feed.
[+] [-] billbrown|5 years ago|reply
- search - categories - RSS - archive pages - header/footer/navigation
It's great that the content area is simpler, but if I just typey-typey for the blog post and then have to manually create backlinks and the RSS feed item then forget it.
There is such a thing as _too_ simple.
[+] [-] jl6|5 years ago|reply
Blogs need to go back to document publishing formats. It doesn't get more user-friendly than 1. WYSIWYG word processor; 2. Save As PDF; 3. Dump the file on a web host.
I'm switching to PDF/A: https://lab6.com/0#page=2
[+] [-] sedatk|5 years ago|reply
[+] [-] still_grokking|5 years ago|reply
[+] [-] rayrag|5 years ago|reply
>Simplicity is key
This isn't simplicity...
I need a beer.
[+] [-] ilovefood|5 years ago|reply
[+] [-] thunderbong|5 years ago|reply
I prefer this -
https://every.sdf.org
[+] [-] rpdillon|5 years ago|reply
https://inoads.com/style.css
[+] [-] johncena33|5 years ago|reply
[+] [-] ffpip|5 years ago|reply
I had to copy to a notepad so I could read it.
Edit:
Apparently, dark mode users get this - https://i.imgur.com/5PHYac1.png
I get this - https://i.imgur.com/5PHYac1.png
Light mode is terrible, dark mode is okay. Please increase the contrast in both places.
[+] [-] city41|5 years ago|reply
edit: nevermind, switched to dark mode using the dev tools. It looks like this just to be complete: https://i.imgur.com/qPv7guO.png
[+] [-] _4570|5 years ago|reply
(ideally, the website should get the fix rather than you doing it... but this works better than notepad!)
[+] [-] bhauer|5 years ago|reply
In my opinion, what makes it a bit difficult to read is the use of a fixed-width font for body text. Fixed width is great for code, but proportional-width fonts are easier for reading prose.
[+] [-] robertoandred|5 years ago|reply
[+] [-] otherme123|5 years ago|reply
[+] [-] Priem19|5 years ago|reply
Leaving as much as possible left to default is what I prefer; it supports the greatest number of browsers and assume is the fastest. https://www.quitfacebook.org/file/play.html
[+] [-] Scaevolus|5 years ago|reply
[+] [-] chacha2|5 years ago|reply
[+] [-] codazoda|5 years ago|reply
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.
https://neat.joeldare.com
[+] [-] clintonb|5 years ago|reply
Why?
[+] [-] pickpuck|5 years ago|reply
Two problems I see:
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>.
So these newlines aren't always just replacing <div>s. The page has no structure except what can be derived from headings.
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.
[+] [-] martinsb|5 years ago|reply
EDIT: some wording changes.
[+] [-] tomtomtom777|5 years ago|reply
But abusing <code>, <h4> and <h5> like that is a horrendous and pointless. Please use the proper tags to keep the web clean.
[+] [-] throwaway4good|5 years ago|reply
[+] [-] beefman|5 years ago|reply
http://lumma.org/microwave/
[+] [-] andyp-kw|5 years ago|reply
I don't really see how this can be next-gen when it strips out any semantic elements.
[+] [-] mmackh|5 years ago|reply
[+] [-] chrismorgan|5 years ago|reply
[+] [-] angus_gh|5 years ago|reply
[+] [-] alpaca128|5 years ago|reply
[+] [-] hashkb|5 years ago|reply
This isn't the same "dynamic" - the author must know that JS can provide interaction without a page refresh; PHP (alone) cannot.
[+] [-] codingdave|5 years ago|reply
[+] [-] MoOmer|5 years ago|reply
1. Read first sentence,
2. Right click, "View Page Source" on Firefox (`84.0.2 (64-)bit)`) 3. Close source pop-up/tab.4. It takes ~10 seconds to re-render the page (with spinner gif running, in the meanwhile).
5. Tab completely frozen.