Units and dimensions

[jwes]

When should I use which units for dimensions, e.g. should fonts be pt, em, px, in, ... ? What about margins or images?

[Turtle91]

This question has been addressed many times. You should be able to find multiple responses if you search the MR forum.

In general, use em for fonts/margins/indents so they are resizable by the user and maintain relative size with other items on the page... However, many advocate not specifying any size (in any dimension) for those at rely on the user setting. I think it depends on the device used by your target market, and prefer to set a default size that the user can then override if they desire. I highly advise against using any fixed size units (pt, px, in, etc.) as that looks absolutely horrible on anything except the device you are using when coding the ePub... eg if the user has a different size display or they use a different font size, etc.

I also tend to use % (or vh & vw) when defining image sizes or trying to limit an element based on the screen size or Viewing Height/Width.


Cheers,

[JSWolf]

If you need the eBook to be ePub2 compatible, do not use vh or vw as they are not ePub2 compatible.

[Turtle91]

Originally Posted by JSWolf

If you need the eBook to be ePub2 compatible, do not use vh or vw as they are not ePub2 compatible.

Every time you say something like this it proves you don’t pay attention to anyone’s posts.

Your statement is not true.

You simply need to use fallback coding.

CSS:
img {
  width:90%;
  width:90vw;
}

If your device app supports vw it will use it. If it doesn’t support it, it ignores it (as required by ePub spec) and “falls back” to the previous coding:90%

This is how CSS works, Jon. Please stop intentionally telling people things you know are incorrect.

[DNSB]

But what if your renderer is so borked that it does not ignore unsupported CSS?

Sorry but couldn't help myself. :

[Turtle91]

Originally Posted by DNSB

But what if your renderer is so borked that it does not ignore unsupported CSS?

Sorry but couldn't help myself. :

lol

Well, the current method (and reason we see 2 css files on many ePubs…thanks ADE) is to put the newer coding on a different style sheet…. If the device is so borked that it ignores the entire sheet then it still falls back to the older coding on the other sheet!

Users of those borked devices should get a refund for false advertising, as they are NOT meeting the ePub standard! Lol

To be fair to ADE they realized they screwed up and fixed that problem in their newer version… but they should update the software on those outdated, “borked”, devices.

[JSWolf]

Originally Posted by DNSB

But what if your renderer is so borked that it does not ignore unsupported CSS?

Sorry but couldn't help myself. :

That's the problem with the code for Standard Ebooks. They have CSS code (that's not needed at all) that RMSDK on a Kobo does not like and it throws out all of the CSS. If I'm not mistaken, it's a media query (don't know if it's one or more).

Your comment does make a sense.

[JSWolf]

Originally Posted by Turtle91

lol

Well, the current method (and reason we see 2 css files on many ePubs…thanks ADE) is to put the newer coding on a different style sheet…. If the device is so borked that it ignores the entire sheet then it still falls back to the older coding on the other sheet!

Users of those borked devices should get a refund for false advertising, as they are NOT meeting the ePub standard! Lol

To be fair to ADE they realized they screwed up and fixed that problem in their newer version… but they should update the software on those outdated, “borked”, devices.

I highly doubt we'll ever get Kobo to update RMSDK. So we most likey are always going to have to code for the old version.

[Turtle91]

Originally Posted by JSWolf

I highly doubt we'll ever get Kobo to update RMSDK. So we most likey are always going to have to code for the old version.

Yes....so use fall-back coding.....

Don't just give up and tell people it can't be done.....

[theducks]

Originally Posted by Turtle91

Yes....so use fall-back coding.....

Don't just give up and tell people it can't be done.....

I think you are ignoring:
Fallback encoding is INVALID, thus tossing the WHOLE CSS on some devices.
I know this to be true on my old EZReader 100% or none

[Turtle91]

Not ignoring, just not giving examples to cover every situation. The simple example I gave shows the concept of using css properties and techniques to code for different devices. There are other techniques, such as the multiple css sheets to cover for ADE’s non-compliant issues, or devices that gag on a particular sheet. Other techniques that have been addressed on other threads discuss using techniques like @media queries or @supports queries or even JavaScript to link the appropriate css file at runtime based on the capabilities of the device.

There are ways to overcome most of these issues. However, as DNSB mentioned, if your device is soooo borked up that it can barely turn itself on, let alone meet the ePub2 specification, then there really isn’t a need to code for them anymore. Keeping coders from using the current spec because someone, somewhere, might have a Frankenstein device that can’t run it is not logical.

Besides, my biggest point here is keeping the MR readers from giving up on finding a solution just because Jon doesn’t think anything exists beyond ePub2… there are solutions to 98.9% of these issues…

[RbnJrg]

Originally Posted by theducks

I think you are ignoring:
Fallback encoding is INVALID, thus tossing the WHOLE CSS on some devices.
I know this to be true on my old EZReader 100% or none

No, you didn't understand what Turtle91 wanted to say; in fact, the technique described by him is the best to deal with the ADE bug for epub2 ebooks. You need to employ TWO stylesheets; one of them is ONLY for ADE properties, the other one is for properties supported for Webkit/Readium ereaders. When ADE finds one property in the stylesheet for Webkit/Readium that doesn't like it, it will fully ignore THAT stylesheet BUT NOT ALL STYLESHEETS; the .css with ADE properties still will be honored by ADE. Watch the epub I attach and the .css I include; try opening it in ADE 2.x and in any other ereader not based on RMSDK; you'll understand better what I want to explain

[JSWolf]

Originally Posted by Turtle91

Every time you say something like this it proves you don’t pay attention to anyone’s posts.

Your statement is not true.

You simply need to use fallback coding.

CSS:
img {
  width:90%;
  width:90vw;
}

If your device app supports vw it will use it. If it doesn’t support it, it ignores it (as required by ePub spec) and “falls back” to the previous coding:90%

This is how CSS works, Jon. Please stop intentionally telling people things you know are incorrect.

Your fallback code does not work with the older RMSDK. The second width: is what's used and because ADE doesn't do vw, the wide: is ignored. Do you have a fallback that works? Given that % works, why use vw?

[Turtle91]

Read the thread.