EPUB 3.3 BECOMES A W3C RECOMMENDATION

[Quoth]

Originally Posted by ownedbycats

Nah. Just because the options are there doesn't mean you have to use them.

I agree. I wish everyone would realise it and there was some way to know what features a reader or app provides, or what features an electronic document needs as a minimum and maximum.

Originally Posted by ownedbycats

Plus this:

(source)

Oh yes, been there several times and designed the new spec

[JSWolf]

Originally Posted by Quoth

I agree. I wish everyone would realise it and there was some way to know what features a reader or app provides, or what features an electronic document needs as a minimum and maximum.

Test it with software that is still in use such as an older version of RMSDK as used in a Kobo because Kobo is popular and you cannot guarantee that your eBooks will be read as KePub.

[shalym]

Originally Posted by JSWolf

Test it with software that is still in use such as an older version of RMSDK as used in a Kobo because Kobo is popular and you cannot guarantee that your eBooks will be read as KePub.

Did you try the epub that graycyn uploaded?

Shari

[graycyn]

Originally Posted by Quoth

I agree. I wish everyone would realise it and there was some way to know what features a reader or app provides, or what features an electronic document needs as a minimum and maximum.

Oh yes, been there several times and designed the new spec

Seems to me that half our troubles would be solved if there were an actual reading system standard that anything (device or app) calling itself an epub reader had to adhere to. One that includes the entire subset of CSS/HTML that applies to epub.

I know, I know, WISHFUL THINKING!

[JSWolf]

Originally Posted by shalym

Did you try the epub that graycyn uploaded?

Shari

Yes and it did work.

But, I've seen plenty of cases where things that could work, don't work because the code used is not correct for backwards compatibility.

Things like rem (instead of em) and vh/vw (instead of %) for example. The old software (for the foreseeable future) is not going away. So eBooks really do need to be made as compatible as possible.

[JSWolf]

Originally Posted by graycyn

Seems to me that half our troubles would be solved if there were an actual reading system standard that anything (device or app) calling itself an epub reader had to adhere to. One that includes the entire subset of CSS/HTML that applies to epub.

I know, I know, WISHFUL THINKING!

What would solve most of the problems (IMHO) is to get Kobo to update RMSDk to the latest version.

[DNSB]

Originally Posted by graycyn

Seems to me that half our troubles would be solved if there were an actual reading system standard that anything (device or app) calling itself an epub reader had to adhere to. One that includes the entire subset of CSS/HTML that applies to epub.

I know, I know, WISHFUL THINKING!

One problem is that quite a few of the features in the various ePub and CSS specifications are not mandatory and while there seems to be some effort to gracefully fail, that is not the case with all epub renderers especially the Android ones which seem to happily wander off in their own directions.

[DNSB]

Originally Posted by JSWolf

What would solve most of the problems (IMHO) is to get Kobo to update RMSDk to the latest version.

Jon, your insistence that Kobo update their version of RMSDK to the latest and greatest is getting overly repetitive. Perhaps you should be willing to pay for the cost of the newest version of RMSDK from whichever Adobe reseller?

[graycyn]

Originally Posted by JSWolf

What would solve most of the problems (IMHO) is to get Kobo to update RMSDk to the latest version.

But that's only Kobo. Not that I'm not in favor of them updating, mind you! All for it!

I think Nook is actually on an older version than Kobo is. No proof, other than occasionally I've tried some bit of CSS that would be OK on Kobo (app and device) and bork in the Nook app.


Sent from my iPad using Tapatalk

[graycyn]

Originally Posted by DNSB

One problem is that quite a few of the features in the various ePub and CSS specifications are not mandatory and while there seems to be some effort to gracefully fail, that is not the case with all epub renderers especially the Android ones which seem to happily wander off in their own directions.

The Android epub readers wander every which way and not always happily, either! Some totally toss publisher CSS out. Others have weird overrides. I downloaded one once, can't remember the name, but it was a relatively popular one, and it made all headings a particularly ugly GREEN color. Like why?

Another decided to override the default display for the <abbr> tag, setting it to display as a BLOCK ELEMENT rather than inline. Even if the tag was specified INLINE in CSS!

Some apps will ignore a semantic <hr/> rule, resulting in no scene break appearing. I try not to think about these apps. I don't want to believe people actually read books in them, yet obviously, it happens. 🤣


Sent from my iPad using Tapatalk

[DNSB]

Originally Posted by graycyn

The Android epub readers wander every which way and not always happily, either! Some totally toss publisher CSS out. Others have weird overrides. I downloaded one once, can't remember the name, but it was a relatively popular one, and it made all headings a particularly ugly GREEN color. Like why?

Another decided to override the default display for the <abbr> tag, setting it to display as a BLOCK ELEMENT rather than inline. Even if the tag was specified INLINE in CSS!

Some apps will ignore a semantic <hr/> rule, resulting in no scene break appearing. I try not to think about these apps. I don't want to believe people actually read books in them, yet obviously, it happens. 🤣

For me, Moon+ Reader is atrocious excuse for an epub renderer. To even get Moon+ to make some use of the epub's CSS, you end up digging down multiple menus. And yet, there is a rather vocal crowd proclaiming that it is the greatest thing since sliced bread and insisting any issues with Moon+ should be fixed by the epub publishers and not Moon+'s developers.

[Hitch]

Originally Posted by graycyn

But that's only Kobo. Not that I'm not in favor of them updating, mind you! All for it!

I think Nook is actually on an older version than Kobo is.

To the best of my general knowledge, that's right. My Nooks were blood brothers to ADE 2.x and to the first-gen of the then-iBooks, and I haven't seen them really update massively, either.

No proof, other than occasionally I've tried some bit of CSS that would be OK on Kobo (app and device) and bork in the Nook app.

Oh, yeah. Borking Be Common!

Hitch

[JSWolf]

And now B&N has taken away hyphenation from the nook.

[ZodWallop]

Originally Posted by JSWolf

And now B&N has taken away hyphenation from the nook.

That's been done. Now hyphenation on Nook is as bad as (default) hyphenation on Kobo.

[graycyn]

Originally Posted by JSWolf

Yes and it did work.

But, I've seen plenty of cases where things that could work, don't work because the code used is not correct for backwards compatibility.

Things like rem (instead of em) and vh/vw (instead of %) for example. The old software (for the foreseeable future) is not going away. So eBooks really do need to be made as compatible as possible.

I'm glad you gave it a try.

And I agree, there's enough devices out there that use an older Adobe RMSDK that backward compatibility is important. But that doesn't mean we always have to ignore code that isn't supported by older systems.

I mean, think about font-variant: small-caps! You can use it as a decorative element like a chapter lead-in where it's not critical mass that someone actually SEE the small caps. But if it is important that a word or phrase be emphasized in some way, then you need a different approach.

The CSS hanging-punctuation property is another example. It'll be ignored by most every reading system, old or new, but there's one exception, it is supported in Apple Books. And lots of folks have iDevices! So no penalty for using it, and some readers can enjoy the typography improvement.