W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css3-gcpm] bookmark-label: keyword definitions and whitespace processing

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Sun, 03 Jun 2012 10:05:24 +0200
Message-ID: <4FCB1AC4.5010103@kozea.fr>
To: Brad Kemper <brad.kemper@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>
Le 03/06/2012 04:05, Brad Kemper a ťcrit :
>> If the values of bookmark-level are inconsistent (for example a
>> level 1 entry followed by a level 3, without a level 2 in-between)
>> the levels are adjusted somehow to make a proper tree without
>> "holes".
> I suppose that can be up to the UA, but it seems like it would not
> always be what the author intended, and may cause problems if the
> document is changing via script. I'd think that sometimes a level 2
> might be reserved for a label that is sometimes there in between a
> section heading and a chapter heading, but not for every section. I'd
> still want all the chapter headings to line up in the Table of
> Contents.

I agree this is better left (explicitly) undefined in the spec.

This example was especially pathological to show the problem. A more 
common use case we have is as follows:
h1 and h2 are a title and sub-title for the whole document. Only 
starting from h3 are the titles for sections. We only want to have 
sections in the TOC, so we disable the bookmarks for h1 and h2:

h1, h2 { bookmark-level: none }

Since there is no element with level 1 or 2 anymore, we want level 3 to 
become "top-level".

> I think part of my problem is that I am jumping ahead to thinking of
> how to style the TOC, and that isn't part of this spec. I realize
> that would often be outside of the control of the author, but perhaps
> sometimes not? I think a :toc pseudo-class would be nice for styling
> the actual bookmark tree.

 From here on I assume a CSS UA that produces PDF files to be opened in 
a variety of PDF viewers. I think this is the main use case for 
bookmarks, although Iím not excluding other use cases.

I just checked the PDF spec again. Each bookmark entry can have an RGB 
color, an "italic" bit and a "bold" bit. Of all the viewers I could test 
and that showed bookmarks at all, only Adobe Reader actually changed the 
color or font. Everything else just ignores these values.

Changing the bookmark color is probably a bad idea in general since (for 
PDF) there is no way to change the background. Italic or bold is more 
reasonable, but I canít think of a use case.

A ::toc or ::bookmark pseudo-element would be the most general mechanism 
to specify these in CSS, although only a few properties would have any 
effect there. The 'content' property of this pseudo-element could even 
replace bookmark-label. But in the end Iím not sure that the use case is 
worth the complexity of a new pseudo-element.

>>> The bookmark "target" is a single point. We picked the
>>> before-start corner (top-left in horizontal-tb ltr) of the margin
>>> edge of the first box/fragment generated by the element.
> This is still unclear to me. You mean that when you click on the
> element in the generated bookmark tree, then the H1 (or whatever) is
> scrolled into view, to be shown in the upper left corner?

GCPM doesnít say anything on this, but I guess that the intent is to 
scroll the element into view when the bookmark entry is clicked. In case 
the element is bigger than the viewport, I guess we want to show the 
"start" of the element.

Actually there is no elements this late in visual rendering, so it 
should be something like "the start of the first principal box generated 
by the element".

However, PDF files or viewers do not know about CSS boxes either. In the 
PDF spec, a bookmark target is an (X, Y) point on a page. In WeasyPrint 
we picked the top-left corner of the margin edge for that point.

>>> We did not implement bookmark-target because we did not
>>> understand what it is supposed to do.
> The example is confusing, given that it is a hyperlink. Perhaps it is
> for when you want the generated TOC to include some of the document's
> links to other documents.

The spec is really lacking here. Perhaps the original author can explain 
(or extend the spec.)

>>> (And bookmark-state because we did not need it yet.)
> This is for when the bookmark is like a disclosure element?

In most PDF viewers, each bookmark sub-tree can be "closed" to hide all 
descendants and make navigation in big documents easier. This is often 
controlled by a button on the left of the entry with a "+" when closed 
to expand, or a "-" when opened to collapse the sub-tree.

Simon Sapin
Received on Sunday, 3 June 2012 08:05:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC