I had an idea for the epub standard, and want to know your thoughts.

[graycyn]

Originally Posted by JSWolf

You have to be careful. If ADE 2.0.1 or 3.x thinks your code is a mistake, the entire CSS will be ignored.

What would happen if you had first-letter and a span for a program that supports both? This is a good reason to forgo drop caps if you need ePub2 compatibility.

Since I'm back working on Under the Lilacs (on to scanning images and processing, almost done with the illustrated titlepage), and since the 1910 hardcover has, you guessed it, drop caps, I was delighted to see that initial-letter is getting some support.

So, for the moment at least, I've added it:

p.chapter-lead::first-letter {
  initial-letter: 2;
  -webkit-initial-letter: 2;
}

Here's a few images so you can see what it looks like in Sigil (which is similar to what happens in supported apps) and what it looks like in Adobe Digital Editions, v2.0.1. Same file, same code, same computer.

Now, you do have to play about with it. For instance, if you add any padding, you have to consider that if a device honors first-letter but NOT initial-letter, you could get an odd look if you go crazy with too much. A tiny dab might be OK. I've been playing with adding a trace for the letter "I", because it tends to look a bit cramped otherwise.

It's possible it might not play well with every font too, I tried it with Open Dyslexic and placement of the drop cap was odd. So a risk, given one never knows what fonts people will decide to read with. I've seen folks post some doozies!

And, with a phone in landscape orientation, you run the risk that if only the first line of the chapter fits on the screen, your drop cap will show, but its bottom half on the second line will be truncated....

I tossed the epub into the Kobo iOS app and also BookFusion iOS, and not only is initial-letter honored, but also hanging-punctuation! YAY! I tossed in a picture of the hanging-punctuation property working in the Kobo app on my iPad!

Fun times if you make backward compatible epub3! You can't eat cake ALL the time, but sometimes is nice!

[Turtle91]

Originally Posted by JSWolf

That's a very good suggestion.

Yeah, that would be nice....but.... all you need to do is put the non-supporting css first, then the @supports rule. If it supports then it takes priority since it is later in the css.

Here is the example from W3Schools:

/* use this CSS if the browser does not support display: grid */
.container {
  display: table;
  width: 90%;
  background-color: #2196F3;
  padding: 10px;
}

/* use this CSS if the browser supports display: grid */
@supports (display: grid) {
  .container {
    display: grid;
    grid: auto;
    grid-gap: 10px;
    background-color: #2196F3;
    padding: 10px;
  }
}

[Falkor]

Originally Posted by JSWolf

The problem is that when you vh or % (ie, margin, height, etc) whichever is second in the CSS is what's used. So if the reading software doesn't do vh, and that's second, it won't do anything. Neither will do anything.

That's not how CSS works. It's a nasty bug in RMSDK. CSS error handling is designed to allow for fallback.

Originally Posted by W3C

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support.

Originally Posted by graycyn

Now, you do have to play about with it. For instance, if you add any padding, you have to consider that if a device honors first-letter but NOT initial-letter, you could get an odd look if you go crazy with too much. A tiny dab might be OK. I've been playing with adding a trace for the letter "I", because it tends to look a bit cramped otherwise.

You may apply that style only to readers that support initial-letter, so you can add as much padding or margin as you need

@supports (initial-letter: 2;) {
  p.chapter-lead::first-letter {
    initial-letter: 2;
    -webkit-initial-letter: 2;
}
}

Originally Posted by JSWolf

You have to be careful. If ADE 2.0.1 or 3.x thinks your code is a mistake, the entire CSS will be ignored.

Another ridiculous bug in their error handling. I haven't ever managed to make it ignore the entire CSS, though. @supports has never been a problem for me.

Originally Posted by JSWolf

What would happen if you had first-letter and a span for a program that supports both? This is a good reason to forgo drop caps if you need ePub2 compatibility.

You have to undo the span’s styling for readers that support initial-letter. This works fine for me:

span.dropcap-epub2 {
  font-size:580%;
  float:left;
  margin: -0.1em 0.1em -0.1em 0;
  vertical-align: top;
  line-height: 1 !important;
}

@supports (initial-letter:2) or (-webkit-initial-letter:2) {
  span.dropcap-epub2 {
    font-size:revert;
    float:revert;
    margin: revert;
    vertical-align: revert;
    line-height: revert;
    }
  
  h2 + p::first-letter{
    initial-letter: 2;
    -webkit-initial-letter: 2;
    margin-right: 0.3em;
    }  
}

[JSWolf]

Originally Posted by Falkor

That's not how CSS works. It's a nasty bug in RMSDK. CSS error handling is designed to allow for fallback.

But because older versions of RMSDK are still very much used by a lot of people, you have to deal with the bug and code for it not to be triggered.

You may apply that style only to readers that support initial-letter, so you can add as much padding or margin as you need

@supports (initial-letter: 2;) {
  p.chapter-lead::first-letter {
    initial-letter: 2;
    -webkit-initial-letter: 2;
}
}

I did test @supports with an older RMSDK and yes it either works or is ignored. So that's not going to be a problem.

StandardEbooks has managed to cause the entire CSS to be ignored because they used extremity crappy code. They use code that you don't need at all. The idea is to keep it as simple as possible and they make it as complicated as possible.



You have to undo the span’s styling for readers that support initial-letter. This works fine for me:

span.dropcap-epub2 {
  font-size:580%;
  float:left;
  margin: -0.1em 0.1em -0.1em 0;
  vertical-align: top;
  line-height: 1 !important;
}

@supports (initial-letter:2) or (-webkit-initial-letter:2) {
  span.dropcap-epub2 {
    font-size:revert;
    float:revert;
    margin: revert;
    vertical-align: revert;
    line-height: revert;
    }
  
  h2 + p::first-letter{
    initial-letter: 2;
    -webkit-initial-letter: 2;
    margin-right: 0.3em;
    }  
}

Looks OK. However, a better solution (IMHO) would be to forget drop caps for ePub2.

[DNSB]

Originally Posted by JSWolf

But because older versions of RMSDK are still very much used by a lot of people, you have to deal with the bug and code for it not to be triggered.

I was under the impression that ADE2 disregarding the entire style sheet after an error was triggered by a structural error in the stylesheet not by an correctly structured unknown item. A missing { or } for instance.

[JSWolf]

Originally Posted by DNSB

I was under the impression that ADE2 disregarding the entire style sheet after an error was triggered by a structural error in the stylesheet not by an correctly structured unknown item. A missing { or } for instance.

RMSDK (ADE3 version) used by Kobo will ignore the entire stylesheet with what is thought to be an error.

Here is code that ADE 2.0.1 thinks is an error from a StandardEbooks CSS. It's code that will not work in most cases anyway. So there's no need for it.

@media all and (prefers-color-scheme: dark) {
  img.epub-type-se-image-color-depth-black-on-transparent {
    filter: invert(100%);
  }
  img.epub-type-se-image-color-depth-black-on-transparent.epub-type-se-image-style-realistic {
    background: currentColor;
    filter: none;
  }
}
@media all and (prefers-color-scheme) {
  img.epub-type-se-image-color-depth-black-on-transparent:not(.epub-type-se-image-style-realistic) {
    background: transparent !important;
  }
}

[RbnJrg]

Originally Posted by JSWolf

RMSDK (ADE3 version) used by Kobo will ignore the entire stylesheet with what is thought to be an error.

The way to deal with potential ADE bugs was explained here:

https://www.mobileread.com/forums/sh...8&postcount=12

[RbnJrg]

Originally Posted by Falkor

This kinda works for me:

<figure>
 <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"  viewBox="0 0 960 1207" preserveAspectRatio="xMidYMid meet"><image width="960" height="1207" xlink:href="../picture.jpg"/></svg>
  <figcaption>This is a caption</figcaption>
</figure>

figure {
  text-align: center;
  -webkit-column-break-inside: avoid !important;
  page-break-inside: avoid !important;
  break-inside: avoid !important;
  display:block;
}

figure > svg {
  height:80vh;
  width:100%;
}

figcaption {
  height:18vh;
  }

The trick was to not give the figure a height. That eliminated all kinds of issues.

Really? Did you try to open your epub for example under Foliate (to name one of the problematic ereaders) by employing that trick? At least you need to give a "height: 100%" for the <figure> tag. That height means nothing (because the parent box doesn't have a height) BUT will allow that the height defined by the svg wrapper takes the full space and works in those buggy ereaders. On the other hand, is perfectly possible to assign a valid height (not one that has no effect, as I stated in the previous paragraph) to the figure tag; read the following post about images and captions:

https://www.mobileread.com/forums/sh...4&postcount=29

[Falkor]

Originally Posted by RbnJrg

Really? Did you try to open your epub for example under Foliate (to name one of the problematic ereaders) by employing that trick? At least you need to give a "height: 100%" for the <figure> tag. That height means nothing (because the parent box doesn't have a height) BUT will allow that the height defined by the svg wrapper takes the full space and works in those buggy ereaders. On the other hand, is perfectly possible to assign a valid height (not one that has no effect, as I stated in the previous paragraph) to the figure tag; read the following post about images and captions:

https://www.mobileread.com/forums/sh...4&postcount=29

Sorry, I don't have a Linux system to run Foliate on.
With a 100% height setting, things can become messy in calibre viewer. (see attachment). Not setting it eliminates all issues with the caption overlapping the text.

The solution you linked places the caption on the picture in Thorium and Calibre viewer and may split the image in ADE and in Books. Removing the div and setting the height for the SVG works better for me, but splits can still happen.

[JSWolf]

Originally Posted by RbnJrg

The way to deal with potential ADE bugs was explained here:

https://www.mobileread.com/forums/sh...8&postcount=12

You would need a 3rd style sheet for software that does ePub3 but not webkit. However, it would be best for forget webkit exists as then you don't need to code for it when it won't work everywhere ePub3 works. Webkit is not part of the ePub3 standard so code without it if you want to be compliant.

In your CSS for figure, if you do need webkit code, then the program being used is not ePub3 compliant enough.

[Falkor]

Originally Posted by JSWolf

But because older versions of RMSDK are still very much used by a lot of people, you have to deal with the bug and code for it not to be triggered.

Ensuring backwards compatibility for a renderer with broken forward compatibility sure is a pain. Might be one of the reasons why it's taking so long for epub3 to catch on.

[RbnJrg]

Originally Posted by Falkor

Sorry, I don't have a Linux system to run Foliate on.
With a 100% height setting, things can become messy in calibre viewer. (see attachment).

You are doing something wrong. By writting "height: 100%" has no effect on children boxes (unless you also have "height: 100%" for <html> and <body> tags on ereaders based on Readium/Webkit. It has effect on ereaders based on RMSDK (ADE 2.x/3.x) but these last ones will ignore your "height: 80vh", so for that reason "height: 100%" works. But some ereaders based on Readium/Webkit won't use the full space you reserve for figure > svg (in your case "height: 80vh") unless you set "height: 100%" for figure. You must have something wrong with the width and height in your svg wrapper.

The solution you linked places the caption on the picture in Thorium and Calibre viewer and may split the image in ADE and in Books.

What? I suppose you are working under epub3, otherwise <figure> is not honored under epub2 and you shouldn't employed it in ADE (in ADE 4.x, as epub3, it WORKS). In Thorium and Calibre Viewer my code looks great; here you have some screenshoots:

1. In Thorium (with a font-size of 100%):



2. In Thorium (with a font-size of 137.5%):



3. In Calibre Viewer (with a font-size of 14px):



4. In Calibre Viewer (with a font-size of 18px):



I attach the respective epub so you can test it in your system. Open it in Calibre Viewer and start with a font-size: 14px; then increase the font-size to 28px. As you will be able to see, the caption remains with the picture and there is no fragmentation in the text (there is no blank space generated by the image and the change of the font-size). You must be doing something wrong, otherwise you would have the same output than me.

Removing the div and setting the height for the SVG works better for me, but splits can still happen.

As I stated before, you have something wrong. Post your code here and I will be able to help you better.

[RbnJrg]

Originally Posted by JSWolf

You would need a 3rd style sheet for software that does ePub3 but not webkit. However, it would be best for forget webkit exists as then you don't need to code for it when it won't work everywhere ePub3 works. Webkit is not part of the ePub3 standard so code without it if you want to be compliant.

In your CSS for figure, if you do need webkit code, then the program being used is not ePub3 compliant enough.

It's useless for me to explain it to you, there is no one more blind than he who does not want to see. But tell me, how do you can avoid a page-break after a box under epub3? Of course, with a code that works for example, in Thorium (that is the standard in epub3 and is the solution from Readium as desktop ereader).

[RbnJrg]

Originally Posted by Falkor

Ensuring backwards compatibility for a renderer with broken forward compatibility sure is a pain.

Not if you follow the correct method. You have to write a little more css code, but it's nothing special. It may be a little more difficult the first time, but in subsequent ebooks you use what you've already written; it's much more cut and paste.

Might be one of the reasons why it's taking so long for epub3 to catch on.

It's slow because no e-reader device has properly implemented epub3 (though the Tolino Shine is close to offering adequate support). Android, however, boasts many e-readers with great epub3 support: Cantook, Reasily, Lithium, PocketBook, Kobo, and Infinity Reader (also is still good Gitden but you can't find it anymore in Play Store).

[JSWolf]

Originally Posted by RbnJrg

You are doing something wrong. By writting "height: 100%" has no effect on children boxes (unless you also have "height: 100%" for <html> and <body> tags on ereaders based on Readium/Webkit. It has effect on ereaders based on RMSDK (ADE 2.x/3.x) but these last ones will ignore your "height: 80vh", so for that reason "height: 100%" works. But some ereaders based on Readium/Webkit won't use the full space you reserve for figure > svg (in your case "height: 80vh") unless you set "height: 100%" for figure. You must have something wrong with the width and height in your svg wrapper.

Please stop saying height: 100% only works on RMSDK when I've already proved it works on software that's not RMSDK based.

Webkit code has to go as it's nothing to do with ePub3 or ePub2 code.

What? I suppose you are working under epub3, otherwise <figure> is not honored under epub2 and you shouldn't employed it in ADE (in ADE 4.x, as epub3, it WORKS). In Thorium and Calibre Viewer my code looks great; here you have some screenshoots:

For backwards comparability, you don't use figure. You use div instead. It works the same.