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.
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`.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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).
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.
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.
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.
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.
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.
> 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.
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.
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!)
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.
178 comments
[ 2.8 ms ] story [ 227 ms ] threadBut 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.
Look, I don't hate hand-written HTML. I actually like it better than Markdown.
And I have zero idea why you all insist that I must love writing HTML.
Leave me alone!
Edit: Actually, seems you're right. Though doctype is not there, and there are other problems with the markup.
The smallest valid HTML document is:
If you put that into the validator, you will see that it is valid.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.
I personally wouldn't make that compromise, why is pre-processing not simple enough?
http://lumma.org/microwave/
That's like a text file blog, but with the ability to have real hyperlinks.
EDIT: some wording changes.
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).
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...
[0]: https://github.com/icyphox/mawkdown
In your m.awk, I also noticed that the markdown formattings (bold, inline and links) are not turned off in code blocks.
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
Why?
[1] https://macwright.com/2019/02/06/how-to-blog.html
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...
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.
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.
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.
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.
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!
[1] https://web.archive.org/web/20201206065632/http://inimino.or...
[2] https://blog.izs.me/2010/12/an-open-letter-to-javascript-lea...
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.
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
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. ;-)
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.
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".
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 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.
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 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.
> <html lang="en">
Yeah, no. The text is in Latin (la), not in English (en).
[Edit: I notice now that the content is indeed written in Latin. It contains the "Lorem Ipsum" placeholder text. Nice catch! :-)]
> 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.
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.
“Pencil what comma building twenty section human fedora”
is English, even if it makes no sense.
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".
[1]: https://www.youtube.com/watch?v=jy-b4jeJSas&list=PLQpqh98e9R...
[2]: http://sgmljs.net/blog/blog1701.html (the "Talk" link for slides)
(Note that I say HTML tags; on foreign elements—meaning inline SVG and MathML—trailing slashes do make tags self-closing, XML-style.)
Also since I’m writing, that viewport declaration is wonky. It should have device-width, and it should not have maximum-scale which is user-unfriendly.
All up:
And for completeness, https://html.spec.whatwg.org/multipage/syntax.html#elements-... defines void and foreign elements.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.
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.
The logical coherence of this response is in "not even wrong" territory.
https://en.wikipedia.org/wiki/Not_even_wrong
It makes the life of parsers a lot harder.
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/>?
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.
Could you explain the use of that "cross" symbol, versus what I use normally, [0] [1] etc. ?
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.
This isn't the same "dynamic" - the author must know that JS can provide interaction without a page refresh; PHP (alone) cannot.
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.
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 think we're all of the same opinion: the contrast should/could be higher.
> 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.
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.
(ideally, the website should get the fix rather than you doing it... but this works better than notepad!)
edit: nevermind, switched to dark mode using the dev tools. It looks like this just to be complete: https://i.imgur.com/qPv7guO.png
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.