@media types beyond screen

The @media rule in CSS isn't limited to screen — it supports several media types that target different output devices. The most commonly used are screen (computers, tablets, phones), print (printers and print preview), and all (every device, which is the default). There's also speech for screen readers, though browser support for speech-specific properties is limited.

Print styles are the most practical use of non-screen media types. When a user prints a page (or uses print preview), @media print rules apply. You typically want to hide navigation, footers, ads, and interactive elements, switch to black text on white background, remove shadows and decorative elements, and ensure content fits on paper.

@media print {
  /* Hide non-essential elements */
  nav, footer, .sidebar, .ads, .no-print {
    display: none !important;
  }

  /* Optimize for paper */
  body {
    color: #000;
    background: #fff;
    font-size: 12pt;
    line-height: 1.5;
  }

  /* Remove decorative styles */
  * {
    box-shadow: none !important;
    text-shadow: none !important;
  }

  /* Show URLs after links (so printed links are useful) */
  a[href]::after {
    content: " (" attr(href) ")";
    font-size: 0.8em;
    color: #666;
  }

  /* Prevent awkward page breaks */
  h1, h2, h3 {
    page-break-after: avoid;
  }

  img {
    page-break-inside: avoid;
    max-width: 100% !important;
  }

  /* Force page breaks where needed */
  .page-break {
    page-break-before: always;
  }
}

The a[href]::after trick is particularly clever — it appends the URL after each link in parentheses, so printed pages show where links point. The page-break-* properties control where content splits across pages, preventing headings from appearing alone at the bottom of a page.

You can also specify media types on <link> elements to load entire stylesheets conditionally. The browser still downloads all stylesheets regardless of media type (for faster switching), but only applies the matching ones. This means print stylesheets don't block rendering of the screen version.

<!-- Applied to all devices (default) -->
<link rel="stylesheet" href="base.css">

<!-- Only applied on screens -->
<link rel="stylesheet" href="screen.css" media="screen">

<!-- Only applied when printing -->
<link rel="stylesheet" href="print.css" media="print">

<!-- Combining media type with media features -->
<link rel="stylesheet" href="large-screen.css" media="screen and (min-width: 1024px)">

<!-- The 'not' keyword inverts the query -->
<link rel="stylesheet" href="not-print.css" media="not print">

Even though the browser downloads all linked stylesheets, non-matching ones are given low priority and don't block the critical rendering path. This is why separating print styles into their own file can slightly improve initial page load performance.

Modern CSS relies more on media features (width, height, prefers-color-scheme, hover, pointer) than media types. The deprecated types like handheld and tv were replaced by feature queries that describe device capabilities rather than device categories — because a modern phone has more in common with a desktop browser than with the feature phones handheld was designed for.

/* Media type: targets a device category */
@media screen { /* ... */ }
@media print { /* ... */ }

/* Media features: targets device capabilities (preferred approach) */
@media (max-width: 768px) { /* Small screens */ }
@media (hover: none) { /* Touch devices — no hover capability */ }
@media (prefers-color-scheme: dark) { /* User prefers dark mode */ }
@media (prefers-reduced-motion: reduce) { /* User wants less animation */ }

/* Combining type + features */
@media screen and (min-width: 1024px) and (hover: hover) {
  /* Desktop with mouse — safe to use hover effects */
}

The shift from types to features reflects how the web evolved. Instead of asking 'is this a TV?' you ask 'does this device support hover?' — which is more useful because a smart TV with a remote might or might not support hover-like interactions.

This question tests whether you know CSS media queries beyond just responsive breakpoints. Interviewers want to see that you've thought about print styles (a common real-world need), understand the difference between media types and media features, know which types are deprecated and why, and can discuss the evolution from device-category targeting to capability-based queries.