TASVideos
Allow Wikis to have a max-height function especially to reduce the Wiki's page length as seen in Hawk's History Release.
I know very well that I definitely brought this up in dev-chat, just y'know. :) So I'm finally writing the issue request months/year later.
This needs to be actually addressed to be completely blunt.
The temporary solution that I provided is a joke because you can't do a Ctrl+F for build/emulation corrections (which has been showcased) and it was instead done to set up ahead of time for a solution in the future.
And that future is to emulate/copy how melonDS has it set up, and that's to have this code called when it's being made:
<div style="max-height:23em; overflow:scroll; overflow-x: hidden; border:1px dotted #888;">
(Ignore the colours because it's my overwriting script for what I want on the site, I typically always load up private to showcase stuff, but in this instance I didn't do that.)
I assume it's related to the stuff in NewParser but I do not obviously understand jack when it comes to this stuff, and typically adjust stuff that's not related to site code.
You might be able to make boxes like that with %%DIV already? Or else there's tabs.
Tabs are not Ctrl+F'able, as was already mentioned in the opening post. I don't think we have a good DIV style for this kind of scrolling yet, but that is probably the easiest way of implementing it. It wouldn't require touching the wiki syntax or parser. Only needs a CSS style. Question is, what do we do for Margin? Padding? The style that was suggested above seems too close to our Quote style https://tasvideos.org/TextFormattingRules#Quotations . (Maybe nobody cares though.)
What about a sticky TOC sidebar? I find very large pages easy to browse when they have that. For instance, the ECMAScript 1 page spec is over 1 million pixels tall but it doesn't feel bad.
You might as well have both if you're bringing that up. The example site you brought up failed to load text for me funnily enough. So I'm partly concerned about Ctrl+F just failing.
The example site you brought up failed to load text for me funnily enough.
Really? It's just static HTML. There's some support JS, but the content is all in the HTML. I use it all the time for work and I've never had issues. You bring up a good point though; if we're worried about users on bad connections that will randomly just fail to load giant static wiki HTML pages, then an extra %%FOOBAR primitive isn't going to be enough; we'll have to deal with the problem that the served HTML is just too big.
On phones, the mentioned ECMAScript page takes a while to style-calculate, ~10 seconds. But after the initial load it displays and scrolls without issues. Of course opening the burger menu for the TOC triggers another style recalculation, so it takes like 1 second to open, close, or navigate to things.
That page didn't fail to load, it just took a long time. And our page loads fine. Thus, I don't think the goal of this ticket to reduce the served HTML. An extra %%FOOBAR primitive would be enough.
How much longer will we make pages after we have %%FOOBAR though?
But as you mentioned above, the simplest solution requires no parser changes at all here. So long as we have a good idea of what we want these to be styled like, and we can create one canonical class name for it, then it can just be %%DIV {class}.
I strongly advise against putting any bootstrap nonsense into the class name, because this class will become a permanent part of the wiki content.
max-height: 40vh; overflow-y: scroll; seems sufficient, plus you probably want to set a border (maybe copy BS cards: border: var(--bs-card-border-width) solid var(--bs-card-border-color); border-radius: var(--bs-card-border-radius);).
I think it would be a good idea to separately put a hard cap on the filesize of wiki pages.