Gap in code blocks in 0.27.0 with Starlight

[Dylan Anthony]

In trying to update in this PR, the code blocks in the preview have a margin between the frame header and the content.

[Hippo]

This is a Starlight-specific issue that is created by this Starlight CSS rule (taken from your preview) that introduces margins between adjacent siblings:

.content:where(.astro-ml6ntd6l) :not(a,strong,em,del,span,input,code)+:not(a,strong,em,del,span,input,code,:where(.not-content *)) {
    margin-top: 1.5rem;
}

You can see the fix for this behavior in my PR to add Expressive Code to Starlight:
https://github.com/withastro/starlight/pull/742/files#diff-beb0bce82b7f4b09c96906f85bed4c5ff5f3968064121f03ae605f8b06295c58R53-R60

In short, we need to add the CSS class not-content to the rendered blocks to avoid the adjacent sibling margin rule from matching.

Until the Starlight integration PR has been merged, you can add the same trick to your astro.config.mjs:

import { default as expressiveCode, addClassName } from 'astro-expressive-code';

// (your other code)

/** @type {import('astro-expressive-code').AstroExpressiveCodeOptions} */
const expressiveCodeOptions = {
  theme: ["github-light", "github-dark"],
  frames: {
    removeCommentsWhenCopyingTerminalFrames: true,
  },
  plugins: [{
    name: 'Starlight Plugin',
    hooks: {
      postprocessRenderedBlock: ({ renderData }) => {
        addClassName(renderData.blockAst, 'not-content');
      },
    },
  }],
};

[Hippo]

Just a note on why this is happening since v0.27: Previous versions of Expressive Code used CSS selectors of higher specificity to style the code blocks.

While the old CSS selectors included a dynamic hash and looked like .ec.ec-s1gwf .frame, the new selectors don't need this hash anymore - they are now static and look like .expressive-code .frame, which is one class selector less than before. This seems to be the reason why the Starlight adjacent sibling margin rule now "wins" and interferes with the code block styling.

I could theoretically add another (static) class back in again to counteract this, but I wanted to see first if the not-content solution works well enough to avoid fighting specificity wars.

Hope that helps!

[Hippo]

This is fixed now with the release of Starlight v0.13 (how to update). You can have a look at the release notes to see how to migrate your Expressive Code configuration into the new integration built into Starlight.