Next Gen Static Blogging | Hacker News Reader

Next Gen Static Blogging

inoads.com

227 pointsmmackh175 comments

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.

Frontend developer here --

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!

Especially with HTML as it's going to get minimized and hacked up to reduce the filesize. Including the closing tags makes the transpilers job easier and less error prone.

A transpiler that gets confused when optional tags are missing (a feature explicitly allowed by the spec) is a broken transpiler and it needs to be fixed. This is like the automatic semicolon insertion of JavaScript debate[1][2] all over again. These things are spelled out in the standards and tools that do not adhere to the standards are broken.

[1] https://web.archive.org/web/20201206065632/http://inimino.or...

[2] https://blog.izs.me/2010/12/an-open-letter-to-javascript-lea...

Yeah, fine. The tool is broken. Right.

But YOU have still an issue.

The Point is: There a lot of broken tools out there, and you can't know which of them will be used in the future. Just avoid a lot of headaches for your future self and your colleges by not testing out the spec-compliance of all those tools you'll probably use at some point.

> But YOU have still an issue.

I disagree.

> There a lot of broken tools out there

A tool that incorrectly handles optional tags may handle other parts of the spec incorrectly too. Such a tool may provide incorrect results for even perfectly well-written HTML. There is no know what it takes to make all the broken parsers out there happy.

I know you made a point about ETL tools[1] where XML parsers are used to parse HTML but there is no way to cater to such absurd use cases anyway. Using an XML parser to parse HTML5 is not going to work correctly anyway even if you do retain the optional tags because it would fail on other HTML5 tags that do not have closing tags such as <meta>, <link>, <img>, etc., empty attributes like <input disabled>, <input required>, etc. Web developers from all around the world are not going to start writing self-closing <img /> tags just because these broken ETL tools have decided to use an XML parser to parse HTML5.

There are plenty of good HTML5 parsers out there for almost every mainstream programming language. Just use them.

[1] https://news.ycombinator.com/item?id=25708209

Most of the "plenty of good HTML5 parsers out there" are broken. No wonder as the spec is nuts. (It took years before there was even a correctly working validator).

Also I was explicitly talking about XML compatible HTML. It's called so because it's XML compatible.

Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-)

> Most of the "plenty of good HTML5 parsers out there" are broken.

Can you name a few popular and widely used HTML5 parsers that are broken and tell us what the bugs are in those parsers? I would be surprised if you can find or name even two such parsers that are popular but cannot handle optional tags correctly as required by the spec.

> Also I was explicitly talking about XML compatible HTML.

There is no such thing as XML compatible HTML (unless you mean XHTML which we are not discussing here). Maybe you mean XML-serialized HTML5. I can only guess since the terminology you are using is vague and unclear. In any case, HTML5 by itself is incompatible with XML. I mentioned this in my previous comment. Not all tags in HTML5 are self-closing, thus incompatible with XML. XML-serialized HTML5 is however compatible with XML, by definition, and in that case, one would use an XML parser, not an HTML5 parser. More importantly, you can safely omit the optional tags and still convert your HTML5 document into XML-serialized HTML5 document without any issues whatsoever. This was explained to you by anjbe here at https://news.ycombinator.com/item?id=25706163. He is absolutely right.

> Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-)

You see all the tags there because it shows the entire DOM. The browser automatically creates the elements when optional tags are not explicitly present in the HTML. This is all spelled out in the spec very clearly. Any HTML5 parser worth its name follows the spec. I am not sure what your point is here.

See https://html.spec.whatwg.org/multipage/syntax.html#optional-... for details, especially:

"Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string <html> doesn't appear anywhere in the markup."

I hope that explains why you always see the elements for the optional tags in a web browser's developer tools.

The minimizer should output HTML without unneccesary tags, and it should probably expect to run on its own output, so I don't see why adding unneccesary tags would help it work.

I am not a frontend developer. I agree with you. I write my blog posts with handwritten HTML because that is how I began writing blog posts many years ago when Markdown was not as popular as it is now. Indeed I never omit any optional tags while writing my blog posts or blog layout.

I am not necessarily recommending that one should omit the optional tags. However, it is worth noting that the option to do so while conforming to the HTML5 spec is there. The "certain conditions" are not really much to worry about. I think they are drafted quite carefully and are quite sensible. If one is writing simple HTML documents, say, for blog posts, text-based articles, etc. one can safely omit the optional tags without running into issues due to the "certain conditions".

> Indeed I never omit any optional tags while writing my blog posts or blog layout.

Do you type <tbody> every time you write a table? That is an optional implicit tag that can be left out just like <html>, <head>, and <body>.

I don't type <thead> and <tbody>. I believe that's an exception to the practice of never omitting optional tags. Maybe there are a few more exceptions like that but none that I can remember right now. Thanks for posting this comment. It made me realize that my previous claim was inaccurate.

I write plenty of HTML by hand, for myself. I prefer to omit things like </p>, </li>, </td> and </tr>, because it takes less effort (and I hate text editor plugins that automatically add closing delimiters of any form, because they always do the wrong thing a meaningful fraction of the time in a way that I have to think about, more than if I just type the delimiters myself, though an accurate “insert at the cursor whatever is needed to close the last thing” shortcut might be handy), and reduces visual noise.

I also normally omit quotes on attribute values if correct to do so.

I mostly do these things when working on things of my own, when I know no one else needs to worry about them. When working on things others will touch, I don’t drop quite as many closing tags, and will normally leave attribute values quoted.

> I hate text editor plugins that automatically add closing delimiters

Glad I'm not the only one. The less an editor does automatically to "help" me the better. I agree, a shortcut to close the last opening syntax element would be nice, but for this to work properly the editor needs to be aware of how all the syntax elements interact, e.g. to differentiate between '<' used in a logical comparison and the same symbol as start of an XML tag. Or to correctly close an XML tag no matter if it has attributes.

I have a shortcut in Vim for three different kinds of brackets but it's a bit janky. Still better than the automatic stuff the typical IDE and modern editor does without asking, though.

The man who collects rocks in his pockets eventually drowns.

> You would also need to concern yourself with the "certain conditions" that must be met for it to work.

You have to concern yourself with them anyway. If you do something that automatically closes an element, it's automatically closed at that point whether you put a close tag somewhere later on (that will be ignored) or not. This is like semicolon insertion in JS: the fact you're using semicolons does not mean you can ignore the rules for how they're inserted.

> the opening <html> tag is optional too but I retained it in the above example to specify the lang

> <html lang="en">

Yeah, no. The text is in Latin (la), not in English (en).

~Any references to support your claim?~

[Edit: I notice now that the content is indeed written in Latin. It contains the "Lorem Ipsum" placeholder text. Nice catch! :-)]

To be fair, you did write your post in Latin:

> 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.

Hmm I always thought lorem ipsum was a text with letter usage histograms similar to English, without distracting the reader with meaning. I could have sworn I read that somewhere...

Lorem ipsum is words/phrases copied from one of Cicero's writings, "De finibus bonorum et malorum". It's not a straight copy, kind of like if you copied every other word in places, but it's definitely Latin.

It does likely have relatively similar usage patterns to English in terms of letter distribution, if only because they're both indo-european languages and English has deep vocabulary ties to Latin through Norman influences.

You are almost right: The distribution of letters and length of words is similar to that of the Latin language. But it is not Latin and the text does not make sense. It's gibberish.

Those are Latin words, drawn from a Latin source.

“Pencil what comma building twenty section human fedora”

is English, even if it makes no sense.

The words are English words, but many would argue it's not an English sentence.

> Those are Latin words, drawn from a Latin source

No, "Lorem" is "dolorem" with the first part chopped off, "adipiscing" and "elit" are mangled non-words, too, and so on.

"Pencil what correct horse battery staple" can be called a sequence of English words. If someone who doesn't know what they're doing writes "ncil what correctando taple", though, then you're no longer in a position to say, "Those are English words".

This is true. And still it is (nonsensical) Latin. It's chosen because Latin looks quite similar to English text. They use the same alphabet and word length tends to be similar.

la-gb? (Latin, Gibberish?)

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).

[1]: https://www.youtube.com/watch?v=jy-b4jeJSas&list=PLQpqh98e9R...

[2]: http://sgmljs.net/blog/blog1701.html (the "Talk" link for slides)

And since we’re talking about optional things:

  <link rel="stylesheet" href="/style.css" />
  <meta name="viewport" content="initial-scale = 1.0,maximum-scale = 1.0" />

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.

All up:

  <link rel="stylesheet" href="/style.css">
  <meta name="viewport" content="device-width,initial-scale=1">

And for completeness, https://html.spec.whatwg.org/multipage/syntax.html#elements-... defines void and foreign elements.

They're optional in the same way that braces around single-statement "if" clauses are optional in most curly brace languages—and indentation, for that matter—i.e. they still serve a purpose for many humans who are going to be tasked with upkeep and will choose to include them for personal reasons. Not every decision is rooted in trying to satisfy the machine. But speaking of machines, on that note...

If you ever have to write any tooling for HTML processing, you'll realize that they can be useful for machines, too. If your team doesn't make use of any of these "features" that trigger corner cases in the spec, then you can adopt an XML-like parsing strategy (where these aren't optional) and your parser can be simpler than if you were to implement the entirety of the HTML5 parsing algorithm. You don't need any notion of void elements, and your parser doesn't need hardcoded lists of which elements are among them. You can write a "dumb" parser that can derive the node structure without needing any intimate knowledge of HTML. It's like the difference between parsing S-expressions and parsing an ALGOL-like language.

I do think there’s an important difference from the optionality of curly braces on if statements in many languages: syntax highlighting will normally make it very obvious what is attribute name and what is attribute value, so that any error will be obvious, more obvious than the probable incorrectness of something like `if (a) b; c;` on one line.

Your point on HTML processing is a nice idea, but quite useless in practice for HTML. XHTML failed: people didn’t want to go to the effort of getting it all rigorously correct; they rather wanted the browser to guess what they meant, because it got their intent right most of the time, and now they could forget about various details like tbody elements and trailing slashes. I regularly look at page sources, and I regularly encounter people putting these trailing slashes on various void element; but I can’t remember when I last found a page that actually applied that consistently—invariably they have at least one void element without a trailing slash. My conclusion is that the whole thing is misguided. I would be curious to see the result of attempting to parse all the HTML in something like Common Crawl with an XML parser. I suspect that barely any pages would succeed.

The fact of the matter is that the HTML parsing algorithm is well-defined and very nuanced, so if you’re processing HTML you should use a real HTML parser, and to do anything else is folly—unless you are assiduous about maintaining XML correctness, which you can do, but it’ll be even more of a footgun for others than omitting quotes on attribute values. But if you’re writing something new, then by all means, strongly consider the comparatively simple and principled XML philosophy over the organic and complicated philosophies of the HTML serialisation.

This comment comes off as very, very, very... weird. A little condescension and a lot of pretending that the goalposts are there when before they were here (and still are, too); almost no "situational awareness" or acknowledgement of the actual context, constraints, and motivation behind making a choice about what to do. Syntax highlighting (esp. for attributes[???]) has _nothing_ to do with what we're talking about (trailing slashes, void elements), for example—and it gets worse from there.

The logical coherence of this response is in "not even wrong" territory.

https://en.wikipedia.org/wiki/Not_even_wrong

It would be valid, but wouldn't Google penalize it for being poor html?

If it doesn't, it should.

It makes the life of parsers a lot harder.

Under what definition is leaving off optional closing tags “poor html”? It is perfectly valid, part of the spec, very widely used, and completely unambiguous.

This is great point. Doesn't it mean that "markdown" is kind of redundant ?

Please never ever break XML compatibility!

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.

Only one branch of the HTML family tree was ever XML compatible. I was a heavy user of XHTML in the day, so I'm sympathetic... But it's misleading to characterize non-XML variants of HTML as questionable shortcuts.

Strictly speaking, HTML is still XML-compatible—the XML serialisation is still a thing, though pretty rare these days. But yeah, the HTML serialisation is not XML-compatible, though you can easily write documents that will be parsed identically by the XML and HTML parsers.

You don’t seem to realize that your post only applies to xhtml doctypes and your concern is extremely outdated to boot.

Use an html parser to parse html.

You also are extremely off on your estimation of how common xhtml is on the web since you thought this would be a useful PSA and you seem unaware of what <!doctype html> means here, as it specifically is not xml. I’m not tying to be mean, but you came in with guns blazing with weird advice and it seems very mislead.

Note that the XML serialisation of HTML is still a thing—if you open a .xhtml file or navigate to something served with the content-type application/xhxml+xml, the XML parser will be used instead of the HTML parser.

Implicit and optional tags have been part of HTML for decades. A valid HTML page that uses them is completely unambiguous. Nothing prevents it from being parsed and converted to an XML‐compatible document on the fly by tools.

Writing HTML in an XML‐like fashion has its own quirks since HTML is not parsed the same way. Can you add elements within an <img></img>, or self‐close a <span/>?

Automatic conversion to XML is not always possible cleanly as those documents tend to not follow all rules (which can happen for example by template nesting). At that point you have a headache.

The point of being XML compatible is not about the browser environment. It's about tools and processes that work with XML (and assume therefore valid XML) and use your HTML as input. That's still a quite common thing. Even you don't do it today you can't know whether you or someone else is going to need it tomorrow.

Being XML compatible also opens up the possibility to use powerful tools like transformations and queries right on the raw HTML data in ad-hoc scenarios.

Sure, that's nothing you would do on an private blog usually, but in more enterprisey settings all kinds of processing happens on all kinds of data, quite often including web page contents. My experience after working in such environments is that not keeping HTML XML compatible will cause some serous trouble eventually.

I haven't encountered a tool that uses an XML parser against HTML in over a decade.

Maybe you just didn't any ETL things lately. :-)

> † These tags

Could you explain the use of that "cross" symbol, versus what I use normally, [0] [1] etc. ?

The dagger (the typographic name of that symbol) is usually employed as a footnote indicator if an asterisk is already present.

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.

For me, the power of a blogging platform is in automating boilerplate. This lacks:

- 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.

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.

Agree with you. So... managing it is more involved than dynamically generating everything, and it doesn't have rss?

I mean... I expect that putting more work into it would be a tradeoff for more features, not less

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.

I'm switching to PDF/A: https://lab6.com/0#page=2

As a visually impaired person please don't. I like being able to resize text and still have the document flow properly instead of endlessly scrolling back and forth.

It's a Tagged PDF so supports reflow or extraction into HTML or text formats.

I'm a big fan of pdf/a but it doesn't support reflow, not in any sense that users would want or mean. Reading your post on a phone is awful.

Excellent article, and a compelling proposition! Thanks for sharing this.

PDF is the last way I want to consume content, especially on a smaller device.

I want to read the content, so just give me the content, not a pretentious image of it. Just give me <p> and image tags. Basic data.

I don’t want your “document”.

No, Pdf isn't appropriate for electronic documents, it is especially user-unfriendly.

What exactly do you have against HTML? (It's not like we have any better alternative...)

IMHO the .mhtml format should be resurrected.

EDIT: And the Pdf format can be abused as well. At least it's easy to block JavaScript on HTML, even selectively (uMatrix).

I expect to be able to use video in an electronic document, PDF readers don't seem to be even able to support MP4, much less the upcoming AV1 !

I hate reading that on mobile device, as it doesn't support reflow.

I wrote a response to this a few months ago that others may be interested in:

https://news.ycombinator.com/item?id=24258193

Largely I am baffled, because the end result seems worse in almost every way than the starting point of HTML.

"User friendly". Yes, for you, the author. At the expense of everyone reading your blog. When considering this is a one to infinity relationship (i.e. write once read a million times), focusing on optimizing the "write once" at the expense of the million times it gets read, might just well... cause it to be read only 10 times instead.

I wouldn't even bother reading a PDF and I am on a desktop. I make some exception: Books & Papers, device manuals and legal documents & the like.

I would never read a blog in PDF, unless it's the last blog on earth.

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 :/

>Simplicity is key

This isn't simplicity...

I need a beer.

The CSS the author uses (style.css) has both 'white-space: pre-line;' (line 6) and 'max-width: 640px;' (line 18).

https://inoads.com/style.css

Then he could use div tag instead of code tag but then it wouldn't be 'next-gen' I assume.

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.

Agree with the beer.

I prefer this -

https://every.sdf.org

Your site is too hard to read on. Make the color of the font darker or the background lighter please.

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.

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 agree with ffpip's comment. I too found the contrast to be too low for my comfort. Here are the colors used for the body element in the CSS (see https://inoads.com/style.css):

  background-color: #FDF6E3;
  color: #657B83;

Now plug those values into https://webaim.org/resources/contrastchecker/ and we can see that this color scheme fails even the WCAG AA check (see https://i.imgur.com/iK7FRfU.png for a screenshot). I think the WCAG AA is the absolutely bare minimum accessibility guideline any color scheme should conform to, otherwise we risk making the text hard to read for many people just like the text in this website is hard for me to read.

Ah, it seems this site is aware of my preference for a dark color scheme.

    @media (prefers-color-scheme: dark) {
      /* defaults to dark theme */
      body {
        background-color: #002B36;
        color: #AAA;
      }
    }

You are seeing the bright color scheme and I am seeing the dark. So when ffpip said either "darken the text or brighten the background," and I'm looking at the dark theme, that would mean reduce the contrast.

I think we're all of the same opinion: the contrast should/could be higher.

Ah! That makes sense. Indeed you had mentioned in your comment:

> Its use of gray text on a dark blue background is pretty common

That should have been a clue for me that you were seeing the dark color scheme.

There is an interesting thing happening here. It appears the colors on the site are largely either similar to solarized-light or solarized-dark, depending on whether the user's browser has a dark-preference or not.

The OP comment evidently looks at the light version (which is grey text on tan background, and which I also find a bit annoying to read). I would guess that the parent comment is seeing the dark-mode version.

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!)

You linked the same image twice. I'm curious what the other image was.

edit: nevermind, switched to dark mode using the dev tools. It looks like this just to be complete: https://i.imgur.com/qPv7guO.png

My bad. I must have messed up just before updating with the edit, because I definitely check the links I post

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.

My browser doesn't allow the switch to read mode, for example.

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

yeah, for me, breaking reader mode is a big downside.

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.

It would be nice to read a static blog that talks about more than creating a static blog.

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.

https://neat.joeldare.com

> I'm ALWAYS looking for a more simple blogging solution.

Why?

> Once you choose the technology that runs your blog, use it. Don’t replace it, ever. Never ever rewrite it.[1]

[1] https://macwright.com/2019/02/06/how-to-blog.html

This is good advice, for anything that can be tinkered with. Just as applicable to setting up a window manager on Linux, for example. It's an amazing rabbit hole, but it can consume you.

The antithesis of this is exactly why I asked the question. I was reminded of a tweet/post describing that most blogs have a single post: the one that describes how the author built their own static site generator/blog framework. After that, they are too tired/unmotivated to write anything else.

I was on WordPress. Now I’m on Jekyll. I occasionally think of changing the theme, then I remember how little that will benefit me or my few readers.

THIS!

I'm on Hugo now, and have used both self-hosted and .com (free) versions of Wordpress. Which of the 3 do you think I wrote the most when I was in it?

Yeah, free wordpress is limited, if not open-source, blah-blah-blah. But it's a few clicks to create, easy to write the posts/have drafts/change theme. And I would argue that having limited themes on free can actually be a positive thing. You have a few options, chose something and start writing.

Having to write in any other editor (to have grammar checking), then paste on VS Code, deploy... it just takes more time. And this is without managing any media, which I just upload to imgur and use the link...

I built my first blog on Dokuwiki somewhere around 15 years ago. Since then Markdown has become the standard for text. Dokuwiki also updates a lot and is difficult to move from one server to another.

I'm always on the hunt because I haven't found the perfect solution to replace it yet. I'm convinced it's either plain text (including Markdown) or plain html, but I am not sure I've found the perfect solution.

Today I'm using Markdown hosted on GitHub, but who knows how long I'll use GitHub or if GitLab or BitBucket will work as replacements in the same way.

It's easy to say, "stick with it", but technology changes a lot as the decades begin to pass by.

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.

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.

But abusing <code>, <h4> and <h5> like that is a horrendous and pointless. Please use the proper tags to keep the web clean.

So instead of a body tag you have a code tag?! Is that next gen?

Is this better than my 2001 solution of wrapping everything in a <pre> tag?

http://lumma.org/microwave/

Also a neat idea!

That's like a text file blog, but with the ability to have real hyperlinks.

Main benefit I see is text wrapping on small viewports

Maybe an expert can confirm, but my understanding is that this would be poor from an SEO standpoint.

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.

You could also override the font-family of the main <code> to make it more readable; since it isn't code there's no need to use a monospace font.

    body code {
        font-family: sans-serif;
    }

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.

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.

> 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.

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...

1. Read first sentence,

    Take a look at the source code of this page - I rely mostly on CSS for the rendering of this article.

2. Right click, "View Page Source" on Firefox (`84.0.2 (64-)bit)`)

    Edit: adding that I do have `NoScript 11.1.8` and `uBlock origin 1.32.4` installed.

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.

If you're into the monospace look, .txt is cool too.

epic

For the web plain text is pretty terrible. Web browsers are terrible plain text readers, mobile browsers doubly so.

Browsers render content in a "viewport". On the desktop the viewport width is the width of the window but on mobile defaults to 960 CSS pixels (pixels adjusted for screen DPI). When a page is rendered it's as if the browser window is 960px wide. This can be controlled with the viewport meta tag where you explicitly tell the browser the viewport is the window width, on desktop browsers that doesn't change anything but mobile browsers use their screen width rather than the default.

When it comes to plain text there's no way to tell the browser to do that. So if the plain text doesn't have a hard column wrap it's rendered as if it's in a 960px wide window. If it is hard column wrapped it's probably to some common terminal width like 40 or 80 characters. At 80 characters the default font size ends up causing really awful wrapping in the viewport. Pinch to zoom doesn't change the font size but the viewport magnification do that doesn't help readability.

You also lose hyperlinks and in-line images. The web could do with fewer stupid images bulking up pages but without hyperlinks you don't really have a web. Putting all links at the bottom of a document HN style isn't a great solution. Visitors still need to copy and paste links which is a pain in the ass at best and inaccessible at worst.

If you want a monospace "look" just put 'body {font-family:monospace;}' in a style tag and you're all done. You get all the benefits of a real HTML document and the terminal chic of a monospace font. Don't waste everyone's time with plain text on the web.

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.

That <date> tag you are using does not exist in the specs. You may want to change that to <time>.

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 https://inoads.com/blog

I had to copy all the text out into a text editor to be able to read the article, not just the links. Contrast is out of vogue I guess.

I don’t understand the current fashion of making everything off-gray on off-gray. I guess it keeps designers employed.

Hypothesis: Whenever you’re building it, you spend hours looking at it, and want to reduce harshness of contrast. The reader is only going to spend 5 minutes and prefers contrast as it allows quick scanning of the text.

Thanks for the feedback. The colour scheme uses https://ethanschoonover.com/solarized/ as a foundation. This is how I have all my editors / IDEs set. I'll look at implementing this next: https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...

Wow, never heard of that CSS property — cool!

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.

IIRC there is some sort of tool for generating inter-blog links. Maybe by our stavros? My memory is fuzzy here.

You can always publish on both Medium and your own blog. https://indieweb.org/POSSE

Cool. Go one step further and render the CSS inline.

Of late, I have been writing with just MarkDown and dropping in some of the simplest tool (Pandoc, Jekyll) possible to render as HTML.

Here's some crazyness: https://dataswamp.org/~solene/2019-08-26-minimal-markdown.ht...

I suppose it is not much hard to translate this into PHP...

I built mawkdown[0] off of solene's initial awk implementation!

[0]: https://github.com/icyphox/mawkdown

I do not have much experience in awk, but after reading Solene's and your code, I am curious about why < > are escaped with \ ?

In your m.awk, I also noticed that the markdown formattings (bold, inline and links) are not turned off in code blocks.

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 https://color.a11y.com/Contrast/

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

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.

In the next generation, I implore people to focus on content, not the tech.

Yep, this is not my first run at blogging. Looking forward to writing more content.

I’ll be watching to see if you do.

Running this site through an HTML validator generates quite a few errors.

https://validator.w3.org/nu/?doc=https%3A%2F%2Finoads.com%2F...

    <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>

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?

You can have it auto-generated using directory indexes in Apache. You can even customize them (within limits).

I've toyed with having a minimal blog, where I simply drop text files with file names beginning with their date in a folder and rely on directory indexes as a "home page".

I too was toying with a similar idea, but was finding the devil was in the details.

For instance, you want to sort by publish date, which isn't the same as file creation date. If you add it to the file name, to sort by that, then you can no longer use file names for urls, at least without some transformation.

So I was really curious how others were dealing with that in a clean way.

I found that using w3.org's CSS validator shows reference to the page's URI as '[...].php'. http://jigsaw.w3.org/css-validator/validator?uri=https%3A%2F...

With that and the author's mention of using PHP for a custom blogging setup, I'm guessing it's being dynamically generated by PHP still.

A neat little css property aside, isn't the separation of concerns a cornerstone of web pages?

Html - structure of the document CSS - appearance JS - interactivity

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?

Separation of concerns is still seen as the way to go. People just have different opinions about what a concern is.

It started with markup, styling, and interactivity. But many people think, this is a too technical perspective and software should be split up into non-technical concerns (i.e. microservices).

This structure vs appearance dichotomy was added after the fact, though, since CSS came significantly later than HTML. It has been used as a (misguided IMO) narrative to defend CSS's complexity and redundancy and is partially to blame for HTML and the web ceasing to be a straightforward medium for simple publishing, seized by big media and ad networks.

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.

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.

https://developer.mozilla.org/en-US/docs/Web/CSS/white-space...

If I'm understanding correctly, here, the semantic value of the <code /> element is ignored to increase DX.

I personally wouldn't make that compromise, why is pre-processing not simple enough?

You could use <article /> instead (which I probably would). Jest tested it using dev tools, seems to work.

Using some HTML elements like section makes Safari switch to "reader" mode. Which is broken.

The outer <code> here is simply a very poor choice due to what I can only imagine is ignorance. It would be better removed, and the `code` rule in the stylesheet changed to `body` and `font-family: monospace` added. (And `code code` would need to be changed to `code`.)

Yeah if browsers would just render markdown nicely that'd be great.

I've built the simplest static site generator. https://github.com/eguneys/jener

So I'm guessing this isn't accessible for screen readers?

I think you have the year off by one (2020) on your datestamp.

Thank you, completely missed this.

So how would you do a code snippet with syntax highlighting?

What I think is missing for static blogs are comments.

I can't and won't speak for anybody else, but if I wanted to provide random strangers with a free soapbox I wouldn't bother with a static blog. I'd just fire up a new Fediverse instance.

IMO, there's no need for comments. If people can't either send you an email or quote your blog with a link in their own blog, then they probably don't have much of value to say.

I think putting your email in your blog is going to get you a bit of spam...

At least with comments, they are limited to the comments system

I don't care if contact@ gets spam. That's what it's for. If I reply, it'll come from a different address on that domain.

@demifiend, then don't reply to their comment with a comment of your own. Why don't you quote it in your blog or email them instead?

I've been using this technique on midnight.pub as well, and it's working surprisingly well.

Even simpler: serve txt files. Browsers display them just fine.

How does this play with Assistive Technology?

It is a neat idea, but the purist in me misses those <p> tags, even though they are the main reason why I don't like writing HTML by hand.

What about the standard <html><head>...</head><body>...</body></html> tags?

What about them? They occur exactly once, and I probably have a prepared file with them already in it.

But for every paragraph I write I need to type <p> (and maybe even </p>, if I choose to).

That's exactly the use case for Markdown, to get rid of that tedious stuff.

A lot of modern text editors will let you type 'p' and then tab and they will create the opening and closing tag for you.

Sure, I can type "<p", but that's still annoying.

Look, I don't hate hand-written HTML. I actually like it better than Markdown.

What about Enter, Enter to get <p>|</p>

I'm not interested in you selling me an editor or IDE.

And I have zero idea why you all insist that I must love writing HTML.

Leave me alone!

All of those tags are optional. It’s perfectly valid to omit them.

Not according to w3.org's validator. https://validator.w3.org/nu/?doc=https%3A%2F%2Finoads.com%2F...

Edit: Actually, seems you're right. Though doctype is not there, and there are other problems with the markup.

Izmaki and I were talking about the <html>, <head>, and <body> tags, not the article.

The smallest valid HTML document is:

    <!DOCTYPE html><title>…</title>

If you put that into the validator, you will see that it is valid.

Correct, documented at https://html.spec.whatwg.org/multipage/syntax.html#optional-...

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.

https://wave.webaim.org/report#/https://inoads.com/articles/...

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.

I bet that blind people can't wait for next 'next-gen' static blogging:

html::after { content: "Welcome to my blog" }

Whenever people do stuff like this, alternative text protocols like Gemini make more sense.

I thought the crowd on HN was more technically versed than this post. This self-titled "next-gen" blogging solution disregards SEO and accessibility. Am I wrong?

I'm tempted to argue the value of SEO when to me it has come to mean catering to Google and trying to game its algorithms, but no. You're not wrong.

Made me realize my own site needs work. Thank you for sharing this

I hope it helps. A woman I worked with a decade ago impressed upon me the importance of accessibility and sometimes I try to pay it forward.

Reply on news.ycombinator.com