Smf2.1: Code tags layout

[mastum]

Description

Code layout doesn't have a limit and with long code we have a very long page.

Environment (complete as necessary)

• Version/Git revision: SMF 2.1 RC1
• Database Type: All
• Database Version: All
• PHP Version: All

Additional information/references

[Sesquipedalian]

The root problem is the decision to add resize: vertical to code blocks. That's incompatible with setting a max-height. We can only do one of the following:

1. Continue using height: auto (or technically, not setting a height, which defaults to auto). This makes setting resize: vertical pointless, since the code block will always already be expanded to its full height.

2. Set resize: vertical and height: <some value>. This will cause code blocks to always start at a certain height regardless of their content, but allow them to be resized. For short code snippets, this will result in a lot of wasted whitespace in each code block on initial page load.

3. Go back to 2.0's max-height: 24em (or whatever value we prefer) and forget about resize: vertical. This will avoid adding useless whitespace to short code blocks while preventing overly tall code blocks, but will take us back to having to scroll through tall blocks.

4. Do something clever with JavaScript so that we can set an initial max-height on page load but then allow the resize to change the real hight beyond that maximum afterwards.

Those who are curious can see the history of development in this series of commits:
e36ef26
f29876b
a309e8c
aff7225
18c6c9b

[Sesquipedalian]

Option 4 would probably involve setting a max-height in the default CSS and adding some deferred JavaScript that would calculate the code block's actual height, then set its height explicitly to that calculated value, and then set its max-height to none.

[smfbigguy]

3 sounds like the best option. (to me anyway) There may be another problem with code tags but I will open that if it ends up I have to. (not sure its a problem yet, I don't use the tags much. Just started to)

[SychO9]

Option 4 sounds like the best solution, only concern is that the resize property is not supported in Edge & IE

[Sesquipedalian]

only concern is that the resize property is not supported in Edge & IE

True, but then the process described in option 4 would simply have no visible effect in those browsers. The script would still set the height explicitly and remove the max-height, and then the addition of the resize property would accomplish nothing. The net effect would be indistinguishable from the initial appearance for Edge and IE users.

[SychO9]

that's a good point, you can leave this to me if it's okay with you.

[Gwenwyfar]

I'd just go with option 3. We could use a vh max height instead perhaps, so having a resize is essentially useless anyway. You're only changing one scrollbar for another scrollbar if the box is already at a nice height, when in one case you'll have to use the resize AND scroll (just the browser window, instead), which is just more work. If anything else, it could have an expand button if we want to make it a little smaller by default.

[Sesquipedalian]

If anything else, it could have an expand button if we want to make it a little smaller by default.

That's the best idea. Go with option 3, but add a little expand button that simply set max-height: none on its parent code block.

[Sesquipedalian]

that's a good point, you can leave this to me if it's okay with you.

Thanks!

[mastum]

Sorry @SychO9 how can I solve the problem temporarily?
It is very annoying...
Thanks 😉

[SychO9]

Sorry @SychO9 how can I solve the problem temporarily?
It is very annoying...
Thanks 😉

just add a max-height: 25em; to .bbc_code in the css

[mastum]

Thanks 😊