HTML: in solutions and list-of, make a structural heading use span instead of hN

[Alex-Jordan]

As discussed at https://groups.google.com/g/pretext-dev/c/5uscyWjQ0cU/m/LX4uHU_dAAAJ, this changes the "headings" for structural divisions inside a "solutions" to use span instead of hN.

Actually it makes the mode="html-heading" template handle the situation when no $heading-level is passed to output a span. In case there are more situations where a "heading" should be a decorative span instead of a functional hN, this will help.

[rbeezer]

In case there are more situations where a "heading" should be a decorative span instead of a functional hN, this will help.

Can you list the existing situations where this is the case?

[Alex-Jordan]

The other case I am aware of is with "list-of" output (https://pretextbook.org/examples/sample-article/html/appendix-results.html), section titles should perhaps also stop being hN. But only after discussion. I haven't looked hard at those yet.

[rbeezer]

Thanks.

But only after discussion. I haven't looked hard at those yet.

I was going t merge this, but I can't tell if it is done then?

[Alex-Jordan]

For my part, this PR is ready and doing the same for "list-of" would be separate. Or if you think it's good there too, I could add that here.

[rbeezer]

Yes, list-of would be good. I misunderstood, I thought more might happen automatically with commit as-is.

While you are force-pushing. ;-) I try to avoid nested choose. Such as:

• Remove my bare "h" and incorporate as needed.
• First test could be $heading-level and ($heading-level < 7)
• Then two more, so span is still the (only) otherwise.

(And I'd wrap the span in an xsl:text for readability.)

[Alex-Jordan]

Here in a "solutions", the section headings are <hN class="heading hide-type">.

Here in a "list-of", the section headings are <hN class="heading" title="title-as-tooltip-text">.

We are about to make each of these undergo hN -> span.

Should they be the same with respect to .hide-type and title="..."? Other than these things, they have identical structure. I could probably consolidate some code if these can have the same structure.

FWIW, I lean toward not having the title and including the hide-type in both places. But that's just personal taste. Consolidating in some manner seems like a plus. Or maybe it is intentional to keep these things laid out differently.

[Alex-Jordan]

FWIW, I lean toward not having the title and including the hide-type in both places. But that's just personal taste. Consolidating in some manner seems like a plus. Or maybe it is intentional to keep these things laid out differently.

Maybe I lean toward having hide-type in both places, and then including the title, and it is a full title that shows the type (Section, Subsection, etc.).

[Alex-Jordan]

I just force pushed with changes.

New summary: create a "secondary-heading" modal template for making headings of divisions for use in places other than where they are born. Then use this modal template for headings of divisions in "solutions" and "list-of".

Collateral edit: as was the case before, a "Chapter" will show its type in these places. Since an "Appendix" is parallel to a "Chapter", I made Appendix show its type as well. Section, Subsection, etc do not show their type and just open with the number.

However some CSS editing is needed, @davidfarmer . Here is the sample article. This is built with chunk level 0, so be patient while it loads. In appendices F and G, we can see the types "Appendix" as well as "Section", "Subsection", etc. Possibly line 413 of pretext_add_on.css is no longer needed. Possibly line 413 can stay but should come before what is currently line 410. If @rbeezer approves the PR, one of those things (or soemthing else) shoudl be done.

[rbeezer]

Excellent! Thanks for pushing through on this one.

Yes, Chapters and Appendices should behave as much like each other as possible.

@davidfarmer: I'll update public sample article after one more PR, so you can work off that if you prefer.

[rbeezer]

Forgot to say. Just a small contribution to your XSL-fu. Definitely not necessary to change or anything.

Your outermost span of the commit could be literal, I believe (not xsl:element) even if it is necessary to make attributes programmatically with xsl:attribute (as it is here).

[davidfarmer]

Probably you don't want to hear this, but it is impossible to style those headings properly, with the current HTML.

This problem has always existed in the sample article -- I just never had to care about it before.

In appendices F and G there are consecutive elements which are headings. In come cases those are both top level headings (4 in a row in G), and in some cases one is top level and the next is second level (sect 4 and 4.1 in F).

How to style those two cases differently?

On Tue, 17 Aug 2021, Alex Jordan wrote:

I just force pushed with changes.

New summary: create a "secondary-heading" modal template for making headings of divisions for use in places other than where they are born. Then use this modal template for headings of divisions in "solutions" and "list-of".

Collateral edit: as was the case before, a "Chapter" will show its type in these places. Since an "Appendix" is parallel to a "Chapter", I made Appendix show its type as well. Section, Subsection, etc do not show their type and just open with the number.

However some CSS editing is needed, @davidfarmer . Here is the sample article. This is built with chunk level 0, so be patient while it loads. In appendices F and G, we can see the types "Appendix" as well as "Section", "Subsection", etc. Possibly line 413 of pretext_add_on.css is no longer needed. Possibly line 413 can stay but should come before what is currently line 410. If @rbeezer approves the PR, one of those things (or soemthing else) shoudl be done.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS orAndroid.[AABTULA2CUDHYJBSM6YKHJTT5K2URA5CNFSM5CIRLKC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJK TDN5WW2ZLOORPWSZGOGWW3CNA.gif]

[rbeezer]

Well, I did not get this totally right in LaTeX either. There's only so much mileage you can get from \Huge through \tiny, plus you may be starting at some arbitrary depth already.

I'm OK with every heading in a list-of or in a solutions being the same size.

Can you tell if a solutions (say) is at the level of a subsection or at the level of an appendix and drop the size of the headings down a notch? Or can we place such information that would make it possible?

[Alex-Jordan]

These headings (which are now spans) could say more about themselves using additional classes. They could say the heading level of their "parent" solutions or list-of. Or simply say they are "secondary" headings (which currently just means they are within a solutions or list-of).

It is trickier to actually have them say what their real heading level would be. We can easily get their heading level where they are born. But in a solutions or list-of, we need to know how deep they are relative to the scope of the solutions or list-of. So if every heading in these places can be styled the same without caring about depth, that does make it easier.

[davidfarmer]

Does 4.1 in Appendix F met your definition of "secondary"?

On Tue, 17 Aug 2021, Alex Jordan wrote:

These headings (which are now spans) could say more about themselves using additional classes. They could say the heading level of their "parent" solutions or list-of. Or simply say they are "secondary" headings (which currently just means they are within a solutions or list-of).

It is trickier to actually have them say what their real heading level would be. We can easily get their heading level where they are born. But in a solutions or list-of, we need to know how deep they are relative to the scope of the solutions or list-of. So if every heading in these places can be styled the same without caring about depth, that does make it easier.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS orAndroid.[AABTULCHS5MP4FWGTMM4DBDT5LOGRA5CNFSM5CIRLKC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJK TDN5WW2ZLOORPWSZGOGWXSE7Y.gif]

[Alex-Jordan]

Yes. And even "4" in Appendix F is "secondary". These are "secondary" because they are not really section 4 and subsection 4.1. I looked for a better work than "secondary" before running with that in the XSLT as a modal template name, but I couldn't think of something better. If you happen to see a good word for this idea of "not-where-born", I'd be happy to hear it and change that term.

[rbeezer]

recycled? repurposed?

"secondary" is fine for the code, but CSS classes might want something better.

[davidfarmer]

If "4" and "4.1" are marked up the same, then the problem has not been solved.

On Tue, 17 Aug 2021, Alex Jordan wrote:

Yes. And even "4" in Appendix F is "secondary". These are "secondary" because they are not really section 4 and subsection 4.1. I looked for a better work than "secondary" before running with that in the XSLT as a modal template name, but I couldn't think of something better. If you happen to see a good word for this idea of "not-where-born", I'd be happy to hear it and change that term.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS orAndroid.[AABTULHUHRFDKIIMPHWFM5TT5LS2VA5CNFSM5CIRLKC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJK TDN5WW2ZLOORPWSZGOGWXWE3Y.gif]

[Alex-Jordan]

It's been solved if you reclassify the problem as not being a problem :) Rob said:

I'm OK with every heading in a list-of or in a solutions being the same size.

I could try to encode an appropriate heading level as a class name. Do we feel that is worth doing?