Talk: What Meta Tags Your Site should be Using

There are tons of valuable tags you should be placing within the <head> tag that can really make your site more valuable, accessible, and help showcase it on social media platforms before people even click on links to your site. In this talk, we?re going to go through which tags you should absolutely be placing in the <head> tag of your site if you want to get the maximum exposure and shareability possible. All of these are <meta> tags ? with the exception of one ? and the majority of them are related to how links to your site will render when shared on various social media platforms.

What Meta Tags Your Site Should be Using

Whenever you’re building a new site, you probably pay more attention to the HTML that’s in the <body> tag (i.e. the actual content) than what’s in the <head> tag – and that’s a good thing! If your page doesn’t have rich, valuable content – then it probably shouldn’t be there, but that doesn’t mean that you should put everything else on the backburner. There are tons of valuable tags you should be placing within the <head> tag that can really make your site more valuable, accessible, and help showcase it on social media platforms before people even click on links to your site. In this post, we’re going to go through which tags you should absolutely be placing in the <head> tag of your site if you want to get the maximum exposure and shareability possible. All of these are <meta> tags – with the exception of one – and the majority of them are related to how links to your site will render when shared on various social media platforms. I’m gonna group these into a few different categories:

  • General
  • Open Graph (i.e. Facebook)
  • Twitter

Ready? Let’s get to it!

tl;dr

Before we get into the explanations of all the meta tags, if you just want a quick example of what core meta tags I recommend every page should have (and the one’s we’ll be discussing), then here it is:

These meta tags are taken directly from this webpage. Now that we have that out of the way, I hope you’ll continue reading to see what these tags actually do and why they’re important!

General

These are gonna be the tags that every site should have, regardless of how you plan to use it.

Title

This one’s pretty easy to understand and it’s absolutely the most important tag you should place within your <head> tag. It’s also the only tag we’ll be talking about that’s not explicitly a <meta> tag – this one gets a tag all to itself. You probably already knew this, but the <title> tag sets the title of the page. This will be the title that you see in your browser tab, your bookmark menu, Google results, and practically anywhere that your site is shared. It’s a must to set this.

Viewport

Next to the title, the viewport meta tag is extremely important to have in your site because without it, your site won’t render properly on smaller screen sizes such as mobile phones and tablets. The viewport meta tag gives the browser instructions on how to control the page’s dimensions and scaling. On smaller devices by default, browsers will try to scale down the entire web page width to fit on your screen just like it would on a desktop monitor; you’ve probably seen this if you’ve viewed websites that haven’t been built recently, and you have to zoom in to actually read the content. With modern responsive websites, we don’t want that default behavior. We have the power to build websites that break down properly for smaller screen sizes, and in order to render these sites properly, we need the viewport tag.

Here’s an example of a basic viewport meta tag:

This tag sets the width of the page to the device-width (i.e. your viewport width), and the initial scale attribute sets the zoom level to 1, so that you’re not viewing a zoomed-in or zoomed-out version of the page.

Character Set

This meta tag sets the character set of your website. Browsers need to know which character set your site uses in order to render your content properly.  UTF-8 is the default character set for all HTML5 sites – but you still should be explicit about setting it because in HTML4, the default is ISO-8859-1. If you’re using HTML5 (which you should be), then this tag looks like this:

But if you’re stuck using earlier versions of HTML, then you’d use the http-equiv property to set the character set:

Description

The meta description tag sets a 255-character-max block of text that accurately describes the page you’re on. This tag has been the standard for services like Google, Facebook, Slack, and many others to pull in your page’s description for others to see, which makes it very important.

The limit that any service will pull from your meta description is typically 255 characters, so make sure you stay concise with it!

Open Graph

You probably read “Open Graph” above in the intro and may have thought, “what the heck is that?” Open Graph is a protocol that Facebook created that allows any web page links to become rich objects in a social graph. Whenever you paste a link in Facebook (along with many other services) and it automatically creates a clickable block with a title, description, and/or image from that site – it’s using these Open Graph meta tags to do that. Before I knew what was going on here, it always seemed like magic to me when this happened – but it’s all just from simple meta tags! The Open Graph protocol is abbreviated to og when used in HTML.

I’m gonna display a chunk of Open Graph meta tags here, and then we’ll talk about them.

You’ll notice that some of these tags seem redundant compared to the other tags we’ve added so far – and truth be told, I agree. But the Facebook Open Graph debugger throws warnings if you don’t have an og:title or og:description, so it’s best to include them for maximum accessibility.

og:title

This purpose of this meta tag is similar to the <title> tag that we discussed above, but strictly used when sharing a link to your web page. It wont be used for browser tabs, bookmarks, or Google search results like the actual <title> tag.

og:type

This describes what type of content you’re linking to. More often than not, this will be set to website, but as you see in the example, it doesn’t have to be. Check out the Open Graph docs for the various values that this meta tag can be set to.

og:url

This is the canonical URL that the Open Graph object will reference when shared, and it should 99% of the time be set to the URL of the page you’re linking. The only other value this should really be set to would be something like a home page, in case the current page (e.g. a 404 page, unauthorized page, etc.) really isn’t something you want shared.

og:image

Open Graph Object Example
Open Graph Object Example

This is probably the one that you’ve come across most often as a user, and the one that Open Graph really pioneered: an image meta tag. This tag links to an image file, and if it exists, it will display that image when shared on many social media platforms. While Open Graph was originally built by Facebook, several other services such as Slack, LinkedIn, Google+, etc. all use this to pull in an image when you share a web page.

Typically only JPEGs and PNGs are supported, but it’s really up to the platform you’re sharing it on. If they want to render gifs or svgs, then they can do that. When choosing an image size, there are a couple of recommendations.

1 – The image should be reasonably sized. Facebook and other services typically limit it to 8mB, but you really should never have an image that big on the web. My personal goal is to keep all images under 500kB.

2 – This is Facebook specifically, but they recommend an aspect ratio of 1.91 to 1, and further recommend images to be 600 x 315 or 1200 x 630 pixels. You can choose an image with any aspect ratio, but abiding by these guidelines will make sure that parts of your images don’t get cropped out.

og:description

Just like og:title is a doppelgänger to the title tag, og:description is similar to your meta description tag.

That covers the basic Open Graph meta tags, but as I mentioned earlier, there are more than just these if you want to get nitty-gritty with your site’s content. Let’s move on to our final category.

Twitter

Twitter has it’s own protocol suite for meta tags, and they involve rendering a “card” to your tweets which look just like Open Graph objects. In fact – Twitter will actually use Open Graph meta tags that you already have to help render your cards, which is nice so that you don’t have to duplicate any meta tag content. Here’s a base example of what meta tags you should use for Twitter:

There are more meta tags that Twitter supports such as image, title, description, etc., but the tags shown here are the important ones that are unique to Twitter. You can add those other meta tags – but as mentioned earlier, if they aren’t present, Twitter will go ahead and use the data provided by your Open Graph tags – which is what I prefer.

twitter:card

Twitter Summary Large Image Card Example
Summary Large Image Example

This is the most important twitter meta tag, and it’s required if you want to render a card at all. The various values can be one of ?summary?, ?summary_large_image?, ?app?, or ?player? – all of which you can read about here. The default value should be “summary”, unless you want to showcase a featured image, in which case you would use “summary_large_image.”

twitter:site

This meta tag describes the twitter username for the website used in the card footer, and is required if you want to track attributions to this username through Twitter Card Analytics.

twitter:creator

This meta tag describes the twitter username for the content creator/author.

That wraps it up for the must-have Twitter meta tags. As mentioned, there are plenty more, and if you’re interested you can read up on them here.

Final Thoughts

Did we cover every meta tag out there? Absolutely not – but we covered a lot of them that are pretty important. Some of the ones we missed out on include a whole suite of meta tags dedicated to deeplinking, where you can do things like tell an operating system (such as iOS, Android, or Windows Phone) to open up an app when you land on the webpage instead of rendering the webpage itself. You’ve probably seen this type of action happen when you click on a Twitter, Instagram, or Amazon link. We didn’t cover the author meta tag either, or different things you can do with the http-equiv attribute, or the keywords meta tag – and that last one’s for good reason; the keywords meta tag has become pretty unimportant, and if any SEO “gurus” try to tell you that it is important – then run. Run away, because that’s a bold-faced lie.

Now that you know the purpose of some of the various meta tags and how to use them, you can go update some of your projects to make them more shareable! I hope you enjoyed this post and learned a little bit more about how to power up the HTML in your web pages.

Optimizing Your Web Page for Speed

We’ve all had it happen – that web page that you navigate to, and you can’t hardly interact with the page for a full 10 seconds because images are still loading, or you can’t scroll down because Javascript is still executing, etc. These are what we call unoptimized web sites, and they’re a scourge among the internet. The good news is that it’s relatively simple to optimize your web page and allow it to load practically instantaneously – or at the very least, not hamper the interaction for your users while you’re waiting for larger files to fully download. Keep following along – I’m about to show you how to do it.


Note: This post covers shrinking your web page’s overall payload so that it loads quicker, and nothing related to Search Engine Optimization. If you’re looking for SEO – the internet has a plethora of other posts about this topic.

Optimizing Images

Shrinking the payload of your images is the biggest way that you can help to optimize your web site. Let’s say that you snap a photo with your mobile phone and you want to put it online. That image from your phone easily sits at about 4MB initially – and there’s no way you can put that on your website (especially if it just needs to be a thumbnail!). You might be thinking “but that’s what I do with Facebook and Instagram!” – but they have image optimization built into their services that fires when you upload the image, because they don’t want to house those large images either.

th-tulsaf35-1
This image was a 2 MB screenshot at first – now it’s just 20 KB!

Another thing you might be thinking is that you don’t want to degrade the quality of your images by shrinking their size – and truth be told, that’s just not a real concern. It’s true that when you shrink your image sizes, you will lower the quality of your images, but if you’re uploading a 3000 x 4000 pixel image to your website and your site naturally shrinks it down to 300 x 400 pixels anyway – then you’re losing quality already without saving yourself any of that payload size.

To optimize your images, there are 3 things you can do:

  • Crop your image to a size that you actually plan to show it at on your site
  • Re-save the image at about 60 – 70% quality (you won’t notice the difference) using a tool like Photoshop or Gimp
  • Use a non-lossy image optimization tool such as ImageOptim

By following these 3 procedures, you can easily bring a 4MB image down to under 150KB – or even far less if the image is smaller on your site!

Minimize & Concatenate your CSS & JS

If you’re unfamiliar with these concepts, minimizing means running your CSS and JS through a tool which goes through your code and moves it all to just one line, removes extra white space, shortens variable names, and a slew of other optimization techniques to shrink your file size. Minimizing your files can easily cut their payload in half – and it doesn’t affect how your users interact with your site at all.

You only want to minimize your production files – because developing minimized files is near impossible. To help with this, I encourage you to look into a build automation tool such as Gulp or Grunt to make your life easier. For JS, you can use gulp-uglify, and for CSS there’s gulp-minify-css (similar libraries available for Grunt and other build automation systems). Going further for CSS, there’s also gulp-uncss which will strip out any CSS you have from your production files that’s not actually used in your web site. It doesn’t get much better than that!

On top of minification, you should concatenate your CSS and JS files so that your users’ browsers only need to download the minimum number of files for your site. Using Sass makes CSS concatenation nice and simple because you can include all your other Sass files into one main file via the @import command, but native JS concatenation is a little more difficult. The new ES6 spec supports Javascript modules so that you can include all of your JS files into a main file, just like we talked about with Sass, but ES6 doesn’t have near enough browser support yet. You can make this better with Babel, or if you want to stick with pure ES5, you can use Browserify which allows you to write CommonJS-style modules.

Still – none of this accounts for external libraries you include such as jQuery or Lodash, which are normally just loaded into the global scope of a web page. To get the most code-supportive practice of concatenating JS files (and CSS files, if you’re not using Sass), you should use a build automation plugin such as gulp-concat where you specify exactly which files you want to concatenate, and it just appends the code one after another into a new file.

Easy peasy.

Limit Web Fonts

Just like images, CSS, and JS, fonts are also a resource that count towards your page’s overall size – and if you overload your site on fonts, then you might have a problem. Services like Google Fonts and Adobe Typekit have become pretty traditional ways of adding fonts to your website – and each of them allows you to select certain versions of fonts to use, such as bold, italic, semibold, bolditalic, light, etc. Each version of a font has to be downloaded by the browser, and the vast majority of times you don’t need every version of a font. I strongly, strongly encourage you to select exactly which font forms you need instead of selecting them all. Being choosey with your fonts could mean the difference between adding 50KB and 500KB of extra weight to your page from fonts.

Use Caching

Last but not least, make sure you establish a cache policy for your website. This can be handled a number of different ways depending on whether you use nginx or apache, and if you’re serving up a dynamic site, then there’s a good chance your CMS or language framework supports forms of both client-side and server-side caching (such as WP Super Cache for WordPress).

This topic can get pretty extensive, and if you want to dig deeper into how caching actually works and how to start establishing a stable cache policy, I encourage you to check out my post over How Browser Caching Works.

Final Thoughts

Building an optimized web page these days is incredibly important – especially with mobile phone browsing becoming much more prevalent; after all, you can imagine how annoying it must be for your users to sit and watch while your web page loads – especially if you know you can make it better. There are some users (especially in non-first-world countries) which have a very low monthly data cap too, and if your web site alone takes up 10% of that whole data cap – then that’s just a big no-no.

If it’s your first time really thinking about page optimization, then don’t rush things. Go through this post slowly and build a development process for yourself that you can use for all future projects you work on. After you build one or two sites following these practices, it becomes second nature to optimize everything on your site as you build it – and you may even find ways to optimize your site that we didn’t discuss here (such as uploading videos on YouTube and embedding them on your site, instead of playing them directly through your website).

Thanks for reading, and I hope this post helped to open the doors for you on how you can start optimizing your web pages!

ARIA Roles and Attributes: How to Actually Use Them

If you’re a web developer, then there’s a chance that you’ve heard of ARIA roles and attributes before. WAI-ARIA – a protocol suite for building Accessible Rich Internet Applications (hence the name) – lays down some rules to help developers build websites that are accessible for all users. A lot of the times when we think of accessibility, we only think of blind users – but there are a lot of other types of disabilities that people may have such as color blindness, motor impairment, lack of limbs, auditory issues, cognitive issues, “crisis” moments, etc. Using some of the core ARIA concepts can not only help you build websites that enhance the experience for users with disabilities, but it will also help you architect your HTML better and make it more semantic – and doing things like that will help you to become a better developer.

ARIA by no means makes up the entirety of accessibility concerns for web development, and if you’d like to learn how else you can build your website for accessibility, I suggest you hop on over to my post about Developing for Accessibility. In this post, we’ll specifically be sticking with ARIA roles and attributes, and how you can actually use them.

What I mean by “actually use them” is that I’m going to show you how to take your first simple steps implementing ARIA concepts into your HTML. If you google around for ARIA, you’ll likely find two kinds of resources:

  1. On one end of the spectrum, you’ll find the overwhelming documentation over every single ARIA role and attribute (and there’s a ton) to the point where your eyes glaze over just scrolling down the page
  2. Or, you’ll find some small posts and/or videos about accessibility that basically say “I’m not going to go over ARIA too much, but here are some of the roles you can put in your HTML to help with accessibility.”

Both of these options suck – because they’re not effective at teaching you. I want to provide a middle ground between these two categories. I’m going to show you how exactly you can use ARIA roles and attributes in your HTML today with real examples – but I’m not going to throw a book of documentation at you. We won’t go over everything – in fact, we’ll probably scrape less than 30% of the full WAI-ARIA spec – but we’re gonna cover an important amount that will make sense enough for you to actually use and remember it.

Ready? Let’s get to it.

How ARIA Roles and Attributes Work

Before we get to some examples, I want to explain what ARIA roles and attributes are and how they work. ARIA helps to define attributes that you apply to HTML elements just like an href or class attribute. As a user with little or no disabilities browsing the web, you won’t ever notice ARIA roles or attributes because they don’t affect the visual design of a site – they’re strictly used by screen readers and other assistive technologies.

Browsers build accessibility trees for each website that you visit so assistive technologies can navigate them easier. ARIA roles and attributes help to fill in the gaps of information about what certain elements or groups of elements are for, and how an element is supposed to be used.

Here’s an example of an unordered list aided with ARIA roles and attributes:

Just by looking at it, this type of semantic HTML probably makes sense to you. Without the help of ARIA, this would just look like a list of items – but now you can tell that this is supposed to be a menu and with the aria-expanded state set to false, you know that this menu isn’t showing the individual menu items yet.

Rules of ARIA Use

There are a few core rules to keep in mind when using ARIA:

  1. If you can semantically build your website using native elements (like <nav>, <header>, <aside>, <button>, etc.), then you should always do that instead of relying on ARIA roles or attributes. Use ARIA roles or attributes when the HTML isn’t obviously stating the purpose of an element or group of elements.
  2. Don’t take away or change the native semantic meaning of an element with ARIA roles or attributes.
  3. All interactive controls such as a button, sliding control, or drag-and-drop widget must be usable by the keyboard.
  4. There are 2 ways to hide information from the accessibility tree, which should be used very sparingly for situations where content is unimportant or meant to be hidden. You can do this either with role=”presentation” or aria-hidden=”true”. You should never use these on an element that is visible and can be focused with the keyboard, such as an input field or a link. Defining a presentation role is more strict than an aria-hidden=”true” state – and we’ll see an example of this down below.
  5. Lastly, all interactive elements such as form fields should have a name associated with them. Something like a <label> is perfect, and with ARIA, you can even specify that a certain element is labelled by or described by another element.

Great – we’ve now gotten all of the introductory ARIA stuff out of the way – let’s get to some examples of how you can use ARIA roles and attributes in your HTML today.

Using ARIA Roles and Attributes

ARIA breaks down into 3 categories: roles, properties, and states. Roles define the purpose of an element, properties help better describe what an element can do, and states are like properties that are designed to change – normally with the help of Javascript. An element can only have one ARIA role at a time, but can have as many properties and states as necessary.

Let’s start off simple.

Define your main header, content, and footer

Each page normally has an identifiable header, main content, and footer – and there are specific ARIA roles designed to help express these elements.

The banner, main, and contentinfo roles are meant to be used only one time per page, and they help screen readers figure out how a page is laid out on a high-level.

See, using ARIA roles is easy! Let’s get a little deeper.

Label and Describe Elements

If an element seems rather vague, but could either be given a title or described by another element, then you can define that relationship using ARIA. There are 3 different ARIA properties that can help with this:

Aria-label is a property that defines a short title for an element; aria-labelledby references the ID of another element, which is a short title for the element; and aria-describedby is just like aria-labelledby – but is meant for longer descriptions instead of short titles. Here’s an example of this using a buttons’ tooltip:

For shorter labels of important elements, such as a lightbox that contains a larger version of the image you clicked on, you can use the aria-label property:

Now it’s important to remember that we don’t need to label everything, especially if there’s already a predefined way of labelling an element such as a <figcaption>, title attribute, or an image’s alt attribute. We only need to label something if the HTML doesn’t clearly indicate the purpose of an important element.

Navigation

This topic’s going to be a bit extensive, but that’s because navigation is one of the areas of a site that you really want to get right since people need it to, well, navigate around. Normally this involves <nav>, <ul>, <li>, and <a> elements. Let me give you an example of a solid nav bar set up with ARIA roles and attributes, and then we’ll talk about it:

Lots of roles and attributes, right? Like I said, navigation is one of the most important parts of a website, and that’s why making sure the accessibility tree can build it properly is so important too. In this example, we defined the navigation with a navigation role, and its child unordered list as being a menubar. This means that the navigation is visually presented as a horizontal menu bar as opposed to a vertical menu (which instead would use a menu role). Beneath that, we have our list of menuitems. When we get to a menuitem that has a sub-menu that pops up, then we give it an ARIA property of aria-haspopup=”true”. We give the sub-menu a role of menu because this is a vertical submenu, as well as an ARIA state of aria-hidden=”true”. The reason this is a state is because the sub-menu is initially hidden from view, but when you hover over the parent menuitem, the sub-menu would appear, and then hide again when you aren’t interacting with it. With Javascript, you could change the state to be aria-hidden=”false” while the sub-menu is visible, and then back to true again when it’s not.

ARIA rule #3 above stated to be hesitant to use aria-hidden=”true” – but this is a perfect example of how to use it properly. The aria-hidden property deals with whether an element is supposed to be visible to a user at a certain time, while the presentation role straight up removes the element from the accessibility tree – which we certainly don’t want to do for navigation.

This same type of structure works for lists that aren’t necessarily menus – but instead of menu and menuitem roles, you would use list and listitem roles. Everything else such as properties and states remains exactly the same.

I know there are a lot of ARIA roles and attributes here – but you can reasonably assume that just about every nav – regardless of exact HTML structure – will follow an ARIA architecture similar to this example.

Tab Lists

Another common way you can use ARIA labels and descriptions is when you build a tab widget on your page, where you click tabs to reveal different content. On top of ARIA labels though, we have some other neat tab-specific ARIA roles and properties I want to show you. Specifically, they are:

  • tab – a clickable tab which reveals content
  • tablist – the container which groups the clickable tabs
  • tabpanel – the actual content of the tab
  • aria-controls – a property that’s not tab-specific, but helps indicate that an element controls another element

Tab lists are one of those things which really requires a lot of visual acuity to understand how they work, and without semantic HTML elements specific to tab architecture, it’s difficult to make tabs accessible by default. That’s why it’s so important to build them accessibly with ARIA roles and attributes. Here in this example, we’re doing a lot of different things:

  • Setting ARIA roles for the tablist, tabs, and tabpanels
  • Stating which tab controls which tabpanel
  • Stating which tab labels each tabpanel
  • Handling the aria-hidden state to indicate which tabpanel is visible at any given time

This, my friend, is proper and accessible HTML architecture.

Forms

Last, and perhaps most importantly, it’s absolutely essential that you make the interactive portions of a website as accessible as possible – and usually that ends up being your forms. There are a lot of various ARIA roles and attributes that can be applied to forms, so I just want to highlight some of the ones that are important to include:

  • form – pretty simple, just the landmark role for a <form>
  • search – the role for a form with the primary function of searching data
  • aria-required – property indicating whether a field is required
  • aria-invalid – property indicating that the value of an input field is invalid (wait until after form submission to add this)

On top of ARIA roles, there are a couple important things to consider when building accessible forms.

  1. It’s incredibly important that each form field has a valid <label> associated with it which either wraps the form field or references it with the for attribute. If this isn’t possible, then you can use the ARIA labelling methods discussed above. You cannot substitute the placeholder attribute for a label because it’s not meant to be handled as a label; a placeholder is meant to simply be an example of what you’re supposed to enter in that field.
  2. Forms are often times tabbed-through via the keyboard, so it’s important that the tab order makes sense. Normally this isn’t a concern, but if you position or hide certain input fields via CSS/Javascript, then the tab order might become unintuitive. When this happens, you can set the tabindex attribute of an element to make sure that the tab order is how you expect it to be.

Here’s an example form with proper markup:

I threw in a couple extra ARIA roles and attributes such as radiogroup and aria-multiline – but that’s just to show how specific you can get with them. Notice how we didn’t add a radio role to the radio buttons (which is a valid ARIA role) – that’s because a radio input field itself semantically expresses how that element is supposed to work, and we don’t need to express that again with ARIA. However, because the wrapper of those fields is just a <div>, we still went ahead and gave it a radiogroup role.

Mostly, I just wanted to show the importance of labelling your input fields and how you can flag certain fields as required via ARIA attributes. If any field were invalid during the submission, then we would add an aria-invalid=”true” state onto each invalid field, and remove that state when the field becomes valid again.

Final Thoughts

We went over a lot of examples, and there’s still many more ARIA roles and attributes that we didn’t talk about – so feel free to check out the ARIA docs if you want to learn more.

To me, I love building accessible websites because it really feels like the right thing to do, but I like it for another reason too: I’m huge into code architecture and organization, and using ARIA roles and attributes helps me to architect my HTML much more semantically – and I love that. I hate using un-semantic elements such as <div>, <span>, and sometimes even <ul> – but if I can add an ARIA role such as contentinfomenutreeitem, status, and more, then I’m infinitely more happy because I’ve appropriately defined via HTML what this element is supposed to be. Taking things even further with ARIA attributes such as aria-expandedaria-hidden, and aria-invalid make it even more semantic and meaningful.

If you don’t already, then I encourage you to start applying some of the ARIA principles into your web sites today – and as I mentioned in the intro, if you’d like to learn other ways that you can build your site accessibly, then you can check out my post over Developing for Accessibility. I hope I’ve proven that it’s not too difficult to get started – and if you want more information, then the docs can answer any question you may have about them.

Combining BEM and SMACSS

Code architecture is super important when you want to have clean, readable, and organized code. For small, personal projects, you might be able to get away with just a “hacker” mentality in the sense of just throwing some code together – but that will quickly break down to an unmaintainable state for larger projects. A lot of programming languages have overcome this issue via various frameworks that force some sort of DSL and/or file structure on you (Ruby’s Rails framework is a simple example) – or the language’s paradigm itself allows for clean code architecture (class-based, prototypal, etc.) – but there’s one language devoid of a lot of these niceties that’s ubiquitous across the web and can easily span thousands of lines of code for even the simplest of projects. I’m talking, of course, about CSS.

CSS is about as bare bones of a programming language as you can get; in fact, Wikipedia classifies it as a style sheet language instead of a programming language because it’s practically logic-less. You just select various elements and apply styles to them – and by default the styles will cascade in a particular order based on what selectors you’ve used. That’s it – and like I mentioned earlier, CSS can easily surpass a thousand lines of code for any project! Tools like sass, less, postCSS, and more have helped to add in some neat features to CSS such as mixins, variables, auto-prefixing, and more – but none of those address how you should architect your CSS.

Luckily – several talented developers have begun to tackle this issue, and two CSS design patterns have emerged as the most popular among the crowd: SMACSS and BEM. Now, every design pattern is opinionated to some degree, so you personally have to see if they’re right for you. I started to apply both BEM and SMACSS separately to my CSS-heavy projects and learned what made the most sense for my coding style – and also what I absolutely hated from each design pattern. In the end, I took the core concepts of both BEM and SMACSS and combined them to create a personalized design pattern – and I’m really loving it. It’s helped my CSS organization in such powerful ways, and I want to share with you what I found valuable from each design pattern. Before I do that though, I want to review the core concepts of both BEM and SMACSS – so that we’re all on the same page.

Similarities

Despite the differences, both SMACSS and BEM share a pretty common core set of rules:

  1. Never use ID selectors. CSS class selectors should make up the majority of your styles.
  2. CSS selectors should stay flat – don’t nest them (unless you have a good reason).
  3. Both design patterns focus on a module-based system of organizing the majority of your CSS – which sort of extends how object-oriented CSS (OOCSS) works. What this means is that you should architect your CSS classes in a manner that takes advantage of building repeatable HTML blocks that have a semantic purpose.

Now, let’s get to some of the differences.

SMACSS

SMACSS is a design pattern created by a single developer named Jonathon Snook who works at Yahoo! (which currently implements the SMACSS pattern). It focuses on 5 main types of structures to organize your CSS:

  • Base
  • Layout
  • Module
  • State
  • Theme

Base. Base styles are just that – base styles that apply to base selectors. These should be very simple and incredibly broad styles, such as font color and family, link styles, etc. Something like this:

Easy peasy.

Layout. Layout styles are meant for logic-less container elements that are solely included in your HTML to provide positioning, padding, or other layout-based purposes. By default, SMACSS recommends you begin your layout styles with the l- prefix:

Module. Modules will make up about 95% of the CSS of your page. This topic goes pretty deep – so I encourage you to look up the SMACSS documentation for how modules are intended to work – but the tl;dr version is that you should style a block of HTML code with independent, semantic content as a module with children elements. Something like this:

SMACSS suggests you keep your module names short, so that your child item class names don’t get unnecessarily long. This takes some practice to understand how to style your CSS using a module-based system – but it’s worth the struggle once you feel comfortable with it.

State. States are very simple styles – and are the only time where it’s okay to use the dreaded !important attribute. States are styles that should be triggered by Javascript (i.e. showing an element, hiding an element, marking an element as active, etc.) – and should normally begin with the is- prefix:

Theme. I don’t really use theme styles since my projects typically don’t need them, but their purpose is to provide styles for various themes – where the core styles of a series of pages stay the same, but small things may change like background colors, fonts, etc.

Folder Structure

SMACSS doesn’t place much emphasis on how you should structure your CSS files (which is drastically different from BEM) – so I created my own simple folder structure for the projects where I solely used SMACSS:

Using this as a folder structure, you would just create files for each style type in each respective directory. I use sass in all of my projects, and I’m a very big fan of using sass imports to import every sass file into one core file before I process it as CSS – which is what the app.scss file is.

That covers some of the core concepts of SMACSS – let’s move onto BEM now.

BEM

Compared to SMACSS, BEM is simpler to understand – but it’s much more rigid in how you structure your code and files. In BEM, every style is a part of a module – no base styles, layouts, themes, etc. You just have blockselements, and modifiers. In fact, that’s where BEM gets its name. Here’s a breakdown of what those concepts entail.

Blocks. Blocks are the styles that house related child items. You can think of them as the highest level of a module. Something like a menu:

Elements. Element styles represent the actual child items inside of a block. Elements always begin with the block name, followed by two underscores (__) and a suffixing name:

I like to think of element styles as nouns, since they’re meant as the core styles for actual elements.

Modifiers. Modifier styles are applied to both blocks and elements, and are strictly meant to handle the subtle differences that two similar blocks or elements may have. For example, a menu link may be white – or it may be blue:

Modifier styles always start with the full block or element name, followed by double hyphens (–) and then the modifier name. I think of modifiers as adjectives, since they help to better describe an element or block.

Folder Structure

This is where BEM heavily differs from SMACSS. Where SMACSS didn’t put much emphasis on folder structure, BEM suggests that every single block, element, and modifier should have its own CSS file. So as you start to build out your project, you’ll quickly create detailed file structures like this.

This is very organized – there’s no doubt about that – but to create a new file for every new class basically is a little extreme for me. This was one reason BEM was difficult for me to fully implement in the recommended manner.

So – how do I currently build my CSS? I took the core concepts of BEM and SMACSS and combined them in a way that made sense to me.

Combining Them

I really like BEM’s recommendations with regard to how code blocks should be structured. Blocks, elements, modifiers – building my class names following this design pattern really helped me to think about my code in a reusable block-based manner. I liked it much more than how SMACSS suggested to structure modules – which is practically no structure. However, I don’t feel like everything should be a module – which is BEM’s philosophy. I feel like there’s a valid purpose for base, layout, state, and theme styles – and I don’t feel like they need to be modules.

In the end, I basically went with a SMACSS architecture that leveraged the power of base, layout, and state styles – and instead of SMACSS’ module styles, I substituted them completely with BEM styles – blocks, elements, and modifiers. I also came up with my own file structure that made sense to me:

I kept base, layout, and state styles all limited to single stylesheets because even all together they never grew too large. I created a new file for each block, and kept all modifiers and elements related to that block in the same file. These files usually never grew to beyond 100 lines, so they were very manageable. Finally – I added a config folder for all the files that didn’t translate into direct styles. This config folder would hold things like variables, broad mixins, custom font stylesheets (such as icon fonts), and more.

You can check out a live example of this folder structure in my starter-site template.

Final Thoughts

I mentioned earlier that every design pattern is opinionated – and my personal pattern is no exception. It may appeal to you – or you may hate it, and that’s okay. At the very least, I hope I provided you with a little more knowledge about the two most popular CSS design patterns out there right now, and helped transform some of the opinions you may have had about them. In the end, we all have different coding styles, so one single design pattern won’t fit everyone. The most important obstacle these patterns try to tackle is that of code organization – and as long as you have a methodology behind your code architecture, then you’re good to go – no matter if you use a common design pattern or you just make up your own!

What Does It Really Mean to Support IE8?

Note: This post is geared towards developers who have heard about IE8 being a frustrating browser to support, but are unfamiliar with the ins and outs of it enough to know exactly why. You don?t even need to be a web developer to follow along ? so let?s get to it!

As developers, we’re all familiar with the browser called Internet Explorer (referred to as IE from here on out) and that it’s usually referred to in a negative context. Typical web developers scoff if they see anyone using IE when they have the option to use Chrome or Firefox – but truth be told, the more recent versions of IE (meaning 9+) really aren’t all terrible. Sure, they lack a lot of common browser functionality that should be core to all browsers – but with modern web development in mind, supporting IE 9+ isn’t all that tough.  It’s IE8 and all of the preceding versions that typically fuel our frustrations – but why is that? What’s so different about IE8 that even the phrase “IE8 support” is something that most developers hate? You don’t hear about “IE9 support” being bad nearly as much.

Well, there’s a lot of reasons – mostly related to how IE8 handles and renders HTML, CSS, and Javascript. But before we get into all that, we need to talk about why IE8 support is still a thing worth talking about.

Why is IE8 Still Around?

We’ve had 3 major IE versions after IE8, and we even have the new Microsoft Edge browser available on Windows 10 – so why on earth, you might ask, do we still talk about IE8, let alone support it? Well, not everyone does support it, and general support for IE8 among developers has been falling (which is great for developer sanity). But the reason that supporting IE8 is still slightly common is because some people – typically in their work environment – are forced to use Internet Explorer as their browser. Usually these are government jobs or corporate jobs within large companies where you have a strong bureaucratic culture and managing employee access is crucial. Forcing employees to use IE for security reasons isn’t bad, but some of these work environments also still haven’t upgraded from Windows XP – despite the fact that support for this OS ended over a year ago in April 2014. IE8 is the final version of IE that can run on Windows XP, and this the sole reason that IE8 support has been a thing worth talking about for the past several years.

The number of people working in these environments is shrinking, which is good, but they’re still there. You also have people with personal computers who aren’t very tech-savvy or don’t have much money and may still use Windows XP as well. They still use the internet, and very likely use IE8. Until this number gets to be practically zero, IE8 support will always be a topic that comes up from time to time.

What Makes IE8 Support so Miserable?

I’m glad you asked. Browsers are just applications that send HTTP requests to various locations and render the returning HTML, CSS, and Javascript into a graphical format. However, IE8 provides virtually zero support for the newest features in the most recent versions of these 3 technologies – which is what makes it difficult to support. I’m gonna break this analysis down into each language:

HTML

IE8 provides practically no support for HTML5, which is the most recent version of HTML and has been around since about 2010. Some of the new elements that HTML5 includes that IE8 doesn’t support are section, article, nav, header, footer, aside, and canvas.

Honestly, this is the easiest issue to get around. All of the above mentioned elements (and many more) besides canvas are called semantic elements, and thus don’t function much differently from just a div. By default, all browsers handle unknown elements as inline-elements, so to make them act like they should – which is block-elements – you just add a simple CSS style:

You can check out more tricks like this for browser support here, and you may also want to look into the Modernizr.js library, which provides feature-detection and can make supporting older browsers like IE8 easier. To get support for canvas, which is more difficult, you’ll have to rely on some javascript libraries to polyfill the canvas logic for you. ExplorerCanvas is a good option here – but my personal take is to just fall back to an image or something simple like that.

IE8 also doesn’t support the SVG element – which can be a big problem if your site uses popular graphical libraries like D3.js. Like with most things, there are tricks like these you can employ as fallbacks – but if your site is using SVG heavily, then IE8 support probably would be too much of a hassle to be worth the extra development.

CSS

The most recent major version of CSS is CSS3 and it’s supported by all major browsers; however, IE8 limits full CSS support to version 2.1, and provides little support for CSS3. We’re gonna be getting into more of the headache-causing issues now, but we’ll start off with some of the easier issues to solve and end with the ones that really throw developers for a loop.

No media queries. This one isn’t bad because usually you use media queries for responsive design. But if you’re building for mobile devices first, and thus use media queries to target larger screens, this might get you. To fix this, you can check out css3-mediaqueries.js which adds media query support to IE5+.

No keyframes. It sucks, but I think we can all live without this one. They’re usually just flashy anyway.

No transform or transition support. You won’t be able to do any fancy hover effect transitions or rotate, scale, and translate any elements. Normally this is fine, but I’ve had times where an element that I can’t rotate really looks terrible. jQuery provides some support with transitions, such as the slide or fade APIs, so you have a little bit of support there. You can also forget all about using advanced styles like 3D transforms.

Difficult to do translucent backgrounds. The rgba or hsla color methods you may be used to won’t work in IE8. If you need translucent backgrounds, then you’ll have to resort to the IE-specific styles using filter. It can be a pain because it’s pretty different, but I built a gist about this particular issue which you might find useful.

No nth-of-type or nth-child selectors. There are more than just these missing from IE8, and this can be a true pain. A common way to build out grids is to make sure the blocks in your last column have no margin on the right side. It’s very easy to do that using an nth-of-type, but in IE8 that won’t work. You can fall back to a javascript library like Selectivizr if you need this feature.

The major CSS frameworks don’t support IE8. This includes the most recent versions of frameworks like Bootstrap and Foundation. You can always try to use other CSS and JS libraries out there to add in support for the features that IE8 is missing, but that gets into very tedious work. If you use Bootstrap3 or Foundation5, then you’re better off just kicking IE8 support to the curb than to deal with all of the arising problems.

Various strange things can happen. This is just a bucket category to say that a lot of strange things may happen in IE8 that just don’t happen in other browsers. Maybe one of your elements just doesn’t show up because it’s positioned incorrectly, or has a height of 0, or maybe your clearfix isn’t working properly (and for IE8, I recommend Nicolas Gallagher’s clearfix styles – shown below). For these types of things, you’ll just have to fix them one by one. Who knows, maybe you’ll get lucky and everything will look right in IE8!

Javascript

I saved the toughest section for last. Most of the difficult issues you’ll face in supporting IE8 will be Javascript-related, and there’s one prominent reason for that.

IE8 doesn’t support most of ES5. I went ahead and started out with the toughest problem first. ES5 is at the moment the most common iteration of ECMAScript available, and has been for a while now. Because IE8 doesn’t support most of ES5, you lose a lot of functionality that modern Javascript employs. If you write most of your Javascript yourself, then this might not be as big of a deal because you can just verify that all of your code isn’t using ES5 – but who wants to do that? No one – which is why some smart guys built es5-shim, a library which adds support for many ES5 API updates. This should take care of a lot of problems, but there’s a good chance you’ll still run into some support issues.

Many JS libraries don’t work on IE8. This is largely because of the ES5-non-support issue (es5-shim will help with this). jQuery v1 still supports IE8, which is a huge benefit, so you’re safe there (and it’s still being updated for the time being). But many other libraries don’t – especially the smaller, not-as-popular libraries. Let’s face it, if you want a really cool front-end to your site, you’re going to use a lot of Javascript to do that and a lot of it’s going to be coming from third-party libraries. That’s completely fine, but just be aware that they might not (and probably don’t) support IE8. If they do, then they’ll explicitly mention it. Each new library you add means another potential point of failure when supporting IE8.

No WebGL support. WebGL is a Javascript API that allows modern browsers to implement 3D viewing easier. It’s smooth and leverages the power of your graphics card – but IE8 doesn’t support it (in fact, even IE11 only has partial support for it). If your site heavily uses 3D, then chances are that you’ve already given up on the thought of supporting IE8, but if not, then you’ll definitely need a fallback here such as displaying a simple image instead of a 3D element.

The major single-page app frameworks don’t support IE8. Angular, Ember, Backbone, and React – none of the most recent versions of any of these support IE8 out of the box. Just as with other libraries, you may have to hack support in through es5-shim and other libraries, but because these are frameworks and not just simple libraries, you’re really playing with fire there. If you use any of these technologies – it’s best to not worry about IE8. Older versions of Angular do support IE8, but who wants to use a deprecated version of anything?


Conclusion

After reading all of this – you probably never want to support IE8. And many developers are with you, but the fact of the matter is that even though Microsoft has dropped XP support for over a year now, IE8 is still a browser that many people use and thus modern websites still need to work on them. Maybe not your personal site, but larger sites like Amazon, Wal-Mart, various banks, etc. absolutely need IE8 support, and I hope I’ve given you a little bit of insight into the struggles of what it means to provide that support.

There is a silver lining however; by saying you understand how to provide IE8 support, that’s like an extra merit badge on your developer resume. Everybody likes an additional +1 on their skill list!

Developing for Accessibility

Accessibility is one of those topics that everyone always aims for and remarks how important it is as far as development goes, but it never really gets thought of as much as it needs to during the actual build phase. But wait a minute, let’s define what accessibility for the web really means. Developing an accessible site means ensuring that all users – whether disabled in some way or not – can not only access your site but also interact with it with the best possible user experience.

This doesn’t entail responsiveness as much (which should always be staple of a new web project these days), but focuses more on building a well structured website so that it is keyboard-navigable, parseable with screen readers, visible to users with color-blind deficiencies, etc. Sure, these users won’t make up a majority of the users on your sites, but we all know that’s just an excuse to get out of a little extra planning for development.

Notice how I said planning for development instead of actual development. That’s because there’s really no extra development involved with making an accessible webpage, as long as you know what you’re doing. Let’s get into the key areas where developers should focus on in order to make their sites fully accessible:

Image and Link Attributes

If there’s one thing you know about accessibility, it’s to put alt tags on your images. Something like this:

But, don’t forget about your anchor tags too. Instead of alt attributes, you need to add title attributes here. This isn’t necessary for all links, but make sure you do them for your icon-font anchors – you know, things like your facebook, twitter, and responsive nav icon:

Use Semantic HTML5 Elements

HTML5 added some new descriptive container elements that you should learn about if you don’t know them already. These include nav, section, header, footer, article, and aside. Each of them function just like a div, but have different semantic meanings. For example, nav should be used for your page’s navigation, aside should be used for non-relavant content, section is a large container which can contain a header, footer, and multiple articles, etc.

While an average user won’t usually see the difference, it makes for better design architecture, enhances your browser’s understanding of the content inside of these containers, and allows for more rich screen reading.

Noticeable Focus Status for Links

You probably know about some of the states that an html anchor can be in such as hover or visited, but you may not know about the focus state. The focus state is shown when … yup, you guesssed it, when a link is focused. Many users don’t see this phase because it’s when your keyboard is focused on the element. This is the state when you are typing into an input element, and the state that the ‘Submit’ link has when you tab onto it to hit enter.

Many users do actually use the tab key to navigate through your site, whether for accessibility purposes or just sheer speed, and you need to account for that. There are 2 things I usually do here.

First – I put a default style on all focused links:

Next, I usually find the elements that have unique hover effects, and I often times just use the same hover effect for the focus effect. So some elements of mine are structured like this:

 Skip Menus

Every accessible page should be complete with a skip menu. A skip menu is a menu that is invisible, but becomes visible after you start tabbing through the page. It allows users to skip to certain portions of your page content – this is very important for users who use screen readers or can’t scroll well. Here’s an example of a solid skip menu I built here at Staplegun. Just start tabbing through the page and you’ll see what I mean.

The code involved is very simple, but I won’t cloud up this post with it. See my skip menu gist if you’d like to see how to easily build one.

Test Your Site With a Screen Reader

Many users require the use of a screen reader to interactive with your site. Luckily, if you’ve followed the advice laid out thus far, then most of your site should already work fine with a screen reader. This is where you’ll figure out what links need titles, what images need alt tags, and if you need to fix any of your page layout structure.

If you’re testing in Chrome, I like the screen reader Chrome Vox which is a Chrome extension. It’s very easy to use from a development standpoint.

Test For Color Blind Users

Color blindness isn’t incredibly common, but common enough that to be a good front-end developer, you need to account for it. This means following a good color scheme where the colors fit together for maximum viewing accessibility. Usually if you use a color scheme designer of some sort and stick with it, then you’re in pretty good shape already.

Most users who are color blind fall into the category of deuteranomoly, which means they have difficulties seeing green. To learn more about the different types (Protanomoly, Deuteranomoly, Tritanomoly, etc.), check out the main Colorblind Awareness site.

Since most developers aren’t colorblind, it’s tough to test for without being in a colorblind user’s shoes. Well now you can be, with NoCoffee – a vision simulator that will easily show you what your web pages look like from the viewpoint of several vision impairments. I have been using this extensively to test color issues on my web pages, and it’s been incredibly insightful to see what real colorblind users see.


And that’s the gist of it! A little bit more than just adding alt tags to your images, but not enough to where you can’t handle it. Now go out there and develop fully accessible web pages, and get in touch with me if I missed anything huge in this post.