Issue with "if...else": Multiple scroolbars in interactive example

[dy]

MDN URL: https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Control_flow/if...else

Please fix multiple scrollbars:

(a bit shocked about design change).

MDN Content page report details

• Folder: en-us/webassembly/reference/control_flow/if...else
• MDN URL: https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Control_flow/if...else
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/webassembly/reference/control_flow/if...else/index.md
• Last commit: mdn/content@5788b0b
• Document last modified: 2021-12-06T04:00:43.000Z

[caugner]

Analysis:

1. The interactive examples are embedded via the EmbedInteractiveExample macro.
2. Some articles provide a special CSS class to make the iframe bigger (e.g. taller).
3. In this case, the interactive example is embedded without specifying a CSS class like taller.
4. This suggests that either the interactive examples take more space since the redesign (due to spacing) OR the default height (and possibly the height of CSS classes like taller) have changed.

Solutions:

1. Ugly workaround: add taller to the macro invocation in mdn/content.
2. 👉 Revisit the iframe heights (default, shorter, taller etc.) for interactive example and adjust them accordingly.

[caugner]

FWIW We would already save some space by removing this line in bob:

https://github.com/mdn/bob/blame/28c31ec392efe83a030115515154c51095bac56f/editor/css/editor-libs/tabby.css#L4

Before

After

[caugner]

In contrast to other interactive examples, the WebAssembly examples have tabs, so maybe it would be sufficient to:

1. In mdn/bob, remove the tabs' padding-top (see my previous comment).
2. In mdn/interactive-examples, increase the height of the WebAssembly examples.

[wbamberg]

Ugly workaround: add taller to the macro invocation in mdn/content.

I'm not sure this is the ugly workaround. If the example actually has to be tall, using the taller editor and passing "taller" is what we want. We'd prefer for examples not to be tall (i.e. for them to fit in the standard size editor) but this isn't always possible.

It's preferable for the examples not to be tall (unless they have to be) because interactive examples are rude, occupying a bunch of space at the top of the page. I don't know about the WASM examples, but in JS at least, about 90% of the examples fit into 13 lines[1], so if all the iframes are set to fit 23 lines, we'll get a lot of empty space at the tops of our reference pages. So we would rather treat "tall" as a special case.

Obviously if the examples weren't in iframes then this sizing thing wouldn't be such a hacky problem. But I would still like us to keep them short, and in a weird way I think the iframe thing has turned out to be a useful tool for ensuring this. My # 1 comment on interactive examples PRs is "this example is too long and complicated, interactive examples are for short simple examples that show the basic usage. We have a whole page where we can include longer more complicated examples and show niche aspects of the API". This doesn't mean that I think having them in iframes is good, there are various ways in which it is bad. But it does add friction to making them as long as you like.

[1] mdn/interactive-examples#1530 (comment)

[wbamberg]

Actually now I look at the new design, either the editor height has increased or the line height has decreased, so "medium" examples now get 16 lines, "short" examples get 11 lines, and "tall" examples get a massive 28 lines.

So it would probably be good to go back and look at the size-assignment of JS examples. For instance, almost all "tall" examples now fit into the "medium" editor, so making them tall is just wasting space.

Or was this analysis already done as part of the redesign?

[schalkneethling]

@wbamberg We will have to dig into this one. We no longer do the cross-frame communication we did before to adjust the height etc. of interactive-examples. I am sure this contributed to the problems people have been filing issues about.

Would it be at all possible for you to provide me with a couple of pages where this is problematic? I am happy to do it but, if you already know, it might help speed the process along. Thanks!

[wbamberg]

I'm not 100% sure what problem you're referring to, but if it's the fact that the editor now accommodates more lines, so we might want to reassess which examples should which editor size, then mdn/interactive-examples#1530 (comment) is some kind of place to start.

For example, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/slice could certainly fit in the medium editor now, and the analysis in mdn/interactive-examples#1530 (comment) tells us that (at least in early 2020, and I doubt this has changed a lot) 38/60 "tall" examples could now fit in the medium editor (assuming a max line count of 15 for the medium editor)

Similarly, assuming a max line count of 10 for the small editor, there are 171 "medium" examples that would now fit in the "small" editor. For example, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substring .

Unfortunately that comment doesn't list all the examples in each sizing. I think when I did this analysis I wrote a bit of Python to count the lines in all the examples, and it would be quite quick to redo that. I will do it if you think it's worth it.

In the original conception of these examples we ideally wanted them to fit above the fold - of course that's dependent on the screen and on the overall page design, but that's part of the underlying rationale for caring so much about the height.

[schalkneethling]

I'm not 100% sure what problem you're referring to

I think, will have to do some digging, we also lost the classes for small, medium, and taller as part of the redesign so now, the editor is always the same height. This is probably what is causing these situations where there is a double scrollbar for example. Perhaps the solution is as simple as adding those CSS classes back.

To test that, I would need an example of each of these variations. If you have those handy, or can easily get a list, I would really appreciate it. If not, I can do some digging around as well. Thanks, @wbamberg.

[caugner]

FWIW Those CSS classes got removed in 32b9c00cce6af42e42f9cc62fb6a10af3505828a.

[wbamberg]

now, the editor is always the same height

The editor in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/slice seems taller than the editor in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substring . What am I missing?

[schalkneethling]

now, the editor is always the same height

The editor in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/slice seems taller than the editor in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substring . What am I missing?

You are correct but, was the class names always like .interactive.is-taller-height and .interactive.is-js-height. Perhaps that is part of the problem here?

[caugner]

This issue seems to be fixed, I can no longer see any scrollbars on the if...else article: