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

Also sprach Simon Sapin:

 > Quoting http://dev.w3.org/csswg/css3-gcpm/#bookmarks
 > 
 > > Some document formats have the capability of holding bookmarks.
 > > Bookmarks are typically shown outside the document itself, often a
 > > tree-structured and clickable table of contents to help navigate in
 > > the electronic version of the document.
 > 
 > Bookmarks are called outlines in the PDF spec. They are organized in a 
 > tree structure. Each entry has a textual label and points to a specific 
 > position in the document encoded as (page_number, X, Y). Clicking makes 
 > the viewer display the document at that position.
 > 
 > The GCPM spec is indeed lacking on details. This is how we filled the 
 > blanks when implementing it in WeasyPrint:

The GCPM has been sketchy and I appreciate your efforts to fill in the details. 

 > For each element where the computed value of neither bookmark-level or 
 > bookmark-label is 'none', generate a bookmark entry. 

Isn't is sufficient that 'bookmark-label' is different from 'none'?

In a simple book with several consecutive chapters, you'd want to say:

  h2 { bookmark-label: contents }

And not having to say:

  h2 { 
    bookmark-label: contents; 
    bookmark-level: 2 
  }

 > The used value of 
 > bookmark-label is as described for the string-set property, with the 
 > text taken *after* white space processing (according to the white-space 
 > property.)

According to the white-space value of the element in question? 

I'd probably suggest always processing white-space as if 'white-space:
normal' had been set on the label.

 > By the way, I think that the initial value of bookmark-label should be 
 > 'contents', not 'none'. Actually I’m not even sure that 'none' is ever 
 > useful. 'bookmark-level: none' (the initial) is enough to say "this 
 > element does not generate a bookmark".

I agree that 'bookmark-level' can be used as the on/off switch for
bookmarks, but I'd probably prefer to use 'bookmark-label' as the
switch. This way one can have (say) this in the default style sheet:

  h1 { bookmark-level: 1 }
  h2 { bookmark-level: 2 }
  h3 { bookmark-level: 3 }

without triggering the generation of bookmarks. Bookmarks can then be
switched on with:

  h1, h2, h3 { bookmark-label: contents }

(or something)

Thus, one can turn on bookmarks with one declaration rather than
having to use (and remember) many levels.

 > bookmark-level specifies what "depth" this entry is supposed to be at, 
 > in the bookmark tree. The UA stylesheet for HTML has something like this:
 > 
 > h1 { bookmark-level: 1 } /* ... */ h6 { bookmark-level: 6 }
 > 
 > The order of the generated bookmarks is always the same as the tree 
 > order of the corresponding elements. 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".

This requires more intellingence than we should expect from
implementations, no? (A similar rule for elements would convert all h3
elements into h2 if no h2 element was found.)

 > 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.

That seems reasonable. Is this what browsers do?

 > We did not implement bookmark-target because we did not understand what 
 > it is supposed to do. (And bookmark-state because we did not need it yet.)

Ok. 

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 16 August 2012 14:00:02 UTC