The latest user agents for Safari

Apple's Safari web browser runs on mobile devices (iPhones, iPads and iPod Touches) and macOS computers. Depending on which platform you're using (or want to pretend you're using!) the user agent will be a bit different.

Here we have the latest user agents for Safari on mobile and computer platforms.

Unlike some other popular browsers and platforms, we've noticed that Safari definitely seems to have less "extra" stuff in its user agent - standard Safari will never announce the exact model number of the device being used, and there's generally much less additional fragments added by installed addons/apps - toolbars and so on.

That said, you're welcome to explore our huge listing of various Safari user agents to see the different variations of user agents.

Latest Safari on macOS User Agents

Latest safari on ios user agents, special notes, safari on ios 13.

You may have already noticed, but Safari on the latest version of iOS (version 13) no longer includes fragments to indicate that Safari's running on iOS... instead the user agent is indistinguishable from the desktop version of macOS.

As such, it's not possible to provide valid sample user agents for them any more.

Build numbers and OS version numbers

Test it out.

You can use our User Agent Parser page to try out different user agent varieties, or to test if your user agent switcher is working properly.

Database of user agents

If you're interested in our database of many millions of user agents, please check out our API which provides access to our user agent database . You can perform very detailed and specific queries on it to find user agents that match your exact criteria - version numbers, hardware types, platforms and so on.

Clear cache & history

Do i need to clear my cache.

Not sure why you've been asked to clear your cache? We can explain. Why you need to clear your cache

What is a cache?

Before you consider clearing your browser cache, you should know what it is! Learn a little bit about browser caches

Is it safe to clear my cache?

Are there any risks to clearing your cache? Find out if it's ok to clear your cache

Update my web browser

Do i need to update my browser.

Find out if your browser is out of date Is my browser out of date?

Why should I update my browser?

There are very good reasons to, find out here! Why update your browser?

Is it free to update Chrome?

Find out about the cost of updating Chrome... Does Chrome cost anything?

What does "Update browser" mean?

What does it actually mean? What does it mean to update your browser

Get help with our guides

How to enable javascript.

Change your JavaScript settings Guide to enabling Javascript

How to enable Cookies

Configure your cookie settings for privacy Guide to enabling cookies

Related articles

I can't log in to a website..

We've got a detailed guide to help you solve login problems How to fix website log in problems

Why do websites use cookies?

Why are cookies useful? Do you need them? What's the deal with cookies?

How to update your browser

Old software puts you at risk. Keep your browser fresh and up to date

Clear Cache, Cookies and History

How to reset your browsing history How to reset your browser

Try a different web browser

Different web browsers have different features - try a different one to see if you prefer it. Experiment a bit!

Use a VPN to hide your IP address

We recommend NordVPN to hide your IP address or to unblock websites. Hide your IP Address

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more .

Things I Learned Reading Webkit’s UA Stylesheet

I browsed through Webkit’s user agent stylesheet for no other reason than curiosity (you can find via trac or GitHub ).

A number of interesting things stood out to me, so I started taking notes. I figured it’d make for a good blog post.

Here are my notes.

The very first thing I encounter, before any novel selectors, properties, or values, is this thing I’ve never seen or used in my life: @namespace .

My first reaction: “what the hell is this?”

Honestly, I dug around and never got to a point I where I feel like I can confidently say what it is and why you would use it.

Meme from Lord of the Rings where Boromir asks, “What is this new devilry?” and Gandalf says “It’s @namespace—a demon of the ancient web. It is beyond any of you. RUUUUUUUUN!”

The best example I could find for how/where you might use @namespace is from an O’Reilly book called Using SVG with CSS3 and HTML5 . There’s a chapter about XML Namespaces in CSS describing how @namespace can help “when you want to distinguish between SVG and HTML elements with the same tag names”. As an example:

That sort-of makes sense, but having never had this problem, I can’t fully appreciate how helpful @namespace can be.

Anyhow, if novel things in CSS interest you and you’ve never heard of @namespace , you might want to read more from people who actually know what they’re talking about. FWIW: these links, in addition to the O’Reilly one above, were the most helpful to me:

  • MDN article on @namespace
  • Sara Soueidan on Tympanus

If Statements

Honestly, I’m not sure how these play out. It almost looks like they are executed/evaluated at runtime to apply conditional styling based on system-level configuration ( update : some insider information reveals this is “done at compile-time by running the stylesheet through the C preprocessor ”).

Here’s another example:

It’s not anything us normal web developers can use in our stylesheets, but interesting to see how special styling considerations are taken into account based on the browser knowing about what OS it’s running on.

CSS Keywords

I saw a bunch of keywords. Some standard, others not. For example:

ThreeDFace is an example of a system color , which is part of the specification .

Whereas other values like text , -apple- , and -webkit- are specific to the browser or browser maker.

Curious about what values exist? Here’s a sampling from the 1,500+ lines in CSSValueKeywords.in :

A bunch of the values appear to map to Apple’s OS-level color variables , presumably allowing developers of Safari to imbue browser controls with system-level appearance configurations from the OS.

Handling Legacy Quirks

1__qem was another one of those “what the hell is this thing?” Here’s an example pulled from the UA stylesheet:

Apparently this unit of measurement is webkit magic for handling legacy functionality related to quirks mode (“qem” stands for “quirky em”).

I don’t think it will surprise you to learn that handling legacy browser quirks is a common theme in the UA stylesheet. There’s a number of places where browser-specific values are leveraged to treat legacy quirks. Here’s another example from the code:

Webkit “Extensions”

There are a whole bunch of non-standard properties, values, and pseudo elements specific to Webkit. Take a look at these examples pulled from the code:

MDN even has a giant reference of CSS “extensions” for Webkit but not everything in the UA stylesheet is documented on MDN.

If you really want to dive deeper, you can look at the CSS value keywords file and guess at what these non-standard values do when listed alongside their standardized siblings. For example, -webkit-match-parent appears to have something to do with aligning elements.

Custom Form Element Graphics

You know those little icons you see in specific browsers which hint at browser-injected functionality? For example, this credentials autofill UI:

A form field in Safari with webkit-specific UI elements denoting the field can be autofilled by the OS with credentials the user has saved.

Note the little key icon with a dropdown? Webkit appears to implement UI details like that as webkit-specific pseudo elements. The key/dropdown graphic is implemented as an inline SVG in the UA stylesheet. Example:

If you were to extract that <svg>...</svg> code from the inline data URL in the UA stylesheet and put it in the browser, you’d see the same graphic:

An icon of a key with a dropdown caret.

System Font Keyword

font: message-box

Once again: what the hell is this? According to MDN

The font property may be specified as either a single keyword, which will select a system font, or as a shorthand for various font-related properties.

I’m familiar with the shorthand:

But a single keyword?

Apparently there are system font keywords. Example from MDN:

caption : The system font used for captioned controls (e.g., buttons, drop-downs, etc.). icon : The system font used to label icons. menu : The system font used in menus (e.g., dropdown menus and menu lists).

This lets you do some crazy stuff I didn’t know you could—nor can I think of why you would. Nonetheless, it exists. Checkout the codepen

Screenshot of various fonts displayed in HTML and styled with the system font keyword shorthand.

Appears to be another one of those system things .

Strangely Specific z-index Values

It’s pretty common that, when you want a high z-index, you do something like z-index: 9999999 .

Interestingly, there are only three z-index values in Webkit’s UA stylesheet. All three of them are high, strangely-specific numbers:

I figured this had to be something to do with programmers infusing some kind of joke or meaning into the number rather than just an arbitrarily high number.

I found a site called numbermatics.com which lets you punch in a number and discover its unique traits. Here’s what I found:

  • 2147483644 - composite of four primes multiplied together
  • 2147483645 - composite of three primes multiplied together
  • 2147483647 - is not only a prime number but is “the maximum positive value for a 32-bit signed binary integer in computing. It is therefore the maximum value for variables declared as integers…in many programming languages” ( Wikipedia )

I don’t think you can get a much higher z-index than that—UA stylesheet trumps all!

Crazy Selectors

There are some crazy selectors in the UA stylesheet, like this for handling H1 tags nested five levels deep under any given combination of four different elements:

The :is selector is pretty damn cool. Given the combinatorial nature of these groupings, writing something like this in CSS before :is would’ve been insane:

Reading the user agent stylesheet was intriguing. Maybe next I should compare and contrast those of Chrome and Firefox and see what I find!

  • Do Not Sell My Personal Info

Get The Rundown

  •  ⋅ 
  • Web Dev SEO

How to Change User Agents in Chrome, Edge, Safari & Firefox

SEO professionals can change their browser's user-agent to identify issues with cloaking or audit websites on different devices. Learn the process here.

safari user agent stylesheet

Whether you are an SEO, marketer, or web developer, often you might need to change your browser’s user-agent to test different things.

For example, you’re running a MAC-OS-specific campaign. To find out if your campaign is running properly and not targeting Linux users, changing the user-agent of your browser can help you test.

For web developers, changing user-agents is almost a daily task in order to test how websites behave in different browsers and devices.

What Is a User-Agent?

A user-agent is an HTTP request header string identifying browsers, applications, or operating systems that connect to the server.

Not only browsers have user-agents, but also bots, crawlers such as search engines Googlebot , Google AdSense, etc.

HTTP header user-agent

Here we are going to learn how to change the user-agent of your browser.

The process is called user-agent spoofing .

Yes, when a browser or any client sends a different user-agent HTTP header from what they are and fake it that is called spoofing.

While the term may be alarming, this is not a dangerous activity and will not cause any problems for you. (So feel free to spoof your user-agent as much as you want. 🙂)

How to Change Your User-Agent on Chrome & Edge

Since Microsoft Edge is now using Chromium , the settings for both Chrome and Edge are the same.

1. Right Click Anywhere in Webpage > Inspect

Alternatively, you can use CTR+Shift+I on Windows, Cmd + Opt +J on Mac.

where is google chrome's inspect code

2. Choose More Tools > Network Conditions

Click on the three vertical dots on the upper right corner.

Chrome network conditions

3. Uncheck Select Automatically Checkbox

chrome network conditions

4. Choose One Among the Built-In User-Agents List

Change user agent in Chrome Edge

If the user-agent you want doesn’t exist, you can enter any string you want on the field below the list.

For example, you can enter the following (Googlebot’s user-agent) into the custom field.

This may be useful for SEO professionals to identify if there is a cloaking on the website when the webpage shows different content to Googlebot and another to website visitors.

Alternatively, you can use the Chrome extension User-Agent Switcher and Manager .

That said, I try not to use browser extensions when the browser can actually do the action I want. This is to avoid overloading the browser with tons of add-ons.

Also, extensions have a habit to break websites unexpectedly sometimes.

While you might think the website you visited has an issue, the root cause can be one of the add-ons you’re using.

How to Change User-Agent on Safari

1. go to preferences.

Safari browser preferences

2. Enable Develop Menu Bar

Go to Advanced  and check Show Develop menu in menu bar .

3. Navigate to Develop > User-Agent

Safari's develop menu. User agent

You can again select from a predefined list or enter custom user-agent string by choosing “Other…”

Safari custom user agent setting

How to Change User-Agent in Firefox

In Firefox, it is possible to change user-agents via the browser’s built-in settings.

However, it is not as user-friendly as on Chrome or Safari.

It is a real pain to use the browser’s built-in feature.

Instead, we will use a Firefox add-on called User-Agent Switcher .

After installing the add-on, you will see an icon in the upper right corner.

You can select one of the predefined user-agents or enter a custom user-agent by clicking on the pen icon below.

Firefox User-Agent Switcher extension

Another extension you can use is User-Agent Switcher and Manager .

Firefox User-Agent Switcher and Manager extension

The user-agents are easy to spoof and anyone can use these easy tricks to alter it.

This feature is useful for testing web apps against various devices especially when one has different HTML for mobile or tablet devices.

One doesn’t need to have many physical devices to be able to test.

This feature is useful for SEO professionals, for example, to identify issues with cloaking which is against Google’s Webmaster Guidelines or auditing websites which has different look depending on the device.

More Resources:

  • Crawl-First SEO: A 12-Step Guide to Follow Before Crawling
  • New Bingbot User Agents Will Streamline SEO
  • 7 Essential SEO Browser Extensions & Plugins

Image Credits

All screenshots taken by author, May 2020

What is a user agent?

User agent is a HTTP request header string identifying browser, application, operating system which connects to the server. Not only browsers have user agent but also bots, search engines crawlers such as Googlebot, Google Adsense etc. which are not browsers.

What is user-agent spoofing?

When browser or any client sends different user-agent HTTP header from what they are and fakes it that is called spoofing .

I am dedicated to ensuring the smooth and uninterrupted operation of Search Engine Journal. As the Director of Technology, I ...

Subscribe To Our Newsletter.

Conquer your day with daily search marketing news.

User Agent Style Sheets: Basics and Samples

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development .

CSS manages the default formatting of documents through the concept of user agent style sheets , a cornerstone of the cascade . This means that a web browser doesn’t just present a line of text when it’s fed with an HTML document that has no styling information, but instead serves it using minimal formatting.

Figure: HTML document with Firefox default styling.

Specification

CSS 1 introduces the idea by stating that “each User Agent (UA, often a ‘web browser’ or ‘web client’) will have a default style sheet that presents documents in a reasonable—but arguably mundane—manner.” CSS 2 says that “conforming user agents must apply a default style sheet (or behave as if they did)” and that “a user agent’s default style sheet should present the elements of the document language in ways that satisfy general presentation expectations for the document language.” CSS 3 is of the same mind .

Since the CSS specifications leave it up to implementations whether to use a “real” style sheet for default display or not, it’s not surprising that you don’t find a default style sheet in every browser’s installation folder. Unlike Microsoft’s Internet Explorer as well as Opera , however, Gecko browsers like Firefox and Netscape Navigator (“html.css”) but also Konqueror make it rather simple to comprehend their default styles.

User Agent Style Sheets

The following is a [maintained] list of default style sheets I’ve compiled over recent years. Due to the fact that Firebird, Firefox, and Co. are all based on the same layout engine, their style sheets are similar, if not identical.

  • Chrome (January 26, 2011)
  • Chrome (July 17, 2013)
  • Chrome (September 2, 2015)
  • Chrome (February 11, 2019)
  • Chrome (August 26, 2021)
  • Chrome (May 3, 2023)
  • Chrome (latest)
  • Firebird 0.7
  • Firefox 0.8
  • Firefox 0.9
  • Firefox 1.5.0.4
  • Firefox 2.0.0.6
  • Firefox 2.0.0.12
  • Firefox 3.0b3
  • Firefox 3.0.1
  • Firefox 3.0.8
  • Firefox 3.6.13
  • Firefox 3.6.3
  • Firefox (March 31, 2019)
  • Firefox (February 3, 2021)
  • Firefox (March 28, 2023)
  • Firefox (January 17, 2024)
  • Firefox (latest)
  • Flock 0.9.0.2
  • Flock 1.2.4
  • Flock 1.2.7
  • Internet Explorer 6
  • Internet Explorer 7
  • Internet Explorer 8
  • Internet Explorer 9
  • Konqueror 3.2.0
  • Mozilla 1.0.1
  • Mozilla 1.5
  • Navigator 6.1
  • Navigator 7.1
  • Navigator 8.1
  • Navigator 9.0b3
  • Opera 10.51
  • Safari 3.0.4
  • Safari 3.1.2
  • Safari (January 29, 2013)
  • Safari (May 21, 2015)
  • Safari (November 5, 2018)
  • Safari (April 3, 2019)
  • Safari (April 1, 2021)
  • Safari (May 27, 2022)
  • Safari (latest)
  • SeaMonkey 1.1.2

For comparison, note a 1998 “base style sheet,” as well as the default style sheets proposed by the W3C in the specifications of CSS 1 , CSS 2 , CSS 2.1 , and CSS 2.2 :

  • CSS 2.1
  • CSS 2.2

User Agent and Reset Style Sheets

The examples aim to provide some insight into user agent style sheets. Knowledge of user agent style sheets should help get a better understanding of CSS as well as any display “phenomena.”

However, I encourage to use this knowledge for other things than building more or larger “reset” style sheets . Assuming use of additional style sheets other than just a reset, reset style sheets are typically unnecessary. From my experience , the only occasionally helpful and then quite memorable reset is * { margin: 0; padding: 0; } . Reset style sheets are going to be handled in other posts though, revealing why they’re, well, bad . [Still in doubt? Try this sanity check: Use your preferred reset, then temporarily remove it and see what happens .]

Jens Oliver Meiert, on September 30, 2021.

Comments (Closed)

Thanks for sharing this. You said it well, it gives us better understanding of css and how/what to do with our own style sheets.

For Safari/Webkit stylesheets cannot be found in the installation (propably compiled into some library), but they are on the web source tracking system with their history

html4.css quirks.css

Thanks Martin—I updated the post!

This is a very nice piece, Jens. I’m glad someone can give this little study authoritatively because the recent craze over reset stylesheets, and inherently the notion that browser defaults are bad, is often very misguided: If you are going to respecify everything, there is no need for the extra rule for every element; if you aren’t, you’re far better off with the user/developer’s consideration than nothing.

I absolutely don’t agree with you. The reset with * {margin: 0; padding: 0; } is the worst method of resetting the browser’s default styles. Especially when working on form elements it make a lot of problems.

The better reset: Reset Reloaded

Kind regards Daniel

Interesting read… I just assumed that if the link to the CSS was broken the browsers would default to plain HTML formatting. However, it certainly makes more sense to have a default css file.

Thanks for this. It’s really useful info! Especially for CSS beginners like me.

Interesting read, but I am not able to find out where a textarea’s default font (courier) comes from. Anybody?

Thanks for an excellent writeup. So what do you start with as a default then? I’ve been using a reset of sorts, and am finding some of those defining things I never use in my markup, so that seems redundant to me. How to be sure borders, margins don’t create problems without resetting them or defining them to be the same despite whatever UA styling could derail a layout?

I would love to know how to pry into IE’s resource files to view the actual UA CSS the way I can with Gecko and Webkit. Does anyone have a guide on how to do that? The googles has failed me.

  • Next: Qualities of Design: It Works and It’s Durable
  • Previous: Cost of Solution vs. Cost of Problem

Cover: The Web Development Glossary 3K.

  • CSS Tutorial
  • CSS Exercises
  • CSS Interview Questions
  • CSS Selectors
  • CSS Properties
  • CSS Functions
  • CSS Examples
  • CSS Cheat Sheet
  • CSS Templates
  • CSS Frameworks
  • CSS Formatter

What is a User Agent Stylesheet ?

  • What does StyleSheet.create do and why is it useful ?
  • What is styling text input caret ?
  • What is the use of CSS ruleset ?
  • What is shadow root and how to use it ?
  • CSSStyleSheet cssRules Property
  • Web Design Layouts | Types, Elements and Uses
  • CSS Cheat Sheet - A Basic Guide to CSS
  • What is the purpose of the HTML "aria-*" attributes?
  • Types of CSS (Cascading Style Sheet)
  • Applying Styles in MS Word
  • Web StyleElement API | StyleElement media property
  • What are the different utility classes in Materialize CSS ?
  • What is Material UI ?
  • Which property is used to set the height of a box in CSS ?
  • Semantic-UI Form HTML Select Content
  • HTML | DOM Style listStyle Property
  • HTML | DOM Style fontStyle Property
  • Semantic-UI Loader Types
  • How to use CSS to separate content & design ?

A user agent stylesheet is a pre-defined set of CSS rules that are built into a web browser and applied to web pages automatically. The purpose of the user agent stylesheet is to provide a consistent and standardized visual rendering of HTML elements across different web pages and websites. The rules in the user agent stylesheet define how HTML elements should be displayed by default, including things like font size, color, spacing, and alignment.

  • User-agent stylesheets are provided by the browser and are applied before any styles defined in the web page itself.
  • User-agent stylesheets are used to ensure a consistent and predictable visual appearance for HTML elements across different websites and web pages.
  • User-agent stylesheets can vary between different browsers and versions of browsers, and can also be influenced by the operating system being used.
  • User-agent stylesheets typically define basic styles for HTML elements, such as font size, line height, margins, and padding.
  • Web developers can override the styles defined by the user agent stylesheet by defining their own styles in a stylesheet included with the web page, or by using inline styles.
  • The specific styles applied by the user agent stylesheet can be inspected and modified using the developer tools provided by most web browsers

How does the user agent stylesheet work?

  • A user agent stylesheet is a set of predefined style rules that web browsers use to render HTML documents. These style rules are built into the browser and apply to all HTML documents that are loaded in the browser.
  • When a web page is loaded in a browser, the browser first parses the HTML and creates a Document Object Model (DOM) tree. The browser then applies the user agent stylesheet to the DOM tree to determine how the HTML elements should be displayed on the screen

The syntax may vary depending on the browser being used. The syntax used in the current version of chrome is as follows:

Example 1: In this example, we will give you a basic understanding that what an actual user-agent stylesheet is:

safari user agent stylesheet

What is a user agent stylesheet?

In this example, we have a very basic HTML document with just an h1 element inside the body section. We have not defined any styles for the h1 element in our own stylesheet. When we load this page in a web browser and inspect the h1 element with the developer tools, we will see that it has some default styles applied to it. These styles are coming from the user agent stylesheet. The specific styles that are applied will depend on the browser that we are using. For example, in Google Chrome, the h1 element will have a font size of 2em, a margin-top of 0.67em, and a margin-bottom of 0.67em, among other styles.

Example 2: Another example to get more clarity about the user-agent stylesheet:-

What is a user agent stylesheet?

In this example, we have an HTML document with a head section that includes a style tag. Inside the style tag, we define some basic styles for the body and h1 elements. We set the margin and padding of the body element to 0 and text-align as the center, and we set the color of the h1 element to green. We have also added a p element to the body section. We have not defined any styles for the p element in our own stylesheet. When we load this page in a web browser and inspect the p element with the developer tools, we will see that it has some default styles applied to it. These styles are coming from the user agent stylesheet.

Please Login to comment...

Similar reads.

  • CSS-Questions
  • Web Technologies

Improve your Coding Skills with Practice

 alt=

What kind of Experience do you want to share?

-.- --. .-. --..

Safari custom user agent css overrides using webfonts.

I like to use better monospace fonts as default fonts in browsers. In Chrome and Firefox, this is pretty straight forward—go to Preferences, and you’ll see a menu to change the default fonts. This is a bit harder on Safari; its Intelligent Tracking Protection disables loading all local fonts by default.

A very simple way to circumvent this restriction is by using a webfont. The simplest option is to use an @import statement and load a webfont from, say, Google fonts or some other service (your own web server too!).

Example stylesheet:

And use the Preferences > Advanced > Style sheet, and load this file from disk. This trick, and a little bit of default zoom makes the IETF spec docs much much better to read.

Preferences pane in Safari to upload the default stylesheet override

Sample screenshot of one of the IETF spec docs I’m reading:

Cookies: HTTP State Management Mechanism                     draft-ietf-httpbis-rfc6265bis-05 sample screenshot

This is not perfect, but goes a long way without needing to install extra plugins ala Stylebot or Cascadea for the basic usecase.

  • Stephanie Eckles
  • Oct 6, 2021

A Guide To CSS Debugging

  • 24 min read
  • CSS , Tools , Techniques , Workflow
  • Share on Twitter ,  LinkedIn

About The Author

Stephanie Eckles is a front-end focused software engineer. She’s the author of ModernCSS.dev which provides modern solutions to old CSS problems. She is the … More about Stephanie ↬

Email Newsletter

Weekly tips on front-end & UX . Trusted by 200,000+ folks.

We’ve all been there, at the end of completing CSS for a layout and — what’s that? Ah! An extra scrollbar! Or maybe an element is an unexpected color. And on some browsers, that new feature just doesn’t seem to be working.

Debugging — regardless of the language — is never a favorite task. CSS, like other languages, becomes easier to debug when you take time to learn a bit about its quirks. It also helps to become familiar with tools to help you both debug and prevent creating bugs in the first place.

Common Causes Of CSS Bugs

The first step in debugging is taking a step back and identifying the primary cause of the issue. In my experience, CSS layout issues often fall out of one of the following categories:

  • Overflow of content from its parent resulting in extra or unexpected scrollbars and content being pushed out of the regular viewport area.
  • Inheriting browser inconsistencies leading to mixed results across browsers and devices.
  • Unexpected inheritance from the cascade where multiple styles override one another, which may cause alignment and spacing issues, among other things.
  • CSS resiliency failures from DOM changes , including when child elements have gained wrapping divs or additional elements are unexpectedly added.

We’ll review debugging for each category by learning common culprits for these issues and see how to use dev tools and other methods to pinpoint the offending styles. Of course, we’ll discuss possible resolutions to these bugs as well.

General Debugging Tips

When something has gone wrong in your CSS, you can begin by using your favorite browser’s built-in DevTools to:

  • toggle off rules one at a time
  • toggle all rules off and bring them back one at a time
  • remove or relocate elements

Due to the global nature of CSS, the problematic style for an element may be located in its parent, grandparent, or even further back up the tree. DevTools will display the rules most applicable to the element based on specificity at the top of the pane and then provide a stack trace of the cascade and inherited styles.

You can also try to isolate the specific layout issue by either placing only that part into a local file or using an online editor like CodePen or CodeSandbox. Be aware that using those editors may insert extra opinions that your local environment doesn’t have. For example, CodePen defaults to using the Normalize reset, which may introduce new problems if you’re not already using it. Toggle off any settings that don’t work for your project. Then, you can use DevTools to copy in the relevant HTML.

After that, another handy feature is to open the context menu (“right click” or equivalent) for your element and then select “Copy > Copy styles” from the menu. Repeat for each nested element as needed.

If the problem no longer exists after isolating it, it’s likely that an ancestor element is leading to the difficulties. You may choose to isolate starting from higher up the DOM tree, or you’ll likely need to inspect inheritance more closely. We’ll talk about inheritance a bit more later on.

If you can resolve the problem in your isolated component, you can bring the updated styles back into your main project stylesheet.

Chrome, Edge, Firefox, and Safari also have a way to track the changes you’ve made and save them to make it easier for you to copy over any updates.

  • Chrome/Edge Use the “kebab” more menu to select “More Tools > Changes” to open that panel. Additionally, you can persist your changes by using the local overrides feature.
  • Firefox The “Changes” panel should be already available by default and next to the “Computed” tab.
  • Safari Also offers the “Changes” panel by default, located in the same tab bar as the “Styles”.

Recommended Reading : “ Examine And Edit CSS ,” Firefox Developer Tools, MDN Web Docs

More ideas, tips, and tools will be discussed next.

Debugging Overflow

Overflow is usually one of the most apparent issues and can be pretty frustrating. It’s not always evident at a glance which element is causing overflow, and it can be tedious to try to comb through elements using dev tools inspectors.

“CSS is designed to not lose content, to not cause harm. In order to not cause harm, we show what overflows by default.” — Miriam Suzanne, Why Is CSS So Weird? (video)

Thinking about it another way, the infamous meme of “CSS is Awesome” is, in fact, correct and intentional behavior if the base box was purposely set smaller than the size needed to accommodate that text. (If you’re interested, the original creator, Steven Frank, stopped by CSS Tricks to explain the origin ).

A tried and true method to begin figuring out which element is responsible for overflow is to add the following CSS:

Why outline instead of border ? Because it will not add to the element’s computed DOM size. Adding borders will change element appearances if they’re already using a border and may falsely cause additional overflow issues.

The intent of using outline is to reveal element boundaries and visualize how elements are nested. For example, if overflow is causing unexpected scrollbars, an outline can help point out which element is pushing out of the viewport.

In addition to this manual method, Firefox reveals scrolling elements and specify which elements have children causing overflow, as seen in this screenshot.

Common Causes Of Overflow

Typically when we’re concerned about overflow problems, it’s from a mismatch of width allowances between a parent element and its children.

One of the first things to check is if an element has set an absolute width without a responsive method to allow it to fully resize downwards. For example, a 600px box will trigger overflow on viewports narrower than 600px . Instead, you may be able to adjust to add in a max-width: 100% so that the element will also responsively resize:

An example of when this would not be a complete solution is when the element triggering overflow also has margins that increase its computed size within its parent. In the following example, the paragraph is still forced outside the main element due to its horizontal margin.

Fortunately, we can account for that margin by using the CSS math function calc to subtract the total area used by the horizontal margins:

Now, all that said, it’s not often we should be supplying absolute widths for elements. More often, it would be best to define only max-width if you need to control an element’s size. Again, this reduces bugs related to responsively sizing it. In fact, we can completely resolve the issues for our example by removing both the width and max-width values, which allows the paragraph’s default behavior to let it appropriately adjust within the available space of the main parent.

However, there are situations when the solutions we looked at make sense, such as applying max-width: 100% to create responsive images. And for some flexbox-based layout methods, you’ll also see width or flex-basis used with calc for the reason of accounting for margin.

Another common trigger for overflow has to do with one of the recognized mistakes in the design of CSS by the CSS Working Group. Number 6, in fact, which is that box-sizing should have defaulted to border-box instead of content-box .

All browsers currently ship with the legacy decision to set the element box model to use content-box , which means that an element’s border and padding are added to the computation of the element’s size. So, if you set absolute dimensions for width and/or height, you need to account for the extra space for any added border and padding.

To simplify this behavior, a best practice is to ensure your styles include resetting all elements to use border-box . This reduces the chance of overflow in many instances and makes the CSS layout more predictable due to removing complications from including borders and padding in the final element dimensions.

Other causes of overflow fit a little better into the categories of bugs we’ll review next.

Debugging Browser Inconsistencies

While we’re living in a golden age of near-parity between browsers for critical features, there are still some legacy choices that can interfere. Every browser ships with a default stylesheet called user-agent (UA) styles.

Here’s an example of how those styles appear in the primary browsers:

These happen to be highlighting one of those defaults that can be another common trigger for overflow. The body element has margin attached in every browser, with the top ones as commented:

You may be familiar with the concept of a CSS reset. These have evolved over the years as both CSS and browser support have improved but resetting the body back to margin: 0 is usually a feature.

If you use CodePen, the default reset is Normalize.css , authored by Nicolas Gallagher and initially released in 2012. It can be found in many, many projects and is quite an opinionated reset. However, it’s worth noting that it has not been updated since November 2018.

Note : Another timely note here is that Internet Explorer will reach end of life officially on June 15, 2022 ). This means that many features are needed not only in resets but within our stylesheets, in general, will no longer be required!

CSS has been improving rapidly in the last couple of years, and of course, browsers are continually modernizing. An alternative reset that fits better with more modern projects is Andy Bell’s Modern CSS Reset . This reset is enough to smooth out the handful of things common to most projects that are still inconsistent cross-browser, while not being overly opinionated. It also considers a few basic accessibility features. Andy explains each rule of the reset, and I’ve found it to be a solid starting point.

Let’s look at a few modern browser inconsistencies that can cause layout bugs.

Overflow from Viewport Units and Scrollbars

Without removing the margin on the body , our simple example from the overflow section triggers overflow. That’s because we used 100vw as one of the possible values for the width of the main element. Since it’s not subtracting the margin , it experiences overflow due to 100vw being 16px wider than the available space between the body’s margins.

Depending on the browser and operating system, you may also experience browser scrollbar widths upsetting the 100vw calculation as well. Currently, the fix is to update to 100% if you can. Soon we’ll also have the scrollbar-gutter property to help us account for scrollbar widths. This property is being extended in CSS Overflow Module Level 4 and has gained support in Chromium browsers from version 94. Bramus has an excellent breakdown of scrollbar-gutter of how it will work and what it will help solve. The summary of the solution is to make sure you leave room for scrollbars while achieving an even gap appearance on both sides of the content by adding: overflow: auto; scrollbar-gutter: stable both-edges; .

Note : If you aren’t sure your content requires scrollbars but know that it may need them sometimes, be sure to use the auto value for overflow. This tells the browser only to add them when the element needs them to accommodate the content. That said, users can customize their preferences to always show scrollbars, which is why the scrollbar-gutter property will be extra valuable!

It can also be problematic to set min-height: 100vh on the body without removing the margin first. There are other issues with 100vh specifically, and those have to do with how different devices and browser combinations have implemented the calculation for 100vh .

While 100vh appears to work on most desktop contexts, you may have experienced the frustration of having what seems like unexpected behavior, particularly when tested on iOS in WebKit browsers. Within a fixed layout set to 100vh , the bottom part of the website content is stuck behind the browser chrome, making it inaccessible when scrolling is prevented. For example, in a fixed height mobile menu or a single page app or game trying to fill no more than the available viewport height.

Matt Smith went seeking a solution and discovered in some scenarios the 100vh issue can be resolved by using the following combination:

This solution is imperfect, and I suggest testing on an actual device to ensure it works for your layout.

Jen Simmons also shared a technique (timestamp: 13m) that is available in Safari 15 to adjust this behavior with the help of CSS environment variables. The safe-area-inset-bottom will be 0 when not applicable and dynamically adjust when it does apply. This environment variable can be used for padding, margin, and within calc as shown:

The CSS Working Group has an improved solution in draft to address this category of issues, which will be a set of new units for “ Large, Small, and Dynamic Viewport Sizes .” These are intended to better correspond with the dynamic behavior of the changing browser chrome as is the cause of the WebKit troubles.

Here’s a summary of the current draft (note that these may still have some changes before they are stable in browsers):

  • Small viewport-percentage units (svh, svb, svw, svi) Equivalent to the remaining viewport space when all dynamic UI elements are expanded (ex. URL bar and virtual keyboard), and will not change its value even as the browser chrome changes.
  • Large viewport-percentage units (lvh, lvb, lvw, lvi) The size opposite of small, calculated to assume all dynamic UI elements are retracted.
  • Dynamic viewport-percentage units (dvh, dvb, dvw, dvi) The unstable value of the visible viewport space that changes along with dynamic browser chrome changes.

Typography Element Properties

UA styles also include default styles for common typography elements such as headings, paragraphs, and lists. Typically, CSS resets or frameworks will have already addressed these things. And, while you may not consider differences in these properties to be “bugs,” it’s helpful to understand that they are not the same defaults cross-browser since these styles are some of the most impactful.

The main note here is that if you notice an inconsistency, you may want to select your preferred value (such as a particular font-size for an h1 ) and add it to your stylesheet.

Differences In Browser Feature Support

Browser differences in feature support wins as the most frustrating category, stretching from modern browsers back to the beginning of CSS. Quite simply, not all browsers support all CSS properties equally.

As mentioned earlier, we are in a time of near feature parity but also in a time of rapid development and growth of the CSS language. So the issues we have due to feature support are shrinking, but at the same time, we’re in a holding pattern as we wait for the new things to reach general availability.

Fortunately, we have several tools available to help research feature support during development and to help address inconsistencies.

The one you may already know about is caniuse , which lists support tables for both CSS and JavaScript features. The caveat to be aware of here is that the browser usage data is based on Statcounter , a sampling of 2 million websites. The percentages, therefore, may not match your audience and should only be one data point in trying to determine whether it’s “safe” to use a particular feature for your project.

Another helpful tool is the VSCode extension webhint , which is also powering part of the Issues panel in Edge. Webhint alerts you about features that may have lower browser support to help you be aware during development. You can configure what browsers are considered by including a browserslist in your package.

Knowing about feature support during development helps you make an informed solution. But sometimes, it’s not about whether a feature is strictly supported but whether or not the property has undergone syntax changes. For example, sometimes properties are released with “vendor prefixes.” You’ve likely seen these — ones that begin with -webkit or -moz.

Usually, the stable version of the property does not continue to have a prefix, but it’s best to include the prefixed version for the broadest support. Fortunately, you can automate this step instead of doing it manually with the popular autoprefixer package. In addition, there is support for including it in many build processes, such as postCSS (the method I use). Like webhint, it looks at your browserlist to determine what level of support to provide prefixed properties.

Beyond these tools, each browser’s dev tools have a method of signifying when that browser doesn’t support a property. Chromium, Safari, and Firefox show a yellow warning triangle alongside some other styling and a hover-triggered property to denote an unsupported property.

Reviewing how to handle a lack of support for a feature is a bit beyond the scope of this article. And, providing fallbacks if needed or setting up solutions as progressive enhancements is going to be unique. That’s why setting yourself up with tools to help check support during development is so important. Then, you can create a solution that fits the level of support you need instead of having a complete solution that you then have to debug and define a fallback for once you get bug reports.

Unexpected Cascading Layout Inheritance

Ok, so you feel you’re using well-supported CSS features. And you’ve just added a new section to your site, and you feel pretty confident about the CSS. But when you go to look at it in the browser, things seem incorrect.

Particularly when using a framework or design system and then also writing custom CSS, we can encounter bugs related to the cascade and inheritance. Something that works in isolation may not work when placed within a screen layout.

Fortunately, all browser dev tools allow tracing the cascade. By reviewing the Styles panel, we can see what rules are overriding our styles. Or, we can locate a parent that is adding a layout method we weren’t expecting for our child component.

This simple example shows that the rule for main * is “winning” the cascade for applying color to the paragraph. Dev tools manipulate the order in the Styles panel to show the most applicable styles on top. Then, we can see that the color property for just p is crossed-out as an extra indicator that that rule definition is not applied.

Let’s take a quick step back to CSS basics on the cascade. For this example, some of you may have realized that main * has equal specificity to p . But the other very critical part of the cascade is the order of rules, and here is the order from the stylesheet for the example:

If we want to make sure the rule for just p “wins,” then we either need to make sure it follows the main rule or increase its specificity.

This basic feature of CSS is extremely powerful but can be perceived as a “bug” if you aren’t as familiar with how it works. And it can certainly be frustrating if you are tasked with deploying a new feature on a legacy codebase or required to use a framework where it’s more challenging to get around inherited specificity.

Solving issues due to the cascade often doesn’t have an easy answer. It’s worth the time to step back from the immediate problem and examine the layers of styles coming together to identify the best place to make a change. Recognize that an !important could cause you further issues related to specificity down the line, so try out reordering properties if possible first. Or, you may want to switch to setting up “components,” which provide a layer of scoping for styles and encourage being more intentional about inheritance.

Speaking of layers — speeding through the spec process is another new feature that was designed specifically to assist in orchestrating the cascade and alleviating clashes. At present, the Cascade Layers spec (@layer) has gained experimental support in all the top browsers. For more info on this upcoming feature, check out the excellent overview on CSS layers by Bramus .

Note : Please make sure to check the resources at the end of this article for a few links related to checking CSS specificity.

CSS Resiliency Failures From DOM Changes

Sometimes, a carefully crafted CSS solution stops working. In my experience, that often happens due to the underlying DOM changing. When we add CSS based on the current DOM, our solution isn’t resilient to change.

For example, if we create a grid layout rule for a list defined as .grid li , and then the DOM structure changes to be a set of article elements, the CSS will break.

Or, if we set up a series of icons that fit perfectly within the original space, but then the client needs to add an icon, and it causes overflow.

These examples really show why CSS is a valuable skill. If you can write scalable, DOM-independent CSS, your solutions will scale, and you will reduce the likelihood of this category of bugs.

Similar to creating an API in another programming language, it’s a worthwhile endeavor to consider how your CSS rules will be used beyond the current problem you’re solving. “

Debugging this category usually means tracing back to the original rules to see if they can be extended to work for the updated context. Again, you can use dev tools to find the applied rules and even follow the reference link to go to the source.

Note : For more tips on how to handle this category with specific things to consider, review my article on future-proofing CSS styles .

Layout Swaps To Help Avoid CSS Bugs

Let’s look at a few specific examples that may cause layout bugs and how to address them.

Layout Spacing

Once flexbox was introduced, many grid layout solutions were released that all had some math to compute the width of the flex children. In addition, that width had to be aware of the addition of margin to add space between the children.

Good News : The gap property for flexbox is now supported in all evergreen browsers!

CSS grid also supports the gap property. The advantage of gap over margin is that it will always only apply between elements, regardless of orientation. So, no more funky business of trying to attach margin to the “correct” side or having to use negative margin on the parent to counteract nested margin.

Unlike margin , the use of gap is less likely to cause overflow since it never applies to the outer edge of the elements. However, you may still experience overflow if the children cannot resize to a narrower width.

Handling Element Widths

If either your flex or grid children are causing overflow, here are two methods you may try as upgrades.

For flex, ensure you use flex-basis instead of width and that the flex-shrink value is set to 1 . These properties will ensure that the element is allowed to be reduced in size.

For grid, a method I often use to achieve auto-wrapping behavior for grid children is the following:

But, this prevents elements shrinking below that minimum width of 30ch . So, instead, we can update to this solution that keeps our minimum on larger viewports/within larger parents while still allowing child elements to shrink within narrower spaces:

I often find CSS functions very handy in these sorts of scenarios. If you’re unfamiliar, you may enjoy my article on practical uses of CSS functions .

Outside of a grid or flex context, we can achieve a similar behavior for elements to prevent setting an absolute width. We discussed in the overflow section how absolutes could often cause problems. But, there are, of course, times when we do want to provide some width parameters. Once again, my preferred method for setting a flexible width uses the CSS function of min() . In this example, it is a bit of a shorthand for setting both width and max-width at once. The min() function will use the smaller computed value, which dynamically changes as the element’s context changes:

The min() function accepts more than two values, so you could even add a percentage value here as well. Then, your container would be responsive not just to the viewport but when nested in other containers as well, reducing overflow bugs even further—and achieving our mission of creating scalable, DOM-independent styles!

Review the use of min() as a container style as well as to make grid children more flexible in this CodePen: min() and CSS Grid for responsive containers (codepen.io)

Cumulative Layout Shift

A more recent hot topic in site performance and related metrics is Cumulative Layout Shift (CLS) . This is the Google Lighthouse score for how much elements shift or jump during page load. Some offenders are pretty obvious, such as ads and popup banners. Those things use motion and are typically late or purposely delayed in loading.

Now, before you go attacking the problem, make sure there is one. Chrome and Edge include the “Lighthouse” panel in dev tools which you can use to run a report for both desktop and mobile versions of your site. If CLS is not a problem, that score will be less than 0.1 and be displayed with a green indicator.

Two other things that may affect your site are images and custom fonts.

Fairly recently, all browsers have begun to reserve space for images if they include width and height attributes. Those attributes provide the two necessary pieces of information for the browser to calculate the image’s aspect ratio and hold that space within the page layout.

However, due to responsive design, many of us are used to stripping those attributes assuming that CSS will take over. As Jen Simmons explains , it’s time to add those back in. In addition, you may need to tweak your responsive image CSS slightly to include the following somewhat more specific rule, which will allow the image to respond to narrower contexts without losing its aspect ratio:

As for custom fonts, the issue can come in here when the custom font and the designated system fallback font have a significant mismatch. In years past, we’d call it FLOUT (flash of unstyled text). This “flash” is from the delay in time between the initial page load and the custom font loading.

In the example video from my own site that has this problem, I’ve used the Network Conditions panel in Edge to load the site with “Network throttling” set to “Slow 3G.”

In my case, the actual CLS score doesn’t indicate the problem is severe enough to stress about resolving. However, if the font loading delay causes lots of elements to shift, that’s when it is worth looking into ways to alleviate the shifting problem.

Sometimes you can select a fallback system font that better matches the custom font so that the relative size is a closer match. Or, you can reduce the effect by setting a minimum size on the parent elements or adjusting other layout attributes so that it doesn’t cause a significant shift when the font loads.

Simon Hearne did a deep dive into what causes layout shifts due to fonts as well if you’d like to learn more about the problem, especially if you’re working on a more text-heavy site where the impact on CLS is more significant. They conclude that the ultimate solution to strictly address the layout shift is to use font-display: optional but concede that this is not optimal from a design perspective. Simon provides more solutions to help you select the right path for your site, including a handy CodePen to help you test fallbacks. Google also provides a resource describing preloading fonts .

Resources For Debugging CSS

We covered some frequent causes of CSS bugs and how to address them. Here are more resources that can help you with debugging CSS:

  • Ahmad Shadeed wrote an ebook (paid) called Debugging CSS
  • MDN has a dedicated resource on debugging CSS , which covers more about using dev tools
  • Additionally, you may find the MDN article on handling common HTML and CSS problems useful
  • Worth another mention is Miriam Suzanne’s video: Why is CSS So Weird?
  • To check on and better understand CSS specificity, try out this tool from Kitty Giraudel called “ Selectors Explained “

Additionally, outside of the popular browser’s dev tools, you may find these two alternates helpful due to their extra tools and features:

  • Polypane (paid) is a browser that shows you multiple views of your site to test responsive design but also has additional features that can help you catch bugs early.
  • VisBug is a Chromium extension that gives you extra info about elements, which can also help pinpoint issues.

Smashing Newsletter

Tips on front-end & UX, delivered weekly in your inbox. Just the things you can actually use.

Front-End & UX Workshops, Online

With practical takeaways, live sessions, video recordings and a friendly Q&A.

TypeScript in 50 Lessons

Everything TypeScript, with code walkthroughs and examples. And other printed books.

Blog for seasoned and aspiring software developers alike.

Tim

Unveiling the Magic of User-Agent Stylesheets in Web Development

Unveiling the Magic of User-Agent Stylesheets in Web Development

In the vast and dynamic realm of web development, where styles and layouts shape the digital landscape, user-agent stylesheets play a pivotal yet often overlooked role. These mysterious entities wield their influence over the appearance of web pages, contributing to the overall user experience. In this comprehensive exploration, we delve into the intricacies of user-agent stylesheets, uncovering their purpose, impact, and ways developers can navigate their effects.

What Are User-Agent Stylesheets?

User-agent stylesheets are predefined styles applied by web browsers to HTML documents based on the user-agent string. The user-agent string is a snippet of information transmitted by the browser to identify itself to web servers. It typically includes details about the browser, version, and the operating system.

When a browser renders a web page, it employs a default set of styles known as user-agent styles. These styles provide a baseline appearance for HTML elements, ensuring a consistent presentation across different websites. User-agent styles help create a unified browsing experience for users, regardless of the site they visit.

The Influence of User-Agent Stylesheets

User-agent stylesheets have a significant impact on the visual representation of web content. They define default styling for various HTML elements, including headings, paragraphs, lists, links, and more. Developers often encounter situations where the default styles set by user-agent stylesheets clash with their intended design, leading to the need for additional styling adjustments.

One common scenario is the margin and padding applied to elements like <body>, <h1>, and <p>. User-agent styles may introduce default values that developers might find undesirable for achieving a specific layout. Understanding these default styles is crucial for effective web development, as it allows developers to anticipate and override them when necessary.

Navigating User-Agent Stylesheets in Development

To navigate the world of user-agent stylesheets, developers can employ various strategies:

Browser Developer Tools: Modern browsers provide developer tools that allow developers to inspect and analyze the styles applied to individual elements. By inspecting an element, developers can identify the source of its styling, including user-agent styles.

Reset Styles: A common approach to mitigate the influence of user-agent styles is to use a CSS reset or normalize stylesheet. These stylesheets reset or normalize default styles, providing a clean slate for developers to apply their own styling without interference.

Specificity and Importance: Overriding user-agent styles involves using CSS rules with sufficient specificity. By leveraging the !important declaration or increasing the specificity of selectors, developers can ensure that their styles take precedence.

Vendor Prefixes: In addition to user-agent styles, developers often encounter challenges with vendor prefixes for CSS properties. Keeping up with the latest standards and including appropriate prefixes ensures cross-browser compatibility.

In the intricate tapestry of web development, user-agent stylesheets are an essential thread that weaves consistency across diverse browsing experiences. While they impose default styles, developers have the tools and knowledge to navigate and shape the visual identity of their web projects. By understanding user-agent stylesheets and employing effective strategies, developers can create compelling and harmonious web designs that captivate users and elevate the overall browsing experience.

As we continue to innovate and push the boundaries of web development, acknowledging the influence of user-agent stylesheets becomes integral to crafting web experiences that seamlessly adapt to the diverse array of browsers and devices used by today’s users. Embracing this understanding empowers developers to wield their creativity and expertise, ensuring that every digital encounter is a masterpiece of design and functionality.

Best wishes in your coding journey!

10 Jan 2024

  • web development

Accessible Font Sizing, Explained

Avatar of Andrés Galante

The Web Content Accessibility Guidelines (WCAG), an organization that defines standards for web content accessibility, does not specify a minimum font size for the web.

But we know there’s such a thing as text that is too small to be legible, just as text that can be too large to consume. So, how can we make sure our font sizes are accessible? What sort of best practices can we rely on to make for an accessible reading experience?

The answer: it’s not up to us. It Depends™. We’ll get into some specific a bit later but, for now, let’s explore the WCAG requirements for fonts.

Sizing, contrast, and 300 alphabets

First, resizing text .  We want to provide users with low vision a way to choose how fonts are displayed. Not in a crazy way. More like the ability to increase the size by 200% while maintaining readability and avoiding content collisions and overlaps.

Secondly, there’s contrast . This is why I said “it depends” on what makes an accessible font size. Text has to follow a contrast ratio of at least 4.5:1, with the exception of a large-scale text that should have a contrast ratio of at least 3:1. You can use tools like WebAIM’s Contrast Checker to ensure your text meets the guidelines. Stacy Arrelano’s deep dive on color contrast provides an excellent explanation of how contrast ratios are calculated.

There are around 300 alphabets in the world. Some characters are simple and readable in smaller sizes, others are incredibly complex and would lose vital details at the same size. That’s why specs cannot define a font size that meets the specification for contrast ratios.

And when we talk about “text” and “large text” sizes, we’re referring to what the spec calls “the minimum large print size used for those languages and the next larger standard large print size.” To meet AAA criteria using Roman text, for example, “large” is 18 points. Since we live in a world with different screen densities, specs measure sizes in points, not pixels, and in some displays, 18pt is equal to 24px. For other fonts, like CJK (Chinese, Japanese, Korean) or Arabic languages, the actual size in pixel would be different. Here’s the word “Hello” compared next to three other languages:

Hello สวัสดี مرحبا 你好

In short, WCAG specifies contrast instead of size .

safari user agent stylesheet

Here is the good news: a browser’s default styles are accessible and we can leverage them to build an accessible font size strategy. Let’s see how.

Think about proportions, not size

The browser first loads its default styles (also known as the “User Agent stylesheet”), then those cascade to the author’s styles (the ones we define), and they both cascade and get overwritten by the user’s styles.

As Adrian Sandu mentions in his article about rem CSS units :

[…] there is an empirical study run by the people behind the Internet Archive showing that there is a significant amount of users who change their default font size in the browser settings.

We don’t fully control the font-family property, either. The content might be translated, the custom font family might fail to load, or it might even be changed. For example, OpenDyslexic is a typeface created to increase readability for readers with dyslexia. In some situations, we may even explicitly allow switching between a limited set of fonts . 

Therefore, when defining fonts, we have to avoid hindering the ability of a user or a device to change our styles and let go of assumptions: we just don’t know where our content is going to land and we can’t be sure about the exact size, language, or font that’s used to display content.

But there is one thing that we can control: proportions .

By using CSS relative units, we can set our content to be proportional to whatever the environment tells it to be. WCAG recommends using em units to define font size . There are several publications discussing the benefits of using ems and rems and it’s beyond the scope of this article. What I’d say here is to use rems and ems for everything , even for other properties besides font-size (with the exception of borders, where I use pixels).

Avoid setting a base font-size

My recommendation is to avoid setting font-size on the :root , <html> or <body> elements in favor of letting the browser’s default size serve as a baseline from where we can cascade our own styles. Since this default is accessible, the content will also be accessible. The WACAG 2.2 working draft states that:

When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font.

Of course, there is an exception to the rule. When using an intricate, thin, or super short x-height font, for example, you might consider bumping up the font size base to get the correct contrast. Remember that the spec defines contrast, not size:

Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

In the same manner, a user might change the base font size to fit their needs. A person with low vision would want to choose a larger size, while someone with an excellent vision can go smaller to gain real estate on their screens.

It’s all about proportions: we define how much larger or smaller parts of the content should be by leveraging the default base to set the main text size.

What about headings?

Since headings create a document outline that helps screenreaders navigate a document, we aren’t defining type selectors for heading sizes. Heading order is a WCAG criteria : the heading elements should be organized in descending order without skipping a level, meaning that an h4 should come right after an h3 .

Sometimes resetting the font sizing of all headings to 1rem is a good strategy to make the separation of the visual treatment from the meaning mandatory.

How can we work with pixels?

Both rem or em sizing is relative to something else. For example, rem  calculates size relative to the <html>  element, where em is calculated by the sizing of its own element. It can be confusing, particularly since many of us came up working exclusively in pixels.

So, how can we still think in pixels but implement relative units?

More often than not, a typographical hierarchy is designed in pixels. Since we know about user agent stylesheets and that all major browsers have a default font size of 16px , we can set that size for the main text and calculate the rest proportionately with rem units.

Now let’s explore three methods for using relative sizing in CSS by converting those pixels to rem units.

Method 1: The 62.5% rule

In order to seamlessly convert pixels to rem, we can set the root sizing to 62.5% . That means 1rem equals 10px :

Method 2: Using the calc() function

We can also calculate sizes with CSS calc() by dividing the pixel value by the font base we assume most browsers have:

Method 3: Using a “pixel-to-rem” function

Similar to calc() , we can leverage a preprocessor to create a “pixel-to-rem” function. There are implementations of this in many flavors, including this Sass mixin and styled-components polish .

It’s even possible to create a “pixel-to-rem” function with vanilla CSS:

Is it possible to create a "Pixel to rem" function without using a preprocessor? Yes! ✨See it in action! https://t.co/kPfIMxO0vw cc/ @srambach @matthewcarleton #CSS #DontDoIt pic.twitter.com/PKxE7QCWuO — Andrés Galante (@andresgalante) March 3, 2020

Embrace a diverse web!

The bottom line is this: we don’t have control over how content is consumed. Users have personal browser settings, the ability to zoom in and out, and various other ways to customize their reading experience. But we do have best CSS best practices we can use to maintain a good user experience alongside those preferences:

  • Work with proportions instead of explicit sizes.
  • Rely on default browser font sizes instead of setting it on the :root , <html> or <body> .
  • Use rem units to help scale content with a user’s personal preferences.
  • Avoid making assumptions and let the environment decide how your content is being consumed.

Special thanks to Franco Correa for all the help writing this post.

Mixing rem font-styling with px-based layouts and media queries is tricky, they don’t scale together. The text that looked fine at 1rem size inside a 500px-wide box will look way too large, the container didn’t change at all.

In our experience users are more likely to set a default zoom level for their browsers (or just zoom on the page) instead of setting a default don’t-size (which were about 2% of users).

Rems were great workaround when browser zoom behavior wasn’t consistent. They aren’t worth it anymore.

The biggest visual text accessibility wins can found in the guides from WCAG.

Meaningful text with ARIA labels and states shouldn’t be ignored in this discussion as well, unless we’re just talking about visual a11y.

Would you recommend using a rem-based layout then?

I would recommend all-or-none, not mixing absolute and relative values.

Thank you for gathering this info. I am also a proponent of never setting a base font size, deferring to user preferences instead.

To build a bit on some of the advice here, when setting font sizes:

be careful with any sizing based on viewport units ( vw or vh ); avoid changing font size across viewport size media queries; line length matters, so be careful about letting lines of text get too long; until you have a good test process, avoid min() , max() , and clamp() ; be aware that type set in px will be unaffected when users change the font size in the browser settings, so maybe avoid px completely.

I have examples of how these can be problematic in my post Responsive Type and Zoom .

A quick note on OpenDyslexic from a 2013 study with 48 participants (there are other studies that support this):

Use of the OpenDyslexic font did not enhance text readability or reading speed. The study participants strongly preferred Verdana or Helvetica over the OpenDyslexic alternative.

That being said, variable fonts could be helpful to those with dyslexia (so please experiment!).

Can you elaborate on “avoid changing font size across viewport size media queries”?

D, if your type changes size with viewport size changes, when a user zooms the type will not scale consistently if that zoom triggers a media query. See the first link in my comment for examples.

avoid changing font size across viewport size media queries

I increase the root font size on desktop via a media query.

Is this a problem?

I threw that MQ on a pen and maximized my window to 1,920 × 1,080. As I zoomed up to 150% the text got bigger. When I hit 175% the text got smaller than it was at 150% zoom. At 200% zoom the text size matched the 150% zoom text size. To get the text to 200% the size of the original, I had to zoom 250%. So yeah, that is a problem.

I just wrote the same and oversaw your comment. It works for me, and is also recommended here: https://betterwebtype.com/articles/2019/06/16/5-keys-to-accessible-web-typography/

I forgot to mention that you should use em for media query breakpoints. There they always refer to the base font size of the browser, not to font size you might set to the root element, otherwise you could get infinite loops.

What I’ve taken to doing recently is specifying font sizes in both px and rem (assuming a base font-size of 16px ):

This duplication does add a little to CSS file size, but it allows you to design/code in pixels (including an easy reference to what that px size was), quickly convert to rem (perhaps using a pre-processor if you want), and gives a fallback in case a browser doesn’t support rem (admittedly all mainstream browsers do, but I’m always concerned above some lesser used device — especially an AT device — may not).

I like to scale the whole site up on large screens by changing the root font size, which works fine if you use rems and Ems everywhere, including your media queries. Just make sure to not use pixels, but percent: html { font-size: 110%; } This will take the font size of the user into account, so it may be 110% of 16px, or of whatever the user chose.

Hi Andrés, thanks for sharing :)

A small note

By default, iOS will not size relative lengths based on user settings unless you use system fonts that supports dynamic type behavior.

To enable this you can define -apple-system-body as the root font (I use HTML as it has lower specificity than :root)

The Web Witch's Blog

Browser font rendering inconsistencies

22 June 2020

I was working on a project that required me pulling up the developer tools in different browsers against my personal website when I opened up Safari and noticed how drastically different the title of my page was rendering. It was extremely bold in Safari compared to the other browsers.

Much more bold than I expected it to be.

alt: Font rendering in, from top to bottom, Safari. Edge and Firefox

I looked at my stylesheet and saw that I had applied minimal styling to my headings and recall a decision to just let the browser handle the heading styles apart from defining the font-family and font-sizes . So the difference in weight was be caused by the browser.

h1 tags are bold by default but there appears to be extra bold being applied by Safari.

Jason Pamental suggested using font-synthesis: none; but that didn't have any effect in Safari or Firefox (it's not supported in other browsers at the moment.)

Computed Styles #

I started to dissect differences between the user agent style sheet and the Computed Styles tab in the DevTools.

Safari User agent stylesheet:

Safari computed CSS properties

Edge, Chrome and Firefox user agent stylesheet:

Edge, Chrome and Firefox computed CSS properties

In the computed tab, Edge, Chrome and Firefox are all showing font-weight: bold to be computed to a font-weight of 700, whereas Safari's computed font-weight doesn't have a numerical value, it just remains computed as "bold." But this still doesn't explain much.

In fact somewhat ironically, Safari doesn't have font-weight: 700 defined anywhere in stylesheets that I can see in the DevTools but it is rendering h1 s in the 700 font-weight for the typeface Poppins.

Browser fallback behavior #

So now I'm even more baffled and look to the line of code I have to define the font and font-weights I'm using.

<link href="https://fonts.googleapis.com/css?family=Poppins:400,600" rel="stylesheet">

I don't know why, but I'm compelled to delete "600" from the string while in Edge. So I do and suddenly watch as the heading in Edge re-renders at "400".

I add ,700 to the end of this string: Poppins:400,600 . My heading re-renders and now matches Safari. I remove ,700 and it re-renders in the 600 font-weight. I delete 600 again, it re-renders in the 400 font-weight.

I test this in Firefox and see the same results.

Edge, Chrome and Firefox all have a computed font-weight of 700 and if that particular font-weight isn't defined in the line of Google Fonts code, the browser grabs the next highest numerical font-weight that is defined and renders that font-weight as the bold weight. If you delete all font-weights from the Google Font code, you get the thinnest version of the font.

So what happens when I test this in Safari? Absolutely nothing. It doesn't matter if I delete all the font-weights from the font link. Safari's headings remain bold. But then I noticed something interesting as well after deleting the 400,600 from the font code...my nav bar on my website didn't change either in Safari.

So to confirm I was in fact seeing what I was seeing I changed the file on my live site and stripped 400,600 out so all I had was the following:

<link href="https://fonts.googleapis.com/css?family=Poppins" rel="stylesheet">

alt: Font rendering without any weight being defined

And Safari didn't change at all. I still had the CSS for my nav links declaring them at font-weight: 600 and Safari was still pulling that weight despite me not defining it in the font code.

Edge, Chrome and Firefox had all fallen back to the thinnest font available.

So what do I do to render headings consistently across browsers and platforms? #

This almost feels like a loaded question. This problem is almost akin (but a little bit less complex) to rendering HTML Forms consistently across platforms and browsers. The cross-platform problem is a harder one to solve as you can't control how the operating system handles font rendering.

If you don't want the browser to decide how to bold font-weights then I suggest explicitly defining the font-weight with numerical values: 500, 600, etc to avoid Firefox, Edge and Chrome falling back to whatever the highest font-weight defined is.

And a bit of a disclaimer: I've only looked at h1 rendering for this article. I suspect there are many other areas one could dive into to compare other headings and paragraph rendering.

And the final question you may be wondering is this:

Which way is actually right? Firefox/Edge/Chrome or Safari?

And my answer is: I don't actually know.

Multiple browsers behaving the same isn't necessarily indicative of the correct implementation so I suspect I will be trying to dive into browser behavior to figure out the correct implementation at a later date.

Text that reads 'Join 3000+ developers who are leveling up their design skills today' followed by the book cover for Design for Developers

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

sreelatha

Mac - safari -User Agent Stylesheet

Mac OS X (10.6.4), Safari 4.0.5 and safari 5 also

Posted on Nov 8, 2010 4:19 AM

Loading page content

Page content loaded

VikingOSX

Jun 15, 2017 5:01 AM in response to lynx78rus

Clear the history and browser cache, after you have set the Safari Preferences : Advanced : StyleSheet to None. You will have to quit and relaunch Safari afterwards to be rid of the “User agent Stylesheet” properties.

If the problem persists after paragraph 1, then download and run the free Malwarebytes anti-malware tool (requires Mavericks or later). If it finds anything, allow it to remove what it finds, and then reboot your Mac.

If the problem still persists, then it may very likely be something that the site that you visit is doing to Safari.

Carolyn Samit

Nov 8, 2010 9:51 AM in response to sreelatha

lynx78rus

Jun 15, 2017 12:24 AM in response to Carolyn Samit

Did not work.

http://prntscr.com/fjz5xn

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

Firefox user agent string reference

This document describes the user agent string used in Firefox 4 and later and applications based on Gecko 2.0 and later. For a breakdown of changes to the string in Gecko 2.0, see Final User Agent string for Firefox 4 (blog post). See also this document on user agent sniffing and this Hacks blog post .

General form

The UA string of Firefox itself is broken down into four components:

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion

  • Mozilla/5.0 is the general token that says the browser is Mozilla compatible, and is common to almost every browser today.
  • platform describes the native platform the browser is running on (e.g. Windows, Mac, Linux or Android), and whether or not it's a mobile phone. Firefox OS phones say " Mobile "; the web is the platform. Note that platform can consist of multiple "; "-separated tokens. See below for further details and examples.
  • rv:geckoversion indicates the release version of Gecko (such as " 17.0 ").
  • Gecko/geckotrail indicates that the browser is based on Gecko.
  • On Desktop, geckotrail is the fixed string " 20100101 "
  • Firefox/firefoxversion indicates the browser is Firefox, and provides the version (such as " 17.0 ").
  • From Firefox 10 on mobile, geckotrail is the same as firefoxversion .

Note: The recommended way of sniffing for Gecko-based browsers (if you have to sniff for the browser engine instead of using feature detection) is by the presence of the " Gecko " and " rv: " strings, since some other browsers include a " like Gecko " token.

For other products based on Gecko, the string can take one of two forms, where the tokens have the same meaning except those noted below:

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail appname/appversion Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion appname/appversion

  • appname/appversion indicates the application name and version. For instance, this could be " Camino/2.1.1 ", or " SeaMonkey/2.7.1 ".
  • Firefox/firefoxversion is an optional compatibility token that some Gecko-based browsers may choose to incorporate, to achieve maximum compatibility with websites that expect Firefox. firefoxversion will generally represent the equivalent Firefox release corresponding to the given Gecko version. Some Gecko-based browsers may not opt into using this token; for this reason, sniffers should be looking for Gecko — not Firefox!

Prior to Firefox 4 and Gecko 2.0, it was possible for extensions and plug-ins to add user agent parts, but that has not been possible since Firefox bug 581008 .

Mobile and Tablet indicators

The platform part of the UA string indicates if Firefox is running on a phone-sized or tablet device. When Firefox runs on a device that has the phone form factor, there is a Mobile; token in the platform part of the UA string. When Firefox runs on a tablet device, there is a Tablet; token in the platform part of the UA string instead. For example:

Note: The version numbers are not relevant. Avoid inferring materials based on these.

The preferred way to target content to a device form factor is to use CSS Media Queries. However, if you use UA sniffing to target content to a device form factor, please look for Mobi (to include Opera Mobile, which uses "Mobi") for the phone form factor and do not assume any correlation between "Android" and the device form factor. This way, your code will work if/when Firefox ships on other phone/tablet operating systems or Android is used for laptops. Also, please use touch detection to find touch devices rather than looking for "Mobi" or "Tablet", since there may be touch devices which are not tablets.

Note: Firefox OS devices identify themselves without any operating system indication; for example: "Mozilla/5.0 (Mobile; rv:15.0) Gecko/15.0 Firefox/15.0". The web is the platform.

Windows user agents have the following variations, where x.y is the Windows NT version (for instance, Windows NT 6.1).

Linux is a more diverse platform. Your distribution of Linux might include an extension that changes your user-agent. A few common examples are given below.

Android (version 40 and below)

Android (version 41 and above).

Beginning in version 41, Firefox for Android will contain the Android version as part of the platform token. For increased interoperability, if the browser is running on a version below 4 it will report 4.4. Android versions 4 and above will report the version accurately. Note that the same Gecko—with the same capabilities—is shipped to all versions of Android.

Focus for Android

From version 1, Focus is powered by Android WebView and uses the following user agent string format:

Tablet versions on WebView mirror mobile, but do not contain a Mobile token.

Starting in Version 6, users can opt into using a GeckoView-based Focus for Android with a hidden preference: it uses a GeckoView UA string to advertise Gecko compatibility.

Klar for Android

Since version 4.1, Klar for Android uses the same UA string as Focus for Android . Before version 4.1, it sent a Klar/<version> product/version token.

Focus for iOS

Version 7 of Focus for iOS uses a user agent string with the following format:

Note: this user agent was retrieved from an iPhone XR simulator and may be different on device.

Firefox for Fire TV

Version 3 (and probably earlier) of Firefox for Fire TV use a user agent string with the following format:

Firefox for Echo Show

From version 1.1, Firefox for Echo Show uses a user agent string with the following format:

Device-specific user agent strings

Although it is strongly discouraged by Mozilla, some handset manufacturers unfortunately include a token in their device's UA string that represents their device id. If this is the case, the Firefox OS UA string will look like the device-specific string in the table above, where nnnn; is the manufacturer's code for the device (see Guidelines ). Some of them we have noticed are of the form " NexusOne; ", " ZTEOpen; ", or " Open C; " (note that putting space is also discouraged). We provide this information to assist with your UA detection logic, but Mozilla discourages the detection of a device id in UA strings.

Here is a JavaScript regular expression that will detect all mobile devices, including devices with a device id in their UA string:

The i makes it case-insensitive, and mobi matches all mobile browsers.

Firefox OS version number

While the version number for Firefox OS is not included in the UA string, it is possible to infer version information from the Gecko version number present in the UA string.

Note: It's easy to find the correspondences by looking at the Mercurial repository names : repositories starting by mozilla-b2g are the release repositories for Firefox OS, and have both Firefox OS and Gecko versions in their names.

Firefox OS has a four-digit version number: X.X.X.Y . The first two digits are owned by the Mozilla product team and denote versions with new features (eg: v1.1, 1.2, etc.). The third digit is incremented with regular version tags (about every 6 weeks) for security updates, and the fourth is owned by the OEM.

  • Recommendations on sniffing the UA string for cross-browser support
  • window.navigator.userAgent

IMAGES

  1. Custom Style Sheets in Safari

    safari user agent stylesheet

  2. How to Change User Agent in Safari

    safari user agent stylesheet

  3. Custom Style Sheets in Safari

    safari user agent stylesheet

  4. How to Change User-Agents in Chrome, Edge, Safari & Firefox

    safari user agent stylesheet

  5. How to Change User Agent in Safari

    safari user agent stylesheet

  6. How to Change User Agent in Safari

    safari user agent stylesheet

VIDEO

  1. UX in SAFe

  2. CSS System Colors

  3. Tata SAFARI DARK Edition user experience malayalam #tata #tatasafari #tatasafaridarkedition

  4. User agent switcher extension

  5. Изменение User Agent в популярных браузерах

  6. Safari #blackedition 🫀 #ytshorts #safari #harrier #carslove

COMMENTS

  1. css

    User-agents, or browsers, have basic style sheets that give default styles to any document. These style sheets are named user-agent stylesheets. Most browsers use actual stylesheets for this purpose while others simulate them in code. The end result is the same. edited Feb 10 at 21:25.

  2. How to stop user agent stylesheets from overriding my css

    The (relevant) user agent rule (on chrome) is: input, input[type="password"], input[type="search"] {. cursor: auto; } You can achieve what you want in a couple ways: Create a css class that selects the input directly, for example. using another css class, or. selecting the input within the already-defined class, etc.

  3. Custom Style Sheets in Safari

    First off, Safari lets you specify a custom style sheet. In case you don't know, a custom style sheet is a bunch of CSS rules that you get to specify and then the browser will apply them to every single web page you visit. The first thing I needed to do was open twitter.com and find out what type of CSS rule I could write to target that right ...

  4. What are the latest user agents for Safari?

    The latest user agents for Safari. Apple's Safari web browser runs on mobile devices (iPhones, iPads and iPod Touches) and macOS computers. Depending on which platform you're using (or want to pretend you're using!) the user agent will be a bit different. Here we have the latest user agents for Safari on mobile and computer platforms.

  5. How to Change User Agent in Safari

    Alternatively, you can just open the Safari app and then hit the hotkey Command + comma (,) to bring up Safari Preferences. Go to the Advanced tab from the General tab. The Safari Preferences menu Advanced tab. At the bottom of the Advanced tab, checkmark the checkbox for the setting Show Develop menu in menu bar. 2.

  6. Things I Learned Reading Webkit's UA Stylesheet

    I browsed through Webkit's user agent stylesheet for no other reason than curiosity (you can find via trac or GitHub). A number of interesting things stood out to me, so I started taking notes. ... presumably allowing developers of Safari to imbue browser controls with system-level appearance configurations from the OS.

  7. How to Change User-Agents in Chrome, Edge, Safari & Firefox

    How to Change User-Agent on Safari. 1. Go to Preferences. 2. Enable Develop Menu Bar. Go to Advanced and check Show Develop menu in menu bar. 3. Navigate to Develop > User-Agent. You can again ...

  8. User Agent Style Sheets: Basics and Samples

    Specification. CSS 1 introduces the idea by stating that "each User Agent (UA, often a 'web browser' or 'web client') will have a default style sheet that presents documents in a reasonable—but arguably mundane—manner." CSS 2 says that "conforming user agents must apply a default style sheet (or behave as if they did)" and that "a user agent's default style sheet should ...

  9. What is a User Agent Stylesheet

    A user agent stylesheet is a set of predefined style rules that web browsers use to render HTML documents. These style rules are built into the browser and apply to all HTML documents that are loaded in the browser. When a web page is loaded in a browser, the browser first parses the HTML and creates a Document Object Model (DOM) tree.

  10. Safari custom user agent CSS overrides using webfonts

    Safari custom user agent CSS overrides using webfonts. 18 Nov 2020. I like to use better monospace fonts as default fonts in browsers. In Chrome and Firefox, this is pretty straight forward—go to Preferences, and you'll see a menu to change the default fonts. This is a bit harder on Safari; its Intelligent Tracking Protection disables ...

  11. A Guide To CSS Debugging

    Every browser ships with a default stylesheet called user-agent (UA) styles. Here's an example of how those styles appear in the primary browsers: From top to bottom: Firefox, Safari, and Chrome user agent styles for the margin property of the body (Large preview)

  12. iOS user css stylesheets for Safari

    Yes, see the Hyperweb extension, which allows the injection of a custom CSS on any website to change its style as a free feature, and its instructions on How to inject custom CSS in iOS Safari. Share. Improve this answer. edited Oct 10, 2022 at 10:06. Alper.

  13. Overriding Default Button Styles

    Here's Chrome's user agent stylesheet for buttons: Firefox behaves a bit differently. See in the video above how setting border: 0; removed the border in Chrome, ... /** * Correct the inability to style clickable types in iOS and Safari. */ button, [type="button"], [type="reset"], [type="submit"] { -webkit-appearance: button; } I was a ...

  14. Unveiling the Magic of User-Agent Stylesheets in Web Development

    The user-agent string is a snippet of information transmitted by the browser to identify itself to web servers. It typically includes details about the browser, version, and the operating system. When a browser renders a web page, it employs a default set of styles known as user-agent styles. These styles provide a baseline appearance for HTML ...

  15. Accessible Font Sizing, Explained

    The browser first loads its default styles (also known as the "User Agent stylesheet"), then those cascade to the author's styles (the ones we define), and they both cascade and get overwritten by the user's styles. ... Safari iOS: 16px: Kindle Touch: 26px (renders as 16px since it's a high density screen) ...

  16. Browser font rendering inconsistencies

    Jason Pamental suggested using font-synthesis: none; but that didn't have any effect in Safari or Firefox (it's not supported in other browsers at the moment.) Computed Styles # I started to dissect differences between the user agent style sheet and the Computed Styles tab in the DevTools. Safari User agent stylesheet: h1 { font-weight: bold; }

  17. Mac

    Mac - safari -User Agent Stylesheet. How to get rid of classes applied by "User agent stylesheet" in MAC safari. Show more Less. Mac OS X (10.6.4), Safari 4.0.5 and safari 5 also Posted on Nov 8, 2010 4:19 AM Me too (39 ...

  18. safari

    The culprit in my case turned out to be a Content Blocker (iOS ad-blocker) which was blocking elements on the page by forcing a User Stylesheet to display:none on certain CSS elements. Because of this, Safari showed it as "locked" like in your screenshot with no way to edit/modify it. A warning appeared in the Web Inspector 'Logs' tab telling ...

  19. Firefox user agent string reference

    Firefox user agent string reference. This document describes the user agent string used in Firefox 4 and later and applications based on Gecko 2.0 and later. For a breakdown of changes to the string in Gecko 2.0, see Final User Agent string for Firefox 4 (blog post). See also this document on user agent sniffing and this Hacks blog post.

  20. html

    Lowest 0 │ user agent styles => these are the styles you see in the screenshot. 1 │ User styles. 2 │ author CSS styles => beware CSS precedence rules (link below)! 3 │ author inline styles. 4 │ author CSS styles with `!important`. 5 │ author inline styles with `!important`. Highest 6 │ User styles with `!important`.