A Q & A with Keith J. Grant

Keith J. Grant the author of CSS in Depth, is currently a Senior Web Developer at Intercontinental Exchange, Inc., ICE, where he wrote and maintains the CSS, both for the corporate, as well as The New York Stock Exchange, websites. He has eleven years of professional experience building and maintaining web applications and web sites using HTML, CSS, and JavaScript. He is self-taught in HTML and CSS, and has several more years of informal experience working with the technology.

His manager brought him onto the website team expressly for his expertise in CSS, when ICE needed to implement a redesign of the websites. CSS enables companies to brand their sites in unique and creative ways, and to offer complex web applications with intricate layouts.

Though Keith has primarily been a JavaScript developer, he has become a very important CSS instructor at every company he’s worked for.

Read more author interviews here.

Jump into any page of the book from the table of contents on liveBook!

Take 39% off CSS in Depth. Just enter intgrant into the discount code box at checkout at manning.com.

Tell us about yourself?

I live in Atlanta with my wife and two kids (ages 3 and 5), though we are originally from the Pacific Northwest. I have been doing web development professionally for about ten years, though I began fiddling with HTML and CSS in the early days of the web. I love cooking. I’ll eat just about any type of food, though I have a special place in my heart for good, authentic Mexican food. I also enjoy running. I have done a couple half marathons and hope someday to run a full marathon.

What are some of the coolest new developments to CSS and would you mind talking about how you’ve managed to incorporate some of those features?

The world of CSS has really taken off recently. New features like Flexbox and CSS Variables are starting to become mainstream. Flexbox is rapidly replacing float-based layout. It has long been difficult to build columns of equal height or containers with centered content, but flexbox has made this trivial. I have found myself using it for more and more as I have gotten accustomed to it. A new form of layout called Grid Layout is right around the corner, too, which will open up even more possibilities.

CSS Variables are incredibly fun to play with. Browser support isn’t quite as far along as it is with Flexbox, but it will be ready for “prime time” soon. I am just starting to use them in a project right now to allow for easily customizable themes.

You’ve mentioned that some of the new features are still waiting for browser support. How would you advise developers to go about choosing which CSS features are ‘safe’ to use?

Most emerging features are safe to use today, assuming you have a plan for how it will degrade in browsers that don’t support it. For example, flexbox degrades rather well to floats. You can use floats to lay out a page, then immediately afterwards use flexbox to re-define a similar layout. Browser that don’t understand flexbox will ignore those rules, falling back to the float-based layout. And browsers that do understand flexbox will allow the flexbox rules to override the float rules. This allows newer browsers to get the benefits of the flexbox (vertical centering, columns of equal height), while older browsers still layout the page well.

Another useful tool is the `@supports` rule. This allows you to query the browser to ensure it supports a certain feature, then apply styles only if it does. There’s a good introduction to this feature at https://www.sitepoint.com/an-introduction-to-css-supports-rule-feature-queries/.

Can you talk a bit about how responsive design has changed the way we use CSS?

In the early days of the web, we tended to think of web design no differently than other mediums like photoshop or print design. We would give the page an 800 pixel container and try to implement a “pixel perfect” design within. Responsive design shook the industry awake to start realizing that the web is not like other types of design. The web is fluid. Screen resolutions vary. User font settings vary. Some users have a mouse, others a touchscreen, and still others navigate using the keyboard. This is why it’s so important to get professionals to do your web design Perth so you don’t end up with an out-dated website from the get-go.

With responsive design, we learn to find more general solutions to our design needs. We have to accommodate these variations in the browser environment. Instead of putting pixels precisely where we want them, we provide a system of rules, and trust the browser to work out the details for us. This doesn’t mean we need to be less precise in our designs, but it does mean our designs need to account for more possibilities. Meeting these needs are crucial to this process, and that is why many businesses who are looking to create a new website for their brand, or updating their old one, tend to look for web design companies like Plenty of Pixels Web Design in Winston-Salem to help build them the most-effective website that they can. CSS is an abstract language, but until the rise of responsive design, we tended to avoid that abstraction. Now we have to embrace it.

It sounds like the challenges are becoming more device/technically oriented. Does this mean the classical designer needs to become more technical, or do front-end devs need to pick up the design slack?

I think both need to happen. Designers need to get acquainted with many of the new possibilities on the web, thinking beyond just static mockups and into the realm of a dynamic environment. Developers need to work closely with designers to help them see the new potential avenues for creativity. Responsive design, flexbox, and grid layout present a lot of new possibilities.

For a long time, designers kept asking for designs that weren’t possible in CSS, and developers had to keep reining them back. Now, the opposite is beginning to happen: the web is able to do things that simply aren’t possible in print or other traditional media.

What are some common pitfalls you regularly see?

One pitfall I see a lot is when developers set a height on an element. As soon as you do that, you will start running into all sorts of problems with overflow and alignment. An HTML page is intended to work with a constrained width and an unconstrained height, so containers can grow taller to accommodate their contents. Exact reasons developers set a height can vary, but there is almost always a better way to get at the effect you are going for.

Another thing I see is applying positioning all over the place, especially “relative” positioning. Positioning is a powerful tool, but it can have unexpected side effects on the page. You should only use it when you have a specific reason for it.

The last big problem I see is CSS with no thought given to the overall organization of the stylesheet. Developers throw styles and class names at the page without much rhyme or reason. This leads to buggy, hard to understand code. There are some great techniques for organizing your CSS, but you won’t typically stumble into them unintentionally. Unfortunately, sometimes you just have to see the struggle with the “wrong way” for a while before you can fully appreciate the value of the “right way”. I spend two full chapters ( 9 and 10) diving into this in the book.

Could you give an example of a better way to deal with height than manually defining it?

There are many reasons people want to set a height on an element, but two jump out to me as the most common. The first is to help with vertical centering of its contents. This has been a notorious problem in CSS, but today, it is a piece of cake with flexbox and `align-items: center`.

The second reason is to make an element fill a large portion of the page, perhaps to show a “hero” image. Instead of setting a height, consider setting a large top and/or bottom padding on the element, which will add height above and below its contents. Or set a `min-height` rather than a height. This will ensure the element is at least a certain height, but will still allow it to grow if necessary to contain its content.

Why do you think so many struggle with CSS, and why do you think it’s worthwhile to take the time to really get to know it well?

I think there are two main reasons CSS is difficult. First, it has a very low barrier of entry. You can “learn” CSS in a weekend. Unfortunately, this is misleading. It’s all too easy to miss the fact that there is a lot more to it than this surface level. This ties into to the second reason CSS is hard: you often don’t know what you don’t know. Mastering CSS requires an understanding of so many disparate topics. Some are small and simple; others are deep and complex. But there is no obvious roadmap to learning them all.

We web developers know that JavaScript is complex, and it has a complex ecosystem of frameworks and libraries. So we devote a lot of time and effort to learning it. But CSS doesn’t tend to get this attention. We *think* we’ve learned it, because we’ve been lulled by the straightforward syntax. But it is a cornerstone technology of the web, and it deserves our study so that when people hire a web development company, they know that they will be working with a company that has put time and dedication into learning their craft, and will put their full confidence in us. Popular web frameworks come and go, but the fundamentals of HTML, CSS, and JavaScript are always there. If we truly understand those, we’ll be able to use things like WordPress to create websites rather simply (although, you can click here if you need some help). But, more importantly, we can adapt to any changes in the latest web development trends.