Déjà Viewport: Designing for Dual Screen Devices

• Device Posture API
• Viewport Segments API

Thank you, Dave. I'm excited to be here. I did not, I retired this talk like four years ago because no one was interested in this. So Dave messaged me and was like, do you wanna speak about designing for dual screen devices? And I was like, okay, sure. So it was, this is Deja Viewport. I really wanted to name it Deja Duo because when I first was giving this talk, I was talking about the Surface Duo four years ago and it was discontinued in 2024.

So two screens, one hinge, folded too soon, rest in peace, no.

Okay, so when I first started talking about these APIs that I'm gonna talk about tonight, they were very early proposals. So they were still in origin trials and they were still being developed. The standards and specs were still being worked on. So I've got to sort of watch them evolve over the years into these really easy to use and ergonomic APIs that build on existing concepts that already exist on the web.

And so the big update since I first gave this talk four years ago, they're not experiments anymore. They've actually shipped in chromium browsers. Apple has released its first foldable iPhone and Safari does actually have these APIs behind a flag in Safari beta. So they will be coming to Safari. So that's exciting. And I think the coolest thing about these APIs is how seamless they are to integrate into your code.

So you can progressively enhance your website or your web app for a foldable device and deliver an experience that delights people who are on those devices. And I hope people are more excited about designing for these devices now than they were four years ago, because they weren't excited then.

Because despite what the memes would have you believe, implementing a design for these devices is not that hard. There should be more thought put into whether utilizing the two screens actually makes sense for your experience, and then decide to enhance from there. So a quick about me. So I'm currently at Igalia, which is an open source consultancy. I've been there since 2024. I am AP, I'm on the web platform team doing all sorts of different things.

I also do design for Servo. If you've ever heard of Servo, it's an independent embeddable browser engine built in Rust. And in case you're wondering what an open source consultancy does, so my team gets hired to work on web platform features. This is just like a demo that I have created and not shared yet of things that Igalia has implemented for the web. So we're responsible for Has, CSS Grid, Focus Visible. If you're familiar with MathML, there's been a lot of work done with MathML, word wrapping, line breaks, all sorts of things.

So you can hire us to implement these things in Chromium, Gecko, and WebKit. So it's pretty cool. And before that, I was at a startup called RapidAPI doing developer experience. They no longer exist, which is a whole other story that could be a talk. And before that, I was at Microsoft Edge working on the web platform and developer experiences, which is how I wound up here talking about foldable devices.

So I'm gonna talk about some multi-screen device history 'cause I always like to look at how we got to this point, talk a little bit about the evolution of responsive web design, then the technology that is available now. So viewport segments, CSS environment variables for layout, the JavaScript viewport segments and device posture APIs, and then we'll just look at some examples, testing and browser support. So the concept of foldable devices has been around since at least 2004, probably earlier than that, these things were in development, but this was just a few years before single-screen smartphones took hold.

So in 2004, we saw the first dual-screen touchscreen concept from a firm called V12. It was a dual-screen touchscreen laptop, which looks quite chunky and bulky. I can't imagine trying to carry that around. And then in 2006, we saw something called the Radius, which actually, you were able to pull out and then retract. And then in 2008, Nokia was actually working on this matrix-type looking device that folded out into a tablet, and then it could fold into a smartphone, and then even fold in to a wristwatch.

And after these devices, we got a lot more concepts and prototypes. Lots of these I've never even heard of, but throughout the years, these have all been worked on up until 2019, when more consumer-friendly devices were announced and started to hit the market. So these devices have been under development for well over 20 years, so they didn't just appear out of nowhere. And since those first consumer devices in 2019, foldables have gone from a novelty to a regular product category.

So Samsung's Fold and Flip lines are on their seventh and eighth generations. Google has the Pixel Fold line, and we now have even trifolds from Huawei and Samsung that unfold into a tablet. And so, like I mentioned, the Surface Duo, this is the device that a lot of the web work started with, and that one has been discontinued. But the APIs outlive the device, which is exactly the point of the solid web standards work.

They were designed for any device, whether it had a Fold or a hinge, and not for one specific product. So now, this fall, Apple has its first foldable, the iPhone Duo, and that went on sale just at the end of October. And the foldable market isn't standing still either, so it's estimated around 20.6 million foldables will ship in, or they shipped in 2025, and they're expecting about 20 to 30% growth in 2026 because of Apple, and then Lifetime foldables, they're expecting those shipments to pass 100 million units by the end of this year.

And so in the grand scheme of the smartphone market, that's really not a lot, but it's like 2%. But it's still tens of millions of devices in people's pockets, and so foldables aren't going anywhere. So what do we need to think about when it comes to designing for these devices? The good news is it's nothing new. It's something we're already familiar with. It's just responsive design. Since Ethan Marcotte coined the term in 2010, we've been designing for layout that adapts to whatever screen the user has, rather than just one specific device.

And foldables are just the next step in that. So we have a few main shapes of device. We have dual screens with an actual physical hinge, and that obscures content. You have a book-style foldable, like the Galaxy Z Fold and the Pixel Fold, and now the iPhone Duo is like this. And then we actually have flip phones that sort of are the vertical fold, like the Galaxy Z Flip and Motorola Razr.

So I want you to come away from this talk with the idea that these devices are, again, just the next step in responsive design and progressive enhancement. This isn't a huge new obstacle for you to go build for, and I don't want you to fear the hinge or the fold. I want you to get excited about being creative for devices that are already in people's pockets. So if you did happen to see this talk four years ago,

there's quite a bit, a little bit that's changed, primarily in the JavaScript part of the technology. But since then, so the APIs went through origin trials. The engineers gathered community feedback about the design of the APIs. They integrated that feedback, and these have now shipped, like I said. The device posture API is something that came after my time working on this. And so that shipped in Chrome and Edge in early 2025.

And the Viewport Segments API shipped in Chrome and Edge in June 2025. So even though I was talking about this in the end of 2021, 2022, that's just like how long the standards process can take. It can take years to make sure that we're designing APIs in a way that lasts. One change to note, like I said, the JavaScript Segments property now lives on Window Viewport, not Window Visual Viewport.

And then, like I said, Safari has also started implementing these APIs and they're behind a feature flag. So you really want to treat these as progressive enhancement. They shouldn't be the, you shouldn't make your whole experience for your website or app for a dual screen. It should just be something that gets enhanced for those who are actually on those devices.

So with CSS, Viewport Segments has a media feature and environment variables. And in JavaScript, we have the Viewport Segments API. So these started their life at Microsoft as a screen-spanning media feature and a Window Segments enumeration API.

And so these were, again, reworked to build on the concept that the web already had, which is the Viewport. And so now we also have this device posture media feature. So Viewport Segments tell you where the geometry of the screens are. Device posture tells you how the device is folded. So if it's like a book or a laptop or if it's flat and open. And the specification calls flat continuous. So again, this is available as a CSS media feature and a JavaScript API.

And we'll look at that syntax in a moment. So from the beginning, these features were designed to be easy to work with. The engineers really wanted to focus on simplicity and ergonomics. Again, we wanted you to spend time thinking outside the box and being creative than trying to figure out how to integrate this into your existing architecture. So the first one I'm gonna feature, I'm gonna touch on is the CSS viewport segments media feature.

So these are just, so dual screen devices are just another responsive design target. So just as you use media queries in your CSS today to detect and serve styles based on screen size, you can also use a media query to detect this new class of device using the viewport segments media feature. So we can have two values with our media feature. One is horizontal viewport segments and an integer. And this represents the state of the device when it is in, when the device hinge is vertical and the viewports are split by this hinge or fold into two columns.

So in book mode, kind of. And then the second one is vertical viewport segments. So this is the state of the device where the folder hinge is horizontal and the two viewports are stacked and split into rows. So we'll go through a basic example here of how to use these and then we'll look at a more in-depth one in a little bit. So in this example, we are combining our horizontal viewport segments media feature with another media query, min width.

So we're saying if the device has two viewport segments side by side and the viewport has a minimum width of 540 pixels, make the background of the body yellow. So if we run the code on three different devices, the result will be this one. You'll get a yellow body background just on the dual screen. Now, especially on devices that have a physical hinge that obscures content, you want to be able to snap that content to the fold of the device.

You don't want critical content being obscured there. So some of the initial users of this technology wanted to avoid that hinge and be able to place content within the display region boundaries of each viewport. So with the current media feature solution, we can detect if the browser is spanning across two displays, but that's not enough to achieve this. So you could probably assume that both screens are equal in size, but the engineers designing the API didn't want developers to assume that, because that doesn't necessarily scale for future devices.

You don't know what someone is going to create. So we don't want to assume that both screens are equal. And so this is where our predefined CSS environment variables come in. So these identify the sizing of viewport segments, and they will help you with positioning and placement of elements within that viewport. So we have six variables, and the viewport segment environment variables have two dimensions. So these represent the x and y position in the two-dimensional grid created by the hardware features separating the segments.

So segments along the left edge have an x position of zero, and those in the next column or viewport to the right have an x position of one. And so similarly, segments along the top have a y position of zero and so on. So if we look at that sort of visualized, there is a-- so there's a- essentially, there's a rectangle for each segment, which is represented by the six values. So we have top, bottom, left, right, width, and height.

And viewport segment width and viewport segment height are sort of like shortcuts. They're just convenient environment variables because in theory, you could calculate the display width or height with viewport segment right and viewport segment left, but that just becomes very verbose. So we also have viewport segment height and width. So let's look at an example of these in practice with just a couple of boxes. And again, this was all built with the idea of using the surface duo.

So there is a physical hinge. So we have four boxes wrapped in a flex container, and we have a flex direction of row. For box one, we have our width and our height set to 100 pixels. So we're going to set our position to absolute here, and then we're going to position with the left property. And we're going to use the calc function to subtract the 100 pixels, so the width of the box, from the right viewport segment of the left display. So if we didn't subtract that 100 pixels, you wouldn't be able to see it.

It would align this way to the right. So subtracting that 100 pixels aligns it there. And then if we look at box two, so again, set our height. And we're going to just use the viewport segment width variable with indices one and zero. And that's how we're going to set- so that's our width. So we're setting our positioning by saying we want it to start at the edge of the left segment of the right display.

And we want it pinned to the top, so the top is set to zero. And we want it spanning that whole width, so that's why we want it to take up the whole viewport segment. And then similarly with box three, height 100, and then viewport segment width variable with indices 0, 0. And for this example, we're going to include another value. We're going to say 100% as the fallback. If for some reason our environment variables don't work or aren't supported, we can still include that fallback value.

And that is optional, but it is there as a fallback. And then we don't need any variables for left or top positioning, so just 0 and 0 for left and bottom. And then finally, our fourth box, set height, width, position absolute. And then we want to pin to the left segment of the right display. So we use viewport segment left, indices 1, 0, and bottom property set to 0. So hopefully, this gives you a general idea of how these things work with these variables.

We'll look at a real app example in a little bit. So for the JavaScript side, we have the viewport segments API. The concept of the viewport is something that developers are already familiar with. And so after the feedback from the community, and again, wanting to make these easy to use with existing architecture, segments became a property on the viewport. And again, note that the shipped version lives on window viewport.

Earlier drafts and origin trials did use window.visual viewport. So if you were using any of this code, be sure to update it. And so when you're on a regular desktop computer or an unfolded phone, you query viewport segments. So you'll get back an array with a single segment covering the whole viewport. Earlier versions returned null here. So again, if you have older code that's checking for null, update it to check the length instead.

So on dual screen devices, however, you'll get two DOM recs. So these represent the two viewports available when the browser is spanning across the fold. And the value that gets stored in the segments constant is an immutable snapshot of the device state at the time it was queried. So that means once you resize the browser window or you rotate the device, you fold it, you just change the shape of it, the segments that you previously retrieved are no longer valid.

So you will need to query them again. And then when the viewport goes from spanning two display regions to one, the resize event fires. And again, rotating the device fires at two. You can also listen for the change event on navigator device posture, which fires when the device is folded or unfolded. So use these events to query segments again and get the current geometry of the display regions. And then device posture has two values.

You have folded or book for laptop postures and continuous for a flat device, so when the device is completely flat, which is also what every non-foldable device will report. And then with device posture in CSS, there is a media query in JavaScript. Read navigator device posture type and listen for its change event. And then you can combine it with viewport segments.

And posture will tell you how the device is being held. Segments will tell you where the fold is. And then one question that did come up five years ago when I was talking about this is, when should I use CSS versus JavaScript? So in some cases, there's just simply no CSS for you to be able to pull from. So this happens when you're working with shapes and objects in Canvas 2D and WebGL. So if you're building a game that could leverage both displays or a sketching app, something, something that spans both those displays, you're gonna wanna use JavaScript.

Another use case would be creating DOM elements at application runtime and appending them to the DOM and then inserting some styles inline. So in this case, maybe, those styles would only be applicable for dual screen for when you'd be adding those in. And then examples of enhanced designs on dual screen devices. So the one thing I think I want people to really take away from this is, I don't want you to feel like you need to adapt all of your web experiences to work on a dual screen device.

You wanna think about, does it make sense for what I am building for my product, for my website to utilize both screens. Otherwise it'll work on just the one display. So our first example is a mail application on a dual screen device. And so in the example on the left, we can see that the layout is just slightly off in the message pane. And again, due to the nature of the hinge on this device, that content is broken up and obscured.

So the experience on the right here is what we want to achieve. So let's take a look at how we get there. So our first media query here is blank, but this is where you'd put your rules specific to screens that are wider than a tablet. And then our second media query is for our dual screen device. So we're targeting devices that have a minimum width of 799 pixels and are being held in the vertical fold posture.

So you have two columns, again, like a book. So they have two logical segments of the viewport in a horizontal direction. And so our main element here is wrapping the three columns of our email app. So that contains the navigation, the inbox, and then the message. So for our navigation, our design spec says that the desired width for this is 60 pixels. And since we're using flex direction row, flex basis is gonna act like the flex items width here.

So we set that to 60 pixels. And then for our inbox, we want this to consume the entire width of the first display region. So our first screen, our first viewport segment, minus our navigation. So we have our CSS calculate our width with the viewport segment width 00 environment variable. And so that's to indicate we want that to take up the whole width minus the 60 pixels for the navigation. And then again, on some devices, we have that mask or a fold that's covered by part of the device.

So we wanna add a margin after the column. And so we would use margin inline end here and the calc function to calculate that area that is obscured by the fold. And so that's gonna identify that gap. So we would then subtract the right segment of the left display from the left segment of the right display. And then finally, for email content, the email content should just grow to fill the rest of the space.

So again, we'd use viewport segment width, but with our 1.0 because we just want that to take up the whole second viewport. So if we look at that example again, we would achieve the layout with those, I don't know, what is that, 30 lines of code? And you'd have it adapt to a dual screen device. So some other examples on how you could utilize dual screen devices, so map application, you could have your map in one viewport and the results you're searching for on the other.

This is the one that I came up with and I've actually had friends tell me even to this day, "Ugh, I wish I had a dual screen device 'cause when I'm cooking, I hate scrolling back and forth." And so I made a demo, again, four years ago and it's still live, so if you wanna go look at it, you can, but this will split on the dual screen and then your ingredients stay there on the first viewport and then you can scroll your recipe steps. And I won't walk through all the code for it.

Again, if you want to go check it out, you can go to my website and it's under demos and dig into the developer tools, but I do just wanna highlight the grid structure for the main container and the use of the environment variables here. So when I define my grid, I'm actually able to use those environment variables as the value for my first column of the CSS grid on the dual screen device.

So this line of code is telling the browser when my device is in the vertical fold position, I want my first column to take up the entirety of the first viewport and then create two more columns that are equal with the remaining space because for design purposes, I want to have two columns for more design flexibility. But you could even add three, four, depending on how much flexibility you do want on that viewport.

So if I wanted to create a two column structure in CSS grid, again, I could use viewport segment width twice just with the indices to indicate which column in viewport each one should take up. So these variables really, really reduce the friction when it comes to building layouts for a dual screen device. And because of the nature of them, as foldables continue to evolve and devices start to support these platform features, the layout is going to adapt.

So there's nothing that you should have to update here. You should be able to write this once and then on a future foldable device that maybe has a bigger screen, it should just work. And that is just good standards work. And then finally, let's look at a couple design patterns, some dos and don'ts. They're pretty straightforward. And again, these were built with devices that have a physical hinge obscuring content in mind.

So some of this may not be as applicable to something like the iPhone Duo, but it still is good to think about, especially when it comes to just being mindful of the width of the content that people are gonna be consuming if they are spanning across both screens on the iPhone Duo. So dual screens obviously can provide a book-like paging experience. And so this allows you to show multiple pages at once and related groups of information that are side-by-side.

So keep them side-by-side. Don't, don't spam the whole device. Like your friend. (laughing) If you have actionable items, so you've got a little green button on the second one, split your content up so that each actionable item is on its own viewport or own display. And again, don't pass anything under that hinge. Here, we're using an illustration or a visual indicator on the second screen.

If your content only needs one screen, just don't span it again across both screens because just the line length alone for that is gonna be really inaccessible and hard to read. So try and keep things limited to that one viewport, but don't just fill up space for the sake of filling up space. And then the extended canvas design pattern. So this is the simplest pattern there is for dual screen devices.

This should be used just simply if your app needs a bigger canvas. So again, for maps, you can do that. You can have it span across both. Or if you want, again, a drawing app, something that you can span, something that makes sense to span both of those viewports. And then if you're using the extended canvas pattern, display any dialogues. Again, in the left or right screen, don't center it.

Again, on devices with a physical hinge, it will be obscured, and you most likely will not be able to click that button. If you have additional UI displaying information, don't span it across the whole device. A lot of this is really the same. Just don't span it across the whole device. Really be intentional about how you are dividing those things up across viewports. Same with navigation.

Especially if you really want to think about the design principle of just grouping things together, like things that are grouped together are related, so you don't want to space out your navigation that much, because they don't look like they are a part of one component or group. And then, again, when the device is in a different orientation, avoid toolbars creeping under that hinge. Try and keep them locked to one side. There are some more patterns and resources that are in the links at the end of this talk.

But again, like I said, I think the biggest thing that you should worry about with dual screen is does it make sense to adapt my website or web app to use two viewports or not? And then just treat it as progressive enhancement. So it's a delight to users who do have those devices, but your site should still work just fine, even if you don't have something progressively enhanced. So hopefully you're feeling a little bit inspired by how easy it is to use these.

API status again, so Chrome and Edge, and I believe all other Chromium browsers. And then you have, so you have viewport segments, device posture, Safari, beta is behind a flag, Firefox not yet implemented. They'll probably won't be, would be my guess. They don't really have a reason to, but never say never. And again, treat these as progressive enhancements, use feature detect, and make sure your single screen design is, or your layout is solid.

And so if you want to test without a device, because these devices are expensive, there is in Chromium dev tools, so in the device toolbar, you've got a Galaxy Z Fold 5, Asus ZenBook Fold, and there is more. The Surface Duo is still in there. I checked, you just have to go in and check it to turn it on now.

There's Android Studio foldable emulators. One thing I haven't touched on is there is a whole other set of code and tooling to build dual screen apps for Android.

And then there is a Xcode iPhone Duo simulator behind a Safari flag. So will this play? So if you wanted to go check out DevTools, inspect, find the mobile devices, and then when you click your device, make sure that you are hitting the little icon that looks like an open book, because then that is going to put that device into the actual dual screen viewport device.

And you can switch it to be two vertical, so stacked rows. Resources, MDN is honestly the best, so they will have lots of documentation. Chrome has viewport segments. I don't have a link here, but if you do want to go look at the old Surface Duo patterns there is some good stuff there, and I'm pretty sure it is still on Microsoft Edge Developer or Surface Duo Developer.

And that's it. If you have any questions, you can find me online. I am on Blue Sky. You can find me on Threads and my website. Thank you.