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

On 8/20/12 8:10 AM, "Simon Sapin" <simon.sapin@kozea.fr> wrote:

>Le 18/08/2012 00:21, Håkon Wium Lie a écrit :
>>   > 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?
>
>
>Yes, "generate a bookmark iff both are different from none" would be
>fine. Other variants could work too but my initial point was that the
>spec should say which combinations of value generate a bookmark or not.

I think that bookmark-level alone should determine if a bookmark exists or
not. Right now Prince and WeasyPrint will create bookmarks in PDF output
by default, with no user CSS at all. Prince, WeasyPrint, and AntennaHouse
will create bookmarks with only the bookmark-level property. Prince and
WeasyPrint will suppress bookmarks if bookmark-label is set to "none"
(AntennaHouse does not accept a "none" value).

I think the "none" value for bookmark-label is problematic. It doesn't
mean there's no label, it means there's no bookmark (you can't make a
bookmark in Acrobat without a label). Having the default for
bookmark-lable to be content() seems more consistent with user
expectations.

PDF formatters could have a user agent stylesheet that includes
bookmark-level for h1-h6 (or outline equivalent). Browsers may omit that.
Suppressing bookmark creation (for high-res PDFs for commercial printing,
for example) could be easily done with h1, h2, h3, h4, h5, h6 {
bookmark-level: none }. Authors wouldn't have to mess with bookmark-label
much, unless they wanted to use before | after | first.


>
>>   > >   > 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.
>>
>> What do you suggest the spec should say? (if anything)
>
>It could say something similar to the HTML5 spec for internal
>hyperlinks, or just reference it directly.
>
>http://www.w3.org/TR/html5/history.html#scroll-to-fragid:
>> When the user agent is required to scroll to the fragment identifier,
>> it must either change the scrolling position of the document using
>> the scroll an element into view algorithm defined in the CSSOM View
>> specification, with the align to top flag set, or perform some other
>> action, such that the indicated part of the document is brought to
>> the user's attention. If there is no indicated part, or if the
>> indicated part is not being rendered, then the user agent must not
>> scroll anywhere. [CSSOMVIEW]
>
>This, in turn, references CSSOM View:
>http://dev.w3.org/csswg/cssom-view/#scroll-an-element-into-view
>
>(There may not be an ID on a bookmark target, so the wording may need to
>be tweaked a little.)

I've added some text to the spec to convey this idea.

Dave



This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.

Received on Thursday, 7 August 2014 13:56:19 UTC