hN depth within "solutions"

[Alex Jordan]

One source of too-deep headings (headings whose proper depths should
be 7 or greater) is a "solutions" like the one here:

Solutions 4.2.7: Solutions for This Subsection
https://pretextbook.org/examples/sample-article/html/interesting-corollary.html#solutions-subsection

As a "solutions" within a subsection, the "solutions" itself is
already at depth 4.

Within that "solutions", you have the marker for each subsection (like
for 4.2.3) at depth 5. Then the solution to checkpoint 4.10 at depth
6. And then tasks at depth 7, and subtasks at depth 8.

I have been looking at this and looking at the heading tree that the
headingsMap Firefox add-on reveals. I have two separate proposals:

1. The marker for divisions within the "solutions" could be cosmetic
and omitted from the heading tree (meaning, replace its hN with a
span). Mainly, it's confusing to be navigating the heading tree and
reach this item that says "4.2.3 Advice" but it's not really
subsection "4.2.3 Advice". It's just the solutions to things that were
in that subsection. It seems like if all heading children of the
"solutions" were the actual things with solutions (the exerciss, the
projects, etc), that would be a good use of headings. And a nice side
effect would be cutting down depth from the heading tree.

2. Only print terminal tasks within the "solutions". So in that
solution to checkpoint 4.10, instead of showing task (c), subtasks (i)
and (ii), and task (d); only have items (c.i), (c.ii), and (d), all
at the same heading tree depth. This would flatten all tasks and
subtasks down to just one level of depth below the depth of the
containing exercise.

These are independent proposals, and implementing them may be tricky.
Putting implementation aside, how do we feel about each one?

[David Farmer]

> 1. The marker for divisions within the "solutions" could be cosmetic
> and omitted from the heading tree (meaning, replace its hN with a
> span).

Changing it to a "span" should have no effect on the visual appearance.
(If it does, tell me and I'll fix it.)
So, seems to have no negatives for appearance, and a positive
for accessibility.

[Rob Beezer]

There is significant, very complicated code, to support the wide variety of
places exercises can land, such as inside a column of an exercise group inside a
subexercises within a solutions. So there is a lot of effort to have any such
exercise use as much common code as possible.

So a label like (c.ii) makes a lot of sense, but now nesting and indentation go
away, plus those same changes need to migrate to the LaTeX conversion also
(tcolorbox) since numbering is isolated in -common to ensure consistency.

Yes, I'm ignoring your request to ignore implementation. ;-)

This seems to be a deficiency in the structure made available by HTML, so maybe
changes should focus on HTML structure, and not the *content* of an exercise.
Which would ssuggest not bleeding into -latex and -common? So maybe more of (1)
and less of (2)?

Rob

[Alex Jordan]

Looking again at Checkpoint 4.10 (within this solutions)
https://pretextbook.org/examples/sample-article/html/interesting-corollary.html#solutions-subsection
does it make sense to consider not using hN at all on tasks and
subtasks? So only "Checkpoint 4.10" would be in the heading tree, with
no descendents. If we know we are inside a "solutions", does it make
sense to simplify the heading tree in that way?

As with the other thing from this thread (which is now in
https://github.com/rbeezer/mathbook/pull/1580) it would just replace
the hN with a span. If styling is just based on .heading, then styling
would not be affected.

> --
> You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/d375034a-ce49-49ba-05c7-703e6f9abfaf%40ups.edu.

[Rob Beezer]

#1580 is merged. I'd guess fewer hN inside a "task" would be fine, but I think
that is your call. Not clear to me what is better for accessibility.