UW Credit Union makes use of certain HTML elements and CSS properties that require the use of the HTML5 doctype. Include it at the beginning of all your projects.
<!DOCTYPE html>
<html lang="en">
...
</html>
UW Credit Union's CSS is mobile first. To ensure proper rendering and touch zooming, add the viewport meta tag to your
<head>.
<meta
name="viewport"
content="width=device-width, initial-scale=1"
/>
<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
/>
You can force Internet Explorer to use the latest rendering mode that it supports by adding the X-UA-Compatible meta tag and setting content="IE=Edge". This will prevent Internet Explorer from rendering your pages in Compatibility mode.
Note: The X-UA-Compatible tag has to be the first <meta> tag in the <head> or it will not work.
<meta
http-equiv="X-UA-Compatible"
content="IE=Edge"
/>
You can provide icons for your site which will be displayed in the browser's address bar and when your site is bookmarked. Add the following <link> tags to the <head> of your document to use these icons.
<link rel="icon" href="/favicon.ico" />
<link rel="shortcut icon" href="/favicon.ico" />
<meta name="msapplication-TileImage" content="//static.uwcu.org/Content/assets/logos/uwcu/icon_u_uwcu_apple_touch.png" />
<meta name="msapplication-TileColor" content="#D50032" />
UW Credit Union uses SCSS source files which are converted via Gulp tasks into CSS upon building the UWCU.Static solution.
Files that are not meant to generate a CSS file, but rather to be imported by other files, are named with a leading underscore.
Each application has a SCSS master file which imports the required files for that application: variables, mixins, functions and partials. Use the uwcu.scss file as a starting point for creating a new application file, and follow the naming convention uwcu-applicationname.scss. For example, for the Web Branch application, the file is named uwcu-webbranch.scss.
A set of variables with default values are included in the SCSS library.
An individual application can override those variables, or create new variables. The variables should be organized in a subfolder named by application.
A set of default mixins and functions are included in the SCSS library.
If an individual application requires mixins or functions for that application only, they can be organized in a subfolder named by application.
Partials include base, layout, template and component styles. An application should only include the partials required for that application.
When including partials for related CSS modules in your application, such as .box and .box-left-cap, the root module is always required and should be imported before the related module.
A CSS bundle is a collection of CSS files which are minified and combined into one file to be delivered to the browser using the functionality provided by .NET's System.Web.Optimization.Bundle. With the use of SCSS, most of the UW Credit Union bundles only contain one CSS file, because the application's master SCSS file uses imports to combine multiple files into one.
Add a link to your bundle in the <head> of your document.
Remember to include a version in the query string. The version makes the file path unique and eliminates caching problems. Without a version, the browser could continue to use a cached version of the bundle file.
The StaticContentVersion value in the Config database is the recommended value to use for the version.
<link href="/static/Content/css/sitename_bundle.css?v=201501014" rel="stylesheet" type="text/css" />
UW Credit Union uses media queries to define styles for printing. We target the medium breakpoint for printing. Any media queries for medium or smaller screens should include print. Media queries for large and extra larges screens should not.
display:block;.
display:none;.
The term "module" is used to refer to a standalone visual element on a page. It can be something simple, such as a button, or more complex, such as a nav bar.
A module should have the same visual styling regardless of where it appears on the page.
For example, if you move .btn-primary out of a .wizard and into a .tile,
its appearance should remain the same.
A module may be a single HTML node or it may contain child elements.
A module name should be a fully spelled out word, or words separated by hypens. In certain cases, we have used abbreviations for longer words, but fully spelled out words are preferred.
The name of the module, followed by an underscore is the naming convention for module children.
Using specific class names for module children, as opposed to using element selectors, allows for greater flexibility in markup. For example:
For variations of a module that involve distinct visual or structural differences which significantly affect child elements, if any, the module root name should be used, followed by hypen-seperated keywords. The module root name is typically the most basic type of a particular module, such as .list-group or .box.
Child elements always use only the module root as a prefix.
For small variations to visual style of a module, including sizes, spacing, colors, borders, etc., a keyword modifier should be used. For example:
It's important to note that keyword modifiers are different than utility classes. Utility classes change the value of a single property, such as background-color, and can be used on any module to override its default value for that property. Keyword modifiers must be suported by the module to have any effect.
Refer to the documentation for a module to determine which keywords it supoprts.
The list of reserved keyword modifiers includes, but is not limited to:
In situations where a parent module needs to know about the presence of a child module to accommodate it in some way, the .has-* keyword should be used. For example:
Modules and/or module children can be combined, if desired, to work on the same HTML node to take advantage of styling from both modules.
In some cases, presence within a particular parent may affect the appearance of a module. This is called scoping. Scoping should be used sparingly.
For example, in Web Branch's .header-main, the .prepend-icon styling is modified slightly to fit the space better. The CSS scoping looks like this:
UW Credit Union aheres to the following guidelines when authoring SCSS files.
Use nesting to aid code readability. Limiting nesting blocks to 3 levels is recommended. If more nesting is required, break a section out into a new root level block.
DoUse "&" for clarity when nesting to create a descendent selector, even though it's assumed and not necessary for the SCSS compiler.
DoUse nested media queries to keep all style rules for a single selector in one place. This results in slightly more CSS after the SCSS file is processed. However, it makes it easier to edit style rules when they are all in one place, so the benefit outweighs the small increase to the final file size.
DoThe UW Credit Union naming convention for CSS modules makes a modifying the ampersand an efficient solution for responsive classes and children since many of them start with the same prefix, such as .indent and .indent-sm, or .tile and .tile_head.
Remember to avoid nesting greater than 3 levels deep.
UW Credit Union only extends placeholder classes, such as %btn, to avoid unknowingly making changes to a class that is being extended elsewhere. Placeholder classes are not ouput to CSS unless they are used in another class with @extend. Extending should only be used when classes are highly related. For example, .btn-primary and .btn-hollow can extend a %btn class. However, .box and .list-group, should not extend something like %clearfix. See mixins to solve that type of problem.
UW Credit Union uses mixins to create reusable groups of style rules that perform a sepcific function, such as creating a self-clearing item. Mixins should be focused on a single, reusable piece of functionality that is not specific to any particular CSS module. They should not be used to establish the base style rules for related css modules. See extending to solve that type of problem.
ExampleGlobal mixins to be used by many files are saved in the mixins folder.
Local mixins, to be used in only one file, should be included at the top of the file.
Local Mixin ExampleWhen a keyword modifier class is applied to a module parent, UW Credut Union organizes the rules as follows:
This ensures that all rules which affect the styling of an element with a particular class are grouped together in the SCSS file, which makes it easier to debug and edit the style rules.
DoWhen the style of a module is changed because of its placement within another module, style rules should be included with the module, not the parent module. For example, if .reveal-triggerreveal-trigger needs special treament when it's inside .list-group_item, those style rules should be nested in the .reveal-trigger rule block.
Rules for children of modules with variations should be included together, nested within the child class, to make it easier to debug and edit the style rules for that class. For example, when .tile_body rules vary based on the parent — .tile or .tile-convertible — the rules should be nested within the block for .tile_body.