Floating aside quirks in HTML

[Jeremy Sylvestre]

Asides are a hot topic for me this week.

Came across some floating aside quirks as I was checking all my asides in DLA to see if I wanted to edit them.

1. An aside where the following paragraph contains a mathdisplay has a quirk when the aside is un-knowled while floating.

Screenshot

Live example

2. Asides don't behave well when they are descendents of an exercisegroup with @cols ≥ 2. Might be best to just never float to the margin in that case.

Live example

Note: The live example was built with vanilla PreTeXt. These quirks are unrelated to my aside-valign experiments.

Cheers,

Jeremy S

[Andrew Scholer]

Jeremy - 

Thanks for the live samples - very helpful.

1. That is non-ideal behavior that is related to the case where the display math extends into the right margin. In that case, the aside can either cover up the math or push it down. Covering it up is problematic if the aside is about the math. And it is extra problematic if the unopened aside would overlap with the math. Possible alternatives:

• Allow overlap. (With the aforementioned new issues).  Oscar and I talked about allowing overlap vs the push down behavior. We both felt the bad outcomes possible with overlap were worse than the push down behavior. 
• Remove the ability of display math to extend past the normal content boundary. so there is no need to clear anything.
• Use JS to try to detect display math elements with a rendered width less than the content width and turn off the "clear: right" style on them. Doing too much in JS programatically makes me nervous. When the new behavior ends up causing some other issue, it becomes that much harder to debug/fix.

2. The process of moving asides from their natural place in the HTML to a different location on the page (while retaining their actual location in the HTML for navigation/accessibility) is tough to make work for asides in any complex/nested container.

Turning off the float to side behavior in those situations does seem like the safest fix. Aggressive resposition via JS is the only alternative I see. So unless you want to take on the latter as part of your existing JS, I'll PR disable them inside complex containers like cols/sidebysides.

Andrew Scholer (he/him/his)

Computer Science Instructor

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

--
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 visit https://groups.google.com/d/msgid/pretext-dev/CALMYOndHYRiKmei8d0%3DXG8aSxHr%2BOu9EraMe-VMD3_s2k0ULDA%40mail.gmail.com.

[Rob Beezer]

> Asides don't behave well when they are descendents of an exercisegroup

I hope you mean descendant of an #introduction of a #exercisegroup.

An #aside cannot be a child of an #exercisegroup, as described in the schema.

The purpose of an exercisegroup/introduction is to describe the contained
#exercise and provide common instructions. It is a mistake that the schema
indicates this is possible.

Rob

On 8/17/25 19:46, Jeremy Sylvestre wrote:
> Asides are a hot topic for me this week.
>
> Came across some floating aside quirks as I was checking all my asides in DLA to
> see if I wanted to edit them.
>
> 1. An aside where the following paragraph contains a mathdisplay has a quirk
> when the aside is un-knowled while floating.

> Screenshot <https://sites.ualberta.ca/~jsylvest/pretext-dev/unknowled-aside.png>
> Live example <https://sites.ualberta.ca/~jsylvest/pretext-dev/aside-quirks/
> minimal-2-2.html>

>
> 2. Asides don't behave well when they are descendents of an
> exercisegroup with @cols ≥ 2. Might be best to just never float to the margin in
> that case.

> Live example <https://sites.ualberta.ca/~jsylvest/pretext-dev/aside-quirks/
> minimal-2-3.html>

>
> Note: The live example was built with vanilla PreTeXt. These quirks are
> unrelated to my aside-valign experiments.
>
> Cheers,
> Jeremy S
>

> --
> 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 <mailto:pretext-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CALMYOndHYRiKmei8d0%3DXG8aSxHr%2BOu9EraMe-VMD3_s2k0ULDA%40mail.gmail.com

> <https://groups.google.com/d/msgid/pretext-dev/
> CALMYOndHYRiKmei8d0%3DXG8aSxHr%2BOu9EraMe-VMD3_s2k0ULDA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Oscar Levin]

> An #aside cannot be a child of an #exercisegroup, as described in the schema.

I was going to claim the same thing, but the schema says that an aside-like can be the child of an exercise.  Maybe this should be disallowed though.

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzMC5iZWV6ZXI.1755556193%40pnsh.

[Jeremy Sylvestre]

On Mon, 18 Aug 2025 at 16:29, 'Rob Beezer' via PreTeXt development <prete...@googlegroups.com> wrote:

I hope you mean descendant of an #introduction of a #exercisegroup.

In practise I mean

exercisegroup

    exercise

        statement

            p

        solution

            p

            aside

An #aside cannot be a child of an #exercisegroup, as described in the schema.

The source file that built my "live example" produced no errors when checked against the schema by jing.

 

The purpose of an exercisegroup/introduction is to describe the contained
#exercise and provide common instructions.

Understood. That's how I use exercisegroup:

Exercise Group 4.6.9–48: Matrix arithmetic in DLA.

Cheers,

Jeremy S.

[Jeremy Sylvestre]

On Mon, 18 Aug 2025 at 16:39, Oscar Levin <oscar...@gmail.com> wrote:

> An #aside cannot be a child of an #exercisegroup, as described in the schema.

I was going to claim the same thing, but the schema says that an aside-like can be the child of an exercise.  Maybe this should be disallowed though.

I would be sad if asides were not permitted in exercises across-the-board. I'm very fond of the following.

Exercise X. [instructions]

Aside. Did you notice [some pattern that appeared in, but wasn't the focus of, Exercise X]? We'll explore [that pattern] in Chapter Y.

[Jeremy Sylvestre]

Andrew: thanks for your reply. More below.

On Mon, 18 Aug 2025 at 12:03, Andrew Scholer <andrew....@chemeketa.edu> wrote:

1. That is non-ideal behavior that is related to the case where the display math extends into the right margin. In that case, the aside can either cover up the math or push it down. Covering it up is problematic if the aside is about the math. And it is extra problematic if the unopened aside would overlap with the math. Possible alternatives:

• Allow overlap. (With the aforementioned new issues).  Oscar and I talked about allowing overlap vs the push down behavior. We both felt the bad outcomes possible with overlap were worse than the push down behavior. 
• Remove the ability of display math to extend past the normal content boundary. so there is no need to clear anything.
• Use JS to try to detect display math elements with a rendered width less than the content width and turn off the "clear: right" style on them. Doing too much in JS programatically makes me nervous. When the new behavior ends up causing some other issue, it becomes that much harder to debug/fix.

Sounds like every approach has trade-offs. Ideally authors wouldn't create displaymath that overflow into the right margin, but I suppose textwidth is unpredictable when you can have knowls inside knowls inside knowls... with shrinking boundaries. I guess I might have chosen option #2 above, since there is already the precedent on mobile to add horizontal scroll bars to math that is too wide, but I don't have the knowledge to understand the drawbacks to that approach.

But with the current approach, I find pushing down from the first displaymath a bit jarring. I think it is likely that my initial impression that it was a glitch rather than something intentional would be shared by textbook readers. Maybe the entire div.para.logical could be pushed down instead?

 

2. The process of moving asides from their natural place in the HTML to a different location on the page (while retaining their actual location in the HTML for navigation/accessibility) is tough to make work for asides in any complex/nested container.

Turning off the float to side behavior in those situations does seem like the safest fix. Aggressive resposition via JS is the only alternative I see. So unless you want to take on the latter as part of your existing JS, I'll PR disable them inside complex containers like cols/sidebysides.

Assuming asides are actually allowed within the depths of multi-column material, floating them to the margin moves them too far from the content to which they are associated anyway. So probably best to disable in those situations imo.

Also, I've come across a third quirk. Although it might be another case of "allowed by the schema but shouldn't be," idk.

3. The title of an aside that is a child of an li appears to inherit the style of list-item titles.

Live example

Cheers,

Jeremy S

[Andrew Scholer]

My preference for the "push down" over overlap was slight to begin with. I view(ed) it as the option with the least bad worst case. Your aside placement tweak PR might minimize one of one of my major concerns - what if the initial placement of the aside overlaps other content. If you want to experiment with changing it as part of that PR, I'm not going to push back. (Get rid of clear:right in _expendables.scss and the aside itself might need a z-index)

I'll plan on PRing the list title issue with the multi-col issue.

Andrew Scholer (he/him/his)

Computer Science Instructor

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

--
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 visit https://groups.google.com/d/msgid/pretext-dev/CALMYOndoNxRyh%2BrVRUnCrZnokrhp9XpS3HE5MRAWpJ8RnCGGog%40mail.gmail.com.