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.
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.
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!
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".
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.
> 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.
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.
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.
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.
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.
"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.
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).
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.
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.
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
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".
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.
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.
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.
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.
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.
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.
"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 :/
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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
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.
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.
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.
<body style="white-space: pre-line">
The idea is that an extra newline within a block with style="white-space:
pre-line" acts like <p> 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.
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.
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`.)
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.
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 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?
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.