Browser & Device Agnostic
In order to deliver a proper experience to the most users, I rely on a few key principles.
- Webpages are files written in languages (code) that browsers and devices must read and render
- Each browser and device combination can read and render a specific set of code
- Browser bias kills developer productivity
Essentially all browsers read and render HTML and basic CSS. Some browser and device combinations will forgive mistakes, and others will render exactly the code you wrote – nothing more, nothing less. Clean error free code generally renders the same in all browsers and devices, because there is no guess work regarding mistakes.
The key caveat, depending on the language, some browser and device combinations will not render some code, because they simply can not read it. Programing languages, just like other written and spoken languages, have a bit of a dialect.
In specific cases, we must included every version of the specific code in order for every browser and device combination to read and render it, OR we must deliver a back up for browsers and devices that do not recognize the code we have written.
A common example is border radius. Border radius allows us to curve the corners of something. In order to create a 10px radius across all browsers, we must include more than one version of the same rule.
- -webkit-border-radius: 10px;
- -moz-border-radius: 10px;
- border-radius: 10px;
It is not that a browser is better or worse becasue it reads and renders one version of border radius. Rather, we should as developers know what rules can be used where and how they must be written. There are many tools, such as Can I Use, that will tell use with precision what code will be rendered by what browser. To not take the time to check code compatibility can only be regarded as laziness or ignorance.
There are no bad browsers, only bad developers
Many developers dislike Internet Explorer and Edge, but this is a fairly shortsighted view. The problem is not IE or Edge, it is that most developers are ignoring errors and not checking their work.
I can not tell you the number of times I have been asked for help concerning a cross browser or mobile specific issue. My first step is always to check for HTML errors using the W3C HTML Validator. When I suggest that we first clear all HTML errors, I am often told “those don’t matter”, which could not be further form the truth.
I could not stress enough, as you build, regularly check your HTML for errors, and correct them as you go. HTML is the basic foundation of web pages and HTML errors cascade in a way that cause headaches. Not only will fixing HTML errors correct cross browser problems, but pages without errors also load faster.
Furthermore, go one step further and check for cross browser compatibility as you build. Using a service such as Browserstack is affordable and convenient.
Most developers create an entire build, working in one, or maybe two browsers (Chrome and or Firefox). Once they have completed something they love, they then check Internet Explorer or Edge, only to discover it does not look or work the same. There is no should be no surprise that IE does not render a website well, when the website has not been developed with it in mind.
Rather than exploring why IE looks or work differently, developers will dismiss IE as a bad browser, and focus their efforts on convincing the client of the same. Developers take this approach becasue to correct a full build can be rather time and effort intensive. However, if they had taken the time to incrementally check IE during the build, they could have found small differences and addressed them as they went.
My philosophy on cross browser, cross device development
1. There are no bad browsers.
2. Error free and concise code, with a bit browser specific languaging, and a sprinkle of fall back code will render a good experience in nearly any browser and device combination.
Common page errors
- Spell check
- No broken links
- No broken images
- Able to load all resources
- No JS errors
- No CSS errors
- No HTML errors
- Alternative text for all images
- Natural width and height for all images
- Correct use of HTML5 Elements
- Correct structure and syntax
- No typo’s / space errors
- Escape all characters
- No use of obsolete code
- No duplicate ID
A lack of spelling errors not only shows professionalism, it tends to give a small bump in search. Consider that search bots also read and judge the reading level of the content. Try Respelt.com to quickly check any web page or website for spelling errors.
Broken links are a bad human experience, but also negatively effect search bots. Search engines want to find and index every page of the internet. A broken link is then a break in the chain that is the world wide web.
Broken images are most often the result of an incorrect source URL. When a browser can not load an image, it not only loads the page more slowly, but it causes larger usability issues.
Most often a browser can not load a resource because it is being called from an insecure resource, but on a secure page, or it is being called from a separate domain. Anytime a resource can not be loaded, the web page will load more slowly, but will inevitably load with a poor experience.
Pages with HTML errors take longer to load and often have a poor human experience. HTML errors are the main source of “broken” pages and poor cross browser performance. You can check any web page using the W3C Markup Validation Service
A final thought on HTML errors. Webpages are HTML documents that are read and rendered from top to bottom. Small errors at the top of the document often cascade down the document and cause much larger issues further down the document (web page).
Common HTML Errors:
Alternative text on all images is required by HTML documents and is intended for the visually impaired.
Natural width and height on images makes pages load faster and maintains the page structure if the image does not load.
Correct use of HTML5 elements is key. The incorrect use of HTML5 elements is far worse than not using HTML5 elements.
Incorrect syntax and structure is far more common than it should be. Putting items in the wrong place or order makes web pages load slow and or break – particularly in older browsers.
Typos or space errors can cause a havoc. Something as little as a missing space can confuse the computer.
Not escaping all characters can also confuse the computer.
Most browsers will typically render obsolete code, but the name implies it all. Replacing obsolete code is the bare minimum of keeping code up to date.
ID’s by definition are unique objects on a page, and therefore can not appear more than once. If an ID appears on a page more than once the browser is unable to determine which object the ID is referring to.
Classes are applied when a type of object appears more than once on a page. A very important and basic programing flaw, many developers over look duplicate ID’s. Duplicate ID’s should never ever be allowed into production.
Want to learn more? Check out my full checklist for website quality assurance and quality control.