Tweak inline code and preformatted blocks

[patrickhlauke]

Adds a contrasting border to preformatted blocks (mainly for code blocks, but a few others), gives a subtle style to inline code elements in prose

Relates to #4193 and applies suggestion 1 (the box around the pre) and a slightly tweaked variant of suggestion 2b (the "subtle" style for code, with some extra selector shenanigans to avoid having the background when it's inside a link or already in a pre block)

EDIT: as a quick before/after, see https://www.w3.org/WAI/WCAG22/Techniques/html/H85 and the preview here https://deploy-preview-4683--wcag2.netlify.app/techniques/html/h85

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	3a0a68a
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/68f299a3ea7b8e0008cbd074
😎 Deploy Preview	https://deploy-preview-4683--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[patrickhlauke]

@kfranqueiro do changes to CSS not get reflected in preview? https://deploy-preview-4683--wcag2.netlify.app/techniques/html/h85

[kfranqueiro]

Thank you, Mario, but our CSS is in another castle!

additional.css is only used by the wcag20 folder. You probably want base.css.

[patrickhlauke]

Thanks for the pointer @kfranqueiro ... updated, and the preview now shows up my change :)

[adampage]

Hmm, yeah, to @kfranqueiro’s point, these two consecutive code blocks in ARIA19’s Example #1 appear to be one.

Perhaps some explicit margin for <pre>s, or try relocating those new styles to pre > code?

Or does those two <code> elements need to be contained by only one <pre>, in that particular case? We could search the repo for adjacent pre > code + code instances and tweak them in the markup.

[patrickhlauke]

Example of pre being used for something OTHER than code blocks https://deploy-preview-4683--wcag2.netlify.app/techniques/text/t1

[kfranqueiro]

RE multiple codes in one pre, I think Patrick had identified and separated some of those in the original big PR that I had split things out of, so yeah we could hunt those down (or make the build system do it). They technically cause no issue for highlight.js, but they do potentially complicate these styles.

I guess there's also still the question of whether the styles are worth the trouble, since I think we had a few votes of ambivalence or actual -1 in the issue.

On that note, some other edge cases to consider for inline code:

• Headings, e.g. h1 and h3 in H39
• This SCR20 mappings table might turn out to look a little odd, but other cases inside tds that are inline with other text look fine
• There are a few in G208's Examples that effectively look like they should be proper highlighted code blocks, which we could decide to tackle separately

[patrickhlauke]

For things like multiple code blocks in a single pre, and cases like G208 ... I'd say these new styles actually visually surface issues in the original markup that should be addressed in the markup.

Regarding code in headings, I actually intentionally kept that in, but those can be easily excluded by expanding the :not(:is(pre, a)) > code selector.

ditto things like code as direct descendant of a td or th

[patrickhlauke]

I think I caught all instances where we have two code blocks inside the same pre 70c4816

[patrickhlauke]

I'll add here that we can also soften the border around the pres a bit, as it's not the only visual indication that it's a code block (indentation, margin, different typeface, all provide visual hints). so we could make the border less contrasty (e.g. using var(--line-grey); like the border around the "About this technique" at the top of techniques for instance)

EDIT: done that with the next commit

Example (zoomed out to show both the "About this technique" and a newly styled code block):

Obviously personal preference on whether or not these styles are even worth pursuing, but for my own part, I find them much more immediately "skimmable" as I read through a technique, seeing exactly where code blocks are, where HTML elements/attributes are being mentioned (rather than only finding them by carefully reading a sentence), etc. Arguably yes, because these styles are not all 3:1, some users will not be seeing them ... but I think these styles fall more under "eye candy" than actual "required for understanding/meaning"...

[patrickhlauke]

thanks for spotting the </code> ... <code> variants there @kfranqueiro