h? font size adjusting

[hobnail]

In my html I have

 <h2>One <span>Old Man Arlo’s dogs</span></h2>

The text in the span gets moved to its own line with display:block. I also want it larger than the h2 text. In my css I have

h2 span {
    display: block;
    font-size: larger;
}

I don't specify a font-size in the css for the h2 tag; I'd rather keep things simple and let the ereader use whatever size it uses. I'd like to make the h2 text even smaller but if I put font-size:smaller in the css for the h2 that also makes the text in the span smaller. Is there a way to make the h2 text smaller and keep the span text larger, only with css? (Without adding a span around the "One" for example.)

[JSWolf]

Originally Posted by hobnail

In my html I have

 <h2>One <span>Old Man Arlo’s dogs</span></h2>

The text in the span gets moved to its own line with display:block. I also want it larger than the h2 text. In my css I have

h2 span {
    display: block;
    font-size: larger;
}

I don't specify a font-size in the css for the h2 tag; I'd rather keep things simple and let the ereader use whatever size it uses. I'd like to make the h2 text even smaller but if I put font-size:smaller in the css for the h2 that also makes the text in the span smaller. Is there a way to make the h2 text smaller and keep the span text larger, only with css? (Without adding a span around the "One" for example.)

 <h2>One <span class="h2">Old Man Arlo’s dogs</span></h2>

.h2 {
    font-size: larger;
}

That will do what you want.

[hobnail]

Originally Posted by JSWolf

 <h2>One <span class="h2">Old Man Arlo’s dogs</span></h2>

.h2 {
    font-size: larger;
}

That will do what you want.

The current css is doing that, but without the class on the span. The current css is using the "h2 span" combinator which matches spans inside an h2. I'm getting the larger part and I want to make the h2 text even smaller.

[Jellby]

Originally Posted by hobnail

I'd rather keep things simple and let the ereader use whatever size it uses. I'd like to make the h2 text even smaller

Aren't those two things contradictive?

My suggestion: don't rely on "whatever size it uses" being anything reasonable, set what you want, but in relative terms, e.g.:

h2 { font-size: 100% }
h2 span { font-size: 120% }

Anyway, relative sizes are relative to the container element, so yes, changing the h2 size will affect the absolute size of the span inside, but not its relative size, it will always be 120% of whatever a bare h2 is.

Or maybe what you really want is:

<h2><span class="number">One</span><span class="title">Old Man Arlo’s dogs</span></h2>

h2 span.number{ font-size: smaller }
h2 span.title { font-size: larger }

Now "One" will be one step smaller (whatever that is) than a bare h2, and "Old Man Arlo’s dogs" will be one step larger, so they will be separated by two steps. A similar thing you should get with:

<h2>One <span><span>Old Man Arlo’s dogs</span></span></h2>

h2 { font-size: smaller }
h2 span { font-size: larger }

[hobnail]

Originally Posted by Jellby

My suggestion: don't rely on "whatever size it uses" being anything reasonable, set what you want, but in relative terms, e.g.:

h2 { font-size: 100% }
h2 span { font-size: 120% }

Anyway, relative sizes are relative to the container element, so yes, changing the h2 size will affect the absolute size of the span inside, but not its relative size, it will always be 120% of whatever a bare h2 is.

I like this idea; thanks. I have an add-on css file for these books that have two lines for the chapter title, the ones where the h2 has a span in it. The add-on css file overrides stuff in the main css file. In the add-on I could use whatever percentages work for me.

[JSWolf]

H1 = 2em
H2 = 1.5em
h3 = 1.17em
h4 = 1em
h5 = 0.83em
h6 = 0.67em

Those are the default sizes that h? should be. As to what you want, that can be set in CSS. A CSS size of 100% is meaningless as that's 100% of the default size for that program. If you use font-size: 1.5em; you get the correct default size. The other thing you could do if you want smaller is to use <h3> instead of <h2>.

[Jellby]

Originally Posted by JSWolf

A CSS size of 100% is meaningless as that's 100% of the default size for that program.

I could be wrong, but no, it's 100% of the font size of the parent element (which will probably be <body>), so it's effectively the same as 1.00em, but far more understandable, in my opinion.

[JSWolf]

Originally Posted by Jellby

I could be wrong, but no, it's 100% of the font size of the parent element (which will probably be <body>), so it's effectively the same as 1.00em, but far more understandable, in my opinion.

If the program being used respects the correct default values for h?, then <h4> will give 1em.

IMHO, 100% is not as understandable as you have to know what the the what the 100% is 100% of. If you use 1em as the font size, you know it's 1em. So 120% would be 20% larger then 100%, but you still don't know what 100% translates to so how would you know what 120% is other then 20% larger then 100%?

[hobnail]

Originally Posted by Jellby

I could be wrong, but no, it's 100% of the font size of the parent element (which will probably be <body>), so it's effectively the same as 1.00em, but far more understandable, in my opinion.

I don't know anything, which is why I get ides from sites like this:

https://friendsofepub.github.io/eBookTricks/

Somewhere on there he recommends for the body tag font-size:100%.

[Jellby]

Originally Posted by JSWolf

If the program being used respects the correct default values for h?, then <h4> will give 1em.

Why are they "correct" default values? I don't recall their being given in any specification. At most they are recommendations or common values.

IMHO, 100% is not as understandable as you have to know what the the what the 100% is 100% of. If you use 1em as the font size, you know it's 1em. So 120% would be 20% larger then 100%, but you still don't know what 100% translates to so how would you know what 120% is other then 20% larger then 100%?

100% is the selected font size that I (the user) choose as my preferred/default. The same could be said for 1em: 1em at which font size? If you don't know what 100% is, you also don't know what 1em is. To me it is clear that 100% is the size the font would be if there were no other scaling (explicit or default) applied.

[Jellby]

Originally Posted by hobnail

https://friendsofepub.github.io/eBookTricks/

Somewhere on there he recommends for the body tag font-size:100%.

Not that I can find, and I would personally avoid it. It's redundant and misleading. Body font-size is best left unspecified, let the reader (both user and software) choose it. I can only justify it to override some silly default that might be built-in in defective readers.

[JSWolf]

Originally Posted by hobnail

I don't know anything, which is why I get ides from sites like this:

https://friendsofepub.github.io/eBookTricks/

Somewhere on there he recommends for the body tag font-size:100%.

Some of those tricks I would have nothing to do with.

Add line-height to body <-- ignore this or you ruin the line height slider for Kobo.
Don’t define a line-height value which is less than 1.2 <-- KF8 will ignore any line height less then 1.2. It's best to not specify a line height for Kindle eBooks.
Disable hyphens <--- ignore that as hyphens should be left on.
Declare text-align for elements which should be left-aligned <-- use left align sparingly or not at all
Prevent sub- and superscript from affecting line-height <-- You aren't specifying line height so ignore this
Use real small capitals <-- ignore this and specify a font size for small caps as most versions of RMSDK (ADE) in use do not work with a font variant to specify small caps
Use semantic asterisms and make them reflowable <-- ignore this as background images can work rather poorly with eInk screens
Fake asterisms (context change) <-- ignore this because you ignored the one above that goes with it
Force the color of links to be text’s <-- ignore this as it's not useful on eInk screens
Make HTML5 tags behave as expected in legacy RMSDK <-- ignore this as you don't need a block display
Prevent horizontal margins to reflow with font-size <-- ignore this as % for the margins is a very bad idea and the size of the margins will change based on the screen size and possibly resolution
Create an automated numbering system <-- ignore this as it won't work in enough cases
Build a super simple responsive grid <-- ignore this as it won't work in enough cases
Give text wraps a modern twist <-- ignore this as it won't work with ePub 2
Force images to keep their aspect ratio <-- ignore this as it won't work with ePub 2 and I've never seen images be skewed to need to fix the aspect
Use text color as a variable <-- forget used colored text as it doesn't work well with eInk screens

So after looking at all the tips/tricks, most of them should be ignored. They could end up breaking the eBook depending on the software used to read the eBook.

[Turtle91]

Jellby is correct - 120% or 1.2em are effectively the same thing. They are both 1.2 times the size of the font selected by the user - or defined in the body tag.

It is fairly common - in web page design - to assign the standard font size in the <body> (eg. body {font-size 100%}) and then use em's to define the relative font-size to that 100%. If the user changes the font size in their browser, then all fonts change with respect to the base font size in a usable manner. eBooks are similar. I leave the 100% in the body for default purposes, some may choose not to, but the user has the ability to overide that setting with their reader/app settings.

Here's a much better explanation...make sure you read the "addendum" at the end.
https://kyleschaeffer.com/css-font-s...-pt-vs-percent

[Jellby]

The "addendum" and the description before have at least one mistake: "px" is not equivalent to one screen dot, and it's not resolution dependent. "px" is an absolute unit equal to 1/96 in, although it can be modulated by screen resolution (to make it match a whole number of physical pixels, not necessarily 1) and by intended viewing distance. If a device makes a 11-px font very difficult to see, the device is faulty.

[JSWolf]

Originally Posted by Jellby

The "addendum" and the description before have at least one mistake: "px" is not equivalent to one screen dot, and it's not resolution dependent. "px" is an absolute unit equal to 1/96 in, although it can be modulated by screen resolution (to make it match a whole number of physical pixels, not necessarily 1) and by intended viewing distance. If a device makes a 11-px font very difficult to see, the device is faulty.

Another issue with the addendum is...

Pixels are now considered acceptable font size units

Which is wrong because px for font size is not acceptable.