ios safari navigation bar css

Using Bottom Tab Bars on Safari iOS 15

Jun 17, 2021 (Updated Sep 23, 2021)

Apple recently announced the latest version of Safari on iOS 15 with a completely new design featuring a bottom floating tab bar. What does this mean for web developers and designers?

Safari on iOS has had a problem for a long time when it comes to building websites and web apps with bottom-aligned navigation due to the browser toolbar's dynamic height. As you scroll the toolbar disappears making any element that is fixed to the bottom of the screen look great, but as soon as you try to tap any link inside the browser toolbar appears again.

Sorry, your browser doesn't support embedded videos.

This makes for a really poor UX so designers and developers have mostly resorted to user "hamburger" menus instead. This is a shame as bottom tab bars increase discoverability by not hiding links behind a tap and are also easier to reach one-handed on todays large mobile devices.

Updates with Safari 15

Apple reverted some of these changes in the final iOS 15 release. The user can now choose between the old UI (top bar) or the new one. If they choose the new bottom bar UI it does not float as much greatly improving overlap issues. While you might not need safe areas anymore if you're lucky, I would still recommend to implement it as I've seen it cause issues anyways.

The new Safari 15 now has a tab bar floating at the bottom of the screen. At first it might seem like this makes it even harder to create tab bar navigations, and by browsing the web using iOS 15 it's easy to spot issues like this:

Fixing Tab Bar Overlap with Safe Areas

Thankfully solving this issue is very easy by using the env() CSS function together with safe-area-inset-bottom . This API was shipped with iOS 11 making it possible to customize how websites render when using devices with a notch. By inspecting pinterests code we can see that their tab bar has a fixed position anchored to the bottom, the relevant parts look something like this:

To respect the safe area and make sure that nothing from the browser UI overlaps let's add another bottom property with env(safe-area-inset-bottom) as a value. This function works like a CSS variable, returning the minimum amount of inset needed to keep your UI from overlapping with the browser's. We keep the old style rule as a fallback browsers that do not support it:

Now when scrolling nothing overlaps:

Be sure to use env() every time something is anchored to the bottom of the screen or overlap will likely appear. env() can also be combined with css calc() or min() and max() , so if your design needs more padding you can add it like this:

You can learn more about respecting the safe-area in this excellent article published on the webkit blog or Apple's WWDC session called Design for Safari 15 (Relevent part starts around 13 minutes in).

The best way to see if you got it right is to use a physical device with iOS 15, but if you don't have access to one you can download the Xcode 13 beta from Apples developer portal and use an iOS 15 simulator by going to Xcode > Open Developer Tool > Simulator

Tab Bar UX in iOS 15

Remember the issue in previous versions of Safari where you had to click twice when using bottom tab bars? Once for showing the safari toolbar and another tap for actually triggering your link? That is no longer an issue 🙌. Safari 15 now respects and follows links or buttons, which is a big improvement! Check out how much better Twitter's tabbar works when switching tabs on Safari 15:

Even if tab bars now technically work better than before we still have to consider the design and UX to create something that people understand and that looks good. The browser UI is now very bottom-heavy and placing more actions next to it might feel cluttered. What do you think? Let me know on twitter @samuelkraft .

I'm excited to see how everyone adapts to the new UI and if we will see a return of tab bars on the web or not.

Get an email when i write new posts. Learn animation techniques, CSS, design systems and more

Related posts

Dec 18, 2021

Dec 15, 2021

Sep 07, 2021

• 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.

Amit Merchant Verified ($10/year for the domain)

A blog on PHP, JavaScript, and more

Designing websites keeping floating tab bar of Safari 15 (on iOS) in mind

September 2, 2021 · Safari

The newest version of Safari, i.e Safari 15 , on iOS is great. It comes with an all-new layout and a new way of navigating websites on it.

Essentially, the address bar is now moved to the bottom of the screen and it now adjusts itself as you scroll the website. As you swipe on a webpage, the tab bar minimizes into the bottom of the app. Swipe back up or tap at the bottom to make the tab bar reappear.

The problem

The safe-area-inset-* properties.

So, for instance, if the website would look something like following when you’re not scrolling along.

And as soon as you start scrolling, the tab bar/address bar will reappear like so.

This is to make the entire experience of visiting a website more seamless and appealing.

This improvement/enhancement comes with a shortcoming. The “floating” nature of the tab bar hurts in some scenarios.

Take the following for example.

As you can see, in this example, the tab bar is actually obstructing the footer of the website and it’s really hard to tap on those buttons now.

How to get around this problem?

Well, it turns out, the CSS has its answer in form of safe-area-inset-* properties.

By using the safe-area-inset-* properties in conjunction with the env() , it’s possible to mitigate this issue.

There are four kinds of safe-area-inset-* properties

• safe-area-inset-top
• safe-area-inset-right
• safe-area-inset-bottom
• safe-area-inset-left

These properties define a rectangle by its top, right, bottom, and left insets from the edge of the viewport, which is safe to put content into without risking it being cut off by the shape of a non‑rectangular display.

In the case of Safari 15, the safe area is the rectangle area that resides above the tab bar (when scrolling) as shown below.

As you can tell, the green area shown in both of the cases defines the safe area and so, we can adjust the design of our website accordingly.

So, if we want to do that, we can use the env() and safe-area-inset-bottom to give the bottom padding that it needs like so.

When done, the footer will have that extra padding, thanks to safe-area-inset-bottom . And now, those two buttons won’t be obstructed by the tab bar anymore.

In the usual scenario, let’s say in the Chrome browser, the safe-area-inset-bottom will always be 0 . So, the footer would look normal. The safe-area-inset-bottom will only kick in when the website is loaded on Safari 15 on iOS.

And this is how you can make your website compatible with Safari 15 without sacrificing the experience!

» Share: Twitter , Facebook , Hacker News

Like this article? Consider leaving a

👋 Hi there! I'm Amit . I write articles about all things web development. You can become a sponsor on my blog to help me continue my writing journey and get your brand in front of thousands of eyes.

More on similar topics

Dock installable web apps in Safari macOS Sonoma

Get your website ready for new tab bar theming of Safari 15

Awesome Sponsors

Download my eBook

Recommendation(s)

Get the latest articles delivered right to your inbox!

No spam guaranteed.

Follow me everywhere

More in "Safari"

Recently published.

A browser to take cleaner screenshots of websites NEW

A few new array functions are making their way into PHP 8.4

Cloning queries in Laravel

Ignore and acknowledge class attribute on elements in CSS

The new Quick Search Text in VS Code is Gooood!

Top Categories

Using Bottom Tab Bars on Safari iOS 15

Published on Jun 17, 2021 (Updated Jun 29, 2021) · 4 min read · -- Views

Apple recently announced the latest version of Safari on iOS 15 with a completely new design featuring a bottom floating tab bar. What does this mean for web developers and designers?

Safari on iOS has had a problem for a long time when it comes to building websites and web apps with bottom-aligned navigation due to the browser toolbar's dynamic height. As you scroll the toolbar disappears making any element that is fixed to the bottom of the screen look great, but as soon as you try to tap any link inside the browser toolbar appears again.

This makes for a really poor UX so designers and developers have mostly resorted to user "hamburger" menus instead. This is a shame as bottom tab bars increase discoverability by not hiding links behind a tap and are also easier to reach one-handed on todays large mobile devices.

Updates with Safari 15

The new Safari 15 now has a tab bar floating at the bottom of the screen. At first it might seem like this makes it even harder to create tab bar navigations, and by browsing the web using iOS 15 it's easy to spot issues like this:

Fixing Tab Bar Overlap with Safe Areas

Thankfully solving this issue is very easy by using the env() CSS function together with safe-area-inset-bottom . This API was shipped with iOS 11 making it possible to customize how websites render when using devices with a notch. By inspecting pinterests code we can see that their tab bar has a fixed position anchored to the bottom, the relevant parts look something like this:

To respect the safe area and make sure that nothing from the browser UI overlaps let's add another bottom property with env(safe-area-inset-bottom) as a value. This function works like a CSS variable, returning the minimum amount of inset needed to keep your UI from overlapping with the browser's. We keep the old style rule as a fallback browsers that do not support it:

Now when scrolling nothing overlaps:

Be sure to use env() every time something is anchored to the bottom of the screen or overlap will likely appear. env() can also be combined with css calc() or min() and max() , so if your design needs more padding you can add it like this:

You can learn more about respecting the safe-area in this excellent article published on the webkit blog or Apple's WWDC session called Design for Safari 15 (Relevent part starts around 13 minutes in).

The best way to see if you got it right is to use a physical device with iOS 15, but if you don't have access to one you can download the Xcode 13 beta from Apples developer portal and use an iOS 15 simulator by going to Xcode > Open Developer Tool > Simulator

Tab Bar UX in iOS 15

Remember the issue in previous versions of Safari where you had to click twice when using bottom tab bars? Once for showing the safari toolbar and another tap for actually triggering your link? That is no longer an issue 🙌. Safari 15 now respects and follows links or buttons, which is a big improvement! Check out how much better Twitter's tabbar works when switching tabs on Safari 15:

Even if tab bars now technically work better than before we still have to consider the design and UX to create something that people understand and that looks good. The browser UI is now very bottom-heavy and placing more actions next to it might feel cluttered. What do you think? Let me know on twitter @samuelkraft .

I'm excited to see how everyone adapts to the new UI and if we will see a return of tab bars on the web or not.

Enjoyed this post? Subscribe to the newsletter!

A newsletter in the realm between design & development . Learn animations, CSS, web development tips & tricks and creating delightful and useful interfaces!

No spam, unsubcribe at any time!

Related Posts

Creating a chat messaging app ui with CSS (with a sprinkle of JS and Framer Motion)

Published on Feb 21, 2021 · 8 min read

Create a rating component with svg stars that support fractional values

Published on Sep 07, 2021 · 4 min read

How to create an animated icon perfect for visualizing music

Published on Jan 31, 2021 · 5 min read

Overlapping bottom navigation bar despite 100vh in iOS Safari

»100vh« may not behave as expected for some mobile browsers and the bottom of your content will be partially hidden behind the browser’s bottom bar (i.e. below the »fold«).

First of all, let’s have a look at the issue by checking out the following example. It’s a simple page with 2 absolutely positioned boxes in the top left corner ( .top ) and the right bottom corner ( .bottom ). These boxes are wrapped within an element ( .container ) with a width of 100vw and a height of 100vh . You may have something similar in your project, such as a fullscreen modal/lightbox with a header/footer.

This should span accross the full viewport, right? Well, in the left screenshot below, you can see that in iOS Safari the bottom navigation bar actually overlaps your content, i.e. your content is below the »fold«—although you may have expected that it’s not part of the viewport.

In the right screenshot, you can see how one would expect the layout to be. The container spans between the top address bar and the bottom navigation bar.

This is a well-known issue and unfortunately intentional, as it prevents other problems, as Benjamin Poulain explained in his reply to a WebKit bug ticket regarding this issue.

This is completely intentional. It took quite a bit of work on our part to achieve this effect.

The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS).

It is hard to show you the "looks like shit" part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting.

Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size.

From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.

So, it’s not a bug—and no fix is planned for this.

Luckily, this doesn't have to be the most depresssing answer ever. How do we go on from this? There’s a couple of solutions.

Depending on your use case, it may be enough to simply use 100% instead of 100vh , especially for fixed/sticky elements (as 100% will be relative to the »real« viewport).

However, if your element is nested somewhere in the DOM, this may not work out (as 100% will be relative to the parent elements which are only as tall as the content they contain). And that may have been the motivation why you wanted to use 100vh in the first place.

stretch / -webkit-fill-available

Intrinsic and extrinsic sizing is a new CSS functionality that extends the sizing properties with keywords that represent content-based »intrinsic« sizes and context-based »extrinsic« sizes. This allows CSS to more easily describe boxes that fit their content or fit into a particular layout context.

One of these keywords is stretch which formerly was known as fill , fill-available , and its prefixed spin-offs -moz-available and -webkit-fill-available . We can make use of this functionality and because CSS skips over style declarations it doesn’t understand, we can implement fallbacks for all of these possible implementations.

(Hint: Autoprefixer will compile stretch to -webkit-fill-available and -moz-available automatically.)

JavaScript is always the »last stronghold« for stuff that’s not possible with pure CSS. Using CSS variables, you can pass the value of window.innerHeight into your CSS and update this variable every time the viewport is resized.

In your CSS, you can consume this variable as follows.

If you can’t use CSS variables in your project (e.g. due to browser support concerns), you can also update the height of your affected elements directly from within your script.

Unfortunately, there isn’t a one-size-fits-all solution for this issue. You should try the aforementioned solutions top down and be very conscientious with your cross-browser/cross-device testing.

• Discuss on Twitter
• Edit on GitHub

How to change the iOS navigation's bar background-color

To make a website fullscreen on iOS, add the following to index.html header:

You can change the bar's color behind the URL by setting the theme color (no need to modify the CSS). For example, let's change the background to black:

Or to navy:

If you remove the theme-color meta tag, iOS will decide the background color (generally it'll use the same color as the one in the body).

Hi, I'm Erik, an engineer from Barcelona. If you like the post or have any comments, say hi .

More articles

This iPhone Setting Will Make It Easy To Switch Between Pages On Safari

Even though Safari is Apple's official browser app for its devices, you can actually change your iPhone's default web browser to a third-party option. If you do, though, you may miss out on some of the features and upgrades Apple's made to Safari over the last few years. For instance, in 2022 with iOS 16, Apple added passkeys, a more secure way of logging in to apps and service while browsing the web than standard passwords. Meanwhile, those who've recently upgraded to last year's iOS 17 can enjoy an overall faster search that provides more relevant related suggestions. The company also added a feature to lock private browsing tabs between uses.

With the imminent release of iOS 18 this fall, it can be easy to overlook iPhone features that came out long ago. For Safari, there are  little known features  like the ability to create tab groups. Apple's also added features to change the location of the Safari address bar, a setting that  initially irked iPhone users . This setting though actually unlocks a pretty useful and seemingly underutilized feature that makes it easy to page-hop on the browser app.

How to change the tab bar location

Since Apple released iOS 15 in 2021, iPhone users have had the option to pick between two address bar placements for the mobile browser's interface: the original that places the search field at the top of the screen, or a newer "tab bar" layout that places it at the bottom of the screen instead. Here's how you can make modifications to how Safari looks like on your iPhone:

• Launch the Settings app.
• Scroll down and go to Safari.
• Under the Tabs section, select Single Tab to place the address bar up top. Otherwise, pick Tab Bar to have the address bar placed at the bottom.

The top tab bar option is likely what a lot of mobile browser users are accustomed to as top-of-page is often the default placement of address bars across a variety of browser apps, including those used on computers. If you want more flexibility in your use of the browser app on your iPhone though, there is merit to picking the lesser known page layout instead. Not only is it more thumb-friendly, but it adds certain browsing features that are only accessible when you do so.

Surfing Safari's tab bar layout

If you opt for the bottom Tab Bar view in the Settings app, you can easily switch from one web page to another by swiping left or right on the address bar at the bottom of the screen. If you have several browser tabs open at once, you can essentially flip through them, as if you're reading a book. Meanwhile, if you choose to stick with Safari's Single Tab layout, you can only view one page at a time. You'll also need to click on the Tabs switcher icon to see all your open pages or any tab groups that you may have.

Based on testing, embracing the unconventional bottom-of-the-screen address bar placement has a few perks. It makes it more convenient to use Safari and operate your iPhone one-handed . You can quickly type in new searches or websites into the search field since it's closer to the thumb of the hand holding your device. It's also easier to scroll through your tab group carousel — that's also located at the bottom of the iPhone screen — when you hit the Tab switcher icon to view all your open tabs.

The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home › Forums › Other › Hide ios Safari search/URL bar?

• This topic is empty.
• Author Posts

Hello everyone,

For those of you using ios Safari…I’m curious if there is a standard method for hiding the search/url bar for websites added to the home screen.

Here is an example: http://blog.mengto.com/

Access this site after adding it to the homescreen, you will notice that the url/search bar is hidden.

Any help is appreciated. Thanks

Just remember to keep in mind that hiding default behaviour isn’t always the best.

You have to options here. The meta tag posted above really hides it so your page look likes an app. If its not a web-app, I wont do this. Instead, try this:

window.addEventListener( “load”, function () { setTimeout( function () { window.scrollTo( 0, 1 ); }, 0 ); });

That way, the user still can scroll to the top to access the addressbar.

• The forum ‘Other’ is closed to new topics and replies.