The Design Language is here to help create a consistent brand experience and to get you and your projects up and running as quickly as possible.
We provide a collection of ever-evolving tools, and standards as a baseline starting point for new projects or the flexibility to update styles and assets of existing properties.
Using the supplied assets and documentation will help you to build fast, robust, and adaptive sites quickly. By registering for release notifications we will always keep you updated with the latest improvements.
What’s more, you have now become a part of a global community and we value your input to help us evolve and grow the Design Language.
To find out more about contributing click here.
What do you get with the Design Language?
- Assets that are easily imported from our CDN for global consistency across all Royal Canin digital properties.
- The ability to quickly update and switch asset versions so you’re always ahead of the game and can test the latest updates.
- A robust base of lightweight and scalable styles to build from.
- Boilerplate templates to either drop in or aim for with your CMS rendering system.
- The chance to grow and evolve the Design Language by contributing your own improvements and feedback.
A framework optimisation has been made that adds a prefix to any Design Language related class. For new projects this will be out of the box functionality. As of version 8.4.1 a new CDN reference has been updated to:
<link rel="stylesheet" type="text/css" href="https://d1a19ys8w1wkc1.cloudfront.net/royal-canin.styles.prefix.min.critical.css?v=8-11-9" />
As projects are not always new builds, we’ve supplied various tools to help developers that are working with legacy systems and wish to introduce Design Language into their project.
The Design Language uses the BEMs naming convention for its selectors. This will help stop Design Language styling impacting on legacy components as well as giving good hints to developers as to what the selector targets are used for.
<link rel="stylesheet" type="text/css" href="https://d1a19ys8w1wkc1.cloudfront.net/royal-canin.styles.min.css?v=8-11-9" />
A framework optimisation has been made that adds a prefix to any Design Language related class. This is not a breaking change. The non prefixed classes will however be depreciated by version 9.0.0 so it is highly recommended to upgrade as soon as possible. To upgrade projects use the CDN reference.
<link rel="stylesheet" type="text/css" href="https://d1a19ys8w1wkc1.cloudfront.net/royal-canin.styles.prefix.min.css?v=8-11-9" />
Using BEMs means we can decouple common styles from markup, this enables designers to create visual hierarchies detached from the HTML page semantics.
Some CMSs and WYSIWYGs struggle with adding classes to their markup, to combat this we’ve introduced some classes to add to wrappers when using either WYSIWYGs or groups of elements, which will then inherit the type styles on plain H tags etc.
- Ensure you’ve included the CSS style import before your styles in the page head
- Start including new components
Intentional inheritance and normalization
Excluding baseline styles at a global level
This technique is intended for projects that rely on external libraries or frameworks that may otherwise cause conflicts with Design Language baseline styles.
If low level styles need to be excluded as part of the project, this can be achieved by including the class
rc-no-baselineon the html element.
To apply baseline styles at a block level on projects use the
rc-no-baselineclass on the html element and then on nested block level items use
rc-dl-baselineto apply styles to children.
CSS normalisation can be disabled by including the
rc-no-normclass on the html element.
WYSIWYG/Rich text class
rc-wysiwyg can be added to a parent wrapper which contains content generated by a WYSIWYG or rich text editor, this will allow the correct styles to cascade.
The design language contains a wealth of resources to build or enhance the project you’re working on. There are many different styles of development and we’ve tried to cater for these through different methods of implementation.
These methods include:
Template Heavy CMSs - Using Components straight from the design language
This method is the easiest as you’ll just be reproducing components ‘as is’ with their interaction etc already bound. Simply copy the markup from the supplied code snippet and add your content insertion logic.
The browser support policy has been substantially updated (as of September 2020) to remove support for all versions of IE and a swathe of older browsers.
In fact the new browser support list looks like this…
<pre> <!-- this is a browserlist config extracted from package.json --> "browserlist": [ "last 2 versions", "not IE 11", "not IE_Mob 11", "not dead" ] </pre>
This is a dynamic list that will automatically update as time goes on, as newer versions of browsers are released. The full list of supported browsers, as of writing, now looks like this…
- and_chr 78
- and_ff 68
- and_qq 1.2
- and_uc 12.12
- android 76
- baidu 7.12
- chrome 78
- chrome 77
- edge 18
- edge 17
- firefox 71
- firefox 70
- ios_saf 13.2
- ios_saf 13.0-13.1
- kaios 2.5
- op_mini all
- op_mob 46
- opera 64
- opera 63
- safari 13
- safari 12.1
- samsung 10.1
- samsung 9.2
I think it’s worth noting that this list may require some more refinement as time passes. It would be prudent to check the browser analytics frequently to determine if minor/uncommon browsers can be dropped from the list.
Also, if some of the older legacy browsers can be removed from the list, the site will perform better due to a reduction in the overall size of the asset bundle, which due to the old browser support is more inflated than it probably could be.