[css-content] Need to clarify in-flow presentation implications for bookmarks

[drmacro]

In reference to the Editor’s Draft, 24 January 2018:

https://drafts.csswg.org/css-content/#bookmark-generation

The section on bookmarks does not indicate whether or not elements styled with bookmark-* properties are presented in the main flow as well as generating bookmarks.

I have both use cases in documents I am publishing now:

Case 1: Existing print ToC also produces bookmarks.
Case 2: PDF bookmarks must be different from print ToC

In Case 1 it is convenient to simply add bookmark properties to existing ToC elements. I'm using this technique with Antenna House Formatter today, for example.

In Case 2 the PDF bookmarks need to be different from the ToC in some way. In my case, the PDF bookmarks need to be more complete than the ToC, which only reflects the top 2 or 3 levels in the publication hierarchy.

I noticed note 20.

I would support requiring bookmarks to be generated from display: none elements. However, I can see that some users might complain that that prevents turning off bookmarks entirely by simply hiding the bookmark-generating structure.

A more complete solution would be to provide some type of "bookmark only" indicator. Typical markup practice would be to have a root element that then contains the bookmark-generating elements, e.g.:

<div class="bookmarks">
  <div class="bookmark" label="This is the first bookmark" target="#id-01"/>
  <div class="bookmark" label="This is the second bookmark" target="#id-02"/>
  ...
</div>

A property that could go on the .bookmarks div to indicate that it is used exclusively for bookmarks would address the requirement.

[faceless2]

I can't see any reason why display: none should prevent bookmark generation. This is how it works with all sorts of other document metadata: HTML <title> and elements affect the document regardless of their display value, and many of the most obvious cases for the CSS "string-set" property, such as setting a page header based on the document title or author, require it to apply even on an element with display: none.

Just because the element is not part of the visible node tree of the Document doesn't mean it should have no other effect.

I'm pretty sure AH and Prince both do this with string-set at least, as do we.

If there was a need to turn off bookmarks on a hidden section of the document for some reason, it's easy enough to add "bookmark-level: none" to the stylesheet as well as "display: none"

[drmacro]

In subsequent discussion with Tony Graham of Antenna House I realized that I had misunderstood the intent of the CSS bookmark feature, in that it is intended to be used as properties on the element being bookmarked, not as a way to generate a separate navigation structure that then links to the elements being bookmarked (which is how XSL-FO works and how Antenna House's CSS extensions allow you to create bookmarks).

So in the context of that understanding my comments are either non-sensical (in that if something was hidden you probably wouldn't want a bookmark for it.

The use cases the I have that drove this analysis cannot be addressed by this "bookmark as decoration of thing bookmarked" approach because in my case it will often be the case that the hierarchy of the HTML structure (e.g., sections) will not match the desired bookmark structure in one or more ways.

For example, sections that are peers may need to be reflected as a hierarchy or there may be levels in the hierarchy that need to be reflected in the bookmarks but that are not explicit in the source.

Another use case for bookmarks is including a generated back-of-the-book index (that is, something that would never reflect the actual order and hierarchy of the source) in the bookmark tree. This cannot be done through decoration alone.

So without a defined way to generate an arbitrary navigation structure that becomes bookmarks with links to the actual target source (as opposed to the elements that define the navigation structure itself) there is a whole host of bookmark use cases that CSS as currently defined cannot support.

I think this can be stated as there needs to be away to have HTML5-style navigation structures with links to the things being navigated to (for example, as used by the EPUB 3 standard) to generate PDF bookmarks.

In that case, the navigation structure may or may not also be rendered in the main flow (but usually it would not be). Here I have basically two use cases:

1. Given an in-flow table of contents have it serve also as the definition fo the PDF bookmarks
2. Use a completely separate navigation structure in the HTML that is not shown in-flow and produces the PDF bookmarks.