Add ability to expand and collapse code blocks in content

[schalkneethling]

An alternative solution is to add a button that when clicked, forced the width of the pre block to a wider width.

On load

After clicking the button

We add min-width: max-content; that results in

Originally posted by @schalkneethling in https://github.com/mdn/yari/issues/2187#issuecomment-759278250

[peterbe]

Why would you not want that to always be pressed automatically for you?

[schalkneethling]

Why would you not want that to always be pressed automatically for you?

You mean always expanded?

[peterbe]

Why would you not want that to always be pressed automatically for you?

You mean always expanded?

Yes, if my viewport is large, what benefit is there to capping the width? It makes sense to cap the widget for prose sentences because the eye is expected to track down to the very next line all the way back to the left, and that's hard if the lines are long. But for all <pre> tags, I see no benefit in doing any capping. And in these screenshot examples, that lovely HTML is really easy to read even if a line it happened to be pretty long.

What I'm proposing is to have no max-width on <pre> tags and no button that at all to expand it.

[schalkneethling]

@peterbe Oh, I see. Where this came up is when these were inside an unordered list for example. The unordered list itself is constrained with readable-line-length. The idea here is for the button to "force" a min-width that is equal to the max-content forcing the pre to expand beyond its container.

There might be a way to achieve this without the proposed user interaction here, but I will need to ponder that for a bit 😃

[peterbe]

Been pondering? I really see no reason to ever width-limit any <pre> tag.

[schalkneethling]

Been pondering? I really see no reason to ever width-limit any <pre> tag.

So, it is not the width of the pre element that is width-limited but the container it is in. That is what makes this extra tricky to implement. If you look at the context of the original report, you will see the pre elements were wrapped inside li elements:

https://developer.mozilla.org/en-US/docs/Learn/Forms/How_to_structure_a_web_form#active_learning_building_a_form_structure

The unordered list container of those has the same readable-line-length applied as paragraphs for example. So, I guess this proposed "solution" is for those specific instances. This makes me wonder whether this is even worth implementing. Seems like we might need to reconsider our options here.

[ghost]

This certainly doesn't help but let's say that a component should perform well wherever you put it regardless of the context. In this regard, in another project we had created blank test pages where there were only the components in different containers to see them. A sort of catalog. Trick 💡: If you want to guarantee the same behavior of a certain context, you can take all the computed properties and hardcode them into the component. Of course we could also reason about what properties we want to be inherited and there is a keyword for that.

[peterbe]

So it's only a problem in pages where you have <li><pre>? How common is that? And can we instead encourage people to write their code examples, when it's part of a bullet point list in a way that they're not very wide in the first place?

Also, there was talk about a fancy widget that expands it that you have to press. If that can be implemented at all, and if it's important, it should just do it without even offering a widget to press. :)

[ghost]

? https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullScreen

[schalkneethling]

So it's only a problem in pages where you have <li><pre>?

Exactly

How common is that?

I do not know honestly.

--

I think we need to revisit this issue. It feels like an edge case where the "real" solution is to guide authors to not have code examples inside list items. It kinda sucks because sometimes it makes a lot of sense when it explains something in a step-by-step process to wrap it in an ordered list for example.

@chrisdavidmills Thoughts?

[chrisdavidmills]

So it's only a problem in pages where you have <li><pre>?

Exactly

How common is that?

I do not know honestly.

It is pretty common in tutorials/guides, not so much in other content types.

I think we need to revisit this issue. It feels like an edge case where the "real" solution is to guide authors to not have code examples inside list items. It kinda sucks because sometimes it makes a lot of sense when it explains something in a step-by-step process to wrap it in an ordered list for example.

@chrisdavidmills Thoughts?

Yeah, I for one certainly use code blocks inside ordered lists a lot.

Could we have some kind of styling update whereby all code blocks stretch the entire width of the content area, both to the left and right. Would that be doable in a way that looks OK?

[schalkneethling]

Could we have some kind of styling update whereby all code blocks stretch the entire width of the content area, both to the left and right. Would that be doable in a way that looks OK?

Let me look at this and get back to you @chrisdavidmills

[schalkneethling]

@chrisdavidmills Here is another idea. While I acknowledge that it can be tedious and I am not sure how this plays out in a markdown world, perhaps it is a KIS(keep it simple) options? 😀

<ol>
  <li>
    To start with, make a local copy of our blank template file and the CSS for
    our payment form in a new directory on your computer.
  </li>
  <li>
    Apply the CSS to the HTML by adding the following line inside the HTML
    <code>&lthead></code>:
  </li>
</ol>

<pre data-type="html">
<code>
&lt;link href="payment-form.css" rel="stylesheet" />
</code>
</pre>

<ol start="3">
  <li>
    Next, create your form by adding the outer <code>&lt;form></code> element:
  </li>
</ol>

<pre data-type="html">
<code>
&lt;form>

&lt;/form>
</code>
</pre>

<ol start="4">
  <li>
    Inside the <code>&lt;form></code> tags, add a heading and paragraph to
    inform users how required fields are marked:
  </li>
</ol>

[chrisdavidmills]

@schalkneethling I see what you are saying here. I think my main concerns are:

1. This would be a lot of effort to update. There are so many instances that would need changing, for something that I'm not sure is really that much of a gain.
2. Having multiple lists as opposed to a single list would look OK visually, but would probably be confusing for AT users?

[schalkneethling]

1. This would be a lot of effort to update. There are so many instances that would need changing, for something that I'm not sure is really that much of a gain.

Yup, very good point

Having multiple lists as opposed to a single list would look OK visually, but would probably be confusing for AT users?

Well, if you "link" them all to the same heading using aria-labelledby it might help but probably not ideal. Well, you might even link the code snippet to the description with aria-describedby but then again, what happens in a markdown world? 😄

I think we might just see what happens if we just always show them with a min-width of 100% as Peter suggested. Might need to tweak it for mobile, but perhaps it will "just work".

I will look into this.