电子书的CSS API

或者，我只是想避免使用“微格式”一词，因为人们不想听到这个肮脏的词，因为它可以解决很多CSS问题。

API代表应用程序编程接口。 它只是用于构建软件和应用程序的一组定义，协议和工具。 基本上就像乐高：提供了构建块，您只需将它们放在一起即可。

是的，也许“ CSS API”是牵强的，因为我们绝不是在谈论软件和应用程序，但我想您可能至少掌握了驱动它的精神。

为什么，为什么呢？

不管我们是否喜欢，＃eprdctn都是一只奇怪的野兽：虽然有点像webby，但它也带来了自己的挑战。 哦，男孩，这些挑战是顽固的……

• 您需要DRM保护的电子书的6个理由
• 手工质量软件2.0
• 使用Markdown为Kindle和iBooks创建电子书格式文件
• 可以防止（甚至只是管理）电子书盗版吗？
• 电子书注定要失败吗？

首先，您需要处理所有这些渲染层（即分页）。 而且，由于在网络环境中进行分页是一种糟糕的做法，因此一团糟。 经常使用CSS 3列，但始终缺少其实现，有时只是简单地更改文件以进行分页等等。

然后，您将获得所有这些默认CSS及其替代，所有这些显然都没有记录。 不用说，某些覆盖是通过JavaScript动态应用的，这使得调试更加困难。

最终，您得到了中等程度的CSS支持，例如，如果您进行分页，我可以保证人类无法应对您不支持整套“无论页面中断”的想法。 更糟的是，由于RS去YOLO进行分页，所以可能会破坏工作原理。

那么，如果我们使每个人都更轻松呢？

而且我知道，考虑到RS开发人员和电子书作者之间的关系，这听起来像是个疯狂的主意，有时看起来像是一场战役……

但是事实是，阅读系统开发人员比我们以往拥有对渲染的更多控制权。 因此，它们是解决方案的一部分。 🙂

哦，怎么样？

假设您正在编写非小说类电子书……恭喜！ 你的生活真可怕。

为什么？ 因为您必须处理图像。

阻碍流程的数字…

带字幕的数字…

您希望浮动的数字不会浮动在狭窄的列中，但是由于媒体查询已损坏，因此您无法可靠地做到这一点……

具有人像宽高比的图形…😱

具有纵向宽高比和标题的图形。 😭

不好，真的很不好。

似乎由于某种未知原因，一些阅读系统开发人员认为所有数字均为横向宽高比，没有标题。 他们将根据该假设进行覆盖…

¯\ _（ツ）_ /¯

亲爱的网络专家，如果您不知道情况有多糟，请通知我们，我们无法确保将图形及其图形说明显示在所有页面的同一页面上。

那么……如果我们共享一组通用的构建基块怎么办？

喜欢说

要么

要么

或者，让我们一起去YOLO TO THE MAX

这样对每个人都容易吗？

1. “全出血”表示图像应适合页面，同时保持其宽高比（将用于……例如……覆盖图像）；
2. “风景标题”表示应实施“闯入：避免”，以便图中的两个相关元素保持在一起并显示在同一页面上；
3. “人像字幕”表示图像不应为全高，并且必须为该字幕保留一些空间（将空白全部带给Reading Systems）；
4. “宽度–70”表示如果可能，图像应为宽度的70％。
5. “ height–80”表示如果可能，图像应为高度的80％（或80vh）。

是的，它基本上是在为阅读系统描述图形，然后依次对它们进行样式设置。

什么什么

如果一分钟考虑一下，这不只是数字。

假设您使用这个

BOOM，现在RS知道有一个边框，他们要么提供一个默认边框，要么使用它在夜间模式下覆盖边框颜色，这是他们目前不做的事情。

现在，如果…

和

和

和

  
  
   
 如果您根本不需要CSS，那会很棒吗？ 
 我的意思是，如果您不想这样做。 明显。 
 如果可以导致交互式小部件怎么办？ 如… 
   
 实际上，应该更像这样…… 
   
  “ data-epubWidget”是“交互式弹出式触发器”，“ class”是静态后备。 
 也许它不能在任何地方都有效，但是，嘿，至少您可以通过对其样式进行“优雅降级”。 
 利弊 
 我说实话，这并不完美。 毕竟，在现实生活中没有完美的事物，因为纯理论无法经受时间的考验…… 
  优点： 

确认电子书具有网络不一定要处理的特定问题（因为默认情况下未分页）； 
 越简单越好：您可能讨厌这个想法，但是每个人都知道如何“分类”，这对于其他任何事物都不一定是正确的； 
 如果您不想使用类，则可以将逻辑框架应用于其他任何对象（数据属性？）； 
 您仍然可以设置这些类的样式（例如，对于不提供此“ CSS API”的RS）； 
  RS级别的一致性； 
 创作软件级别的一致性（开发人员可以为用户提供一组预定义的电子书样式）； 
 如果CSS是绝对废话，则可以全局覆盖它； 
 阅读系统+创作软件可以为用户提供电子书主题（等待）（开发人员和作者都有额外的现金机会）； 
 您可能讨厌作为电子书作者的想法，但是覆盖将容易得多。 

  缺点： 

 是的，客观上来说，它是一种微型格式，我知道您不想听到这一点； 
  RS中有多余的东西（可能不会指定）； 
 如果RS中存在错误，则每个人都会受到影响； 
 性能影响（???）; 
 可能应该“加上前缀”，因为可能会产生附带损害； 
 您可能会恨我，因为在EPUB 3.1试图摆脱任何特定于电子书的东西的情况下，感觉就像是创建特定于电子书的“ API”的建议。 

 有什么想法吗？