Safe display behavior
Runtime Presentation
Vibecodr uses one presentation profile for each published runtime artifact so a vibe keeps the same intended shape across player, focus, Studio preview, embeds, and vanity domains.
Public explanation of cross-surface runtime presentation profiles.
Implementation focus
Use this when a vibe looks clipped, cramped, over-scaled, or different between player surfaces, or when deciding whether a project should behave like a fixed stage, responsive app, document, or unknown fallback.
Expected outcomes
- Understand why fixed sketches scale differently from responsive apps.
- Know why child DOM measurements do not silently resize the public player after mount.
- Know that player, focus, Studio, embed, and vanity surfaces use the same profile even when the route or viewport size changes.
- Report presentation problems with the surface and intended layout named clearly.
Why vibes keep their shape
A published vibe can be a game, canvas sketch, spreadsheet, whiteboard, chat shell, document, dashboard, poster, or something harder to name. Vibecodr does not ask every surface to guess from the iframe after it loads. The published runtime manifest carries a presentation profile that tells the player how the app should be hosted safely.
That profile travels with the same runtime facts used by player pages, focused overlay, Studio preview, embeds, and vanity domains. The result should feel simple to viewers: the same vibe keeps the same intended shape wherever it opens.
- Fixed games and sketches keep a stable logical stage and scale into the available space.
- Responsive apps fill the available surface instead of being postcard-framed.
- Long pages and documents keep their scroll behavior accessible.
- Unknown or ambiguous work uses a conservative full-surface fallback instead of being clipped.
How Vibecodr decides
The profile combines safe evidence from the published artifact: authored hints, build-time HTML classification, publish-time browser probes, runtime-manifest facts, and conservative platform defaults. Runtime reports can help diagnose what an app is doing, but the parent page does not let child DOM measurements take over product layout.
The important rule is host-owned presentation. Vibecodr owns the outer surface, the iframe viewport, and the display fit; your app owns what it draws inside that viewport. The same profile can be route-specific and size-aware, so a project can behave like a page on one route and a fixed sketch on another without each host inventing a separate rule.
- Use stable explicit dimensions for fixed canvas or game worlds when those dimensions are part of the experience.
- Generated or advanced HTML can declare obvious presentation intent with `data-vc-kind`, `data-vc-scene`, `data-vc-chrome`, and `data-vc-scroll-region` so Vibecodr records that shape in the manifest.
- For fixed-framed canvas apps with side panels, footers, toolbars, or HUDs, size the canvas from the primary scene container. Do not size that canvas from `window.innerHeight`, `100vh`, or body height unless the whole app is intentionally a viewport scene.
- Let responsive apps respond to the viewport naturally instead of hardcoding accidental page measurements.
- Keep critical controls reachable at smaller sizes; feed cards may show a safer preview when live interaction would be cramped.
- Use fullscreen/focus when an app needs more room than a feed or embed can responsibly provide.
- If Vibecodr cannot certify a stronger shape, it uses a safe fallback instead of clipping controls or suppressing reachable scroll.
What creators should expect
Most creators do not need to configure this directly. Publish and BUMP IT create new runtime facts, and Vibecodr normalizes the presentation profile as part of playback. When a project changes from a fixed sketch into a full responsive app, publish a new cut so the profile can move with the release.
If a live surface looks wrong, name the surface and the expected behavior when reporting it: player, focus, Studio preview, embed, or vanity domain. That helps support compare the same profile across every host instead of debugging one page in isolation.
- Player, focus, Studio, embeds, and vanity domains share the same presentation profile.
- Presentation profiles are about safe display behavior, not source visibility or private project settings.
- A runtime report can explain a mismatch, but it should not silently resize the public page after mount.
- BUMP IT is the right path when the intended layout changed with the app itself.
Example and read next
Example: a fixed-size canvas game looks right in Studio but cramped in an embed. Publish a new cut with stable presentation facts, then verify player, focus, Studio, embed, and vanity surfaces keep the same intended shape.
Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.
- Read next: Source & Versions (/docs/source)
- Read next: Dependency Determinism (/docs/dependency-determinism)
- Read next: Embeds (/docs/embeds)
- Read next: Studio (/docs/studio)