How to Use Feature Detection to Know If Browser Supports Border-Radius? (Including IE9)

How to use feature detection to know if browser supports border-radius? (Including IE9)

Got it - the detection array needs 'borderRadius' added - it's case-sensitive.

for How can I replace my old browser check with a feature detection check for border-radius without modernizr?

Simply test for the presence of borderRadius property (using the JavaScript naming conventions for CSS properties) in the style properties of an element, using e.g. the condition

'borderRadius' in document.body.style

This is a simplified version of the code in @Ohgodwhy’s answer.

Note that this performs the exact check requested, for the property border-radius. @thecodeparadox’s answer, and other answers to similar questions elsewhere, test for vendor-prefixed names too, which may or may not be what you want (depending on whether your code uses them as well).

This only tests that the browser recognizes the property. The implementation may still be broken or incomplete.

The best way of checking for -moz-border-radius support

How about this?

var mozborderAvailable = false;
try {
  if (typeof(document.body.style.MozBorderRadius) !== "undefined") {
    mozborderAvailable = true;
  }
} catch(err) {}

I tested it in Firefox 3 (true) and false in: Safari, IE7, and Opera.

(Edit: better undefined test)

how to detect HTML5 and CSS3 support in IE browser?

Neither HTML5 nor CSS3 is an all or nothing proposition. You can't say a browser 100% supports it or doesn't support it as both are a whole grab bag of individual capabilities.

The safe way to check for support is to identify the particular features that you need and use feature detection to see if they are supported or not.

For example, IE9 supports pieces of CSS3, but not CSS transitions. HTML5 consists of many different pieces which are again supported differently by different browsers and different versions of the same browser. There's one set of tests for HTML5 audio, yet another for local storage, canvas, hash change events, web sockets, etc...

The feature detection library modernizr contains a wide array of feature detection capabilities that can let you test for exactly the capabilities your app needs using well-tested code. You can either include the whole library or copy just the pieces you need into your own app.

So, to test for CSS3, you'd have to identify exactly which capabilities you need in CSS3 and identify feature tests for those particular capabilities.

See this article for more info about feature detection for individual HTML5 features.

Show a message if the browser is not internet explorer 9 or greater

HTML

IE 9 and earlier (down to, I think, IE 4) can be identified using conditional comments in HTML.

As @Jost noted, you could use them to warn IE users on IE 8 and earlier, like this:

<!--[if lte IE 8]>
    BANNER HERE
<![endif]-->

However, as IE 10 dropped support for these, you can't use them to identify non-IE browsers.

jQuery

jQuery used to include a browser detection module ($.browser), but it was removed in jQuery 1.9. If you can use an earlier version of jQuery (e.g. 1.8.3) or the jQuery Migrate plugin, then you could use this to show the banner.

if ( !$.browser.msie || $.browser.version < 9 ) {
    // Add banner to the page here.
}

Browser Detection in general

Please note that browser detection is difficult. New browsers are coming out all the time, so any browser support plugin can rapidly become out of date, as can the premise on which you base your warning messages. jQuery's browser detect was the most consistently maintained, and even they gave up on it in the end.

These days, web developers are generally expected to write code that works cross-browser, and use feature-detection to deal with browsers that don't support the features they want to use.

As you're working on a SharePoint site, presumably it's for internal company use, and the company is Microsoft-centric. It sounds like you're developing the site to work in IE, and ignoring other browsers during development.

If you can reasonably expect most of your users to be on some version of IE, maybe the conditional comment warning is enough.

Is it worth specifying certain properties for IE, or just any other older versions? [Backwards Compatible]

Here are my thoughts - before going into detail I have to say that I am a freak when it comes to browser support.

Up until a couple of years back I was trying to support from IE8 and upwards. The reason behind this logic was that people where "trapped" with Windows XP and IE8 was the latest version supported by Windows XP. By trapped I mean that they were cases like government pcs that were too costly to upgrade.

After Windows 7 has matured enough and Windows XP usage dropped, I tried to support IE9 and upwards. This essentially meant that even after useful properties came out (like flexbox) it took me a long time to migrate - so I was building layouts with tables for best browser support, etc.

However, Javascript Frameworks started dropping support for older browsers (including IE9), then CSS frameworks started dropping support. If you consider it for a while, MS itself has dropped support quite some time back. Major mobile companies drop support for their 2-year devices, so why should we support older browsers? As stated in in other answers, it depends on the audience - imagine the CEO of your best client-company having a laptop with Windows XP or other outdated device - wouldn't matter if anyone else used modern browsers..

So, it came down to a point a couple of years back that you have to select between following the stream and being modern or supporting older devices. I am all up for consistency and uniformity of content, so supporting modern features for a few select browsers and dropping them for others would be a no go for me. Flexbox was one of those properties that pushed me to skip older browser support - it vastly helped me reduced markup - thus making maintenance easier. At the same time, even Bootstrap decided to drop support for older browsers, so, must upgrade to keep pace with the competition.

Needless to say, the problem isn't just IE, but was also Android which took up to v4.4 in order for the stock browser to support specific properties - vh, flexbox wrapping, etc

These said, let me give you a straight answer:

• Don't bother with support for IE9 - not even 10. IE10 could be upgraded to 11 on the same OS, so it should be upgraded anyway for security reasons. IE9 is not supported by JS frameworks (eg Ember), lacks CSS3 transitions and other useful properties, like flexbox. Without these your designs would have to take many steps back if you were aiming for design consistency.

• As a sidenote IE10 started supporting their own interpretation of flexbox (sorry about all this persistence with flexbox, but it's one of the most useful properties). This means, that in order to support it properly, you would have to write a lot of CSS. Imagine adding 30kb of minified CSS to support just one browser that is fairly uncommon. Is it worth it?

• Some webkit browsers (like Opera) might still require vendor-specific prefixes for browser versions released 4 years ago -eg for CSS3 transforms. Tbh more important things are broken on such browsers (Opera included) that I would worry about other stuff more. Personally I only use the -webkit- prefix in select cases (eg flexbox properties that have matured quite lately).

• There might be some cases where browser-specific prefixes might come handy even in modern browsers, eg styling a range input or a scrollbar where you have to mess with browser-specific properties to achieve consistency. In such cases specific CSS hacks with vendor prefixes might be required.

As a final note, I would avoid any bleeding-edge properties, eg grid; learn what it does and how it works, but don't use it just yet. You should give a look at https://caniuse.com/ in order to have an idea about CSS properties and browser support.

However, it is up to you to decide and you should make your selection based on the requirements of your project. Two years back I would tell you to support as old as you can... back then you would be able to achieve the same things with different effort, but this is not the case any more. From a point onwards... older browsers can't keep pace.

Modernizr with border-radius, media queries etc

Modernizer uses javascript to add a bunch of classes to the HTML element of your page on page-load.
E.g.

<HTML class="backgroundsize borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients no-cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio localstorage sessionstorage webworkers applicationcache svg">

These classes describe whether an HTML5/CSS3 feature is available to use in the browser the page is viewed on.

This allows you to use more efficient css by only applying CSS3 styles if the browser can handle them (progressive enhancement).

E.g.

.no-audio .music-player {
   display: none
}
.audio .music-player {
   /* styles for music player */
}

Also Modernizer lets you test if these elements are available with it's javascript API.
This is useful for providing fallbacks for older browsers (polyfills).
So for rounded corners you could do:

Modernizr.load({
  test: Modernizr.borderradius,
  yep : /* do nothing */
  nope: 'borderradius.js' /* css3 pie for example */
});

or alternately:

if (Modernizr.borderradius) {
   // do nothing
}else{
    /* script for making rounded corners e.g css3 pie */
}

Or in the CSS only us borderradius if available:

.box {
 border: 1px solid #000; /* all browsers, no rounded corners */
}

.borderradius .box{
  border-radius: 15px; /* only CSS3 compliant browsers get this style */
}

Media queries for older (IE <9) browsers require another plugin such as repond.js

IE9 border-radius and background gradient bleeding

Here's one solution that adds a background gradient, using a data URI to create a semi-transparent image that overlays any background color. I've verified that it's clipped correctly to the border radius in IE9. This is lighter weight than SVG-based proposals but as a downside, is not resolution-independent. Another advantage: works with your current HTML/CSS and does not require wrapping with additional elements.

I grabbed a random 20x20 gradient PNG via a web search, and converted it into a data URI using an online tool. The resulting data URI is smaller than the CSS code for all that SVG mess, much less the SVG itself! (You could apply this conditionally to IE9 only using conditional styles, browser-specific css classes, etc.) Of course, generating a PNG works great for button-sized gradients, but not page-sized gradients!

HTML:

<span class="button">This is a button</span>

CSS:

span.button { 
  padding: 5px 10px;
  border-radius: 10px;
  background-color: orange;  
  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAvUlEQVQ4y63VMQrDMAyF4d/BGJ+rhA4dOnTo0Kn3P4ExxnSoXVQhpx0kEMmSjyfiKAF4AhVoqrvqjXdtoqPoBMQAPAZwhMpaYkAKwH1gFtgG0v9IlyZ4E2BVabtKeZhuglegKKyqsWXFVboJXgZQfqSUCZOFATkAZwEVY/ymQAtKQJ4Jd4VZqARnuqyxmXAfiAQtFJEuG9dPwtMC0zD6YXH/ldAddB/Z/aW4Hxv3g+3+6bkvB/f15b5gXX8BL0z+tEEtuNA8AAAAAElFTkSuQmCC);
  background-size: 100% 100%;

  border: 2px solid white;
  color: white;
}

---

Related Topics