Conditional rendering for reading systems
| Project: | EPUB Maintenance |
| Component: | General |
| Category: | feature request |
| Priority: | normal |
| Assigned: | GConboy |
| Status: | future consideration |
Jump to:
A destination reading device or system may influence how an OPS stylesheet or content document is authored; for example it can be desirable to adapt both XHTML and CSS documents to account for the maximum screen resolution of a device when calling a full-page image.
Naturally this becomes problematic when an ePub document is bound for destination devices with differing hardware specifications.
It would therefore be beneficial for the OPF/OPS specifications to support conditional elements in stylesheets and/or content documents. Dependant on a reading systems support for certain pre-defined parameters the most appropriate rendering would be used.
Comparable support exists in both OPF/OPS specifications in relation to “additional” media-types and the corresponding fallback instruction and OPS switch vocabulary.
Description
Issue Id:
34
Resolution:
Proposed resolution for moving to "future direction" -- this likely an important area for development in the next version of the specification.
- Login to post comments
Comments
#1
I agree, this is very important and we should probably get to it sooner rather than later to avoid incompatible implementations. Unfortunately, this is almost certainly *not* something we can do in errata. It will likely need to be moved to future consideration.
#2
This is not only a issue for CSS rendering. Supported character set and glyphs also influence to ePub creation.
Then, it need to be moved to future consideration with these items.
#3
Just for the record: Adobe XPGT stylesheets support conditional and computed styling using XPath expression syntax. It can be used as a foundation for this feature.
#4
That is certainly one of many possible approaches. We might also consider the more widely implemented media query approach. In any case, this is clearly something we will want to dive into in some depth when we decide to deal with the issue. For the time being, I agree that this should be moved to future directions for later discussion.
#5
#6
Proposed resolution for moving to "future direction" -- this likely an important area for development in the next version of the specification.
#7