## Problem Inline `code` inside a live-example preview picks up the docs site's own prose code style instead of GitLab's product style. When an example copies real product markup verbatim, the code element inside the rendered preview doesn't look like the product. I hit this on the "Destructive confirmation" example at http://localhost:2018/components/modal, built from [`contents/components/modal.md`](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/contents/components/modal.md). I want to be clear about scope up front. I'm not asking anyone to touch how inline code looks in docs prose, that style is correct and expected there. The problem is only inside the live-example preview area, where the rendered output is supposed to match the product. ## Evidence Here's the difference. The product, in my GDK, on the project deletion confirmation modal:  The same `code` markup in the live example on the docs site:  The product markup, in [`app/assets/javascripts/groups_projects/components/delete_modal.vue` lines 189-206](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/groups_projects/components/delete_modal.vue#L189-206), renders the confirmation phrase as: ```html <code class="gl-whitespace-pre-wrap">{{ confirmPhrase }}</code> ``` In the running product this shows as dark text on a subtle light-gray rounded background, at normal body text color. That look isn't a `@gitlab/ui` class. It comes from the GitLab application's own reset in [`app/assets/stylesheets/bootstrap_migration_reset.scss` line 61](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/bootstrap_migration_reset.scss#L61-71), which applies a bare `code {}` rule with no class guard: ```scss code { @apply gl-py-1; @apply gl-px-2; @apply gl-text-strong; @apply gl-bg-strong; @apply gl-rounded-base; ... } ``` That rule overrides Bootstrap's own inline-code color. `packages/gitlab-ui/src/vendor/bootstrap/scss/_code.scss` sets a bare `code { color: $code-color; }`, and `$code-color: $pink !default;` is defined in `packages/gitlab-ui/src/vendor/bootstrap/scss/_variables.scss` line 1115. design.gitlab.com never ports the product's reset. It has its own inline-code rule in [`assets/stylesheets/framework/_typography.scss` lines 62-73](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/assets/stylesheets/framework/_typography.scss#L62-73): ```scss code:where(:not([class])) { @apply gl-text-default #{!important}; @apply gl-bg-strong; @apply gl-rounded-default; @apply gl-font-monospace; @apply gl-px-2; @apply gl-py-1; @apply gl-whitespace-pre-wrap; @apply gl-break-keep; font-size: 90% !important; word-wrap: normal; } ``` The `:not([class])` guard is the problem. Real product markup almost always puts a class on `code` (here it's `gl-whitespace-pre-wrap`), so this rule never matches it. Once that's out of the running, the only remaining rule that matches a classed `code` is Bootstrap's bare `code { color: $code-color; }`. `assets/stylesheets/app.scss` line 2 imports `@gitlab/ui/src/scss/gitlab_ui` (which pulls in Bootstrap) before `framework/typography` loads at line 20, so Bootstrap's rule is what's left standing. That's the pink monospace text with no background I'm seeing in the live example. design.gitlab.com already has a pattern for this exact kind of problem. [`assets/stylesheets/framework/_markdown.scss` line 49](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/assets/stylesheets/framework/_markdown.scss#L49) excludes live-example content from a prose rule: ```scss a:not(.live-example-preview *)[href] { @apply gl-underline; } ``` That's the underline rule for links in prose, written so it doesn't reach into `.live-example-preview`. Nothing equivalent exists for `code`. ## Where I think the fix goes [`components/live_example_layout.vue`](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/components/live_example_layout.vue) renders every live-example preview inside `.live-example-preview` (the `<template #default>` block). A scoped override targeting `.live-example-preview code` would go in that component's `<style scoped>` block, using `:deep()` since the preview content is slotted in from outside the component. It would need to reproduce the product's actual `code {}` reset from `bootstrap_migration_reset.scss`, not just drop the pink color and leave `code` unstyled. The other option is to follow the `_markdown.scss` line 49 pattern directly: tighten `_typography.scss`'s `code:where(:not([class]))` selector, or add a sibling rule, to exclude `.live-example-preview` the way the link rule does, then give `.live-example-preview code` the product's reset directly, probably in `_markdown.scss` next to the link exclusion. I don't want to guess which of these fits the codebase's conventions better. Does `_markdown.scss` or the component's own scoped styles usually own preview-only overrides here? And should the fix literally copy `bootstrap_migration_reset.scss`'s rule, or is there a reason to share that reset some other way so it doesn't drift the next time the product changes it? ## Done looks like - [ ] `code` in docs prose (`.md` content outside `.live-example-preview`) keeps its current docs-site style, unchanged. - [ ] `code` rendered inside `.live-example-preview` shows the product's style, dark text on a subtle light-gray rounded background, matching `bootstrap_migration_reset.scss`'s `code {}` rule. - [ ] The "Destructive confirmation" example on http://localhost:2018/components/modal (from `contents/components/modal.md`) renders its confirmation phrase with the product look, not pink monospace text. - [ ] I want a check of other live examples that render inline `code`, in case the same problem shows up elsewhere on the site.