Repository navigation
Copy buttons on sourcecode/figure mess with layout #415
Description
Activity
"helpful"
My original proposal of this feature only added the copy button to RFC8792 folded blocks in order to copy unfolded, the button showed up only on hover, and it did not bloat the vertical space.
BTW, this strong shading (#425) shows up the problem of vertical spacing in
<sourcecode>renderings pretty badly. The offsets from surrounding text is arguably too small on the bottom of the block, but the gutter on the top is a vast gulf. This won't be fixed simply. The<pre>itself has symmetric margins, which would collapse with the bottom margin on<p>, except that the<pre>is nested in another layer of<div>, preventing that collapse. That<div>serves a purpose though, because it contains both the sourcecode and any "figure" caption that might be associated with it.I've discussed this with the team and yep we agree this should be fixed.
Any thoughts on this approach to 'copy' buttons?
Any thoughts on this approach to 'copy' buttons?
Much nicer! And the green popover confirmation could use a style change that fits the light/dark theme too.
Reacted by Martin ThomsonIs that icon in the gutter, like the pilcrow? Could it overlay wide text? GitHub avoids problems like that by having it inside the shaded area, but having the scrollable area short of the full shaded area width.
It adds a gutter so that it doesn't overlay the text.
Reacted by Martin ThomsonThis is now on prod.
I did not expect what I got here.
I guess that this is an instance of #370 (comment) fix side-effects.
The fixes deployed today primarily address the RFC content typography, which now has a clean right edge (not a ragged right edge caused by previous approach to limiting max line length). The copy buttons and wider sidebar are part of this.
There was talk today of narrowing the overall page container to reduce that area in the middle that you've highlighted. This will narrow the
<pre>/<table>overflow areas.Any thoughts on this approach to addressing the area you've highlighted? afaik we don't want to increase the font size and so we're left with few other options.
triage: center line (space on the right and left, not in the center)
Hi @martinthomson , the rfc-editor.org site has a 'feature flag' system for testing changes that might (or might not) become default in the future. Currently there's a layout change that hopefully addresses the
<- w? ->issue.To see this for yourself go to the homepage search and type
//feature-flag-experimentsand then at "Narrower /info/ RFCs enabled?" enable 'narrow-center'.Your feedback would be appreciated, thanks!
I do like that a lot better. I still find the fact that the code blocks are significantly wider than the text a little off-putting, but with the gap reduced it's a lot less noticeable. I do quite like the "narrow-left" option slightly better, even.
A very noticeable bug on these though in the two tables following this paragraph:
Also, the pilcrow location is a bit whacky. https://www.rfc-editor.org/info/rfc9986/#section-13-2 is a bit long, so you will probably need to scroll to get it, but it's about 80% of the way across and so close to the bottom of the shaded area it looks like it's bugged.
Edit to add a picture (I turned pilcrows on unconditionally here):
Also, should SVG images with a figure caption be getting a pilcrow? Because I'm seeing them on https://www.rfc-editor.org/info/rfc9458/#section-6.5.2-6.1.1 (which is also https://www.rfc-editor.org/info/rfc9458/#figure-9).
Hi @martinthomson prod now has the center narrow option by default.
We're progressing the other issues (pilcrow, table formatting) and I'll let you know when we've got something to show.
@martinthomson yes SVGs should, as it's in the original HTML too (which we're now calling compact HTML), but the placement might be wrong.
We're revising the table design currently.
Tables now have separation.
Describe the issue
It appears as though there is a "helpful" button added to every block of code and any ASCII art figures in documents. This is a reasonable feature, but the choice of placement negatively affects the layout of the document. The insertion of the button adds a significant amount of vertical whitespace between the lead-in text and the figure.
The button is also very distracting. It is large, highlighted with shading and a border, and it is in bold text with an icon. All of which draw attention unnecessarily. Consider the alternative affordance on this website:
A small icon like that is no more emphasized than the text. Placing it within the right-side gutter is likely viable if there is a concern about obscuring text. Another option is to avoid showing the control unless the element is active somehow (hover, text highlight, active).
Consider finding a way to present these buttons in a less distracting way.
Link to example rfc
https://www.rfc-editor.org/info/rfc9458/#appendix-A