Styles for the `pre` tag are displayed incorrectly when parsing the `readme.txt` file

[blackstar1991]

Can you please fix the display for a block of code in one line. For example

/wp-json/gigroute-events/v1/events
on page site ​https://wordpress.org/plugins/gigroute-events/ transfor in this

Added scrolling elements where they are not needed

or fpr next blocks in plugin

/wp-json/gigroute-events/v1/events

/wp-json/gigroute-events/v1/events?mode=upcoming

/wp-json/gigroute-events/v1/events?mode=all&year=2026

/wp-json/gigroute-events/v1/events?mode=all&year=2026&month=4

/wp-json/gigroute-events/v1/events?country=ukraine&city=kyiv&event_type=concert

/wp-json/gigroute-events/v1/events?start=2026-04-01&end=2026-04-30

/wp-json/gigroute-events/v1/events?mode=all&page=2&per_page=20

set up for

pre {
  overflow: auto;
}

[dd32]

@blackstar1991 What browser/OS are you using? I'll attach what I currently see.

[blackstar1991]

Windows 10 Chrome 148
I see this styles for tag pre
​https://s.w.org/wp-content/themes/pub/wporg-plugins-2024/css/style.css?ver=1774331365

pre {

background-color: #f7f7f7;
border: 1px solid var(--wp--preset--color--light-grey-1);
overflow: scroll;
padding: 20px;

}

[softglaze]

Environment

• OS: Windows 11 Pro N 25H2
• Browser: Chrome 150, clean guest profile

What I ran

console.table([...document.querySelectorAll('pre')].map((el, i) => {
  const cs = getComputedStyle(el);
  const bx = parseFloat(cs.borderLeftWidth) + parseFloat(cs.borderRightWidth);
  const by = parseFloat(cs.borderTopWidth) + parseFloat(cs.borderBottomWidth);
  return {
    i,
    overflowX: cs.overflowX,
    overflowY: cs.overflowY,
    overflowsX: el.scrollWidth > el.clientWidth,
    overflowsY: el.scrollHeight > el.clientHeight,
    vBarPx: Math.round(el.offsetWidth - el.clientWidth - bx),
    hBarPx: Math.round(el.offsetHeight - el.clientHeight - by),
    text: el.textContent.trim().slice(0, 30)
  };
}));

This snippet measures the space consumed by the scrollbars on the pre blocks. vBarPx represents the width taken by the vertical scrollbar, and hBarPx represents the height taken by the horizontal scrollbar.

Current behaviour

Page	row	overflowX	overflowsX	overflowsY	vBarPx	hBarPx
/plugins/gigroute-events/	0	scroll	false	false	15	15
/plugins/gigroute-events/	1	scroll	true	false	15	15
/plugins/softglaze-click-to-chat/	0	scroll	true	false	15	15

gigroute-events-before-overflow-scroll.png​
click-to-chat-before-overflow-scroll.png​

As the table shows, overflowsY is false on every row, yet vBarPx still reserves 15px. On row 0 of the GigRoute page, both overflowsX and overflowsY are false, but both scrollbars still consume 15px each.

With overflow: auto

I applied the change in the browser to check the effect:

const s = document.createElement('style'); s.id = 'fix-8264'; s.textContent = 'pre { overflow: auto; }'; document.head.appendChild(s);

I confirmed window.getComputedStyle(document.querySelector('pre')).overflowX returned scroll before the injection and auto after, ensuring the style change actually applied.

Page	row	overflowX	overflowsX	overflowsY	vBarPx	hBarPx
/plugins/gigroute-events/	0	auto	false	false	0	0
/plugins/gigroute-events/	1	auto	true	false	0	15
/plugins/softglaze-click-to-chat/	0	auto	true	false	0	15

gigroute-events-after-overflow-auto.png​
click-to-chat-after-overflow-auto.png​

With overflow: auto, vBarPx dropped from 15 to 0 on every row. hBarPx dropped from 15 to 0 where overflowsX was false, and stayed at 15 where overflowsX was true. The fix returned the unused gutters and kept the horizontal scrollbar exactly where the content genuinely overflowed.

Source

• wordpress.org/public_html/wp-content/themes/pub/wporg-plugins-2024/client/components/_code.scss
• overflow: scroll is on line 6 (and sets no explicit height constraint).

[blackstar1991]

I still see this problem ​https://ibb.co/9kTXVSy6

[softglaze]

Looking at why the one-line snippets render as blocks rather than inline, this appears to come from the readme parser rather than the stylesheet.

The rule

Markdown::code_trick() in plugin-directory/class-markdown.php rewrites any backtick span that begins a line into a four-space indented Markdown block:

// Markdown can do inline code, we convert bbPress style block level code to Markdown style.
$text = preg_replace_callback( "!(^|\n)([ \t]*?)`(.*?)`!s", array( $this, 'code_trick_indent_cb' ), $text );

That is line 48. The indent is applied in code_trick_indent_cb(), and Markdown then renders the result as <pre><code>. Consecutive indented lines coalesce into one block, which is why the seven query examples appear as a single element rather than seven.

Control, on the same page

The readme for the plugin linked in the description contains the same string in both positions.

In the Description it starts a line:

`/wp-json/gigroute-events/v1/events`

and renders as:

<pre><code>/wp-json/gigroute-events/v1/events
</code></pre>

In the FAQ the identical string appears mid-sentence:

Yes. Public event data is available at `/wp-json/gigroute-events/v1/events`.

and renders inline, as <code>/wp-json/gigroute-events/v1/events</code>.

Across the whole rendered page: 9 readme lines begin with a backtick span and produce 2 block elements; 9 lines carry backticks mid-sentence and produce 17 inline elements. The rendering follows where the backtick sits in the line, not what it contains.

What follows

Because the block element is produced at parse time, a change to the pre styling would change how the box looks but not whether a box is produced at all. Writing a snippet inside a sentence, so the line does not begin with a backtick, renders it inline.

Whether the parse rule itself should change is not something I can assess — it is long-standing and other readmes will depend on it.