Responsive sizing for interactives (geogebra, etc...)
18 views
Skip to first unread message
Andrew Scholer
Jul 5, 2025, 11:29:22 AMJul 5
to prete...@googlegroups.com
I have a draft of something to make iframe based interactive (Geogebra, Desmos, etc..,) responsively sized. This would fix the issue reported here:
It would also allow themes to "widen" interactives by making the container around them wider.
But it raises a question: What does an author mean when they specify width="70%". Do they mean 70% always (even on mobile)? Or do they mean "the max size is 70% of the largest possible rendering container?"
I would guess that author intent is generally the second one. And that is closest to the current behavior (only the largest possible container is assumed to always be 600px). But it is also a slippery definition. To work, it needs to be calculated as a pixel value. But that pixel value depends on the theme and whether or not the theme has "widened" the particular container. The first is known at HTML build time. The second is not. And whatever the value is, it is likely unknown to the author. Which means if what they really want to specify is "I have an interactive with a natural size of 400px and it looks broken if it is scaled past that," they are going to have a hard time getting the correct value.
The HTML native approach would be a width specified in pixels and a max width 100%.
Would it make sense to provide a natural-size that is interpreted as raw pixel measurement in HTML rendering? If one was specified it would essentially override the %width in html rendering.
<interactive ... natural-size="400px"/> would be 100% but max out at 400px. (It would be 100% in print).
<interactive ... natural-size="400px"/> would be 100% but max out at 400px. (It would be 100% in print).
<interactive ... width=70% natural-size="400px"/> would also be 100% but max out at 400px. It would be 70% in print.
It is a bit clumsy. But so is trying to figure out a % to use when what you really want to say is "this thing really shouldn't be blown up past 400px". And it is more precise. In the 400px case, there is not going to be a percent that the author can specify that will guarantee the browser renders to 400px instead of 399.9999 or something like that.
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
Rob Beezer
Jul 6, 2025, 1:20:39 PMJul 6
to prete...@googlegroups.com
> What does an author mean when they specify width="70%"?
That means, (ideally) I want this block centered, with healthy (15%) margins on
each side.
> largest possible rendering container?
I'm not sure what that means, and I don't think an author would.
> even on mobile
Our attitude is that mobile might be good for reviewing for an exam while you
sit at the bus stop, but serious studying (whatever that is!) needs more real
estate. And where is the breakpoint for that: 6" phone, 12" tablet (w/ or w/o
keyboard), 15" laptop, 27" desktop, 55" gaming monitor?
If an author's source is going to be agnostic about output formats, then I don't
think it should have physical units (centimeters, inches). And pixels is
another step beyond - they are even more meaningless.
We have a 600px "design width" for text, so wrapping paragraphs works well.
Might we make that 800px someday? What happens to an author's source then?
Does an author know that their interactive "looks best" at 400px? And why is
that it looks crappy if scaled up? Is it the fault of the interactive? We will
never be able to just ingest everything (witness WeBWorK OPL problems). Should
it be on the interactive to scale gracefully from mobile to desktop? Don't we
want a low-vision reader to be able to scale up and have things look good?
Having said all that, interactives are great. And *only* in HTML, almost by
definition. They are a pale imitation in all other formats, even in EPUB
(lacking JS, typically). So I guess some notion of a width in pixels is a
property of an interactive that we might consult profitably.
You talk about scaling up being bad. What about the problem when an interactive
is so busy that it pretty much decides it owns the whole screen? Click on the
"Discrete" panel here:
Figure 15.6
https://pretextbook.org/examples/sample-article/html/section-interactive-server.html#figure-phet-fourier
You can zoom this standalone page to (say) 200% and it is better:
https://pretextbook.org/examples/sample-article/html/interactive-phet-fourier.html
would @natural-width=1800px be used in some way?
I'd entertain a PR. But let's not use @natural-width. It might make people
think graphics files have natural widths. How about @design-width. Not our
600px design width (an author may not know that), but the design width of the
#interactive. Somebody built it assuming a canvas of a certain (ideal?) size.
Consider it a hint. Most formats ignore it. Other formats and styles and
device limitations *might* consult it.
Rob
On 7/5/25 08:28, Andrew Scholer wrote:
> I have a draft of something to make iframe based interactive (Geogebra, Desmos,
> etc..,) responsively sized. This would fix the issue reported here:
> https://groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667-
> c9b9694fbf5fn%40googlegroups.com?utm_medium=email&utm_source=footer <https://
> groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667-
> c9b9694fbf5fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> computerscience.chemeketa.edu/people/andrew-scholer/ <http://
> 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 <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N__1f6%2Bp7FMYPV0UN-aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/CACm44N__1f6%2Bp7FMYPV0UN-
> aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
That means, (ideally) I want this block centered, with healthy (15%) margins on
each side.
> largest possible rendering container?
I'm not sure what that means, and I don't think an author would.
> even on mobile
Our attitude is that mobile might be good for reviewing for an exam while you
sit at the bus stop, but serious studying (whatever that is!) needs more real
estate. And where is the breakpoint for that: 6" phone, 12" tablet (w/ or w/o
keyboard), 15" laptop, 27" desktop, 55" gaming monitor?
If an author's source is going to be agnostic about output formats, then I don't
think it should have physical units (centimeters, inches). And pixels is
another step beyond - they are even more meaningless.
We have a 600px "design width" for text, so wrapping paragraphs works well.
Might we make that 800px someday? What happens to an author's source then?
Does an author know that their interactive "looks best" at 400px? And why is
that it looks crappy if scaled up? Is it the fault of the interactive? We will
never be able to just ingest everything (witness WeBWorK OPL problems). Should
it be on the interactive to scale gracefully from mobile to desktop? Don't we
want a low-vision reader to be able to scale up and have things look good?
Having said all that, interactives are great. And *only* in HTML, almost by
definition. They are a pale imitation in all other formats, even in EPUB
(lacking JS, typically). So I guess some notion of a width in pixels is a
property of an interactive that we might consult profitably.
You talk about scaling up being bad. What about the problem when an interactive
is so busy that it pretty much decides it owns the whole screen? Click on the
"Discrete" panel here:
Figure 15.6
https://pretextbook.org/examples/sample-article/html/section-interactive-server.html#figure-phet-fourier
You can zoom this standalone page to (say) 200% and it is better:
https://pretextbook.org/examples/sample-article/html/interactive-phet-fourier.html
would @natural-width=1800px be used in some way?
I'd entertain a PR. But let's not use @natural-width. It might make people
think graphics files have natural widths. How about @design-width. Not our
600px design width (an author may not know that), but the design width of the
#interactive. Somebody built it assuming a canvas of a certain (ideal?) size.
Consider it a hint. Most formats ignore it. Other formats and styles and
device limitations *might* consult it.
Rob
On 7/5/25 08:28, Andrew Scholer wrote:
> I have a draft of something to make iframe based interactive (Geogebra, Desmos,
> etc..,) responsively sized. This would fix the issue reported here:
> https://groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667-
> groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667-
> c9b9694fbf5fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> 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 <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N__1f6%2Bp7FMYPV0UN-aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/CACm44N__1f6%2Bp7FMYPV0UN-
> aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Andrew Scholer
Jul 7, 2025, 10:43:44 AMJul 7
to prete...@googlegroups.com
Great, thanks.
Yes, the near dependance on HTML output for interactives is what gave me the temerity to even suggest pixels for this use. :)
I had not been thinking about it before, but for something like the Fourier example, a design-width larger of 1800px could productively be used to allow it to get larger. Perhaps for items with a design width larger than the rendered width we could automatically provide a "open in new tab" link that opens the standalone version where the interactive can likely be displayed larger.
Pixel sizes are often determinable. If the interactive is being adopted from some other location, a quick "Inspect" will show what size it is being displayed at whatever site it comes from. However, even if an author does resort to guess and check, the answer they determine will be more stable. "This looks best capped at 400px" is going to work on default-modern or salem, on a desktop, mid-sized tablet, phone, etc.... "This looks best capped at 70%" is entirely context dependent.
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
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/MTAwMDAzNy5iZWV6ZXI.1751822437%40pnsh.
Rob Beezer
Jul 7, 2025, 10:54:47 AMJul 7
to prete...@googlegroups.com
Yes, a "open in new tab" link sounds like a good idea (I was going there
before). Maybe all the time?
We need to do exactly the same sort of thing in the PDF, though it needs a "base
URL". That work got hung up *long ago* due to the need for some serious
refactoring to get the link information at the right place.
> a quick "Inspect"
Which is going to be too much to ask of some authors. ;-)
Thanks,
Rob
On 7/7/25 07:43, Andrew Scholer wrote:
> Great, thanks.
>
> Yes, the near dependance on HTML output for interactives is what gave me the
> temerity to even suggest pixels for this use. :)
>
> I had not been thinking about it before, but for something like the Fourier
> example, a design-width larger of 1800px could productively be used to allow it
> to get larger. Perhaps for items with a design width larger than the rendered
> width we could automatically provide a "open in new tab" link that opens the
> standalone version where the interactive can likely be displayed larger.
>
> Pixel sizes are often determinable. If the interactive is being adopted from
> some other location, a quick "Inspect" will show what size it is being displayed
> at whatever site it comes from. However, even if an author does resort to guess
> and check, the answer they determine will be more stable. "This looks best
> capped at 400px" is going to work on default-modern or salem, on a desktop, mid-
> sized tablet, phone, etc.... "This looks best capped at 70%" is entirely context
> dependent.
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/ <http://
> server.html#figure-phet-fourier <https://pretextbook.org/examples/sample-
> article/html/section-interactive-server.html#figure-phet-fourier>
> interactive-phet-fourier.html>
> a667->
> > c9b9694fbf5fn%40googlegroups.com?utm_medium=email&utm_source=footer
> <http://40googlegroups.com?utm_medium=email&utm_source=footer> <https://
> > groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667-
> <http://groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667->
> > c9b9694fbf5fn%40googlegroups.com?utm_medium=email&utm_source=footer
> <http://40googlegroups.com?utm_medium=email&utm_source=footer>>
> computerscience.chemeketa.edu/people/andrew-scholer/> <http://
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > CACm44N__1f6%2Bp7FMYPV0UN-aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com
> <http://40mail.gmail.com> <https://
> > groups.google.com/d/msgid/pretext-dev/CACm44N__1f6%2Bp7FMYPV0UN- <http://
> groups.google.com/d/msgid/pretext-dev/CACm44N__1f6%2Bp7FMYPV0UN->
> > aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com?
> utm_medium=email&utm_source=footer <http://40mail.gmail.com?
> dev%2Bunsu...@googlegroups.com>.
> pretext-dev/MTAwMDAzNy5iZWV6ZXI.1751822437%40pnsh>.
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N9zGXC1b%2BEp%2BM8yDW4mZEK1LnDgz0m7ObdtsY9-0Dk1dQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
before). Maybe all the time?
We need to do exactly the same sort of thing in the PDF, though it needs a "base
URL". That work got hung up *long ago* due to the need for some serious
refactoring to get the link information at the right place.
> a quick "Inspect"
Which is going to be too much to ask of some authors. ;-)
Thanks,
Rob
On 7/7/25 07:43, Andrew Scholer wrote:
> Great, thanks.
>
> Yes, the near dependance on HTML output for interactives is what gave me the
> temerity to even suggest pixels for this use. :)
>
> I had not been thinking about it before, but for something like the Fourier
> example, a design-width larger of 1800px could productively be used to allow it
> to get larger. Perhaps for items with a design width larger than the rendered
> width we could automatically provide a "open in new tab" link that opens the
> standalone version where the interactive can likely be displayed larger.
>
> Pixel sizes are often determinable. If the interactive is being adopted from
> some other location, a quick "Inspect" will show what size it is being displayed
> at whatever site it comes from. However, even if an author does resort to guess
> and check, the answer they determine will be more stable. "This looks best
> capped at 400px" is going to work on default-modern or salem, on a desktop, mid-
> sized tablet, phone, etc.... "This looks best capped at 70%" is entirely context
> dependent.
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> article/html/section-interactive-server.html#figure-phet-fourier>
>
> You can zoom this standalone page to (say) 200% and it is better:
> https://pretextbook.org/examples/sample-article/html/interactive-phet-
> fourier.html <https://pretextbook.org/examples/sample-article/html/
> You can zoom this standalone page to (say) 200% and it is better:
> https://pretextbook.org/examples/sample-article/html/interactive-phet-
> interactive-phet-fourier.html>
>
> would @natural-width=1800px be used in some way?
>
> I'd entertain a PR. But let's not use @natural-width. It might make people
> think graphics files have natural widths. How about @design-width. Not our
> 600px design width (an author may not know that), but the design width of the
> #interactive. Somebody built it assuming a canvas of a certain (ideal?) size.
> Consider it a hint. Most formats ignore it. Other formats and styles and
> device limitations *might* consult it.
>
> Rob
>
> On 7/5/25 08:28, Andrew Scholer wrote:
> > I have a draft of something to make iframe based interactive (Geogebra,
> Desmos,
> > etc..,) responsively sized. This would fix the issue reported here:
> > https://groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-
> a667- <https://groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-
> would @natural-width=1800px be used in some way?
>
> I'd entertain a PR. But let's not use @natural-width. It might make people
> think graphics files have natural widths. How about @design-width. Not our
> 600px design width (an author may not know that), but the design width of the
> #interactive. Somebody built it assuming a canvas of a certain (ideal?) size.
> Consider it a hint. Most formats ignore it. Other formats and styles and
> device limitations *might* consult it.
>
> Rob
>
> On 7/5/25 08:28, Andrew Scholer wrote:
> > I have a draft of something to make iframe based interactive (Geogebra,
> Desmos,
> > etc..,) responsively sized. This would fix the issue reported here:
> > https://groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-
> a667->
> > c9b9694fbf5fn%40googlegroups.com?utm_medium=email&utm_source=footer
> <http://40googlegroups.com?utm_medium=email&utm_source=footer> <https://
> > groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667-
> <http://groups.google.com/d/msgid/pretext-support/baf44543-936d-49c4-a667->
> > c9b9694fbf5fn%40googlegroups.com?utm_medium=email&utm_source=footer
> <http://40googlegroups.com?utm_medium=email&utm_source=footer>>
> > computerscience.chemeketa.edu/people/andrew-scholer/ <http://
> 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 <mailto:pretext-
> dev%2Bunsu...@googlegroups.com> <mailto:pretext- <mailto:pretext->
> 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
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> > CACm44N__1f6%2Bp7FMYPV0UN-aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com
> <http://40mail.gmail.com> <https://
> > groups.google.com/d/msgid/pretext-dev/CACm44N__1f6%2Bp7FMYPV0UN- <http://
> groups.google.com/d/msgid/pretext-dev/CACm44N__1f6%2Bp7FMYPV0UN->
> > aeqjRY30ZZ5FsZGJ8kjnDuLgK8g%40mail.gmail.com?
> utm_medium=email&utm_source=footer <http://40mail.gmail.com?
> utm_medium=email&utm_source=footer>>.
>
> --
> 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-
>
> --
> 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
> dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> MTAwMDAzNy5iZWV6ZXI.1751822437%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAzNy5iZWV6ZXI.1751822437%40pnsh>.
>
> --
> 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
> --
> 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/
> CACm44N9zGXC1b%2BEp%2BM8yDW4mZEK1LnDgz0m7ObdtsY9-0Dk1dQ%40mail.gmail.com
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N9zGXC1b%2BEp%2BM8yDW4mZEK1LnDgz0m7ObdtsY9-0Dk1dQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
Andrew Scholer
Jul 7, 2025, 4:02:41 PMJul 7
to prete...@googlegroups.com
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
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/MTAwMDAyMC5iZWV6ZXI.1751900084%40pnsh.
Mitch Keller
Jul 10, 2025, 5:04:38 PMJul 10
to prete...@googlegroups.com
From the testable version, it looks like this is only hitting things in the “interactive elements, server” part of the sample article. I’m curious about if it can also bring improvements to the “interactive elements, authored” portion as well. At least for Sage Interacts, PreTeXt produces an HTML file that is included in an iframe. Sizing these things and dealing with the aspect ratio is a huge headache for Active Calculus - Multivariable, so anything that improves the situation would be great, and I do like the open in new tab link that’s demonstrated.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N_XttpHBTNiUmusFRjv_VZaVK-yKrLzyF2Gi2W7%2B2c42g%40mail.gmail.com.
Andrew Scholer
Jul 11, 2025, 11:06:02 AMJul 11
to prete...@googlegroups.com
I focused on those because they all use the same basic rendering implementation and all of the contents are in an iframe. For authored interactives, things are a little more varied. There are a variety of slate types, and I am not sure the same logic applies to all of them. Maybe it does. I can take a look.
Related note:
Rob - Since one of the two ways of adding Geogebra elements is deprecated, can we drop it from the SA? Or at least add a big DO NOT USE in the slate section?
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/9D8E3B5E-4ED8-4AC6-93D2-C6761C7EA88F%40rellek.net.
Andrew Scholer
Jul 11, 2025, 8:04:43 PMJul 11
to prete...@googlegroups.com
Mitch -
I just have the one instance in SA to work with. Do you have any particularly tricky example you can share? Maybe add it to the PR or send it to me offline?
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
Andrew Scholer
Jul 14, 2025, 7:09:45 PMJul 14
to prete...@googlegroups.com
I had a chance to check out samples that Mitch shared with me offline.
The @slate="sage" is, as I feared, problematic in that the content generated by sage (especially when it is rendering a 3d plot) painted onto a fixed size canvas. So if you shrink the container it is in, the only way to handle it is to have the container start scrolling to reveal the contents.
The "server" interactives are all a different case - the contents of each of those iframes rescales itself to fit the container it is in. So when the container around one of those gets smaller, the contents can adapt and scrollbars are not needed.
The line isn't actually "authored" vs "server" interactives. Some authored interactives (doenet, plain threejs) know how to resize themselves. An arbitrary iframe from a remote server might not rescale its contents.
So I have an updated proposal to expand what I currently have:
<interactive @responsive="yes/no">
The existing PreTeXt behavior is "no". The width and aspect ratio are used to make a fixed sized container. If the page does not have room for that container, the container gets scroll bars so that it's content can stay the same size.
responsive="yes" is like what I have on the sample "server" interactive page (
https://computerscience.chemeketa.edu/ascholer/pretext-test/interactives/section-interactive-server.html). The width and aspect ratio are used to make a dynamic container that resizes to maintain the aspect ratio and lets the content adjust itself.
Either method would still allow an interactive that knows how to to set its own height via the SPLICE protocol to send that request, which would override the height calculated from the aspect ratio.
We can provide some logical defaults for known interactives (e.g. geogebra/desmos/doenet which all appear to be responsive by default). But the author could override the default with the per element @responsive. They will be the ones that know (or can figure out) if the interactive they created or found resizes itself.
Side note:
Mitch's samples are indicative of the pain of trying to figure out sizes for interactives using just percent width and aspect ratio. The %width specified in pretext gets baked into the iframe created for the interactive as a % of 600px. That in turn gets used by sage code to build a series of elements, some of which are sized (including height) based on that width.
Now if you throw that interactive inside some kind of container (exercise, etc...) that adds margin, and your sizing based on 600px is likely too big and thus the content will scroll. So now you need to change the %width to 90 (or is it 89? or 91?) to get the right width. But that changes your aspect ratio too as not everything's height changes proportionally to its width.
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
Andrew Scholer
Aug 19, 2025, 1:43:21 PMAug 19
to PreTeXt development
I just completed an overhaul of the responsive interactives.
I have decided interactives fall into two buckets - ones that are should scale proportionally (responsive) and ones that pretty much assume a fixed height. So now there are two strategies for interactive layouts: one that maintains the aspect ratio and assumes the interactive will resize itself and one that maintains a fixed-height and scrolls if needed.
This first page has some layout demos at the bottom. The second page has various other samples:
For comparison:
https://pretextbook.org/examples/sample-article/html/section-interactive-server.html
https://pretextbook.org/examples/sample-article/html/section-interactive-authored.html
https://pretextbook.org/examples/sample-article/html/section-interactive-authored.html
The "open in a new tab" link is now only added to the responsive style interactives - they are the ones that might make good use of more real estate on a standalone page. Example:
https://computerscience.chemeketa.edu/ascholer/pretext-test/interactives/interactive-phet-fourier.html
https://computerscience.chemeketa.edu/ascholer/pretext-test/interactives/interactive-phet-fourier.html
Reply all
Reply to author
Forward
0 new messages