Display and layout

Updated: Sep 19, 2026

How the display renders

Meta Ray-Ban Display glasses use an additive-light display. An unlit black pixel adds no light, while brighter pixels add light over the wearer’s view. The surroundings therefore remain part of the visual result.
Use an unlit black page canvas. Add bounded surfaces where text or controls need separation from the surroundings instead of painting a bright full-screen background. Validate readability over both bright and dark real-world scenes. Communicate state with structure or text as well as color.

Size from the viewport

The device display is 600 × 600, but the page should not hardcode a 600-pixel layout. Treat 600 × 600 as a validation target and derive application dimensions from the browser’s actual viewport. This keeps the page usable in desktop preview, text scaling, and future host configurations.
Use the standard responsive viewport declaration:
<meta name="viewport" content="width=device-width, initial-scale=1">
Keep browser scaling available by omitting user-scalable=no.
A framework-neutral page shell can fill the available viewport without fixing its dimensions:
* {
  box-sizing: border-box;
}

html,
body,
#app {
  inline-size: 100%;
  block-size: 100%;
}

body {
  margin: 0;
  min-inline-size: 0;
  background: #000;
}

.app-shell {
  display: grid;
  grid-template-rows: minmax(0, 1fr) auto;
  inline-size: 100%;
  block-size: 100%;
  overflow: hidden;
}

.content {
  min-inline-size: 0;
  min-block-size: 0;
}
Use percentages, flexible grid or flex tracks, intrinsic content sizes, and logical CSS properties. Reserve media queries for meaningful layout changes rather than forcing a 600-pixel width or height.

Keep controls away from obstructed edges

System UI and focus feedback can use space near the display edges. Keep important text and interactive controls comfortably inside the viewport. Full-bleed backgrounds and noninteractive artwork can extend farther than controls.
Use a safe-region value only when the platform documents it for the supported runtime. Test every edge control on the device and verify that system UI, focus feedback, and pressed states remain visible.

Make overflow intentional

Keep document scrolling intentional and keep content reachable. When content exceeds the available area:
  • Prefer one scroll owner per axis.
  • Give the scroll region a flexible track such as minmax(0, 1fr) and set min-block-size: 0 on shrinking ancestors.
  • Keep the selected control visible as directional navigation moves through the region.
  • Keep one scroller on each axis so focus and scroll ownership remain clear.
  • Use pagination or progressive disclosure when it makes the task clearer.
  • Provide a visible cue that more content is available.
For a short, single-task screen, a static layout may be appropriate. For longer content, intentional scrolling is preferable to clipping or shrinking everything until it becomes unreadable.

Use readable type and surfaces

Use relative type sizes and adequate line height rather than fixed-height text boxes. Allow text to wrap and test the longest localized strings. Reserve large type for the information that needs the strongest hierarchy.
Use sufficient luminance contrast, stroke weight, spacing, and bounded surfaces to separate content from the wearer’s surroundings. Bright saturation by itself does not guarantee readability. Make focus and selection visible through more than color alone.

Validate the complete layout

Before publishing, verify:
  • the page at a 600 × 600 browser viewport without fixed-width assumptions;
  • the physical device in bright and dark surroundings;
  • browser text scaling and the longest supported localized strings;
  • directional traversal through every interactive control;
  • focus and pressed feedback near each edge;
  • the empty, loading, error, and maximum-content states;
  • intentional scrolling, clipping, and overflow behavior; and
  • that critical content remains reachable without a mouse, touchscreen, or continuous drag input.