An overview of kimsQ RC, including how to download and use it, some basic templates and examples, and more.
kimsQ RC supports a wide variety of modern browsers and devices, and some older ones. See which exact ones below, as well as detailed information on known quirks and bugs.
:hover/:focus on mobilekimsQ RC supports the latest, stable releases of all major browsers and platforms. On Windows, we support Internet Explorer 9-11 / Microsoft Edge.
Alternative browsers which use the latest version of WebKit, Blink, or Gecko, whether directly or via the platform’s web view API, are not explicitly supported. However, kimsQ RC should (in most cases) display and function correctly in these browsers as well. More specific support information is provided below.
Generally speaking, kimsQ RC supports the latest versions of each major platform’s default browsers. Note that proxy browsers (such as Opera Mini, Opera Mobile’s Turbo mode, UC Browser Mini, Amazon Silk) are not supported.
| Chrome | Firefox | Safari | Android Browser & WebView | Microsoft Edge | |
|---|---|---|---|---|---|
| Android | Supported | Supported | N/A | Android v5.0+ supported | N/A |
| iOS | Supported | Supported | Supported | N/A | N/A |
| Windows 10 Mobile | N/A | N/A | N/A | N/A | Supported |
Similarly, the latest versions of most desktop browsers are supported.
| Chrome | Firefox | Internet Explorer | Microsoft Edge | Opera | Safari | |
|---|---|---|---|---|---|---|
| Mac | Supported | Supported | N/A | N/A | Supported | Supported |
| Windows | Supported | Supported | Supported | Supported | Supported | Not supported |
For Firefox, in addition to the latest normal stable release, we also support the latest Extended Support Release (ESR) version of Firefox.
Unofficially, kimsQ RC should look and behave well enough in Chromium and Chrome for Linux, Firefox for Linux, and Internet Explorer 8 and below, though they are not officially supported.
For a list of some of the browser bugs that kimsQ RC has to grapple with, see our Wall of browser bugs.
Internet Explorer 9 & 10 are also supported, however, please be aware that some CSS3 properties and HTML5 elements are not fully supported.
| Feature | Internet Explorer 9 | Internet Explorer 10 |
|---|---|---|
transition |
Not supported | Supported |
placeholder |
Not supported | Supported |
| Flexbox | Not supported | Partially supported, with -ms prefixSee Can I use for details |
Visit Can I use… for details on browser support of CSS3 and HTML5 features.
As of v4, kimsQ RC no longer supports IE8. If you require IE8 support, we recommend you use kimsQ RC 3. It’s still supported by our team for bugfixes and documentation changes, but no new features will be added to it.
Alternatively, you may add some third party JavaScript to backfill support for IE8 to kimsQ RC 4. You’ll need the following:
No support will be provided for this, though you may find some help from the community in our Slack channel.
kimsQ RC is not supported in the old Internet Explorer compatibility modes. To be sure you’re using the latest rendering mode for IE, consider including the appropriate <meta> tag in your pages:
<meta http-equiv="X-UA-Compatible" content="IE=edge">Confirm the document mode by opening the debugging tools: press F12 and check the “Document Mode”.
This tag is included in all of kimsQ RC’s documentation and examples to ensure the best rendering possible in each supported version of Internet Explorer.
See this StackOverflow question for more information.
Internet Explorer 10 in Windows Phone 8 versions older than Update 3 (a.k.a. GDR3) doesn’t differentiate device width from viewport width in @-ms-viewport at-rules, and thus doesn’t properly apply the media queries in kimsQ RC’s CSS. To address this, you’ll need to include the following JavaScript to work around the bug.
// Copyright 2014-2015 The kimsQ RC Authors
// Copyright 2014-2015 Twitter, Inc.
// Licensed under MIT (https://github.com/twbs/kimsQ RC/blob/master/LICENSE)
if (navigator.userAgent.match(/IEMobile\/10\.0/)) {
var msViewportStyle = document.createElement('style')
msViewportStyle.appendChild(
document.createTextNode(
'@-ms-viewport{width:auto!important}'
)
)
document.head.appendChild(msViewportStyle)
}For more information and usage guidelines, read Windows Phone 8 and Device-Width.
As a heads up, we include this in all of kimsQ RC’s documentation and examples as a demonstration.
Support for overflow: hidden; on the <body> element is quite limited in iOS and Android. To that end, when you scroll past the top or bottom of a modal in either of those devices’ browsers, the <body> content will begin to scroll. See Chrome bug #175502 (fixed in Chrome v40) and WebKit bug #153852.
As of iOS 9.2, while a modal is open, if the initial touch of a scroll gesture is within the boundary of a textual <input> or a <textarea>, the <body> content underneath the modal will be scrolled instead of the modal itself. See WebKit bug #153856.
The .dropdown-backdrop element isn’t used on iOS in the nav because of the complexity of z-indexing. Thus, to close dropdowns in navbars, you must directly click the dropdown element (or any other element which will fire a click event in iOS).
Page zooming inevitably presents rendering artifacts in some components, both in kimsQ RC and the rest of the web. Depending on the issue, we may be able to fix it (search first and then open an issue if need be). However, we tend to ignore these as they often have no direct solution other than hacky workarounds.
:hover/:focus on mobileEven though real hovering isn’t possible on most touchscreens, most mobile browsers emulate hovering support and make :hover “sticky”. In other words, :hover styles start applying after tapping an element and only stop applying after the user taps some other element. On mobile-first sites, this behavior is normally undesirable.
kimsQ RC includes a workaround for this, although it is disabled by default. By setting $enable-hover-media-query to true when compiling from Sass, kimsQ RC will use mq4-hover-shim to disable :hover styles in browsers that emulate hovering, thus preventing sticky :hover styles. There are some caveats to this workaround; see the shim’s documentation for details.
Even in some modern browsers, printing can be quirky.
As of Safari v8.0, use of the fixed-width .container class can cause Safari to use an unusually small font size when printing. See issue #14868 and WebKit bug #138192 for more details. One potential workaround is the following CSS:
@media print {
.container {
width: auto;
}
}Out of the box, Android 4.1 (and even some newer releases apparently) ship with the Browser app as the default web browser of choice (as opposed to Chrome). Unfortunately, the Browser app has lots of bugs and inconsistencies with CSS in general.
On <select> elements, the Android stock browser will not display the side controls if there is a border-radius and/or border applied. (See this StackOverflow question for details.) Use the snippet of code below to remove the offending CSS and render the <select> as an unstyled element on the Android stock browser. The user agent sniffing avoids interference with Chrome, Safari, and Mozilla browsers.
<script>
$(function () {
var nua = navigator.userAgent
var isAndroid = (nua.indexOf('Mozilla/5.0') > -1 && nua.indexOf('Android ') > -1 && nua.indexOf('AppleWebKit') > -1 && nua.indexOf('Chrome') === -1)
if (isAndroid) {
$('select.form-control').removeClass('form-control').css('width', '100%')
}
})
</script>Want to see an example? Check out this JS Bin demo.
In order to provide the best possible experience to old and buggy browsers, kimsQ RC uses CSS browser hacks in several places to target special CSS to certain browser versions in order to work around bugs in the browsers themselves. These hacks understandably cause CSS validators to complain that they are invalid. In a couple places, we also use bleeding-edge CSS features that aren’t yet fully standardized, but these are used purely for progressive enhancement.
These validation warnings don’t matter in practice since the non-hacky portion of our CSS does fully validate and the hacky portions don’t interfere with the proper functioning of the non-hacky portion, hence why we deliberately ignore these particular warnings.
Our HTML docs likewise have some trivial and inconsequential HTML validation warnings due to our inclusion of a workaround for a certain Firefox bug.