Šime’s blog

The dialogs on your website should probably not be taller than 539px

2026-02-15T00:00:00Z

And the reason for that is the iPhone SE, specifically its 2nd (2020) and 3rd (2022) generations. These two iPhone models, which are still actively supported by Apple and run the latest version of iOS, have probably the smallest viewport height of all smartphones in use today: 549px in Safari, and only 539px in Firefox (due to Firefox’s taller address bar).

Dialogs (dialog boxes) on websites that are taller than that won’t fit into the viewport on iPhone SE. In the worst case, the user may not be able to use the website at all. Exactly that happened to Z Centar (a new shopping center in Zagreb, Croatia):

The website shows a newsletter sign-up dialog on page load
The dialog’s close button is located in the upper right corner of the dialog
The close button is not visible in the viewport because the dialog is too tall
The dialog cannot be scrolled at all, so the close button is unreachable

iPhone SE on the left, a typical Android on the right

I opened this website on my iPhone SE because I needed to check the closing times of a bookstore in Z Centar. I could not get past the dialog in my preferred browser (Firefox). That website was effectively down for me. Signing up to the newsletter just to get rid of the dialog does not help either, in case you were wondering. I was at home, so I could access the website from one of my other devices, but if I were out, I would have to think of another way to access the information that I needed, and I’m not sure if I would have had the patience to do that. (I later remembered that Safari has a “Hide distracting items” feature that could have helped me get rid of the dialog.)

It’s worth mentioning that the website would not have had this problem if it used the standard <dialog> element, which provides built-in scrolling functionality if its contents are taller than the viewport. So to the devs of Z Centar, if you need a hotfix, replace the <div> with <dialog> and use the showModal method to show the dialog.

Device modes in browser devtools have an “iPhone SE” preset, but those tools have a critical flaw (IMO). They set the viewport height to the full screen height of the iPhone SE, but on a real iPhone SE, the actual viewport height is of course smaller because the iOS status bar and the browser’s address bar take up some space. So if you test your dialog or similar content in the devtools preset and it fits, it might not fit when I open your website on my iPhone SE. For that reason, you might want to manually check the height of the content and make sure that it’s not taller than 539 pixels.

How to make horizontal scrolling work well in Android browsers

2025-08-11T00:00:00Z

I recently created a small web page that scrolls horizontally instead of vertically. Making it work well in web browsers on Android required a custom solution, which I’ll explain in this blog post.

But first, this is how the page looks:

Try it out at switch2.šime.eu

While creating this page, I wanted to achieve the following behavior:

The content should be full height (as tall as the viewport).
The page should scroll horizontally.
The page should not scroll vertically.

Additionally, all three requirements should continue to be met when the user rotates their phone sideways and Android switches to landscape mode. In other words, I want the same user experience regardless of whether the user holds their phone upright or sideways.

Seems simple enough. Let’s try to make it happen, step by step. (Note: This blog post is longer than it needs to be for educational purposes. If you just want my suggested solution, skip to step 4.)

Step 1: Have the page be very wide

To test how Android browsers handle pages that are very wide, we’ll use a <div> with the following dimensions:

#content {
  width: 3000px;
  height: 95svh;
}

Why 95svh instead of 100svh?

In desktop browsers with classic scrollbars, the horizontal scrollbar at the bottom of the viewport takes up some vertical space (around 17px), so an element that is 100svh tall no longer fits into the viewport, which causes an undesired vertical scrollbar on the viewport — it’s an entire different problem. I wrote a detailed article about that topic. For my simple page, 95svh will be just fine.

Of course, the page needs to have the viewport meta tag:

<meta name="viewport" content="width=device-width">

Test page 1

In Android browsers, the test page is zoomed out on page load. The content is not full height. On my phone, the initial zoom level is around 25%.

full height ❌
scrolls horizontally ✅
doesn’t scroll vertically ✅

It looks like Android browsers detect that the page is too wide and reduce the zoom level to show more of the page content on page load. This is a good default behavior, I guess, but our page is designed to be full height and horizontally scrollable, so we don’t want this behavior. Luckily, it can be disabled.

Step 2: Force the initial zoom level to be 100%

Adding initial-scale=1 to the viewport meta tag tells browsers not to zoom out the page on page load, regardless of how wide it is.

Test page 2

Android browsers show this test page at the default zoom level (100%). The content is full height. But now there’s an additional vertical scrollbar. If the user scrolls down, the content scrolls completely out of view. This is not only useless (there is nothing below the content), but it’s a bad user experience because the user may accidentally swipe up while trying to swipe left or right, or they may instinctively start scrolling down after the page loads and be confused about all the empty space below the content.

full height ✅
scrolls horizontally ✅
doesn’t scroll vertically ❌

Why do Android browsers add this vertical scrollbar? I have a theory.

The user can zoom out (via pinch gestures) until the entire page, in this case the 3000px-wide <div>, is visible in the viewport. The <div> is rendered at the top of the viewport, and there is white space beneath it. This viewport is the layout viewport. The width of this viewport is 3000px (based on the page content), and its aspect ratio is the same as the aspect ratio of the visual viewport. Let’s say this aspect ratio is 3:5. Then the height of the layout viewport is 5000px. When the browser first loads the page, it determines the dimensions of the layout viewport based on the page content and the aspect ratio of the visual viewport: the layout viewport becomes 3000px wide and 5000px tall. Then the browser zooms in to 100% because the page sets initial-scale=1. Now the visual viewport, whose dimensions are around 300px by 500px, is smaller than the layout viewport (whose dimensions don’t change), and that’s why the browser provides both horizontal and vertical scrollbars: to allow the user to freely move the visual viewport within the layout viewport in both directions. This still doesn’t explain why there is no vertical scrollbar on test page 1 (at least not initially). My guess is that when the browser can freely set the initial zoom level to whatever it thinks is the optimal value (test page 1), it can decide to not show the vertical scrollbar if it thinks that it’s not necessary, but when the page forcefully sets the initial zoom level via initial-scale (test page 2), the browser thinks, “The page might be doing something weird with the zoom. I better provide all the scrollbars for my user, just in case.”

It’s difficult to make a web page work the way you want if you don’t understand why browsers behave the way they do. The vertical scrollbar seems to be related to the zoom level. When the page is fully zoomed out, the vertical scrollbar disappears. The vertical scrollbar is present so that the user can zoom out. Is that it? So then maybe if we disable zooming out, the vertical scrollbar will go away.

Step 3: Disable zooming out below 100%

In addition to initial-scale, there also exists minimum-scale. If both are set to the same value (1), the initial zoom level (100%) also becomes the minimum zoom level. The user can zoom in to 200% and zoom back out to 100%, but they can’t zoom out to 50%.

Test page 3

Android browsers indeed stop showing a vertical scrollbar by default. However, if the user force-enables zoom in the browser’s settings (“Zoom on all web sites” in Firefox, “Force enable zoom” in Chrome), the vertical scrollbar reappears.

The mentioned accessibility option exists because some websites didn’t want to allow users to zoom in (above 100%). This option doesn’t really have anything to do with zooming out below 100%. The whole concept of zooming out below 100% doesn’t really exist in Android browsers in practice. Normal websites that scroll vertically cannot be zoomed out below 100%. It’s unfortunate that an accessibility option that exists for an unrelated reason gets in the way of implementing a web page that scrolls horizontally.

full height ✅
scrolls horizontally ✅
doesn’t scroll vertically ✅ (default) ❌ (when zoom is force-enabled)

I don’t know how to reliably achieve the desired behavior with the default viewport scroller. Maybe there is a way, but I haven’t found it (so far). Luckily, the viewport scroller isn’t strictly necessary. We can let an element on the page do the scrolling instead.

Step 4: Put the content in a custom scroll container

We wrap the page content in a <div> and let that <div> act as our horizontal scroll container. By containing the scroll functionality within an element that itself does not overflow the viewport, we completely avoid the issue of the enlarged layout viewport and the resulting vertical scrollbar on the viewport scroller.

#scroller {
  height: 100svh;
  overflow-x: auto;
}

100svh? Didn’t you say 95svh?

In this case, the #scroller element is the scroll container that scrolls the content. The horizontal scrollbar belongs to this element and is contained within it. This element needs to have the full viewport height (100svh) so that the scrollbar appears at the very bottom edge of the viewport, as if it was the scrollbar of the viewport itself. The #content element inside the #scroller element still has a height of 95svh, for the same reason as before.

Test page 4

As far as I can tell, this approach works flawlessly. The user can zoom in normally. When the phone is rotated sideways, the content remains full height. We don’t even need the initial-scale=1 and minimum-scale=1 properties in the viewport meta tag anymore.

full height ✅
scrolls horizontally ✅
doesn’t scroll vertically ✅

Why I use Firefox

2024-02-26T00:00:00Z

Questions like “Which browser should I use?” regularly come up on the r/browsers subreddit. I sometimes respond to these posts, but my quick replies usually only contain one or two points. To be honest, until recently I wasn’t even sure myself why I use Firefox. Of course it’s a pretty good browser, but that doesn’t explain why I’ve stubbornly stayed loyal to Firefox for more than a decade. After giving it a bit more thought, I came up with the following reasons.

1. The about:config page

In Firefox, there is an internal about:config page with thousands (tens of thousands?) of individual configs that can be freely edited by the user. If you don’t like a particular UI element or behavior in Firefox, there’s a good chance that you can change it with a config. The about:config page is also used to individually enable experimental web platform features (without requiring a browser restart like in Chrome).

Here are some of the configs that I’ve edited or added:

devtools.toolbox.zoomValue = 1.2

increases the default text size in Firefox devtools to 120%

browser.tabs.closeWindowWithLastTab = false

prevents the entire browser window from closing when the user closes the last tab (I find this behavior annoying)

devtools.inspector.showUserAgentStyles = true

shows user-agent styles in the CSS Rules pane in Firefox devtools (why are user-agent styles hidden by default?)

browser.chrome.guess_favicon = false

stops Firefox from attempting to load the website’s favicon from the default location when an icon is not declared in the HTML document (I use this config to get rid of the distracting ”favicon not found” errors in the devtools console)

browser.urlbar.resultMenu.keyboardAccessible = false

removes menu buttons from the individual items in the URL bar dropdown list (those buttons make tabbing through the items slower)

2. Mozilla cannot decrypt my data on their servers

All the major browsers have a feature for syncing the user’s browsing data across devices (Firefox Sync, Chrome Sync, Apple iCloud, and so on). The user’s data is stored on the browser vendor’s servers, and this data is of course encrypted. But can the browser vendor decrypt this data? Google can. Apple claims that they can’t, but they have disclosed user data to law enforcement in the past, so I don’t trust them. Mozilla says that they can’t, and I trust them.

It seems that Mozilla goes out of their way to make absolutely sure that they can’t access the synced browsing data of Firefox users. The encryption is strong enough that with current technology it would take trillions of years to break into this data, so it’s pretty safe. However, if I somehow managed to lose all my devices where I’ve activated Firefox Sync, my browsing data on Mozilla’s servers would be lost forever; there would be no way of recovering it. Still, I like the idea of using a browser from a company that does not want to access my data on their own servers. I feel like this is how it should be.

3. Translating web pages is also completely private

Firefox Translations is a relatively new feature that allows users to translate web pages to a different language (from a small set of supported languages) directly in the browser, without sending any data to any servers. This feature is based on machine learning and neural networks.

This is another example of Mozilla going the extra mile to protect the user’s privacy.

4. Mozilla develops their own browser engine

Firefox uses Mozilla’s Gecko browser engine. No other major browser uses Gecko. The web is my favorite platform, and since a diversity of browser engines is good for the web*, I want to support Gecko. By using Firefox and reporting Firefox and web compat bugs, I’m doing my part.

*Allow me to quote Google’s F.A.Q. from 2013 when they forked WebKit:

Hold up, isn't more browsers sharing WebKit better for compatibility?

It's important to remember that WebKit is already not a homogenous target for developers. For example, features like WebGL and IndexedDB are only supported in some WebKit-based browsers. Understanding WebKit for Developers helps explain the details, like why <video>, fonts and 3D transforms implementations vary across WebKit browsers.

Today Firefox uses the Gecko engine, which isn’t based on WebKit, yet the two have a high level of compatibility. We’re adopting a similar approach to Mozilla by having a distinct yet compatible open-source engine. We will also continue to have open bug tracking and implementation status so you can see and contribute to what we’re working on at any time.

From a short-term perspective, monocultures seem good for developer productivity. From the long-term perspective, however, monocultures inevitably lead to stagnation. It is our firm belief that more options in rendering engines will lead to more innovation and a healthier web ecosystem.

How does this affect web standards?

Bringing a new browser engine into the world increases diversity. Though that in itself isn't our goal, it has the beneficial effect of ensuring that multiple interoperable implementations of accepted standards exist. Each engine will approach the same problem from a different direction, meaning that web developers can be more confident in the performance and security characteristics of the end result. It also makes it less likely that one implementation's quirks become de facto standards, which is good for the open web at large.

I couldn’t have said it better. We currently have three major browser engines—and a couple of smaller ones in development—and of those three, Gecko is the only one that may be at risk. I’m not sure what Gecko’s conservation status would be if it were a real animal (probably “Conservation Dependent”), but I don't plan on giving up on it anytime soon.

5. The best support for extensions on Android

The web has unfortunately become slower and more annoying over the past decade. Extensions that block ads and other types of problematic content have become necessary to have a normal web browsing experience. On Android, Firefox has by far the best support for browser extensions. This includes uBlock Origin (the best ad-blocker) and extensions for adding user styles and user scripts to websites. I actively use all of these extensions (uBlock Origin, Stylus, Tampermonkey) on desktop to tweak websites to my liking. It is awesome that Firefox users on Android can do the same.

6. A great picture-in-picture player

I should probably finally mention an actual feature in Firefox that a regular user might find useful. I don’t really use Firefox for its general features, but if there’s one such feature that I really like, it’s the native picture-in-picture video player in desktop Firefox, which is superb. It has everything that one could ask for. It can be quickly opened via an overlay button that is shown when hovering any video. It can be resized and positioned anywhere on the screen. It has the full controls, including pause, mute, and the seek bar for skipping to any point in the video. I use it all the time.

In summary

I trust Mozilla more than I trust Google, Apple, Microsoft, or any other company that makes web browsers. This trust is based on the fact that Mozilla chooses the highest level of user privacy when developing services such as Firefox Sync, Firefox Translate, and others. A web browser is an integral part of a person’s online life, so it makes sense to choose a browser from a company that one trusts the most.

In addition to that, Firefox offers the highest level of customization, whether it’s through browser extensions or internal configs. This is important to me because I prefer websites over native apps.

Any great feature, such as the picture-in-picture player, is just the cherry on top. I understand that for most people it’s probably the other way around. They care about features more than they care about privacy and customization. That is fine. There is no wrong answer. Everyone should use the browser that serves them best.

24 seconds to view the product images on Amazon’s website

2024-01-31T00:00:00Z

Earlier this month I finally retired my Motorola G4 that served me well for testing web performance for over half a decade. The new device that I got is the Nokia C02 (view specs). In terms of CPU and RAM, it’s the lowest-end Android smartphone I could find that was released by a mainstream brand in 2023. According to Speedometer, it’s about 25% slower than the 2016 Motorola G4. Yes, slower.

Did I go too low? I don’t think so. Around 4 billion people browse the web using smartphones. If we were to sort these 4 billion smartphones by web performance, the Nokia C02 would probably not be in the bottom 5%, and maybe not even in the bottom 10% (I’m just guessing). So when a website is too slow on my Nokia, then it’s too slow for probably at least a few hundred million people, and that’s unacceptable.

When I saw a post on my Mastodon timeline about the poor performance of Amazon’s website, and the dangers of not testing on real devices, I had to see for myself. I loaded the product page for some vase on my Nokia, and at first everything seemed more or less fine. The page rendered within a couple of seconds, and there was no major scroll jank. The experience was acceptable.

I was about to end the test and conclude that it’s not as bad as the performance profile made it out to be, but then I tried to view the other product images. The first two images rendered immediately, but none of the other images had loaded. So I waited. And waited. I imagined that some JavaScript error might have caused the loading spinner to get stuck. I put the phone down and returned to my laptop because modern technology has ruined my attention span, and I can’t just gaze at a loading screen for more than 10 seconds without any progress. Another 10 seconds later, the image finally appeared.

Tested in Chrome on a 34 Mbps connection.

I repeated the test a few more times across different product pages to confirm that it wasn’t just a fluke. Overall, it takes about 24 seconds from navigation start to product image render. That’s on the Nokia C02. I also performed a site performance test with an “emulated Motorola G4” on WebPageTest. The test result shows about 10 seconds of scripting on the main thread, and the first 30 seconds are riddled with long tasks. According to my browser’s devtools, a typical product page on Amazon’s website executes around 7 MB of JavaScript.

While this is undoubtedly too much JavaScript (five times more than I would be comfortable with), users on low-end devices can still have a passable experience—at the expense of their device’s battery percentage—as long as they don’t have to wait too long for each individual event. But in this case, waiting 20+ seconds for the product images to load is too long.

Since the first two product images load immediately, it could be that Amazon decided to eagerly load only those two images because they determined that by the time the user swipes to the third image, most if not all of the JavaScript has already been executed anyway, so there’s only a small delay. Amazon’s test devices must be more powerful than my Nokia. Amazon should consider eagerly loading all product images. After all, viewing these images is one of the first things the user does after checking the price, isn’t it? If that’s not possible, Amazon could probably reduce the image loading delay by prioritizing the JavaScript that is responsible for loading the images, and making sure that the images can load faster if needed, without being delayed by other resources.

But those are just my surface-level thoughts. I don’t have the whole picture. I’m sure Amazon knows how to fix this issue, assuming that it can be fixed without a major overhaul of the code. The only question is whether they consider this issue to be important enough to be prioritized. In the meantime, I’ll stick to my admittedly simplistic rule: If it’s too slow on my Nokia, it’s unacceptable.

Websites shouldn’t reject passwords generated by browsers

2024-01-28T00:00:00Z

When I decided to get the domain šime.eu for my blog, I had to find a domain name registrar that supports .eu domains. My first choice was Netim (I forgot why). I added my order for šime.eu to the cart, and the next step was to create an account. My browser, Firefox, offered to generate a secure password, which I of course accepted, but when I tried to submit the form, the website showed the error message “The password provided is invalid”.

I was confused. According to the tooltip, the password meets all the requirements. It even says that it’s a strong password. So what’s the problem? I didn’t have the patience to figure out the reason, but it turns out that when Netim says “at least one symbol”, they don’t mean any symbol; they mean one of the 13 supported symbols that are listed in the tooltip. I’ll leave it to you to figure out which symbol in the password generated by Firefox is not supported. What a fun game, huh?

I reported this issue to Netim, and they said that they asked their dev team to add more characters to the list. They should probably test their account creation form in every major browser, since different browsers use different algorithms for generating secure passwords. If I were an expert in this field, I could give you better advice on exactly which symbols to support (all of them?), but one thing seems clear to me: Websites should not reject passwords generated by browsers.