5 ms·

HTML5 undeprecated the and tags. https://www.w3.org/International/questions/qa-b-and-i-tags https://www.w3.org/International/questions/qa-b-and-i-tags

by nfoz 7y ago

HTML5 undeprecated the and tags. https://www.w3.org/International/questions/qa-b-and-i-tags https://www.w3.org/International/questions/qa-b-and-i-tags And I think the history here is pretty hilarious. - Classic html: and mean bold and italics. - Then the semantic folks took over, deprecated these tags, and say you have to use and instead. - Now with HTML 5 the and are brought back, but they don't mean bold and italics. They have new semantic meanings that sound like hilariously over-engineered attempts to pretend that they have some higher purpose that fundamentally really just means bold and italics. What I think the committees must have missed is that presentation and semantics are not separable; in many ways the presentation is the semantics. Bold text itself gives meaning to the boldness, inferred by readers and authors, based on how the boldness looks to them.

masswerk 7y ago
Ah, yes, I just noticed. Wasn't this marked as deprecated in HTML 5.2? Now the Living Standard explicitly notes that isn't necessarily rendered as bold (because it might be overridden by style sheets), by this loosening the connection to typographical appearance. As for the over-engineered part: I usually try not using spans or similar in markup to separate short terms or phrases, where there's a change in meaning or the level of information, rather using emphasis () for this. 99% of the time I end up styling this as italics. Because, this is really what typographical emphasis is all about. P.S.: And I always failed to recognize the crucial difference in meaning of "bold" and "strong". Both in speech and type these are quite the same concept to me, "bold" may be even be a bit more general and specific at the same time. (E.g., "bold" is not shout, but it's about a general concept of raised importance, which isn't clearly expressed by "strong".)
- masswerk 7y ago
 As a sidenote, as I now recall it, I was just too shocked by the phasing out of framesets in order to recognize the "undeprecation" of and . (I really fail to see where it helps, if future browsers fail to present historic documents in appropriate and meaningful context. Even more so, when 99% of these structures could be easily translated to semantic regions and landmarks, like header/banner, main, footer, aside, etc, even navigations could be inferred with ease by screen readers. Moreover, screen readers now have to support dynamic updates of isolated regions anyway in order to cope with JS frameworks. There was probably never a time, when frames would have posed that small a problem than at this point in time.)
- saltminer 7y ago
 >Now the Living Standard explicitly notes that isn't necessarily rendered as bold (because it might be overridden by style sheets), by this loosening the connection to typographical appearance. This is some pretty selective reasoning by the working group considering they don't provide a warning for all other elements (not even or , which can also be overridden by stylesheets). I could toss a "p { display: none !important; }" into my stylesheet, yet the tag doesn't have a warning that text inside it might not be displayed. Seems like they're grasping for reasons to discourage and .
blotter_paper 7y ago
But boldness might not look like anything -- the user agent could be outputting to a brail reader for all the developer knows. This is the purpose of the redefinition.
- deleted 7y ago
  [deleted]
- onion2k 7y ago
  Braille has typeform indicators that appear before the text to indicate that it's bold, italic, underline, etc. It is written differently in the sense that there's a character prefix. http://www.brailleauthority.org/formats/2016manual-web/section05.html http://www.brailleauthority.org/formats/2016manual-web/secti...
2038AD 7y ago
>in many ways the presentation is the semantics As McLuhan said, the medium is the message
dsego 7y ago
Doesn't mean a fontawesome icon? /s
anjbe 7y ago
 and were never deprecated. They are perfectly valid in HTML 4.01 and XHTML 1.1 and were basically treated like except with default styling. No semantic web person would have said and “replaced” and except for the specific cases where and are semantically appropriate. For example, italicizing ship names with has always been wrong.

by nfoz 7y ago

masswerk 7y ago

Ah, yes, I just noticed. Wasn't this marked as deprecated in HTML 5.2? Now the Living Standard explicitly notes that isn't necessarily rendered as bold (because it might be overridden by style sheets), by this loosening the connection to typographical appearance. As for the over-engineered part: I usually try not using spans or similar in markup to separate short terms or phrases, where there's a change in meaning or the level of information, rather using emphasis () for this. 99% of the time I end up styling this as italics. Because, this is really what typographical emphasis is all about. P.S.: And I always failed to recognize the crucial difference in meaning of "bold" and "strong". Both in speech and type these are quite the same concept to me, "bold" may be even be a bit more general and specific at the same time. (E.g., "bold" is not shout, but it's about a general concept of raised importance, which isn't clearly expressed by "strong".)

masswerk 7y ago
As a sidenote, as I now recall it, I was just too shocked by the phasing out of framesets in order to recognize the "undeprecation" of and . (I really fail to see where it helps, if future browsers fail to present historic documents in appropriate and meaningful context. Even more so, when 99% of these structures could be easily translated to semantic regions and landmarks, like header/banner, main, footer, aside, etc, even navigations could be inferred with ease by screen readers. Moreover, screen readers now have to support dynamic updates of isolated regions anyway in order to cope with JS frameworks. There was probably never a time, when frames would have posed that small a problem than at this point in time.)
saltminer 7y ago
>Now the Living Standard explicitly notes that isn't necessarily rendered as bold (because it might be overridden by style sheets), by this loosening the connection to typographical appearance. This is some pretty selective reasoning by the working group considering they don't provide a warning for all other elements (not even or , which can also be overridden by stylesheets). I could toss a "p { display: none !important; }" into my stylesheet, yet the tag doesn't have a warning that text inside it might not be displayed. Seems like they're grasping for reasons to discourage and .

blotter_paper 7y ago

But boldness might not look like anything -- the user agent could be outputting to a brail reader for all the developer knows. This is the purpose of the redefinition.

deleted 7y ago
[deleted]
onion2k 7y ago
Braille has typeform indicators that appear before the text to indicate that it's bold, italic, underline, etc. It is written differently in the sense that there's a character prefix. http://www.brailleauthority.org/formats/2016manual-web/section05.html http://www.brailleauthority.org/formats/2016manual-web/secti...

2038AD 7y ago

>in many ways the presentation is the semantics As McLuhan said, the medium is the message

dsego 7y ago

Doesn't mean a fontawesome icon? /s

anjbe 7y ago

and were never deprecated. They are perfectly valid in HTML 4.01 and XHTML 1.1 and were basically treated like except with default styling. No semantic web person would have said and “replaced” and except for the specific cases where and are semantically appropriate. For example, italicizing ship names with has always been wrong.

HTML5 undeprecated the <b> and <i> tags. https://www.w3.org/International/questions/qa-b-and-i-tags https://www.w3.org/International/questions/qa-b-and-i-tags

HTML5 undeprecated the <b> and <i> tags. https://www.w3.org/International/questions/qa-b-and-i-tags https://www.w3.org/International/questions/qa-b-and-i-tags