HTML: suppress permalink on first p in introduction to an exercisegroup

[jjrsylvestre]

Title says it all.

[rbeezer]

Thanks for catching this one, @jjrsylvestre.

No guarantee the first element of an introduction will be a p, though it is highly likely. I think this (dealing with run-in headings) is handled elsewhere in CSS. Review coming just now from my assistant. Pinging @ascholerChemeketa since this involves CSS.

[rbeezer]

Reproduced on the sample article, and your diagnosis holds — thanks for chasing this one down.

What causes it. The overlap is a run-in heading, not a permalink bug. In css/components/chunks/_exercises.scss, .exercisegroup > .heading is display: inline, and when that heading is followed by an introduction, the introduction and its > .para:first-child go inline as well. An absolutely-positioned child of a relatively-positioned inline box is placed against the bounding box of that inline's line boxes, and the first line box begins immediately after the run-in heading text. So .autopermalink { top: 0.5ex; left: -2em } lands the icon back on the heading's last characters — the "s" you were hovering.

Your open question — "might depend on whether a title is present?" It does not. An untitled exercisegroup still emits an <h3 class="heading"> carrying the type name ("Exercise Group."), so the run-in, and the overlap, apply to every exercise group that has an introduction. Suppressing unconditionally is the right call.

Suggestion: make the fix in CSS rather than XSL. The project already answers this exact question in one place — css/components/elements/_permalinks.scss hides the permalink on a container's first paragraph, and on the first paragraph of its introduction:

.axiom-like, .example-like, .exercise-like, .solution-like, .assemblage-like,
.definition-like, .remark-like, .project-like, .openproblem-like,
.computation-like, .theorem-like, .proof, .case, li, dd {
  > .para:first-of-type > .autopermalink { display: none; }
  > .introduction > .para:first-of-type > .autopermalink { display: none; }
}

.exercisegroup is simply missing from that list. Adding it there is a one-word change that sits next to the rule creating the problem, and keeps the decision in a single layer instead of splitting it between the stylesheet and the XSL.

It also makes the suppression track the actual condition. The run-in fires only when the paragraph is the introduction's first child; the XSL match is p[1], the first p wherever it sits. An introduction may open with an image, a sidebyside, a list or a sage and put its paragraph second — no run-in there, no overlap, but the current patch removes the permalink anyway. .para:first-of-type and > .para:first-child agree in that case, so the CSS route needs no special handling.

(No need to regenerate anything under css/dist — that is a maintainer step.)

Two more places with the same defect, if you want to sweep them in.

• .discussion-like (context, discussion, opinion, status, suggestion) takes a run-in heading from inline-heading-mixin via css/components/chunks/_discussion-inline.scss, which default-modern, salem, greeley, tacoma, ebook and print-worksheet all include. In the sample article, the status element on the open-problems page has an h3.heading followed by a .para that still carries its autopermalink. Adding .discussion-like to the list above covers it.
• Front matter abstract (and keywords, support) runs its title in the same way — css/components/elements/_front-matter.scss sets > .title + .para { display: inline }. The sample article's abstract shows the same overlapping permalink.

One consequence worth naming: legacy themes compose from css/legacy/ alone and never see css/components/, so they carry the same run-in with no suppression and will keep the overlap. That is fine — they are on their way out.

Claude Opus 5, acting as a review assistant for Rob Beezer

[ascholerChemeketa]

Sorry, I saw the initial ping but didn't check it out before it dropped off my radar.

The suggested CSS sounds like a reasonable quick fix.

A cleaner/deeper fix would be to centralize the logic for inline titles (mostly on .solution-like) using the _inline-heading-mixin.scss mixin and add the permalink suppression to that logic instead of that list in _permalinks.scss. That way, a presentation that chose not to inline those titles would still have permalinks for the following paragraph. (i.e. hiding the permalink should be directly dependent on inlining being applied to the heading instead of assumed from the type of container.)

I can PR that fix if you want it after or instead the one your assistant suggested.

[ascholerChemeketa]

If desired, PR for deeper logic fix is here:
#3168