Modern CSS with Jen Simmons

Transcript

Stefan Tilkov: Hello and welcome, listeners, to a new conversation about software engineering This is Stefan Tilkov. Today on the CaSE podcast I'm talking to Jen Simmons about modern CSS. Jen is a designer advocate at Mozilla, where she spends her time researching, writing and speaking at conferences. She also hosts and produces the awesome Web Ahead podcast. Jen, welcome to the show!

Jennifer Simmons: Hi!

Stefan Tilkov: Our topic today is CSS, which is a little bit unusual of a topic for this show, because we typically cover hardcore programmer topics, and people don't necessarily believe CSS is one of those. Maybe we'll have to do a little bit more explaining today than we typically do. Can you briefly describe what CSS's role is in the browser architecture?

Jennifer Simmons: Yes. It's funny you say people don't think of CSS as a hardcore programming language... We're going to get into that - is that really true or not? Or what does "hardcore programming language" mean?

Jennifer Simmons: CSS, basically, when you go to make a website or a web application (web app is the cool new term for, basically, a website that does more things than a website did ten years ago), you have a whole stack of technology that you're using. You've got the HTTP connection, you've got the URL, you've this, that and the other, but also you've got HTML, CSS and Javascript. Hopefully you have all three, although you don't need Javascript. You can leave that off; if you're not doing anything with it, you should leave it off. But you definitely need HTML - that's the core/heart of every web page. And you probably need CSS.

Jennifer Simmons: If you like Georgia on a white background with blue links, then you don't need any CSS, but if you want your website to look any different than the defaults that the browser has - which make the web look like 1994 - then you need CSS. Its role is to provide all the styles. It stands for Cascading Style Sheets, and it's about making things look a certain way. You can also do animations, so it's not always static, the way things appear; they can move or change over time as well.

Jennifer Simmons: As a person interacts with the website, as your user interacts with your website, you can have different things happen, or at different screen sizes you can have different things happen.

Jennifer Simmons: It's powerful. How many programming languages are used every single solitary time? There's not many, and CSS is one of those.

Stefan Tilkov: What makes it different from other programming languages then?

Jennifer Simmons: For one, it's declarative, and this is probably where a lot of people think, "Oh, that's not a real programming language." Because you're just declaring things. It doesn't run, it's not procedural; you're not writing a bunch of if statements... You're saying, "Hey, take this thing on the page and make it look like this. Take this headline and put it in this font. Take this link and make it this color. Take this box and give it a background of this color and a border of that color. Take this item, and when someone hovers over it, I want you to move it across the page from this place to that place."

Jennifer Simmons: That sounds weak, but it's not weak. It's really quite powerful and important. But from a programming point of view, declarative is not that hard to learn, in a way. You've got some sort of selector that's written down. Usually it's a class, or maybe it's an ID, or maybe it's the element itself - there's a handful of ways to do it. You basically need to target which part of the page are you talking about at this moment - that's called a selector.

Jennifer Simmons: Then you open one of those curly brackets and you write down "property". There's a whole bunch of properties. You pick the property, and then you define the value for that property. You say, "I want my background to have the color of blue", or more likely a hexadecimal number or an RGB/RGBA number. Then the next thing, and the next thing, and the next thing. You're just declaring them.

Jennifer Simmons: Then you close the curly bracket, and you're done. If you understand that syntax, then you understand all the syntax of CSS.

Stefan Tilkov: What about the cascading part?

Jennifer Simmons: The cascade - I make it sound super simple, but of course it gets super complicated. The cascade is about -- what happens if you say two things at once? What if you say, "I want all my links to be red", and then further down on the page you say, "I want all my links to be blue"? In a way, you're contradicting yourself, and the computer simply says, "I'll take the second one."

Jennifer Simmons: But maybe at the top you say, "I want all my links to be red" - which is a terrible color - but "I want all my links to be this particular shade of creamy blue color", and then further down you say, "I want all the links that are inside this particular kind of box to be green."

[00:05:49.09] Then it will in general make all the links blue, and in that particular context, in that particular place where you're inside that certain box, it is going to make them green. That second context is where things are more specific. Probably at the top you just put "a" (which is the syntax for this) - here's the color, or a: This is where people get frustrated or they get confused. It's very important to understand how the cascade works and when you use an element or when you use a class or when you use an ID. There's math being done by the browser, to make the calculation of which is more specific. If they in specificity, then the second one gets the priority; you can basically override yourself. But something further up in the page, earlier in the cascade, can easily override something that comes later by being more specific. There's a math on that. Elements get a certain number in the calculation - classes get a certain number, ID's get a certain number.

[00:05:49.09] Then it will in general make all the links blue, and in that particular context, in that particular place where you're inside that certain box, it is going to make them green. That second context is where things are more specific. Probably at the top you just put "a" (which is the syntax for this) - here's the color, or a: People get frustrated and confused by that, because they think "Look, I've got this ID and I've got this class, and the class is coming later. Why is the class not overriding the ID?" Well, because the class is ten times as powerful as the ID. There's other particulars about the way the cascade works that's important for people to go learn if they're writing CSS. Again, it's not that complicated, but if you don't know that that is happening, it's very confusing. Once you know that that's happening, you go look it up, read one or two blog posts about it, maybe write and print out a little cheat sheet and put it next to your computer for a couple months until you have that memorized... Then it's fairly simple, it's very obvious what's happening, and why one thing is overriding another, and you use that to your advantage.

Stefan Tilkov: How do you think that is related to the fact that so many software developers actually hate CSS? They don't only consider it to be weak and not a real programming language, they also really despise it. It's not something they want to use. Why is that?

Stefan Tilkov: Jennifer Simmons:[00:09:00.27] I have my quick ranty answers that I might give out in a setting, at an after party at a conference or something, but I do ask myself that question in a quieter time and try to really understand. It is such a visceral response that a lot of people have to towards CSS, and why do they hate it? Of course, there's a bunch of reasons.

Stefan Tilkov: Part of it is that a lot of people who have taken the time and put the effort into learning computer science programming - maybe they have a PhD, they went to school, they have some kind of good degree... It's really important. Along the way, I doubt that they had a class where they learned CSS. I don't see CSS being taught in those kinds of programs, and because it's a declarative language, it's different than a lot of the languages that people learn. Frequently, if you put seven years and a hundred thousand dollars into learning computer science and you come out and there's something that you've never heard of, and people tell you it's easy but every time you ever try to write a few lines of it, it doesn't work the way you think it's supposed to work, then that's going to make you hate it.

Stefan Tilkov: I wonder how much of the frustration really is just that, and if computer science programs would teach CSS in the second class that everybody takes, maybe a lot more people would find it very interesting and powerful and fun and easy and not a big deal at all. I think that's one thing.

Stefan Tilkov: I also think there's something beautiful about programming where the procedural languages -- when I started learning them (Fortran and Turbo Pascal) it was fun to program a database application in Turbo Pascal. It's like you're imagining these little creatures running around in the machine, following your commands and doing what you want, and show back up with answers. Or I almost imagine it like little mice running around in the walls and coming... Probably because I learned Turbo Pascal about the same time I was reading kids books, about Ralph the Mouse.

Stefan Tilkov: There's something fun about the little tiny people who live in the walls, or little tiny creatures who come and do magical things for you. Somehow, programming is a bit like that; procedural programming feels like that. To me, CSS feels a bit more like there's nobody there. It's like hanging clothes on a laundry line, or something. You're just putting things out there, and that's how you want them to be. It doesn't quite have that spark of magic that a procedural language has. That doesn't mean it's bad, it just means it's different. It's declarative.

Stefan Tilkov: The good thing, the great thing, the really powerful thing about declarative languages that I think engineers could really appreciate is how forgiving they are. If you make a mistake in CSS, if you leave off a semi-colon or you misspell a word - you mean to say 'border', but you actually put another letter in there and it's misspelled, the browser will start to parse that file and it will hit the line that it doesn't understand, because maybe it's brand new CSS that it's never seen before (it's an old browser, it's never seen this new CSS) or it's simply a mistake (you left off a semi-colon or you wrote your class selector in such a way you thought it would be an underscore, but actually it's a dash and you put the wrong thing), it just ignores that one line of code and it skips to the next line. It parses the next line and it keeps going.

Stefan Tilkov: A procedural programming language doesn't do that. And you don't want it to do that. Javascript doesn't do that. If Javascript hits a command it doesn't understand, it stops and it says, "I don't know what to do here. You were defining a variable and then you were about to tell me to do something with that variable, and I don't understand the syntax of that line, so I'm just going to stop and make you fix this. Because otherwise I don't know what to do. I might guess, and I'm gonna guess completely wrong what it is that you want me to do now", because of the nature of a procedural language.

Stefan Tilkov: With a declarative language, really everything that you write in CSS is a suggestion. You're saying, "I would like my font to be 17 pixels tall, or big." Perhaps the person who's using that browser and going to your website, they don't like their text at 17 pixels; maybe it's way too small for them, and they told the browser to make it much bigger. The browser is going to do what the user asks them to do, before it's going to do what the person who made the website asks them to do. All of the things that you write in CSS are suggestions. They're suggestions that 90% or 99% of the time are followed, but sometimes they're not.

Stefan Tilkov: Sometimes CSS hits something it doesn't understand; you have a mistake in your code or it's a new thing, or the user overrode everything and said, "I can't read black text on white, so I've used a special browser that's making everything be light-colored text and dark backgrounds", or whatever; lots of things can happen.

Stefan Tilkov: The declarative language is forgiving. The declarative language basically says, "Hey, I know you want me to do this thing, but I can't, so I'm just going to do my best... I'm going to do part of it and we're going to move on. I'm still going to display this page, I'm still going to give everybody all the other stuff that you asked for. I'm still going to make this experience usable." If it's a banking website, people can still use their bank account. If it's an airline booking website, they can still book their tickets to buy their airline ticket. The fact that that link isn't that exact shade of blue that you wanted is not a good reason to not let people buy an airline ticket, right?

Stefan Tilkov: In that way, it's good. It was intentionally architected like this by really brilliant people. This is not a baby language because people who invented the web were dumb and didn't know what to do. It was architected like this on purpose. It was made to be declarative so that it could be forgiving, so that it would work and deliver the best experience all the time, even under conditions that are not ideal, even under conditions where everything's a little bit off, a little bit broken, a little bit crazy.

Stefan Tilkov: Is that part of the reason why you -- in the introduction you mentioned that Javascript is an optional component. Would you prefer that there be less built-in Javascript and more in HTML and CSS?

Jennifer Simmons: I think Javascript is amazing. It does things that are part of the nature of the web itself, and when people 50 or 100 years from now look back on websites from this era, especially from ten years ago, they're going to think, "Wow, those websites aren't even really what the web is. The web became..." We look at films now, and then if you look back at films that were created before film and sound was invented (the silent film era), you're like "That's nice, those silent films... But that's not really what film is. Film is really this other thing."

Jennifer Simmons: Javascript is opening up parts of the web and making it possible to make websites in a certain way that you wouldn't be able to do without Javascript. It is part of the nature of the medium itself, but what I want is I want people to use Javascript for what Javascript should be used for. I don't think it's a good idea to use Javascript for things that you should and could instead use HTML or instead use CSS for. Great software engineering is about understanding your tools and knowing which tool to use at which moment, and to understand why one tool is good at one thing and the other tool is good at something else. If you need a screwdriver, use a screwdriver; if you need a hammer, use a hammer. Hammers are great. Just because screwdrivers exist doesn't mean hammers aren't a good idea, but you don't wanna use a hammer to do something you should be using a screwdriver to do.

Jennifer Simmons: HTML has its place. CSS has its place. There is a movement right now it feels, where people who don't understand CSS, who haven't taken the time to learn HTML, they want to get rid of those two parts of the stack, and they just want to use Javascript. They have to use some sort of HTML, so they're using divs and spans for everything, or maybe links, but they're not using button, they're not using form elements properly, they're not using aside and definition lists and all the other things that are in HTML. They're just using divs and spans and maybe links, and then you've got people who think that CSS is terrible and they don't want to write stylesheets, so they're basically taking all the things that CSS would be doing, they're taking the CSS syntax itself and they're putting it inside Javascript and getting Javascript to deliver all the CSS's separate. Tiny little commands scattered throughout the markup, rather than in proper stylesheets. Those are terrible ideas. Terrible ideas.

Jennifer Simmons: They make a website incredibly brittle and fragile. The moment that anything fails at all, the whole website fails. And there's no reason for that. That's a bad idea. The web was built to be incredibly resilient under crazy conditions. You can build a website that will work on every popular computer out there. Maybe not some sort of super computer off in the corner that nobody knows about, but every popular operating system that regular humans buy these day... You can walk into any electronic store anywhere, and if it's got a connection to the web and a web browser, it's going to read your website.

Jennifer Simmons: Phones and game console browsers, tablets, laptop computers, desktop computers... Devices that you've never heard of. Somebody could come up with a toaster that has a web browser in it, and your website will run on that toaster if you build it in this resilient way, using HTML to do HTML's job, CSS to do CSS's job, and Javascript just to do the things you need Javascript for. And you layer it on top. You have the Javascript come last and do its job last, and do just the things that it's really good at, and you can build an amazing website that way.

Stefan Tilkov: Is that what people call progressive enhancement?

Jennifer Simmons: Yes, progressive enhancement is a flag that gets flown, a principle around the way that a stack gets built. It's sort of like thinking the worst-case-scenario first, and make sure things are being built really well for that. You don't spend a lot of time there, but you just make sure... If we're going to build a photo sharing website, and that's the job of the website, to share photos, then make sure there's a way for people to upload the photo and then see other people's photos using the simplest technology in the stack, which in this case would be HTML; you can just use HTML for that. It may be ugly; it's not going to be the most elegant experience, but it's going to be functional, it's going to work.

Jennifer Simmons: If for some reason everything else broke, the HTML could get the job done. Then use CSS to style that site and to give it your branding, and to give it some layout and give things a great look and feel, and then use Javascript to make it so that you don't have to actually click the button in order to upload the image the moment that you finished with this other button; it immediately starts uploading, you don't have to push a second button. Or make it so that you don't have to refresh the page in order to see the photo; the page refreshes itself once the photo is done.

Jennifer Simmons: That sort of interactivity and making it a more elegant experience, and making it cooler and faster and more of a 2016, 2018 expectation of an experience - use Javascript for that. But at the core, at the very beginning, make sure that the base functional experience is implemented in HTML by itself, so that if the Javascript falls off - which it does - people can still use your website.

Stefan Tilkov: This seems to suggest that people need to know all of these things to make an informed decision. You have to know these technologies to know which one to use, and that suggests that while it's perceived by some as purely something for designers to use, it is something that the actual software developers need to be aware of and have to be part of their tool set. How much is this true in the reverse as well? How much software engineering is there in CSS development or design?

Jennifer Simmons: You have a couple good questions in there. One, I do think that everybody who uses Javascript knows Javascript and uses Javascript to make website. You might use Javascript to do other things, that's cool; I can't really speak to those spaces, because what I know is the web. But if you're using Javascript to make websites, I do think you should know HTML and CSS. It mystifies me sometimes when I see professional frontend developers who it's their job to implement the front end of the stack - not the backend. Again, Node, in the backend - I don't know, maybe it's different. But if you're doing a website and you're working on the frontend, your job is frontend developer, frontend engineer and you don't know anything about HTML or CSS, I don't... I would hire you. That's bad.

Jennifer Simmons: If that's your job, I highly suggest taking the time and going and learning HTML and CSS. Start with HTML. There's like 120-something elements - just go learn what they are, and learn when to use which one... Because it is also declarative. It's easy to learn. There's no variables in HTML, there's not a lot of stuff to go and learn. You can pick up a great book and learn it in less than a week. Then CSS as well.

Jennifer Simmons: Someone who knows HTML and does not know Javascript used to be the very definition of a frontend developer. For a long time we weren't using Javascript at all, because it was so buggy and badly implemented. It only feels like in the last 18 months or two years that knowing Javascript is starting to feel like a requirement.

Jennifer Simmons: I don't know that everybody needs to know the whole thing. There are a lot of great people out there who don't know Javascript, and it's really up to them to figure out where they want their career to go and whether or not learning Javascript will help them. Maybe it could, I don't know.

Jennifer Simmons: Before I move back to the design side, I should say I do think that -- usually we work on teams these days; bigger projects have teams. A small project of one person who knows HTML and CSS could totally be an incredible website, incredibly successful. It's not going to have Javascript on it, because they don't know Javascript. It's a small budget website, they probably don't have any budget for anything in Javascript anyway. Or maybe the Javascript that's getting used is the Javascript that came with WordPress or came with Drupal, or some plugin that you download and it adds Javascript - that's cool, that's fine.

Jennifer Simmons: When it comes to a bigger team - you've got a big ol' team, the team as a whole... Overall, the group is architecting the entire system. Overall, the group is figuring out "How are we going to build this? What tools are we going to use? Should we use a framework?" I definitely think that the people who are making those decisions for the team as a whole should understand the entire stack. They should understand the role of these three pieces of the stack, and the strengths and the weaknesses of each, and they should architect the system for the whole multi-million-dollar budget website, or whatever they're working on, with a really great understanding of all three.

Jennifer Simmons: If you're spending two million dollars on somebody's website and you only know Javascript, and you think HTML and CSS are dumb, and you're coming with the architecture for that giant project, you're probably going to make some bad decisions. You probably need someone on your team who understands all three in order to help you make better decisions.

Jennifer Simmons: Your question actually was about designers - there's a debate with designers, whether designers need to know anything about the medium that we're working in at all, beyond being a user. There are a lot of people who just use websites and then they maybe go to arts school or they love graphic design, or maybe they went through some sort of a program where they learned how to be a web designer, but they don't know anything about the medium from an author point of view, from a person who makes websites point of view. They don't know what HTML or CSS really is, they view source on a web page and they freak out and they just want to close it and go back to drawing pictures in Photoshop.

Jennifer Simmons: In a way, that's my audience. I feel like at a lot of conferences I speak to those groups of people. I'm trying to convince them that they really... If you were an amazing painter three centuries ago, or a sculptor, a true artist, you wouldn't dare not know how to use oil paints or how to use a chisel on a piece of marble. You need to know your tools. You need to understand - if you take this mallet and you hit that chisel in this particular way, the marble's going to crack in that way, and this kind of marble tends to crack like this, and that type of marble tends to crack in this other way, and you can see the seam right here, and if you hit the chisel in this part of the seam it's going to fall away in this way, and if you hit it in that -- you know, there's a way in which if you wanted to be a sculptor in the Renaissance era and make something gorgeous, you had to understand your medium.

Jennifer Simmons: Designers should understand their medium. They should understand HTML. If I were going to hire a designer, I would only hire designers who know how to write CSS, because then they can work in the medium, they can prototype a website. They don't need to write production-ready CSS, they may not be the best from an engineering point of view, they may not know any Javascript, but to be able to open up some documents, some empty code text documents and write HTML and CSS and put together a prototype for a design - I find that to be a much better way to really design something, than to just open up Photoshop and draw a bunch of photos of what you think you hope the website would look like in the future.

Stefan Tilkov: Okay. Let's go back to CSS details. Maybe we can start with a little bit of history. I don't necessarily want to go into a year-by-year thing, but some of the major milestones or the major history - how it started out and how did it change over the course of time?

Jennifer Simmons: The web was first invented back in - depending how you start counting - 1993, 1994, that's when it first launched. 1989 is when it first started out as a memo. Really, the only web technology that existed... There was, of course, the things around the server side and the protocols, but the web technology itself, the document that you make to make a website - HTML. Just HTML. That HTML had a particular look to it. There was nothing that you could use to make layouts, there were no images, it was just text... Headlines, paragraphs, lists and a few other things. An unordered list would have bullets, or an ordered list would have numbers, and they would get indented, and links would be blue and underlined.

Jennifer Simmons: There was styling that would come automatically with HTML, but there wasn't any other kinds of tools - right away, at least - to be able to control other things. All the backgrounds of every website were grey, and there were no images. Then HTML evolved over time. In fact, the reason that HTML could evolve and the reason that CSS could evolve is because they're declarative languages. That's another thing about declarative languages - it makes it really easy to have things change over time.

Jennifer Simmons: HTML got things like -- now I forget the syntax, actually... I've deleted it from my RAM. But fonts - you could set your font size, you could change the font itself, you could set a background color on something...

Stefan Tilkov: I remember the blink tag.

Jennifer Simmons: Yes, that was like an element that came with a certain formatting. Images - the fact that you could put an image on a page meant people started doing things like type-setting their name of their website, or the font of the headline; they'd type-set the headline for an article using a certain font that was available on their computer, but not available on the web. So then instead of having a real headline in the HTML, you'd have just an image in the HTML, which basically means nothing.

Jennifer Simmons: Right as soon as we had images, we started making the web do things that it shouldn't do, or making our websites do things that were against the nature of the web itself... Breaking the inherent flexibility and accessibility of the web by doing things that now we recognize as bad practices.

Jennifer Simmons: HTML evolved, and it got all these different tags, all these formatting tags. We started using tables to do layout, because it's all we had. One of the problems with it - there were many - was that if you wanted to change the font, you had to go in on every single solitary paragraph and put one of these little font attributes on your paragraph tag that said "I want it to be Times New Roman". You'd just do that over and over and over and over again, and there was no way to set that universally and have it be everywhere. You had to get interjected into every paragraph separately.

Jennifer Simmons: Then CSS got invented. We sort of like needed it; it didn't exist at first. After many years, people came along and said, "Hey, you know what? We actually need this thing." So it got invented. People can look up the details, I actually don't have the whole history of exactly how it evolved and all that, but it has changed quite a bit over time. There was the CSS as it got started, then around the days of CSS 2 it became really usable. CSS 2 was sort of everything really usable in CSS, and the industry itself kind of switched over to using CSS instead of using HTML tags or attributes in the tags.

Jennifer Simmons: In the early 2000s - 2001, 2003, 2004, we went through this whole nerd war, debating whether or not we should stop using tables for layout and start using CSS for layout. It took quite a lot of convincing... It took a decade, basically, of education and convincing people to separate their HTML and their CSS, to put the styling in the CSS, to not put any styling in HTML. To have the HTML be semantic. You could theoretically completely change the way a website looks - maybe you have a website that's been running for ten years; you come along and you rebrand your company, you want to change everything about how that website looks... If it's built properly, according to how we understand things today, that HTML probably won't need to be changed at all. Ideally, it doesn't, and you only need to change your CSS, and by swapping out your CSS, you get a completely different look.

Jennifer Simmons: It's part of what's so frustrating about what's happening right now with people who are giant fans of Javascript. I guess it's because there's a younger - some of us have been around doing this long enough now - new generation of people coming along who were not alive when these nerd wars were fought, or they were kids, they were toddlers, or something. They were not involved in making websites, so they don't know, they have no idea that we already went down this road. The original idea about how to style a website, that was to put the styling in the markup and to put it on every single solitary thing all over the place, and we learned very painfully why that wasn't a good idea, and we came up with a whole new way to do it, to universalize our styling and to put it in a special place that the entire website can just go to that one place and get all the styling; you could change it in one place, and there it is.

Jennifer Simmons: Now these kids today with their Javascript, they're doing styling in Javascript and having Javascript interject in-line styles into every single element separately. It's CSS instead of HTML stuff, but it's the same thing, it's the same bad architecture, it's the same bad idea for the same exact bad reasons. I spoke to somebody who had built one of these tools for a framework - a very famous tool for a very famous framework - to do in-line styles to interject all the styles into the HTML, and now that his tool is insanely popular and he's been working on it for several years, he's like "Yeah, I actually have changed my mind. I see now why in-line styles are a bad idea." So I don't know...

Jennifer Simmons: Back to the history of CSS... CSS 3 came along; probably people who are familiar at all with the web heard about CSS 3. There was a lot of stagnation for a while in the 2000s. We put a lot of effort into switching to CSS, and then things just sort of stagnated for a while. But then a new effort came along around CSS 3, a lot of new properties showing up; you could do a lot of things in CSS that we've been wanting to do for a long time, like rounded corners, that you had to do weird, hacky things... Then you've got web fonts, so you don't have to put your text in a picture anymore, in an image; you just let your text be real text and you can add any particular font you want that you have a license for to your website, and then you can have real text look a certain way, not just be these same five fonts that we've had.

Jennifer Simmons: Then CSS has gotten so complicated as they stopped having one specification, because CSS level 1, CSS level 2, CSS level 3 were all everything about CSS in one specification. The specifications got so complicated and big with CSS 3 that the CSS Working Group has split it out into a bunch of separate specs. Now you have a whole bunch of different specs, and each are at whatever level that they're at. There's more coming, there's more and more and more CSS all the time coming.

Jennifer Simmons: Stefan Tilkov:[00:37:12.14] Most people now take web fonts for example for granted, and rounded corners and some of the stuff that basically every website uses these days, but what are some of the newer things that are just emerging or just becoming available and usable.

Jennifer Simmons: When this new energy, this new group of people got involved with CSS, they intentionally tackled some of the easier things first, things that people desperately needed and wanted, like rounded corners, because they were technically simpler. Then once those were kind of done, they were able to start tackling the more complicated things, which are all about page layout.

Jennifer Simmons: We've never really had proper tools for page layout on the web; we started out by using tables to sort of force the browser to do some sort of layout, and we switched to doing floats when we switched to CSS.

Jennifer Simmons: Floats are a great technology. Basically, you take a thing and you sort of float it in the other things that come after it and wrap around it. That's great, we should keep using that tool; we will keep using that tool. But what we started using that tool for is not what it was intended for, which is to float a sidebar around the main content column and to maybe make the footer not be on top of the column, so you have to do this hack, and then you need to do this other hack, and it only works in certain browsers, so for this other browser you have to do this other thing.

Jennifer Simmons: I think that's one of the reasons that people hate CSS. Trying to get CSS to do things that -- again, if you need a hammer and instead you have a knife, that's not a hammer. CSS has not had proper layout tools for a long time, and it was hard. Browsers were inconsistent at their implementations, so if three different browsers that were important had slightly different ways that they rendered and understood your CSS, that was really annoying. But a lot of that is gone; a lot of that inconsistency is now completely gone.

Jennifer Simmons: CSS works pretty much exactly the same in every browser these days, and now we have tools for layout. Flexbox is a big one. You can do a lot of great things with Flexbox, and sometime this year I hope, or if not, then early next year, CSS Grid will ship (CSS Grid layout), which will completely change the way that everybody does layout. I think we're going to drop basically every tool that we're using for layout and switch to CSS Grid layout, and be able to do some amazing designs that up until now have been completely impossible.

Stefan Tilkov: Can you talk a bit about what Grid layout does?

Jennifer Simmons: Yes. If anybody has been trying to do page layout in CSS in the last five years, you've probably been using a framework. 960.gs was popular for a while, but when responsive design came along, we all sort of reached for different tools. A lot of people use the layout framework that's in Bootstrap. Foundation has its own as well, and then there's a bunch of standalone layout frameworks. But every single one of them basically does exactly the same thing, which is they break the space into 12 equal-sized columns. As any one of those columns gets bigger, the other columns are all also getting bigger by the exact same amount.

Jennifer Simmons: Then it offers you the chance to place items on those lines, boxes. You just make rows of boxes. Everything is a row of boxes on a 12-column grid. Visually, that's incredibly boring. Every website has its header on the top, with the name of the website and a navigation and a thin long line, then it's got a big Contact column that's not really as big as it could be or should be, and you want to look at photos, but they're kind of small, and then you get this sidebar that's full of junk and ads that you never, ever look at. Then down at the bottom you've got crap upon more crap upon more stuff you don't want to look at.

Jennifer Simmons: So many websites are done that way... And in part, they're done that way because of design conventions, but in part they're done that way because that's what the tools that we have have been wanting to make us do.

Jennifer Simmons: Grid layout has some of that in it. You could do that layout in Grid layout very easy, actually. You don't need a framework anymore. We'll be able to drop and dump our framework tools, which will be great. And if you want to do a 12-column or grid where they're all the same width as each other, you can do that, that's cool. But if you want to do 11 or 9 columns, that's also pretty cool. If you want rather than your columns being the same exact width as each other, you want to base them off of a golden ratio or some other mathematical array, you could do that.

Jennifer Simmons: CSS Grid will let us do rows, and you'll be able to define rows, which we've never been able to do in CSS. It's something we did in HTML tables, but then we dropped it when HTML tables went away. By defining rows, everything doesn't have to be jammed up against the top of the page, or jammed up against the thing that came before it. We can use white space. You can put an item near the top of the page and then put the second item much further down the page. You can place things on diagonals, you can really visually do things that are much more interesting, much different than what we're used to.

Jennifer Simmons: That excites me, both as a designer, as an artist, because I'm just tired of seeing all the junk, but also as a person who cares about providing a strategic advantage to clients, because you can really create a fresh experience, where people go to the website and they're like, "Oh, wow! What's going on here? I'm going to pay attention... What's the name of this website? Maybe I'll come back here again, this is interesting."

Jennifer Simmons: We haven't had that feeling in a long time, and I hope we do again. I hope we're able to break through the pressure to just do the same crap and do some much more interesting things.

Stefan Tilkov: How long will it take until this is actually usable by people in practice, because of the browser adoption and usability?

Jennifer Simmons: The way that CSS has evolved in really a lot of web technologies, it's changed quite a bit. In the past, when a new property came out, it went into browsers right away, but it would be in one browser and not the other and that was annoying, and it would be inconsistent, and all the bugs...

Jennifer Simmons: These days, the way it happens is all of the browsers are working on their implementation -- it's called "behind the flag", which means it's in the browser. You could download Chrome, Firefox, Safari right now, and they have the new version of CSS Grid implemented already in the browser, but it doesn't actually work, and it won't work unless you go into a special secret place and you click a button, you check a checkbox, which is called a flag.

Jennifer Simmons: I forget the syntax, but you have to go to "about://flags" in one of the browsers maybe, or some other sort of thing... You type these magic words into the browser where you would normally put a URL in the toolbar, and it opens up. You didn't know it was there, but hey, there's this whole super long list of crazy check box of experimental features that only people who make browsers are going to know to turn on and off, or people who are really good at making websites know to turn on and off.

Jennifer Simmons: If you want to try Grid out, if you want to make a web page and see what Grid does, you can do that, as a person who's a geek. You can write code and see how it's working. The browser makers are able to all four of them - Edge is working on this as well, although it's a little bit different for them because they invented this technology and they already put it into their browser years ago, although the specifications changed since then, so they need to update their implementation, and they will once things are a little more finished.

Jennifer Simmons: What this means is there are people who don't make browsers trying this out. I'm one of those people. Making websites, making demos, making examples... You can't ship it on a website unless you know your audience is going to turn on their flags, which they do not. That sounds a little bit odd, but this is actually a really, really good way. Over time, the way that this works has evolved; this so far is the best way for it to work, and there are downsides to it, but it's still also really great. What it means is that once all the browser makers feel like they're really done and we all agree that everybody's done or that the spec is done -- because what's happened is you have an idea, right? The people who invent this stuff - especially the complicated stuff, this is true - invent this stuff by writing it in a specification and say, "I think this is what we should invent, I think this is how it should work. Here's the syntax, here are the ideas, here is how the bugs should work, here's what should happen when it's broken. Everybody build this into your browser exactly like this, so that it's the same everywhere. This is why we have a standard, this is why we have a specification."

Jennifer Simmons: In a simple technology, everybody can go, "Okay, I understand that in my head, let's do it", and everybody does it and it works. But in a complicated thing, they started implementing this technology, and then you have it running code and you can make running code and you can try it out and you can say, "Oh, I like this, except it's not quite what we're going to really want. What we're really going to want is we're going to want to have gaps", so they added grip gaps. "Oh, this syntax doesn't make any sense. It seems like it was going to make sense, but when you start actually using it, it doesn't make any sense. We need to change it."

Jennifer Simmons: Over the last two years, there's been this kind of dialogue between the browser makers and between people who make websites, trying it out, actually building real websites, changing it, trying it out again, changing it a little bit more, trying it again, and the implementations have been happening all -- it seems like in secret... It's not really in secret, but in a level of nerdom that most people don't know about it. What it means is that the spec has been tested and thought out and changed and evolved, and it means that the browsers are nailing their implementations; they're really going to get them correct before they ship them. Then they're going to ship them.

Jennifer Simmons: All they have to do to ship them is just change the flag states and make it turn it on by default, rather than off by default. I expect once it comes out, it's going to come out very quickly. All the browsers are going to ship it -- sometimes it's been years... One browser ships something and it's years before the other browser ships something - that's not going to be the case here. I don't know if they'll come out -- it'd be so fun if they all came out on the same day or the same week - I think that's a fantasy - but maybe within the same three or four months, or within the same six months. It's going to feel like they all came out at the same time, once people start waking up to the fact that Grid exists, and then we'll be able to use it.

Jennifer Simmons: Of course, there'll be some users who still have older browsers around and we'll have to think about them, but the way that browsers work today, all of the browsers automatically update themselves, except for Internet Explorer. Oh, Safari doesn't yet either, but I bet you that's going to change. IE will never get Grid, but hopefully fewer and fewer people will use IE and everybody will be using Edge instead. Safari's on top of this as well, so I think it's going to happen.

Stefan Tilkov: But there's no real fallback strategy. For example with Javascript APIs, if there's a newer Javascript API, there's a chance of having a native Javascript implementation of that browser feature, a “polyfill” that will emulate the Javascript behavior, but there's no such thing for CSS, right? If I use Grid layout, I'm relying on the browser to support Grid layout. Or is there a way to achieve something like a fallback layout option for older browsers?

Jennifer Simmons: There's always ways to do fallbacks. With simpler technology, you can frequently just say, "Oh, it doesn't work. Okay, no big deal." CSS shapes, for example.

Stefan Tilkov: Or rounded corners.

Jennifer Simmons: Or rounded corners. They only work in -- well, rounded corners now work in pretty much every browser, but CSS shapes only work in like half the browsers; or rounded corners used to only work in half the browsers. So your corner is square, or your text doesn't flow around your item in a cool circle or a polygon, it wraps around it in a square. It's one of the things that is really beautiful about the declarative language - when the old browsers see a line of code that they don't understand, they just skip it, and the rest of the code gets parsed.

Jennifer Simmons: But with something like the entire page layout, you have to think about, "Well, what does it mean if a browser skips all of the lines of code for Grid that it doesn't understand?" There are other lines of code in there that it does understand, like margins, and maybe I put a background on here, I did this thing, I put this line over here and I did this box over there because I expected the Grid layout to work. So there's probably a bunch of code that you don't want to run in a browser that's not going to be able to run the Grid layout. There's probably also some code that you would like to run only in browsers who don't understand Grid, and you give them a separate layout - give them a simple layout. Give them just all the stuff in one big, long column and make it readable and usable, and don't worry about the rest of it.

Jennifer Simmons: There is a property called a "feature query" that's a little test... You write the syntax at support and open a curly bracket and you can put whatever you want in there. At supports display Grid. "If you understand display Grid, then I want you to run this code. If you do not understand display Grid, then I want you to run this other code." Or "Here's the default for the people who don't understand display Grid and do not understand a feature query", and then her is a feature query that says, "Okay, now that you understand this feature query and you understand display Grid, here's what I want you to do - I want you to do all this code in here."

Jennifer Simmons: It's just about architecting your code so that it makes sense that it's going to work, taking a little bit of time to think through the experience of different kinds of browsers, and then shipping it.

Stefan Tilkov: It's interesting that you mentioned the word 'architecting' the code. There's one thing that I found in projects of the last years, that there really is an architecture to this whole thing in every single project, and if the only people you have in a project that know what CSS is are the people who just basically are Photoshop experts, that's really going to be a problem. You need to have somebody who understands both the idea of architecture and modularity, as well as the design aspects, at least the technical parts of the design aspects. They don't have to be the best visual designer, but they definitely have to be the expert in these technologies.

Jennifer Simmons: Yes, that's another reason why CSS maybe gets a bad rep, because people experience really badly-written CSS. Every programming language is horrible when you do a horrible job with it.

Stefan Tilkov: I think we can all agree on that. What do you think of all those pre-processor options? Can you briefly explain them and can you give us your opinion of those things?

Jennifer Simmons: Yes. Pre-processors, they came along like any -- there's so many different kinds of third-party tools that help us out, and we use them and we don't use them, and we try them on a project, and sometimes we find one that we really like and we keep using it... LESS and Sass came along a lot like that eight or ten years ago, and over time, more and more people started using them for every project. Sass became the industry favorite, beating out LESS and beating out any other competitors that came along.

Jennifer Simmons: At this point, if I'm at a conference or in a big group of people, a big group of frontend developers and someone says, "How many of you use Sass?", usually 80%-90% of the room will raise their hands. It seems to be very, very common, and very much a tool that everybody's using.

Jennifer Simmons: As a pre-processor, here's what it does. Instead of writing CSS directly into a CSS stylesheet, I write Sass (which is basically CSS) into a Sass stylesheet. It's slightly different... Instead of being a .css file, it's a .scss file. Then I have a little tool - a lot of people use the command line; I like avoiding the command line when I'm designing because I like to think visually and I don't want to have to think in words on a command line, so I use a tool called Code Kit, which is a really fabulous GUI for basically a command line, and does lots of things.

Jennifer Simmons: One of the things it does is it runs a Sass. However you do it - there are many ways to do it... Some people use Gulp or Grunt, some kind of build tool. There's a build step - you save the Sass file and it gets built into a CSS file. As the engineer, I never touch the CSS files, I touch the Sass files, and Sass makes the CSS files for me. By having this extra step in there, there's a whole bunch of different things that Sass can do that are not in CSS itself.

Jennifer Simmons: The output is CSS. It's not changing what the browsers are doing, the browsers don't need to support Sass. There's nothing that Sass can do that isn't in CSS. Rounded corners work in Sass because rounded corners work in CSS. If Grid doesn't work over here, Sass isn't going to be able to do anything about that. What it does is it gives me tools to make it easier to write CSS. Nesting is one of my favorites, you can nest stuff. You have to be careful, because you don't want to nest too much stuff. If you nest things too much, then the cascade gets really out of hand.

Jennifer Simmons: Again, you have to be smart, you have to use good architectural principles, but nesting is handy. It's very handy to be able to nest selectors. You can create variables... You can define, say, some colors at the top of your cascade, at the top of your file or in another file, and make sure your files load in a certain order. Your variables are defined at the beginning, and then if you want to use them universally - you also don't have to use them universally, you can use them locally... But it's nice, because maybe you have a certain shade of red, but marketing is still working on the branding and you've written all this CSS, a couple thousand lines of CSS, and then they change the color of red - change it in one place and Bam! it's changed.

Jennifer Simmons: Or if you're designing in code - which I do a lot - and I think I liked the red, but I changed my mind, and next week I want to see what blue looks like, I can change it in one place and it changes it everywhere.

Jennifer Simmons: There are some other things... They're very simple tools, and probably people who are more used to writing hardcore -- what did you call it, 'hardcore programming languages'? Those people would go, "Well, how come we didn't have that before? It's not a real programming language."

Jennifer Simmons: There are some things that are getting pulled into CSS proper because it's become so popular in the industry. CSS is going to have variables - or does already have variables; I forget - which will work differently, because Sass variables are really just for creating some efficiency in writing the code itself, but CSS variables will be able to take inputs from the user on the frontend in real time.

Jennifer Simmons: But Sass is pretty great. There's other things I'm forgetting right now that it does that are pretty handy. It lets you create a whole bunch of separate files, which you see a lot in more UNIXy worlds... Lots of short files, so it can be much easier to keep your code organized and much easier to keep track of where things are, because you just sort of put all the typography in a typography file, and all the layout in a layout file, and all the code for styling the events in a file called 'events', and all the code for styling the news in this file called 'news', or however you want to do it. But then in the end, all of it gets concatenated in one stylesheet, which is better at least for HTTP/1 (much better performance) and it will also compress your CSS and remove all the white space, remove all the comments and things, so that the CSS files themselves are as fast and tight as possible.

Jennifer Simmons: Meanwhile, the code that the engineers actually handle and touch and read is much more expanded and easier to find stuff; you're not scrolling through 6,000 lines of CSS, you're actually able to just open up a file that has a hundred lines and read it and do what you need to and get back out again.

Jennifer Simmons: Sass has extensibility in it - you can write your own mixins. A mixin is like if you find yourself repeating yourself and you have the same eight lines of code that you need to use over and over again, you can turn that into a thing, and then you can call that thing somewhere else. Clearfix is a trick that you do all the time, that you're like "Oh, I need a clearfix." There's nothing in CSS for doing clearfixes; it's actually like six hacky lines of code. It's a total hack, but a very helpful hack. You just turn that into a mixin, and instead of having to remember those six weird lines of code every time, you just say, "include clearfix", and Sass will go get those six lines of code for you.

Jennifer Simmons: I've used a clearfix hack on every website I've worked on in the last 10-15 years. Why do I need to remember how to write that? Just give me a mixin for it.

Stefan Tilkov: Now I'm curious, what is the clearfix hack? What does it do?

Jennifer Simmons: A clearfix hack has to do with using floats. When you float something, it takes it out of the direct flow of the document, so something else could come along and end up on top of that thing in a way that you really did not intend. The things that come after it, you can say "clear both" or "clear left/clear right" and it will clear the stuff that's above it, but the thing that got floated, if it's a container itself, the objects inside of that container might not -- the height of that container should be bigger than everything inside of it, but it's not.

Jennifer Simmons: It's just a way to force a container to recognize a height for the stuff that's inside of it, instead of being too short.

Stefan Tilkov: You made such a great job of improving CSS's reputation, and I've ruined it all... So sorry. [laughter[

Jennifer Simmons: I know, but it's a hack. That's a perfect of like, we were using floats to do something that they were never intended for, and that stinks, it's hard. Over the last decade we've come up with these tools, and the tools really help. I probably screwed up my explanation of it because I don't quite understand it, because I don't need to understand it anymore. I used to to need -- now I'm just like, "Whatever... Include clearfix, I think that will fix it. Oh, look, it fixed it! I'm done."

Jennifer Simmons: Better than that is I'm going to use Grid layout, I'm going to use Flexbox. There is no clearfix hack needed inside of Flexbox; it's part of what's so beautiful about Flexbox - it gets rid of all this clearing and this height stuff that's all so crazy, and we can stop using broken tools for something they were never intended for, and start actually having a real layout system in CSS. But that's true in every language. Every language has its edge, like you wanted to do this thing and it doesn't, and say you have this hack, and they make it do that. Every language has that.

Stefan Tilkov: I agree. Good. I think that was an awesome set of answers. Do you have some good resources to point people to if they want to brush up on their CSS skills? What's a good way to start?

Jennifer Simmons: That is a good question. I will get you a little list of links and we can put them in your show notes. I know one book... If you enjoy learning by books, there's a book by Jen Robbins called Learning Web Design. It's an O'Reilly book. It's really good at teaching you HTML and CSS from scratch if you've never known it, without insulting you as someone who's just kind of dumb. I find that rare.

Jennifer Simmons: Lots of times, the beginner books are for real beginners, and it's hard to find a book that can respect the fact you've got a programmer's mind - you know what a code editor is, and you just want to learn the HTML and the CSS. It does have some of that stuff in there; it does teach people where to write code if they never have before, but it also has a lot of great -- like, it tells you what Sass is, and it gives you a picture of the whole landscape.

Jennifer Simmons: A Book Apart has great books... There's one "HTML 5" - that's a great little starter book for HTML. Book number 1, Jeremy Keith, they've just put out a new edition of it, so it's all updated fresh and new - really, really good. They have a CSS book or two as well, that I would highly recommend. There's a book on Sass...

Jennifer Simmons: The A Book Apart books are good because they're very short. "We know you're busy, and we know you have client work and you just want to learn this one thing. Here's how to use Sass", or "Here's all the new elements in HTML and you're not really sure which one to use for what. Here's the deal, here's what you need to know." They're great little reference guides, easy to read and powerful.

Jennifer Simmons: CSS Tricks is a great website (css-tricks.com). Probably if you ever do a search online for anything in CSS, it's going to come up as your number one, number two or number three result because it's super popular. Good blog posts, good reference guide.

Jennifer Simmons: Of course, MDN (Mozilla Developer Network) website is probably -- if anybody who's listening, it works on the web, you're like "Duuuh..." MDN is THE wikipedia of web technology. You need to know what something is, you need to remember that Javascript API, you need to remember that HTML element, you need to know "Which CSS property is that again? I remember the property, but I don't remember the attributes... What is the thing called?" Just, MDN. Yeah.

Stefan Tilkov: Great. Jen, that was awesome. Thank you so much for having been on the show.

Jennifer Simmons: Thank you.

Stefan Tilkov: Thanks to the listeners for listening. Bye!