Skip to content

Latest commit

 

History

History
90 lines (61 loc) · 3.47 KB

Browser-compatibility.md

File metadata and controls

90 lines (61 loc) · 3.47 KB
tree_title description last_modified
Browser compatibility
Making sure your CSS works in different browsers
2022-01-27 17:10:03 UTC

Browser compatibility (CSS)

Contents

Eliminating inconsistencies

Problem: Different browsers use different defaults for how elements should look like

Solution: CSS reset stylesheet that overrides browser defaults by some sensible values and provides a "clean slate" for your CSS to build upon

Example: Normalize.css

Checking which browsers support certain functionality

Support queries

Can be used to conditionally apply CSS only if the browser supports certain functionality

Example:

@supports (display: grid) {
    .container {
        display: grid;
        /* other grid properties */
    }
}

Vendor prefixes

Different browsers implement new features differently and at different speeds

Vendor prefixes: browser-specific (or rendering-engine-specific) prefixes on properties or values that trigger a browser-specific (or rendering-engine-specific) version of the feature

Goals:

  • Allow developers to make use of new features before they are standardized
  • When the features become standardized, it is still possible to get the old non-standard behaviors by using the prefixes (don't break behavior for early adopters that depend on some specific non-standard behavior)
  • By including the vendor prefixes next to the normal properties/values for a standardized feature, you can still support older browser versions in which the feature was not yet standardized

Example:

.container {
    /* last one supported by current browser wins */
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    display: flex;
}

You can also automatically include vendor prefixes by using a tool like Autoprefixer

Polyfills

Polyfill = JavaScript that enables certain features in browsers that would not support them otherwise

Can be useful, but polyfills come at a cost (loading + execution time)

Also, it is pretty much impossible to create a CSS polyfill that is not either big, slow or doesn't behave the way it should in all cases. See The Dark Side of Polyfilling CSS.

Testing in different browsers

Useful tool: BrowserStack (or one of its many alternatives)

Resources