Figure in aside?

[Andrew Scholer]

The Guide promises that an aside can have "an optional title and then a variety of tags such as <p>, <figure>, and <sidebyside> (and many more)"

https://pretextbook.org/doc/guide/html/basics-s-fn.html#basics-s-fn-6

That is not reflected in the schema, which says aside can have BlockText only, not BlockStatement.

Is changing the schema to match the documentation reasonable here?

[Mitch Keller]

My gut tells me the schema is correct and the Guide is wrong here. A #figure lurking inside an #aside seems bad because it will make numbering seem wrong. I can think of a couple of times where we’ve used a small #image inside an #aside, so I’d like the option of that, but probably not too much stuff should be allowed inside an #aside.

--
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/CACm44N8nEQxjZJ3oRN%3D81846B2EfwznDeVYN1iUnZiC9WobF3g%40mail.gmail.com.

-- 
Mitch Keller
mi...@rellek.net

http://www.rellek.net/

[Rob Beezer]

Mitch is on to the bigger question here. How much stuff should we park in an #aside, and then try to do things like put it into a marginal note in print, an extreme example being a Tufte style presentation.

Banning numbered stuff might be a good middle ground. An #image, yes; a #figure, no. Sean and APEX has some hard-won experience with graphs and #tabular in the margin, iirc. And a #sidebyside in the margin is ludicrous.

On the other hand, perhaps we give up on clever presentational ideas and an #aside is just another block, so most anything goes. Then #fn is for true short blasts of tangential material. (I've been improving #fn and have more on a branch. But an #fn inside an #fn is still not supported.)

Musing,
Rob

On August 11, 2026 7:37:03 AM PDT, Mitch Keller <mi...@rellek.net> wrote:
>My gut tells me the schema is correct and the Guide is wrong here. A #figure lurking inside an #aside seems bad because it will make numbering seem wrong. I can think of a couple of times where we’ve used a small #image inside an #aside, so I’d like the option of that, but probably not too much stuff should be allowed inside an #aside.
>
>> On Aug 10, 2026, at 6:16 PM, Andrew Scholer <asch...@chemeketa.edu> wrote:
>>
>> The Guide promises that an aside can have "an optional title and then a variety of tags such as <p>, <figure>, and <sidebyside> (and many more)"
>>
>> https://pretextbook.org/doc/guide/html/basics-s-fn.html#basics-s-fn-6
>>
>> That is not reflected in the schema, which says aside can have BlockText only, not BlockStatement.
>>
>> Is changing the schema to match the documentation reasonable here?
>>
>> --
>> 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...@googlegroups.com>.
>> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N8nEQxjZJ3oRN%3D81846B2EfwznDeVYN1iUnZiC9WobF3g%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CACm44N8nEQxjZJ3oRN%3D81846B2EfwznDeVYN1iUnZiC9WobF3g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>

[Sean Fitzpatrick]

In APEX we move a lot of things into the margin for PDF, but I would not want those things in an aside for HTML! 

(Maybe if there was a layout for wider screens that didn't hide asides in a knowl?)

But even in PDF this has required a lot of extra xsl, and some rogue attributes that Oscar's excellent vscode validation likes to remind me are illegal.

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/MTAwMDAzbkRnYmlGSXI.1786752189%40pnsh.

[Andrew Scholer]

If you really want to author a Tufte-style work and use aside as the primary organizational tool, you would need to put figures, tables, and yes, even sidebysides into the asides.

To what degree should the schema reflect document semantics vs presentational constraints?

Semantically to me, an aside is very much like a remark, only more meta or tangential. Why should one allow for a captioned image and the other does not?

Because in some presentations the content is going to be placed into a narrow sidebar? What if the work is never intended to be built in those presentations? Because one structure has a number and the other doesn't? That is a presentation choice (albeit a more global one in PreTeXt land) that could be changed.

I've brought it up before, but I think the idea of "in a sidebar" should be disconnected from aside/historical/biographical. Publisher option could allow the publisher to specify default layouts for various categories of items or even items. Maybe a certain work wants <historical> to play a more central role and not get pushed to the side. Maybe a heavily annotated work wants to put <remark>s and other content into a sidebar. (I'm thinking back to musing a while back about what it would take to markup a heavily annotated work where annotations corresponded to ranges of text and highlighted the relevant parts when activated..)

Authoring choices (stuffing lots of stuff into asides) are going to constrain reasonable publisher choices... but that seems fine. A print publisher is going to have to work with an author to figure out a reasonable presentation of the content of the work.

This is more musing than a real proposal. But it does seem that aside/historical/biographical are an awkward spot where presentation is guiding the schema more than most places. And that seems to rule out PreTeXt ever gracefully handling texts that have different or more complex relationships between text and commentary.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CAH%2BNcPZSk8qUQr9zYXLX%3DSWxjXCr3u5LGTbEsw43YQGZGZj3zA%40mail.gmail.com.

[Sean Fitzpatrick]

Similar to the device introduced by Alex to handle page breaks in PDF, if a publisher wants marginalia, they could use xml:id to indicate which things to in the margin. 

But you also need a second piece of data, since many margin items will need to be adjusted vertically. 

I wanted to mimic what Alex did, so I could move away from illegal source, but I couldn't figure out the best way to include both bits of information.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N-86WJ5BPK%2B2enJgcr7PcwMzO3vB6fkMo9QeTMN6UNKUg%40mail.gmail.com.

[Alex Jordan]

I agree with Andrew that the concept of an aside (some content loosely related to the main content) should be separate from the presentation style of putting something in the nargin.

But also an aside is (was?) meant to be something so tangential that there shouldn't be a need to cross reference anything inside it. If it's worthy of being cross referenced, make it a remark-like. And having the two families (aside-like and remark-like) is perhaps because outlawing numbered things inside an aside can give more freedom for "fun" layout options.

Is the motivating instance more a matter of what could be done to present remark-like (and more) in a different way, as marginalia?

Is the convo about print, html, or both? Sean, in print, how bad would it be to put marginalia in the margin, but just descening from the top of the page, with no regard to the vertical position of nearby source content in the main part of the page? (I'm trying to think of how to eliminate the vertical shift part of your problem.)

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CAH%2BNcPaXO178uV%3DS4UcS_9nNb%3D7HutEuN4Rbu2JzJ6AkJCnhqg%40mail.gmail.com.

[Sean Fitzpatrick]

I had PDF in mind, but I could imagine an HTML theme with a layout that put figures beside the text. 

Maybe there is a LaTeX package that is smart enough to automatically place things in the margin so that they don't overlap, but if so, I didn't find it. 

The manual adjustments in APEX are necessary because LaTeX places things in the margin relative to where they're anchored in the text, and this leads to items that either collide, or spill off the top or bottom of the page.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jrfMpe9kSEtbDkZAJ28piRC2sAvyoGTGqGjkRb5%2Bap2_%2Bg%40mail.gmail.com.