List of links, articles, and other resources you might find interesting from the past few weeks.
John Gruber and Aaron Swartz intended Markdown to be used for prose and for it to be readable with no further processing. When Markdown’s syntax is insufficient for what you need to do, you can use regular inline and block-level HTML elements.
There are Markdown flavors which see Markdown as too simplistic, and they extend its syntax. But in my opinion, that is a mistake. Let’s keep Markdown simple and use HTML for the more complex stuff.
This is also addressed in the official Markdown documentation:
Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web.
Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.
So, don’t complicate Markdown. Just use Markdown and HTML together. Or maybe consider if Markdown is even what you want. You might be better off with regular HTML.
What about HTML? Isn’t writing it easy enough? Do we even need Markdown?
Article Is HTML a humane markup language? (2008) by Jeff Atwood tries to dig deeper into these questions. I like how it raises the question that maybe HTML itself is already simple enough when programmers are the intended users. The most interesting tidbit:
But in general, I’d much rather rely on a subset of trusty old HTML than expend brain cells trying to remember the fake-HTML way to make something bold, or create a hyperlink. HTML isn’t perfect, but it’s an eminently reasonable humane markup language.
In the end, I’m still a fan of how Markdown does it. It simplifies the syntax for writing prose, but it doesn’t try to replace HTML and offers a simple way to use HTML for the more advanced stuff.
Trying to make your website more accessible? Microsoft has a free browser extension Accessibility Insights to help you with that.
By default, HTML documents don’t look good because the default browser styles have some poor defaults. If you’d rather not bother with styling HTML documents yourself, you might want to try W3C Core Styles.
They offer several themes which you can just use by linking them from the head of your documents. Some of them look pretty outdated, but some of them still look good.
I’ve been looking for a way to create an accessible inline list with bullets between items, such as this:
item 1 • item 2 • item 3. There are numerous solutions how to do this, but most of them don’t have good accessibility. The best solution I’ve found: Accessible inline list with bullets between items. It has some gotchas, all is described in the article.
In the interview Linus Torvalds on Linux, Git, and the future of open-source, Linus Torvalds touched upon something he describes as “good taste”:
But there is that occasional “inspiration” part, that “good taste” thing that is about more than just solving some problem — solving it cleanly and nicely and yes, even beautifully.
I never thought this way about why some people solve programming problems more elegantly than others. In this interview, Linus Torvalds gives an interesting take on it.
But it’s like there’s a gap, that for the first couple years that you’re making stuff, what you’re making isn’t so good. … But your taste … is still killer, and your taste is good enough that you can tell that what you’re making is kind of a disappointment to you. … And the most important possible thing you can do is do a lot of work — do a huge volume of work.
Weird things happening at Twitter, so you might be seeking some alternative. It’s critical to remember that you should try to avoid services that hate the Internet.
If you ever make something just for fun and someone starts criticizing what you did, just remember the site Just for fun. No, really.
Because every so often you do something really just for fun. There’s no purpose, it’s not supposed to be better than something else, it might be even completely useless. It’s made just for fun.
Find your favorite programming font by playing the coding font tournament.
Joel Spolsky has a pretty hard stance on rewriting large codebase from scratch: Don’t do it. It’s a waste of time and money, and you might even end up with something that’s worse than what you had before. It’s better to improve upon what you already have.
It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.