iphone safari css viewport

Does Safari 15 finally fix viewport height?

Written by Luke Channings on June 11, 2021

The design for Safari 15 has been very controvercial, and has changed significantly since the beta that this article was based on Sadly, one of the casualties of the evolving design was the main thrust of this article: env(safe-area-inset-bottom) is no longer dynamically the height of the address bar in the final release.

TL;DR : No , but if you subtract env(safe-area-inset-bottom) from 100vh you'll get what you want .

Safari 15's UI is a radical departure from the previous version — and from web browsers in general — but does it fix the viewport height problem?

What is the viewport height problem again?

Mobile Safari has had problems related to 100vh not behaving like web developers expect 1 2 pretty much since the beginning. The main crux of the issue is that Mobile Safari's UI Chrome shrinks when you scroll, and expands again when you activate it. That means 100vh ("100% the height of the viewport") can't be a static number.

Let's start by understanding the definition of the vh unit 3 :

vh is defined as Equal to 1% of the height of the initial containing block . — Anthony Frehner

And here's the best explanation of the 100vh issues in Mobile Safari that I've seen so far,

The core issue is that mobile browsers (I’m looking at you, Chrome and Safari) have a “helpful” feature where the address bar is sometimes visible and sometimes hidden, changing the visible size of the viewport. Rather than adjusting the height of 100vh to be the visible portion of the screen as the viewport height changes, these browsers instead have 100vh set to the height of the browser with the address bar hidden. The result is that the bottom portion of the screen will be cut off when the address bar is visible, thus defeating the purpose of 100vh to begin with. — David Chanin , Avoid 100vh On Mobile Web

Let's put this new Safari to the test

I have a simple HTML page based on the example given in David's article. It has a header at the top and a button at the bottom, all wrapped in a 100vh container.

Safari's new floating address bar is displayed above our test button, which is more-or-less exactly the same behaviour as iOS 14.

So - Safari 15 does not change the behavour of 100vh 😢.

So what's the solution then?

It makes sense to me that the WebKit team wouldn't change the behaviour of the viewport unit, it's already well defined.

Do you remember when Apple introduced env() and safe-area-inset so that web developers could avoid their content being shown behind the notch 4 ?

Well in Safari 14, safe-area-inset-bottom is 0px whether the UI chrome is active or inactive, which is something that has annoyed me for a while.

safe-area-inset-bottom is 0px when the UI chrome is inactive in Safari 15 on iOS, and then the height of the collapsed chrome minus the height of the expanded chrome when the bar is expanded.

That means that to get a button to float at the bottom of the page, always above the UI Chrome, all you have to do is use calc(100vh - env(safe-area-inset-bottom)) .

Wrapping up

So not only does safe-area-inset-bottom work in Safari 15, it's animated !

I've been hoping that something to remedy the viewport height bug was coming since Jen Simmons (who joined the Safari / WebKit team in June 2020) was asking for feedback regarding viewport height issues.

Hey everyone who’s been frustrated that VH units in CSS don’t do what you need… can you describe your usecase? What layout are you creating? With which layout mechanism? What do you need? Screenshots & sample code appreciated. — Jen Simmons ( @jensimmons ) May 15, 2021

Have a feeling I’m going to be talking about Environment Variables a lot this week. They are really cool & supported! https://developer.mozilla.org/en-US/docs/Web/CSS/env() https://caniuse.com/css-env-function padding-bottom: calc(1rem + env(safe-area-inset-bottom)); -or- height: calc(100vh - env(safe-area-inset-bottom)); — Jen Simmons ( @jensimmons ) June 7, 2021

• https://bugs.webkit.org/show_bug.cgi?id=141832 ↩
• https://css-tricks.com/the-trick-to-viewport-units-on-mobile/ ↩
• https://github.com/w3c/csswg-drafts/issues/4329 ↩
• https://webkit.org/blog/7929/designing-websites-for-iphone-x/ ↩

• Web Development

Fixing the iOS Toolbar Overlap Issue with CSS Viewport Units

One of the most exciting aspects of web development in recent years has been the continued growth and improvement of CSS. Flexbox and grid revolutionized how we build webpage layouts. Custom properties (aka, CSS variables) opened up new possibilities for theming. Newer selectors like :has() , :is() , and :where() have lead to more powerful and concise CSS. Container queries are now a reality and looking ahead, native CSS nesting is on its way ( decisions concerning its syntax notwithstanding).

But all of these new and upcoming features means that CSS is becoming increasingly complicated. Inevitably, then, some new features might fall through the cracks and get overlooked. (Which is why I’m of the opinion that “full-time CSS engineer” ought to be a thing, but that’s a topic for another post.) Speaking personally, I’m still pretty ignorant concerning the benefits of newer color formats like hwb() and lch() . Which brings me to viewport units.

Put simply, viewport units allow you to size a page’s elements relative to the size of the browser’s viewport , which contains everything that is currently visible on a webpage. (The viewport is basically the browser window minus any UI elements like the navigation and search bar.)

Consider this very simple example:

The vh stands for “viewport height,” so an element set to 100vh will be 100% of the viewport’s height. If that element’s height is set to 50vh , then it’ll be 50% of the viewport’s height, and so on. The 100vh is often used when you want an element to fill up the entire browser window. For instance, I use this technique on special features (like my recent David Zindell post ) to make their headers fill up the entire viewport with a splashy image. This gives them some extra visual oomph that sets them apart from my “normal” posts.

Not All Viewports Are the Same

This approach works well except for one pretty prominent scenario. If you’re viewing such a layout in Safari on an iOS device, that 100vh element fills up the viewport, but its bottom portion is then covered by a toolbar that includes the next/previous navigation and other controls. (See Figure A.)

Note: Although I’m focusing on iOS Safari, this issue also occurs in iOS Chrome. It doesn’t occur in other iOS browsers like Brave, DuckDuckGo, Firefox, and Opera. (More on that in a moment.) I haven’t tested this in any Android browsers.

In other words, Safari doesn’t seem to take its own UI into consideration when drawing its viewport. Thus, a 100vh element doesn’t behave the way it seems like it should, i.e., filling up the space between the URL bar and the bottom toolbar. (Remember that a browser viewport is the browser window minus any UI elements.)

There are, of course, reasons for why Apple opted for this approach. And reading the developer’s explanation  — the viewport’s height changes dynamically because any toolbars disappear or minimize when you scroll — they seem perfectly valid. But that doesn’t mean I liked how it looked. It was hard to believe that this was still an issue the Year of Our Lord 2023.

Various Google searches returned different solutions, including some JavaScript-based workarounds . Using JavaScript to fix visual layout issues, however, always feels hack-y to me. Call me old-fashioned, but I like to keep my CSS and JavaScript nice and separate, and reserved for those things that they do best (e.g., CSS for layout, JavaScript for interactivity).

That aforelinked article also pointed me to Matt Smith’s article about -webkit-fill-available , which seemed promising at first. Unfortunately, it wasn’t applicable to my situation. I didn’t want the post header to simply fill up the entire available space because I also needed to take into account the height of my site’s header, which contains the logo, nav, and search.

Here’s what my original CSS looked like:

The site header is 6 rems high, so I use the calc function to subtract that from the 100vh to dynamically calculate the post header’s new height. But, as pointed out before, iOS doesn’t respond to 100vh the way you might think it would. What I really needed was a new type of CSS unit — and fortunately, I found it.

New Viewport Units

Back in November, Google’s Web.dev blog covered three new viewport units: the “large,” “small,” and “dynamic” viewport units . These units were created specifically to work with viewports whose size might change due to dynamic toolbars —  which was the exact problem I was facing .

• The “large” viewport units assume that any dynamic toolbars (e.g., Safari’s bottom bar) are retracted and hidden , and calculate the viewport’s size accordingly. (This is akin to Safari’s aforementioned default behavior.)
• The “small” viewport units assume that any dynamic toolbars are expanded and visible , and calculates the viewport’s size accordingly.
• The “dynamic” viewport units sit in-between the “large” and “small” units, and react automatically to the dynamic toolbar’s behavior.

At first glance, a “dynamic” viewport unit seemed like the solution. After all, who doesn’t like a web design that automatically responds, all on its own, to a given situation? With that thought in mind, I updated my CSS:

In addition to the original selector, I added a feature query via @supports that basically says if the browser recognizes and supports the height: 100dvh declaration, then run the following CSS. (This is an example of progressive enhancement , i.e., starting with the basics and then adding on more advanced code that modern browsers will recognize.) That CSS is virtually identical to my original CSS, except I’m now using 100dvh instead of 100vh . (The dvh stands for “dynamic viewport height.”)

The first time I loaded the page, the problem seemed to be solved: the post header now filled up the space between Safari’s toolbars without anything cut off or hidden. But then I scrolled a little bit.

When you scroll down in iOS, the browser’s toolbars disappear or reduce in size, thus increasing the height of the browser’s viewport. Conversely, scrolling back to the top causes the toolbars to reappear or return to their original size, thus decreasing the viewport’s height. This behavior caused some distracting (IMO) changes to the post header: the background image expanded while the text shifted down in response to the additional height.

Interestingly, this “dynamic” approach is the behavior employed by the iOS versions of Brave, DuckDuckGo, Firefox, and Opera. In other words, toolbar overlap appears to be a non-issue for them, at least as far as Opus is concerned.

So after giving it some more thought, I replaced 100dvh with 100svh  — i.e., the “small” viewport height — which assumes that any toolbars are always expanded.

Here’s my final code:

You can see the results — that is, the entire post header — in Figure B. Upon scrolling, the post header doesn’t take advantage of the increased viewport height, so it’s not a truly “full-height” element. However, it doesn’t have any weird shifting, either, but looks the same all the time. And I always prefer such stability in my web designs.

For what it’s worth, Firefox, Brave, et al . ignore the 100svh setting altogether, and instead, always stick with the “dynamic” handling of the viewport and post header heights. That’s a little frustrating, but since they represent a relatively minuscule amount of Opus ’ overall traffic, I’m not going to sweat it.

Final Thoughts

Along with the aforementioned color formats, viewport units are one of those aspects of CSS that has always felt rather abstract to me. (Then again, I still have trouble wrapping my mind around how srcset works, and that’s used all the time for responsive images.) The problems they seek to address have often seemed rather niche to me, compared to the issues that I’m trying to solve 95% of the time.

Of course, now I have to eat a little crow because I found myself in just such a “niche” situation. Which is to say, I’m glad that really smart people have spent time thinking through these situations, rarefied as they might seem, to find and propose potential solutions.

I’m also glad that browser makers are quick to implement them; browser support for these new viewport units is pretty good, with Opera being the only major holdout. (Which means that I’ll probably remove the @supports feature query in the not-too-distant future and use the 100svh as the default CSS.)

Finally, while Safari’s behavior was initially frustrating, I do believe they made the better choice concerning how to handle dynamic toolbars and viewport heights now that I’ve seen how Firefox et al . handle them. I’d rather have part of the design covered up by default (but fixable, if needed, with the right CSS) then see the page rearrange itself as you scroll. The latter behavior is unexpected and thus distracting, two things that can create a poorer user experience — which is something I try to avoid in every aspect of my designs.

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free

Viewport concepts

This article explains the concept of the viewport — what it is, its impact in terms of CSS, SVG, and mobile devices — and differentiates between the visual viewport and the layout viewport.

What is a viewport?

A viewport represents the area in computer graphics being currently viewed. In web browser terms, it is generally the same as the browser window, excluding the UI, menu bar, etc. That is the part of the document you are viewing.

Documents like this article may be very long. Your viewport is everything that is currently visible, notably, the "what is a viewport" section, and perhaps some of the navigation menu. The size of the viewport depends on the size of the screen, whether the browser is in fullscreen mode or not, and whether or not the user zoomed in. Content outside the viewport, such as the See Also section in this document, is likely to not be visible onscreen until scrolled into view.

• On larger monitors where applications aren't necessarily full screen, the viewport is the size of the browser window.
• On most mobile devices and when the browser is in fullscreen mode, the viewport is the entire screen.
• In fullscreen mode, the viewport is the device screen, the window is the browser window, which can be as big as the viewport or smaller, and the document is the website, which can be much taller or wider than the viewport.

To recap, the viewport is basically the part of the document that is currently visible.

Viewport sizes are mutable

The width of the viewport is not always the width of the window. If you query the width or height of the window and document in Chrome or Firefox, you may get:

There are several DOM properties that can help you query viewport size, and other similar lengths:

• The document element's Element.clientWidth is the inner width of a document in CSS pixels , including padding (but not borders, margins, or vertical scrollbars, if present). This is the viewport width .
• The Window.innerWidth is the width, in CSS pixels, of the browser window viewport including, if rendered, the vertical scrollbar.
• The Window.outerWidth is the width of the outside of the browser window including all the window chrome .

In an experiment with these, the innerWidth and outerWidth was seen to be the same, but the outerHeight was 100px taller than the innerHeight . This is because the outerHeight includes the browser chrome: measurements were taken on a browser with an address bar and bookmarks bar totalling 100px in height, but no chrome on the left or right of the window.

The area within the innerHeight and innerWidth is generally considered the layout viewport . The browser chrome is not considered part of the viewport.

When zoomed in, both Firefox and Chrome report the new CSS pixel size for innerWidth and clientWidth . The values returned for the outerWidth and outerHeight depend on the browser: Firefox reports the new value in CSS pixels, but Chrome returns the length in the default pixel size. When zoomed in you may get:

The viewport was originally 1200 x 800 pixels. Upon zooming in, the viewport became 800 x 533 pixels. This is the layout viewport . Sticky headers or footers, with the following styles, will stick to the top and bottom of the layout viewport respectively.

We got the 800 x 533 measurement when we zoomed in using the keyboard. The header and footer stayed flush against the top and bottom of the window. But what if we had pinched-zoomed on a tablet? What if a dynamic keyboard pops open on a phone?

The web contains two viewports, the layout viewport and the visual viewport . The visual viewport is the part of the web page that is currently visible in the browser and can change. When the user pinch-zooms the page, pops open a dynamic keyboard, or when a previously hidden address bar becomes visible, the visual viewport shrinks but the layout viewport is unchanged.

Sticky headers or footers, as discussed above, stick to the top and bottom of the layout viewport , and therefore remain in view when we zoom in with the keyboard. If you pinch-zoom, the layout viewport may not be fully visible. If you magnify from the middle of the layout viewport, the content will expand in all four directions. If you have a sticky header or footer, they will still be stuck to the top or bottom of the layout viewport, but they may not be visible at the top and bottom of the device's screen — which is the visual viewport. The visual viewport is the currently visible portion of the layout viewport. If you scroll down, you are changing the contents of the visual viewport and bringing the bottom of the layout viewport into view, displaying the sticky footer, which will then stay stuck at the bottom.

The visual viewport is the visual portion of a screen not including on-screen keyboards, areas outside of a pinch-zoom area, or other feature that doesn't scale with the dimensions of a page. The visual viewport is the same size as the layout viewport or smaller.

For a page containing iframes, objects, or external SVG, both the containing pages and each included file has their own unique window object. Only the top-level window has a visual viewport that may be distinct from the layout viewport. For included documents, the visual viewport and layout viewport are the same.

The layout viewport and visual viewport described above are not the only viewports you will encounter. Any sub-viewport that is fully or partially displayed within the layout viewport is considered a visual viewport.

We generally think of width and height media queries as being relative to the width and height of the browser window. They are actually relative to the viewport, which is the window in the main document but is the intrinsic size of the element's parent in a nested browsing context like objects, iframes and SVG. In CSS, we also have length units based on the viewport size. A vh unit is 1% of the layout viewport's height. Similarly, the vw unit is 1% of the layout viewport's width.

<iframe>

Inside an iframe, the visual viewport is the size of the inner width and height of the iframe, rather than the parent document. You can set any height and width on an iframe, but the whole document may not be visible.

If you use viewport length units in your CSS within the iframe document, 1vh will be 1% of the height of the iframe, and 1vw will be 1% of the width of the document.

If the iframe is set to 50vw, it will be 50% of the width of the 1200px parent document in our example above, or 600px , with 1vw being 6px . When zoomed in, the iframe shrinks to 400px and 1vw becomes 4px .

A width-based media query within the iframe document is relative to the iframe's viewport.

If the above CSS is included in the iframe, the paragraphs will become red when the user has zoomed in, but this style does not apply in the non-zoomed-in state.

In an SVG document, the viewport is the visible area of the SVG image. You can set any height and width on an SVG, but the whole image might not be visible. The area that is visible is called the viewport. The size of the viewport can be defined using the width and height attributes of the <svg> element.

In this example, the viewport has an aspect ratio of 3:4 and is, by default, 400 by 300 units, with a unit generally being a CSS pixel.

SVG also has an internal coordinate system defined via the viewBox attribute, which is not related to this viewport discussion.

If you include an SVG file in your HTML, the viewport of the SVG is the initial containing block, or the width and height of the SVG container. Using the @media query in your SVG's CSS is relative to that container, not the browser.

Generally, when you write the above media query, the styles are applied if the viewport, generally the browser window, is between 400px and 500px, inclusive. The width media query in the SVG is based on the element in which the SVG is contained — the <img> if the source is an SVG file, the SVG itself if the SVG is included directly into the HTML, or the parent if the parent element has a width assigned and — not the viewport's width. With the above media query being in our SVG file, the CSS is applied if the SVG container is between 400 and 500px.

The Visual Viewport API provides a mechanism for querying and modifying the properties of the visual viewport.

Mobile Viewports

Mobile devices come in all shapes and sizes, with screens of differing device pixel ratios. The mobile browser's viewport is the area of the window in which web content can be seen, which is not necessarily the same size as the rendered page. Mobile browsers render pages in a virtual window or viewport, generally at 980px, which is usually wider than the screen, and then shrink the rendered result down so it can all be seen at once. Users can then pan and zoom to see different areas of the page. For example, if a mobile screen has a width of 320px, a website might be rendered with a virtual viewport of 980px, and then it will be shrunk down to fit into the 320px space, which, depending on the design, is illegible for many if not everyone. To tell a mobile browser to use the viewport width instead of the default 980px as the width of the screen, developers can include a viewport meta tag, like the following:

The width property controls the size of the viewport. It should preferably be set to device-width , which is the width of the screen in CSS pixels at a scale of 100%. There are other properties, including maximum-scale , minimum-scale , and user-scalable , which control whether users can zoom the page in or out, but the default values are the best for accessibility and user experience, so these can be omitted.

• Visual Viewport API
• <meta> , specifically <meta name="viewport">
• Using the viewport meta tag to control layout on mobile browsers

• Getting Started

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Popular Articles

How to reload the page, html5 navigation: using an anchor tag for hypertext, how to create indents and bullet lists, top online courses to learn seo, sellzone marketing tool for amazon review, the top database plugins for wordpress, the revolutionary es6 rest and spread operators.

Table of contents:

Overview and dimensions, screen size, viewport & pixel ratio, key points for development and testing, css media query, launch device in blisk application, launch device from command prompt or terminal, specification (summary).

iPhone 13 was released by Apple on Friday, September 24, 2021 and is powered by iOS OS. By default, the device is shipped with a web browser — Safari for iOS. Device dimensions are 71.5×146.7×7.7 millimeters (2.81×5.78×0.3 inches) 1 . The device weighs 174 g.

iPhone 13 has a Super Retina XDR OLED display with a 6.1-inch screen (90.2 cm 2 , 19.5:9 aspect ratio), and an approximately 86% screen-to-body ratio. The display is a touch screen, meaning that it supports touch events - interactions using a finger or stylus.

1 - Property is displayed as width × height × thickness.

iPhone 13 has a 6.1-inch screen with a screen size (resolution): 1170px × 2532px , 390px × 844px viewport 1 , and a CSS Pixel Ratio of 3.

1 - Property is displayed as width × height.

Screen size (resolution) is the number of physical pixels present on a screen.

Viewport or Viewport size is the number of software pixels (CSS pixels) present on a screen. Usually, viewport size displays as viewport width in pixels to viewport height in pixels.

Device Pixel Ratio (DPR) or CSS Pixel Ratio is the ratio between the physical pixels (screen size or resolution) and CSS pixels (viewport). Depending on device specification, one CSS pixel can equal one or mode physical pixels. Modern devices have screens with high pixel density resulting in the difference between screen size (resolution) and viewport.

Summary: Screen Size (Resolution) = Viewport size × Device Pixel Ratio. Viewport size = Screen Size (Resolution) / Device Pixel Ratio. CSS Pixel Ratio = Screen Size (Resolution) / Viewport size.

Before you start web development or testing, check that the web application supports a responsive viewport by using a viewport meta tag:

You can inspect this tag in the head section of an HTML document on iPhone 13 right in the Blisk app . If this viewport tag is missing, the web application will not be responsive and will overflow the screen, hiding the content from users and leading to a bad user experience.

The form factor of the device represents its primary orientation as a portrait. Landscape orientation is popular on iPhone 13 as well and should be seriously considered when you develop or test web applications on any mobile.

You also need to consider that the users will manipulate your web application on iPhone 13 with a finger and stylus because this device has a touch screen that supports touch events. It is important to remember, that users may interact with multiple fingers (multi-touch) and gestures: single tap, multi-tap, swipe, pinch, stretch, zoom, etc. The users are highly likely to use gestures on small touch screens because of seamless interaction and great user experience.

Use the CSS Media Queries below to apply custom CSS properties for iPhone 13 and devices with the same screens:

iPhone 13 Media Query for min-width:

iPhone 13 Media Query for min-height:

iPhone 13 Media Query for landscape orientation:

iPhone 13 Media Query for portrait orientation:

iPhone 13 Media Query with device pixel ratio:

iPhone 13 is ready to use in the Blisk app, where you can develop web applications and test cross-browser compatibility, use this phone as a standalone device or simultaneously with other devices. Getting started with Blisk...

• Download the latest version .
• Launch the Developer Mode from the Toolbar (screenshot below).
• Click Device Manager (screenshot below).
• Select iPhone 13 from the list.
• Click Launch Devices .

You can launch iPhone 13 in the Blisk app from Command prompt (Windows) or Terminal (macOS or Linux) to develop web applications and test cross-browser compatibility on a standalone device or simultaneously with other devices. Learn more...

• Launch the Developer Mode from the Toolbar.
• Click Menu: Device Set ➜ Share Set .
• Select Command and click Next .
• Copy the generated command.
• Launch Command prompt or Terminal, paste the command, and execute it.

is ready to use for web development, testing, marketing, SEO needs

App for Windows, macOS, Linux

• Develop responsive web applications for mobiles, tablets, and desktops
• Test cross-browser compatibility for mobiles, tablets, and desktops
• Test touch events, simulate medium or slow Internet connection
• Debug and measure performance with Developer Tools

WebKit Features in Safari 17.5

May 13, 2024

by Jen Simmons

Happy May! It’s time for another release of Safari — our third significant update of 2024. With just a month until WWDC24 and the unveiling of what’s coming later this year, we are happy to get these 7 features and 22 bug fixes into the hands of your users today.

There are several exciting new CSS features in Safari 17.5, including text-wrap: balance , the light-dark() color function, and @starting-style , plus the ability to use feature queries with @import rules. Let’s look at how you can put each one to use.

Text wrap balance

On the web, with its flexible container widths, inconsistent lengths of content, and variation between browsers, it can feel impossible to avoid having text wrap in such a way that too few words end up all by themselves on a very short last line.

When type was set by hand, typographers would painstakingly avoid this undesirable result by manually moving content around. Over the decades, web developers have tried a series of different tricks to avoid orphans in CSS, in HTML, in JavaScript, and in content management systems. None work very well. The attempts usually feel hacky, laborious, and fragile.

To solve this and other frustrations, the CSS Working Group has defined three new options that you can use to change how text will wrap. You can switch from default wrapping to another style with text-wrap . WebKit for Safari 17.5 adds support for the first of these new options — balancing.

The text-wrap: balance rule asks the browser to “balance” the lines of text and make them all about the same length.

You can see how now the text no longer fills the containing block — there’s a large amount of space on the right of the words. This is expected, and something you’ll want to think about as you decide when to use text-wrap: balance .

Where exactly each line of text will break when using text-wrap: balance may be slightly different in each browser. The CSS Text level 4 web standard leaves it up to each browser engine team to decide which algorithm they want to use in determining how exactly to wrap balanced text.

It can be computationally expensive for the browser to count characters and balance multiple lines of text, so the standard allows browsers to limit the number of lines that are balanced. Chromium browsers balance 6 or fewer lines, Firefox balances 10 or fewer, while Safari/WebKit balances an unlimited numbers of lines.

For now, Safari does not balance text if it’s surrounding a float or initial letter. And Safari disables the balancer if the content contains preserved tabs or soft hyphens.

Text wrap shorthands and longhands

The text-wrap property is actually a shorthand for two longhand properties: text-wrap-style and text-wrap-mode .

The text-wrap-mode property provides a mechanism for expressing whether or not text should wrap.

The wrap value turns it on, and the nowrap value turns it off, just like the values for white-space . (In fact, text-wrap-mode is the newly introduced longhand of white-space .) WebKit added support for text-wrap-mode: wrap and nowrap in Safari 17.4 .

The text-wrap-style property selects how to wrap. The initial value is auto — asking text to wrap in the way it has for decades. Or, you can choose a value to switch to another “style” of wrapping.

WebKit for Safari 17.5 adds support for text-wrap-style: balance , stable , and auto .

Of course, the text-wrap shorthand is a way to combine text-wrap-mode and text-wrap-style and declare them together. If you write text-wrap: balance it’s the same as text-wrap: wrap balance , meaning: “yes, please wrap, and when you do, please balance the text”.

Full support will eventually include three properties and six values. No browser supports everything yet, so be sure to look up support for the text-wrap , text-wrap-mode , and text-wrap-style properties, as well as the balance , pretty , stable , auto , wrap , and nowrap values.

The balance , pretty , and stable values will simply fall back to auto in browsers without support, so progressive enhancement is easy. You can use these values today, no matter how many of your users don’t yet have a browser with support. They will simply get auto -wrapped text, just like they would if you didn’t use text-wrap . Meanwhile, those users with support will get an extra boost of polish.

Dark mode and the light-dark() color function

More and more, users expect websites and web apps to support dark mode . Since Safari 12.1 , the prefers-color-scheme media query has given you the ability to write code like this:

Or perhaps you’ve used variables to define colors for both light and dark mode at once, making it easier to use them everywhere.

Well, now there’s a new option — the light-dark() function. It makes defining colors for dark mode even easier.

First, inform the browser you are providing a design for both light and dark modes with the color-scheme property. This prompts the browser to switch the default user agent styles when in dark mode, ensuring the form controls appear in dark mode, for example. It’s also required for light-dark() to work correctly.

Then, any time you define a color, you can use the light-dark() function to define the first color for light mode, and the second color for dark mode.

You can still use variables, if you’d like. Perhaps you want to structure your code like this.

An often-asked question when learning about light-dark() is “does this only work for colors?” Yes, this function only works for colors. Use the prefers-color-scheme media query to define the rest of your color-scheme dependent styles.

Starting style

WebKit for Safari 17.5 adds support for @starting-style . It lets you define starting values for a particular element. This is needed to enable a transition when the element’s box is created (or re-created).

In the above example, the background-color will transition from transparent to green when the element is added to the document.

Many developers are excited to use @starting-style along with display: none interpolation. To do so, WebKit also needs to support animation of the display property, which has not yet shipped in Safari. You can test this use case today in Safari Technology Preview .

Features queries for importing CSS

WebKit for Safari 17.5 adds the supports() syntax to @import rules. Now you can conditionally import CSS files based on whether or not there’s support for a certain feature.

For example, you could load different stylesheets based on whether or not CSS Nesting is supported .

Or you could load certain CSS files when a browser does not have support for Cascade Layers . (Note that any @import rules with layer() will automatically be ignored in a browser without layer support.)

Or simply test for a feature. Here, these layout styles will only be loaded if Subgrid is supported .

WebKit for Safari 17.5 adds support for AV1 to WebCodecs when an AV1 hardware decoder is available.

WebKit for Safari 17.5 adds WebGL support for EXT_conservative_depth and NV_shader_noperspective_interpolation .

WKWebView adds support for logging MarketplaceKit errors to the JavaScript console. This will make errors easier to debug.

Bug Fixes and more

In addition to these new features, WebKit for Safari 17.5 includes work polishing existing features.

Accessibility

• Fixed a bug preventing VoiceOver word echoing in some text fields. (122451549) (FB13592798)
• Fixed flickering with multiple accelerated animations and direction changes. (117815004)

Authentication

• Fixed excludeCredentials property being ignored during a passkey registration request. (124405037)
• Fixed the proximity calculation for implicit @scope . (124640124)
• Fixed the Grid track sizing algorithm logical height computation avoid unnecessary grid item updates. (124713418)
• Fixed any @scope limit making the element out of scope. (124956673)
• Fixed native text fields becoming invisible in dark mode. (123658326)
• Fixed fallback native <select> rendering in dark mode. (123845293)
• Fixed scrolling for an element when a video element with pointer-events: none is placed over it. (118936715)
• Fixed HTML5 <audio> playback to continue to the next media activity when in the background. (121268089) (FB13551577)
• Fixed AV1 to decode in hardware on iPhone 15 Pro. (121924090)
• Fixed audio distortion over internal speakers when streaming content in web browsers. (122590884)
• Fixed firing loadeddata events for <audio> and <video> on page load. (124079735) (FB13675360)
• Fixed adjusting the size of the scrollable area when changing betwen non-overlay and overlay scrollbars. (117507268)
• Fixed flickering when showing a layer on a painted background for the first time by avoiding async image decoding. (117533495)
• Fixed line breaking before or between ruby sequences. (122663646)
• Fixed mousemove events in an iframe when the mouse is clicked from outside the iframe and then moves into it while the button is held down. (120540148) (FB13517196)
• Fixed several issues that caused Web Push to not show notifications when the web app or Safari was not already running. (124075358)

Web Inspector

• Fixed info and debug buttons not appearing in the Console Tab until new console messages are displayed. (122923625)
• Fixed WebCodecs to correctly use the VP9 hardware decoder. (123475343)
• Fixed no incoming video in Teams VA. (124406255)
• Fixed the camera pausing occasionally when torch is enabled. (124434403)

Updating to Safari 17.5

Safari 17.5 is available on iOS 17.5 , iPadOS 17.5 , macOS Sonoma 14.5 , macOS Ventura, macOS Monterey and in visionOS 1.2.

If you are running macOS Ventura or macOS Monterey, you can update Safari by itself, without updating macOS. On macOS Ventura, go to  > System Settings > General > Software Update and click “More info…” under Updates Available.

To get the latest version of Safari on iPhone, iPad, or Apple Vision Pro, go to Settings > General > Software Update, and tap to update.

We love hearing from you. To share your thoughts on Safari 17.5, find us on Mastodon at @[email protected] and @[email protected] . Or send a reply on X to @webkit . You can also follow WebKit on LinkedIn . If you run into any issues, we welcome your feedback on Safari UI, or your WebKit bug report about web technologies or Web Inspector. Filing issues really does make a difference.

Download the latest Safari Technology Preview on macOS to stay at the forefront of the web platform and to use the latest Web Inspector features.

You can also find this information in the Safari 17.5 release notes .

• Note20 Ultra
• OnePlus 10 Pro
• iPhone 14 Pro

Viewport Sizes for iPhone

Apple iPhone have Retina Display, Which means iPhone screen shows 2x or 3x higher resolution display instead of normal display to our Eye.

In Retina display, ONE pixel may contains many more pixels, thats why Retina Display or Device Dimensions got bigger and we see high resolution of images and content in smaller display. However devices' actual dimensions depends on actual Pixels Per Inch which is called "Viewport Size" of device or "device-width". Web designs for mobile or CSS responsive styles are based on viewport size of devices, Click here to see popular devices viewport table .

Here we list down all Apple iPhone models with their viewport size, resolution, pixel density, screen size and CSS media queries respectively:

This website uses cookies, We and our partners use technology such as cookies to analyse our traffic and to show you personalised content and ads. You consent to our cookies by clicking "Agree" or by continuing to use our website.

Safari 15: New UI, Theme Colors, and… a CSS-Tricks Cameo!

There’s a 33-minute video (and resources) over on apple.com covering the upcoming Safari changes we saw in the WWDC keynote this year in much more detail. Look who’s got a little cameo in there:

Perhaps the most noticeable thing there in Safari 15 on iOS is URL bar at the bottom ! Dave was speculating in our little Discord watch party that this probably fixes the weird issues with 100vh stuff on iOS. But I really just don’t know, we’ll have to see when it comes out and we can play with it. I’d guess the expectation is that, in order for us to do our own fixed-bottom-UI stuff, we’d be doing:

On desktop, the most noticeable visual feature is probably the theme-color meta tags.

This isn’t even a brand new Apple-only thing. This is the same <meta> tag that Chrome’s Android app has used since 2014 , so you might already be sporting it on your own site. The addition is that it supports media queries.

It’s great to see Safari get aspect-ratio and the new fancy color systems like lab() and lch() as well. Top-level await in JavaScript is great as it makes patterns like conditional imports easier.

I don’t think all this would satisfy Alex . We didn’t exactly get alternative browser engines on iOS or significant PWA enhancements (both of which would be really great to see). But I applaud it all—it’s good stuff. While I do think Google generally takes privacy more seriously than what general internet chatter would have to believe, it’s notable to compare each company’s newly-released features. If you’ll forgive a bit of cherry-picking, Google is working on FLoC , a technology very specifically designed to help targeted advertising. Apple is working on Private Relay , a technology very specifically to making web browsing untrackable.

I’ve been using the iOS 15 beta for a few days, and I’ve liked how Safari handles the viewport height for the most part. While the URL bar is in its normal state, the viewport extends to the bottom of the screen (and going past the safe area on devices with a notch). The viewport shrinks down to right above the URL bar when it becomes hidden.

This video might explain it better than I can.

Last Christmas, my wife got me a new Android phone with 6” display. On it, Android 11 featured Chrome serach bar at the bottom. Firefox for Android also has search bar at the bottom by default (although this can be changed).

I suspect it has something to do with larger screen sizes and top part of the screen not being as acessible on handheld devices (espacially when using single-hand).

If I were to do design prediction, I would say we should see even more movement from headers toward rich footers in the future.

Yeh, I feel another pattern Apple are using is the card from the bottom, which improves the thumb reach area.

The URL bar at the bottom really bugs me. It seems that Apple believes that Safari is the primary app in itself, not a gateway to other experiences on the web.

I see no reason to have the most accessible part of the screen reserved for interacting with the URL bar instead of it being available to websites, to make them easier to use.

Though the notch on their latest models already killed more than 44 CSS pixels of the bottom for interactive use, the new URL bar now demands twice that and does it always, not just until the user has scrolled down the page.

Am I the only one who thinks this actually makes the 100vh issues way more complicated? Ugh.

This is a big change too:

Y’all see the new default html form controls in Safari???!? Woah 🤯 pic.twitter.com/PI6Wm4hhfh — Kevin Gutowski (@kevgski) June 12, 2021

This url bar on mobile is absolutely bad. What this means? You have to fix all old project for one browser! Stupid

There are quite a few bugs. For example, interfaces where you have fixed cards or absolute cards will cause the env() of the tab bar to inexplicably double. -> https://codepen.io/paul3fa/pen/gOmBxxY try this on your phone in debug mode, ios15

Has there been more research on how to handle the new address bar?

I just had to fix this in one of my current project. It seems that using bottom: env(safe-area-inset-bottom) worked out of the box for me, without the need for calc .

How do I get it to apply on Bottom address bar on Safari 15?

It should be default! But if not, 9to5Mac breaks down the steps which you can do with the Safari app open:

• In the address/search bar, tap the “aA” icon on the left (when on a website)
• Tap “Show Bottom Tab Bar”

Alternatively, you can also change the iOS 15 address/search bar by heading to the Settings app > Safari > swipe down and choose “Tab Bar.”

Hope this helps!

how can i disable the divider/border between the adressebar and the website? The divider/border appears only on iOS Safari. A few websites e.g. t3n.de does`t have it.

Best, Florian

Safari 15 still has issues with 3d transform e.g: transform: rotate3d(1, 0, 0, -60deg); Or -webkit-transform: rotate3d(1, 0, 0, -60deg)

it just not renders while any other browser can.

Also still issues with html5 video tags. Somehow IOS restrictions are applied for desktop too :”HTTP servers hosting media files for iOS must support byte-range requests”

Safari is becoming the IE of browsers …

How to Use Inspect Element in Chrome, Safari, & Firefox

Published: May 20, 2024

When I started my coding journey, I couldn’t always pinpoint what made a web page great — all of the code underneath that craft a well-designed experience. So, I would use the inspect element on my browser to peel back the curtain. Here, I could see how pages were coded so I could understand how to recreate elements for my own projects.

The inspect element feature lets us view and even modify any website’s front end. This simple trick can help you understand how websites work and even help you build your own.

In this post, I’ll discuss what it means to “inspect” page elements and how to do so on three common web browsers. If you’re in a pinch, jump ahead to what you’re looking for.

Table of Contents

How to Inspect Elements in Chrome

How to inspect elements in safari, how to inspect elements in firefox, get a closer look with inspect, what does “inspect element” mean.

Inspect element is a feature of modern web browsers that enables anyone to view and edit a website’s source code, including its HTML, CSS, JavaScript, and media files. When the source code is modified with the inspect tool, the changes are shown live inside the browser window.

Inspect is a web professional’s scout team. Developers, designers, and marketers frequently use it to peek inside any website (including their own) to preview content and style changes, fix bugs, or learn how a particular website is built. For instance, if I find an intriguing interface on a competing website, the inspect element lets me see the HTML and CSS that make it up.

I also think of my browser’s inspect feature as a “sandbox” of sorts. I can play around with a web page as much as I want by changing content, colors, fonts, layouts, etc. When finished, I just refresh the page to revert everything to normal.

Inspect doesn’t change the website itself — only how it appears in your browser. You can then experiment without worry!

Inspect is also an incredibly valuable tool for those learning web development. Instead of viewing plain source code, I can use the inspect element to interact with the page and see how each line of code maps to an element or style.

By better understanding what constitutes the typical web page, I can communicate effectively with developers in the case of an error or if I want to make a change.

Inspect may be a “developer tool,” but you don’t need to write any code or install any additional software to use it. You can do everything I’ve described right inside your browser. Let’s learn how.

How to Inspect Elements

To inspect elements, you have to right-click any part of a web page and click Inspect > Inspect Element. Alternatively, you can press Command+Option+i on your Mac or F12 on your PC to do the same.

Every modern web browser has a native tool for inspecting elements. It can be accessed in any browser, but some browsers like Chrome and Safari have slight differences. Let’s discuss how to use the inspect tool in three desktop web browsers: Google Chrome, Apple’s Safari, and Mozilla Firefox.

Chrome comes with a handy developer tool that allows you to inspect individual elements. This allows you to see the code behind a web page and even edit it on your own browser. (Note that the changes are only visible to you, not to anyone else across the web.)

Here's how to get started.

Free Guide: 25 HTML & CSS Coding Hacks

Tangible tips and coding templates from experts to help you code better and faster.

• Coding to Convention
• Being Browser-Friendly
• Minimizing Bugs
• Optimizing Performance

You're all set!

Click this link to access this resource at any time.

1. Launch Chrome and navigate to the page you want to inspect.

To use the element inspector in Google Chrome, I first navigate to any web page. In these examples, I’ll be using HubSpot.com .

2. Open up the Inspect panel.

Once I arrive at my desired page, I have several ways to open Chrome's Inspect tool.

• Option 1 : I can right-click any part of the page and choose Inspect . Right-clicking a specific page element will open that element in the inspector view.
• Option 2 : In the top menu bar, I can select View > Developer > Developer Tools .
• Option 3: I can click the three-dot icon in the top right corner of the browser window. From there, I can choose More Tools > Developer Tools . Then, I can click the Inspect tab in the popup.
• Option 4 : I can use the shortcut control-shift-C on Windows or command-option-C on macOS.

3. Change the location of the inspect panel.

To better view the code, I can change the position of the inspector window.

The Chrome Developer Tools panel will open at the bottom of the browser window, but sometimes it opens in a separate window altogether.

If I want to change the location of the panel, I can click the three-dots icon in the top right corner of the panel (next to the X icon), and then choose my preferred dock position.

Pro tip: Choosing Dock to right makes it easier to view the rendered page and its source:

Along the top of the inspect panel, I see tabs for Elements , Console , Sources , etc. These are all tools I can use to assess a page’s contents and performance. However, everything I need to inspect is under the Elements tab.

4. Look at the source HTML code of the page.

The biggest area of the panel will contain the source HTML of the current page. I always spend some time exploring this region. Hovering the cursor over the piece of code highlights the corresponding element on the page.

Blue indicates the contents of an element, green corresponds to padding, and areas in orange are margins.

Pro tip: If you’re a beginner and want to learn more about the different elements you’re inspecting, check out this HTML guide for beginners.

5. Select a specific element to inspect.

Rather than trying to read through the code to find an element, I can also do the opposite. I can locate a piece of code by hovering over the page element itself. To do this, I click the Element select icon in the top left corner of the panel.

8. Edit the page's CSS code.

Moving down the Chrome inspect panel, I see the Styles tab. This shows me what CSS styling has been applied to the selected element. I can click on lines of code to rewrite them, or I can activate/deactivate certain declarations by checking/unchecking the boxes next to them. I’ll do this for my <h1> element’s font-weight property:

9. View the page's mobile version.

Finally, let’s cover one more feature of Chrome’s inspect feature: mobile view. When building a site, designers need to consider how its pages appear on desktop, mobile, and tablet screens alike.

Fortunately, Chrome lets me preview the same web page in multiple screen resolutions. Start by clicking the Toggle device icon in the top left corner of the panel:

Now, when I click a page element, the Web Inspector reveals the corresponding source code.

7. Edit, add, or delete page elements.

Like Chrome’s inspector, Safari lets me modify, add, and remove page elements. To edit the page, I can right-click an HTML element in the inspect panel. I can then choose an option from the Edit menu.

Web Inspector will prompt me for a new text input and then display my changes in real time:

If I want to delete a page element, I just select some code and delete it. Or, I can right-click and choose Toggle Visibility to hide an element without deleting it.

8. Activate or deactivate the page's CSS code.

To the right, I have the Styles column, where I can change or activate/deactivate CSS declarations for any element, like so:

When testing content and style changes, I want to see the effect on mobile screens as well as desktops. I’ll cover that next.

Pro tip: When seeking inspiration from other web pages, I always take advantage of the Styles tab in my browser’s developer tools to tailor the CSS according to how I envision it on my own page. Try it out. This allows you to refine and adapt design elements to suit your specific preference before moving forward with coding it in your own workspace.

Safari’s Responsive Design Mode allows me to preview a website across common devices.

To view the page in a mobile viewport, I choose Develop → Enter Responsive Design Mode . In this mode, I can use the same inspector tools on pages formatted for Apple devices or set the dimensions myself:

What I like: Safari’s responsive design tab not only lets you test your web page’s responsiveness on devices, but you can also test its behavior across different browsers. Serving as a one-stop-shop for testing responsiveness, the Safari dev tools are a huge time saver.

Firefox is another great option for inspecting a web page in either macOS, Windows, or Linux. Here’s how to get started.

1. Open Firefox's inspect element tool.

To open the Firefox Inspector, I have several options:

• Option 1: I can right-click any part of the page and choose Inspect Element . Right-clicking a specific page element will open that element in the inspector view.
• Option 2: I can select Tools → Browser Tools → Web Developer Tools from the top menu bar.
• Option 3: I can use the shortcut control-shift-I or press f12 in Windows or command-option-I in macOS.

Next, I go to the web page I’d like to inspect. I’ll be using HubSpot.com again.

3. Change the location of the inspector panel.

The Firefox inspector appears along the bottom of the window by default. To change its position, I can select the three-dots icon in the top right corner of the inspector, then choose an alternative display option.

4. Look at the HTML code of the page.

Firefox’s inspector panel is comparable in features to Chrome’s and Safari’s. The HTML source code indicates the corresponding page element with color codes — content is blue, padding is purple, and margins are yellow:

I can also find code by selecting elements on the page. To enter selection mode, I click the cursor icon in the top left corner:

I can then click any page element to reveal its source code in the inspect panel.

6. Modify or delete page elements.

To modify or delete a page element, I select its code in the inspector. Then, I can either double-click to change the text, right-click and choose Edit as HTML, or click Plus Button next to the “Search HTML” bar to add code. Or I can simply delete the code and see the resulting changes on the page.

7. Toggle the page's CSS styles.

To toggle the CSS styling of an element, I use the Filter Styles region at the bottom of the inspect panel. There, I can uncheck the box next to a CSS declaration to deactivate it (or write in new code myself):

8. View the page's mobile version.

Finally, Firefox’s tools also come with a mobile preview option. To use it, I can click the Responsive Design Mode icon in the top right corner of the panel:

Responsive Design Mode lets me choose from several preset screen resolutions or set my own. I can also toggle connection speed and device pixel ratio:

What I like: As a software developer, it is very important that I make web pages that can be easily used by anyone. Firefox’s accessibility tab in its inspector tool allows me to check if my nodes accessibility tree is missing any important properties. I can verify color contrasts too.

The quickest way to access this feature is by right clicking on the page → choose Inspect → select the two arrows next to debugger → select Accessibility .

Once you learn the basics of your browser’s inspect tool, you might realize just how much information about your favorite websites is publicly available. With a few clicks, you can explore how exactly web pages are built, what styles they use, how they optimize for search engines, how they format on mobile screens, and a lot more.

Editor's note: This article was originally published in December 2020 and has been updated for comprehensiveness.

Don't forget to share this post!

Related articles.

The Beginner's Guide to Website Development

Are .io Domains Good? Why Tech Startups Love .io Domains

15 Backend Project Ideas for Your Developer Portfolio

37 Backend Interview Questions and Answers: The Ultimate Guide 2022

How to Build & Run an Effective Website With a Small Team or Budget [Startup Tips]

How to Code a Website for Free in 6 Easy Steps

How Long Does it Take to Build a Website?

Flush DNS: What It Is & How to Easily Clear DNS Cache

How to Make a Website With User Accounts and Profiles [With WordPress, Wix, and More]

Wildcard SSL Certificates: What They Are & How They Work

CMS Hub is flexible for marketers, powerful for developers, and gives customers a personalized, secure experience

• Español – América Latina
• Português – Brasil
• Tiếng Việt
• Chrome for Developers

Introducing the CSS anchor positioning API

The CSS Anchor Positioning API is a game-changer in web development because it lets you natively position elements relative to other elements, known as anchors . This API simplifies complex layout requirements for many interface features like menus and submenus, tooltips, selects, labels, cards, settings dialogs, and many more. With anchor positioning built into the browser, you'll be able to build layered user interfaces without relying on third-party libraries, opening a world of creative possibilities.

Anchor positioning is available from Chrome 125.

Browser Support

Core Concepts: Anchors and positioned elements

At the heart of this API lies the relationship between anchors and positioned elements . An anchor is an element designated as a reference point using the anchor-name property. A positioned element is an element placed relative to an anchor using the position-anchor property or explicitly using anchor-name in its positioning logic.

Setting up anchors

Creating an anchor is straightforward. Apply the anchor-name property to the selected element, and assign it a unique identifier. This unique identifier must be prepended with a double dash, much like a CSS variable.

Once assigned an anchor-name, .anchor-button serves as an anchor, ready to guide the placement of other elements. You can connect this anchor to other elements in one of two ways:

Implicit anchors

The first way to connect an anchor to another element is with an implicit anchor as in the following code example. The position-anchor property is added to the element you want to connect to your anchor, and has the name of the anchor (in this case --anchor-el ) as a value.

With an implicit anchor relationship, you can position elements using the anchor() function without explicitly specifying the anchor name at its first argument.

Explicit anchors

Alternatively, you can use the anchor name directly in the anchor function (for example, top: anchor(--anchor-el bottom ). This is called an explicit anchor , and can be handy if you want to anchor to multiple elements (read on for an example).

Position elements relative to anchors

Anchor positioning builds on CSS absolute positioning To use positioning values you need to add position: absolute to your positioned element. Then, use the anchor() function to apply positioning values. For example, to position an anchored element at the top left of the anchoring element, use the following positioning:

Now you have one element anchored to another, like so:

To use logical positioning for these values, the equivalents are as follows:

• top = inset-block-start
• left = inset-inline-start
• bottom = inset-block-end
• right = inset-inline-end

Center a positioned element with anchor-center

To make it easier to center your anchor positioned element relative to its anchor, there's a new value called anchor-center which can be used with the justify-self , align-self , justify-items , and align-items properties.

This example modifies the previous one by using justify-self: anchor-center to center the positioned element on top of its anchor.

Multiple anchors

Elements can be tethered to more than one anchor. This means you may need to set position values that are positioned relative to more than one anchor. Do this by using the anchor() function and explicitly stating which anchor you are referencing in the first argument. In the following example, the top-left of a positioned element is anchored to the bottom-right of one anchor, and the bottom-right of the positioned element is anchored to the top-left of the second anchor:

Position with inset-area

In addition to the default directional positioning from absolute positioning, there is a new layout mechanism included in the anchoring API called inset area.

Inset area makes it easy to place anchor positioned elements relative to their respective anchors, and works on a 9-cell grid with the anchoring element in the center.

Various possible inset-area positioning options, shown on the 9-cell grid

To use inset area rather than absolute positioning, use the inset-area property, with physical or logical values. For example:

• Top-center: inset-area: top or inset-area: block-start
• Left-center: inset-area: left or inset-area: inline-start
• Bottom-center: inset-area: bottom or inset-area: block-end
• Right-center: inset-area: right or inset-area: inline-end

To explore these positions further, check out the following tool:

Size elements with anchor-size()

The anchor-size() function, also part of the anchor positioning API, can be used to size or position an anchor positioned element based on the size of its anchor (width, height, or inline and block sizes).

The following CSS shows an example of using this for height,using anchor-size(height) within a calc() function to set the maximum height of the tooltip to be two times the height of the anchor.

Use anchor with top-layer elements like popover and dialog

Anchor positioning works incredibly well with top-layer elements like popover . and <dialog> . While these elements are placed in a separate layer from the rest of the DOM subtree, anchor positioning lets you tether them back to, and scroll along with elements not in the top layer. This is a huge win for layered interfaces.

In the following example, a set of tooltip popovers are triggered open using a button. The button is the anchor and the tooltip is the positioned element. You can style the positioned element just like any other anchored element. For this specific example, the anchor-name and position-anchor are inline styles on the button and tooltip. Because each anchor needs a unique anchor name, when generating dynamic content, inlining is the easiest way to do this.

Adjust anchor positions with @position-try

Once you have your initial anchor position, you may want to adjust the position if the anchor reaches the edges of its containing block. To create alternative anchor positions, you can use the @position-try directive along with the position-try-options property.

In the following example, a submenu appears to the right of a menu. Menus and submenus are a great use of the anchor positioning API along with the popover attribute , as these menus tend to be anchored to a trigger button.

For this submenu, if there's not enough space horizontally, you can move it underneath the menu instead. To do this, first set up the initial position:

Then, set up your fallback anchored positions using @position-try :

Finally, connect the two with position-try-options . All together, it looks like this:

Anchor position auto-flip keywords

If you have a basic adjustment, such as flipping from top to bottom or left to right (or both), you can even skip the step of creating custom @position-try declarations and use the built-in browser-supported flip keywords like flip-block and flip-inline . These work as stand-ins for custom @position-try declarations, and can be used in combination with each other:

Flip keywords can significantly simplify your anchor code. With just a few lines, you can create a fully-functional anchor with alternative positions:

position-visibility for anchors in subscrollers

There are some cases in which you may want to anchor an element within a subscroller of the page. In these instances, you can control the visibility of the anchor using position-visibility . When does the anchor stay in view? When does it disappear? You have control over these options with this feature. You use position-visibility: anchors-visible when you want the positioned element to stay in view until the anchor is out of view:

Alternatively, you use position-visibility: no-overflow to prevent the anchor from overflowing its container.

Feature detection and polyfilling

Because browser support is limited at this time, you likely want to use this API with some precautions. First, you can check for support directly in CSS by using the @supports feature query. The way to do this is to wrap your anchor styles in the following:

Additionally, you can polyfill the anchor positioning feature with the CSS anchor positioning polyfill by Oddbird , which works from Firefox 54, Chrome 51, Edge 79, and Safari 10. This polyfill supports most of the basic anchor position features, though the current implementation is not complete and contains some outdated syntax. You can use the unpkg link or import it directly in a package manager.

A note on accessibility

While the anchor positioning API allows an element to be positioned relative to others, it doesn't inherently create any meaningful semantic relationship between them. If there actually is a semantic relationship between the anchor element and the positioned element (for example the positioned element is a sidebar comment about the anchor text), one way to do that is to use aria-details to point from the anchor element to the positioned element(s). Screen reader software is still learning how to deal with aria-details, but support is improving.

If you are using anchor positioning with the popover attribute or with a <dialog> element, the browser will handle the focus navigation corrections for proper accessibility, so you don't need to have your popovers or dialogs in DOM order. Read more on the note on accessibility in the spec.

This is a brand new feature and we're excited to see what you build with it. So far, we've seen some really neat use cases from the community like dynamic labels in charts, connector lines, footnotes, and visual cross-referencing. While you're experimenting with anchor positioning, we'd love to hear your feedback and if you find any bugs, let us know .

Further reading

• Drawing a Line to Connect Elements with CSS Anchor Positioning
• Future CSS: Anchor positioning by Roman Komarov
• Una's Codepen Collection of Anchor demos
• Anchor positioning tool

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2024-05-10 UTC.