Is using more than one
<strong>
tag actually make the word stronger?
i.e. is
<strong><strong>abc</strong></strong>
stronger than
<strong>abc</strong>
?
I'm asking this because if you view the HTML source of the official website of North Korea,
http://www.korea-dpr.com/ you will see it has many strong tags. Is this supposed to be something like an IE hack?
Thanks in advance.
Yes, you can nest strong tags and the more you nest, the stronger it becomes. Although I'd say beyond 2-3 nested is extraneous.
The relative level of importance of a
piece of content is given by its
number of ancestor strong elements;
each strong element increases the
importance of its contents.
Source: HTML 5 spec
Some modern user agents will apply font-weight:bolder; to strong, though since it's already bold you won't really notice a visual difference. If you want, you can apply a rule such as the % so nested strong elements become larger, as indicated in the other answer.
Some screen readers might dictate the word out more loudly.
Seems like JAWS/Window Eyes screen readers don't indicate importance, according to this.
Theoretically, I think it could be made to do this with a relative CSS declaration like such:
strong { font-size: 120%; }
<strong> is a semantic tag, as all HTML tags. It don't say that that word is bold, but that have a strong emphasis. You have to use CSS to style the element.I suggest you to read this CSS Property: font-weight and the whole website.
Anyway usually web fonts don't have more than one level of "boldness" so you have to denote emphasis in another way (font size, color, etc...)
Like other have said, use a percentage if you want each nested one to make it even larger. If you want (I don't know why you would) to control explicitly how many deep you can go and what other attributes that entails, then you could also say
strong { font-weight: 100; }
strong strong { font-weight: 300; font-size: 1.1em }
strong strong strong { font-weight: 500; font-size: 1.1em; color: red; }
edit: by percentage, i meant to use font-weight: bolder... not percentage font-weights (which I'm not sure are supported)
I don't think nesting <strong> tags will make it stronger.
Edit Guess I was wrong about nesting bold tags make the font stronger based on other answers.
I would recommend using CSS with class names instead of <strong>. The CSS font-weight property offers a variety of options that you can use to incrementally bold a word
.strong
{
font-weight: bold;
/* Other options bold, bolder, lighter, normal, 100...900 */
}
.stronger
{
font-weight: bolder;
}
.strongest
{
font-weight: 900;
}
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
I'm facing a problem in changing the font size of the h1 tag with CSS. I have set the size to 4rem, but it doesn't change.
When I inspect the element in the dev-tools, h1 is showing font-size: 2.5rem;:
And the h1 title ("Meet new and interesting...") font size looks like this:
But I want the h1 tag to be bigger, like this:
I got that screenshot by editing the h1 CSS manually in dev-tools:
Why is my CSS for h1 not showing up automatically?
Code for CSS
#title {
background-color: #ff4c68;
}
h1 {
font-family: 'Montserrat', sans-serif;
font-size: 4rem;
Line-height: 1.5;
}
.container-fluid {
padding: 3% 15%;
}
Nenad Milosavljevic's answer is right, and I am just adding an explanation.
You might be having a CSS file in your HTML file which is overriding your internal CSS. To override that one, you need to put !important to your properties.
h1 {
font-family: 'Montserrat', sans-serif;
font-size: 4rem !important;
Line-height: 1.5;
}
h1.hadeline {
font-family: 'Montserrat', sans-serif;
font-size: 4rem !important;
Line-height: 1.5;
}
<h1 class="hadeline">Meet your new and ....</h1>
Try to use !important:
h1 {
font-family: 'Montserrat', sans-serif;
font-size: 4rem !important;
Line-height: 1.5;
}
While OP accepted Lokesh's answer about using !important, and others answered the same, you should treat any time you want to use !important as a code smell that you might be not playing the CSS game correctly, fighting against your other styling.
Simple specificity is better than !important
#Ashtrix is correct that increasing specificity is better than the !important sledgehammer — you can see in dev-tools that the matched CSS rule is single specificity h1, .h1, so even a single added class would make your rule be selected.
And the truth is, you are not looking for a standard h1, where all the h* sizes are proportionally bigger than the next one. So make a style h1.huge or something like that.
Not fighting against your styling library is even better
But even then, you'd be fighting against the styling library you're using!
I think you should pay attention to #Ashtrix's point about
Seems like you have an external library Reboot that is taking over the styling.
The first search hit for "reboot css" leads you to https://getbootstrap.com/docs/4.0/content/reboot/, which mentions "responsive type-scaling". If you set 4rem manually, you've lost any responsive scaling, that is to say: the library styles h1 smaller on phones than on desktop, which is a good thing.
So you need to ask the documentation, "How do I make a really big title font-size in this styling library?
And the answer is as simple as
Click on the Typography link in the docs
Skim the docs page to see its options for font size
There's 3 options that it presents to you:
Increase the whole font size by changing $font-size-base. I do not think this is what you want.
Use the Display headings class, and adjust its styling if you want. This is targeting exactly what you're looking for:
Traditional heading elements are designed to work best in the meat of your page content. When you need a heading to stand out, consider using a display heading
Make your manual h1.huge, but make it responsive. There's a concrete example in the Responsive Typography section
It seems like you have an external library, Reboot, that is taking over the styling. You need to increase the specificity of your tag.
<h1 class="title">Meet your friends</h1>
h1.title {
font-family: 'Montserrat', sans-serif;
font-size: 4rem;
Line-height: 1.5;
}
You can also use !important, but it is not considered a good practice, at least in simple use cases like this one where adding a class will suffice.
In my codepen I placed <strong></strong> tags within a paragraph, but I noticed no emphasis being displayed. Chrome developer tools shows the user agent stylesheet for strong has a line through it. What could possibly be disabling this setting as I do not override strong myself or change any font-weight within my code?
I am using chrome version 56.
<p id="p10">offset() - Get the current coordinates of the first element, or set the coordinates of every element, in the set of matched elements, relative to the document. <strong>[returns: object]</strong>
</p>
Your codepen calls this reset stylesheet (the classic "Eric Meyer Reset"):
https://cdnjs.cloudflare.com/ajax/libs/meyer-reset/2.0/reset.min.css
This resets all internal browser styles (i.e. it overwrites them), so you have (among many others) to add your own CSS for the strong tag with a rule like
strong {
font-weight: bold;
}
Or you just erase the reference to that reset style sheet...
Just as a reaction to the downvote: what do you think this is:
Is it possible that you are setting the font-weight or calling font: inherit on the <p> tag or possibly from the id?
As other answers have stated, you are probably overwriting this in your css reset file:
https://cdnjs.cloudflare.com/ajax/libs/meyer-reset/2.0/reset.min.css
You could redeclare it as follows:
strong {
font-weight: bold !important;
}
Is it possible that you are setting the font-weight or calling font: inherit on the tag or possibly from the id? I think that might be overwriting the tag. You could redeclare it as follows:
strong { font-weight: bold; }
If the above solution does not work, try using it with !important, like this:
strong { font-weight: bold !important; }
I've found an inconsistency among browsers in handling font-size (on Mac OS X 10.11.4). I'd like to know if this is a bug in Firefox, or a bug in CSS, or am I not understanding something about CSS?
This JSFiddle shows the details. In a section like this:
<pre>Start of pre section
<code>**problem here!**</code>
End of pre section
</pre>
the style code { font-family: Courier; } changes the font-size shown by Safari and Chrome, but not in Firefox. Yet in other sections, the code element size increases from 13px to 16px in all the browsers.
Why does the font-size increase from 13px to 16px after setting the font-family in all browsers?
Perhaps Firefox is changing the font-family but not the font-size. Yet it does change the font-size in other places, like in code inside a p element or inside a list.
I'm guessing the solution is to just aggressively set explicit font size with pixel units wherever I care about it (ignoring accessibility).
Quote from possibly related Firefox bug from 2006: Bug 328621 - strange default monospace font size -- differs from the proportional fonts
Though the inter-browser portability problem this imposes doesn't seem that trivial to me. The last time I wanted to markup HTML so that the monospaced parts showed the same in both Mozilla and M$IE I had to resort to absolute font sizes, which should be certainly avoided due to the accessibility problems they impose.
And yes, there's a simple workaround -- changing the settings. But most of the users will use defaults. :-(
This issue is not new; it has been known for many years that browser handling of monospace fonts is incredibly screwy and inconsistent across browsers. A number of workarounds are available that don't require you to override the monospace font preference set by the user, the most perplexing of which is to specify
font-family: monospace, monospace;
That's right: two monospace keywords at the end of the font stack. Nobody knows why this works; it just does.
For what it is worth, Firefox's UA stylesheet contains references to a -moz-fixed keyword which refers to the preference that is set by the user, which includes both the family and the size despite it being a value for the font-family property. Firefox ships with the preference set to 13px in whichever the system's default monospace font is. It would seem that monospace, monospace forces the browser to compute the element's font-size according to the spec while still preserving the preferred monospace family, at least. But this is just a guess.
Is this a bug? It depends on whom you ask. If you ask browser vendors, they'll probably say this is intentional. If you ask other authors, they'll probably also call it a bug. Is this a spec violation? No, because the spec allows browsers to implement defaults however they like.
Why does the font-size increase from 13px to 16px after setting the
font-family in all browsers?
probably because the browser's default stylesheet has these settings.
I'm guessing the solution is to not try to understand all this but
just aggressively set font and font-size wherever I care about it.
Not sure what you mean by "agressivly" but yes: If you have particular demand for that style, set it as precisely as possible in your own stylesheet, including font familiy, weight, size etc.
Since I asked the question and got a couple of good faith answers that are however not really answering my question: I'm going to try to prove that this really is a problem with current browsers. See my comment at the end about why this might or might not matter.
Here then are
3 problems with font-size in CSS/HTML in FireFox, Chrome and Safari on Mac OS X 10.11.4:
Problem 1. Changing font-family should not change font-size, but it sometimes does.
I don't know what the "user agent stylesheet" is. There can be all kinds of settings on it. But regardless of those settings, changing font-family should not change computed font-size. (Some fonts might appear larger at the same font size compared to other fonts at same font size, so visually they can look bigger or smaller, but the computed font size number should not change).
notation: in the following
pre(code) means roughly <pre><code>text here</code></pre>
p(code) means roughly <p><code>text here</code></p>
In the default situation, a page with no styles, I see this in all 3 browsers:
pre=13px
pre(code)=13px
p=16px
p(code)=13px
<pre>pre <code>pre(code)</code></pre>
<p>paragraph <code>p(code)</code></p>
Perhaps the user agent stylesheet is something like this:
pre { font-size: 13px }
code { font-size: 13px }
p { font-size: 16px }
The user agent can't be using relative sizes for code, because it appears as 13px inside of both pre and p elements. So it could be this:
pre { font-size: 81.25% }
code { font-size: 13px }
p { font-size: 100% }
or the equivalent using em instead of percentage. Or perhaps a descendent rule with percentages or em:
pre { font-size: 81.25% }
pre code { font-size: 100% }
p { font-size: 100% }
p code { font-size: 81.25% }
But then how do we explain this:
After setting code { font-family: Courier } (or any font family other than monospace) we get:
pre=13px
pre(code)=16px for Chrome & Safari pre(code)=13px for FireFox
p=16px
p(code)=16px
code { font-family: "Courier"; }
<pre>pre <code>pre(code)</code></pre>
<p>paragraph <code>p(code)</code></p>
No matter what the stylesheet is, the font-size should not change after only changing the font-family.
Problem 2. Relative font-size should be based on parent element's computed font-size. But it sometimes is not.
With no styles we have:
p=16px
p(code)=13px
After setting code { font-size: 100%; } we should have
p=16px
p(code)=16px
Instead we still have:
p=16px
p(code)=13px
This is wrong because author style should override default user-agent (browser) style. And relative (percentage) font-size is based on the parent element's computed font-size.
code { font-size: 100%; }
<p>paragraph <code>p(code)</code></p>
Similarly, after setting code { font-size: 120%; } we should have
p=16px
p(code)=19.2px = 16px * 1.2
Instead we have:
p=16px
p(code)=15.6px = 13px * 1.2
code { font-size: 120%; }
<p>paragraph <code>p(code)</code></p>
This shows that parent element is being ignored, and that some phantom value of 13px is being used to calculate the relative font-size.
Problem 3. The standard advice to use html { font-size: 62.5% } and then use em or rem for font-sizing does not work correctly
(Note: FireFox with rem does seem to be correct)
(Note: using the also recommended body { font-size: 62.5% } seemed to produce some crazy results, like doubling of font sizes, so I'm not considering that here.)
With html { font-size: 62.5%; } and code { font-size: 1.6em; } we have:
p=10px
FireFox: p(code)=13.0167px
Chrome: p(code)=13px
Safari: p(code)=13px
These should all be 16px = 1.6 * 10px
body { font-size: 62.5%; }
code { font-size: 1.6em; }
<p>paragraph <code>p(code)</code></p>
With html { font-size: 62.5%; } and code { font-size: 1.6rem; } we have:
p=10px
FireFox: p(code)=16px
Chrome: p(code)=13px
Safari: p(code)=13px
FireFox is the only browser to get it right here.
html { font-size: 62.5%; }
code { font-size: 1.6rem; }
<p>paragraph <code>p(code)</code></p>
I suspect this all doesn't matter much because people are used to slapping font-size styles all over the place in their CSS.
From my reading, there has been an attempt to make web pages more responsive to the native settings on each device: to adapt to varying hardware with more or fewer pixels per inch (PPI); to allow users with reduced vision to request larger text so they can read more easily; etc.
There are various recommendations and a bit of controversy about how to best do this: specify font-size with html { font-size: 62.5% } and use em or rem everywhere seems to be a popular opinion. Lately just using good old px to specify font-size is coming back in style, with the idea that px does not specify actual screen pixels but rather an idealized 96 dpi for the viewer (which may translate to a different number of pixels) and letting the browser's zoom controls handle user desired changes in font-size.
In summary, I think these problems with font size argue against the logic behind most of the advice about "responsive design" for font size. My guess is that this is an area where there is a lot of history factored into how browsers work, and it's near impossible to change now. And of course there are millions of websites with existing code that are all presumably happy with how font sizing is working now.
It seems to me that the only way to get consistent font sizing is to use pixels: px. For example, px at the Root, rem for Components, em for Text Elements. Or just just use pixels everywhere.
Mozilla writes the following about accessibility and font-size
Defining font sizes in pixel is not accessible, because the user cannot change the font size from the browser. (For example, users with limited vision may wish to set the font size much larger than the size chosen by a web designer.) Therefore, avoid using pixels for font sizes if you wish to create an inclusive design.
But with all these bugs with inherited and relative font size it doesn't seem like an option to avoid using pixels. Plus the argument about a reference pixel and using the browser's zoom control seems to solve the accessibility issue.
That's because back in the dark ages one Netscape dev decided to force his personal preferences on everyone else in the browser settings (most coders are young people who think it is smart to destroy their eyes by setting text size one or two sizes smaller than everyone else, they think "monospace" belong to them and "sans serif" to normal human beings).
Thus, Firefox ships with defaults that alias "monospace" to a smaller font size than "sans serif". Pretty much destroys coordinated font sets (where the monospace font is designed to look the same as the serif or sans serif one).
You can "fix" it locally by launching about:config and changing all font.size.fixed.* properties to the same value as font.size.variable.* ones. But since you can't fix all Firefoxes in the wild, that makes the monospace css alias useless for this browser.
Response from OP moved from question to answer:
The answer from BoltClock was super helpful. The page he/she referenced about Fixed Monospace Sizing by Eric Meyer has a thorough analysis and some solutions. It explains some of the browser mechanics related to when the user's font preferences are used, which explains some of the mysterious behavior I was seeing (e.g. why was the code element seeming to inherit a size of 13px when it was the child of a p element with size of 16px: the reason is it actually inherits size medium which causes the browser to use the default browser/user preferences).
For my situation I'm finding I can remove the html { font-size: 16px; } style and instead add the following:
pre { font-family: monospace, monospace; }
code { font-family: monospace, monospace; font-size: 100%; }
This gives me consistent relative font-sizing but still allows the user to set the default font-size. Eric Meyer recommends using monospace, serif but I'm finding that monospace, monospace works, and I think it makes a little more sense when you see it in a style-sheet (it's odd, but looks probably intentional, and it means you really, really want monospace).
I think that the ultimate problem is that the browsers have different font-size defaults/preferences for monospace font, than for other fonts. The main idea of "accessible responsive design" in regards to font-size is to let the user have control over font-size. But when we have several settings for font size (serif, sans-serif, monospace) then that's too many options for the user to set. The user just wants bigger text that they can read. But for the author: they just want the relative sizes of the fonts to be correct at whatever given size.
In case it's helpful to someone else, here are some examples (in the slick Eric Meyer style) showing that monospace, monospace fixes some of the problems I wrote about in my own answer below.
code:before {
content: attr(style);
border-bottom: 1px solid #AAA;
color: #575; margin-right: 0.5em;
}
p {
margin-bottom: 2em;
}
<p>This is a 'p' element with a <code>'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace, monospace">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-size: 100%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace; font-size: 100%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace, monospace; font-size: 100%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace; font-size: 120%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace, monospace; font-size: 120%">'code' element</code> contained within.</p>
I came across a similar issue where I used monospace and the sizes were different in Google Chrome and Edge & Mozilla Firefox. This is because different browsers have different font weights and sizes for standard fonts.
To resolve this issue I used Google fonts and then the fonts sizes were the same in all browsers.
I want to put tags around a some text without changing whatever font family and font size the text has already inherited. I could redefine the CSS for h1 so that nothing is said about the font-family or font-size but then the values from the user agent would just come through. I need to define the CSS for h1 in a way that the user agent values are killed, something like
h1{
font-family:none;
font-size:none;
}
But I don't think that will work.
Thanks
Just use the inherit keyword.
font-family: inherit;
font-size: inherit;
I can't think of a good reason for making the most important heading in your document indistinguishable from body text though. It runs the risk of being treated as a spam flag by search engines.
Please use inherit, this will work, which will inherit your parent style
font-family: inherit
Font size is simple:
h1 { font-size: 100%; }
Font family is trickier, and the most robust way is to declare the font family h1 and its parent together. Assuming that h1 is a child of body, you could use
body, h1 { font-family: Helvetica, Arial, sans-serif; }
These settings, like any settings you might set, are ineffective against user style sheet rules that override them, as well as against browser defaults when the browser has been configured to ignore font sizes and/or families specified on web pages.
However, they work wider than the use of inherit, which is not recognized by some old browsers.
I am aware than ID rules are faster than class rules, which are faster than tag rules, which are faster than universal rules, as noted on MDN. My question pertains to CSS performance with respect to inheritance. For example, which of the following is more efficient?
body {
font-family: Helvetica, Arial, sans-serif;
font-size: 16px;
}
h1 {
font-family: Georgia, serif;
font-size: 36px;
font-weight: 700;
}
or
h1 {
font-family: Georgia, serif;
font-size: 36px;
font-weight: 700;
}
.article-text {
font-family: Helvetica, Arial, sans-serif;
font-size: 16px;
}
While there is only one <body> tag in the DOM, there could be hundreds of p.article-text elements. Since there is only one <body> tag, does that mean that a <body> style is more efficient, even though I'd be restyling the <h1> elements? Or is it more efficient to style the .article-text elements, since doing so would use a more specific selector and I wouldn't need to worry about restyling the <h1> elements?
Always wondered this. Thoughts?
I think that the MDN article you showed is written in a harmful way, as it proposes to focus on CSS micro-optimizations while almost always page speed can be increased in different ways (eg. Google Page Speed has interesting hints).
I can't remember any situation in my websites where CSS was a bottleneck. You might want to see "Timeline" in Chrome Developer Tools on some pages and notice that the amount of time spent on working with styles is usually insignificant compared to other events.
If I was to give advice, I'd rather go the other way and use CSS preprocessing tools like SASS or LESS to improve maintainability. This might even eventually help to reduce number of rules.
As mentioned by steveax. It's not worth worrying about.
Moreover, the answer really depends on the browser and on the HTML actually given.
i would say the top one is probably faster out of the two but tbh like everyone has said with the browsers we have ATM and devices and connections speeds you wouldn't notice a difference unless you have a huge site that has more than 40 - 50 pages that's when you should look into slim lining your code