-
Notifications
You must be signed in to change notification settings - Fork 13
CSS
There are three types of CSS files in this project:
-
Page stylesheets - There's one of these per page; they live next to the page's
.jsx
file and share the same name. -
Component stylesheets - There's one of these per component; they live next to the component's
.jsx
file and share the same name. - gu-sass stylesheets - These contain CSS generic to the entire site, e.g. accessibility, colour palette, fonts. Ideally these consist of function and mixins, to be used in either of the other types of stylesheets described above.
To add a new stylesheet to the project simply create the file and then import
it into your page or component. Webpack will resolve this and add it to a CSS file named after your bundle's entry point.
Example
π myComponent.jsx
import React from 'react';
import './myComponent.scss'; /*looks weird at first*/
Currently in support-frontend
there are two types of components.
Shared component: Components that are used in more than one page, they are located inside the global components
folder. These should only contain rules which are context-independent. For instance, font sizes, colours, padding (since it's internal), margins of child elements. But margin on the parent, for example, should probably be avoided, because it's presupposing that it will be used in a particular place. This kind of positional styling should happen in the page-level CSS.
Non-shared component: Components specific to a page which are not used outside that page. Typically located inside the components
folder of a certain page.
The classes should follow the BEM convention system. The shared components should have the component
prefix in their class names.
Example
Bad
#double-heading {
font-size: 22px;
}
h2 {
color: gu-colour(neutral-1);
}
Good
.component-double-heading {
font-size: 22px;
}
.component-double-heading__subheading {
color: gu-colour(neutral-1);
}
Nesting should be avoided. The only case where it is justified is inside a CSS file of a page, where we nest the entire style of a page inside the page's id to avoid conflicts with other pages' rules.
Example
Bad
.component-cta-link {
width: 200px;
.component-cta-link__text {
font-family: $gu-egyptian-web;
}
}
Good
.component-cta-link {
width: 200px;
}
.component-cta-link__text {
font-family: $gu-egyptian-web;
}
The .scss
file of examplePage
will have the following shape:
#example-page {
.component-example-component{
// Specific rules for a shared component in this specific page
}
}
When we add a shared component into a page, sometimes we would like to add extra CSS rules for that component. Those rules should be put inside the CSS file of a page. Additionally, we should not overide any rule of the shared component. If we find ourselves overriding a lot of CSS rules, that is an indicator that we probably should move those rules out of the shared component's css file and we should place them inside the pace specific file.
As an example, a shared component which will have a different position (determine via margin-right
) in each page, should not have a margin-right
value in the shared component'css file but inside each specific page.
When we write css
files we should indent them using two-spaces and avoid other styles such as tabs or four-spaces.
Example
Bad
.component-cta-link {
width: 200px;
}
Good
.component-cta-link {
width: 200px;
}
As an example consider the following CSS for a shared component called DoubleHeading
.
.component-double-heading {
font-size: 28px;
line-height: 32px;
}
.component-double-heading__heading {
font-weight: 900;
font-family: $gu-egyptian-web;
color: gu-colour(neutral-1);
}
.component-double-heading__subheading {
color: gu-colour(neutral-1);
font-family: $gu-text-sans-web;
font-weight: normal;
font-size: 20px;
line-height: 24px;
@include mq($from: phablet) {
font-size: 24px;
line-height: 28px;
}
}
Note that we avoid nesting, we use a BEM approach and we prefix the classes with component
.
Yes! But since we still support IE11, there are a few caveats (courtesy of caniuse.com):
- IE11 requires a unit to be added to the third argument, the flex-basis property. see MSFT documentation
- In IE11, containers with
display: flex
andflex-direction: column
will not properly calculate their flexed childrens' sizes if the container hasmin-height
but no explicitheight
property. See bug. - IE 11 does not vertically align items correctly when min-height is used see bug
- Redux Glossary
- Why Redux Toolkit?
- Writing state slices with Redux Toolkit
- Handling action side effects in Redux
- Presentational and Container Components
- Scoped actions and reducers
- Server Side Rendering
- Form validation
- CI build process
- Post deployment testing
- Post deployment test runbook
- TIP Real User Testing
- Code testing and validation
- Visual testing
- Testing Apple Pay locally
- Test Users
- Deploying to CODE
- Automated IT tests
- Deploying Fastly VCL Snippets
- End-to-end Tests with Playwright
- Archived Components
- Authentication
- Switchboard
- How to make a fake contribution
- The epic and banner
- Environments
- Tech stack
- Supported browsers
- Contributions Internationalisation
- Payment method internationalisation in Guardian Weekly
- Print fulfilment/delivery
- Updating the acquisitions model
- Runscope testing
- Scala Steward for dependency management
- Alarm Investigations
- Ticker data
- Ophan
- Quantum Metric
- [Google Tag Manager] (https://github.com/guardian/support-frontend/wiki/Google-Tag-Manager)