What is the difference between STRONG and BOLD tag?
The <strong> tag is a “logical” tag. This means that it is used when you want to add emphasis to particular words or phrases. Some screen readers may use a different inflection when they come across this tag to communicate the emphasis. The <b> tag is primarily for visual effect on a page when designing layout.
<b> applies the typographical convention of making the text content bold. It has no effect on the content where it is presented in any other way other than as written text. You would use it when there is a typographical convention that gives some significance to the text being bold - which is very rarely the case. Most typographical conventions use italic rather than bold text to indicate whatever it is they are trying to indicate - book name, ship name, foreign language etc.
If you are trying to apply emphasis to particular words then <em> and <strong> are the appropriate tags to use as they apply regardless of how the content is presented - written, spoken etc.
Check the example I put in this thread:
It explains the differences between B, I, STRONG and EM very well. If you aren’t stressing the point by emphasizing a section of text, that’s when B and I are more appropriate than STRONG and EM. When you say a name or book title you aren’t emphasizing them, you’re just making them bold due to typographical conventions. <em>As I’ve said many times</em> here on <b>Sitepoint</b>, <q><strong>Do NOT use tags that add emphasis on elements that are simply bold or italic for other reasons!</strong></q>
Strong is used as bold text, and <em> as italics. There is no difference between <b> and <strong> and <i> and <em>.
I’m sorry, but that’s just wrong. Deathshadow and Felgall have both explained the difference quite clearly, and you should be able to work it out from the tag names themselves. <b> is for bold text and <i> is for italic text. These are purely presentational. <em> is for emphasised text and <strong> for strongly-emphasised text, irrespective of how that text is presented. The default rendering in most browsers may be bold and italic, but that is not what the tags themselves mean.
Both tags are approximately same and use for highlighting the text on a web page.
no, that’s wrong, sorry
highlighting?? sheesh!!
please try and keep up
Don’t waste time arguing with the one post wonder ******, they’re probably just spammers posting nonsense to up their post counts…
I mean really, 15 day bump by posters who obviously have no clue what they’re talking about? Fishy. You look at the rest of both of those users posts and… well…
Willing to bet they wouldn’t even have been allowed to join if you folks were running something like stopforumspam.com – which is frankly WAY overdue here.
Though I could just be kneejerking into paranoid mode just because I ‘get that way’ whenever dealing with people who choose their markup based on the tags default appearance – as always if you choose a tag based on what it looks like, you’re probably choosing the wrong tag.
Where people get confused, and where I had gotten confused in the past, until I started reading about this, here and elsewhere, is that <strong> and <bold> can LOOK the same, depending on the style, but semantically are different. It just so happens that the browsers default both elements as bold, so people who don’t know just think it’s another element for bold, or that it replaces it. Both tags can be whatever you want it to be if you override the browser’s default. But from what I understand, bold defines the weight of the text, and strong defines the intention of the designer to stress a certain piece of content over another.
Here is my question, even though I know <b> is not depreciated, if you are concerned with separation of presentation and content, isn’t <b> presentational? I mean, shouldn’t we be defining our presentation in the CSS sheet and not in the markup? It seems to me that <strong> should replace <b> for that reason.
B, is a font style although not deprecated, its use is discouraged in favour of style sheets. Within the XHTML 1.1 family it is consider part of the Presentation Module whereas the EM and STRONG are text containers. CSS ‘bolder’ would most likely be the nearest visual substitute for B thus being akin to; b {font-weight: bolder;} .
Not only that I have actually found that when you use <b> for your text, each browser renders that differently because it is not using a specially designed alternate bold typeface as in the print industry. You are leaving the browser to interpret bold with it’s own trickery. It’s actually faux bold. This might be a small issue for most applications of it, but I have actually found that because the <b> was smaller in some browsers than others, I was actually having problems when the size difference caused alignment issues of a few pixels that made a huge visual difference in the end.
When I changed <b> to <strong> it went away. I am not sure why since it was still faux bold, but it worked. However, I even recommend finding a free typeface online with multiple variations specially designed, using Font Squirrel to convert it, and defining bold and strong that way. The fact that we are able to do this on the web brings friggin tears to my eyes. It’s a miracle! Wow, finally real professionally designed bold and italic type variations. Who’d have thought.
Even though I know browsers still interpret fonts differently, I have found the difference to be very small.
I’m amazed that there is any rendering difference between <b> and <strong>, even if you’re using fonts that don’t have a bold style built in. Have you got any examples or screenshots of this difference?
No, that was a while ago. It might be that I had styled <strong> via CSS as a font weight of bold, but again, that shouldn’t make a difference, I know.
B and I DO NOT MEAN presentational style!!! Many words and phrases GRAMMATICALLY should be bold or italic in print. Book Titles, names of ships, etc… When TBL made HTML many of the output devices couldn’t make bold… Do bold text on a daisy wheel printer… do Bold text in 80x25 MDA or a 132 column serial terminal… The bold tag does NOT ACTUALLY MEAN THE USER AGENT NEEDS TO RENDER IT AS BOLD… “grammatically as print it would be bold”. Does not mean on your page it has to be; just so long as you indicate the text is different from what’s around it… See how on many non-graphical browsers underscores are put around bold text, and tilde’s are put ~around~ italic text.
The actual presentation being entirely up to the discretion of the user agent – like EVERY OTHER original HTML 2 tag.
Just as horizontal rule does not actually MEAN a bar across the screen, but a change in topic… just as P means a grammatical paragraph, not a typographical one… (or worse, “but it’s text”)
Again why if you’re choosing tags based on it’s default appearance, you’re probably choosing the wrong tags.
though Grammer m0st poStrs width nutters me drive y shud theys sights different be?
I’m sorry to disagree, but <b> seems pretty clearly presentational. The reason is that is is not describing WHAT the content is but what it LOOKS LIKE. It would be as bad as having <helvetica></helvetica>. Sure I could style that to be Tahoma, but then I have semantic problems. If you take the <b> tag which semantically means “bold” and you define it as italic, then you have a tag that means “bold” in your markup but presents as “italic.” That’s like having this <div class=“red text”> and then defining it as blue. Or worse yet, <span="BoldText>. To me that last one is the same as using <b></b>.
A horizontal rule DOES mean a “rule” that runs “horizontally.” Semantically that is what it actually means. A NON presentational would be if you created a class like “topicChange” and then define a horizontal line with a border style because you have left all your styling to your CSS so now you are not stuck with “horizontal” or “rule” but you can make it be whatever you want.
So if you had a book title, rather than do this <b> Grapes of Wrath </b>, you do <span="BookTitle>Grapes of Wrath </span>. Now you define it as bold, or italic, or red, or blue, or uppercase or whatever. You aren’t stuck with “b” for “bold” if your title isn’t bold anymore.
I think that may vary by location. I was taught at school that, grammatically, book titles and the like should be contained in inverted commas. (The fact that I was taught grammar and punctuation at all probably says something about my age.)
However, in this context, I was looking at the W3C meaning. In the HTML4 specs, <b> and <i> are regarded as styling elements and therefore presentational. But “The HTML5 specification redefines b and i elements to have some semantic function, rather than being purely presentational”, says the [URL=“http://www.w3.org/International/questions/qa-b-and-i-tags”]HTML5 resource.
So, it looks as if, on this occasion, ds60 and HTML5 are in complete agreement. He will be pleased…:stir:
That’s a distinctly UK thing… Oxford English… Which wasn’t established as a standard until the early part of the last century… as opposed to US English which was standardized and taught from that standard from the 18th century onward… Funny that, until sometime around 1900 the limeys had no official standard/specification for their language.
Sorry, worked at a living history museum that recreates the 17th century for a number of years, tend to pick up a few things.
HTML 4’s… definitions of tags are … bad. It’s actually something that for all the pissing on HTML 3.2 we do for it’s presentational crap like CENTER and FONT, it does a better job of when it comes to certain elements like P and H1… at the same time the definition of B and I has sucked ever since 3 came along.
You go back to 2…
http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.7.2
For the link shy:
Typical renderings for idiomatic elements may vary between user agents. If a specific rendering is necessary – for example, when referring to a specific text attribute as in “The italic parts are mandatory” – a typographic element can be used to ensure that the intended typography is used where possible.
(21)
Bold: B
The B element indicates bold text. Where bold typography is unavailable, an alternative representation may be used.
In this case they are using the word typographical to mean grammatically, while they seem to be using the word typographic to mean presentation – which is a piss poor choice of words and the root cause of all the confusion down the pipe. As such, you have to reason out the rest of what it says to put those words in context. (treading into the same area as empty elements – where an empty element in HTML means an element that cannot have child nodes (not even text) – NOT elements that have no child nodes. <div></div> is not an empty element which is why <div /> is invalid XHTML!)
That it can be rendered as something other than bold (as said many times in every html spec) is proof it means when text would be bold, not must be bold – which is the difference between meaning and appearance.
Which is why the HTML Specifications (all of 'em) are filled to the gills with “typicallly”, “would”, “could” and “may” and damned scarce on “must” or even “should”… It’s how it should be as the entire original point of HTML was to be able to structure a document in a manner that the user agent could customize to the device capabilities; So saying BOLD was NOT to say “this must be shown as bold” but “this typically is shown as bold, do what you can”.
But again, with the needlessly vague and cryptic wording of every specification – it’s a miracle the bloody thing works at all. Makes you want to scream at them Samuel L. Jackson style Englisc, mōdor wyrter! Gedōn ēow cweþan hit!?!
There are at least some attempts to clean up the meanings of the existing tags in HTML 5… it’s one of the few things I have positive things to say about – 99% of my problems lie with the new redundant pointless idiotic tags that serve no good purpose apart from making pages a billion times more complex than need be, and the loosening of the structural rules to the point it sets coding practices back a decade… Again, carefully crafted for the people who just vomit up HTML 3.2 and slap a 4 transitional doctype on it – now instead of slapping a tranny on it they give it 5 lip service, net improvement zero. Either way you look at it, it’s Admiral Ackbar territory.
According to W3C:
Which is probably why they also say: “You should not use b and i tags if there is a more descriptive and relevant tag available. If you do use them, it is usually better to add class attributes that describe the intended meaning of the markup, so that you can distinguish one use from another.”
In the case of all their examples above, here are better, and more meaningful semantic markups:
<span=“keyword”>
<span=“productName”>
That way you don’t have to be STUCK with BOLD, if you decide to change your keywords to something, say like italic instead? Span is completely neutral, while bold is descriptive of the presentation of the text. That’s why when you set up your styles in CSS, you have “font-weight” with available values like: 300, 400, 600, and … bold! I have a general rule that if it can be done through a CSS value, I probably should keep it out of my markup. So just like I wouldn’t use <400>, or <#F00>, or <uppercase> if they were available, I don’t use <b> either, even if it is a technically valid holdout from ancient past.
Obviously W3C is lightly discouraging the use of <b> and <i> for pretty good reasons.
I want to bring up some points.
Some screen readers may use a different inflection when they come across this tag to communicate the emphasis.
None that I know of. Similarly, they all (at least the big names) seem to ignore aural stylesheets entirely. When the specs were written, there was hope that strong and em would be pronounced differently, but if you give a good listen to speech synthesizers, they mostly suck already. You’re lucky to get them to bring the tone down at the end of a sentence (mine do it in the middle of a sentence if it’s the end of a line!) or speak capital letters out in a higher pitch… getting them to speak like a human with emphasis is just asking too much. Except from VoiceOver, that synth is pretty good and would be the first one I’d expect to even try making strong and em sound differently. At least for English. The Dutch is… hilarious to say the least. Feeeerfox and weeeebdesigners, lawlz.
Not only that I have actually found that when you use <b> for your text, each browser renders that differently because it is not using a specially designed alternate bold typeface as in the print industry. You are leaving the browser to interpret bold with it’s own trickery. It’s actually faux bold.
This isn’t true for any of my browsers, but I could believe this to be true on a Mac. Specifically Safari was one of the few browsers who actually understood the different font-weights (100, 400, 700, etc) and Macs were possibly the only OSes equipped with actually different weights of at least some fonts.
What my (Linux) browsers do: if the font they are rendering has a bold version, they just throw that in there. Nothing more. Once I downloaded a “free” Tahoma (somehow it was supposedly around the licensing restrictions???) for Linux. It did not come with a bold or an italic or an oblique, only “normal”. B and strong tags were not rendered bold when this font was applied, because I simply did not have it.
Italics, however… IE especially was known for making faux italics by tilting the letters, which I believe lead to the overflow bug known in IE6. I’m sure IE wasn’t the only browser to tilt letters instead of using the italic version of the chosen font. Also explains why it looked like pants. : )
However, in this context, I was looking at the W3C meaning. In the HTML4 specs, <b> and <i> are regarded as styling elements and therefore presentational. But “The HTML5 specification redefines b and i elements to have some semantic function, rather than being purely presentational”, says the HTML5 resource.
Yeah the HTML5 guys have been trying to figure out how to make non-semantic (typographic) tags mean something.
Guess what they did with the u tags? Yeah, they’re back. Specifically for Chinese proper nouns though. And of course WYSIWYGs; unfortunate that the HTML5 spec considers real-world use, even if terrible, to be reason enough to state that’s how we should do things. Bleh.
I was taught at school that, grammatically, book titles and the like should be contained in inverted commas.
I was taught in school that ship names, the first time a name of an interviewee was presented in an article, and bibliographies needed to be bold. I was taught that book/magazine/article titles were to be underlined. However, in practice, we underlined everything (or, that was allowed) because most of us didn’t have computers with word processors, but electric typewriters. Bold was possible (go back every letter and re-hit it several times) but underlining was just easier to do and easier to see. This is partially why some styleguides say bold and others say underline for the same thing: only a typesetter could do bold or italic, while regular people were stuck with underlining.
That’s why when you set up your styles in CSS, you have “font-weight” with available values like: 300, 400, 600, and … bold!
You have “bold” because not all fonts (I’d maybe dare say MOST fonts) don’t have all those weights at all. Bold == anything 400 and up. However some of the older font absolutely have a 100 weight, a 400 weight, a 600 weight… so CSS was designed to deal with that, but in the real world, means little. But you type one less character so I’m all for it.
Personally I set
strong {
font-weight: bold;
}
and
em {
font-style: italic;
}
in my stylesheets most of the time because, as you’ve noted, it’s not a hard and fast rule how they are rendered, just that most user agents currently tend to display those tags that way.
But since no machines can see the difference, the semantics I write with strong and em are just for kicks, shts, giggles, and to stroke my ego as “semantics warrior”. I kinda believe something can’t be “semantic” (have meaning) if nobody actually bothers to read the meaning into the tag. HTML5 is like that currently: there are all these supposed future benefits of “semantic tags” but they don’t mean zip to any machine or program out there. <article> == <div> in current user agents, including screen readers (who are one of the big reasons championed for more semantic tags really).
In the glorious future, though, they will have meaning and we’ll finally get our damned flying cars. Only been waitin 50 years for those…