<!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.
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.
<link rel="stylesheet" href="/style.css" />
<meta name="viewport" content="initial-scale = 1.0,maximum-scale = 1.0" />
(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">
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.
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 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 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.
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.
[1]: https://www.youtube.com/watch?v=jy-b4jeJSas&list=PLQpqh98e9R...
[2]: http://sgmljs.net/blog/blog1701.html (the "Talk" link for slides)
> <html lang="en">
Yeah, no. The text is in Latin (la), not in English (en).
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.
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.
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/>?
Could you explain the use of that "cross" symbol, versus what I use normally, [0] [1] etc. ?
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 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.
I mean... I expect that putting more work into it would be a tradeoff for more features, not less
- 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.
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
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 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”.
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.
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.
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.
edit: nevermind, switched to dark mode using the dev tools. It looks like this just to be complete: https://i.imgur.com/qPv7guO.png
(ideally, the website should get the fix rather than you doing it... but this works better than notepad!)
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.
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.
background-color: #FDF6E3;
color: #657B83;
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.
html::after { content: "Welcome to my blog" }
>Simplicity is key
This isn't simplicity...
I need a beer.
I prefer this -
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.
Why?
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.
body code {
font-family: sans-serif;
}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.
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".
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 personally wouldn't make that compromise, why is pre-processing not simple enough?
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.
At least with comments, they are limited to the comments system
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.
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.
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.
Of late, I have been writing with just MarkDown and dropping in some of the simplest tool (Pandoc, Jekyll) possible to render as HTML.
I suppose it is not much hard to translate this into PHP...
In the next generation, I implore people to focus on content, not the tech.
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?
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).
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
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.
EDIT: some wording changes.
But abusing <code>, <h4> and <h5> like that is a horrendous and pointless. Please use the proper tags to keep the web clean.
I don't really see how this can be next-gen when it strips out any semantic elements.
This isn't the same "dynamic" - the author must know that JS can provide interaction without a page refresh; PHP (alone) cannot.
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.
Edit: adding that I do have `NoScript 11.1.8` and `uBlock origin 1.32.4` installed.
4. It takes ~10 seconds to re-render the page (with spinner gif running, in the meanwhile).
5. Tab completely frozen.
There's no point pontificating about the next generation of static blogging when you forget the basics - make the writing easy to read.
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.
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 <p> paragraph elements.
This is a separate paragraph.
</body>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.