151–160 of 179 posts
So, instead of using semantic html and css like 'white-space: pre-line' and 'max-width: 40ch' author wrapped content of his blog post into 'code' tag and called it 'next-gen'. What is 'next-gen' about it? Either I am missing something or I'm not drunk enough. Worst thing it has 100 upvotes :/ >Simplicity is key This isn't simplicity... I need a beer.
I prefer this -
Note that closing tags are optional † , so one can be an HTML purist and still write a decent HTML document with a relatively clean markup like this: Lorem Ipsum Lorem Ipsum 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. Maecenas at neque posuere, aliquet era…
Frontend developer here -- Although you could omit the closing tags, I don't see the benefit of doing so. If you know HTML, nesting is fundamental and not explicitly closing dom nodes would lead to confusion. You would also need to concern yourself with the "certain conditions" that must be met for it to work. Consistency and clarity over brevity!
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.
What I think is missing for static blogs are comments.
I can't and won't speak for anybody else, but if I wanted to provide random strangers with a free soapbox I wouldn't bother with a static blog. I'd just fire up a new Fediverse instance. IMO, there's no need for comments. If people can't either send you an email or quote your blog with a link in their own blog, then they probably don't have much of value to say.
At least with comments, they are limited to the comments system
I'm glad I'm not so blind that I need a screenreader for this site, because @mmackh doesn't seem to have given any consideration to accessibility. https://wave.webaim.org/report#/https://inoads.com/articles/... If this is "next gen", I think I'll stick to using emmet-mode in Emacs to write raw HTML, templating with m4 macros, validating with tidy, and doing the build and deployment with a makefile.
I thought the crowd on HN was more technically versed than this post. This self-titled "next-gen" blogging solution disregards SEO and accessibility. Am I wrong?
I'm glad I'm not so blind that I need a screenreader for this site, because @mmackh doesn't seem to have given any consideration to accessibility. https://wave.webaim.org/report#/https://inoads.com/articles/... If this is "next gen", I think I'll stick to using emmet-mode in Emacs to write raw HTML, templating with m4 macros, validating with tidy, and doing the build and deployment with a makefile.
Made me realize my own site needs work. Thank you for sharing this
Earlier quoted context omitted.
I can't and won't speak for anybody else, but if I wanted to provide random strangers with a free soapbox I wouldn't bother with a static blog. I'd just fire up a new Fediverse instance. IMO, there's no need for comments. If people can't either send you an email or quote your blog with a link in their own blog, then they probably don't have much of value to say.
I think putting your email in your blog is going to get you a bit of spam... At least with comments, they are limited to the comments system
Earlier quoted context omitted.
Please never ever break XML compatibility! Not having valid XML in the first place complicates any further processing quite a lot. Also you're going to run into annoying and / or strange issues with tooling. Those HTML shortcuts are just not worth it. Their value is "questionable" (to put it kindly) but down the road their cost can become surprisingly high.
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 means here, as it specifically is not xml. I’m not tying to be mean, but you came in with guns blazing with weir…
Note that closing tags are optional † , so one can be an HTML purist and still write a decent HTML document with a relatively clean markup like this: Lorem Ipsum Lorem Ipsum 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. Maecenas at neque posuere, aliquet era…
And since we’re talking about optional things: 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…
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.
Earlier quoted context omitted.
Please never ever break XML compatibility! Not having valid XML in the first place complicates any further processing quite a lot. Also you're going to run into annoying and / or strange issues with tooling. Those HTML shortcuts are just not worth it. Their value is "questionable" (to put it kindly) but down the road their cost can become surprisingly high.
Only one branch of the HTML family tree was ever XML compatible. I was a heavy user of XHTML in the day, so I'm sympathetic... But it's misleading to characterize non-XML variants of HTML as questionable shortcuts.
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…
IMHO blogs are documents, and HTML is no longer designed for documents but web applications. Blogs need to go back to document publishing formats. It doesn't get more user-friendly than 1. WYSIWYG word processor; 2. Save As PDF; 3. Dump the file on a web host. I'm switching to PDF/A: https://lab6.com/0#page=2