Forem: Angela Damaso

Angular 6: Dynamic Themes Without a Library

Angela Damaso — Sat, 02 Jun 2018 20:41:28 +0000

The concept of theming has been around as long as I can remember. Giving users the ability to choose the look and feel of your product has incredible value — it creates a more localized experience and reduces developer maintenance time.

How can we create something like this in our Angular apps?

Why Sass Alone Won’t Work

Although Sass variables may work to create a preset themed experience, the biggest drawback is that it can’t be manipulated by JavaScript. We need JavaScript to dynamically change the value of our variable!

Why Material Alone Won’t Work

Ever since Angular Material was released, developers have been flocking to this library to utilize their reusable components (not to mention built-in accessibility)

Material comes with built-in theming, but this may not work for two reasons:

By default, Material comes with it’s own color palette that is optimized for accessibility. If you want to generate more colors, you’ll need to pass it into their mat-palette mixin or create a new theme file, using 3rd party tooling. This creates an external dependency and restricts the ability to switch themes without touching code.
Although it is a great option, not everyone wants to use Material! Many developers do not wish to import an entire library to utilize components and opt to create their own.

The solution? Sass + CSS Variables!

If you have never used native CSS Custom Properties (I call them variables), there is a great article (here) to help you get started. The reason this approach works is because CSS variables can manipulated by JavaScript! With this combination, you can use a form to pass CSS variables to a Sass map, which can be used throughout the app.

Let’s See It!

This implementation:

Does not use any external libraries
Allows multiple components to dynamically change styles through a form
Saves the form as an object that can be saved in a database or local store
Has the capability to load an external object as a preloaded or preset style

Link to Demo: https://native-theming-form-medium.stackblitz.io/

Link to Stackblitz: https://stackblitz.com/edit/native-theming-form-medium

The Magic

The core principle behind this method is combining Sass maps and CSS Variables.

In thetheme.scss file, the default values are set and passed into a Sass map

theme.scss

// default colors
.theme-wrapper {
    --cardColor: #CCC;
    --cardBackground: #FFF;
    --buttonColor: #FFF;
    --buttonBackground: #FFF;
    --navColor: #FFF;
    --navBackground: #FFF;
    --footerColor: #FFF;
    --footerBackground: #FFF;
    --footerAlignment: left;
}
// pass variables into a sass map
$variables: (
    --cardColor: var(--cardColor),
    --cardBackground: var(--cardBackground),
    --buttonColor: var(--buttonColor),
    --buttonBackground: var(--buttonBackground),
    --navColor: var(--navColor),
    --navBackground: var(--navBackground),
    --footerColor: var(--footerColor),
    --footerBackground: var(--footerBackground),
    --footerAlignment: var(--footerAlignment)
);

A function is created to return the native css variable from the global sass map

function.scss

@function var($variable) {
    @return map-get($variables, $variable);
}

The components can now read these two files to host a dynamic variable that changes upon form resubmit

card.component.scss

@import '../../theme';
@import '../../functions';
.card {
    background-color: var(--cardBackground);
    color: var(--cardColor);
}

The card’s background color is now #FFFFFF and text color is #CCCCCC

But how do we change the values?

Through the theme-picker component!

In our theme-picker.component.html file, we are using template forms with ngModel to create an object with a unique key (style) and value (input). The object then gets passed to the TypeScript file which dynamically overwrites the variable.

theme-picker.component.ts

// searching the entire page for css variables
private themeWrapper = document.querySelector('body');
onSubmit(form) {
    this.globalOverride(form.value);
}
globalOverride(stylesheet) {
    if (stylesheet.globalNavColor) {
        this.themeWrapper.style.setProperty('--navColor',     stylesheet.globalNavColor);
    }
...
    if (stylesheet.globalButtonColor) {
        this.themeWrapper.style.setProperty('--buttonColor',     stylesheet.globalButtonColor);
    }
}

The globalOverride function checks to see if a value exists for that specific variable, then replaces each CSS Variable with the new inputted one.

Violá!

This code can be better optimized to scale (using preset style objects, saving/publishing styles on submit), so feel free to play around with it!

Why You Should Give a S*** About Accessibility

Angela Damaso — Wed, 31 Jan 2018 18:51:52 +0000

57,000,000 Americans have a disability.

According to a 2012 Census report, 56.7 million Americans have some form of disability. As developers and designers, it is our responsibility to create websites and applications that cater to everyone. It is also our social responsibility to make the web accessible to more than just 80% of the population and to educate the public (especially other engineers and designers) about these issues.

Consider impairments that impact accessibility of online websites, applications, and documents. This survey estimates the number of people with specific impairments as follows:
19.9 million (8.2%) have difficulty lifting or grasping. This could, for example impact their use of a mouse or keyboard.
5.2 million (6.3%) have a cognitive, mental, or emotional impairment.
8.1 million (3.3%) have a vision impairment. These people might rely on a screen magnifier or a screen reader, or might have a form of color blindness.
7.6 million (3.1%) have a hearing impairment. They might rely on transcripts and / or captions for audio and video media (source).

How Accessibility Impacts Business

Ignoring accessibility can create a loss in potential profit each year. Imagine something as small as text color choice alienating half of your potential customers. Even age-related conditions such as presbyopia (loss of the eyes’ ability to focus) hinders the capability to read small text or see colors with low-contrast.

Top companies such as Target, JetBlue, and Scribd have been fined/sued over inaccessibility.

“The case, brought by the California Council of the Blind and three blind JetBlue customers, is about access barriers on JetBlue’s website and the inaccessibility of JetBlue’s airport check-in kiosks to people with visual impairments. JetBlue has designed its website in a way that prevents blind customers from independently and privately accessing information and using the site’s features. JetBlue’s airport kiosks cannot be used by blind customers because the machines do not have audio output or an accessible means to input information.” (source)

The NFL Color Rush

Another example of accessibility negligence is the 2015 NFL Color Rush campaign. To celebrate the league’s 50th anniversary of the first-ever TV game shown in color, the Bills were wearing all-red and the Jets were wearing all-green. Ironically, the NFL failed to account for the 8% of men who are red/green color-blind.

Afterward, the NFL released a statement claiming they “did test the jerseys this summer on field and on television. The standard television test did not account for color blindness for fans at home, that became apparent.”

Hopefully, this instance highlights the importance of color choice and awareness of inclusive design.

What We Can Do About It

Use the Web Content Accessibility Guidelines Checklist (WCAG)
Use this for accessibility compliance — WCAG 2.0 is the current inclusive web standard. WCAG applies to all web content, including single page and dynamic web applications, multimedia, and mobile websites.

Use those tools!

There are a variety of websites and browser plugins to help you check for accessibility.

My favorites are:

Chrome Developer Accessibility Tools
WAVE (Web Accessibility Evaluation Tool)
ChromeVox Screen Reader
SEE Chrome Plugin

10 General Design & Development Considerations

Use headings (h1, h2) properly
Use ARIA landmarks (marking sections of a web page)
Add labels to form fields
Keep color contrast in mind
Use live text, not pictures of text (this also helps with SEO!)
Provide video descriptions and use closed captioning
Choose dropdown menu that works for all users (someone may be unable to trigger or access a submenu)
Test websites without a keyboard (many people don’t have a mouse)
Test sites with assistive technologies on mobile and desktop
Add proper alt-text to images (great article about alt-text)

Accessibility is the new standard of web development and we must not fall behind.

Friends with BEM-efits

Angela Damaso — Tue, 30 Jan 2018 19:10:08 +0000

An Introduction to BEM

What is BEM?

The Block, Element, and Modifier (BEM) methodology is a common naming convention for CSS classes developed by Yandex. The core idea behind BEM is to provide a strict way to arrange your CSS classes into modules. BEM captures the purpose and meaning through it's CSS class name syntax:

Block: Represents a module or context where the element finds itself. ("What is it?")
- navigation
- footer
- item-review
Element: Describes a component within the block that performs a particular function. ("What does this do/show?")
- item
- link
- button
Modifier: Defines the appearance, state, or behavior of a block or element. ("What state is it in?")
- active
- red
- large

We represent this syntax with two underscores for elements and two dashes for modifiers:

.navigation__item--active
.footer__link--red
.item-review__button--large

An Analogy

To grasp a further understanding of how these are all related, think of it like an analogy.

Hierachy

Car
|-- Transmission
|   -- Automatic
|   -- Manual

Person
|-- Female
|   -- Lips
|-- Male
|   -- Beard

CSS

.car {}
.car__transmission {}
.car__transmission--automatic {}
.car__transmission--manual {}

.person {}
.person--male__beard {}
.person--female__lips {}

Let's say we want to display different classes to describe a car's transmission. The block or module would be the Car. The element we are showing is a Transmission, and is modified or described by Automatic and Manual.

In our second example, we see that the modifier is coming before the element!!

If you look at our tree hierarchy, this approach makes more sense. In this example, a Person is being divided into a Female and Male class. Each modifier will have elements of its own, such as Lips or Beard.

Remember to be thoughtful and tasteful when creating your naming hierarchies. Nobody want's to read .person--female__arm__hand--left__finger--pinky and can easily clutter up your markup. If that level of specificity is needed, try breaking it down into submodules for easier readability and organization.

Sass + BEM = <3

In a Sass file, one way to structure your classes is through nesting.

.block {
    &__element {
        &--modifier { 
        }
    }
    &--modifier {
    }
}

which would print out to:

.block__element {}
.block__element--modifier {}
.block--modifier[]

The great thing about this architecture is potential to handle scalability. Code is grouped modularly and describes its purpose and state. Let's take a look at an example:

HTML

<ul class="tabs">
    <li class="tabs__header--active">
        <img class="tabs__content__image" src="">
    </li>
    <li class="tabs__header">
        <img class="tabs__image" src="#">
        <img class="tabs__image--inverse" src="#">
    </li>
</ul>

Sass

.tabs {
    &__header {
        &--active {
        }    
    }
    &__image {
        &--inverse {
        }
    }
}

Outputted CSS

.tabs {

}
.tabs__header {

}
.tabs__header--active {

}
.tabs {

}
.tabs__image {

}
.tabs__image--inverse {

}

Pretty cool! As applications grow, this nested structure makes class names easier to read and removes the guesswork when other developers read your code.

Just remember: Try not to nest your Sass more than three levels deep!!

So...Why BEM?

Self-documenting CSS! It displays the hierarchy between different nodes' relationships in the DOM.
Strict class naming promotes encapsulation and reduce naming collisions or using classes outside a given context.
Performance benefits!
Tells other developers more about what a piece of markup is doing from its name alone.
Removes the need for descendant selectors.
Component styles are decoupled and highly portable from project to project. In practice, this means an improvement in code quality and development speed!

In short, BEM will make you push yourself to pay attention to detail, think things through and thus raise the quality of your code :)