I love this comment because you follow another common linking style that is distinct from the ones presented, the “punctuation style” where links are treated like footnotes or words or phrases.
I agree it’s poor style to do links with words like “here” or “this article” and similar, but that also doesn’t imply we have to put the names of things we are linking. I understand the argument for it, but it’s often a style choice to use links as punctuation rather than like more traditional references.
where links are treated like footnotes or words or phrases
Unfortunately they are not rendered as footnotes when printed.
There is also a curse of knowledge issue. The author knows what is behind their link, how important it is, whether it is a reference or a definition or a “further reading”. The reader has no idea. So the least I’m likely to do for any non-speaking link is hover over it to see what URL it points to. This wouldn’t be necessary if the link were named with something close to the title of its target.
it’s often a style choice
And it’s best to choose a style that supports the function, right? I don’t mind “punctuation style” in most ordinary blog posts. But it doesn’t work for (semi-)scientific material that is likely to be printed. Especially by beginners like me. Maybe more advanced people can just tear through an article on, say, Benign model-free RL, but I need the aid of pages spread on my desk.
Unfortunately they are not rendered as footnotes when printed
This seems like a fault in the printing process.
If the author is optimizing for one reading format, and you want to convert it to another, and it’s unsatisfactory in the new format, then perhaps the conversion process is what should be improved.
Good point. I experimented for ten minutes with saving the HTML, changing it and loading it again in the browser. But it doesn’t work for LessWrong. The article appears briefly and then it switches to: ‘Sorry, we couldn’t find what you were looking for.’ I didn’t feel like figuring this out.
I love this comment because you follow another common linking style that is distinct from the ones presented, the “punctuation style” where links are treated like footnotes or words or phrases.
I agree it’s poor style to do links with words like “here” or “this article” and similar, but that also doesn’t imply we have to put the names of things we are linking. I understand the argument for it, but it’s often a style choice to use links as punctuation rather than like more traditional references.
Unfortunately they are not rendered as footnotes when printed.
There is also a curse of knowledge issue. The author knows what is behind their link, how important it is, whether it is a reference or a definition or a “further reading”. The reader has no idea. So the least I’m likely to do for any non-speaking link is hover over it to see what URL it points to. This wouldn’t be necessary if the link were named with something close to the title of its target.
And it’s best to choose a style that supports the function, right? I don’t mind “punctuation style” in most ordinary blog posts. But it doesn’t work for (semi-)scientific material that is likely to be printed. Especially by beginners like me. Maybe more advanced people can just tear through an article on, say, Benign model-free RL, but I need the aid of pages spread on my desk.
This seems like a fault in the printing process.
If the author is optimizing for one reading format, and you want to convert it to another, and it’s unsatisfactory in the new format, then perhaps the conversion process is what should be improved.
Good point. I experimented for ten minutes with saving the HTML, changing it and loading it again in the browser. But it doesn’t work for LessWrong. The article appears briefly and then it switches to: ‘Sorry, we couldn’t find what you were looking for.’ I didn’t feel like figuring this out.
Try getting the article from greater wrong instead.
Good idea! I will try that.
This is a bug in Vulcan, the framework we’re built on; https://github.com/LessWrong2/Lesswrong2/issues/638 . We’ll come up with a workaround at some point.
Thanks for the info! By the way, Markdown included the period after ‘638’ in the
hrefattribute. Also a bug?