Skip to end of metadata
Go to start of metadata

DOCTYPE and HTML validation

We use the XHTML 1.0 Transitional DOCTYPE. All pages should validate with 0 Errors and 0 Warnings. Nested HTML tags are indented by four spaces.

HTML5

We do not currently use the HTML5 Doctype, nor any of the new elements but should transition to this throughout 2013.

Page grid

We use a fixed-width 12-column, 960px grid. Further grid details are in our Visual Identity.

Browser Support

Most on-campus site visitors use IE. Externally there is a 25% equal share to IE, Firefox, Chrome and Safari. We currently use <meta http-equiv="X-UA-Compatible" content="IE=7" /> to force IE 7 mode for later versions of Internet Explorer but will drop this during 2013.

Pages should basically render in IE 6 and information on the page should be available to visitors but full functionality on a par with more modern browsers is not a requirement.

Fuller information is on our Browser support statement.

CSS, Coding Style and CSS validation

We use Eric Meyer's Reset CSS and provide our own base CSS after it.

Our CSS coding standards, including selector targeting, naming and indentation are specified in CSS and SASS coding conventions.

Our main CSS should be in a single CSS file. Per-page CSS should go in separate CSS files named appropriately.

JavaScript

All of our pages include jQuery 1.8.2 by default. When writing JavaScript we indent by four spaces. Per-page JavaScript should be included via separate files rather than inline and we encourage the use of unobtrusive JavaScript.

We have no defined JavaScript coding conventions but try to follow the ones on http://na.isobar.com/standards/#_javascript

We have a set of defined interaction patterns for applying JavaScript effects on pages.

Screen resolution

Almost 100% of external visitors to our site have a horizontal resolution (width) of greater than 1024px. The width of our pages is dictated by the Visual identity.

Two-thirds of external visitors to our site have a vertical resolution (height) of 800px or lower.

We don't currently capture how much of this area is used by the browser but we can assume that the initially visible area of our pages is significantly less than this, so pages should be designed accordingly using tools like Google Browser Size to ensure that the key aspects of the page are obvious to the visitor when the page is loaded. A viewport of 600px in height is a sensible guide.

Page loading time

In May 2010 the average web page takes up 320KB according to Google. We use this as a guideline for creating our pages.

We use the statistics tab of YSlow for evaluating the total size of served pages.

No page may take longer than 3x the average loading time of the University homepage. In November 2010 the median of ten loads of the homepage with webpagetest is 3.624s. The detailed results are here.

For testing the performance of pages off-campus we use http://www.webpagetest.org testing from Chicago, IL at DSL speed. The page load time data should be used in relative terms, rather than absolute, but the Waterfall image can be used to identify resources which are too large or load too early in the page lifecycle (such as large JS files which could be loaded at the end of the <body> rather than in the <head>).

In addition to the above, we follow several good practices:

  • appropriate image optimisation
  • appropriate delivery of CSS for the correct media
  • disabling JS when not in use (such as CrazyEgg)
  • ensuring that images, JS and HTML are loaded at appropriate times during the page lifecycle

Based on this information from the author of jQuery, we do not pack our JS.

  • No labels

4 Comments

  1. Is something about mobile support needed?

    1. According to Analytics, mobile usage is about 2% of total for both external users and overall.

      1. Although this only includes browsers which can run the JS in the first place of course, and not all mobile user-agents visiting the site.

  2. Unknown User (ccsya)

    Jakob Nielsen has some guidelines about response time limits :

    The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

    • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
    • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
    • 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.