position of asides in html output

[Michael Shulman]

Is there any way to configure the html output so that asides will always appear between paragraphs in the main text, rather than off to the right side?  By default it seems that they appear in the main text if the window is less than a certain width, and off to the right side if it is wider than that certain width.

I don't like the way it looks to have them off to the side, for a number of reasons: they are too narrow, making the aside very long vertically if it has any appreciable amount of text in it; expanding their knowls tends to push other content down the page; and their vertical position often doesn't appear where I would like it to.  Plus I think it is inconsistent for some readers to see them in the main text and other readers to see them off to the side.  But I wasn't able to find any mention of an option to configure this.

--

Michael Shulman

Professor of Mathematics for Humans

University of San Diego

"The role of the intellectual cannot be to excuse the violence of one
side and condemn that of the other."
        -- Albert Camus

[Andrew Scholer]

There is not a publisher switch for changing the aside behavior, though different themes treat asides differently.

Some options:

1) Use a different element (<remark>?) and optionally rename it to "Aside" (https://pretextbook.org/doc/guide/html/basics-ch-rename.html)

2) Disable that behavior for your book by adding custom CSS. You can find examples of adding custom CSS in this project:
https://github.com/PreTeXtBook/pretext/tree/master/examples/custom-theming

The CSS rule you could add would look like:

@media screen and (min-width: 1280px) {
    details.aside-like {
        position: relative;
        margin-left: inherit;
        width: auto;
        right: inherit;
        float: none;
        clear: none;
    }
}

Andrew Scholer

--
You received this message because you are subscribed to the Google Groups "PreTeXt support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-suppo...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-support/CADYavpzXeTLO9NPDxV-P_2P%3DKJcT6FmNew-rJ8gA8OV9AOKooQ%40mail.gmail.com.

[Rob Beezer]

Dear Michael,

#aside has a very long history, in part since the name suggests it goes to one
side. And there is limited real estate to do that, notably for mobile and print.

Packages do this sort of thing for LaTeX, but automating placement is hard.
Absent a good solution, we do not even try. (Looking at you, Sean F.)

But you are the first to ask to put them between paragraphs in HTML output.

No real problem to make an HTML-only publisher switch.

@Andrew - suppoxe we had such a switch, and reacted to it by putting an
additional class next to .aside-like (.interleave?). Could the CSS then react
(naturally) in the way you suggest below?

Rob

On 2/25/26 11:01, Andrew Scholer wrote:
> There is not a publisher switch for changing the aside behavior, though
> different themes treat asides differently.
>
> Some options:
> 1) Use a different element (<remark>?) and optionally rename it to

> "Aside" (https://pretextbook.org/doc/guide/html/basics-ch-rename.html <https://
> pretextbook.org/doc/guide/html/basics-ch-rename.html>)

> Professor of Mathematics for Humans <https://home.sandiego.edu/~shulman/
> humans.html>

> University of San Diego
>
> "The role of the intellectual cannot be to excuse the violence of one
> side and condemn that of the other."
>         -- Albert Camus
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to pretext-suppo...@googlegroups.com <mailto:pretext-
> support+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-
> support/CADYavpzXeTLO9NPDxV-P_2P%3DKJcT6FmNew-

> rJ8gA8OV9AOKooQ%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-
> support/CADYavpzXeTLO9NPDxV-P_2P%3DKJcT6FmNew-
> rJ8gA8OV9AOKooQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to pretext-suppo...@googlegroups.com <mailto:pretext-
> support+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-support/

> CACm44N-N5j6Gswhfuf-axVJJpsHmtJXnTgZ%2BUZ%3DKmyG0BWPRKA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-support/CACm44N-N5j6Gswhfuf-
> axVJJpsHmtJXnTgZ%2BUZ%3DKmyG0BWPRKA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Alex Jordan]

If we are exploring alternatives, I'd propose behavior like a dialog that pops up, similar to the search tool. My perspective is that if it's truly an "aside", we don't need to see the main content simultaneously, and we don't need to see more than one aside at a time. Perhaps controversial. But if we're talking publisher switches...

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

[Andrew Scholer]

Yes, it would be easy to disable the CSS that moves asides to the side given some class. We already render them inline at smaller widths. And Tacoma never even tries to move them out to the side.

I like Alex's suggestion of a popover presentation. As Michael noted, the "on the side" presentation really only works well if you have very small asides and nothing that they will push down. An alternative presentation for authors that want more extended asides or ones that don't interact with other content would be nice. 

So my suggestion would be a pub attribute that allows for multiple values (not just @inline="true"). Given something like @render="inline/expanding/side" we can allow for rendering them: 1) with fully expanded content (for fidelity to print); 2) interleaved but expanding; 3) current behavior. And we make it easy to add a "popover" or other option down the road. (Multiple things should get refactored to use the html <dialog> element, adding popovers using that would be easy to mix into that work.)

I'm happy to handle any needed/wanted HTML/CSS changes given appropriate pub variable switches.

The sidebar conflicting with other content issues are largely restricted to default-modern, which has the fuzziest conceptual boundary for "the page". Long equations, runestone elements, etc... are allowed to bleed into the sidebar and thus "sidebar" content needs to worry about interacting with them:

https://pretextbook.org/examples/sample-article/default-modern/section-mathematics.html#section-mathematics-4-9

In themes like Denver/Salem, there is no need to deal with that issue as "page" content is strictly contained to the page:

https://pretextbook.org/examples/sample-article/denver/section-mathematics.html#section-mathematics-4-9

We could make default-modern refuse to expand content past the "page" (which I don't think would be popular). Or we could allow asides to overlap other content. That would prevent the pushdown behavior whereby opening an aside pushes down anything that might have expanded into the sidebar:

The downside there is that an aside placed right before some wide content would cut off that content:

I'm happy to make that change if we are comfortable saying that an author that wants the sidebar treatment is responsible for fixing overlap issues by moving their aside.

Andrew

To view this discussion visit https://groups.google.com/d/msgid/pretext-support/CA%2BR-jrfypakB62Y2cteWgUKzvKO_bN8zktv1FRW9RgO%3Dy7-rJw%40mail.gmail.com.

[Rob Beezer]

On 3/1/26 10:28, Andrew Scholer wrote:
> I like Alex's suggestion of a popover presentation.

Sure. I like that idea in principle. But why not a knowl? We have a lot of
infrastructure in place for that already, and it is not trivial to manufacture
the content, clickable titles, and so on, plus it would not require any
additional Javascript. Search is its own separate thing, with a dialog serving
a different purpose.

> I'm happy to handle any needed/wanted HTML/CSS changes given appropriate pub
> variable switches.

Thanks! Publisher switches and additional classes are pretty straight-forward
to add. So lets continue discussion of what the publisher options might be.

Rob

[Alex Jordan]

> But why not a knowl?

There are reasons. Not throwing shade at knowls of course, but:

• PTX knowls use javascript to insert stuff in the page. Whereas a dialog can just use native HTML and the invoker API on buttons.
• Pushing down the content that comes after the knowl. Any movement of content is not ideal, when it's not literally the user choosing to scroll.

If there's anything that we currently knowl where it seems least likely you would need to see the main content or other knowls at the same time, it's "aside" imho.

--
You received this message because you are subscribed to the Google Groups "PreTeXt support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-suppo...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pretext-support/MTAwMDAxNS5iZWV6ZXI.1772555901%40pnsh.

[Rob Beezer]

I'll grant you that #aside might be the least likely item to have open and
consult other parts of the page, but you might still want to open the knowl, and
choose to leave it open for a good long while as you read through other parts of
the page.

Everything else here does seem critial of knowls themselves, generally. Should
we convert all born-hidden knowls to popup dialogs?

I was just discussing this with Andrew at Drop-In, and was further reminded of
all the code that is in place for generating content for knowls - visible or
not, born-hidden or cross-reference. I don't feel the case here is compelling
enough to initiate and debug a parallel system.

> PTX knowls use javascript to insert stuff in the page

Certainly true for a cross-reference knowl. But a born-hidden knowl (which is
what we are discussing) has all its content on the page already, so it is more a
matter of visibility, I think? Of course, I don't know the JS that well, but I
think there is a fundamental distinction between the two here.

Rob

On 3/3/26 10:24, Alex Jordan wrote:
> > But why not a knowl?
>
> There are reasons. Not throwing shade at knowls of course, but:
>

> * PTX knowls use javascript to insert stuff in the page. Whereas a dialog can

> just use native HTML and the invoker API on buttons.

> * Pushing down the content that comes after the knowl. Any movement of content

> is not ideal, when it's not literally the user choosing to scroll.
>
> If there's anything that we currently knowl where it seems least likely you
> would need to see the main content or other knowls at the same time, it's
> "aside" imho.
>
>
>
>
> On Tue, Mar 3, 2026 at 8:38 AM 'Rob Beezer' via PreTeXt support <pretext-
> sup...@googlegroups.com <mailto:pretext...@googlegroups.com>> wrote:
>
> On 3/1/26 10:28, Andrew Scholer wrote:
> > I like Alex's suggestion of a popover presentation.
>
> Sure.  I like that idea in principle.  But why not a knowl?  We have a lot of
> infrastructure in place for that already, and it is not trivial to manufacture
> the content, clickable titles, and so on, plus it would not require any
> additional Javascript.  Search is its own separate thing, with a dialog serving
> a different purpose.
>
> > I'm happy to handle any needed/wanted HTML/CSS changes given appropriate pub
> > variable switches.
>
> Thanks!  Publisher switches and additional classes are pretty straight-forward
> to add.  So lets continue discussion of what the publisher options might be.
>
> Rob
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to pretext-suppo...@googlegroups.com <mailto:pretext-
> support%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-

> support/MTAwMDAxNS5iZWV6ZXI.1772555901%40pnsh <https://groups.google.com/d/
> msgid/pretext-support/MTAwMDAxNS5iZWV6ZXI.1772555901%40pnsh>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to pretext-suppo...@googlegroups.com <mailto:pretext-
> support+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-support/

> CA%2BR-jrd0O3LWcEAsGvvNxAf9_Q2GqpzaZH9c1dzJeYJm6KAp_w%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-support/CA%2BR-
> jrd0O3LWcEAsGvvNxAf9_Q2GqpzaZH9c1dzJeYJm6KAp_w%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Alex Jordan]

We have replaced (I think?) born hidden knowls with #summary/#details.  Aside is in that bucket, so my comment about javascript is not relevant. Aside is officially different from other born hidden knowls in the sense that theme css files are doing special things to handle it. I know you mean infrastructure to mean XSLT building HTML. Just saying it is an odd one. Anyway anything "critical" of knowls is still outweighed by their benefit: seeing main content and the referenced content at the same time, when desired.

We haven't heard back from Mike. I was just putting out there a different approach that would address Mike's concern. In my own projects I learned that asides are too much trouble. They either come out wrong in PDF, or require too much attention there. So I don't have a direct interest in where this goes. As I noted, it is "Perhaps controversial".

 

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