feat: Adds print styles for Starlight docs pages

[tony-sull]

What kind of changes does this PR include?

• Changes to Starlight code
• Something else!

Description

• Adds print-specific styles for pages built with Starlight
• Hides navigation elements like the sidebars, search, and mobile menu
• Forces the light theme color palette when printing

[changeset-bot]

🦋 Changeset detected

Latest commit: 20cf394

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@astrojs/starlight	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

✅ Deploy Preview for astro-starlight ready!

Name	Link
🔨 Latest commit	20cf394
🔍 Latest deploy log	https://app.netlify.com/sites/astro-starlight/deploys/6761c124bc992d0008d2227d
😎 Deploy Preview	https://deploy-preview-157--astro-starlight.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 (no change from production) Accessibility: 100 (no change from production) Best Practices: 100 (no change from production) SEO: 100 (no change from production) PWA: - View the detailed breakdown and full score reports

---

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

[astrobot-houston]

size-limit report 📦

Path	Size
/index.html	6.96 KB (+0.54% 🔺)
/_astro/*.js	21.19 KB (0%)
/_astro/*.css	13.75 KB (0%)

[tony-sull]

@delucis thoughts on whether this feature is worth merging or should I close it?

I'm still a bit torn on the increase in bundled CSS versus pulling all print styles out to a global print.css file. We could definitely move the styles out of layouts/components to avoid the bundle size increase, as long as the core layout doesn't change too much it really shouldn't be too risky since the changes are largely just hiding navigation elements.

[delucis]

I think my preference is likely for pulling this out to a separate global file to avoid extra downloads. (We’d need a ?url import I’d guess to pass that to the appropriately configured style tag.)

I am a bit torn because as you highlighted, that does come with extra maintenance complexity. Especially as this is exactly the kind of thing we’re likely to forget to check as we add stuff 😅 That said, most stuff is done pretty safely via print:hidden, so we should be OK with that approach?

(There’s a chance even doing that will fail the CI check here — it’s a bit of a rough tool at the moment, just globbing dist/*.css and measuring that gzipped, so even CSS that doesn’t actually get loaded is liable to get taken into account. Tried another approach and found it unreliable, but this is definitely on a list of tooling to improve.)

Let me know if you’re happy doing that or if you’d prefer me to tackle!

[tony-sull]

@delucis Yep that's no problem, I'll refactor that this morning and pull the styles out into a global sheet 👍

[tony-sull]

@delucis done! Everything is moved out to the separate print.css file

Looks like the HTML size-limit is failing by ~1kb, that should just be from the extra print: class names + the stylesheet <link>

[tony-sull]

Best laid plans! It turns out there isn't currently a great way to get around the CSS being inlined there, I'm going to close this out for now as blocked.

@delucis, @bluwy, and I were catching up on Discord and it sounds like this may be worthy of a feature in Vite to be able to ?url import and make sure it's never inlined. My vote is still on ?no-really-i-want-a-url, but I'll leave that up to the Vite team to decide 😄

[delucis]

Will need to wait on withastro/astro#12758 to use the ?url&no-inline import query without type errors.