Composr Tutorial: Browser version requirements

Written by Chris Graham (ocProducts)
This is a tutorial that details the default browser requirements for visitors to a Composr site. It also contains a lot of historical information, as understanding the development history is useful for understanding the current browser landscape.


The browser wars

Early days:
In the beginning the only mainstream web browser was Netscape Navigator. Microsoft soon realised it needed a browser too, so launched Internet Explorer.

Heavy competition:
Towards the end of the 1990s, after Microsoft started seriously competing with Netscape rather than only matching it, there was a very fast period of Internet development. Microsoft and Netscape both created technologies and submitted them to the W3C for standardisation, and the two browsers developed head-to-head, until Netscape essentially went out of business due to loss of sales when Internet Explorer was bundled with Windows and all ISPs switched to supporting it instead of Netscape Navigator.

The transitory years:
Once Netscape was truly 'buried', Internet Explorer essentially stagnated for many years, left with a lot of rough edges with respect to the standards the W3C had designed and moved forward in the interim. Somewhat in the sidelines, Netscape was rebuilt in Open Source as a browser framework designed specifically to standards (packaged as Mozilla, and then Firefox), and browsers such as Opera and Konqueror also got developed to be of a similar quality. Konqueror essentially became Safari after Apple got involved (Microsoft stopped supporting Mac OS). The renewed competition, and the time for 'the dust to settle' provided the environment for a movement for websites to strictly be designed such that the web technologies they use draw on W3C/JavaScript standards only. This left an environment where Internet Explorer was clearly seen to be inferior in terms of standard compliance, and browser compatibility.

Microsoft returns:
As Microsoft woke up to their popular competition from Firefox, they sped up their development again: releasing Internet Explorer versions 7 through 11, then the new 'Edge' browser.

Google dominates:
Parallel to Microsoft speeding up, Google Chrome (based on Safari's Webkit code) came along and ate up significant market share from both Firefox and Microsoft. Google Chrome now has a big lead because it is a high quality cross-platform browser, heavily promoted by Google. Google forked Webkit to create the Blink engine. Opera threw out their own engine and started using the Blink engine.

Supported browsers

Composr is designed to work on all serious modern browsers. We have official support for:
  • Microsoft Edge (latest version †) (EdgeHTML/Chakra engine)
  • Internet Explorer (common versions †††) (Trident/Chakra engine)
  • Firefox (latest version †) (Gecko/SpiderMonkey engine)
  • Safari (common versions ††) (Webkit/JavaScriptCore engine)
  • Google Chrome (latest version †) (Blink/V8 engine)
  • Android browser (common versions ††) (Webkit/JavaScriptCore engine)
  • Mobile Safari (common versions ††) (Blink/V8 engine)

† These browsers auto-update, so we support the latest versions only.

†† We officially support the last two releases of these browsers. In practice we are likely to accept bug reports for older browsers if they are still widely used by relevant demographics.

††† As IE is particularly widely-used and inflexible we are more explicit about what we will support. Officially it is still the last two releases, but we will accept bug reports for IE9-IE11, and maintain a basic level of frontend support for IE8). The exact supported versions will change over time, as install bases change, and this tutorial will be updated accordingly.

We do not explicitly support the following browsers, but will generally accept bug reports for them:
  • Chromium (the Open Source version of Google Chrome)
  • Opera (a browser with a long history, now based on Blink/V8)
  • Konqueror (an important browser on Linux, the originator of Webkit)
  • Waterfox, Iceweasel, Pale Moon, SeaMonkey (alternative Gecko browsers)

We also provide support for high quality text-mode browsers such as 'Lynx' and browsers designed for people with disabilities. The inherent nature of this support is that it is partial support for an 'accessible' experience, rather than a 'wizz-bang' experience.

Browser testing

Image

BrowserStack are kind enough to provide free testing capabilities to the core Composr developers. It is a high-quality service.

BrowserStack are kind enough to provide free testing capabilities to the core Composr developers. It is a high-quality service.
Browser testing presents the following difficulties:
  1. A machine can only have one Microsoft browser installed.
  2. To test on mobile devices you really should test on a proper mobile device to get a real feel for things.
  3. Safari only works on Mac OS, so you need a Mac.
  4. Internet Explorer only works on Windows, so you need a Windows install.
  5. On browsers such as Google Chrome operating system font rendering differences may mean things lay out slightly differently on different operating systems.

There are a number of approaches that can help you with the above problems:
  • Google Chrome has excellent device emulation, for quick/earlier testing for different mobile devices (not a substitute for proper testing).
  • Internet Explorer lets you run in compatibility modes to test on earlier versions of their engines (imperfect, but useful).
  • IETester lets you test much older Internet Explorer versions (imperfect/unstable, but useful).
  • Virtual Machines let you test different Internet Explorer browsers without needing separate physical machines. Microsoft supply free images to help. They come at a hefty download size though, uses lots of disk space, and using VMs means lots of RAM usage.
  • You can use a commercial online testing system like BrowserStack. BrowserStack host virtual machines for you in the cloud so that you don't need to maintain your own VMs. You can also automatically take mass-screenshots across many devices, and also run automated JavaScript testing (for developers).

JavaScript

JavaScript may be disabled by visitors to Composr. Sometimes users consider it unsafe and disable it (there is a strong case to this, but it is a very limiting thing to do), although by doing so on the modern web, most websites will not work.

If a Composr visitor has JavaScript disabled then certain functionality will not work, such as using the menu editor (appropriate Composr error messages will be given explaining why); in addition, other functionality reduces in ability due to a lack of interactive ability in the web browser: for example, the Comcode hide tag will drop-down to the level where the content isn't actually hidden by default.

The main reason for Composr not requiring JavaScript is that interactive functionality is usually inaccessible for those with certain forms of disability such as blindness. By disabling JavaScript in their accessible browser, or by the browser not supporting it anyway, they may get a better experience.

Cookies

Composr does not require cookie support, although it is recommended. To at least have 'session cookies' enabled is strongly recommended, as otherwise Composr will need to carry additional data along in the URL.

Desktop settings

A screen-resolution of at least 1024×768 is strongly suggested, as this is the minimum resolution that we design the default theme for.

Printing

It is not usually appropriate for a printed webpage to look like it does on the screen. For example, margins would want removing from each side of the site, social media links should not show, background images should be disabled, and so on.
There are 3 approaches to solving this problem that work together:
  1. Browsers automatically disable background images, when printing
  2. CSS provides a mechanism for specifying different display rules for the printed version; Composr makes use of this
  3. Composr has a parameter, wide_print, that will influence some aspects of how pages are put together

The Composr wide_print parameter is activated from either:
  1. The link from the side_printer_friendly block
  2. The link from the main_screen_actions block
  3. Or, a link you've put together yourself

See also


Feedback

Please rate this tutorial:

Have a suggestion? Report an issue on the tracker.

Back to Top