[
https://issues.apache.org/jira/browse/SOLR-11584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244334#comment-16244334
]
Cassandra Targett commented on SOLR-11584:
------------------------------------------
I like this work so far - it makes it much more foolproof. The whole point was
to make docs easier instead of making writers/editors worry about display
issues and problems; this is a simpler convention that doesn't go too far away
from that goal.
In response to a couple of your questions/comments:
bq. the code currently assumes we always want the force the first {{tab-pane}}
to be the active tab pane/pill
I agree we should do this. It makes it simpler, and I think it would be an
expected default for readers.
bq. currently the code removes the tab label from the tab-pane itself – so the
text doesn't appear redundently when a tab is visible – but there's no reason
we can't leave it in if people think it looks better
I think a minor adjustment to the padding of the tabbed content box would make
it look fine without the tab label (I experimented with this, but am not
attaching a patch with it yet).
bq. the custom javascript is currently forgiving about tab panes that don't
have a tab-label in them anywhere and auto generates a label based on the
"number" of the tab
I think we should try to enforce that every tab-pane has a tab-label. We want
to make sure this looks right in the PDF, and I think making sure the sections
are labeled will help differentiate them.
>From your earlier comment, I think these were all the things that you said
>could be enforced with build-time validation:
* No tab has a {{active}} class, that will be done by default by the JS
* Every {{tab-pane}} has a unique ID
* {{tab-label}}'s are defined for each tab
Of those, the last 2 I think are most important. The JS could instead just
ignore an active class? Although since {{active}} is a real thing with real
rules in CSS not sure what else would break, so maybe better to just fail the
validation.
> Ref Guide: support Bootstrap components like tabs and pills
> -----------------------------------------------------------
>
> Key: SOLR-11584
> URL: https://issues.apache.org/jira/browse/SOLR-11584
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Cassandra Targett
> Assignee: Cassandra Targett
> Priority: Minor
> Fix For: 7.2
>
> Attachments: SOLR-11584.patch, SOLR-11584_customjs.patch,
> refguide-tabs.png, tabbed_api_output_example.png
>
>
> The theme I initially copied as the basis for the new Ref Guide included a
> Bootstrap integration, which has the potential to provide us with a number of
> options, such as organizing some content on a page into tabs (to present the
> same information in multiple ways - such as Windows vs Unix commands, or
> hand-editing schema.xml/managed-schema vs Schema API examples).
> However, the way AsciiDoctor content is inserted into a Jekyll template made
> it difficult to know how to use some of Bootstrap's features. Particularly
> since we have to make sure whatever we put into the content comes out right
> in the PDF.
> I had a bit of a breakthrough on this, and feel confident we can make
> straightforward instructions for anyone who might want to add this feature to
> their content. A patch will follow shortly with more details but the summary
> is:
> * Add an AsciiDoctor passthrough block that includes the Bootstrap HTML code
> to create the tabs.
> ** This has an {{ifdef::backend-html5[]}} rule on it, so it will only be used
> if the output format is HTML. The PDF will ignore this section entirely.
> * Use AsciiDoctor's "role" support to name the proper class names, which
> AsciiDoctor will convert into the right {{<div>}} elements in the HTML.
> ** These will take multiple class names and a section ID, which is perfect
> for our needs.
> ** One caveat is the divs need to be properly nested, and must be defined on
> blocks so all the content is inserted into the tab boxes appropriately. This
> gets a little complicated because you can't nest blocks of the same type
> (yet), but I found two block types we aren't using otherwise.
> ** The PDF similarly ignores these classes and IDs because it doesn't know
> what to do with custom classes (but in the future these may be supported and
> we could define these in a special way if we want).
> * Modify some of the CSS to display the way we want since AsciiDoctor inserts
> some of its own classes between the defined classes and the inheritance needs
> to be set up right. Also the default styling for the blocks needs to be
> changed so it doesn't look strange.
> I'll include a patch with a sample file that has this working, plus detailed
> instructions in the metadocs. In the meantime, I've attached a screenshot
> that shows a small snippet from my testing.
> While the focus here is using tabs & pills, we will be able to use the same
> principles to support collapsing sections if that's preferred for
> presentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
