Selectively assigning font-size within an element

[ElMiko]

Originally Posted by JSWolf

But in this case, it can look the same. It just means the ePub3 solution is not going to be as simple. However, the solution that would work for both ePub2 and ePub3 actually is better as it would not rely on any embedded font.

It just mean you have to use spans which will work in more cases then the embedded font solution.

Yes, that's what I said. The "fallback" for this solution (i.e. <span>ing) doesn't result in any loss. It creates less elegant code (and is more cumbersome to apply), but there's no loss... so if I'm going to <span> anyway as a nominal fallback, I might as well make it the principal code because incorporating the nicer/easier code is redundant. In this case.

[Turtle91]

I seem to recall one of the “downsides to spanning” conversations we’ve had in these threads about this topic was that it broke spellchecking, audio readback, searching, and possibly accessibility in some software because

<span>W</span>ord ≠ Word

I imagine newer software may have fixed this to some degree, but if you are using newer software it likely supports the newer capabilities in ePub3 anyway. For these reasons, and my abhorrence of kludgy coding, I stay away from breaking up words with spans just to achieve a particular (drop-cap, small-cap, etc.) type effect. (I have no issues with spanning a whole word or phrase.)

To fix the OP’s original issue (if I understand it correctly) of preventing punctuation/symbols/quotes from being included in the :first-letter pseudo selector, I use one of the following methods: 1) place the cursor to the right of the offending punctuation and tap the Backspace key, or 2) place the cursor to the left of the offending punctuation and tap the Delete key. Both methods work equally well!

It is amazing how few people would actually notice a missing opening quotation at the beginning of a chapter, and even fewer still would care…

Which do you think is the cleaner coding (assuming identical styling is achieved in the css)??

/*this css is just an example, style as you wish*/
p.first              {margin-top:2em; text-indent:0}
p.first:first-line   {font-variant:small-caps}
p.first:first-letter {font-size:6.7em; font-family:"Dion’s Big Font"}

<p class="first">Hey Dion,” she said. “That was amazing! I’ve never seen such 
efficient and practical coding!”</p>

~OR~

p.first                 {color=red}
span.firstlineinchapter {font-size:1.2em; text-transform:uppercase} 
span.smallpunct         {display:inline-block; font-size:.5em}
span.dropcap            {font-size:6.7em}
span.bigletter          {font-size:2em}
/*all the myriad span styling required to make this work*/

<p class="first"><span class="firstlineinchapter"><span class="smallpunct">”
</span><span class="dropcap">H</span>ey <span class="bigletter">D</span>
ion,” she said. “<span class="bigletter">T</span>hat was amazing!</span> … </p>

[JSWolf]

Originally Posted by ElMiko

Yes, that's what I said. The "fallback" for this solution (i.e. <span>ing) doesn't result in any loss. It creates less elegant code (and is more cumbersome to apply), but there's no loss... so if I'm going to <span> anyway as a nominal fallback, I might as well make it the principal code because incorporating the nicer/easier code is redundant. In this case.

The advantage to the <span> is that it does not rely on the font you've chosen to embed. Any program/plaform that can override embedded fonts would mean that your ePub3 code would fail.Witht he <span>, it will work regardless of what font is used.

These are the sorts of things you have to think of. So don't do anything where you need the font you've chosen to embed. Make it work with any font if possible.

[JSWolf]

Originally Posted by Turtle91

I seem to recall one of the “downsides to spanning” conversations we’ve had in these threads about this topic was that it broke spellchecking, audio readback, searching, and possibly accessibility in some software because

<span>W</span>ord ≠ Word

I imagine newer software may have fixed this to some degree, but if you are using newer software it likely supports the newer capabilities in ePub3 anyway. For these reasons, and my abhorrence of kludgy coding, I stay away from breaking up words with spans just to achieve a particular (drop-cap, small-cap, etc.) type effect. (I have no issues with spanning a whole word or phrase.)

To fix the OP’s original issue (if I understand it correctly) of preventing punctuation/symbols/quotes from being included in the :first-letter pseudo selector, I use one of the following methods: 1) place the cursor to the right of the offending punctuation and tap the Backspace key, or 2) place the cursor to the left of the offending punctuation and tap the Delete key. Both methods work equally well!

It is amazing how few people would actually notice a missing opening quotation at the beginning of a chapter, and even fewer still would care…

Which do you think is the cleaner coding (assuming identical styling is achieved in the css)??

/*this css is just an example, style as you wish*/
p.first              {margin-top:2em; text-indent:0}
p.first:first-line   {font-variant:small-caps}
p.first:first-letter {font-size:6.7em; font-family:"Dion’s Big Font"}

<p class="first">Hey Dion,” she said. “That was amazing! I’ve never seen such 
efficient and practical coding!”</p>

~OR~

p.first                 {color=red}
span.firstlineinchapter {font-size:1.2em; text-transform:uppercase} 
span.smallpunct         {display:inline-block; font-size:.5em}
span.dropcap            {font-size:6.7em}
span.bigletter          {font-size:2em}
/*all the myriad span styling required to make this work*/

<p class="first"><span class="firstlineinchapter"><span class="smallpunct">”
</span><span class="dropcap">H</span>ey <span class="bigletter">D</span>
ion,” she said. “<span class="bigletter">T</span>hat was amazing!</span> … </p>

So how would you handle backward compatibility with your ePub3 CSS code?

[Turtle91]

Originally Posted by JSWolf

So how would you handle backward compatibility with your ePub3 CSS code?

As discussed in a different thread, those pseudo-selectors have been around for a very long time. All browsers (except your Netscape Navigator 1.0) support them and I don’t think there are any current apps that don’t support them. There might be an ancient reader device that doesn’t meet ePub standards, but in that case the device would just ignore the css it doesn’t understand. It would still display fine, it just wouldn’t include the fancy extras. ie. it would display as a normal sentence without the dropcap.

This is similar to a coder that uses color in their coding… looks great on a modern/compliant reader, but still looks ok on a black and white eink…

I think that is a much better alternative than potentially breaking accessibility laws that may be introduced by using the span technique.

EDIT:
To be clear: This technique with the pseudo-selectors is not an ePub3 thing. Pseudo-selectors are supported under ePub2.

The “fallback” aspect would be using Rbnjrg’s example of setting the font range. That would work for any ePub3 compliant reader/app. If the app doesn’t support ePub3 then it would ignore that css and revert to whatever other css you had set. It wouldn’t be as pretty, but it would be acceptable.

My example of the opening quote/dropcap issue works in both ePub2 or 3.

[Turtle91]

Originally Posted by JSWolf

The advantage to the <span> is that it does not rely on the font you've chosen to embed. Any program/plaform that can override embedded fonts would mean that your ePub3 code would fail.Witht he <span>, it will work regardless of what font is used.

These are the sorts of things you have to think of. So don't do anything where you need the font you've chosen to embed. Make it work with any font if possible.

You are correct that a user choosing to override the font would cause the font to be…. Overridden. But that is true for just about ANY styling you put in the css. You can’t force the user to read things exactly as the coder wishes in an ePub; you’d need to use a PDF for that. At some point the user needs to take responsibility for breaking the ePub when they use the nuclear override option.

[ElMiko]

Originally Posted by Turtle91

To fix the OP’s original issue (if I understand it correctly) of preventing punctuation/symbols/quotes from being included in the :first-letter pseudo selector, I use one of the following methods: 1) place the cursor to the right of the offending punctuation and tap the Backspace key, or 2) place the cursor to the left of the offending punctuation and tap the Delete key. Both methods work equally well!

Not quite. What I'm looking to do is have ALL the letters in a paragraph have a different (smaller) font-size than all the punctuation and numbers in that paragraph. So, for example:

BORN: Dec. 15, 1948

[Turtle91]

Oh! That’s much easier; that’s just a basic span.

.bigger {font-size=1.1em}

<p>BORN: Dec. <span class="bigger">15, 1948</span></p>

~OR~

.smaller {font-size=.9em}

<p><span class="smaller">BORN: Dec.</span> 15, 1948</p>

[JSWolf]

Originally Posted by Turtle91

Oh! That’s much easier; that’s just a basic span.

.bigger {font-size=1.1em}

<p>BORN: Dec. <span class="bigger">15, 1948</span></p>

~OR~

.smaller {font-size=.9em}

<p><span class="smaller">BORN: Dec.</span> 15, 1948</p>

And that will work in ePub2 and ePub3.

[JSWolf]

Originally Posted by Turtle91

You are correct that a user choosing to override the font would cause the font to be…. Overridden. But that is true for just about ANY styling you put in the css. You can’t force the user to read things exactly as the coder wishes in an ePub; you’d need to use a PDF for that. At some point the user needs to take responsibility for breaking the ePub when they use the nuclear override option.

But, if there is a solution that works for both ePub2 and ePub3 and it happens to be more complicated because of ePub2, as long as it can be done, then it should be done even if the ePub3 only solution is more elegant.

As for psuedo selectors, they aren't part of ePub2. And you have to take into account Kobo and it's older RMSDK.

[rjwse@aol.com]

I have been using a right-leaning extra-large exclamation mark which descends below the line and also extends upwards beyond normal height. It just looks good to me and seems to work well with Amazon Kindle and also PDF for printing. To use it I just type in the exclamation mark twice, then hit ctrl-J to make it function as a snippet. I amusing verdana font which has right- and left-leaning quotation marks and when the exclamation mark precedes an end quote I think it looks nice. Since the concept of ending a sentence with extreme emphasis is the basis of this mark I think that being a bit larger is all to the good. Even though it is descending and ascending beyond normal size I wanted to make sure it did not change line height for the single line it is on. I certainly do like the idea of putting in a unicode-range and did not know this could be done<span class="exclam2">!</span>

[Turtle91]

Originally Posted by JSWolf

As for psuedo selectors, they aren't part of ePub2. And you have to take into account Kobo and it's older RMSDK.

Ummm, not quite. Per the ePub2 spec, section 3.1 Selectors

Reading Systems must support all CSS2 selectors, including pseudo-elements and pseudo-classes.

The red emphasis is mine.


OBTW, the ePub3 spec was released in 2011. I wonder how long it'll take for readers to adopt them... or do we get to ignore those readers after 15 years???

[rjwse@aol.com]

was released in 2011. I wonder how long it'll take for readers to adopt them... or do we get to ignore those readers after 15 years???

My Toyota is not backward-compatible to steam cars. "When" an old technology drops off varies, but it leaves the guy who owns a steam car without support. This forces you to get a new car even if you are happy with steam. There is another side to this also: the guys who are developing new car stuff are hobbled by guys clinging to steam. After all, steam guys will scream about "forced obsolescence," so there is a sort of buffer at work preventing new stuff. Maybe they got a committee of guys who say, "Yeah, we'll go there if the old stuff drops down to X percent." I just cannot see backward-compatible beyond a reasonable point. It's hard to run CP/M or DOS within modern GUI. For that matter, I do not use Microsoft Windows. I'd like to see container queries, etc. What is the best ebook reader out there? It's calibre.

[DNSB]

Originally Posted by JSWolf

As for psuedo selectors, they aren't part of ePub2. And you have to take into account Kobo and it's older RMSDK.

Jon, you really should try to keep up within a decade at least of the state of the art. The ePub 2.1 spec states that all selectors defined in the CSS 2.1 spec must be supported. See 5.10 Pseudo-elements and pseudo-classes for a list of those items.

And yes, I have used a few of them with a Kobo ereader's version of RMSDK and those few worked.

[JSWolf]

Originally Posted by DNSB

Jon, you really should try to keep up within a decade at least of the state of the art. The ePub 2.1 spec states that all selectors defined in the CSS 2.1 spec must be supported. See 5.10 Pseudo-elements and pseudo-classes for a list of those items.

And yes, I have used a few of them with a Kobo ereader's version of RMSDK and those few worked.

I'll have to give some pseudo selectors a try with RMSDK on my Libra 2. I didn't think they worked.