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

Also sprach Simon Sapin:

 > >   > 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
 > >    }
 > 
 > You mention below that h1..h6 get a bookmark-label value in the HTML UA 
 > stylesheet. I think it’s hard to generate a bookmark if bookmark-level 
 > is none. Where would you put it in a PDF outline tree, for example?

It could be level 1. (In which case we might as well make the initial
value 1 instead of none.)

Or we could say that, in order for a bookmark to be generated, both
'bookmark-level' and 'bookmark-label' must be different from 'none'.

This will allow UAs and authors to use any switch they want, no?

 > >   > 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?
 > 
 > Yes. This is what I implemented, but it could change.
 > 
 > > I'd probably suggest always processing white-space as if 'white-space:
 > > normal' had been set on the label.
 > 
 > I don’t see a strong argument either way. 'normal' is the initial value 
 > so headings rarely have another value for white-space anyway.

I could see the value of 'white-space' change for effect in the
document without wanting a similars effect in the outline (where space
is more precious). So, I suggest adding this to the definition of <content-list>:

  The textual content is processed as if 'white-space: normal' had been set. 


 > >   > 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.
 > 
 > If no bookmark is generated by default I agree that it is interesting 
 > for authors not to have to specify levels explicitly. But in WeasyPrint 
 > we chose to have h1..h6 generate bookmarks by default. (Again, nothing 
 > set in stone.) In that case, opting-out is also easy:
 > 
 >      /* Limit bookmarks to 3 levels */
 >      h4, h5, h6 { bookmark-level: none }

Yes, turning off is easy. This is compatible with my proposal above.

 > >   > 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.)
 > 
 > I was only describing our implementation. I think it is good to leave 
 > such details unspecified so that implementation can but do not have to 
 > make a smart algorithm for broken pages.

Ok.

 > >   > 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?
 > 
 > Actually I switched from margin box to border box after writing the 
 > quoted emails:
 > 
 > http://lists.w3.org/Archives/Public/www-style/2012Jun/0318.html
 > 
 > I do not know of a browser that implements bookmarks, but the closest is 
 > internal hyperlinks. Apparently browsers scroll the top of the *border 
 > box* to the top of the viewport (assuming a box far enough from the top 
 > and bottom of the document.) Horizontally things are more subtle. If the 
 > box is narrower than the viewport, browsers scroll horizontally as 
 > little as possible so that the whole width of the border box is visible.
 > 
 > But in PDF we do not have such fine-grained control: the targets for 
 > outlines and internal hyperlinks is a single (X, Y) point on a page.

What do you suggest the spec should say? (if anything)

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

Received on Friday, 17 August 2012 22:21:53 UTC