Using feature detection to write CSS with cross-browser support

In early 2017, I presented a couple of workshops on the topic of CSS feature detection, titled CSS Feature Detection in 2017.

A friend of mine, Justin Slack from New Media Labs, recently sent me a link to the phenomenal Feature Query Manager extension (available for both Chrome and Firefox), by Nigerian developer Ire Aderinokun. This seemed to be a perfect addition to my workshop material on the subject.

However, upon returning to the material, I realized how much my work on the subject has aged in the last 18 months.

The CSS landscape has undergone some tectonic shifts:

  • The Atomic CSS approach, although widely hated at first, has gained some traction through libraries like Tailwind, and perhaps influenced the addition of several new utility classes to Bootstrap 4.
  • CSS-in-JS exploded in popularity, with Styled Components at the forefront of the movement.
  • The CSS Grid Layout spec has been adopted by browser vendors with surprising speed, and was almost immediately sanctioned as production ready.

The above prompted me to not only revisit my existing material, but also ponder the state of CSS feature detection in the upcoming 18 months.

In short:

  1. ❓ Why do we need CSS feature detection at all?
  2. 🛠️ What are good (and not so good) ways to do feature detection?
  3. 🤖 What does the future hold for CSS feature detection?

Cross-browser compatible CSS

When working with CSS, it seems that one of the top concerns always ends up being inconsistent feature support among browsers. This means that CSS styling might look perfect on my browsers of choice, but might be completely broken on another (perhaps an even more popular) browser.

Luckily, dealing with inconsistent browser support is trivial due to a key feature in the design of the CSS language itself. This behavior, called fault tolerance, means that browsers ignore CSS code they don’t understand. This is in stark contrast to languages like JavaScript or PHP that stop all execution in order to throw an error.

The critical implication here is that if we layer our CSS accordingly, properties will only be applied if the browser understands what they mean. As an example, you can include the following CSS rule and the browser will just ignore it— overriding the initial yellow color, but ignoring the third nonsensical value:

background-color: yellow;
background-color: blue; /* Overrides yellow */
background-color: aqy8godf857wqe6igrf7i6dsgkv; /* Ignored */

To illustrate how this can be used in practice, let me start with a contrived, but straightforward situation:

A client comes to you with a strong desire to include a call-to-action (in the form of a popup) on his homepage. With your amazing front-end skills, you are able to quickly produce the most obnoxious pop-up message known to man:

Unfortunately, it turns out that his wife has an old Windows XP machine running Internet Explorer 8. You’re shocked to learn that what she sees no longer resembles a popup in any shape or form.

But! We remember that by using the magic of CSS fault tolerance, we can remedy the situation. We identify all the mission-critical parts of the styling (e.g., the shadow is nice to have, but does not add anything useful usability-wise) and buffer prepend all core styling with fallbacks.

This means that our CSS now looks something like the following (the overrides are highlighted for clarity):

.overlay { background: grey; background: rgba(0, 0, 0, 0.4); border: 1px solid grey; border: 1px solid rgba(0, 0, 0, 0.4); padding: 64px; padding: 4rem; display: block; display: flex; justify-content: center; /* if flex is supported */ align-items: center; /* if flex is supported */ height: 100%; width: 100%;
} .popup { background: white; background-color: rgba(255, 255, 255, 1); border-radius: 8px; border: 1px solid grey; border: 1px solid rgba(0, 0, 0, 0.4); box-shadow: 0 7px 8px -4px rgba(0,0, 0, 0.2), 0 13px 19px 2px rgba(0, 0, 0, 0.14), 0 5px 24px 4px rgba(0, 0, 0, 0.12); padding: 32px; padding: 2rem; min-width: 240px;
} button { background-color: #e0e1e2; background-color: rgba(225, 225, 225, 1); border-width: 0; border-radius: 4px; border-radius: 0.25rem; box-shadow: 0 1px 3px 0 rgba(0,0,0,.2), 0 1px 1px 0 rgba(0,0,0,.14), 0 2px 1px -1px rgba(0,0,0,.12); color: #5c5c5c; color: rgba(95, 95, 95, 1); cursor: pointer; font-weight: bold; font-weight: 700; padding: 16px; padding: 1rem;
} button:hover { background-color: #c8c8c8; background-color: rgb(200,200,200); }

The above example generally falls under the broader approach of Progressive Enhancement. If you’re interested in learning more about Progressive Enhancement check out Aaron Gustafson’s second edition of his stellar book on the subject, titled Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement (2016).

If you’re new to front-end development, you might wonder how on earth does one know the support level of specific CSS properties. The short answer is that the more you work with CSS, the more you will learn these by heart. However, there are a couple of tools that are able to help us along the way:

  • Can I Use is a widely used directory that contains searchable, up to date support matrices for all CSS features.
  • Stylelint has a phenomenal plugin-called called No Unsupported Browser Features that gives scours errors for unsupported CSS (defined via Browserslist) either in your editor itself or via a terminal command.
  • There are several tools like BrowserStack or Cross Browser Testing that allow you to remotely test your website on different browsers. Note that these are paid services, although BrowserStack has a free tier for open source projects.

Even with all the above at our disposal, learning CSS support by heart will help us plan our styling up front and increase our efficiency when writing it.

Limits of CSS fault tolerance

The next week, your client returns with a new request. He wants to gather some feedback from users on the earlier changes that were made to the homepage—again, with a pop-up:

Once again it will look as follows in Internet Explorer 8:

Being more proactive this time, you use your new fallback skills to establish a base level of styling that works on Internet Explorer 8 and progressive styling for everything else. Unfortunately, we still run into a problem…

In order to replace the default radio buttons with ASCII hearts, we use the ::before pseudo-element. However this pseudo-element is not supported in Internet Explorer 8. This means that the heart icon does not render; however the display: none property on the <input type="radio"> element still triggers on Internet Explorer 8. The implication being that neither the replacement behavior nor the default behavior is shown.

Credit to John Faulds for pointing out that it is actually possible to get the ‘::before’ pseudo-element to work in Internet Explorer 8 if you replace the official double colon syntax with a single colon.

In short, we have a rule (display: none) whose execution should not be bound to its own support (and thus its own fallback structure), but to the support level of a completely separate CSS feature (::before).

For all intents and purposes, the common approach is to explore whether there are more straightforward solutions that do not rely on ::before. However, for the sake of this example, let’s say that the above solution is non-negotiable (and sometimes they are).

Enter User Agent Detection

A solution might be to determine what browser the user is using and then only apply display: none if their browser supports the ::before pseudo-element.

In fact, this approach is almost as old as the web itself. It is known as User Agent Detection or, more colloquially, browser sniffing.

It is usually done as follows:

  • All browsers add a JavaScript property on the global window object called navigator and this object contains a userAgent string property.
  • In my case, the userAgent string is: Mozilla/5.0 (Windows NT10.0;Win64;x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.9 Safari/537.36.
  • Mozilla Developer Network has a comprehensive list of how the above can be used to determine the browser.
  • If we are using Chrome, then the following should return true: (navigator.userAgent.indexOf("chrome") !== -1).
  • However, under the Internet Explorer section on MDN, we just get Internet Explorer. IE doesn’t put its name in the BrowserName/VersionNumber format.
  • Luckily, Internet Explorer provides its own native detection in the form of Conditional Comments.

This means that adding the following in our HTML should suffice:

<!--[if lt IE 9]> <style> input { display: block; } </style>
<![endif]-->

This means that the above will be applied, should the browser be a version of Internet Explorer lower than version 9 (IE 9 supports ::before)—effectively overriding the display: none property.
Seems straightforward enough?

Unfortunately, over time, some critical flaws emerged in User Agent Detection. So much so that Internet Explorer stopped supporting Conditional Comments from version 10 onward. You will also notice that in the Mozilla Developer Network link itself, the following is presented in an orange alert:

It’s worth re-iterating: it’s very rarely a good idea to use user agent sniffing. You can almost always find a better, more broadly compatible way to solve your problem!

The biggest drawback of User Agent Detection is that browser vendors started spoofing their user agent strings over time due to the following:

  • Developer adds CSS feature that is not supported in the browser.
  • Developer adds User Agent Detection code to serve fallbacks to the browser.
  • Browser eventually adds support for that specific CSS feature.
  • Original User Agent Detection code is not updated to take this into consideration.
  • Code always displays the fallback, even if the browser now supports the CSS feature.
  • Browser uses a fake user agent string to give users the best experience on the web.

Furthermore, even if we were able to infallibly determine every browser type and version, we would have to actively maintain and update our User Agent Detection to reflect the feature support state of those browsers (notwithstanding browsers that have not even been developed yet).

It is important to note that although there are superficial similarities between feature detection and User Agent Detection, feature detection takes a radically different approach than User Agent Detection. According to the Mozilla Developer Network, when we use feature detection, we are essentially doing the following:

  1. 🔎 Testing whether a browser is actually able to run a specific line (or lines) of HTML, CSS or JavaScript code.
  2. 💪 Taking a specific action based on the outcome of this test.

We can also look to Wikipedia for a more formal definition (emphasis mine):

Feature detection (also feature testing) is a technique used in web development for handling differences between runtime environments (typically web browsers or user agents), by programmatically testing for clues that the environment may or may not offer certain functionality. This information is then used to make the application adapt in some way to suit the environment: to make use of certain APIs, or tailor for a better user experience.

While a bit esoteric, this definition does highlight two important aspects of feature detection:

  • Feature detection is a technique, as opposed to a specific tool or technology. This means that there are various (equally valid) ways to accomplish feature detection.
  • Feature detection programmatically tests code. This means that browsers actually run a piece of code to see what happens, as opposed to merely using inference or comparing it against a theoretical reference/list as done with User Agent Detection.

CSS feature detection with @supports

The core concept is not to ask “What browser is this?” It’s to ask “Does your browser support the feature I want to use?”.

—Rob Larson, The Uncertain Web: Web Development in a Changing Landscape (2014)

Most modern browsers support a set of native CSS rules called CSS conditional rules. These allow us to test for certain conditions within the stylesheet itself. The latest iteration (known as module level 3) is described by the Cascading Style Sheets Working Group as follows:

This module contains the features of CSS for conditional processing of parts of style sheets, conditioned on capabilities of the processor or the document the style sheet is being applied to. It includes and extends the functionality of CSS level 2 [CSS21], which builds on CSS level 1 [CSS1]. The main extensions compared to level 2 are allowing nesting of certain at-rules inside ‘@media’, and the addition of the ‘@supports’ rule for conditional processing.

If you’ve used @media, @document or @import before, then you already have experience working with CSS conditional rules. For example when using CSS media queries we do the following:

  • Wrap a single or multiple CSS declarations in a code block with curly brackets, { }.
  • Prepend the code block with a @media query with additional information.
  • Include an optional media type. This can either be all, print, speech or the commonly used screen type.
  • Chain expressions with and/or to determine the scope. For example, if we use (min-width: 300px) and (max-width: 800px), it will trigger the query if the screen size is wider than 300 pixels and smaller than 800 pixels.

The feature queries spec (editor’s draft) prescribes behavior that is conveniently similar to the above example. Instead of using a query expression to set a condition based on the screen size, we write an expression to scope our code block according to a browser’s CSS support (emphasis mine):

The ‘@supports rule allows CSS to be conditioned on implementation support for CSS properties and values. This rule makes it much easier for authors to use new CSS features and provide good fallback for implementations that do not support those features. This is particularly important for CSS features that provide new layout mechanisms, and for other cases where a set of related styles needs to be conditioned on property support.

In short, feature queries are a small built-in CSS tool that allow us to only execute code (like the display: none example above) when a browser supports a separate CSS feature—and much like media queries, we are able to chain expressions as follows: @supports (display: grid) and ((animation-name: spin) or (transition: transform(rotate(360deg)).

So, theoretically, we should be able to do the following:

@supports (::before) { input { display: none; }
}

Unfortunately, it seems that in our example above the display: none property did not trigger, in spite of the fact that your browser probably supports ::before.

That’s because there are some caveats to using @supports:

  • First and foremost, CSS feature queries only support CSS properties and not CSS pseudo-element, like ::before.
  • Secondly, you will see that in the above example our @supports (transform: scale(2)) and (animation-name: beat) condition fires correctly. However if we were to test it in Internet Explorer 11 (which supports both transform: scale(2) and animation-name: beat) it does not fire. What gives? In short, @supports is a CSS feature, with a support matrix of its own.

CSS feature detection with Modernizr

Luckily, the fix is fairly easy! It comes in the form of an open source JavaScript library named Modernizr, initially developed by Faruk Ateş (although it now has some pretty big names behind it, like Paul Irish from Chrome and Alex Sexton from Stripe).

Before we dig into Modernizr, let’s address a subject of great confusion for many developers (partly due to the name “Modernizr” itself). Modernizr does not transform your code or magically enable unsupported features. In fact, the only change Modernzr makes to your code is appending specific CSS classes to your <html> tag.

This means that you might end up with something like the following:

<html class="js flexbox flexboxlegacy canvas canvastext webgl no-touch geolocation postmessage websqldatabase indexeddb hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio localstorage sessionstorage webworkers applicationcache svg inlinesvg smil svgclippaths">

That is one big HTML tag! However, it allows us do something super powerful: use the CSS descendant selector to conditionally apply CSS rules.

When Modernizr runs, it uses JavaScript to detect what the user’s browser supports, and if it does support that feature, Modernizr injects the name of it as a class to the <html>. Alternatively, if the browser does not support the feature, it prefixes the injected class with no- (e.g., no-generatedcontent in our ::before example). This means that we can write our conditional rule in the stylesheet as follows:

.generatedcontent input { display: none
}

In addition, we are able to replicate the chaining of @supports expressions in Modernizr as follows:

/* default */
.generatedcontent input { } /* 'or' operator */
.generatedcontent input, .csstransforms input { } /* 'and' operator */
.generatedcontent.csstransformsinput { } /* 'not' operator */
.no-generatedcontent input { }

Since Modernizr runs in JavaScript (and does not use any native browser APIs), it’s effectively supported on almost all browsers. This means that by leveraging classes like generatedcontent and csstransforms, we are able to cover all our bases for Internet Explorer 8, while still serving bleeding-edge CSS to the latest browsers.

It is important to note that since the release of Modernizr 3.0, we are no longer able to download a stock-standard modernizr.js file with everything except the kitchen sink. Instead, we have to explicitly generate our own custom Modernizr code via their wizard (to copy or download). This is most likely in response to the increasing global focus on web performance over the last couple of years. Checking for more features contributes to more loading, so Modernizr wants us to only check for what we need.

So, I should always use Modernizr?

Given that Modernizr is effectively supported across all browsers, is there any point in even using CSS feature queries? Ironically, I would not only say that we should but that feature queries should still be our first port of call.

First and foremost, the fact that Modernizr does not plug directly into the browser API is it’s greatest strength—it does not rely on the availability of a specific browser API. However, this benefit comes a cost, and that cost is additional overhead to something most browsers support out of the box through @supports—especially when you’re delivering this additional overhead to all users indiscriminately in order to a small amount of edge users. It is important to note that, in our example above, Internet Explorer 8 currently only stands at 0.18% global usage).

Compared to the light touch of @supports, Modernizr has the following drawbacks:

  • The approach underpinning development of Modernizr is driven by the assumption that Modernizr was “meant from day one to eventually become unnecessary.”
  • In the majority of cases, Modernizr needs to be render blocking. This means that Modernizr needs to be downloaded and executed in JavaScript before a web page can even show content on the screen—increasing our page load time (especially on mobile devices)!
  • In order to run tests, Modernizr often has to actually build hidden HTML nodes and test whether it works. For example, in order to test for <canvas> support, Modernizr executes the follow JavaScript code: return !!(document.createElement('canvas').getContext && document.createElement('canvas').getContext('2d'));. This consumes CPU processing power that could be used elsewhere.
  • The CSS descendant selector pattern used by Modernizr increases CSS specificity. (See Harry Roberts’ excellent article on why “specificity is a trait best avoided.”)
  • Although Modernizr covers a lot of tests (150+), it still does not cover the entire spectrum of CSS properties like @support does. The Modernizr team actively maintains a list of these undetectables.

Given that feature queries have already been widely implemented across the browser landscape, (covering about 93.42% of global browsers at the time of writing), it’s been a good while since I’ve used Modernizr. However, it is good to know that it exists as an option should we run into the limitations of @supports or if we need to support users still locked into older browsers or devices for a variety of potential reasons.

Furthermore, when using Modernizr, it is usually in conjunction with @supports as follows:

.generatedcontent input { display: none;
} label:hover::before { color: #c6c8c9;
} input:checked + label::before { color: black;
} @supports (transform: scale(2)) and (animation-name: beat) { input:checked + label::before { color: #e0e1e2; animation-name: beat; animation-iteration-count: infinite; animation-direction: alternate; }
}

This triggers the following to happen:

  • If ::before is not supported, our CSS will fallback to the default HTML radio select.
  • If neither transform(scale(2)) nor animation-name: beat are supported but ::before is, then the heart icon will change to black instead of animate when selected.
  • If transform(scale(2), animation-name: beat and ::before are supported, then the heart icon will animate when selected.

The future of CSS feature detection

Up until this point, I’ve shied away from talking about feature detection in a world being eaten by JavaScript, or possibly even a post-JavaScript world. Perhaps even intentionally so, since current iterations at the intersection between CSS and JavaScript are extremely contentious and divisive.

From that moment on, the web community was split in two by an intense debate between those who see CSS as an untouchable layer in the “separation of concerns” paradigm (content + presentation + behaviour, HTML + CSS + JS) and those who have simply ignored this golden rule and found different ways to style the UI, typically applying CSS styles via JavaScript. This debate has become more and more intense every day, bringing division in a community that used to be immune to this kind of “religion wars”.

—Cristiano Rastelli, Let there be peace on CSS (2017)

However, I think exploring how to apply feature detection in the modern CSS-in-JS toolchain might be of value as follows:

  • It provides an opportunity to explore how CSS feature detection would work in a radically different environment.
  • It showcases feature detection as a technique, as opposed to a specific technology or tool.

With this in mind, let us start by examining an implementation of our pop-up by means of the most widely-used CSS-in-JS library (at least at the time of writing), Styled Components:

This is how it will look in Internet Explorer 8:

In our previous examples, we’ve been able to conditionally execute CSS rules based on the browser support of ::before (via Modernizr) and transform (via @supports). However, by leveraging JavaScript, we are able to take this even further. Since both @supports and Modernizr expose their APIs via JavaScript, we are able to conditionally load entire parts of our pop-up based solely on browser support.

Keep in mind that you will probably need to do a lot of heavy lifting to get React and Styled Components working in a browser that does not even support ::before (checking for display: grid might make more sense in this context), but for the sake of keeping with the above examples, let us assume that we have React and Styled Components running in Internet Explorer 8 or lower.

In the example above, you will notice that we’ve created a component, called ValueSelection. This component returns a clickable button that increments the amount of likes on click. If you are viewing the example on a slightly older browser, you might notice that instead of the button you will see a dropdown with values from 0 to 9.

In order to achieve this, we’re conditionally returning an enhanced version of the component only if the following conditions are met:

if ( CSS.supports('transform: scale(2)') && CSS.supports('animation-name: beat') && Modernizr.generatedcontent
) { return ( <React.Fragment> <Modern type="button" onClick={add}>{string}</Modern> <input type="hidden" name="liked" value={value} /> </React.Fragment> )
} return ( <Base value={value} onChange={select}> { [1,2,3,4,5,6,7,8,9].map(val => ( <option value={val} key={val}>{val}</option> )) } </Base>
);

What is intriguing about this approach is that the ValueSelection component only exposes two parameters:

  • The current amount of likes
  • The function to run when the amount of likes are updated
<Overlay> <Popup> <Title>How much do you like popups?</Title> <form> <ValueInterface value={liked} change={changeLike} /> <Button type="submit">Submit</Button> </form> </Popup>
</Overlay>

In other words, the component’s logic is completely separate from its presentation. The component itself will internally decide what presentation works best given a browser’s support matrix. Having the conditional presentation abstracted away inside the component itself opens the door to exciting new ways of building cross-browser compatible interfaces when working in a front-end and/or design team.

Here’s the final product:

…and how it should theoretically look in Internet Explorer 8:

Additional Resources

If you are interested in diving deeper into the above you can visit the following resources:

  • Mozilla Developer Network article on feature detection
  • Mozilla Developer Network article on user agent detection
  • Mozilla Developer Network article on CSS feature queries
  • Official feature queries documentation by the CSSWG
  • Modernizr Documentation

Schalk is a South African front-end developer/designer passionate about the role technology and the web can play as a force for good in his home country. He works full time with a group of civic tech minded developers at a South African non-profit called OpenUp.

He also helps manage a collaborative space called Codebridge where developers are encouraged to come and experiment with technology as a tool to bridge social divides and solve problems alongside local communities.

The post Using feature detection to write CSS with cross-browser support appeared first on CSS-Tricks.

CSS Basics: The Second “S” in CSS

CSS is an abbreviation for Cascading Style Sheets.

While most of the discussion about CSS on the web (or even here on CSS-Tricks) is centered around writing styles and how the cascade affects them, what we don’t talk a whole lot about is the sheet part of the language. So let’s give that lonely second “S” a little bit of the spotlight and understand what we mean when we say CSS is a style sheet.

The Sheet Contains the Styles

The cascade describes how styles interact with one another. The styles make up the actual code. Then there’s the sheet that contains that code. Like a sheet of paper that we write on, the “sheet” of CSS is the digital file where styles are coded.

If we were to illustrate this, the relationship between the three sort of forms a cascade:

The sheet holds the styles.

There can be multiple sheets all continuing multiple styles all associated with one HTML document. The combination of those and the processes of figuring out what styles take precedence to style what elements is called the cascade (That first “C” in CSS).

The Sheet is a Digital File

The sheet is such a special thing that it’s been given its own file extension: .css. You have the power to create these files on your own. Creating a CSS file can be done in any text editor. They are literally text files. Not “rich text” documents or Word documents, but plain ol’ text.

If you’re on Mac, then you can fire up TextEdit to start writing CSS. Just make sure it’s in “Plain Text” mode.

If you’re on Windows, the default Notepad app is the equivalent. Heck, you can type styles in just about any plain text editor to write CSS, even if that’s not what it says it was designed to do.

Whatever tool you use, the key is to save your document as a .css file. This can usually be done by simply add that to your file name when saving. Here’s how that looks in TextEdit:

Seriously, the choice of which text editor to use for writing CSS is totally up to you. There are many, many to choose from, but here are a few popular ones:

  • Sublime Text
  • Atom
  • VIM
  • PhpStorm
  • Coda
  • Dreamweaver

You might reach for one of those because they’ll do handy things for you like syntax highlight the code (colorize different parts to help it be easier to understand what is what).

Hey look I made some files completely from scratch with my text editor:

Those files are 100% valid in any web browser, new or old. We’ve quite literally just made a website.

The Sheet is Linked Up to the HTML

We do need to connect the HTML and CSS though. As in make sure the styles we wrote in our sheet get loaded onto the web page.

A webpage without CSS is pretty barebones:

See the Pen Style-less Webpage by Geoff Graham (@geoffgraham) on CodePen.

Once we link up the CSS file, voila!

See the Pen Webpage With Styles by Geoff Graham (@geoffgraham) on CodePen.

How did that happen? if you look at the top of any webpage, there’s going to be a <head> tag that contains information about the HTML document:

<!DOCTYPE html>
<html> <head> <!-- a bunch of other stuff --> </head> <body> <!-- the page content --> </body> </html>

Even though the code inside the <head> might look odd, there is typically one line (or more, if we’re using multiple stylesheets) that references the sheet. It looks something like this:

<head> <link rel="stylesheet" type="text/css" href="styles.css" />
</head>

This line tells the web browser as it reads this HTML file:

  1. I’d like to link up a style sheet
  2. Here’s where it is located

You can name the sheet whatever you want:

  • styles.css
  • global.css
  • seriously-whatever-you-want.css

The important thing is to give the correct location of the CSS file, whether that’s on your web server, a The Sheet is Not Required for HTML
You saw the example of a barebones web page above. No web page is required to use a stylesheet.
Also, we can technically write CSS directly in the HTML using the HTML style attribute. This is called inline styling and it goes a little something like this if you imagine you’re looking at the code of an HTML file:
<h1 style=”font-size: 24px; line-height: 36px; color: #333333″>A Headline</h1>
<p style=”font-size: 16px; line-height: 24px; color: #000000;”>Some paragraph content.</p>
<!– and so on –>
While that’s possible, there are three serious strikes against writing styles this way: If you decide to use a stylesheet later, it is extremely difficult to override inline styles with the styles in the HTML. Inline styles take priority over styles in a sheet.
Maintaining all of those styles is tough if you need to make a “quick” change and it makes the HTML hard to read.
There’s something weird about saying we’re writing CSS inline when there really is no cascade or sheet. All we’re really writing are styles. There is a second way to write CSS in the HTML and that’s directly in the <head> in a <style> block:
<head> <style> h1 { color: #333; font-size: 24px; line-height: 36px; } p { color: #000; font-size: 16px; line-height: 24px; } </style>
</head>
That does indeed make the HTML easier to read, already making it better than inline styling. Still, it’s hard to manage all styles this way because it has to be managed on each and every webpage of a site, meaning one “quick” change might have to be done several times, depending on how many pages we’re dealing with.
An external sheet that can be called once in the <head> is usually your best bet.
The Sheet is Important
I hope that you’re starting to see the importance of the sheet by this point. It’s a core part of writing CSS. Without it, styles would be difficult to manage, HTML would get cluttered, and the cascade would be nonexistent in at least one case.
The sheet is the core component of CSS. Sure, it often appears to play second fiddle to the first “S” but perhaps that’s because we all have an quiet understanding of its importance.
Leveling Up
Now that you’re equipped with information about stylesheets, here are more resources you jump into to get a deeper understanding for how CSS behaves: Specifics on Specificity – The cascade is a confusing concept and this article breaks down the concept of specificity, which is a method for how to manage it.

  • The latest ways to deal with the cascade, inheritance and specificity – That’s a lot of words, but the this article provides pro tips on how to manage the cascade, including some ideas that may be possible in the future.
  • Override Inline Styles with CSS – This is an oldie, but goodie. While the technique is probably not best practice today, it’s a good illustration of how to override those inline styles we mentioned earlier.
  • When Using !important is The Right Choice – This article is a perfect call-and-response to the previous article about why that method may not be best practice.

  • CSS Basics: The Second “S” in CSS is a post from CSS-Tricks

    A Sliding Nightmare: Understanding the Range Input

    You may have already seen a bunch of tutorials on how to style the range input. While this is another article on that topic, it’s not about how to get any specific visual result. Instead, it dives into browser inconsistencies, detailing what each does to display that slider on the screen. Understanding this is important because it helps us have a clear idea about whether we can make our slider look and behave consistently across browsers and which styles are necessary to do so.

    Looking inside a range input

    Before anything else, we need to make sure the browser exposes the DOM inside the range input.

    In Chrome, we bring up DevTools, go to Settings, Preferences, Elements and make sure the Show user agent shadow DOM option is enabled.

    Series of Chrome screenshots illustrating the steps described above.
    Sequence of Chrome screenshots illustrating the steps from above.

    In Firefox, we go to about:config and make sure the devtools.inspector.showAllAnonymousContent flag is set to true.

    Series of Firefox screenshots illustrating the steps described above.
    Sequence of Firefox screenshots illustrating the steps from above.

    For a very long time, I was convinced that Edge offers no way of seeing what’s inside such elements. But while messing with it, I discovered that where there’s a will and (and some dumb luck) there’s a way! We need to bring up DevTools, then go to the range input we want to inspect, right click it, select Inspect Element and bam, the DOM Explorer panel now shows the structure of our slider!

    Series of Edge screenshots illustrating the steps described above.
    Sequence of Edge screenshots illustrating the steps from above.

    Apparently, this is a bug. But it’s also immensely useful, so I’m not complaining.

    The structure inside

    Right from the start, we can see a source for potential problems: we have very different beasts inside for every browser.

    In Chrome, at the top of the shadow DOM, we have a div we cannot access anymore. This used to be possible back when /deep/ was supported, but then the ability to pierce through the shadow barrier was deemed to be a bug, so what used to be a useful feature was dropped. Inside this div, we have another one for the track and, within the track div, we have a third div for the thumb. These last two are both clearly labeled with an id attribute, but another thing I find strange is that, while we can access the track with ::-webkit-slider-runnable-track and the thumb with ::-webkit-slider-thumb, only the track div has a pseudo attribute with this value.

    Chrome screenshot of the structure we have inside a range input.
    Inner structure in Chrome.

    In Firefox, we also see three div elements inside, only this time they’re not nested – all three of them are siblings. Furthermore, they’re just plain div elements, not labeled by any attribute, so we have no way of telling which is which component when looking at them for the first time. Fortunately, selecting them in the inspector highlights the corresponding component on the page and that’s how we can tell that the first is the track, the second is the progress and the third is the thumb.

    Firefox screenshot of the structure we have inside a range input.
    Inner structure in Firefox.

    We can access the track (first div) with ::-moz-range-track, the progress (second div) with ::-moz-range-progress and the thumb (last div) with ::-moz-range-thumb.

    The structure in Edge is much more complex, which, to a certain extent, allows for a greater degree of control over styling the slider. However, we can only access the elements with -ms- prefixed IDs, which means there are also a lot of elements we cannot access, with baked in styles we’d often need to change, like the overflow: hidden on the elements between the actual input and its track or the transition on the thumb’s parent.

    Edge screenshot of the structure we have inside a range input.
    Inner structure in Edge.

    Having a different structure and being unable to access all the elements inside in order to style everything as we wish means that achieving the same result in all browsers can be very difficult, if not even impossible, even if having to use a different pseudo-element for every browser helps with setting individual styles.

    We should always aim to keep the individual styles to a minimum, but sometimes it’s just not possible, as setting the same style can produce very different results due to having different structures. For example, setting properties such as opacity or filter or even transform on the track would also affect the thumb in Chrome and Edge (where it’s a child/ descendant of the track), but not in Firefox (where it’s its sibling).

    The most efficient way I’ve found to set common styles is by using a Sass mixin because the following won’t work:

    input::-webkit-slider-runnable-track, input::-moz-range-track, input::-ms-track { /* common styles */ }

    To make it work, we’d need to write it like this:

    input::-webkit-slider-runnable-track { /* common styles */ }
    input::-moz-range-track { /* common styles */ }
    input::-ms-track { /* common styles */ }

    But that’s a lot of repetition and a maintainability nightmare. This is what makes the mixin solution the sanest option: we only have to write the common styles once so, if we decide to modify something in the common styles, then we only need to make that change in one place – in the mixin.

    @mixin track() { /* common styles */ } input { &::-webkit-slider-runnable-track { @include track } &::-moz-range-track { @include track } &::-ms-track { @include track }
    }

    Note that I’m using Sass here, but you may use any other preprocessor. Whatever you prefer is good as long as it avoids repetition and makes the code easier to maintain.

    Initial styles

    Next, we take a look at some of the default styles the slider and its components come with in order to better understand which properties need to be set explicitly to avoid visual inconsistencies between browsers.

    Just a warning in advance: things are messy and complicated. It’s not just that we have different defaults in different browsers, but also changing a property on one element may change another in an unexpected way (for example, when setting a background also changes the color and adds a border).

    WebKit browsers and Edge (because, yes, Edge also applies a lot of WebKit prefixed stuff) also have two levels of defaults for certain properties (for example those related to dimensions, borders, and backgrounds), if we may call them that – before setting -webkit-appearance: none (without which the styles we set won’t work in these browsers) and after setting it. The focus is going to be however on the defaults after setting -webkit-appearance: none because, in WebKit browsers, we cannot style the range input without setting this and the whole reason we’re going through all of this is to understand how we can make our lives easier when styling sliders.

    Note that setting -webkit-appearance: none on the range input and on the thumb (the track already has it set by default for some reason) causes the slider to completely disappear in both Chrome and Edge. Why that happens is something we’ll discuss a bit later in this article.

    The actual range input element

    The first property I’ve thought about checking, box-sizing, happens to have the same value in all browsers – content-box. We can see this by looking up the box-sizing property in the Computed tab in DevTools.

    Comparative screenshots of DevTools in the three browsers showing the computed values of box-sizing for a range input.
    The box-sizing of the range input, comparative look at all three browsers (from top to bottom: Chrome, Firefox, Edge).

    Sadly, that’s not an indication of what’s to come. This becomes obvious once we have a look at the properties that give us the element’s boxes – margin, border, padding, width, height.

    By default, the margin is 2px in Chrome and Edge and 0 .7em in Firefox.

    Before we move on, let’s see how we got the values above. The computed length values we get are always px values.

    However, Chrome shows us how browser styles were set (the user agent stylesheet rule sets on a grey background). Sometimes the computed values we get weren’t explicitly set, so that’s no use, but in this particular case, we can see that the margin was indeed set as a px value.

    Screenshot of Chrome DevTools showing where to look for how browser styles were set.
    Tracing browser styles in Chrome, the margin case.

    Firefox also lets us trace the source of the browser styles in some cases, as shown in the screenshot below:

    Screenshot of Firefox DevTools showing where to look for how browser styles were set.
    Tracing browser styles in Firefox and how this fails for the margin of our range input.

    However, that doesn’t work in this particular case, so what we can do is look at the computed values in DevTools and then checking whether these computed values change in one of the following situations:

    1. When changing the font-size on the input or on the html, which entails is was set as an em or rem value.
    2. When changing the viewport, which indicates the value was set using % values or viewport units. This can probably be safely skipped in a lot of cases though.
    Gif recording showing how changing the font-size on the range input changes the margin value in Firefox.
    Changing the font-size of the range input in Firefox also changes its margin value.

    The same goes for Edge, where we can trace where user styles come from, but not browser styles, so we need to check if the computed px value depends on anything else.

    Gif recording showing how changing the font-size on the range input doesn't change the margin value in Edge.
    Changing the font-size of the range input in Edge doesn’t change its margin value.

    In any event, this all means margin is a property we need to set explicitly in the input[type='range'] if we want to achieve a consistent look across browsers.

    Since we’ve mentioned the font-size, let’s check that as well. Sure enough, this is also inconsistent.

    First off, we have 13.3333px in Chrome and, in spite of the decimals that might suggest it’s the result of a computation where we divided a number by a multiple of 3, it seems to have been set as such and doesn’t depend on the viewport dimensions or on the parent or root font-size.

    Screenshot of Chrome DevTools showing the user agent rule where the font-size for inputs is set.
    The font-size of the range input in Chrome.

    Firefox shows us the same computed value, except this seems to come from setting the font shorthand to -moz-field, which I was first very confused about, especially since background-color is set to -moz-Field, which ought to be the same since CSS keywords are case-insensitive. But if they’re the same, then how can it be a valid value for both properties? Apparently, this keyword is some sort of alias for making the input look like what any input on the current OS looks like.

    Screenshot of Firefox DevTools showing how the font-size for inputs is set.
    The font-size of the range input in Firefox.

    Finally, Edge gives us 16px for its computed value and this seems to be either inherited from its parent or set as 1em, as illustrated by the recording below:

    Recording of Edge DevTools showing the computed value of font-size for inputs and how this changes when changing the font-size of the parent.
    The font-size of the range input in Edge.

    This is important because we often want to set dimensions of sliders and controls (and their components) in general using em units so that their size relative to that of the text on the page stays the same – they don’t look too small when we increase the size of the text or too big when we decrease the size of the text. And if we’re going to set dimensions in em units, then having a noticeable font-size difference between browsers here will result in our range input being smaller in some browsers and bigger in others.

    For this reason, I always make sure to explicitly set a font-size on the actual slider. Or I might set the font shorthand, even though the other font-related properties don’t matter here at this point. Maybe they will in the future, but more on that later, when we discuss tick marks and tick mark labels.

    Before we move on to borders, let’s first see the color property. In Chrome this is rgb(196,196,196) (set as such), which makes it slightly lighter than silver (rgb(192,192,192)/ #c0c0c0), while in Edge and Firefox, the computed value is rgb(0,0,0) (which is solid black). We have no way of knowing how this value was set in Edge, but in Firefox, it was set via another similar keyword, -moz-fieldtext.

    Comparative screenshots of DevTools in the three browsers showing the computed values of color for a range input.
    The color of the range input, comparative look at all three browsers (from top to bottom: Chrome, Firefox, Edge).

    The border is set to initial in Chrome, which is equivalent to none medium currentcolor (values for border-style, border-width and border-color). How thick a medium border is exactly depends on the browser, though it’s at least as thick as a thin one everywhere. In Chrome in particular, the computed value we get here is 0.

    Screenshot of Chrome DevTools showing how the border for inputs is set.
    The border of the range input in Chrome.

    In Firefox, we also have a none medium currentcolor value set for the border, though here medium seems to be equivalent to 0.566667px, a value that doesn’t depend on the element or root font-size or on the viewport dimensions.

    Screenshot of Firefox DevTools showing how the border for inputs is set.
    The border of the range input in Firefox.

    We can’t see how everything was set in Edge, but the computed values for border-style and border-width are none and 0 respectively. The border-color changes when we change the color property, which means that, just like in the other browsers, it’s set to currentcolor.

    Recording of Edge DevTools showing the computed values of border properties for inputs and how border-color changes when changing the element's color property.
    The border of the range input in Edge.

    The padding is 0 in both Chrome and Edge.

    Comparative screenshots of DevTools in Chrome and Edge browsers showing the computed values of padding for a range input.
    The padding of the range input, comparative look at Chrome (top) and Edge (bottom).

    However, if we want a pixel-perfect result, then we need to set it explicitly because it’s set to 1px in Firefox.

    Screenshot of Firefox DevTools showing how the padding for inputs is set.
    The padding of the range input in Firefox.

    Now let’s take another detour and check the backgrounds before we try to make sense of the values for the dimensions. Here, we get that the computed value is transparent/ rgba(0, 0, 0, 0) in Edge and Firefox, but rgb(255,255,255) (solid white) in Chrome.

    Comparative screenshots of DevTools in the three browsers showing the computed values of background-color for a range input.
    The background-color of the range input, comparative look at all three browsers (from top to bottom: Chrome, Firefox, Edge).

    And… finally, let’s look at the dimensions. I’ve saved this for last because here is where things start to get really messy.

    Chrome and Edge both give us 129px for the computed value of the width. Unlike with previous properties, we can’t see this being set anywhere in Chrome, which would normally lead me to believe it’s something that depends either on the parent, stretching horizontally to fit as all block elements do (which is definitely not the case here) or on the children. There’s also a -webkit-logical-width property taking the same 129px value in the Computed panel. I was a bit confused by this at first, but it turns out it’s the writing-mode relative equivalent – in other words, it’s the width for horizontal writing-mode and the height for vertical writing-mode.

    Gif recording showing how changing the font-size on the range input doesn't change its width value in Chrome.
    Changing the font-size of the range input in Chrome doesn’t change its width value.

    In any event, it doesn’t depend on the font-size of the input itself or of that of the root element nor on the viewport dimensions in either browser.

    Gif recording showing how changing the font-size on the range input doesn't change its width value in Edge.
    Changing the font-size of the range input in Edge doesn’t change its width value.

    Firefox is the odd one out here, returning a computed value of 160px for the default width. This computed value does however depend on the font-size of the range input – it seems to be 12em.

    Gif recording showing how changing the font-size on the range input also changes its width value in Firefox.
    Changing the font-size of the range input in Firefox also changes its width value.

    In the case of the height, Chrome and Edge again both agree, giving us a computed value of 21px. Just like for the width, I cannot see this being set anywhere in the user agent stylesheet in Chrome DevTools, which normally happens when the height of an element depends on its content.

    Gif recording showing how changing the font-size on the range input doesn't change its height value in Chrome.
    Changing the font-size of the range input in Chrome doesn’t change its height value.

    This value also doesn’t depend on the font-size in either browser.

    Gif recording showing how changing the font-size on the range input doesn't change its height value in Edge.
    Changing the font-size of the range input in Edge doesn’t change its height value.

    Firefox is once again different, giving us 17.3333px as the computed value and, again, this depends on the input‘s font-size – it’s 1.3em.

    Gif recording showing how changing the font-size on the range input also changes its height value in Firefox.
    Changing the font-size of the range input in Firefox also changes its height value.

    But this isn’t worse than the margin case, right? Well, so far, it isn’t! But that’s just about to change because we’re now moving on to the track component.

    The range track component

    There’s one more possibility regarding the actual input dimensions that we haven’t yet considered: that they’re influenced by those of its components. So let’s explicitly set some dimensions on the track and see whether that influences the size of the slider.

    Apparently, in this situation, nothing changes for the actual slider in the case of the width, but we can spot more inconsistencies when it comes to the track width, which, by default, stretches to fill the content-box of the parent input in all three browsers.

    In Firefox, if we explicitly set a width, any width on the track, then the track takes this width we give it, expanding outside of its parent slider or shrinking inside, but always staying middle aligned with it. Not bad at all, but, sadly, it turns out Firefox is the only browser that behaves in a sane manner here.

    Gif recording showing how changing the width on the track component doesn't influence the width of the range input in Firefox only that of the track. Furthermore, the track and the actual range input are always middle aligned horizontally.
    Explicitly setting a width on the track changes the width of the track in Firefox, but not that of the parent slider.

    In Chrome, the track width we set is completely ignored and it looks like there’s no sane way of making it have a value that doesn’t depend on that of the parent slider.

    Gif recording showing how changing the width on the track component doesn't do anything in Chrome.
    Changing the width of the track doesn’t do anything in Chrome (computed value remains 129px).

    As for insane ways, using transform: scaleX(factor) seems to be the only way to make the track wider or narrower than its parent slider. Do note doing this also causes quite a few side effects. The thumb is scaled horizontally as well and its motion is limited to the scaled down track in Chrome and Edge (as the thumb is a child of the track in these browsers), but not in Firefox, where its size is preserved and its motion is still limited to the input, not the scaled down track (since the track and thumb are siblings here). Any lateral padding, border or margin on the track is also going to be scaled.

    Moving on to Edge, the track again takes any width we set.

    Gif recording showing how Edge allows us to change the width of the track without changing that of the parent slider.
    Edge also allows us to set a track width that’s different from that of the parent slider.

    This is not the same situation as Firefox however. While setting a width greater than that of the parent slider on the track makes it expand outside, the two are not middle aligned. Instead, the left border limit of the track is left aligned with the left content limit of its range input parent. This alignment inconsistency on its own wouldn’t be that much of a problem – a margin-left set only on ::-ms-track could fix it.

    However, everything outside of the parent slider’s content-box gets cut out in Edge. This is not equivalent to having overflow set to hidden on the actual input, which would cut out everything outside the padding-box, not content-box. Therefore, it cannot be fixed by setting overflow: visible on the slider.

    This clipping is caused by the elements between the input and the track having overflow: hidden, but, since we cannot access these, we also cannot fix this problem. Setting everything such that no component (including its box-shadow) goes outside the content-box of the range is an option in some cases, but not always.

    For the height, Firefox behaves in a similar manner it did for the width. The track expands or shrinks vertically to the height we set without affecting the parent slider and always staying middle aligned to it vertically.

    Gif recording showing how changing the height on the track component doesn't influence the height of the range input in Firefox only that of the track. Furthermore, the track and the actual range input are always middle aligned vertically.
    Explicitly setting a height on the track changes the height of the track in Firefox, but not that of the parent slider.

    The default value for this height with no styles set on the actual input or track is .2em.

    Gif recording showing how changing the font-size on the track changes its computed height in Firefox.
    Changing the font-size on the track changes its computed height in Firefox.

    Unlike in the case of the width, Chrome allows the track to take the height we set and, if we’re not using a % value here, it also makes the content-box of the parent slider expand or shrink such that the border-box of the track perfectly fits in it. When using a % value, the actual slider and the track are middle aligned vertically.

    Gif recording showing how changing the height on the track component doesn't influence the height of the range input in Chrome if the value we set is a % value. Otherwise, the track expands or shrinks such that the track perfectly fits in. Furthermore, in the % case, the track and the actual range input are always middle-aligned vertically.
    Explicitly setting a height on the track in % changes the height of the track in Chrome, but not that of the parent slider. Using other units, the actual range input expands or shrinks vertically such that the track perfectly fits inside.

    The computed value we get for the height without setting any custom styles is the same as for the slider and doesn’t change with the font-size.

    Gif recording showing how changing the font-size on the track doesn't change its computed height in Chrome.
    Changing the font-size on the track doesn’t change its computed height in Chrome.

    What about Edge? Well, we can change the height of the track independently of that of the parent slider and they both stay middle aligned vertically, but all of this is only as long as the track height we set is smaller than the initial height of the actual input. Above that, the track’s computed height is always equal to that of the parent range.

    Gif recording showing how changing the height on the track component doesn't influence the height of the range input in Edge. The track and the actual range input are always middle aligned vertically. However, the height of the track is limited by that of the parent slider.
    Explicitly setting a height on the track in Edge doesn’t change the height of the parent slider and the two are middle aligned. However, the height of the track is limited by that of the actual input.

    The initial track height is 11px and this value doesn’t depend on the font-size or on the viewport.

    Gif recording showing how changing the font-size on the track doesn't change its computed height in Edge.
    Changing the font-size on the track doesn’t change its computed height in Edge.

    Moving on to something less mindbending, we have box-sizing. This is border-box in Chrome and content-box in Edge and Firefox so, if we’re going to have a non-zero border or padding, then box-sizing is a property we need to explicitly set in order to even things out.

    Comparative screenshots of DevTools in the three browsers showing the computed values of box-sizing for the track.
    The box-sizing of the track, comparative look at all three browsers (from top to bottom: Chrome, Firefox, Edge).

    The default track margin and padding are both 0 in all three browsers – finally, an oasis of consistency!

    Comparative screenshots of DevTools in the three browsers showing the computed values of margin for the track.
    The box-sizing of the track, comparative look at all three browsers (from top to bottom: Chrome, Firefox, Edge).

    The values for the color property can be inherited from the parent slider in all three browsers.

    Comparative screenshots of DevTools in Chrome and Firefox browsers showing the computed values of color for the track.
    The color of the track, comparative look at Chrome (top) and Firefox (bottom).

    Even so, Edge is the odd one here, changing it to white, though setting it to initial changes it to black, which is the value we have for the actual input.

    Resetting the color to initial in Edge.
    Resetting the color to initial in Edge.

    Setting -webkit-appearance: none on the actual input in Edge makes the computed value of the color on the track transparent (if we haven’t explicitly set a color value ourselves). Also, once we add a background on the track, the computed track color suddenly changes to black.

    Adding a background on the track in Edge changes its computed color from white to black.
    Unexpected consequence of adding a background track in Edge.

    To a certain extent, the ability to inherit the color property is useful for theming, though inheriting custom properties can do a lot more here. For example, consider we want to use a silver for secondary things and an orange for what we want highlighted. We can define two CSS variables on the body and then use them across the page, even inside our range inputs.

    body { --fading: #bbb; --impact: #f90
    } h2 { border-bottom: solid .125em var(--impact) } h6 { color: var(--fading) } [type='range']:focus { box-shadow: 0 0 2px var(--impact) } @mixin track() { background: var(--fading) } @mixin thumb() { background: var(--impact) }

    Sadly, while this works in Chrome and Firefox, Edge doesn’t currently allow custom properties on the range inputto be inherited down to its components.

    Screenshots of the expected result (and what we get in Chrome and Firefox) vs. the result we get in Edge (neither the thumb or the track show up)
    Expected result (left) vs. result in Edge (right), where no track or thumb show up (live demo).

    By default, there is no border on the track in Chrome or Firefox (border-width is 0 and border-style is none).

    Comparative screenshots of DevTools in Chrome and Firefox browsers showing the computed values of border for the track.
    The border of the track, comparative look at Chrome (top) and Firefox (bottom).

    Edge has no border on the track if we have no background set on the actual input and no background set on the track itself. However, once that changes, we get a thin (1px) black track border.

    Adding a background on the track or actual input in Edge gives the track a solid 1px black border.
    Another unexpected consequence of adding a track or parent slider background in Edge.

    The default background-color is shown to be inherited as white, but then somehow we get a computed value of rgba(0,0,0,0) (transparent) in Chrome (both before and after -webkit-appearance: none). This also makes me wonder how come we can see the track before, since there’s no background-color or background-image to give us anything visible. Firefox gives us a computed value of rgb(153,153,153) (#999) and Edge transparent (even though we might initially think it’s some kind of silver, that is not the background of the ::-ms-track element – more on that a bit later).

    Comparative screenshots of DevTools in the three browsers showing the computed values of background-color for the track.
    The background-color of the track, comparative look at all three browsers (from top to bottom: Chrome, Firefox, Edge).

    The range thumb component

    Ready for the most annoying inconsistency yet? The thumb moves within the limits of the track’s content-box in Chrome and within the limits of the actual input‘s content-box in Firefox and Edge, even when we make the track longer or shorter than the input (Chrome doesn’t allow this, forcing the track’s border-box to fit the slider’s content-box horizontally).

    The way Chrome behaves is illustrated below:

    Chrome only moves the thumb within the left and right limits of the track's content-box.
    Recording of the thumb motion in Chrome from one end of the slider to the other.

    The padding is transparent, while the content-box and the border are semitransparent. We’ve used orange for the actual slider, red for the track and purple for the thumb.

    For Firefox, things are a bit different:

    Firefox moves the thumb within the left and right limits of the actual range input's content-box.
    Recording of the thumb motion in Firefox from one end of the slider to the other (the three cases from top to bottom: the border-box of the track perfectly fits the content-box of the slider horizontally, it’s longer and it’s shorter).

    In Chrome, the thumb is the child of the track, while in Firefox it’s its sibling, so, looking at it this way, it makes sense that Chrome would move the thumb within the limits of the track’s content-box and Firefox would move it within the limits of the slider’s content-box. However, the thumb is inside the track in Edge too and it still moves within the limits of the slider’s content-box.

    Animated gif. Shows how Edge moves the thumb within the left and right limits of the actual range input's content-box.
    Recording of the thumb motion in Edge from one end of the slider to the other (the three cases from top to bottom: the border-box of the track perfectly fits the content-box of the slider horizontally, it’s longer and it’s shorter).

    While this looks very strange at first, it’s because Edge forces the position of the track to static and we cannot change that, even if we set it to relative with !important.

    Animated gif. Recording of the following steps: 1) checking the computed value of the position property on the track in Edge DevTools - it's static 2) setting ::-ms-track { position: relative } 3) checking the computed value again - it's still static 4) adding !important to the rule previously set on the track 5) checking the computed value a third time - annoyingly, it's still static!
    Trying (and failing) to change the value of the position property on the track in Edge.

    This means we may style our slider exactly the same for all browsers, but if its content-box doesn’t coincide to that of its track horizontally (so if we have a non-zero lateral padding or border on the track), it won’t move within the same limits in all browsers.

    Furthermore, if we scale the track horizontally, then Chrome and Firefox behave as they did before, the thumb moving within the limits of the now scaled track’s content-box in Chrome and within the limits of the actual input‘s content-box in Firefox. However, Edge makes the thumb move within an interval whose width equals that of the track’s border-box, but starts from the left limit of the track’s padding-box, which is probably explained by the fact that the transform property creates a stacking context.

    Edge moves the thumb within an interval equal to the scaled track's border-box, starting from the left limit of the padding-box
    Recording of the thumb motion in Edge when the track is scaled horizontally.

    Vertically, the thumb is middle-aligned to the track in Firefox, seemingly middle-aligned in Edge, though I’ve been getting very confusing different results over multiple tests of the same situation, and the top of its border-box is aligned to the top of the track’s content-box in Chrome once we’ve set -webkit-appearance: none on the actual input and on the thumb so that we can style the slider.

    While the Chrome decision seems weird at first, is annoying in most cases and lately has even contributed to breaking things in… Edge (but more about that in a moment), there is some logic behind it. By default, the height of the track in Chrome is determined by that of the thumb and if we look at things this way, the top alignment doesn’t seem like complete insanity anymore.

    However, we often want a thumb that’s bigger than the track’s height and is middle aligned to the track. We can correct the Chrome alignment with margin-top in the styles we set on the ::-webkit-slider-thumb pseudo.

    Unfortunately, this way we’re breaking the vertical alignment in Edge. This is because Edge now applies the styles set via ::-webkit-slider-thumb as well. At least we have the option of resetting margin-top to 0 in the styles we set on ::-ms-thumb. The demo below shows a very simple example of this in action.

    See the Pen by thebabydino (@thebabydino) on CodePen.

    Just like in the case of the track, the value of the box-sizing property is border-box in Chrome and content-box in Edge and Firefox, so, for consistent results across browsers, we need to set it explicitly if we want to have a non-zero border or padding on the thumb.

    The margin and padding are both 0 by default in all three browsers.

    After setting -webkit-appearance: none on both the slider and the thumb (setting it on just one of the two doesn’t change anything), the dimensions of the thumb are reset from 10x21 (dimensions that don’t depend on the font-size) to 129x0 in Chrome. The height of the track and actual slider also get reset to 0, since they depend on that of their content (the thumb inside, whose height has become 0).

    Animated gif. Shows Chrome DevTools with the thumb selected. Changing the font-size on the thumb doesn't change its dimensions. Setting -webkit-appearance: none on both the thumb and the actual slider resets its dimensions to 129x0
    The thumb box model in Chrome.

    This is also why explicitly setting a height on the thumb makes the track take the same height.

    According to Chrome DevTools, there is no border in either case, even though, before setting -webkit-appearance: none, it sure looks like there is one.

    Screenshot. Before setting -webkit-appearance:none, it looks like there is a border on the thumb, even though Chrome DevTools says there isn't.
    How the slider looks in Chrome before setting -webkit-appearance: none.

    If that’s not a border, it might be an outline or a box-shadow with no blur and a positive spread. But, according to Chrome DevTools, we don’t have an outline, nor box-shadow on the thumb.

    Screenshot. The computed value for outline in Chrome DevTools is none 0px rgb(196, 196, 196), while that for box-shadow is none.
    Computed values for outline and box-shadow in Chrome DevTools.

    Setting -webkit-appearance: none in Edge makes the thumb dimensions go from 11x11 (values that don’t depend on the font-size) to 0x0. Explicitly setting a height on the thumb makes the track take the initial height (11px).

    Animated gif. Shows Edge DevTools with the thumb selected. Changing the font-size on the thumb doesn't change its dimensions. Setting -webkit-appearance: none on both the thumb and the actual slider resets its dimensions to 0x0
    The thumb box model in Edge.

    In Edge, there’s initially no border on the thumb. However, after setting a background on either the actual range input or any of its components, we suddenly get a solid 1px white lateral one (left and right, but not top and bottom), which visually turns to black in the :active state (even though Edge DevTools doesn’t seem to notice that). Setting -webkit-appearance: none removes the border-width.

    Animated gif. Shows Edge DevTools with the thumb selected. There is originally no border, but setting a background on either the slider or its components makes the lateral borders solid 1px white ones. Setting -webkit-appearance: none on both the thumb and the actual slider removes this border (as well as making both thumb dimensions 0).
    The thumb border in Edge.

    In Firefox, without setting a property like background on the range input or its components, the dimensions of the thumb are 1.666x3.333 and, in this case, they don’t change with the font-size. However, if we set something like background: transparent on the slider (or any background value on its components), then both the width and height of the thumb become 1em.

    Animated gif. Shows Firefox DevTools with the thumb selected. Changing the font-size on the thumb doesn't change initially its dimensions. However, after setting a background on the actual input, the thumb dimensions become equal to the font-size (1em).
    The thumb box model in Firefox.

    In Firefox, if we are to believe what we see in DevTools, we initially have a solid thick grey (rgb(153, 153, 153)) border.

    Screenshot. Shows Firefox DevTools displaying the computed values for the slider thumb border.
    The thumb border in Firefox DevTools.

    Visually however, I can’t spot this thick grey border anywhere.

    Screenshot of the slider in its initial state in Firefox, before setting a background on it or on any of its components. I cannot see any border on the thumb, even Firefox DevTools says there is a pretty thick one.
    How the slider looks initially in Firefox, before setting a background on it or on any of its components.

    After setting a background on the actual range input or one of its components, the thumb border actually becomes visually detectable and it seems to be .1em.

    Animated gif. Shows Firefox DevTools with the thumb selected. In DevTools we originally see a thickish grey border, with a different width on every side, but setting a background on either the slider or its components makes this border thinner an uniform around the thumb. Its width varies with the font-size and it seems to be .1em.
    The thumb border in Firefox.

    In Chrome and in Edge, the border-radius is always 0.

    Screenshots. Top: screenshot of Chrome DevTools showing the computed value for the thumb's border-radius is 0. Bottom: screenshot of Edge DevTools showing the computed value for the thumb's border-radius is 0.
    The thumb border-radius in Chrome (top) and Edge (bottom).

    In Firefox however, we have a .5em value for this property, both before and after setting a background on the range input or on its components, even though the initial shape of the thumb doesn’t look like a rectangle with rounded corners.

    Animated gif. Shows Firefox DevTools with the thumb selected. In DevTools, we change the font-size on the thumb and, from the way the computed border-radius value changes, we get that it's set to .5em.
    The thumb border-radius in Firefox.

    The strange initial shape of the thumb in Firefox has made me wonder whether it doesn’t have a clip-path set, but that’s not the case according to DevTools.

    Screenshot. Shows Firefox DevTools with the thumb selected. The computed value for the clip-path property on the thumb is none.
    The thumb clip-path in Firefox.

    More likely, the thumb shape is due to the -moz-field setting, though, at least on Windows 10, this doesn’t make it look like every other slider.

    Screenshots. The initial appearance of the slider in Firefox vs. the appearance of a native Windows slider.
    Initial appearance of slider in Firefox vs. appearance of a native Windows 10 slider.

    The thumb’s background-color is reported as being rgba(0, 0, 0, 0) (transparent) by Chrome DevTools, even though it looks grey before setting -webkit-appearance: none. We also don’t seem to have a background-image that could explain the gradient or the lines on the thumb before setting -webkit-appearance: none. Firefox DevTools reports it as being rgb(240, 240, 240), even though it looks blue as long as we don’t have a background explicitly set on the actual range input or on any of its components.

    Screenshots. Top: screenshot of Chrome DevTools showing the computed value for background-color on the thumb is rgba(0, 0, 0, 0) and the computed value for background-image is none. Bottom: screenshot of Firefox DevTools showing the computed value for background-color on the thumb is rgb(240, 240, 240).
    The thumb background-color in Chrome (top) and Firefox (bottom).

    In Edge, the background-color is rgb(33, 33, 33) before setting -webkit-appearance: none and transparent after.

    Animated gif. Shows Edge DevTools with the thumb selected. The computed value for the thumb's background-color is rgb(33, 33, 33). In DevTools, we set -webkit-appearance: none on the actual slider and on the thumb. The computed value for the thumb's background-color becomes transparent.
    The thumb background-color in Edge.

    The range progress (fill) component

    We only have dedicated pseudo-elements for this in Firefox (::-moz-range-progress) and in Edge (::-ms-fill-lower). Note that this element is a sibling of the track in Firefox and a descendant in Edge. This means that it’s sized relative to the actual input in Firefox, but relative to the track in Edge.

    In order to better understand this, consider that the track’s border-box perfectly fits horizontally within the slider’s content-box and that the track has both a border and a padding.

    In Firefox, the left limit of the border-box of the progress component always coincides with the left limit of the slider’s content-box. When the current slider value is its minimum value, the right limit of the border-box of our progress also coincides with the left limit of the slider’s content-box. When the current slider value is its maximum value, the right limit of the border-box of our progress coincides with the right limit of the slider’s content-box.

    This means the width of the border-box of our progress goes from 0 to the width of the slider’s content-box. In general, when the thumb is at x% of the distance between the two limit value, the width of the border-box for our progress is x% of that of the slider’s content-box.

    This is shown in the recording below. The padding area is always transparent, while the border area and content-box are semitransparent (orange for the actual input, red for the track, grey for the progress and purple for the thumb).

    Animated gif. Shows the slider in Firefox with the thumb at the minimum value. The width of the border-box of the progress component is 0 in this case. We drag the thumb to the maximum slider value. The width of the border-box of the progress component equals that of the slider's content-box in this case.
    How the width of the ::-moz-range-progress component changes in Firefox.

    In Edge however, the left limit of the fill’s border-box always coincides with the left limit of the track’s content-box while the right limit of the fill’s border-box always coincides with the vertical line that splits the thumb’s border-box into two equal halves. This means that when the current slider value is its minimum value, the right limit of the fill’s border-box is half the thumb’s border-box to the right of the left limit of the track’s content-box. And when the current slider value is its maximum value, the right limit of the fill’s border-box is half the thumb’s border-box to the left of the right limit of the track’s content-box.

    This means the width of the border-box of our progress goes from half the width of the thumb’s border-box minus the track’s left border and padding to the width of the track’s content-box plus the track’s right padding and border minus half the width of the thumb’s border-box. In general, when the thumb is at x% of the distance between the two limit value, the width of the border-box for our progress is its minimum width plus x% of the difference between its maximum and its minimum width.

    This is all illustrated by the following recording of this live demo you can play with:

    Animated gif. Shows the slider in Edge with the thumb at the minimum value. The width of the border-box of the progress component is half the width of the thumb's border-box minus the track's left border and padding in this case. We drag the thumb to the maximum slider value. The width of the border-box of the progress component equals that of the track's content-box plus the track's right padding and border minus half the width of the thumb's border-box.
    How the width of the ::-ms-fill-lower component changes in Edge.

    While the description of the Edge approach above might make it seem more complicated, I’ve come to the conclusion that this is the best way to vary the width of this component as the Firefox approach may cause some issues.

    For example, consider the case when we have no border or padding on the track for cross browser consistency and the height of the both the fill’s and thumb’s border-box equal to that of the track. Furthermore, the thumb is a disc (border-radius: 50%).

    In Edge, all is fine:

    Animated gif illustrating how the case described above works in Edge using a slider with a grey track and orange progress.
    How our example works in Edge.

    But in Firefox, things look awkward (live demo):

    Animated gif illustrating how the case described above works in Firefox using a slider with a grey track and orange progress.
    How our example works in Firefox.

    The good news is that we don’t have other annoying and hard to get around inconsistencies in the case of this component.

    box-sizing has the same computed value in both browsers – content-box.

    Screenshot. Top half shows Firefox DevTools with the progress component selected. The computed value for box-sizing is shown to be content-box. Bottom half shows Edge DevTools with the lower fill component selected. The computed value for box-sizing is shown to be content-box in this case too.
    The computed value for box-sizing in the case of the progress (fill) component: Firefox (top) and Edge (bottom).

    In Firefox, the height of the progress is .2em, while the padding, border and margin are all 0.

    Animated gif. Shows Firefox DevTools with the progress component selected. Changing the font-size on this component also changes its height, allowing us to see it was set as .2em.
    The height of the progress in Firefox.

    In Edge, the fill’s height is equal to that of the track’s content-box, with the padding, border and margin all being 0, just like in Firefox.

    Animated gif. Shows Edge DevTools with the fill component selected. The height of the fill is the same as that of the track's content-box. We set box-sizing: border-box on the track and give it a vertical padding to check this. The height of the fill shrinks accordingly.
    The height of the fill in Edge.

    Initially, the background of this element is rgba(0, 0, 0, 0) (transparent, which is why we don’t see it at first) in Firefox and rgb(0, 120, 115) in Edge.

    Screenshot. Top half shows Firefox DevTools with the progress selected. The computed value for the background-color of the progress is rgba(0, 0, 0, 0). Bottom half shows Edge DevTools with the lower fill selected. The computed value for the fill's background-color is rgb(0, 120, 115).
    The background-color of the progress (fill) in Firefox (top) and Edge (bottom).

    In both cases, the computed value of the color property is rgb(0, 0, 0) (solid black).

    Screenshot. Top half shows Firefox DevTools with the progress component selected. The computed value for color is shown to be rgb(0, 0, 0). Bottom half shows Edge DevTools with the lower fill component selected. The computed value for color is shown to be rgb(0, 0, 0) in this case too.
    The computed value for color in the case of the progress (fill) component: Firefox (top) and Edge (bottom).

    WebKit browsers don’t provide such a component and, since we don’t have a way of accessing and using a track’s ::before or ::after pseudos anymore, our only option of emulating this remains layering an extra, non-repeating background on top of the track’s existing one for these browsers and making the size of this extra layer along the x axis depend depend on the current value of the range input.

    The simplest way of doing this nowadays is by using a current value --val CSS variable, which holds the slider’s current value. We update this variable every time the slider’s value changes and we make the background-size of this top layer a calc() value depending on --val. This way, we don’t have to recompute anything when the value of the range input changes – our calc() value is dynamic, so updating the --val variable is enough (not just for this background-size, but also for other styles that may depend on it as well).

    See the Pen by thebabydino (@thebabydino) on CodePen.

    Also doing this for Firefox is an option if the way ::-moz-range-progress increases doesn’t look good for our particular use case.

    Edge also provides a ::-ms-fill-upper which is basically the complementary of the lower one and it’s the silver background of this pseudo-element that we initially see to the right of the thumb, not that of the track (the track is transparent).

    Tick marks and labels

    Edge is the only browser that shows tick marks by default. They’re shown on the track, delimiting two, five, ten, twenty sections, the exact number depending initially on the track width. The only style we can change for these tick marks is the color property as this is inherited from the track (so setting color: transparent on the track removes the initial tick marks in Edge).

    Screenshot. Shows Edge DevTools with the SVG group containing the tick lines selected. Unfortunately, I cannot access this group, its children, its SVG parent or the SVG container to modify their styles. I can only access the track (which is the SVG container's parent) via ::-ms-track. Since the color property is inherited and the tick lines use currentColor as the stroke value, changing the color on the track also changes the stroke of the tick lines.
    The structure that generates the initial tick marks on the track in Edge.

    The spec says that tick marks and labels can be added by linking a datalist element, for whose option children we may specify a label attribute if we want that particular tick mark to also have a label.

    Unfortunately, though not at all surprising anymore at this point, browsers have a mind of their own here too. Firefox doesn’t show anything – no tick marks, no labels. Chrome shows the tick marks, but only allows us to control their position along the slider with the option values. It doesn’t allow us to style them in any way and it doesn’t show any labels.

    Screenshot. Shows the range input with the tick marks generated in Chrome when adding a datalist.
    Tick marks in Chrome.

    Also, setting -webkit-appearance: none on the actual slider (which is something that we need to to in order to be able to style it) makes these tick marks disappear.

    Edge joins the club and doesn’t show any labels either and it doesn’t allow much control over the look of the ticks either. While adding the datalist allows us to control which tick marks are shown where on the track, we cannot style them beyond changing the color property on the track component.

    Screenshot. Shows the range input with the tick marks generated in Edge when adding a datalist.
    Tick marks in Edge.

    In Edge, we also have ::-ms-ticks-before and ::-ms-ticks-after pseudo-elements. These are pretty much what they sound like – tick marks before and after the track. However, I’m having a hard time understanding how they really work.

    They’re hidden by display: none, so changing this property to block makes them visible if we also explicitly set a slider height, even though doing this does not change their own height.

    Animated gif. Illustrates the steps above to make the tick marks created by ::-ms-ticks-after visible.
    How to make tick marks crested by ::-ms-ticks-after visible in Edge.

    Beyond that, we can set properties like margin, padding, height, background, color in order to control their look. However, I have no idea how to control the thickness of individual ticks, how to give individual ticks gradient backgrounds or how to make some of them major and some minor.

    So, at the end of the day, our best option if we want a nice cross-browser result remains using repeating-linear-gradient for the ticks and the label element for the values corresponding to these ticks.

    See the Pen by thebabydino (@thebabydino) on CodePen.

    Tooltip/ current value display

    Edge is the only browser that provides a tooltip via ::-ms-tooltip, but this doesn’t show up in the DOM, cannot really be styled (we can only choose to hide it by setting display: none on it) and can only display integer values, so it’s completely useless for a range input between let’s say .1 and .4 – all the values it displays are 0!

    Animated gif. Dragging the thumb in Edge results in the tooltip displaying always 0 if both the minimum and the maximum are subunitary.
    ::-ms-tooltip when range limits are both subunitary.

    So our best bet is to just hide this and use the output element for all browsers, again taking advantage of the possibility of storing the current slider value into a --val variable and then using a calc() value depending on this variable for the position.

    See the Pen by thebabydino (@thebabydino) on CodePen.

    Orientation

    The good news is that every browser allows us to create vertical sliders. The bad news is, as you may have guessed… every browser provides a different way of doing this, none of which is the one presented in the spec (setting a width smaller than the height on the range input). WebKit browsers have opted for -webkit-appearance: slider-vertical, Edge for writing-mode: bt-lr, while Firefox controls this via an orient attribute with a value of 'vertical'.

    The really bad news is that, for WebKit browsers, making a slider vertical this way leaves us unable to set any custom styles on it (as setting custom styles requires a value of none for -webkit-appearance).

    Our best option is to just style our range input as a horizontal one and then rotate it with a CSS transform.

    See the Pen by thebabydino (@thebabydino) on CodePen.


    A Sliding Nightmare: Understanding the Range Input is a post from CSS-Tricks