When questions like this come up, this is one of the two sets of "rules" that I often point to.
The other is Tania Rascia's (which shows each rule being applied to the same example, instead of each rule being demonstrated in a vacuum). I think the two different ways of illustrating the impact of each "rule" can be helpful for a pretty wide range of folks who often think in different modes.
As a (relatively, though age is catching up with my vision, admittedly) able-bodied Westerner who reads no other languages than English, I find this opinion shocking. Would paraphrasing your point as, "I don't think anyone who reads in any way other than the one I'm familiar with deserves knowledge," have a different impact, or does that seem ok to you, too?
No. The correct paraphrase would be "I think you should recognize that text is different from speech and English is different from Japanese and welcome the diversity of media of knowledge instead of trying to make an one-size-fits-all solution for every method to convey information that the human body is capable of."
Imagine if I had a markup language for voice synthesis. If I typed a word, the computer would say out loud that word. But I had tags like <whisper> and <yell> to change the volume of the computer voice, and <pausedly> and <quickly> to change its speed. These tags make no sense in the text medium, and yet their semantics are self-evident in speech.
If authors had a way to mark up how their text should be voiced, perhaps they would mark them so. Who wouldn't love a real <sarcasm> tag for sarcastically voiced text? But HTML went the opposite way. Instead of providing more tools to let authors express themselves, they took every format of expression and dumped it in a single label.
Changing the context to voice markup doesn't in any way change or address the core point, which is that you really seem to be expressing that you only care about the way that you happen to consume text and therefore any other viewpoints are superfluous. Also that you're willing to go out of your way to create and publish a plugin to effectively sabotage anyone trying to do anything else.
Of all the opinions someone could hold strongly, that's certainly one of them.
>you really seem to be expressing that you only care about the way that you happen to consume text
No, I only care about the way I write text. If I'm writing an article and I want to make text bold, I don't want to waste my time having to come up with a deeper explanation about WHY should the text be bold. That's an obstacle in the creative process. I want bold text. Period. I don't want <em> or <strong>, and I don't want a "bring attention to" element". I want bold.
Can you say that EVERY SINGLE TIME I want bold text that will match the semantics of <strong>? If that's true, then it shouldn't be called <strong>, it should be called <bold>. If that's not true, then one day I'll mark something as <strong> because I want bold text and it will be the incorrect tag for that text because of a semantic mismatch. In that case, what should I do? Should I just use <span style="text-weight: bold"> or <span class="bold"> for my bold text? Are you telling me that every time I want bold text I'll have to make the conscious choice of deciding whether I should use a <strong> tag or a <span> tag? Can you imagine the nightmare of making this work in a CMS like Wordpress? It would be much easier to just never use <strong> at all and just use <span> for bold every time.
If the only way to make sure you're using the semantics correctly is to just never use the tag at all, I say we just give up on this <strong> nonsense and use the <b> tag which matches the semantics of what the person writing the text wants to convey.
> I don't want <em> or <strong>, and I don't want a "bring attention to" element". I want bold.
When I read the above, I thought: you want bold, because you want to highlight a word. Because highlighting a word is a widely recognized way to bring attention to it. And so making it bold is just a tool, it's secondary to the actual goal.
I suspect you might not agree with that, but could you point me to the part where I got it wrong from your perspective?
The problem is that you're trying to come up with a reason for the text to be bold. The reason the text is bold is simply because the writer wanted bold text. Bold is the tool and the tool that the writer chose was bold, specifically.
Trying to come up with an universal reason for why bold is bold is like trying to come up with an universal formula to explain why any number 42 is 42. You wouldn't say every 42 came from 40 + 2 just because 40 + 2 equals 42, because some 42's come from 44 - 2 and others come from 6 times 7. Similarly, there is no universal reason for bold to be bold except for the fact that it is bold and that is it.
You say bold is used for highlighting. What would you say italic is used for then? And underline? All caps? Small caps? Title case? Colored text? A yellow background on the text? There are countless ways to highlight text.
Do you have the courage to style <strong> as ANYTHING but bold or <em> as anything but italic? (oblique doesn't count!)
No, you do not.
Because in your heart you know. The writer CHOSE bold. He CHOSE italic.
He had all these "highlight" tools in front of him, like a palette of colors, and he specifically and unambiguously picked bold. You can't ever change the meaning of bold to anything but bold, regardless of whether you use <b> as bold or <strong> as bold, because bold is an inseparable part of the content now.
If you changed <strong> to a non-bold red color text, it would change the typographic semantics of everything ever written with <strong>.
So in my view, it's not something abstract like highlight, it's literally bold, in its pure concrete form, because the author had a healthy vision, he spoke a Latin language, and he wanted his text to have bold letters.
I mean, just look at Wordpress and WYSIWYG editors. Nobody in sane mind would write "emphasis" and "important" text unstyled and put those buttons in the editor, because no author would EVER click on them. No author WANTS to mark emphasis or important text. Authors click the B button and the I button because they want bold and italic.
Can you imagine someone looking up Markdown's or restructured text's to find out how to mark "emphasis"? Nobody is writing text or *text* or _text_ or __text__ because they want emphasis. They're looking up which one of these characters generates BOLD text.
What the author means is BOLD. Means. As in meaning, semantics. It makes no sense to second guess what they really mean and change those semantics to emphasis/importance just because you think those are human-language/medium-agnostic and thus more portable. When you change <b> to <strong> what you're doing has a name: semantic bleaching, which happens when a word that had concrete meaning loses its meaning when it starts functioning in a more abstract (grammatical) way. Feels like the opposite of what anyone would want!
OK, now I can see that there could be e.g. a two-word brand name, where one of the words is simply bolder than the other, as a purely visual effect.
And then IMHO it would be incorrect to use <strong>.
As for the difference between <strong> and <em>, they way I understand it is:
> <strong>Hacker News</strong> is <em>the</em> site.
Basically one highlights a term (say, it could be then looked up somewhere), and the other adds spoken emphasis--in the above sentence, HN is not some site, it's THE site we talked about before.
The standard way of rendering (or priting) words with such semantic meaning is respectively bold and italics. But if you ask me it could also be underline and uppercase (respectively).
And if you render the page not to a visual medium but to sound (screen readers), then you give the screen reader a chance to treat (and read) those words differently.
>if you render the page not to a visual medium but to sound (screen readers), then you give the screen reader a chance to treat (and read) those words differently.
Good argument, ignoring what occurred in practice.
Every person with healthy vision writing a Latin language is using <strong> as bold, and most of them don't even realize it because it's hidden behind GUIs that show a B (bold) button which generates <strong> code. If you make this an issue in their tracker they will just tell you <strong> is more semantic and <b> won't be used.
Regardless of what the semantics of <strong> should have been, in practice you just made <b> with a longer name. In other words, there is no reason to use or have made <strong>, since the end result was just <b> again. Screen readers could have just done what they do with <strong> (i.e. nothing) with <b> and saved us all a lot of trouble.
I can say that almost every single time someone wants bold text now it will be a <strong> tag, even if the semantics are wrong.
> In other words, there is no reason to use or have made <strong>, since the end result was just <b> again
So waitasecond, <strong> was created, airheaded developers of WYSIWYG plugins messed it up, and that retroactively means there is no reason for it to have ever been created? That's a real pretzel you're twisting.
How about: "Programmers of WYSIWYG widgets should just stop messing things up, i.e. sabotaging the efforts of the blind and other people who use/develop screenreaders—so we can finally achieve the accessibility wins that <strong> was created to solve"?
> Screen readers could have just done what they do with <strong>
No, they can't. Not in the sense of, "There's a problem that exists. We want to solve it." Your proposal is to ignore the problem and do nothing. You can apply that approach to anything. (Heck, why even have screenreaders at all? People who are blind or dyslexic are shut out from the Web? Let's just do nothing.)
There's no one single thing, except internalizing a bunch of small ones.
My favorite guide is by Tania Rascia [1]. It walks through each of the "rules" and applies them to a simple example. My second favorite is by Anthony Hobday [2] and each "rule" gets its own, simple example to demonstrate.
Exactly. Apple's lack of contribution to the internet ecosystem exactly aligns with their profit motive: Selling hardware.
Google's involvement in the internet ecosystem exactly aligns with their profit motive: Putting relevant ads in front of individuals based upon data they've gleaned from relatively "un-sexy" sources like search, analytics, libraries, font hosting, email, chat, etc.
I'm not opposed to companies making a profit. I try, however, to keep in mind conflicts of interest when choosing my sources of information. Everything anyone at Google says about the web is suspect because that is a conflict of interest. Google, as an organization, exists to turn web traffic into profit and should always be considered accordingly.
Based in part off Gibson's work, there's also The Design of Everyday Things by Donald Norman. First published as Psychology of Everyday Things in '88, it's arguable whether it counts as "older" but seems pretty timeless conceptually, even if the specific examples may become dated.
Edit: Oh, yeah. How about Tufte ('83 for Visual Display of Quantitative Information) and Albers (Interaction of Color in '63). I should think first, then post.
An example might be helpful. Imagine you had buttons that come in small, medium, and large sizes. You want those buttons to have similar, proportional padding, letter-spacing, and border-radius. Margin around the buttons, however, should always be the same size to align with your columns or something.
You can put those properties which should vary in ems and then all you have to do is change the large and small font sizes from the default. Margin, however, remains in rems because it needs to be consistent. Everything will scale proportionately and your large and small button classes are clear, expressive, and concise.
The other is Tania Rascia's (which shows each rule being applied to the same example, instead of each rule being demonstrated in a vacuum). I think the two different ways of illustrating the impact of each "rule" can be helpful for a pretty wide range of folks who often think in different modes.
https://www.taniarascia.com/design-for-developers/