CSS Layouts: Grids, Regions and @Supports, with Jen Simmons

In this episode of the Versioning Show, Tim and David are joined by Jen Simmons, Designer Advocate at Mozilla, award-winning podcaster and regular conference presenter. They discuss the future of CSS layouts with grids, regions and @supports, being a rebel with a cause in the workplace, and inventing French fry cheeseburgers with Houdini.

Show Notes

• Jen on Twitter: @jensimmons
• JenSimmons.com
• Jen’s podcast The Web Ahead
• Jen’s Experimental Layout Lab: labs.jensimmons.com
• CSS Regions
• CSS Working Group
• CSS Regions Considered Harmful
• Safari Technology Preview
• Houdini
• Net Award for Podcast of the Year
• CodePen Radio
• More Twitter links: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

And so it felt to me like I was breaking rules. And the more I did that, the more the people around me loved me. They were like, “You’re awesome!”

I was like, “Oh, I thought I was gonna get in trouble!” But instead, I would get a promotion …

---

Look around and see what you can do. If you want to do better work, and you see an opportunity, just grab it, and hopefully you won’t get in trouble, and you will be valued for the quality of your effort, and your craftsmanship.

---

I forget that people, when they use the word designer, mean eye-candy specialist, because that’s not how I see a designer at all.

---

I do think at some point, if you’re really in a place where you’re miserable, and the people around you are doing crappy work, and no matter what you do you’re not able to do better work, maybe you want to quit, right?

Find a team where it’s a better fit, where other people also want to do good work, and you’re able to thrive and have the people around you be better than you, and inspire you, and challenge you to do better work, instead of constantly pushing you down to do worse work.

---

I’m gonna invent French fry cheeseburger, I want every browser to support French fried cheeseburger, because I can do this cool thing in CSS and nobody does. So, instead of simply talking about it or writing up a spec or going to the Working Group and hoping they’ll write up the spec, I’m going to implement it using JavaScript and this Houdini API.

---

I think the CSS Working Group is amazing. I think this amazing miracle happens there, where really smart people have long conversations that take a long time to come up with a really, really good tool — and then it ships into browsers. And I don’t want that conversation to go away. I want that conversation to keep going.

Transcript

Tim:

Hey, what’s up, everybody, this is Tim Evko …

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number six of the Versioning Podcast.

David:

This is a place where we get together to discuss the industry of the web from development to design — with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

With us today we have Jen Simmons, and we’re going to be talking all about her show, The Web Ahead, and CSS, and whatever else we can think about. So we’re going to go ahead and get this Versioning started.

Jen, thanks for joining us. How are you doing today?

Jen:

Good.

David:

Great, we’re really excited to have you here. And before we get started, one of the things we like to do with all of our guests is ask a philosophical question. Since this is the Versioning Show, in your current career, what version do you think you are, and why?

Jen:

I don’t know, version 15, 17? I don’t know, something fairly high.

David:

That’s impressive! How did you get that high?

Jen:

I started a new version quite a few times.

Tim:

Would you mind giving us an introduction into some of the things that you’re involved in?

Jen:

Yeah, so these days I am a Designer Advocate at Mozilla, which means that I spend my time really teaching designers and developers — both, really — best practices around CSS, design, layout … And going to a lot of conferences, speaking at a lot of places, keeping an eye on what’s happening, and then taking a lot of the feedback from people who make websites back into Mozilla and helping to shape Firefox.

And these days — really it’s been the last three years — I’ve been focusing on layout design, page layout, what’s possible, graphic design, sort of looking at what we used to do. Kind of the history of layout design, and where it is that I think we’re going to be headed in the future.

David:

Well, the obvious question is: where do you think we’re going to be headed in the future?

Jen:

At the very beginning, we didn’t really do any sort of layout on webpages; there really weren’t any tools whatsoever to do that.

And then we started using tables for layout. Maybe some of your listeners remember the days when we would use HTML tables to position things on the page and kind of put them where we wanted them on the page. But there are good reasons to never do that. Really, we need to separate the styling from the actual content, or the stuff that is the page itself: that should be in HTML, and the styling should be in CSS.

And CSS got invented, and the industry started shifting to that kind of separation of concerns. We were using floats mostly to do layout, and there really were only a handful of things that we could possibly do. And we got kind of stuck in this rut of having a header and a sidebar and a footer and a main content column, and just laying out every single solitary website like it’s a blog.

Or now, these days, we do a lot of landing page designs, where you’ve got kind of a big hero graphic, three objects underneath the hero graphic, and then the next section is split into two halves. And then something further down is like four in a row.

And each of those is like a row where they’re lined up with a row; everything in that row is lined up with the other things in that row. And not stuff you see quite so dominant in magazine design or in poster design, or in newspaper design, or any other medium. It just seems like we have these very small number of layouts.

But, we got that way in part because of the tools that we had. We couldn’t do a lot of the things that we wanted to do with layout, because of the limitations of CSS. But those limitations are about to change, or really they actually have already started changing.

There’s a lot of new tools in CSS that are coming out this year, next year, or have come out in the last two or three years that we can use to do much more interesting page designs.

And I just think a lot of people haven’t heard about them. They don’t know the kinds of things you can do. So what do I think is going to come in the future? I think especially once CSS Grid is shipped, it will let us really do something very, very, very different with our page layouts.

David [4:08]:

I know one of the things that has kept people from moving forward has been the sort of staged way that things get rolled out, from only working in one browser, only working in certain versions of browsers, only working with people who have upgraded to such and such version of Internet Explorer or whatever.

I’m sure that that’s one of the challenges that you see with getting these things rolled out to people.

Jen:

Yeah, the web has evolved over the last 25 years. It isn’t what it used to be. It’s pretty miraculous in some ways the way that it has evolved, especially HTML and CSS.

Because of the nature of the languages — because they’re declarative programming languages — there’s a way in which we’re able to keep adding new syntax, new properties to those languages and have old websites still work. You don’t see that a lot in software development. If you wanted to download an iPhone app from 2009, it’s not going to run on your current 2016 iPhone. Or vice versa: you can’t take your 2016 iPhone app and run it on 2009 iPhone — or never mind run that app on an Android device, or another kind of phone. There’s a way in which each piece of software in that context is written specifically for a certain device, at a certain version number, in a certain time. And then, if you try to put it somewhere else, it just doesn’t work.

But the web is not like that. You can take a website from 2005 or 1995 and open it up in a web browser today, and it still works. Or you can take a website from now, and if it’s well coded — if it’s written correctly — honestly, you could open that up in a super old browser, and a lot of the parts of it might not work the way that the people who made it want it to work but, hopefully the basic purpose of the website — the reason the website exists — would totally work, and you could use it.

There’s a way in which, if you build your website that way, you’re going to be able to handle a plethora of different kinds of situations. Phones you’ve never heard of, if somebody’s got a brand new gaming console, and they bring it home and they’re opening up your website on their web browser on their gaming console, and you never even thought about gaming consoles when you built your website — you never tested them …

If you’ve built a good site with progressive enhancement, with HTML, CSS and JavaScript each doing their own job, and not trying to do the job of the other one, your site’s just going to work.

So, what does that mean for new CSS properties? It means that when new CSS properties come out, there is a period when that new property is not going be supported in current browsers that people are using, or the older version of the browser people are still using because they haven’t upgraded their browser yet. But, if you know how to write your code, and you do it well, it’s still going to be OK.

This is harder for full-page layouts. It’s easier when you’re talking about something like rounded corners. The browsers that understand rounded corners will get the rounded corner. The browsers that do not understand the rounded corners will show square corners. And if you’re OK with that … I know some people’s bosses are not OK with that, but they really should be OK with that. “Hey, you asked for a rounded corner, you’re probably going to get it, buuuut you might not get it …”

It’s OK, it’s not going to break the website: people can still book an airline ticket, they can still read the news article, they can still send a message to a friend — they just might do it with a square corner instead of a rounded corner, right?

So, with Grid, though — with full-page layout — you might think, “Well, what are we going to do for the entire page layout?” And I think we’re going to go through a period where we’ll be able to write fairly simple code for browsers that do not understand Grid — maybe do a single column layout, do something kind of not complicated — and then layer in Grid code for the browsers that understand, and take that code, along with any other code that needs to go with it — maybe you’re using different margins, or you’re using different kinds of topography — and wrap all of that up in a feature query.

This @supports syntax, that’s a little statement — a question in CSS — that says, “Hey, do you support this property? If so, run all of this code; if not, skip all of this code.”

David [8:16]:

I could see that. And since you’re coming from a designer advocacy perspective, it seems to me, historically, there have always been issues with designers thinking in a static way.

And I’m wondering if there’s a new generation of designers coming up that you’re seeing who are capable of looking at a design and seeing all of the ways that it can progressively enhance, or intelligently degrade, depending on context.

Jen:

I believe, very deeply, that if you’re designing for the web as a medium, there is a way in which you need to understand this is how it works.

Everybody’s using a different computer to go to your website. Some people aren’t even looking at the site; some people are only going to hear the site. Some people are going to read it visually, but they’re not going to get any of your styling, because they clicked a button and sent it to Instapaper or Pocket, or Read It Later, or they switched the browser into Reader mode.

So they’re going to get a completely different visual styling than the one that you originally shipped the website with. We don’t control that; the user controls that. We don’t have a say as to whether somebody uses their phone, or a tablet, or a laptop, or a desktop computer, or a fancy new screen with super high-quality pixels, and tiny, tiny pixels, and high-quality color.

Or they’re using some old machine that’s got giant pixels, and not nearly as many colors. It’s going to look different in every browser; it’s going to look always slightly different. So I think when people are “designing a website”, and they open up Photoshop and they start drawing pictures of what they think their website is going to look like when they’re done, that could be a handy stage.

It can be helpful to use that tool if you’re familiar with it. I don’t know; a lot of people like it, go for it, use it. But don’t fall under the delusion that the website will ever look like that Photoshop drawing, because it won’t. Photoshop renders fonts very differently than web browsers do.

You’re probably in a different color space, especially if you forgot to put RGB in your CMYK color space or something. It’s really easy for no one — for 0% of your audience — to have the same experience as you have when you’re looking at a Photoshop document.

And so what you’re designing is a prescription, in a way, of a whole lot of ideas of how you want it to go, but you’re not completely sure which combination any one person’s going to get.

This article’s got to have more words in the headline, and so the photo’s not going to be nearly as good as the photo in your original design. This other example over here, there’s three authors instead of one author, so what happens to the place where the authors’ names get listed? Is that still going to work out when the content isn’t what you expect it to be? That’s the job of a web designer, because we’re designing for the web.

Tim:

I definitely like the idea of designing for the worst-case scenario, because all too often in my work — and I imagine everybody else’s work — you get that perfect design, everything looks great, and then you implement it and the title is just ten characters too long, and everything is then weird …

Jen:

Yeah.

Tim:

Then come all those on-the-fly adjustments that we developers love so much. [Laughs]

Jen:

Yeah, I think as front-end developers sometimes — especially in the days when the whole design would arrive as a PDF in an email —

Tim:

God!

Jen:

— and you’re supposed to reverse engineer with these pictures of what it’s supposed to be; you’re supposed figure out what the website’s supposed to actually be, based on these pictures.

And you start reverse engineering it, and yeah, you’re like, “Wait, you used lorem ipsum text, and you have exactly the same number of characters in every single one of these examples. What happens when it’s longer, what happens when it’s shorter, what happens when the photo’s not this aspect ratio? Are we designing a system that allows for those things, or are we designing a system that forces people to always make their photos exactly this aspect ratio?”

There’s a whole conversation to be had about the design, and I want designers involved in that part of the conversation. I don’t want it to just simply be front-end developers making decisions by themselves, without discussing it with anyone, without the client seeing the results.

So I think that kind of process, where everybody’s in separate rooms and working on this in separate months, and not even meeting, and the only communication is a PDF that gets emailed back and forth — that never worked. And especially in the age of all these different screen sizes, and responsive web design, and now with all the new layout technology that’s coming, it really doesn’t work now.

Tim [12:50]:

Yeah, very true. So, speaking about design, can you go into a little bit about how you got started in this career field, as well as what it means to be a designer advocate for Mozilla?

Jen:

Yeah, how did I get started. I majored in sociology in school. I was a theater (almost) major, I minored in Math, and I graduated and went into theater. So I was doing a lot of theater design, a lot of theater tech. Lights, sounds, sets, working as a carpenter, as an electrician in some of the bigger theaters, and then in some of the smaller theaters, getting a chance to do some design work.

I worked in nonprofit arts world, and did 300 shows in eight years. While I was running that particular nonprofit, I did all the graphic design work — although we didn’t call it graphic design, we called it “desktop publishing”. And it just made sense, when the web came along, for me to learn the web technology as well.

So I built that nonprofit’s website, and really enjoyed it. I loved the combination of design and coding. I had done a lot of coding in high school, and I hadn’t done it in a while so it was cool to get back to it. And then I just kept going as I was working, and just kind of worked my way into focusing more and more and more on web design itself.

Did some work for Google, I did a bunch of the front-end design on CERN, the new CERN websites. I don’t know, a bunch of clients, too many to remember at this moment. And then, yeah, last year I got this job at Mozilla in the Developer Relations team. So some of my colleagues call themselves “developer advocates”; “developer evangelists” sometimes is the job title.

I like the words “advocate” better than “evangelists”, and I like being a designer advocate — because I feel, if we really want to do great work, if we really want to help people make better websites, then we want to be talking to developers, and designers, and strategists, and executives, and content folks.

Because it takes all of us doing great work to end up with a great result. You can’t only focus on engineers and expect that somehow the site’s going to be fast, when the problem is not that the engineers don’t know how to make fast code; it’s that the ad network puts all this bloat on the page, or the designer picked five fonts and so, right?

Everybody needs to think about performance, everybody needs to be talking about any one of these topics to make it really successful.

David:

I agree 100%. And especially nowadays, the term “designer” is expanding so much. It used to mean you would think just a visual design, or a graphic designer. And now “designer” often gets involved in every aspect — from user experience testing, through the launch, and all the way through, making sure that a product really meets the needs of the business.

Jen:

Yeah, I forget that people, when they use the word designer, mean eye-candy specialist, because that’s not how I see a designer at all.

It’s one of many things that somebody does, but it’s almost like thinking that a developer or an engineer is only in charge of the repo and deploying the repo on the live server — like the sysadmin stuff, where a developer’s doing all these other things as well.

Designers really are thinking about the audience for that site; and what do they need? What do they want? How are we going to get that to them? And part of that is, how do we communicate the story that we want to communicate by using visual graphics — through art direction, through fonts and color, and those kinds of things?

Because those matter, and they tell a story, they create a feeling about the site, and they create an experience when someone goes to a site and they see that styling.

They get a sense of where they are based on that styling. But it’s just one tiny piece of design — the layout of the page, the content, the choices of what the content’s going to be. And the interfaces: where are the buttons? What are they? How many buttons do we have? How does the navigation work? Do we have navigation? Where is it? All of those decisions all factor into the design.

Tim [16:51]:

So, you mentioned a lot of solutions to problems, like getting a PDF tossed over the fence, or getting five fonts in a PSD or Sketch file.

What advice would you have for developers or designers who find themselves in atmospheres or companies where those problems tend to persist?

Jen:

Yeah. Any one of us has the the opportunity to cross a fence. You can even show up at a meeting that you weren’t invited to, but you could also stand up from your desk and walk over across the room and ask the person.

I was working as a front-end developer on a big team, where I still to this day have no idea who designed that project, because we were never allowed to meet any of those folks. We didn’t have their emails — nothing. We just got these PDFs, and we were supposed to figure everything out.

And I had no authority. I wanted to get groups of people together to make decisions. And I wanted to architect our content types, and architect the naming conventions that we were using as a group of developers — and I couldn’t even get any momentum around that.

But what I could do was get up from my desk, and walk over to the people who were going to be adding content to the website — because they were actually in the same floor, they were in the same building, on the same floor as we were. And I would ask them, “What do you want this to be named?”

And I knew I was only affecting my work, and I wasn’t affecting the entire team, but I would go ask them, and I’d just be, like, “Well, this is for you all.”

And I think we should have done this, I think we should have had a big meeting where everybody got together and did this as an overall, overarching process, having architected the whole thing.

But I can at least just do this little bit, and walk over and get out from behind this wall I’m supposed to be behind. And sometimes I felt like I was really going to get in trouble; I think I got to a place where I kind of didn’t care, at that job, if I got in trouble or not.

I just wanted to do the best work I could. I knew I wasn’t going to be there super long, because it was kind of driving me crazy. And so it felt to me like I was breaking rules. And the more I did that, the more the people around me loved me. They were like, “You’re awesome!”

I was like, “Oh, I thought I was gonna get in trouble!” But instead, I would get a promotion, if I were in a situation where I could have gotten a promotion — which I was not, but I don’t know.

So that’s one thing. Look around and see what you can do. If you want to do better work, and you see an opportunity, just grab it, and hopefully you won’t get in trouble, and you will be valued for the quality of your effort, and your craftsmanship.

David:

I think that’s excellent advice.

Jen:

I do think at some point, if you’re really in a place where you’re miserable, and the people around you are doing crappy work, and no matter what you do you’re not able to do better work, maybe you want to quit, right?

Find a team where it’s a better fit, where other people also want to do good work, and you’re able to thrive and have the people around you be better than you, and inspire you, and challenge you to do better work, instead of constantly pushing you down to do worse work.

David [19:54]:

Well, maybe some of our listeners will be able to take inspiration from that story. I’m curious in your work nowadays, what are the challenges that you’re facing?

Jen:

I feel very blessed right now. I get to sit around and make up examples. I just was doing this last night: if you go to labs.jensimmons.com, I have a whole entire pile of sketches really — and by sketches, I mean not in Photoshop or in the program Sketch, but in code, of ideas for layouts. Some of them are polished-up, simple examples of “Here’s how CSS shapes work; look, you can take your text and flow it around a circular object in a circle, instead of in a square. Look, wow, isn’t that amazing you can do that on the web.”

A lot of those are examples that I give in the talks that I present on stage, but there’s also some in there that are kind of half broken, because I’m trying to figure things out.

Last night, I was working on some ideas that I’ve had for the last two years, but I hadn’t had a chance to code them until this past week. If you open up a magazine (or a newspaper), the articles are laid out in columns. And on the web, we really only ever get one column, and we have moved to this world where we’re doing layouts — you see a lot of work that looks an article in medium.com, where there’s a column of text that starts at the top of the page (because we’re speaking English, a left to right situation), centered (it doesn’t have to be centered; could be a bit off center), but basically, you don’t want the text to go super wide. So there it is, constrained, a nice line length that makes it easy to read. And you could have some big pictures or some big graphics: New York Times has done this a lot, Atlantic is doing great work too online. Some beautiful layouts, where the other things besides the text are laid out in interesting ways, and help break up the text a little bit. Simple quotes that are sort of half sticking into the text column, and some possibilities. But we’re still stuck with ooone loooong column of text.

So I’m on this quest to figure out what it will take to give us real tools so that we can do multiple columns. And you can see there (it’s hard to describe on an audio podcast) but you can see, in that exploration, some other possibilities. Multi-column layout is a great way to lay out text if you’ve got small amounts of text. You can quickly lay it out in columns, and it will work beautifully — it will reflow whenever needed.

But for a long article, I don’t now, is it really going to work? I’m not sure. So I think we need the technology that has been proposed, called “Regions”. All the browser makers haven’t agreed yet. The CSS Working Group has not agreed yet that that’s a good idea. There’s some people who think it’s a really bad way to do this kind of tool. And I’m fine with that: we may need different code, I don’t know, we need a better tool. But I think the result is we need something to be able to give us the kind of result that I was able to code up yesterday.

And the reason I coded it up is because some of these ideas about new CSS technologies are in some browsers. So the examples that I’ve made work only in Safari Technology Preview, because the folks behind Safari put Regions into Safari, and it also has Grid, which some of the other browsers don’t have. You need that combination. They’re not the only browser with Regions, but they are the only browser with both Grid and Regions.

So, anyway, that’s a long, not very succinct answer, but I used to live on the edge, where, here’s some really cool, practical stuff that you can totally do right now, that’s brand new, and I’ve pushed myself over the edge, into “OK, this is totally not practical! You can’t do this at all!” But I want to see if this is something we want, because I want to then lobby the CSS Working Group, and lobby browser makers, to invent and build these things if this is something that we really want.

Tim [24:02]:

It is quite a bit like lobbying these days, which is a very interesting challenge to get all those fun, exciting features in browsers.

Last question from me. Do you have any thoughts on the Houdini project as it relates to CSS layout?

Jen:

Houdini! I’m still learning a lot about Houdini, and about what I think about Houdini. I am a bit concerned — not because of Houdini, because Houdini’s just a technology.

I think the cool thing — once Houdini is in browsers — will be that, I guess we should explain for people who don’t know. Basically it would be a way for a group, or really smart engineers to say, “Hey, I wish such and such were in: I want hamburger,” (I dunno, that’s a bad word, because we already made that) … “French fries! I want French fry cheeseburger. I’m gonna invent French fry cheeseburger, I want every browser to support French fried cheeseburger, because I can do this cool thing in CSS and nobody does. So, instead of simply talking about it or writing up a spec or going to the Working Group and hoping they’ll write up the spec, I’m going to implement it using JavaScript and this Houdini API.”

And anybody can download my library, and plug it into their website, and then everybody who visits that website — suddenly their browser will support French fry cheeseburger as well. And I don’t have to wait for all those people, because waiting for people and agreeing with people is a pain in the ass. And, “Yay, we don’t ever have to agree on anything ever again. Yay, we don’t have to have these long epic fights on email, and make all these decisions with humans. Humans are annoying. Yay, I can just do whatever I want by myself.”

I think the CSS Working Group is amazing. I think this amazing miracle happens there, where really smart people have long conversations that take a long time to come up with a really, really good tool — and then it ships into browsers. And I don’t want that conversation to go away. I want that conversation to keep going.

I know it can be hard, I know it’s exhausting, I know it’s annoying, but really good work comes out of it.

David:

It’s good that there are people thinking through the philosophy of these things, and tracking this, and keeping us aware, because as developers we all need to be aware of these things.

And so I’m curious, how can our listeners find you and find out about these efforts you’re involved in?

Jen:

Yeah, so go to JenSimmons.com. That’s the headquarters of everything I’m working on.

Also I have a podcast called The Web Ahead, which, if people haven’t listened to it, I’d love for you to check it out. There’s well over 100 episodes on all kinds of different technologies, where we talk about “What is that technology? How could it be used? What is it good for? What is it not good for?” Sometimes we talk more about philosophical issues of the web, and what the new technology means, and about the history of the web as well.

So that’s at the thewebahead.net, and like I said labs.jensimmons.com is the place where I’m putting all of my experiments these days. Follow me on Twitter, @jensimmons. I’m on Twitter quite a lot.

David:

Very cool. Well, thank you so much for joining us on the Versioning Show. We’ll be sure to put links to those in the Show Notes as well.

Jen:

Great. Thanks for having me!

[Musical interlude]

Tim:

So it’s kind of funny — one of the things that we forgot to ask Jen about was, she won the Net Award for Podcast of the Year last year. And that was going against some pretty big podcasts, like CodePen Radio and some other ones that are really good.

David:

I know — she didn’t even mention that, she’s so humble about that.

Tim:

Yeah, definitely. And her podcasts are just a wealth full of interesting and just fun information. So I definitely encourage any of our listeners who are interested in CSS layout and — I don’t know — designing websites for CERN [chuckles] to go check out some of those episodes.

David [28:00]:

She goes into layout in ways that twist my head around. I’m still getting my head around flexbox, and she’s talking grids, and regions, and all sorts of things that are only in the Safari Technology Preview, pre-release version — it’s just amazing stuff.

Tim:

Yeah, I asked about Houdini, and she brought up a very good point — where Houdini lets you pretty much create how the browser is going to display CSS. So you basically get to “hack” the CSS rendering engine. And that can be a little bit of a scary thing, because what’s to keep you from actually writing CSS and, you know, just keeping standards and things updated and specifications? I want to remind us all that it should be used very responsibly. Don’t skip good CSS standards altogether, because in doing so, you kind of black box any development and just further good use of the CSS standards that way. If you’re writing your own rendering engine, you’re not giving browsers much of a reason to continue to support and improve on CSS as it stands in a global space.

David:

Do you think that Houdini is really going to be relevant — do you think it’s really going to be the thing that takes off, or do you think that it’s sort of the flavor of the month in terms of philosophies, but not necessarily something that people are going to be thinking about a year from now?

Tim:

That’s an excellent question. I think it excites some of the more intellectual and philosophical developers out there — some of the people who have actually spent time reading and working on the spec. And I think it excites them because they might be thinking of it in terms of, oh, IE — or, OK, I shouldn’t say IE anymore — Safari does this terrible thing with CSS on their Chrome browser for iOS. And so let’s overwrite how the spec works in this specific setting for this one property. Then I see some of the big players in the game, like Facebook, saying, “We want CSS to behave this way. So let’s — because we can — write our own CSS rendering engine in JavaScript to support a more React/Redux-like approach.” And that’s where I see things starting to crumble.

David:

The thing that I think, when I think about that, is pretty much what Jen was talking about in terms of designers — or visual designers, in this case — trying to force things to be exactly what they want them to be, instead of recognizing that, as a medium, the web is about writing a prescription for how things are supposed to be presented, the way that Jen described.

And ideally, using progressive enhancement, allowing whatever environment the user has chosen, to display what there is in the way that’s most appropriate for that environment. As opposed to going in and using tools or techniques, like this Houdini, to force that everything must follow this particular prescription.

Tim:

Yeah. Because, at the end of the day, the real issue is progressive enhancement — number one, right? Progressive enhancement, because you could write your own rendering engine, and then have nothing for browsers that don’t support those APIs. And then, number two, I sort of feel like writing your own rendering engine kind of black boxes your thing on the web, wherein the web is no longer this open thing where you can see how everything’s getting done.

It’s a lot harder to dig through, a lot harder to see what’s going on. And let’s say, for example, you do manage to write something with the Houdini API that’s amazing and wonderful, and does exactly what you and a thousand other people need. Let’s get that into the spec, let’s make that a real thing.

Let’s not make that a library that I then have to add on to my site, increasing the overhead, slowing down the performance, all that sort of stuff. I’d rather see it get shipped with the browsers as a native feature, rather than now everyone has to, “Oh, you want this? Well, just do it yourself now, because you have the tools.”

David:

In this sense, it’s almost like the modern version of inserting a hack. Instead of going through and actually saying “OK, there’s a bug,” or “There’s an opportunity,” the browser makers are not recognizing and advocating for enhancements that can apply to everybody.

Tim:

To be fair, this is just about what I have read and what I’ve heard about Houdini, and it is still a very new thing. And you can’t really use it today, because it’s still such an in-development concept.

David:

I will also agree with you that I have very little knowledge about Houdini, other than what I’ve read and what we’ve discussed.

So if it turns out to be our next overlord, then I gratefully bow down to our new overlords. And if it turns out to be the flavor of the month, then I’ll just applaud myself for being right.

Tim:

Sounds excellent. You can’t lose with that strategy.

David:

Exactly!

I was really impressed with having Jen here, and the notion that Mozilla is really putting intention behind designer advocacy, which is not something that I hear a lot about and certainly not enough about.

Tim:

Yeah, as far as just being in it for the good of the open web, man, Mozilla has not lost that battle.

David:

It’s interesting, because I used to be a big Firefox user, and now I’m primarily a Chrome user. And I’d actually be kind of curious what our listeners are doing, and making that relationship between Mozilla and Firefox, and how that is playing out for them.

Tim:

Yeah, that’s a good question. You know what, for those of you listening, why not tweet us or email us, or run up to us on the street and tell us. Tell us what browser you use, why you use it, what you love about it, and maybe we’ll take some time to discuss that in one of the next episodes.

David:

Don’t run up to us on the street. I tend to hit when I’m startled. But do tweet us @VersioningShow.

Tim:

Tweeting’s best.

[Laughter]

David:

All right. Well, Tim, thank you for joining me on this show. I think this was a lot of fun, and Jen was a fantastic guest.

---

Tim:

Everybody, thank you so much for listening. We always enjoy getting to talk technology with all of you.

David:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes.

Let us know how we’re doing.

Tim:

We’ll see you next time, and we hope you enjoyed this version.