CSS Guidelines

CSS Style Development / Design Guidelines

The use of raw HTML should be sufficient to create any element on the Interactive Investor website, as the CSS style sheet controls all spacing, layout and style information, without the need for inline CSS.

This purely helps to facilite the requirement to manage several 'skins' on a range of sites powered by universal components, and the ability to modify and evolve the style sheets as necessary.

Current Issue

Due to legacy code on the site, there is a marked difference between design and development pages. Different parts of the site are written in different languages, and use different templates. Although the goal is to bring all these elements closer together, currently any changes to the existing style sheet can have adverse affects to different parts of the site, and as such require varying degrees of testing.

Goal

Wireframes and designs should be implemented with the minimal effort, controlled via a global style sheet that has been agreed by both design and development, and the aforementioned style sheet should be easily updatable by in terms of rolling out look and feel tweaks across the existing site(s) as necessary. Design needs to be aware of all technical limitations before embarking on a new project, and in the same vein development need to keep design aware of such findings.

Key points

• Always use semantic HTML
• HTML design should always validate as per W3C standards, to ensure ease of production
• Only use DIVs for layout – tables should only be used for tabular data
• Use correct Table HTML structure (caption, thead, tbody, tfoot)
• No inline CSS – although can occasionally be used to achieve a particular effect inside a reusable component, i.e. always float right or fixed width, rather than creating a new style for each component – but should be limited to only one or two attributes
• As the requirement appears for CSS styles to evolve, these should be tackled on a style by style basis as an individual project, and tested across the site in development before live implementation
• Design suggests a monthly or two monthly review of the style sheet between design and development that will produce some actions to tidy things up or fix existing bugs with styles – perhaps this could be solved with a monthly email from design with the ‘top bugs’?
• Some degree of accessibility has already been achieved within the HTML – what’s the next rung?

New style / element rules

• New colors / updates to colors should be kept to same contrast levels inside the existing palette to minimize color shift issues in other areas of the site
• List elements should never use list-style-image, but instead background-image with padding for greater degree of control and cross browser/platform compatibility
• Elements should always space themselves via margin-bottom for consistent display
• Buttons should always stay the width of the button text
• Site typography needs to follow a predefined format – design suggests type rules of margin: 5px 0; on P elements, and margin: 10px 0; on H class elements
• Links need to be obvious on the site, either through the use of underline, border-bottom or a unique color

CSS Consolidation/clean up

We were facing issues related to slow page load. Then we found out that extra CSS on each page is one of the main reasons behind slow page load. Mainly the files which are hurting mostly are nav_and_footer.css, global.css and global_2017.css. These files were part of the most top pages and contain a lot of extra css lines. Which was causing slow page load issues.

Solution

We decided to create the module specific CSS files which only contains css which is used to that specific module/page. In this way we can avoid a lot of extra css.

Implementation

By using the Chrome dev tools like Coverage and Lighthouse we found out how much css is being used and how much extra css is loaded. This same practice needs to perform against each custom css file for all module. and make separate css files for each module. You can find Coverage Dev tool by Ctrl+Shift+P and after performing all the responsive actions like opening pop-ups tool-tips drop-downs and modals etc it will show which css is needed for this specific page.We can copy that and test if any thing is missing or not loading properly then we find out by inspecting elements. In First Version we target the top eight module

• Index
• Directory
• Articles
• Forum
• Kudoz
• Profile
• Glossaries
• Jobs

All the modules have their separate CSS file for nav_and_footer, global and global_2017. In future If we need to change or add any css in these mentioned above modules we suppose to use their module specific CSS