W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2020

Re: [csswg-drafts] [css-content] Generation of bookmarks from CSS is not defined (#204)

From: Mike Bremford via GitHub <sysbot+gh@w3.org>
Date: Sat, 18 Apr 2020 11:35:20 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-615847841-1587209719-sysbot+gh@w3.org>
I agree with @dauwhe that the current specification for bookmarks is complete, works, and is widely implemented.

However I do have a beef with the syntax, which is that bookmark levels have to be specified explicitly. All the examples look a bit like this:
```css
section h1 { bookmark-level: 1 }
section section h1 { bookmark-level: 2 }
section section section h1 { bookmark-level: 3 }
section section section section h1 { bookmark-level: 4 }
section section section section section h1 { bookmark-level: 5 }
```
which is a little absurd. If we were specifying this for the first time now that's not the approach we'd take, but we're stuck with it due to shipping implementations. But can we augment this to make managing large documents, in particular those assembled from multiple smaller ones before processing, a little easier?

I'd like to propose changing the syntax from
```
bookmark-level: none | <integer>
```
to
```
bookmark-level: none | <integer> | add(<integer>)
```
With "add" being defined as "add the specified value to the bookmark-level of the nearest ancestor that has a value other than "none". If no such ancestor exists, the values is added to 0"

This would allow you to change the structure above to
```css
section { bookmark-level: add(1); bookmark-label: none }
h1 { bookmark-level: add(0); }
```

It's slightly complicated because `bookmark-level` is not an inherited property, and `bookmark-label` doesn't default to none. So you can't rely on the normal inheritance mechanism. But traversing up the tree is something we do elsewhere (i.e. the concept of the _decorating style_ for underlining), and this syntax is has precedence too (the proposed [math-script-level](https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property) property, which I believe is largely accepted.

Finally, existing implementations will simply not recognise this syntax as valid, and ignore it - the "legacy" explicit levels can exist earlier in the same stylesheet, as a fallback.

Values of `add(-1)` or `add(99)` woudn't make much sense, but as they collapse to an integer value their behaviour is already specified.

-- 
GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/204#issuecomment-615847841 using your GitHub account
Received on Saturday, 18 April 2020 11:35:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:09 UTC