Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next Gen Static Blogging

inoads.com

Post reply on HN
Print view View original

161–170 of 179 posts

Re: Next Gen Static Blogging

#161

Post by chrismorgan »

mmackh wrote: post #111

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.

Re: Next Gen Static Blogging

#162

Post by cxr »

datapolitical wrote: post #98
zwog wrote: post #92

Earlier quoted context omitted.

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

Those are Latin words, drawn from a Latin source. “Pencil what comma building twenty section human fedora” is English, even if it makes no sense.

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

Re: Next Gen Static Blogging

#163

Post by chrismorgan »

jl6 wrote: post #126
onion2k wrote: post #117

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

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

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

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

Re: Next Gen Static Blogging

#164

Post by simonw »

still_grokking wrote: post #143
anjbe wrote: post #134

Earlier quoted context omitted.

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 , or self‐close a ?

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…

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

Re: Next Gen Static Blogging

#165

Post by still_grokking »

simonw wrote: post #164
still_grokking wrote: post #143

Earlier quoted context omitted.

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…

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

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

Re: Next Gen Static Blogging

#166

Post by ffpip »

city41 wrote: post #112
ffpip wrote: post #47

Your site is too hard to read on. Make the color of the font darker or the background lighter please. I had to copy to a notepad so I could read it. Edit: Apparently, dark mode users get this - https://i.imgur.com/5PHYac1.png I get this - https://i.imgur.com/5PHYac1.png Light mode is terrible, dark mode is okay. Please increase the contrast in both places.

You linked the same image twice. I'm curious what the other image was. edit: nevermind, switched to dark mode using the dev tools. It looks like this just to be complete: https://i.imgur.com/qPv7guO.png

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

Re: Next Gen Static Blogging

#167

Post by martamorena2 »

jl6 wrote: post #126
onion2k wrote: post #117

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

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

Re: Next Gen Static Blogging

#168

Post by JimDabell »

iamtedd wrote: post #25
JimDabell wrote: post #14

Earlier quoted context omitted.

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

Not according to w3.org's validator. https://validator.w3.org/nu/?doc=https%3A%2F%2Finoads.com%2F... Edit: Actually, seems you're right. Though doctype is not there, and there are other problems with the markup.

Izmaki and I were talking about the , , and tags, not the article.

The smallest valid HTML document is:

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

Re: Next Gen Static Blogging

#169

Post by [deleted] »

still_grokking wrote: post #128
susam wrote: post #67

Earlier quoted context omitted.

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

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

[deleted]

Re: Next Gen Static Blogging

#170

Post by susam »

still_grokking wrote: post #128
susam wrote: post #67

Earlier quoted context omitted.

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

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

> But YOU have still an issue.

I disagree.

> There a lot of broken tools out there

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

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

Post reply on HN