A friendly guide for building cross-browser websites
The promise of the web is to allow anyone to access content using any browser on any device. By building cross-browser compatible websites we ensure that our content, tools, and resources remain available for all that seek them, whether they be the American public or Bureau staff. We seek to esnure this open accessibility by designing and coding for unknown client environments, and continually testing our products in as many environments as is practical.
Cross-browser support doesn't come from a single place; it takes a combination of tools and best practices. We've outlined a few high-level topics here, but don't let that stop you from reaching further into your toolset.
We build features for our users, not based on our own technology interests or whims. When looking at a new feature we first start by asking ourselves how will it benefit the user compared to our current offerings and what negative implications will we need to work around. Afterall, what good is a feature if our users are unable to access it. By keeping our users in the forefront of our design and development decisions, we can assure ourselves our work is in their best interest and ensure a level of experience for all.
We always prefer to build features that work for any browser. When that's either impossible or impractical, we start with a basic experience, and build additional features on top. For example, when a user submits a form that returns a response, the base experience would be to reload the page (or navigate to a response-specific page) with the server's response. To improve the experience, we could submit the form via an Ajax request and inject the response into the page. We could then remove the logic to handle the servers response on page load to reduce our own technical debt, but what about users that can't access the scripting? Rather than creating a broken experience, we ensure the default behavior continues to work unimpeded, and then build upon it to improve the experience for the browsers that can handle it.
- Scripting: We do not serve interactive scripting to IE 8 but we do deliver analytics via scripting.
- Icons: We currently use icon fonts to deliver scalable icons. Browsers that do not support icon fonts unfortunately do not receive backups but we try to always pair icons with text to ensure a user can continue to interpret a page's content.
Thankfully the world has created tools to help us track and polyfill disparities between browsers. We rely on a handful of of these tools to help us provide a level of backward compatability for modern features. As mentioned above, this doesn't necessarily mean feature parity. Where it's impossible or impractical to implement a modern feature, we fallback to standard practices for that browser. For example, we do not deliver interactive scripting for Internet Explorer 8, but we do ensure that default browser features continue to work so users that can't or don't want to upgrade continue to have access to the site and our content.
Each project has its own configuration depending on the requirements of the tools and features that project depends on. As a general rule, we strive to cover the following browser list in each project.
We configure Autoprefixer and Babel to support the following list of browsers:
- Latest 2 releases of all browsers including:
- Chrome
- Firefox
- Safari
- Internet Explorer
- Edge
- Opera
- iOS Safari
- Opera Mini
- Android Browser
- BlackBerry Browser
- Opera Mobile
- Chrome for Android
- Firefox for Android
- Samsung Internet
http://browserl.ist/?q=last+2+versions%2C+Explorer+%3E%3D+9
As well as additional Autoprefixer support for:
- Internet Explorer 9
- Internet Explorer 8
http://browserl.ist/?q=last+2+versions%2C+Explorer+%3E%3D+8
We use automated tests with a headless version of Chrome to ensure the majority of the site works as expected. For manual testing, we realistically test these projects locally or in a virtual environment with the following list of browsers:
- Chrome
- Firefox
- Safari
- Internet Explorer 8, 9, 10, and 11
- Edge
- iOS Safari
- Chrome for Android
We use a mix of Sauce Labs and localtunnel to manually test our site. Be sure to review both the testing and accessibility guides when reviewing sites locally.
See #171 for details on testing with Sauce Labs.
To test changes using your CFPB issued iPhone or other devices, you'll need to use localtunnel to expose your localhost. Start by installing localtunnel if you haven't already.
npm install -g localtunnelStart your project's localhost and in a separate tab run lt --port 8000
editing the port value to match your localhost setup. This will create a
temporary public URL that can be accessed from any device on any connection.
Navigate to the URL from your device and test to your heart's content, the URL
will remain active as long as the instance is active (keep this in mind, don't
leave it running forever). Use ctr + c to terminate the connection.
- consumerfinance.gov
- Design System
- Paying for College
- Retirement
- Complaint
- eRegs
- Salesforce/Mosaic/Submit a complaint app/Complaint portal
- cfpb-chart-builder
- HMDA Platform
Autoprefixer parses our CSS and adds vendor prefixes to rules where necessary using reported feature support by Can I Use. For more information, visit the [Autoprefixer documentation site] (https://autoprefixer.github.io/).
Babel compiles our ES6 JavaScript where necessary for the browsers that either don't support or have limited support for ES6 features. For more information, visit the [Babel documentation site] (https://babeljs.io/).
Interactive scripting is additions or adjustments to the browser's default response to a user's interaction. Examples are the Mega Menu, Expandables, Notifications, and Sortable Tables.
Non-interactive scripting is tooling and analytics that we utilize as developers but that remain hidden to the end user. Examples are Modernizr and Google Analytics.