Closed loganfranken closed 3 years ago
I (just) merged the code snippets WYWSIWYG site update that limits the syntax formatting supporting languages and sets the default highlight theme to github
site-wide as discussed/shown in the 08-04-2020 WSG meeting.
I don't think there's anything to fix, but you may want to double check that you've selected SCSS or CSS for the highlighing snippets, or if the highlighting appears wrong, then default to plaintext
as appropriate.
Thanks!
Thanks @tenken!
I migrated this content: https://dev-webguide-ucsb-edu-v01.pantheonsite.io/css https://dev-webguide-ucsb-edu-v01.pantheonsite.io/design/accessibility
https://dev-webguide-ucsb-edu-v01.pantheonsite.io/css While all that info does apply, I too am thinking of the direction we would like go with this. I'm thinking of eliminating the code snippet info and keeping the content in short bursts of statements with a supplying Header label. I think that way we can update the page easier to include the latest info on tools of the trade, as well as link out to sites like www.caniuse.com or Mozilla docs :( for easy reference. Look to mimic the writing style of this page: https://dev-webguide-ucsb-edu-v01.pantheonsite.io/accessibility/guidelines
reviewed and added new row for Frameworks like Material UI or Tailwind.
384
Legacy Page https://webguide.ucsb.edu/css/
Location in New Hierarchy https://dev-webguide-ucsb-edu-v01.pantheonsite.io/development/css
Looking over this page, all of the advice seems relevant, but I'm not sure if this is the direction we want for the web guide or not?
I only have a couple possible edits:
As a general rule of thumb, the content of your website should have a logical flow regardless of any styling. In other words, a user who has disabled CSS should still be able to understand your website's content.
More specifically, websites should not convey information by color alone. This is especially important for users who are color blind or who use a screen reader.
CSS techniques and technologies are evolving rapidly. Website developers should try to understand the tradeoffs involved with their choices (loading one vs. many stylesheets, performance vs. organization, basic CSS vs. minified/compressed/compiled CSS). Website developers may want to consider using stylesheet minifiers, compilers, or other technologies (Less, Sass, Compass, etc.) to make their CSS more consistent.
There may be inconsistencies between how the various browsers interpret CSS and display your website to users. This could be a result of a lack of support for certain CSS properties as well as conflicting or inconsistent implementations of CSS properties. You will need to test in the various browsers to ensure that your website design is cross-browser compatible.
Declarations
Use shorthand properties
Shorthand properties refer to combining multiple CSS property declarations into a single CSS property. Not only do shorthand properties reduce the size of a CSS file, but they also make CSS more readable.
This long rule declaration can be rewritten as:
Note the use of the shortened hex code (
#FFF
instead of#FFFFFF
) and the shortened zero pixel dimensions (0
instead of0px
).Always use external stylesheets
Always place CSS in an external stylesheet linked to a web page within the document head. These external stylesheets can be cached by the browser and also uphold the separation of presentation and content principle:
Avoid placing CSS rules in a style block directly within the page:
Similarly, avoid using inline styles:
These inline styles can not be overridden by standard CSS properties without the use of the
!important
keyword. This also clouds your markup file with presentation information, violating the separation of content and presentation principle.An exception to this rule is when elements are being manipulated by client-side scripting. However, even in this situation, the designer and JavaScript developer should attempt to contain the CSS properties in a class and then programmatically assign this CSS class to an element.
Another exception to this rule is the practice of putting the most important CSS for the page within an inline style block to improve the performance of the page. This practice is referred to as "inlining critical CSS," and should be employed carefully, using performance metrics to measure the impact of the change.
Don't use
!important
The
!important
keyword can be used to add "weight" to a CSS declaration. As an example, imagine you have the following HTML with inline styling:Imagine that you discover you need to edit the color of the
<p>
s, so you add some CSS:This will only work for the
<p>
within the<div>
because an inline declaration will always carry more precedence than a regular CSS declaration. So, to get around this issue, you add!important
:Now your
<p>
will have blue text. However, you realize that you want<p>
s that are within<div>
s to have a different text color than regular<p>
s, so you add another CSS declaration:However, this won't do anything because your earlier
!important
declaration overrides this declaration. To fix this problem, you'll need to add!important
to this rule. As you can see, our CSS selector hierarchy is now becoming needlessly convoluted.Furthermore, using
!important
makes it more difficult for users to apply their own user-defined stylesheets (stylesheets authored by the user of the browser to customize web pages for accessibility and other reasons), since they must now use!important
themselves to fully override styling rules.For all of these reasons, you should avoid using the
!important
keyword.Don't use
@import
As an alternative to using
link
to import stylesheets, you can also import a stylesheet from within a stylesheet using the@import
rule:However, this is less performant than
link
as browsers will often end up downloading imported stylesheets sequentially, rather than in parallel as with the link tag. Due to these easily avoidable performance issues, don't use the@import
rule.Avoid hacks
Avoid using CSS "hacks" that target specific browsers in order to fix browser-specific problems:
In a general, if you need to use a hack, this is a hint that either your CSS rules or your markup is too convoluted. Try reformatting one or the other using standard CSS techniques first and only use a hack as a last resort.
Use relative over absolute units
Prefer relative units (such as
em
,%
, orrem
) over absolute units (such aspx
).By using relative units, elements on the page are better suited for adapting to various screen sizes and container widths. Furthermore, using relative units provides a smoother experience for users zooming in and out of your web pages using a browser's zooming features.
Don't generate content with CSS
Text content can be added to a page using the
content
property (with the::before
and::after
pseudo-elements). However, this content may or may not be read by a screen reader.Given this ambiguity, you should never generate essential content using CSS.
Furthermore, since some screen readers do read content generated with CSS, you should also avoid generating non-essential content as well (for example, inserting a "double arrow" symbol next to links), since this content will be unnecessarily read to a user with a screen reader.
Altogether, you should avoid generating any content with CSS.
Use the "print" media query
A "print" media query can be used to change the display of your website when the user prints it:
Naming
Give selectors semantically meaningful names
When choosing a name for a class or id selector, do not use a name that is linked to a specific implementation in CSS or markup or has no semantic meaning:
Imagine in the above example that you later decide all of the elements that have been marked with the class
.red
(such as error messages, etc.), should now be a different color. Also, imagine you later realize that the<div>
marked with the id#div1
should now be a form element instead.Instead, use CSS names that are semantically meaningful to the content:
Ordering
Alphabetize properties in rules
When listing CSS properties within a CSS rule, alphabetize them:
The exception to this rule are vendor-specific CSS properties (CSS properties that only target a specific browser rendering engine), which should be listed directly before their proper W3C form:
These vendor-specific properties should be listed first because they are volatile and may change at the whim of those developing the browser rendering engine. Since they are vendor-specific, these properties are not required to adhere to the W3C specification.
Thus, there have been cases in which both the vendor-specific and the "proper" form have both worked in the same browser, but with different behavior (
border-radius
and-webkit-border-radius
in Webkit, for example). By listing the "proper" form last, you ensure that you are always overriding any alternate, vendor-specific behavior with the behavior outlined in the CSS specification.Display
Ensure color contrast
Ensure there exists an appropriate degree of contrast between background and foreground colors. This is critical to providing an accessible experience for users with color blindness or limited vision.
There are a number of techniques for checking the accessibility of your website's colors, including using an automated tool, printing your website on a black and white printer, or lowering the brightness of your monitor.
This guidelines applies to all types of content: it should be easy to read the color of text on a given background, to discern where an input field begins and ends, to differentiate between content areas, and so on.
In all cases, the content of your website should be easy to discern and should not rely on subtle differences in color.