oeb-page-head / oeb-page-foot
| Project: | EPUB Maintenance |
| Component: | Open Publication Structure (OPS) |
| Category: | task |
| Priority: | normal |
| Assigned: | BDuga |
| Status: | dismissed |
Jump to:
The current OPS specs support 2 values specific to OPS for the CSS2 "display" element: oeb-page-head & oeb-page-foot. As far as I can tell, none of the EPUB reading systems support these values and properly display an element in the header or the footer. These values are also problematic for the future of the EPUB format if we ever decide to use the upcoming CSS3 Paged Media Module, where the page model can support something very similar: http://www.w3.org/TR/css3-page/#page-terms Should we really continue to support these values in the specs ?
Description
Issue Id:
17
Resolution:
Dismissed, per comments.
- Login to post comments
Comments
#1
I view these display attributes are pretty fundamental to paginated presentation of content. These date back to OEBPS 1.2 and are supported by a number of Reading Systems. If/when we adopt portions of the proposed CSS3 Paged Media Model, we can map these innovations "forward."
We need to push Reading System vendors toward full specification compliance, not move our spec toward the lowest common denominator. We clearly need more tag P-elements! :-)
#2
While Adobe does not currently support these display values, certainly this is a much simpler thing to do than CSS3 Paged Media Module. In general I would point out that use of CSS while understandable is not a particularly good choice for a book layout engine. I would need to be convinced to take on almost any of the CSS3 modules as they stand today in general and Paged Media Module in particular.
#3
I'm not going to start a discussion about XSL-FO vs CSS, and I believe that it's pretty obvious which side you're on Peter.
I agree with Garth that we should encourage reading systems to fully support the specs, and could map both oeb-page-head and oeb-page-foot to something else in the future.
On the other hand, I wonder how useful these properties really are. Based on the specs, they would work pretty well to display the name of the current chapter in the header, but for footnotes they're a bad idea. Sure, we should encourage reading systems to support every property, but I consider that it is also a best practice to design solutions with a proper fallback.
The target_move() from the CSS3 Generated Content for Paged Media module enable content providers to create footnotes using links to a non-linear flow as a fallback when the reading system doesn't support CSS3. With oeb-page-foot, the fallback would display the note inline with the text (ugly).
From my perspective, they're not fundamental to paginated presentation of content, mostly because they're too limited. I'd like to have something more powerful than oeb-page-head & oeb-page-foot as soon as possible...
#4
Yes they are very limited for the author, but not terribly expensive to implement and they capture at least some sematics. I would rather do footnotes with a special display property as well, especially given that in interactive environments "pop"-note may be a better way to implement it. We'll save that topic for the next spec cycle, this is clearly a new feature.
In this cycle I think this issue should be just closed.
#5
I am going to have to side strongly with the "keep them" camp. I have tons of content that use them. In fact, just about every piece of content I have seen for the last 10 years or so makes use of them. OK, maybe we didn't have them 10 years ago, but their vendor-specific variants were being used instead. I agree that they are not well suited to footnotes and having a new mechanism for such a beast wouldn't be a bad idea, but I am not aware of any CSS property (current or proposed) that takes their place for doing running headers (especially being able to swap headers/footers mid-stream).
#6
At the call today there was general agreement to reject removing oeb-page-head/foot. Per our policy, I am posting a potential resolution to dismiss this request. There may be room to add a new request for dealing with footnotes, but that needs a new report. Pending objections, this issue will be dismissed in 1 week.
#7
Can be turned into a different issue marked as future direction: supporting footnotes and other advanced content that need to be displayed in a special way.
#8
Since there is no disagreement on the issue of keeping these elements, the issues is being dismissed.