@matrix it's inconsistent. If the button is "b" for bold, the tag should be <b>. If the tag is <strong>, the button should say so. HTML elements is about semantics, not rendering (<strong> text may be rendered not in bold)
@andybalaam that would be misguiding / poor UX I guess.
strong, em, b, i are different concepts. semantics differs and rendering may not be guaranteed for some. You can refer to the HTML spec or MDN:
It might be more obvious when you will introduce h1, h2, h3... buttons. These do define semantics of titles, subtitles, etc and you can't know how it will render on different clients / themes / devices (font size, font weight). It's the same for <strong> or <em>.
Or, Imagine my client / theme is configured to render <strong> as normal font weight (not bold) but font color is red. That's 100% legit regarding semantics (red means important, visible).
So if I look in the editor interface for a button to make an important text <strong>, the button should not be rendered as a "b" in bold text. I will look for a button with a "strong" label written in red.
@lutindiscret hmm, but, given that we're not going to offer a "strong" button for the very small number of people who want the distinction, then you're suggesting that you'd prefer to have a "b" button that renders in bold, even though you (I suspect) might actually have wanted to express the semantics of strong.
At least, that's consistent. "b" stands for "bold", not "important"
Otherwise, you will get people reporting issues. "I clicked the b button and it does not render as bold" (due to theme or css or whatever)
From a HTML spec, I'm sure of what I say: what you want is a "b" button that does <b>
But from UX point of view, you might be right. Maybe a good UX designer could confirm you that "b" is now a convention for <strong> (like floppy to save). I think not but might be wrong
@lutindiscret Yeah, I'm going to ask our UX person about this.
Thanks for bringing it to our attention - tbh I thought <b> was just deprecated. We could, of course add <span style="blah"> but it feels clunky when we'd really like to produce somewhat-readable HTML if we can.
@lutindiscret we're fairly likely to stay away from headings, at least for early versions, but we will offer lists, links etc. which have semantic meaning.
@lutindiscret I'm not sure I agree. I think often when people hit the bold button, they mean that something is of strong importance. We are *certainly* not going to offer two buttons to express the two subtly different semantics. So we have to choose one, and strong might be the right choice.
@matrix I hope this is optional when it hits Element, I still haven't forgiven Slack for what they did to their text input
From my personal perspective, I tend to hate rich text widgets in things like messengers, so as a dev on this project, I am
a) committed to offering a pure plain text UI too, and
b) trying to not make it as annoying as some other clients. Especially by making sure it's not sluggish, which does my head in!
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!