This site's articles get published through a Drupal role with exactly one text format available to it: restricted_html. No <pre>, no <img>, no <h1>, no <div> — the entire allowed tag list is a, em, strong, cite, blockquote, code, lists, definition lists, and headings from h2 down. Every code sample, every terminal log excerpt, every piece of technical evidence in the last several articles on this site had to fit inside that list, because there was no other option. It turned out to be a better constraint than I expected going in.
What actually breaks first
The obvious casualty is <pre>. A block of terminal output — a stack trace, a wall of nginx error log lines, a before-and-after config diff — normally goes straight into a monospace block and stays exactly as formatted as it was in the terminal, whitespace and all. That option doesn't exist here. Anything that would have been a <pre> block has to become something else, and the only real candidate left in the tag list is a plain list: one line per <li>, each one wrapped in <code>.
Writing up a real outage, that meant a wall of nginx log lines like "Unable to open primary script: index.php (Permission denied)" couldn't just get pasted in as a block quote from the terminal. It had to become a short, deliberately trimmed list — a handful of the actual log lines that mattered, not the full noisy dump. Same with a wall of composer dependency-resolution errors: forty near-identical lines in the terminal became two representative ones in the article, because a list forces you to decide which lines are actually carrying information and which are just repetition.
The trade that's easy to miss
This isn't a purely upside trade, and it's worth being honest about what it actually costs: anything where alignment or indentation carries meaning — a YAML file, a Python snippet, a table of columned output — loses that structure completely. A list item is a single line with no internal whitespace guarantee once it's rendered. Multi-line indented content either has to become several separate list items that lose their relative indentation, or it has to be described in prose instead of shown verbatim. There's real information lost there, and no amount of reframing makes that not true.
What the constraint actually bought back
What surprised me is that the list format, for the specific case of "here's the sequence of things that happened," reads better than the block it replaced would have. A <pre> block asks a reader to parse an undifferentiated wall of monospace text themselves and find the two lines that matter. A short, curated list already did that work — each line is its own scannable item, and trimming a fifty-line error dump down to the three lines that actually explain what happened is a genuine editorial decision the format forces you to make instead of letting you defer it to the reader.
The other quiet fix: paragraphs you don't write
The same format doesn't allow a literal <p> tag either, which looks like it should be a bigger problem than it is. Drupal's own paragraph filter runs after the tag-stripping step, not before, so it adds the paragraph and line-break tags itself from plain, blank-line-separated text — meaning the actual authoring format for every article on this site is closer to plain text with inline markup than to hand-written HTML. It's a small thing, but it means the formatting a reader sees was never something I had to construct directly. It's a side effect of writing plainly and letting the constraint do the rest.