search

snaekobbi / pipeline-mod-braille

ARCHIVED. Please don't make any new issues or pull requests in this repo.
0 stars 0 forks source link

Support volumes #13

Open bertfrees opened 9 years ago

bertfrees commented 9 years ago

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

dkager commented 8 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.

bertfrees commented 8 years ago

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

dkager commented 8 years ago

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.

bertfrees commented 8 years ago

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.

bertfrees commented 8 years ago

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.

dkager commented 8 years ago

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?

dkager commented 8 years ago

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.

bertfrees commented 8 years ago

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.

dkager commented 8 years ago

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.