Open bertfrees opened 9 years ago
Any examples of how to use http://snaekobbi.github.io/braille-css-spec/master/obfl.html in practice? In particular, where would you put -obfl-toc
.
What I'm missing there as well is a way to generate the TOC layout in the first place, i.e. toc-entry
.
This is what I had in mind with the -obfl-toc
display value and the -obfl-toc-range
property (let's ignore the ::-obfl-toc-group
pseudo element for now):
<body>
<section class="frontmatter">
<ul class="toc">
<li>
<a href="#section_1">...</a>
</li>
<li>
<a href="#section_1">...</a>
</li>
</ul>
</section>
<section class="bodymatter">
<h1 id="section_1">...</h1>
<p>
...
</p>
<h1 id="section_2">...</h1>
<p>
...
</p>
</section>
</body>
ul.toc {
display: -obfl-toc;
-obfl-toc-range: document;
}
ul.toc li {
display: block;
}
ul.toc li a::after {
content: ' ' leader('⠒') ' ' target-counter(page, attr(href));
}
The idea is to automatically detect the li
elements as the toc entries by inspecting the references they contain (in this case target-counter(page, '#section_1')
and target-counter(page, '#section_2')
).
OK, so ignore toc-entry and its functionality? Also, this implies you have a TOC that is formatted like a list, as opposed to automatically generating the TOC for a braille volume based on e.g. the levels and headings structure.
I can help you with the detection by the way, it's not very straightforward to do in XSL and I have done a similar thing before.
To be clear: the toc-entry
OBFL elements should be generated by us.
This indeed implies you already have a TOC. Automatically generating the TOC is a feature we can add later but doesn't necessarily have to done with CSS. See also https://github.com/snaekobbi/sprints/issues/69#issuecomment-157804658.
Would it not be more straight-forward to do -obfl-toc-entry { // all the attributes go here name: foo } ul.toc li { -match-obfl-toc-entry: foo }
Or something similar?
Here is part of a TOC as an example of how Dedicon marks this up (from a randomly selected book):
<level1 id="l-2" class="print_toc">
<pagenum page="front" id="page-2">2</pagenum>
<list type="pl" class="toc">
<li><lic class="entry"><strong><em>Winter</em></strong></lic>
<list type="pl">
<li><lic class="entry">Modeshow</lic> <lic class="pagenum">25</lic></li>
<li><lic class="entry">Een bot</lic> <lic class="pagenum">28</lic></li>
<li><lic class="entry">Held op poten</lic> <lic class="pagenum">30</lic></li>
<li><lic class="entry">Ho, ho, ho!</lic> <lic class="pagenum">33</lic></li>
<li><lic class="entry">Vuurwerk</lic> <lic class="pagenum">35</lic></li>
</list></li>
<pagenum page="front" id="page-3">3</pagenum>
<li><lic class="entry"><strong><em>Lente</em></strong></lic>
<list type="pl">
<li><lic class="entry">Een beetje verliefd</lic> <lic class="pagenum">41</lic></li>
<li><lic class="entry">Ballon</lic> <lic class="pagenum">44</lic></li>
<li><lic class="entry">Heel veel vriendjes</lic> <lic class="pagenum">46</lic></li>
<li><lic class="entry">Een vreemde eend</lic> <lic class="pagenum">48</lic></li>
<li><lic class="entry">Een luie dag</lic> <lic class="pagenum">51</lic></li>
</list></li>
</list>
</level1>
This would be printed unaltered. I don't think it makes sense to abstract a braille TOC from this.
From a user perspective I would like to keep the CSS as simple as possible, and the system as smart as possible. Your proposal might be more straightforward from an implementation point of view (maybe), but for the user the name
should be invisible. All the user cares about is that he can set the "TOC range".
Thanks for the Dedicon example TOC. If this is printed unaltered it does indeed not make any sense to mark it as -obfl-toc
.
Yes, the user will only care about the TOC range. My idea was to provide a sort of template for toc-entry’s. I guess this could go into a toc at-rule. Will elaborate on this tomorrow.
Support the CSS features described in the section Volumes.
See pull request: https://github.com/daisy/pipeline-mod-braille/pull/61
To do:
Depends on