[
https://issues.apache.org/jira/browse/SOLR-10612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10612:
----------------------------
Attachment: SOLR-10612.patch
bq. But, maybe there is some stuff we could do with JS and/or the liquid
template with a new param and/or CSS. I'm not throwing away the idea, just one
of the obvious ideas probably isn't workable.
We definitely have a lot of flexibility with the liquid templates and hte
javascript generated toc...
bq. I've attached a patch that introduces a new layout called "largepage" ...
From my initial testing, this pretty much breaks any "responsive" layout we
might have previously achieved on small screens, so it's not perfect.
One possibility is to better lerage CSS features to do this?
i've updated your patch to replace the new layout with a small conditional in
the existing toc.html, that adds a CSS class to the toc based on a page
variable ({{:page-tocclass:}}), and then updated ref-guide.css to have a
"toc-right" class that uses {{float: right}} ... this looks better on some
pages (the contents flows around it so the main content isn't a single narrow
column) but has issues with things like {{<pre>}} tags that overlap it ... my
CSS-fu isn't strong enough to know how to make them play nicer w/eachother.
FWIW: This patch also tweaks the javascript for generating the toc so that
{{:page-toclevels:}} can be used to determine what headers to use in the TOC
(wherever it's placed)
----
Another idea to consider is that the TOC javascript isn't fundementally tied to
building it's TOC outside of the main content, or even (AFAICT) limited to
single TOC for the entire page. If we can use/abuse an (existing or new)
asciidoctor macro to generate some placeholder HTML where we want the TOC to
be, the javascript can put the TOC in that place ... we could even make the
javascript wrapper code smart enough that if there were multiple macro
instances in the page body, we could generate multiple TOCs with diff options
-- ie: if {{solr_custom_toc::[]}} could cause something like {{<div
class="solr_custom_toc"/>}} in the final output (or better still:
{{solr_custom_toc::\[whatever\]}} => {{<div class="solr_custom_toc"
data-solr="whatever"/>}}) then we could use the {{toc.js}} in a way that would
build the TOC at that exact spot, and we could (optionally) limit it to only
build the TOC for the current "subsection" -- either based on page varibales,
or based on the "whatever" data from the macro.
So for example: we could build a very small "toclevels==1" toc at the top of
{{streaming-expressions.adoc}} and then each of the 2 big sections could have
"In this section" TOCs listing just the subsections (which we could style
differnetly, or use javascript tricks to collapse by default and require you to
click on them to expand, etc...)
[~ctargett]: do you know of any simple macros we could use/abuse to generate
some arbitrary HTML?
> make ':toclevels:' work in our jekyll templates
> -----------------------------------------------
>
> Key: SOLR-10612
> URL: https://issues.apache.org/jira/browse/SOLR-10612
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: lang-analysis-1-level-toc.png,
> solr-10612-largepage.patch, SOLR-10612.patch
>
>
> asciidoc has a concept called {{:toclevels:}} which is suppose to determine
> which how deep down a page's section/header depth the generated table of
> contents will show -- ie: some LONG pages have a huge number of level 2
> headings, and on those pages we only want to show level 1.
> but in jekyll, asciidoctor isn't responsible for generating the TOC --
> instead it's done by some javascript (which is better for a variety of
> reasons) and at the moment this javascript doesn't know anything about
> {{:toclevels:}}
> But it should be possible to tweak our rendering templates to include
> {{:toclevels:}} as an attribute in the generated HTML, and then we can tweak
> the javascript call made to generate the TOC so that it respects it on a
> per-page basis
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
