I love the honesty and directness of many element names in html. Sometimes html and css go a bit abstract in the hopes of being widely applicable and not too directly descriptive. In practice some things are usually, if not always, represented in a certain way.

Flexbox is an example of quite an abstract layout concept. I understand the benefits, but I still use display: table; a lot, because it feels more honest. A noble but useless ideal. There's less cognitove overhead in thinking about direct, concrete names, like table or radio button. Dare I say, skeumorphic names. You need to translate the names in your head, from code to visuals. As opposed to abstract terms like area or meter. Though not all design is visual. Also the kids nowadays probably don't even know what a real radio button is, so even concrete names will lose their meaning in time. I'm digging a hole for myself here.

I was heavily on the semantics bandwagon when it was being evangelised. I still am, but what semantics means for web code has changed back and forth quite a bit in recent years. First there was b for bold and i for italics. Then we tried to deprecate them in favor of strong and em. Nowadays it doesn't matter, so I just use b and i. They do mean exactly what they represent. They should be named just that, because the writer usually defines what bold and italics means in the context of the text. The meaning of bold and italics does not come the system or coder. The same logic goes for many other elements.

It's a strange balancing act, trying to name elements. The name shouldn't lock lock you into a single presentation, but also it should tell you what the element is. Sometimes the element should look a certain way and the look takes a meaning, depending on context. Sometimes the meaning defines the look. Sometimes it's easy, sometimes hard.