WordPress is a popular content management system (CMS) that powers over 43% of websites today. One of the key reasons for its popularity is its flexibility and customizability. WordPress allows developers to create custom themes and plugins to tailor the website to their needs.

WordPress Styling

When developing a WordPress theme or plugin, one of the critical aspects is styling. It’s essential to ensure the website looks visually appealing, and the design is consistent throughout. This can be achieved through cascading style sheets (CSS), which dictate how the HTML elements are presented on the page.

However, styling a WordPress website can be complex, especially for those new to web development. Several different methods can be used to apply styles to various parts of the website, including the frontend, content editor, plugins, and admin areas.

Continue reading, and we will explore WordPress styling techniques and the different methods available for adding styles to each area. We will cover everything from basic CSS rules to advanced techniques like hooks and filters.

By the end of this article, you will have a comprehensive understanding of applying styles to different parts of a WordPress website and be well on your way to creating a fully customized and visually stunning website. These are the places where styling is required, which we’ll cover in this blog post:

1. Block Editor Styles
2. Block-Specific Custom Styles
3. Using theme.json
4. Theme & Plugin Styles
5. Classic Editor Styles
6. Admin Styles

1. Block Editor Styles

Customizing the visual appearance of the Gutenberg block editor is an essential aspect of developing a WordPress website. Adding your own custom styles can make your content stand out and create a more engaging user experience.

Fortunately, adding styles to the block editor is a straightforward process. One way to do this is by utilizing the enqueue_block_editor_assets hook, which allows you to enqueue your stylesheet specifically for the block editor.

Enqueuing your stylesheet using this hook ensures that your styles are loaded only in the block editor and not on the front end of your website.

Here is an example of how to add it:

View the code on Gist.

If you want to update the frontend as well, change the code slightly, as shown below:

View the code on Gist.

Use this article from CSS-Tricks as a reference for targeting different blocks in your stylesheet if needed.

Opinionated Styles

When using the Gutenberg block editor, default styles are loaded on both the admin and frontend sides. However, certain opinionated styles need to be added manually. For instance, the default block quote won’t have a colored border on the left-hand side without enabling these styles.

To enable them, add add_theme_support( 'wp-block-styles' ) to your functions.php file like below.

function my_theme_setup() { 
  add_theme_support( 'wp-block-styles' ); 
} 
add_action( 'after_setup_theme', 'my_theme_setup' );

2. Block Specific Custom Styles

Customizing the visual appearance of blocks in the WordPress block editor is made possible by the register_block_style() function. This function allows developers to create custom block styles, expanding users’ options to style and customize their content.

The register_block_style() function accepts three parameters: the block name, the style name, and an array of arguments defining the style properties. With this function, you can easily create a custom style for any block, such as the core/button block.

Here’s an example of how to use register_block_style() to achieve this.

View the code on Gist.

In this example, we’re registering a new style for the core/button block called my-theme-button-style.

Once you’ve registered the block style, users can select it from the block editor’s style selector. The style will be applied to any core/button blocks that use the my-theme-button-style class.

Overall, register_block_style() is a powerful tool that allows you to create custom styles for blocks in the WordPress block editor, giving users more control over the appearance of their content.

3. Using theme.json

The theme.json file is a configuration file introduced in WordPress 5.8 that allows developers to customize a WordPress theme’s global styles and settings. It is a JSON file that defines a set of rules that determine how the theme should be displayed on the front end of the site.

With theme.json, you can customize a wide range of settings, including typography, colors, spacing, and layout. These settings can be applied globally to your theme, or you can specify different settings for specific blocks or block patterns.

Here are some of the key features and benefits of using theme.json:

1. Consistency: With theme.json, you can ensure that your theme’s styles and settings are consistent across all blocks and block patterns. This can help improve your site’s overall design and user experience.
2. Efficiency: By defining global styles and settings in a single theme.json file, you can simplify the process of customizing your theme and reduce the amount of code required to achieve a consistent design.
3. Accessibility: theme.json includes a range of accessibility-related settings, such as font size, line height, and color contrast. By using theme.json, you can ensure that your theme meets accessibility guidelines and is usable by as many people as possible.
4. Flexibility: theme.json allows you to define different styles and settings for other blocks or block patterns, giving you greater flexibility and control over the appearance of your site.

Here’s an example of what the theme.json file might look like this:

View the code on Gist.

In this example, we’re defining a set of global styles and settings for our theme. These include color, typography, spacing, and layout settings, as well as a custom setting called my-custom-setting.

We’re also specifying some block-specific styles and settings for the core/paragraph block. These override the global settings for this block, allowing us to customize its appearance separately from other blocks.

By using theme.json, you can create a consistent and accessible design for your WordPress site with less effort and more flexibility.

4. Theme & Plugin Styles

Themes and plugins have a similar way to enqueue styles by using the wp_enqueue_style() method.

The below example shows how to enqueue the styles in your theme:

View the code on Gist.

In the same way, we can also enqueue the styles in the plugin. The only difference is you have to use the plugins_url() method to point the path to the specific plugin’s stylesheet. See the example below:

View the code on Gist.

Please note that here the styles.css file will load on the front end. But if you want to add some custom styles for the plugin’s interface under Admin, please use admin_enqueue_scripts hook instead of wp_enqueue_scripts hook as in the example below:

add_action( 'admin_enqueue_scripts', 'my_plugin_enqueue' );

5. Classic Editor Styles

Developers can use the hook to add custom styles to the Classic TinyMCE Editor in WordPress. This allows users to see how their content will look on the front end while editing it from the admin panel.

Here is an example of how to implement add_editor_style() to add custom styles to the Classic TinyMCE Editor:

View the code on Gist.

6. Admin Styles

To brand the WordPress Admin Panel or to style a plugin’s user interface, developers can use the admin_enqueue_scripts hook to add custom styles.

This hook can also be used to load styles on specific pages within the WordPress Admin by adding conditions. Here is an example of how to do this:

View the code on Gist.

In this example, we only load the file when the user is on the edit.php page.

Conclusion

By leveraging WordPress styling techniques, you can create beautiful and highly customized websites that truly stand out. Whether you’re looking to brand your WordPress site or create a unique style for your plugin, there are many ways that you can use to achieve your goals. We hope this article has helped provide you with a better understanding of WordPress styling techniques and inspired you to create even more stunning WordPress websites in the future.

The post Exploring WordPress Styling Techniques appeared first on WebDevStudios.

1. Parent Selector

Select a parent from within the child selector.

SCSS

View the code on Gist.

Instead of having to make a new selector for .container .text outside of the .text block, you can just write your selector inside of .text, followed by the &.

Compiled CSS

View the code on Gist.

HTML

View the code on Gist.

View on CodePen.

2. Suffixes

Here’s a cool way to generate suffixes based on a particular class. Use &- followed by the desired suffix. In this case, &-pink will create .container-pink when it’s used inside of .container.

SCSS

View the code on Gist.

Compiled CSS

View the code on Gist.

HTML

View the code on Gist.

View on CodePen

3. String Interpolation

String interpolation will render the result of a SassScript expression as compiled CSS. In this basic example, we’re setting color variables, then rendering them out as CSS comments.

SCSS

Notice how we use string interpolation directly in the comment.

View the code on Gist.

Compiled CSS

View the code on Gist.

View on CodePen

4. Placeholders

Placeholders are similar to variables in that they aren’t compiled in the actual CSS. The benefit of this is that they keep your code clean by rendering only the output of the placeholder. They can be extended anywhere in your code. Placeholders can be useful when you want to extend some particular properties across multiple selectors. Start your placeholder with a percentage sign %, so for example you could write %my-placeholder, and extend it inside your selector with @extend.

SCSS

View the code on Gist.

Compiled CSS

View the code on Gist.

HTML

View the code on Gist.

View on CodePen

5. Default value in mixins

When using a mixin, you normally need to pass in every argument that will be required. The advantage of using a default value is that you aren’t required to pass an argument in, but you can always override the default you’ve set. In this Sass tip example, I’m overriding the defaults for the second h1 as I pass in an argument of darkcyan.

SCSS

View the code on Gist.

Compiled CSS

View the code on Gist.

HTML

View the code on Gist.

View on CodePen

6. Null

Let’s expand on what we just did with using a default value, except this time, we’ll use null as a default value. If no arguments are passed in, nothing will be compiled in the CSS for opacity, but if an argument is passed in, it will be compiled in the CSS. This is a nice trick because your CSS won’t be bloated with unused styles.

SCSS

View the code on Gist.

Compiled CSS

View the code on Gist.

HTML

View the code on Gist.

View on CodePen

7. Color Functions

Color functions open a world of options for manipulating colors. They are built into Sass and can be used to dynamically generate CSS based on your needs. Here, we instantiate our scale-color function, passing in a color, and a saturation percentage. There are many color functions, and I encourage you to experiment with them.

SCSS

View the code on Gist.

Compiled CSS

When compiled, the hexidecimal color here is the result of the expression.

View the code on Gist.

HTML

View the code on Gist.

View on CodePen

8. @if to Change Contrast

Here’s a great Sass tip: Sass has control flow built into it. There are four types of control available to use: @if, @each, @for, and @while. Here, we use an @if conditional to determine if our colors meet the desired threshold for contrast; we then render the text color based on the outcome.

SCSS

View the code on Gist.

Compiled CSS

View the code on Gist.

HTML

View the code on Gist.

View on CodePen

9. @debug

When using Sass, there may be times when you need to know the value of an expression. If you use JavaScript, you have probably used console.log() to print the results of an expression to the console. The good news is that Sass has something similar. For example, it might be more work than it’s worth to figure out the saturation of #e1d7d2 yourself, but @debug is happy to do the math for you, right in the console!

SCSS

View the code on Gist.

Compiled CSS

View the code on Gist.

View on CodePen

10. Use @for to Build Your Own Utility Classes

You can even use loops in Sass. @for is one of the four types of control flow currently in Sass. Here, we’re going to generate some utility classes. We’re using the unquote function to return a string of "px", but without quotes. As you might be wondering, there’s also a quote function, which will return the same thing, but with quotes, of course. Note the use of string interpolation.

SCSS

View the code on Gist.

Compiled CSS

View the code on Gist.

HTML

View the code on Gist.

View on CodePen

Here’s a full list of all the CodePen examples for you to explore:

1. Parent Selector
2. Suffixes
3. String Interpolation
4. Placeholders
5. Default value in mixins
6. Null
7. Color Functions
8. @if To Change Contrast
9. @debug
10. Use @for To Build Your Own Utility Classes

Thank you!

Thanks for taking the time to read these Sass tips. I hope you’ve found some of these items that I’ve picked up over the years to be useful for your daily Sass workflow.

The post Sass Tips to Take Your Skills to the Next Level appeared first on WebDevStudios.

This guide aims to provide direction and help you discover the right paths for learning web development.

The Circle of Knowledge

Before we begin, let’s discuss briefly what I like to call the Circle of Knowledge (aka, the generalized way in which I like to think about knowledge acquisition). Consider the following image:

For the purpose of this article, let’s assume you are interested in learning to build your first website. In the Circle of Knowledge, the outer edge broadly establishes the topic of Web Development. The inner circles define your level of familiarity with the general topic’s more specific subtopics. These interior circles divide your understanding of the larger topic into three sections: topics you know (or think you know), topics you have heard about, and topics you are unaware even exist.

Initially, the innermost circle is probably pretty small, because you’re just starting to dig into what you need to learn in order to understand web development. Maybe you know how to turn on a computer; you understand that something called a browser lets you access the internet (which you know some people also call the web); you can search for topics of interest, and parse the search results to determine which of those accurately represent the answers to your questions.

It may not seem like much, but this is a great starting point. You already have something in common with the vast majority of computer programmers in the world: if we don’t know something, we look it up.

Your First Search

Imagine you search for the phrase “how to build a website” and encounter the following results:

You just populated the middle segment of your Circle of Knowledge. Although you may not understand what they mean, terms like domain, hosting, Wix and eCommerce are now on your radar. Next, you click the link labeled How to Create a Website: Step-by-Step Guide for Beginners (2018) and are greeted with an additional set of terms: WordPress, content management system, HTML, CSS, Drupal, and so on.

Prior to each click, all of these terms occupied your outermost circle (topics you were unaware even existed), but through the process of research, one-by-one you are now moving them to the middle circle: topics you have heard about. This is excellent progress!

The process of learning anything—web development, baking, running for Congress—can be broken down into these steps. Beginning with just a single search, you will learn a whole new set of terms, notice patterns (domain and hosting came up multiple times in our initial search), and start piecing together the puzzle. The goal for your Circle of Knowledge is to grow the inner circle—the things you know—as much as possible. To do that, first you need to expand the middle segment by discovering new concepts, then selecting those on which to focus your efforts.

“That’s great, but where do I go from here?”

I’ll give you a head start: 100% of all websites are composed of HyperText Markup Language, more easily recognized by its initialism: HTML. This language defines the structure of a website’s content and indicates to your browser the differences between headings, sections, paragraphs, images, bulleted lists, numbered lists, and so on. Well-structured HTML is readable both by browsers and devices that assist web users with impaired vision. It’s the foundation of the internet. It’s also the most important language you can learn to write well at the beginning of your web development career.

Of course, websites are powered by more than just well-structured content. Some are beautifully designed. Some have extremely dynamic interactions, and others work like native computer applications. On occasion, you find a site that does it all.

While learning about HTML, you may find yourself asking some new questions:

• “How can I make this look better?”
• “Do I really need to create this navigation menu in every file?”
• “Can I save information that I enter into a form?”
• “Is my markup accessible?”

Once again, search is your friend; and by leveraging your research skills, you will learn new information. You will perhaps discover that CSS is responsible for the way a website looks. Languages like PHP let you to create reusable templates to split up distinct pieces of content such as navigation. Database languages such as MySQL allow you to save form data. And writing semantic markup goes a long way toward making your content accessible.

The Fork in the Road

You will begin to see new learning paths as you continue to acquire more knowledge; and where there are paths, there are choices. Whether you care more about how a website looks and how users interact with it, or how a website saves and makes available its data, is going to inform your decision to pursue specified knowledge in those areas. We define a website’s look and collection of user interfaces as its “frontend,” and its data structures and application logic as its “backend.”

My friend and colleague, Justin Foell, previously published an article that asked whether you should first learn JavaScript or PHP. An alternate question might be, “Should I start by learning to build user interfaces or systems?” That is the primary difference between frontend and backend development.

Frontend Development

The frontend of a site comprises the publicly-visible content that regular visitors will see. As you’ve learned, HTML provides the structure for that content, but the responsibility for the visual appearance of that content belongs to Cascading Style Sheets, or CSS. Additionally, some behavior of your site that responds to user input, such as triggering a slideshow or using keyboard commands to trigger different settings, is written in a language called JavaScript. Developing a mastery of HTML, CSS, and JavaScript is essential to becoming a frontend web engineer.

Frontend Development: templates, presentation styles, animations, handling user interactions.

Resources

One of my favorite book series for an introduction to frontend development is Web Design with HTML, CSS, JavaScript, and jQuery Set, written by Jon Duckett. These books are a wonderful introduction to each of the three primary frontend languages, and they’re beautiful. too.

For CSS development, CSS Tricks has a great beginner’s guide for learning HTML and CSS. Once you have exhausted their collection of those articles, they have loads more about more general frontend development.

A Book Apart regularly publishes books about a variety of topics from renowned experts in the field. You might be interested in their Front-end Fundamentals series. Then shortly after, check out both the series on Responsive Design and Front-end Next Steps.

Smashing Magazine is another great general resource for frontend development. Smashing publishes loads of articles, tutorials, and books for free, and also offers memberships that provide deep discounts to that content. They also host several live events throughout the year.

Backend Development

The backend (sometimes called “server-side”) of a site typically consists of:

1. a mechanism for storing data in a persistent fashion
2. a collection of files that a web server understands

Data can be stored in files, but it’s more likely that you will be using a database instead. The open-source content management system WordPress uses a combination of MySQL (database language) and PHP (otherwise known as Pre-HyperText PHP, a server-side language) to dynamically generate HTML content.

Backend: databases, server-side languages, application logic, application programming interfaces.

If you’re interested in learning how to make a website dynamic, then we recommend you consider learning PHP immediately after you learn HTML.

PHP began as a templating language. As such, you can create HTML templates that use PHP to pull in your dynamic data. This makes it incredibly versatile for building your site’s structure, as you can separate reusable content like navigation menus into separate files. Thus, if that part of your site changes, it can be easily updated everywhere that part is used.

Of course, the true power of PHP is in application development. Because it’s a backend language, most of your PHP code won’t be outputting templates. Instead, it will be used to connect to data sources like a database or application programming interface to retrieve, manipulate, and update that data. Once you learn how to use PHP for templating, introducing a database to the mix and learning how to write queries is the next logical path.

Resources

There are, in my view, two definitive resources for learning PHP. First, PHP has a glorious online manual that will be your go-to resource any time you have questions. Second, PHP The Right Way is an online book that covers everything from templating to servers and deployment, so you can focus on an area of the language that’s right for your skill level.

Of course, in looking for other resources while researching this article, I just found out that Jon Duckett is publishing a new book about server-side development with PHP and MySQL. I don’t own this, but knowing how great the frontend series books are, I’m pre-ordering this today!

In my view, good online MySQL resources are a bit harder to come by, but sites like Lynda.com and Laracasts have some solid instructional videos, if you’re willing to pay for a subscription.

Still with me?

Good! That fork in the road is important, because your initial question, “How do I build a website?” will lead you down many paths. Some will be fulfilling, and some you’ll find are better left unexplored. They are left there for you to discover.

Earlier, I suggested that computer programming contains far more subtopics than any single person could possibly hope to learn. As a part of choosing your own path, you must continually ask yourself whether the information you are learning is necessary in helping you reach your personal goals. Only you can know that for sure.

Continuing Down a Path

Once you spend enough time learning front or backend development basics, you can no longer say you’ve heard of their languages. Instead, you can confidently say that you are proficient with them. Congratulations! You successfully moved one or more topics into the innermost section of your Circle of Knowledge: “topics you know.”

However, learning doesn’t stop because you are proficient. During the course of learning frontend development, you may discover other topics: CSS preprocessors like Sass or LESS, templating engines like Twig or Blade, or JavaScript frameworks like React, Vue, or Angular. Or, while learning backend development, you will hear about dependency management via Composer, unit testing with PHPUnit, or development practices like SOLID. In either path, you might find websites discussing version control, content management applications, responsive design, intrinsic web design, or a concept called “test driven development.”

Summing Up

Regardless of your path, bringing knowledge into your inner circle leads to new information, questions, and ways of thinking about a topic. At that point, it’s up to you to evaluate your own proficiency, level of interests, and next areas of focus. There are no right or wrong paths. Thankfully, there are some folks out there who have published suggested routes.

One such example is Kamran Ahmed’s “Developer Roadmap – 2018”, published on GitHub. Kamran offers recommended paths for both frontend and backend development. His paths are rich with information, but can seem overwhelming, if it’s the absolute first thing you look into. We recommend you start with the basics described above and revisit Kamran’s articles once you feel ready to learn more. Also, take note of new terms or information that come up during the process of learning. The frequency at which you see those terms will inform which topics to dig into next.

Be sure to check in with yourself regularly and evaluate whether or not you are learning topics that you enjoy. If so, great! You have discovered topics rich with new information that are right within your areas of interest. If not, that’s okay, too. There are some aspects of the field that are less thrilling but still important to know to attain long-term success. Sometimes, a topic is simply not for you. Depending how far along you are on your path, you may discover the path itself isn’t the right one. Evaluating your interest in the information you are learning goes a long way toward guiding your path.

Good luck!

The post Paths to Learning Web Development appeared first on WebDevStudios.

Since then, WebDevStudios has kept that promise. When we ship a website to a client, it passes all sorts of accessibility tests, as well as HTML and CSS validation. When a potential client asks us to provide examples of accessible websites that we have built, it’s easy to oblige. More often than not, that leads to a sale.

While impressing clients and acquiring a new project are good reasons to build an accessible website, the reality is that over 285 million people worldwide have visual impairments… which is almost the population of the United States! Thinking about accessibility is just the right thing to do.

Four Basic Principles

Make no mistake, accessibility is hard. So where should you start? To keep from getting overwhelmed, take a cue from Foundation by Zurb and follow four basic principles:

1) Structure your document properly

Modern web browsers can do a lot of the heavy lifting… if you write semantic HTML.

1. Use <button> instead of making <a>, <div> and <spans> look like buttons.
2. Use headings <h1> – <h6> to help provide both structure and context to screen readers.
3. Steer clear of “enhanced” form field plugins. Ask yourself, “Is it really worth having a pretty dropdown, when it is completely unusable by 285 million people?”
4. Use WAI-ARIA to help provide additional semantics to describe role, state, and properties.
5. Read more about “How Writing Semantic HTML Can Help Accessibility” by Jeffrey de Wit.

2) <label> everything

For 285 million people, a screen reader is the only way to “view” a website. When it’s read back to them… does your website makes sense?

1. Make sure form fields have a <label>. It is OK to hide labels with CSS: <label class="sr-only">
2. Using <fieldset> and <legend> to group related form elements.
3. Provide descriptive alt attributes on images: <img alt="A hen Mallard landing on a pond"> vs <img alt="mallard_duck-1.jpg">
4. Read more about “Labeling Controls” from w3.org.

3) Don’t rely on purely visual cues

If a page is being read to a user by a screen reader, it may not be obvious what the user is supposed to do next.

1. Make sure call to actions have labels that can be read by a screen reader.
2. Do call to actions meet a minimum contrast ratio? Meaning, can this person actually see/read it? Make sure the contrast ratio (on everything from text to buttons) is at least 1:4.5 for normal text and 3:1 for headings.

4) Make everything usable on a keyboard, mouse, and touch screen

1. Make sure you can use the tab, spacebar, and arrow keys to navigate a web page.
2. Give users the option to skip around a page.
3. Complex components such as sliders or modals should be tested with arrow and esc keys.

Tools Can Help

These accessibility testing tools can help, by pointing out areas of your web page that need work.

• Tenon.io – Will check your website against Section 508 and WCAG 2.0, and provide recommended fixes.
• WAVE – Similarly, WAVE can test your website against accessibility standards and even display contrast issues.
• Total Validator – Available for Windows and MacOS, this tool can test entire websites against a wide range of validation tests.

Conclusion

By thinking about and ultimately acting on these principles during the entire life cycle of a project, from scoping to design, development, and QA, not only will you be making your website usable by those with disabilities, you will be doing the right thing. This will come with many other benefits including: long-term maintainable code, SEO juice, and that feeling deep down when you do something nice for someone else. In my book, it doesn’t get more successful than that.

Further Reading

• MDN – Learning accessibility
• WebAIM – Training, assistance, certification, and testing
• WordPress Accessibility Code Standards – The WordPress A11y Team
• Accessibility APIs – A key to web accessibility

The post How Thinking About Accessibility Can Lead to Success appeared first on WebDevStudios.

This is Part II of a series called “Evolution of CSS”.

1. Evolution of CSS: Becoming a CSS Composer
2. Evolution of CSS: Class Naming Methodologies
3. Evolution of CSS: Overview of Tachyons

Perhaps you’ve heard this one before?

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

Well, as any developer that writes code daily could attest those words are very true; and CSS class naming and assignment is no exception. Let’s discuss some of the reasons why and some of the solutions and theories offered to help mitigate this conundrum. But first, let’s try and clear the air around one particular subject: semantics.

Semantics

Semantics is the study of symbols, words, phrases and signs and their meaning, both philosophically and linguistically.

In the context of front-end web development, semantics are largely concerned with the agreed meaning of HTML elements, attributes, and attribute values (including extensions like Microdata). These agreed semantics, which are usually formalised in specifications, can be used to help programmes (and subsequently humans) better understand aspects of the information on a website. However, even after formalisation, the semantics of elements, attributes, and attribute values are subject to adaptation and co-option by developers. This can lead to subsequent modifications of the formally agreed semantics (and is an HTML design principle).

“About HTML semantics and front-end architecture” – Nicolas Gallagher

As front-end developers, we tend to toss around the word semantics a lot. We want our code to be semantic, but what do we mean?

There are certain fallacies in regards to CSS and HTML semantics. Yes, HTML can have semantic purpose and help browsers render proper markup to end-users. However, CSS has no semantics; and if it does, it is merely cultural, internal, agreed-upon semantics. In other words, to say certain classes or class naming conventions are “unsemantic” is moot. You’re merely stating that the class names don’t make sense (lack meaning) to you. For the most part, any class name has meaning and purpose to somebody.

The main purpose of class naming should be to help developers. If your HTML is outlined properly, then the content’s meaning is already established. Assigning classes to any of those elements won’t affect that content’s meaning.

This is where we can differentiate content-semantic (e.g. .header or .submenu) vs visually semantic (e.g. .col4 or .btn-success) class naming conventions. Later we’ll also discuss the new kid on the block: functional (or composeable) class naming.

Analyzing Scalable and Performant Methodologies

Many people far smarter than me have written about their experience on scaling CSS. Similarly, many approaches have been born from these conversations. Here are a few and a brief overview of them individually. Hopefully, you’ve already heard of some, and you may be already using a preferred method.

Object Oriented CSS (OOCSS)

Nicole Sullivan first introduced the concept of Object Oriented CSS back in 2009. Her insight and analysis of existing enterprise methods for writing CSS established a larger conversation, which many of the preceding methods stemmed from, and extended on.

The gist of the concept for OOCSS was the idea of marrying traditional object oriented programming methods with CSS. Whereas, objects are merely referring to HTML elements.

The two main tenets of OOCSS are:

Separate structure from skin

Essentially, this means to abstract the structure and positioning styles of an object from the presentational styles, or skin.

Separate container from content

This means to break components’ dependency of their containers. Any object should be able to be placed in another container and still look and behave the same.

Block Element Modifier (BEM)

The Block Element Modifier (BEM) method was developed by Yandex. BEM offers a strict means to class naming in your CSS in order to purpose them as reusable modules.

• Block – Standalone entity that is meaningful on its own. Examples: header, container, menu
• Element – A part of a block that has no standalone meaning and is semantically tied to its block. Examples: menu item, list item, checkbox caption
• Modifier – A flag on a block or element. Use them to change appearance or behavior. Examples: disabled, highlighted, checked

Using a button as an example we might use BEM to write our classes like this:

BEM has a lot more documentation and I encourage you to dig in at GetBem.com.

Scalable and Modular Architecture for CSS (SMACSS)

SMACSS is a framework developed by Jonathan Snook. Snook prefers to classify SMACSS as “more style guide than rigid framework.”

SMACSS is mostly based on five categories:

• Base rules – Target basic elements only, and does not include classes or IDs. This often can include resets. Examples: body, form, a, a:hover
• Layout rules – These are further sub-classified as major and minor layout rules. Major layout styles typically target IDs and can affect things like the header or footer. Whereas, minor layout styles (aka Modules) are nested within major layout components, e.g. nav, or login form
• Module rules – A Module is a discreet component. As mentioned above an example is nav in a header. Modules can reside inside of other modules, but should be styled to stand alone. Typically avoid element and ID selectors, and make liberal use of child or descendant selectors where the use may be predictable.
• State rules – Typically used to override or augment a Module or Layout’s rules when differentiating the different states (e.g. active, inactive, expanded, hidden). These are prefixed with is-, e.g. is-active, is-inactive, is-expanded, is-hidden
• Theme rules – This is where you can set overrides on any of the above: Base, Layouts, Modules, States. Think of it as setting the chrome on your site, or Modules (aka skinning).

SMACSS is not as opinionated as BEM in its class naming conventions. It has a similar approach to BEM in that it suggests you name your block’s child elements by using the parent block with a hyphen, e.g. .pod, .pod-body

New Generation methodologies

Yes, I’m going to lump the following methodologies into what I’m calling: New Generation methodologies. I tried to cover most of the major milestone methodologies above, but there are many others that helped pave the way for exploration. However, in recent years there seems to have been a bit of underlying commonality between these New Generation methodologies: anti-monolithic, component-based, and single-purpose single property practices. Here are a few:

Atomic CSS (ACSS)

Atomic CSS is developed by Yahoo! Inc. Atomic CSS offers immutable, single property classes to emphasize their singular function. Whereas, monolithic styles often times rely on descendant and contextual selectors. Let’s look at an example of how we might markup Atomic CSS two column layout vs traditional methods.

And here would be a comparison of the CSS used by Atomic CSS vs traditional method.

The traditional example above is where we start to see how these methods can break down in large projects. Should a new requirement be introduced to the two-column component then often times there is more bloat introduced. Whereas, the complexity of rules and selectors become so coupled that it can cause confusion or anxiety on editing existing CSS, and instead, “We create new rules, rather than modify existing ones, because we are not sure the latter is 100% safe.” ^[1]

Basscss and Tachyons

These two libraries are so similar it is hard not to group them. They both use similar feature descriptions, like “composable”, “single purpose” classes. Both are framework agnostic, and ready to plug and play with React, Ember, Angular, Rails, Elm, static HTML, etc.

Tachyons has seemingly become more popular. I speculate that it is because the documentation and resources are robust, and as of this writing the number of Contributors is double that of Basscss on Github. I plan on covering Tachyons in-depth in my next post.

Conclusion

I gave a terse overview of some key methodologies, but each one could easily have a post written on its own. I encourage you to dig deeper into any methods that resonate with you, and your current or next project’s needs.

Stay tuned for the next post in this series: “Evolution of CSS: Overview of Tachyons.”

The post Evolution of CSS: Class Naming Methodologies appeared first on WebDevStudios.

Keeping with the Non-Traditional Traditions

I received my degree from a private liberal arts college, but only after a large and intentional vacation from formal education after high school. The college had a non-traditional, experimental program that was typically advertised toward “returning adults,” and this is where I chose to finally continue my formal education. It allowed me to not necessarily have a major, but a “focus” in communications, and specifically, an “interdisciplinary program with courses in multimedia theory and design.” So I was able to dabble a little in graphic design, 3D animation, music theory, and multimedia computer programming. This is where I was introduced to HTML, CSS, and Flash.

(Note: I did not take any computer science classes, which would have probably pointed me in a different trajectory career-wise. Instead, I was more fascinated with the visual, as opposed to the computational disciplines.)

It can be easy (although probably no easier than any other excuse) to have Imposter Syndrome when your formal education is founded on a multi-disciplinary degree, i.e. Jack of all trades, master of none. However, as some have pointed out…

“Learning isn’t a zero-sum activity.”

– “The Myth of the Myth of the Unicorn Designer” by Thomas Cole

Code Is Poetry

My first few jobs heavily involved HTML, CSS, and Flash, of course, as well as dabbling in many other languages and systems. However, I quickly gravitated toward WordPress when I was tasked to research alternative content management systems (CMS) for a state college. I started to become familiar with all the concepts that made up a good and bad CMS and was able to research where each private and open source solution lie on the feature vs cost spectrum. I became passionate about the idea of open source software, and WordPress was, and still is, at the forefront.

Today, the WordPress tagline “code is poetry” has become a mantra in my everyday work. So much of what we, as Front-End Developers, write relies on syntax, logic, and structure. Also, good code (as there is plenty of bad code and poetry) requires elegance and simplicity. The meaning with code and poetry can be both on the surface and simultaneously abstract.

Enough About ME!

So why am I giving you my entire bio? Because again, I think it is important to providing context to why I’m fascinated and passionate about composing CSS. In the upcoming posts, I’ll cover some key points along the history of CSS to try and demonstrate where I see CSS evolving. Remember, writing code is a multi-disciplinary venture, and one should never stop learning.

Stay tuned for the next post in this series:

• Evolution of CSS – Part II: CSS Class Naming Conventions
• Evolution of CSS – Part III: Overview of Tachyons

The post Evolution of CSS: Becoming a CSS Composer appeared first on WebDevStudios.

“Please, no matter how we advance technologically, please don’t abandon the book. There is nothing in our material world more beautiful than the book.” –Patti Smith

There are many great pathways to glean new information out there, whether it be on the web or in a class. Your mileage may vary depending on your learning style or the topic at hand. With the tech industry, evolution often occurs at a faster rate than print media can keep up.

Still, sometimes a good ol’ print version of what you need comes along that earns its place on your bookshelf. Maybe it got there after you heard it mentioned for the tenth time. Maybe it is the book you always find yourself lending out to someone when they want to dip their feet in to a new niche (regardless of the evolution of name-your-favourite-framework-here.js). Maybe it is the book that someone leant to you at a crucial step of your learning. There are brilliant books for front-end developers out there–and they are definitely worth looking over.

A single book won’t be able to provide you with the breadth of information necessary, especially with today’s multi-dimensional coding ecosystems. Often, books cite wonderfully curated online resources so you are able to use their foundation as a jumping off point for knowledge expansion.

The WordPress-specific

WebDevStudios is abundant with people who know more than a few things about WordPress–with a stack of books to their credit, no less! One book from this list is Professional WordPress: Design and Development, which starts from a top-level view on WordPress then digs down into all the nitty-gritty. Sure, I’m biased, but this is a wonderful additional to any WordPress developer’s bookshelf.

The Process

For those who want to know more about the principles of intuitive navigation and information design, Don’t Make Me Think: A Common Sense Approach to Web Usability, by Steve Krug, is an excellent straight-forward resource for both beginners and the more-seasoned on how people connect with interfaces. This is a good resource for management, designers, and developers alike.

The Visual

Are you more visually inclined? Jon Duckett’s books on HTML/CSS and JavaScript/jQuery may be a good fit. They each include code examples and there is a general assumption of little-to-no previous programming experience that make these a good beginner’s starting point and reference.

The Varied

Smashing Magazine offers many great resources and one compilation is Smashing Book 5: Real-Life Responsive Web Design. While responsive design is a default these days, this gathers techniques and strategies on everything from workflow to SVGs to debugging. (There is a level of assumed knowledge and experience in many chapters.)

The Non-Code Code Books

• Code: The Hidden Language of Computer Hardware and Software: Starting with Morse Code and working its way linearly through telegraphs, barcodes and I/O devices, this isn’t going to teach you how to better implement code but you will likely have a new respect for the history behind the work you’re doing (Published in 2000, so don’t expect discussion of technologies beyond)
• Quiet: The Power of Introverts in a World That Can’t Stop Talking: Okay, this one has truly nothing to do specifically with code. This book explores the dominant values of business culture and how the leadership potential of introverts is often overlooked.

What are some other must-reads that you have on your bookshelf?

The post Helpful Books for Front-End Developers appeared first on WebDevStudios.

There were some caveats though…browser support was just okay. To make @font-face work across Chrome, Safari, Firefox, IE, and mobile, you had to enqueue a bunch of different font file types…then do things like, “Bulletproof the @font-face syntax.” All of this introduced a bunch of extra HTTP requests and overhead.

Soon after, Google Fonts and TypeKit came along. Developers once again rejoiced because these services made it super easy to use custom fonts; without all the “@font-face overhead”. Those services are still relevant today, and a GREAT way to serve custom fonts. But…

…what if a client needs a custom font not listed on Google Fonts or Typekit?

In 2010, developers would have needed to enqueue five different fonts files, e.g.;.eot, .svg, .ttf, .woff, and maybe .otf.

In 2016, I will show you how to enqueue–and use–a single font file type: the .woff.

Introduction

For this demonstration, I’ll be using Fenton. It’s a free font from Fatih Güneş, licensed under CC v4.0. Which means I’m free to use however I want (as long as I give reference). This is important, because not all fonts are licensed this way! Make sure that fonts ARE ALLOWED to be used on the web!

Here are all the available Fenton fonts:

For the rest of this demonstration, I’ll be using Fenton Light, Regular, and Bold.

Generate Web Fonts

Font Squirrel is the go to @font-face generator. It can take any (normal) desktop font file, and convert it to a web ready “@font-face” font.

Generally, I just select “optimal” and let Font Squirrel do its thing. Font Squirrel will give us those five familiar font file types: .eot, .svg, .ttf, .woff, and the new .woff2

Define Browser Requirements

Now that we have our web-friendly fonts, what are the browser requirements? For this demonstration, we only need to support IE9+. Let’s look at the browser support for each font file type:

Source: caniuse.com

By this logic alone, you can see that the .woff file type will work in all browsers, including IE 9.

Note: Opera Mini doesn’t support @font-face. Like, at all. So make sure you declare a backup font like “sans-serif” or “serif” in your font stack!

woff vs woff2

According to the W3C, .woff is the “Web Open Font Format” and as you can see from the graphic above, has excellent browser support. According to Wikipedia, .woff2 has a “30% reduction in file size…” In other words, .woff2 has better compression, but according to caniuse.com, browsers like IE  11 wont and Safari only supports it on El Capitan and above.

All this aside, you will be just fine using .woff!

Enqueue The Custom Font

Now it’s time to enqueue our fonts. Let’s take a cue from Google; this is how they enqueue Open Sans:

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'), url(https://fonts.gstatic.com/s/opensans/v13/cJZKeOuBrn4kERxqtaUH3bO3LdcAZYWl9Si6vvxL-qU.woff) format('woff');
}

They’re declaring a font-family, the style, the weight, and specifying the source. But what’s really going on?

Basically, the @font-face declaration is looking for the font on the user’s computer first. If it’s not there, it will download that font. What about the “different spelling thing?” Let’s look at how FontBook displays Fenton:

Notice how it’s “Fenton Regular.” Sometimes this might read, “Fenton-Regular” or “fentonregular.” By checking for different variations in spelling, we’re just covering all the bases. Moving on…

Awesome, we’ve knocked our custom font down to only three HTTP requests, once for each variation. Furthermore, if the user already has this font installed, then there won’t be any extra HTTP requests! Boom!

Finally, Using A Custom Font

Let’s move each font with the .woff file extension into our theme:

/cool-theme
  /assets
    /fonts
      fenton-bold-webfont.woff
      fenton-light-webfont.woff
      fenton-regular-webfont.woff
style.css

Then in style.css, we’ll declare our @font-face:

// Fenton Light - 300
@font-face {
 font-family: 'Fenton';
 font-style: normal;
 font-weight: 300;
 src: local('Fenton Light'), local('Fenton-Light'), url(assets/fonts/fenton-light-webfont.woff) format('woff');
}

// Fenton Regular - 400
@font-face {
 font-family: 'Fenton';
 font-style: normal;
 font-weight: 400;
 src: local('Fenton Regular'), local('Fenton-Regular'), url(assets/fonts/fenton-regular-webfont.woff) format('woff');
}

// Fenton Bold - 700
@font-face {
 font-family: 'Fenton';
 font-style: normal;
 font-weight: 700;
 src: local('Fenton Bold'), local('Fenton-Bold'), url(assets/fonts/fenton-bold-webfont.woff) format('woff');
}

Now, we can actually start using our font:

body {
  font-family: Fenton, sans-serif;   // Try to load Fenton, if all else fails, load the operating systems default sans-serif font.
  font-weight: 400;   // This will load "Fenton Regular".
}

h1 {
  font-weight: 700;   // This will load "Fenton Bold".
}

p {
  font-weight: 300;   // This will load "Fenton Light"
}

By declaring the font-weight, we’re telling the browser to use a different font. That’s it!

No need to mess with font stacks! What’s better is, no more “bulletproofing” or expensive HTTP requests.

Conclusion

I’ve shown you an updated way to work with custom fonts. If you don’t need to support IE8 or older Android browsers, this method will speed up your website by reducing HTTP requests and serving an optimized font file (.woff).

If you’ve got any tips or tricks to expand on this, please leave a comment below.

The post CSS @font-face: 2016 Edition appeared first on WebDevStudios.

Don’t simply default to the latest trend.

I’m sure you’re thinking something like “Well, no duh! That’s nothing new!” but what I want to do is challenge you to think about these two things a little differently than you normally would.

Putting the focus on the user should always be paramount, but don’t just stop at, “It works for our target users. Ship it.” If you really want to create something, like MailChimp, that will be a joy to use and have people talking about for years to come, you need to go a few steps further to make sure you can say, “It works and our audience loves using it.” It’s the reason most of us would probably choose a BMW over a Ford Focus; one looks fine and gets you from point A to point B, but the other looks beautiful and is a joy to drive.

So you want to focus on the user and give them a wonderful experience, but how? One of the best ways you can accomplish both is to simply not default to whatever the latest web trend is. If this sounds kind of vague, allow me to demonstrate:

The site on the left defaults to using most of the trends I’m going to talk about, such as a slider with generic stock photos, clip-art, or stock graphics, and a basic, slightly messy grid.

Contrasting this, the site on the right uses a grid of stories on top that contain more interesting photos that don’t look staged, custom graphics that are interesting and pique interest in the articles, and a more compelling, tidy grid.

Most people would agree that the site on the right is the BMW, but how can you achieve the same effect with your site? Let’s go through the most common web patterns today and look at some alternatives, or anti-patterns.

Stock Photos

The scourge of the internet…sort of. Stock photos have become become practically synonymous with bad or generic design, and not just with web designers. There are many websites and memes making fun of just how bad a lot of stock photos are, including this hilarious parody by Vince Vaughn poking fun at the popular web trend.

We can’t just swear off pictures, though. Imagine the internet without funny cat pictures—horrid, right? Well the good news is that there are plenty of alternatives.

Anti-stock photos

In recent years, a swarm of anti-stock photo sites have popped up offering free or very affordable alternatives that are often less staged and better quality than their paid counterparts. Some of my favorites include:

• Death to Stock
• Unsplash
• Picjumbo

Custom Photography

You can’t beat going with custom photos on your website. Most cities have an abundance of local photographers ranging in prices that you can hire to take photos of your team, products, etc. and you can feel good about helping a local artist/business out in the process!

Stock Icons

This one is a bit different from stock photos; most modern icon sets actually look good. The problem is that web designers have been relying on them so much that they rarely offer anything new or unique to the website. If you’ve fallen into a rut of just sticking your favorite stock icons in every design, here are some alternatives to help your design stand out:

Custom Icons

You guessed it—going custom! The main benefits of creating custom icons is that you can truly make them match the brand and ensure your clients is getting something unique from their competition. The downside of course, is that it does add a decent amount of time to the project.

Customized Icons

An alternative that I like is to take some of my favorite icon packs and customize them to the project. Take a look at the before and after of these icons. I simply added some color from the brand and an extra design touch with the lines and waves to create a more personalized feel. These extra elements even add a little more descriptiveness to the icons as well.

Animated Icons

Another option is to animate your icons with AfterEffects, or even better, CSS. This option can help create a more dynamic, interactive feel that’s more eye-catching for key information.

Layout

Layouts on the web have gone through a lot changes over the years, from main content areas with prominent sidebars to the “bands” of full width content seen today. With the advent of Flat Design, our sites have cleaned up a lot, but in the process we’ve also boxed ourselves into a, well, boxy design trend.

Getting Creative

Jen Simmons has been a proponent of finding information for our designs and layouts in places other than other websites–specifically, magazines and books. These print mediums offer an insane amount of diversity and creativity, and while we can’t achieve everything print can with the web, we can certainly use it as an influence to create some more interesting layouts and effects. Take a look below, normally on the web, floated images and text appear pretty blocky:

…but watch what happens when we apply one CSS rule, shape-outside: polygon; to our image:

A simple CSS change and we have a cool new, magazine-like layout. View my CodePen for this here.

Summary

We covered a lot of common patterns and some alternatives to them, but there are many more out there and many more to come. So go try some of these tips out on your next design and let me know how it turns out for you!

The post Web Design Anti–Patterns: Setting Your Site Apart appeared first on WebDevStudios.

“Does my sassiness upset you? Why are you beset with gloom?” ~Maya Angelou

Don’t be gloomy; be Sass-y. Sass is powerful because it can increase your code efficiency and helps introduce more modular elements that can be incredibly helpful for using across larger projects.

Sass-y Colors

One thing you might already be aware of is the ability to create color variables (check out our starter theme wd_s for some examples of this). Creating variables is great to help differentiate hexadecimal codes (#DC143C) to something more palatable ($ruby-red-slippers). Let’s use those variables and ramp them up to help streamline other portions of your site!

Color functions combined with the ‘for’ control directive can lead to a magical world of loops. And as someone who works at a WordPress company, I am ALL ABOUT LOOPS.

The code above is an example of utilizing an existing color variable within a ‘for’ directive. Loosely translated into human-speak, it is saying for all elements ( $i ) from one to fourteen that have the class of ‘box’, increasingly darken the background color by a factor of three.

Depending on your content, you’ll wind up with a gradient-type design going through your grid of boxes without having to sort out all the different hexadecimal codes.

Now, what if you want to create a consistent effect across your site for an element like a button? You can create a mixin using color functions to streamline it!

@mixin buttonColorProperties($color) {
    $border: adjust-hue($color, -6deg);
    background-color: $color; 
    border: 3px solid $border;
}

@mixin buttonColors($baseColor) {
    @include buttonColorProperties($baseColor);
  
    &:hover {
      $base-hover: darken($baseColor, 30);
      
      @include buttonColorProperties($base-hover);
      transition: all 0.25s;
    }
}

.button-purple  {
  @include buttonColors($violet-base);
}

The concept is to supply one base color and let the mixin take care of the other aspects you would like to define. In this case, the button is supplied the base color. From that variable, the hover effect and border are taken care of automatically.

What happens when you combine the first ‘for’ directive with the mixin? You get a lot of purple and a less-than-subtle button design but you also get a gradient of button backgrounds and an automatically implemented hover effect. Keep in mind that you can add other variables within your button design (maybe a highlight or a shadow?).

Go forth and be Sass-y. And if you create a cool button mixin*, be sure to share it with me!

_{*(Bonus points if it involves purple.)}

The post Getting Sass-y with Color Functions appeared first on WebDevStudios.