415: CSS Aspect Ratio, Rendering Engines, and More with Jen Simmons
Jen Simmons is back on the show to talk with us about her new HTML Essentials course, CSS Aspect Ratio, rendering engines vs browsers, and a big announcement from her personally!
Guests
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier.
Chris Coyier: Hey! I'm doing okay, you know, as well as I can. I'm in the booth again. I've got my equipment set up here. I've been playing with my audio equipment a little bit.
Dave: It looks good. It looks good.
Chris: Does it? Okay. Thanks. I hope it's okay. The only difference in the booth here is I bought this little cloud lifter thing, which supposedly pairs with this SMB 7S, whatever it is, the sure mic because it's low on gain and this thing gets some free gain. Anyway, hopefully, I feel really gain-y!
Dave: Radio!
Chris: [Laughter] We have our very favorite guest here on ShopTalk Show this week, probably been on the show more than any other guest, Jen Simmons. Hey, Jen!
Jen Simmons: Hello!
Chris: Jen is the best because she knows all kinds of stuff about HTML, CSS, and browsers and how they work, who to talk to, what's happening, and just everything - everything. Jen, actually, you have maybe a little bit of news for us, huh?
Jen: Yeah! I haven't talked about this publicly yet but I'll do it right here. People, probably, if you know my work over the last five years, you know that I've been a developer advocate at Mozilla, but I am going to be leaving Mozilla and becoming a Web technologies evangelist at Apple.
Chris: [Whistle]
Chris: Whoa!
Chris: Apple! The big Apple. My dream job.
Jen: At Apple with the Safari team, the WebKit team. Yeah.
Chris: That's so cool.
Jen: Yeah. I'm excited. I'm excited. I'm excited. I haven't started yet. I don't work there yet, although, I guess when the podcast comes out maybe I'll have started by then, but yeah.
Chris: Yeah.
Dave: Yeah, you'll be about four hours into your Monday.
[Laughter]
Dave: You'll be right through employee training.
Jen: Right.
Chris: You'll be thinking about lunch - thinking about lunch.
Jen: I'll be waiting for California to wake up is what I'll be doing.
Dave: Yeah, exactly.
[Laughter]
Chris: Yeah, so you don't know much about the things. You know that there is some little dancing involved, you let us know about, which is funny. Not necessarily resigning, but you leave the CSS working group board because you're no longer a representative of Mozilla and then are immediately what?
Jen: Rejoining. Yeah. Yeah.
Chris: Joining again.
Jen: Yeah, as an Apple -- as a representative from Apple, yeah. Yeah and I think the browsers are different, the teams are different, the companies are different but, in many ways, I'll get to do very similar work in advocating for what so many of us advocate for, which is a really healthy Web ecosystem where technically we have the tools we need, we have the features in CSS, HTML, JavaScript, or the APIs that we need, and we've got ideas about best practices. Yeah.
Chris: Well, it's a big deal to me to have you there because I think you just bring so much clarity to what's going on with browsers that there'll be more clarity from that angle.
WebKit is the name of whatever you want to call it, a rendering engine. I'm terrible at knowing how to call stuff like that.
Jen: Yeah.
Chris: But it's Safari.
Jen: Yeah.
Chris: I even decided on CSS-Tricks, I'm not even going to try to play the game anymore of what to call the right thing. I call it Chrome, Firefox, and Safari. Everybody knows what I mean. Even if I'm talking about it's a WebKit feature or something, like, who cares. It's a Safari feature. I don't know if that's good for the Web or not.
Jen: Yeah, I mean I think most Web developers, most people who make websites are thinking about the browsers and that's the name of the browser: Safari, Edge, Chrome….
Chris: Yeah.
Jen: QQ browser, Samsung Internet browser, Safari, Firefox browser. Yeah, there's the rendering engines, which are really just the core, the plumbing underneath it all that actually renders the page. There are fewer rendering engines than there are browsers, so the Blink rendering engine is used by Chrome. It's not used by Edge. It's used by Samsung Internet. It's used by Opera. It's used by a bunch of other browsers. Where the WebKit rendering engine is used by Safari, the Gecko rendering engine is used by Firefox.
Chris: Mm-hmm. That much I feel like sometimes I've got it. But then you talk about JavaScript or something and you're like, "This is how Blink does JavaScript." Then you're like, whoa whoa!
Jen: Yeah.
Chris: No, Blink doesn't do JavaScript. V8 or something does JavaScript.
Jen: Oh, right.
Chris: Then you're like, "Oh, shoot."
Jen: Yeah, it gets complicated because then also sometimes it's the operating system that does the heavy lifting and sometimes it's the browser rendering engine that does the heavy lifting and it's not the same. Different browsers might be different about who does this part of the font rendering. That's the kind of stuff--
Chris: Sure.
Jen: --I ask people who understand browsers more than I do when I want to know answers to those questions because I don't know either.
Chris: I think Chrome, just this week, released just a slight UI refresh on what form controls look like, so something like the meter element looks a lot different than it did. It used to have this kind of gradient, glossy look to it and now it doesn't, checkboxes look a little bit different, and stuff like that. It's nice. I think most people applaud the effort, especially because there's some accessibility stuff that comes along for free.
Jen: Well, and that effort has been driven by folks at Edge, Greg Whitworth and people at Edge, and they've been collaborating heavily with the folks at Chrome, especially because now they do share the Blink rendering engine.
Chris: Right.
Jen: But a lot of that work is not just about Blink. It's about Web standards, actually. It's about figuring out how, ultimately, slowly, ultimately, how can we give authors, people who write CSS especially, people who write the code for websites, access to styling form controls so that you don't have to reach for a JavaScript framework and you can still use all the proper semantic HTML.
Chris: We didn't get that yet, though, right?
Jen: No, not yet. Not yet, but this is one step in that direction. It also is a little bit overlapping with dark mode. I think all the form control stuff was put into browsers a million, trillion, zillion years ago and it's old code and nobody wants to touch old code, especially if it's 10- or 20-year old code.
Chris: Yeah.
Jen: But they've had to. The browser engineers have been kind of forced to go into that code because of dark mode, because they had to make dark mode versions of all their form controls. Once they got in there, they were all like, "Uck!"
Chris: Ooh, let's clean house.
Jen: Yeah, it's a big nest of awfulness that we've been knowing that this is a nest of awfulness and we should fix this anyway for authors. We've been meaning to get to it, but we haven't because nobody wants to touch the old mess of awfulness. But when you're forced to, you might as well get in there and do it right. That's what this is about.
The CSS working group is working on it. Other working groups are working on it. It's a slow-rolling, multivendor, multiyear process to actually get us to a place where we have what we want.
Dave: With my clients, I always say we have to mow the lawn before we can do any landscaping.
[Laughter]
Dave: It's sort of the analogy I like to use.
Chris: Aw, that's nice.
Dave: That's from my coffee table book on Web analogies that I'm going to put out here.
[Laughter]
Dave: I'm going to have all of them: architecture, landscaping.
Chris: Sports, yeah.
Dave: Sports. Oh, yeah. Oh, sometimes you have to level-set everything and make all your little widgets match. Then you can think about that stuff like dark mode.
Jen: Yeah.
Dave: Even, you know, how do we let a user style this?
Jen: Right. Yep. Yep. Yep.
Chris: It seems like the baby steps so far were like, well, let's make checkboxes and stuff support pseudo-elements.
Jen: Mm-hmm.
Chris: Then if you need to use those to force styling over, cool. It seems like that's temporary-ish in that, ideally, you can use other pseudo-elements that are named that are for that job rather than, like, kick it off the page and use the pseudo-element in its place to do something else.
I feel like you were just talking about it or getting opinions or something on one that was very specific to the file picker element.
<a href="#t=00:08:18 >00:08:18
Jen: Oh, yeah, because we were talking about in the CSS working group. They were naming a pseudo-element to be able to address the button that you would use, a user uses when they upload a file. It's not the regular button - button. It's a special button for file upload inside the file upload thing.
Chris: Right. Right.
Jen: We were naming that and naming can be complicated and hard to do. We were doing it kind of quickly knowing that we could immediately reopen that issue and rename it a different name later if we need to. But in those moments, sometimes, I kick a tweet out where I'm just like, "I don't have time to think about this carefully. I'm just going to see what the crowd thinks."
Chris: I think I saw one of the first responses is, "Is that name final?"
[Laughter]
Jen: Right. right.
Chris: The name, people didn't like, immediately.
Jen: Because we get stuck with the names forever.
Chris: Yeah.
Jen: But also, you don't want to spend 45 minutes discussing a name on an hourlong phone call.
Chris: True. True enough. The type="file" input has been notoriously difficult to style.
Jen: Yeah.
Chris: So it's cool to see little baby steps in that.
Jen: Yeah, and another one that's ongoing, underway is one of the things that's most challenging about styling all these form controls is getting rid of the default styling that was there before you start applying your own styling. For a while now, there's been this WebKit appearance property, this prefix property that's a throwback to when we had prefixes, and it works in more than just WebKit. It works in maybe even all the browsers right now. I don't know.
It was just quickly drafted, I assume, so there's been an effort. I think that Mozilla actually hired Igalia for a year to work on this, to hunt down what is the ultimate solution so that the CSS working group can properly spec appearance, the appearance property as a real CSS property.
Chris: That's a fun journey, wasn't it? My gosh.
Jen: Yeah.
Chris: We could spend the whole time talking about that.
Jen: Yeah, and I don't know the details. I'm pulling them off the top of my COVID addle-brain, so I'm not really sure. But anyway, it's complicated. This stuff is really hard. There is a lot of old, ancient technical debt, which makes it harder than other things are and everybody is working on it. Everybody realizes what we would ideally like to get to is a place where every form control can be fully styled 100% in CSS and you don't have to replace the HTML elements with whatever: div, div, span, span, span, JavaScript, JavaScript, JavaScript.
Chris: Yeah.
Jen: Not that there's anything wrong with using JavaScript if it's the appropriate solution, but that you wouldn't be forced to use it because there was something lacking in CSS or HTML.
Chris: Sure. The classic talking point is, like, "Sure, replace it, but it's really hard. It's pretty spectacular." Just think of a select element. Well, you need to tab to it. It's got to have a focus style and then there's a way to open the select menu, like, what is it: the space bar, the return key, or whatever? Whatever you code in JavaScript better be exactly what the browser does too. If the browser supports two different keys to open it up, then your JavaScript better support the two different keys to open it up.
Jen: Yeah.
Chris: Then the arrow keys need to work to get through it and the tab keys need to work too. Then how do you select one of them? Is it return or is it the space key again? Well, whatever the browser does, that's what your JavaScript needs to do. There's a pretty close to zero percent chance that you're going to get it right.
Jen: Yep.
Chris: Another thing I think of with selects, though, is there's the outside of a select and the inside of a select. The outside has been getting a little easier to style over time. I think we're almost to the point where there are some pretty decent patterns out there for styling the outside of a select, just what it looks like by default when you're unopened and just looking at it. Then it immediately punts on the inside. You can't do anything in there.
Once it opens up, then it's just an operating system. What's funny about that is that the inside doesn't come from the browser. It comes from the operating system, I think, which is one of those weird little tricky things.
Jen: It gets complicated.
Chris: Yeah.
Jen: A lot of these form controls, they are replaced elements, which, hey, we're going to talk about that more later, too, what a replacement element is. They are not part of the website code. They're part of the browser. The browser is like, "Hey, I have radio buttons for you. Let me give you one. Here it is. Boom."
Chris: [Gasp] Yeah.
Jen: The code, the HTML says, "Hey, I'd like to have a radio button," and the browser is like, "I have one of those. Here it is."
Browsers do that differently and browsers do that differently especially depending on what operating system they're using or what device they're on. A phone is going to do that differently than a desktop browser. A tablet browser might do that differently than another browser because, hey, you have a phone with a touchscreen. You would like to have a different keyboard show up. Oh, you're at a computer that just has one hardware keyboard. Well, you're just going to use the hardware keyboard. We want that. We want the user experience design where the color picker that shows up, for instance, is appropriate to the context that you're in.
Chris: Mm-hmm.
Jen: It's part of the operating system, and it matches the color picker that you're using in all of the other pieces of software as a user that you're using color pickers in. But then that means the website, it just gets complicated. Some brand wants the color picker to look like their brand. It's like, well, no, because the color picker isn't part of your website. The color picker is part of the operating system.
Chris: Which is kind of good, right? I heard that the color picker is going to start having an eyedropper in it. The eyedropper should be able to grab color from anywhere on your whole screen, which of course only the operating system can do. But how rad is that? That would be a real limitation to design software on the Web is that you just don't have that cool color picker that you would in a native app, but I love it when the Web gets little tiny things like that that make it more competitive to desktop….
Jen: Yeah, and color spaces. There are so many different color spaces. If your team is trying to handmake your own color picker, is it only going to be RGB or is it going to be HLS or is it going to be the new, fancy color space that just came out and the fancy fanciness? Are you going to rebuild your color picker two years from now because there's a new color space on some of your users' operating systems? No, you don't want to do any of that. You just want to call the color picker, you want the color picker to show up, and you want the color picker to do its job. That's a more extreme example, but it's sort of a blurry gradient. A text field with a button is sort of simple and the color picker is really complicated. I don't know. There's this blurry thing in between like numbers and keypads and select lists. Yeah. That's why it's not going to be something that's going to hurry up and, oh, we've got this whole thing solved in three months and we shipped a whole bunch of new CSS properties and we're done. It's like, no, this is kind of a multiyear project to solve this.
Dave: Well, and even, like, you think of a date picker or whatever. Dramatically different between a desktop and a mobile browser.
Jen: Right.
Dave: Just fundamentally different. You get the little slot machine UI, usually, on a mobile thing.
Chris: It's so weird.
Dave: Then you get the full calendar app, which is also kind of weird. I guess that's the best way to pick a date, but it's like, "Oh, I've just got to click 12 years into the future if I want to do that." There are always those weird things. Yeah, I'm curious how it'll shakedown. Do you think those are going to become--
Chris: And this is just one tiny little corner of the Web, isn't it?
Jen: Right. Yeah.
Dave: Yeah, do you think those are going to become standards, like the Mozilla thing would be the same as the Chrome thing?
Jen: No. No.
Dave: Do you think they'll all kind of be just whatever those users or platforms or whatever need?
Jen: Yep.
Dave: Yeah.
Jen: I think it's going to remain complicated for good reasons because it's better user experience.
Chris: Yeah, so the spec just says stuff like, "And then the browser shows whatever it wants to." [Laughter]
Jen: You know, no, I haven't read those specs, actually.
Chris: I feel like that's the vibe. I haven't either, but I think it just kind of punts, you know. Then show a date picker if you want to, or don't. Up to you.
Jen: Right. [Laughter]
Dave: Well, you know, it would be--
Jen: Right.
Dave: There are some innovation concerns. If Apple would have launched with a date picker or whatever or a select box, you know, and the iPhone with that. It would have been like ten miles long. Everything flying off the screen when you select your country. They probably made a very smart decision to break the convention there. The same with maybe the date picker. Yeah, maybe using a calendar on your phone isn't that radical inside a Web form. There's good innovation. I don't know.
Jen: Yeah, and on the face, this seems simple. It seems like, "Hey, every user should get a really great experience and every team should be able to brand that experience with their brand. Why don't we have that?" [Laughter]
Dave: Mm-hmm. Okay.
Jen: Well, because, oh, it's one of these things where the simplicity and the ease of user experience is one of these -- actually, it's really complicated to make something that beautiful, elegant, and simple. Branding is complicated, but it's being worked on anyway, bit by bit.
There are -- like last summer, I was making a lot of demos of form controls for HTML for the HTML course that I put together. I sort of explored, myself, what is stylable right now? You can style checkboxes. You can style radio buttons. You can style text fields. You can style button buttons. There is a lot that can be styled. I encourage people to do that as much as possible and to reach for other tools, JavaScript or whatever frameworks, or whatever, when you hit the limits of today's technology. When you have to style a select, for instance, you're going to need to reach for something, but don't assume it.
Chris: Even that one is fascinating to me because there's the styling on the outside, the styling of the inside, and then functionality, too.
Jen: Yeah.
Chris: Some people don't even care so much about this styling, necessarily. They just wish that you could, for example, type in AL and get Alabama and Alaska, a trimmed down list. Maybe you can select both of them and not just one of them, and stuff like that.
Jen: Yeah, there's a need for a search bar in the top of a select list in many, many projects.
Chris: Right, like datalist-esque, which is kind of cool that datalist kind of broke ground there a little bit in that it does work like that. You type in and you get a trimmed down list.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Hoefler&Co. Welcome. As a sponsor, I am stoked about it. They are my favorite type shop out there.
The URL is one of the best URLs you could possibly imagine, typography.com. Nothing is more critical to a good Web experience than just clear, clean, attractive typography, which is good news because it's not particularly hard on the Web anymore. Type on the Web has just gotten so good. It's affordable and easy to integrate. Hoefler&Co. fonts are the designers of some of the world's most beloved typefaces like Gotham and Knockout.
You know the CCS-Tricks logo? It's just Gotham rounded, all caps, CSS-TRICKS. [Laughter] That's it and I've used for so long, I feel like it's striking. I feel like it's just coming into its own, really. I really like it, still.
All the typography on CSS-Tricks is also Hoefler&Co. fonts: Ringside, Sentinel, Operator. Ringside is the title, Sentinel is the serif'd body copy, and I've only been using it now for--what's it been--three, four months, and I just love it. In fact, my own team, just yesterday, complimented me on the typography of the site. I've been tweaking it forever. It's finally really beautifully come into its own. It's something I take really serious. Operator mono is just my favorite monospace font for code. Really. It was one of the first ones out there that had the kind of slight cursive look for italics, which was just genius and has been copied many times since. I love it.
At typography.com, you'll find nothing but the highest quality fonts. They're screen optimized for the browser, complete families, deep character sets, clever features to help you solve design problems. Then, on the site itself, there are free tutorials and stuff to help you become a better typography. Oh, thank god. I could use it.
Download their fonts to self-host them or it's $99 a year to get a cloud typography subscription, which lets you use the entire library for $99 a year. You get 15% off that if you use coupon code SHOPTALK at checkout. Just one word, SHOPTALK at checkout. Typography.com/shoptalk gets you that deal. Incredible deal. Incredible fonts. Thank you for the sponsorship. Love it.
[Banjo music stops]
Chris: There used to be this thing called lynda.com. Then it sold to LinkedIn. Now it's called LinkedIn Learning and you have a brand new course on it.
Jen: I do! I have a course on LinkedIn Learning called HTML Essentials, which is a long-running course that they've had for years and it needed updating. They reached out to me and I made a course and now it's online. It's all the new thing and it's not a course that's assuming you knew the old stuff and now it's updating you or assuming you want to know the long, torrid history of all the different.
It's just like, no, no, no. You're busy. You want to know how to use HTML. What is the deal with HTML in 2020? Here it is. Here's how to do images. Here's how to do responsive images. Here's how to do forms. Here's how to do semantic HTML. What is a paragraph? What is a link?
It's really for anybody. It's for people who are on some kind of Web content team who were English majors in school and they're all about writing and marketing, maybe. They don't know anything about technology but they have to click over in their WordPress blog to the HTML section. It freaks them out. They don't know what any of that stuff is.
It's that kind of thing but, also, I've tried really hard not to make it -- because I think, for any of us who are a little bit more advanced, trying to take a beginner course is really annoying. It's not a beginner course. I think LinkedIn Learning does have an even more simple beginner course, and this course is, like, "Oh, you might be a Ph.D. holding computer science major who is an expert in Java and something-something, and now you switched to the Web team. This HTML thing is weird, annoying, and you're not really sure which element you're supposed to be using for what. You don't really understand it."
The course is really for both audiences at the same time.
Chris: That's nice. Even though it seems like HTML gets typecast as the easiest thing that we all do as front-end developers, we all know that it totally isn't. The longer you spend away from it, I think anybody can appreciate a course like this coming back into it, especially how you put it, like the 2020 HTML, you know. It's been a while. Just give me that stuff. I know extremely smart people that take courses on really basic stuff all the time just to feel like they read the manual.
Jen: Yeah.
Chris: Just to be like, "You know what? I see this stuff now," you know.
Jen: It was a little bit interesting--maybe I'll use that word--to realize how much I learned while putting the curriculum together for the course. [Laughter] I was like, yeah, you know, I don't really know this part of HTML. Maybe I'll … on this and find out the expert actual answer to what you're supposed to be doing before I write this chapter. Yeah.
Chris: Isn't that funny?
Jen: Yeah.
Chris: To try to write something, do a video on something, it will expose every misunderstanding you have, every bug that exists with the thing. If you've got to do QA, I do QA for, like, a new feature or something that I'm working on. I'm just like, "This looks good to me. Let me shoot a video quick." Ten bugs I find or ten things that I'm like, "How does that work?" [Laughter] Cool. Yeah.
Dave: I saw a video. You explain code pre- and BR.
Jen: Yeah.
Chris: I just was like, yeah, I couldn't do that. [Laughter]
Jen: [Laughter]
Dave: Is it code before pre- or pre- and then code? Do you even--?
Jen: Exactly.
Dave: Sometimes you just do -- oh, god.
Jen: I spent a long time, like almost a year, writing the curriculum. But the course is under three hours. I think it's 2.5, 2 hours and 45 minutes or something it turned out.
Dave: Yeah, that's awesome. That's like the perfect skill buff for somebody, like an English major who now is finding themselves doing websites or something. I think a lot of managers who maybe don't have the full technical suite, this would be a great place to start. You could even point your manager towards that so, when you're talking about, like, "Oh, we need a new text area or something," or why it's more complicated than that, you could kind of bridge that gap. You could fill in the knowledge gap between you and maybe a manager or somebody like that. This is pretty helpful stuff.
Jen: Yeah. You know I think one of the things that people struggle with HTML is that they want to know which element they're supposed to use when, right? That's the big question. There are some answers. You should use one of the headline elements when you have a headline. You should use a paragraph element when you have a paragraph. You should use form field elements when you have form fields.
But I think sometimes it's hard for especially engineers when there's an ambiguity when maybe there's not a clear answer. There's not a specific rule about when to use an H3 versus when to use an H4.
Chris: Yeah, or worse ones like a section.
Jen: Right.
Dave: An article.
Chris: A citation.
Dave: A div.
Jen: Should you use a regular list, unordered list, or is this a definition list? What is a definition list again? What exactly is that for?
You know, as I dove into this very, very deeply, I kind of realized that the reason that there is that ambiguity is because -- and I'm believer that HTML is a programming language. It's a different kind of programming language, but it is a computer language. It's for computers. It's not a human language.
It bridges the gap between human communication and the way the computers think and computer machine code. It's actually the only language that I know of, or maybe there are some other obscure ones. In our world of languages that we use, it's the only one that really is trying to take human meaning, which is so complicated. The fact that I just said, "Sooo," right? Instead of, "So." Like the way you use your voice, the intonation, the exact words.
Dave: You em'd it. That was an em. Yeah.
Jen: That was an em, right? You're trying to take that complexity of human communication and translate it to something that computers can understand, and so there isn't always a right answer. It is messy.
That's what it means to write when you're writing. If you work for a newspaper and you have a newspaper editor rewrite your weekly column and help make it better before it gets published in the newspaper, they're picking through, choosing the words, and saying this word, that word. There are rules of grammar that are very clear sometimes and then there's a lot of ambiguity in a lot of places where it's just polish or it's opinion or it's skill. It's the art of writing. It's not a rule.
I think HTML reflects that and so I try to communicate that in the course, too, to be like, "Here. I'm going to tell you the rule rules, but then I'm also going to show you the ambiguity and the places where it is more of an art and it's not."
If you have these scared, weird feelings because you're like, "I don't know. This is stupid. I don't know. I don't know how to do this so, therefore, it's wrong because I couldn't be wrong," okay, have those feelings and realize that you're not doing it wrong. It's just ambiguity. It's ambiguous because it's about human meaning and there isn't a clear answer.
Dave: It's a programming language that maybe it's very syntactical, but it has a grammar almost. There's kind of a right and a wrong way to express something. That's different than maybe a lot of programming languages. They don't care if you wrote a while loop or a for loop. One may be better than the other, but they don't care.
These debates are so tired to me. [Laughter] I'm getting old. I turned 40. I've crossed the threshold to curmudgeon. But when people are like, "HTML is not a programming language," and it's like, well, I can write in H2 and that's a function that makes the screen reader say, "Heading level two." You know? You don't know that when you get started or you don't use a screen reader or something like that, but these things have meaning.
Yeah, I was on a front-end -- oh, I'm going to murder it. I was on a podcast.
[Laughter]
Dave: Dave Rupert, you're terrible. Web Platform Podcast, that's it. Even just using the example of a list, you come onto a list with a screen-reader and it's like, "List. Four items." It's like, oh, well, that's great because, as a non-sighted user, I know I'm not going to be here all day. I'm just going to get through four things and I can arrow through. But if it was just 200 divs in a row, they'd be like, "This sucks. This is not helpful to me," so there's a difference.
Like you're saying, it's like grammar plus programming. I like that.
Jen: Yeah, it's semantics plus activating APIs and toolkits that are embedded in the browser.
Dave: Yeah.
Jen: That you may or may not know about because, yeah, some of them are for devices, input devices or output devices that maybe you don't use or you're not aware of, like the color picker or the H2 being read by a screen reader.
Chris: Right.
Jen: You're actually using -- you're asking the browser, "Hey, I have a video file. I want you to put a whole bunch of video controls here. Do that. Put the video controls on the thing. I don't want to program that."
Chris: Yeah.
Jen: You have that in you. You do it.
Chris: There's so much to know.
Dave: What's a color picker on a braille display? What is that? Literally, Dave Rupert does not -- I can't fathom it. I have no concept for what a color picker on a braille display, like 16 little bumpy guys.
Chris: Hmm.
Dave: I don't know what that's like but it matters to people and that's very important.
Jen: Right. Let the browser engineers do some of that work. Let the operating system engineers do some of that work. Then when you make a website, you leverage that work that someone else did for you.
Chris: Think of how much we have to talk about here. We're just scratching the surface. There is a ton to know just about HTML. There's a ton to know just about CSS. That's what makes it such a hot topic whenever it's brought up, which, if you're part of the Twitterverse or places where developers hotly talk to each other, not a week goes by ever, ever, ever, ever, ever where there isn't some conversation that's like, you know, "HTML and CSS people are programmers too!" There'll be some battle about it every week because it really just is complicated. To have a really strong, commanding knowledge of HTML and CSS alone is massive. Then if you actually have it, you're like, "No, there actually is a lot here."
Dave: I remember, Chris. I think it was Eli Finch talking about utility CSS stuff, which I'm not the hugest fan but he made a good argument in this video. It was, CSS is a very, like -- you have to learn it. You learn it piece by piece. Some pieces are easy background color. Those are like, "Oh, okay, I get that. I see what it does," but kind of the long part picture of CSS is, you know, hundreds of properties and values and things like that. You kind of have to -- it takes a big -- you have to study it. You have to learn kind of all these combinations and keep them in memory. It's a little different. It just is a special skill. It's a lot of learning.
Jen: Yeah, and I think CSS -- I think for CSS, kind of one of the important core things that folks should learn -- I don't know that there are the best ways to learn it yet but, if you write CSS for long enough, you end up figuring this out. You end up learning it, which is the mental model of layout. How does layout work? How does sizing work? How do things become the size that they are when they end up on the page?
I think that, over the last ten years, especially before 2017, there was a sense of, like, we've got a handle on this. You put a percent width on everything. You float everything. You put some margins on everything that are also percent and you're good.
The message of the last--what's it now been--three years is basically, okay, that was nice but also horrendously horrible, so let's ignore it. Let's forget all of those things that we used to depend on, except you'd probably have to maintain an old codebase. You can't quite forget it yet but, if you're writing a new thing, don't think about those old things and let's learn the new model. Let's learn the new model that has everything to do with Grid and Flexbox, using Flexbox the way that it was intended to be used and not the way that we were using it before Grid came along, and the stuff that we are going to talk about today, like aspect ratios, sizing, fit content, min-content/max-content, and intrinsic sizing, like, what the heck is all that stuff?
I feel like it's not an infinite amount of information to learn. Once people have a chance to really start to understand it, the new model, the real model, the real, "Guess what. We finally have a layout system on the Web in CSS. We don't have a pile of hacks. We actually have a layout system, finally." It's a beautiful thing. It's a beautiful creature. Then knowing the code and the syntax is much, much easier if you have that mental model in your head.
Chris: Yeah.
Jen: That's the thing I've been wanting to get more to. I have this whole course in my head that's been sitting in my head for three years that I've been wanting to do to teach exactly that, but we're going to talk about some of that today.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by X-Team. You've got to check this out. This is so cool. It's literally x-team.com. Love dashes in domain names, of course, by the way.
The idea, let me explain it. You can hire them. They have this tribe of developers. Those developers, they'll parachute in and help your team do stuff like, "Gosh, I need some more developer help on this thing. Where do I turn?" Go to X-Team and you hire them to help you build your thing. That's cool, but that's almost not what I'm talking about here.
They're also looking for developers to join their team to be one of those developers that goes and helps other people. It's a completely 100% remote company. By parachuting, I mean figuratively, you know. You don't actually parachute in. You just help them remotely and you help them scale.
If a company is like, "We've got to scale right now!" they're going to reach out to X-Team and you're going to be one of those developers that goes and helps those companies, which help really awesome companies like Riot Games who make "League of Legends." Wouldn't that be cool? Kaplan, Coinbase, Fox Broadcasting, Beachbody: who knows what you're going to work on, but they have a bunch of cool clients. Chances are, you're going to work for multiple of those cool clients.
You can, if you choose, live and work in one of their roaming hacker houses. Probably not right at the moment with the pandemic and all, but that's a thing that they have. It changes locations monthly. I don't know. It just gives you a chance to explore the world, explore beautiful locations, take part in their adventures, and share a passion of coding with other people you live with. Pretty darn cool.
There are all kinds of great benefits, too. They give you $2,500 a year just to spend on doing things that you love to be healthy, energized, and all that, go to conferences, buy some video games, buy some cool photography equipment. $2,500, just like bonus bucks to spend on stuff, that's pretty cool.
Anyway, X-Team seems very cool. I guess, check them out for either reason. Do you need to get some devs on your team real quick? You hire them to do that.
But the important thing is, does that lifestyle sound cool to you? Do you want to be a part of a team that does that? Go! Do it! Apply! Be a developer like that. It sounds awesome to me.
[Banjo music stops]
Chris: Yeah, let's do this aspect ratio thing. There's a new thing in CSS. Now, these things are funny. They're not like JavaScript libraries where some developer just invents it in their head and then it ships and it doesn't just arrive. It gets talked about forever and it rolls out in different browsers differently. There's spec stuff and browser stuff. Nobody knows that better than Jen, but let's just call it a new thing for the sake of understanding it.
It's a CSS property. The property is aspect ratio, aspect ratio, and it takes a value, something like 1 - 4 or something.
Jen: Slash.
Chris: Yeah, I said dash. I meant slash, like how you might express an aspect ratio in text, you know, like slash. I don't know. CSS is getting hot with slashes lately, I feel like. I love slashes. And it does something.
When I first saw it, I had a million questions. I was just like, "Oh, my gosh. Another thing that can influence the size of what an element is sized at." That's going to be complicated because there's already all kinds of stuff that can influence how big a box is. My mind reeled with, okay, what does it actually do? How is it influenced by other things that size a box?
Then my question was like, when does it ever win? You know?
Jen: Right.
Chris: "How powerful is it?" is kind of where my brain goes. Also, let me just shut up. Jen, what's up with aspect ratio?
Jen: So, there are some complicated questions that I hope we have time. We'll definitely try to get to them, but let's start with the simple thing. If you have an image, and let's say your image is 400 pixels wide by 300 pixels tall, which means that it's 4 units wide and 3 units tall, you could express that image as a 4x3 image. In fact, in the world of television, for a long time, that's exactly what televisions were. They were all 4x3, so if you ever float around with filmmakers, video makers, and such, you're constantly saying 4x3, or whatever.
Then, for instance, television switched to "widescreen" and everybody talks about 16x9 because, instead of being 4 units wide and 3 units tall, most television, in fact, if you go to a television store today, the television you go home with is going to be a television that's 16 units wide and 9 units tall. There's all this math in the video world, but I won't talk about it right now because it'll just be more confusing.
That idea of an aspect ratio and, in the world of television, for instance, when you say 16:9, it's always the width first and the height second. That was one of the debates among many that we had over the last debating the CSS property because that's actually the inverse of how other things in CSS work, but it's going to be 16x9. You could say aspect-ratio:16/9 and you would basically be saying, "Hey, the thing I'm putting this CSS property on, I would like you to be 16x9."
Let's imagine you have a div, an empty div, just a blank, empty div. You put a background color on it of pink. You put aspect ratio 16:9 on it. Then what you're going to get is a box that is going to be 16x9. Although, probably, especially if you come from the decade of responsive Web design where everything has a percent width on it, so you might imagine in the Western writing modes, in the horizontal TB writing mode, which is the default on the Web, that the width, you might give it a width. You might give it a width of 50%.
Chris: Yeah.
Jen: You give it a width of 100%.
Chris: Let's you didn't, though. Let's say you didn't. It would be zero pixels tall, right?
Jen: No, but let's start with the simple thing.
Chris: Okay.
Jen: Let's say you tell the box to be 1,000 pixels wide and you tell the box to be like a div. You tell this div, "I want you to be 1,000 pixels wide and I want you to have an aspect ratio of 16x9," then what it's going to do -- or let's say the aspect ratio is 2x1, 2/1. What it would do is say, "Oh, so we're going to make the 1,000 be the 2 and then we need to make the height be 1, so the height is going to be 500."
So, what the browser is doing is it's transferring the calculation. It knows how wide to make that div and then it transfers the aspect ratio. It uses the aspect ratio to sort of calculate and transfer into a height. Then the height is 500 pixels. In some ways, it's very simple. That's what it does. Now, the reason it works is because height is set to auto by default.
Chris: Hmm.
Jen: You have a width at 1,000. You have height of auto and an aspect ratio of 2x1, so the width of 1,000 pixels transfers to a height of 500 pixels.
Chris: It does the other one.
Jen: It does the other one.
Chris: Elements have a width already because it's width auto.
Jen: Right.
Chris: Then it'll make the height for you.
Jen: That's a good way to say it. Let's say that div had a width. Instead of having a specific width, a width of 1,000 pixels, maybe it had a width of auto. Maybe you didn't give that div a width or a height. You said nothing about the height or the width of that div and it had a width and a height of auto. What, by default, the browser will do is it will, in a horizontal TB writing mode, make that width be 100% of the containing block.
Maybe the container that it's in is 1,000 pixels, and so the width just fills up. If it's a div, it fills up. If it's a block, display block-level element. An inline-level element will do something different. If it's a block-level element, it will fill that width 100% by default, so it'll be 1,000 pixels.
Then you didn't say, "Be 1,000 pixels," but it is 1,000 pixels because it's the same as its containing block that has a size. It might be nested four levels deep and maybe the direct parent is also auto and the grandparent is auto and the great-grandparent is auto and the great-great-great-great-great-grandparent is 1,000 pixels.
Chris: [Laughter]
Jen: It might have that. It might have that size kind of transferred down. This probably sounds very complicated as I say it in words, but I think that anybody who manipulates CSS, you already kind of know this that you have a headline. You didn't put a width on that headline. The headline is in a section. It has the width. The width of the headline is the width of the section. The height of the headline is auto, so the height of the headline without aspect ratio, let's talk a little bit about height.
If you don't have aspect ratio, you just have a width. The width is going to be either what you told it to be or it's going to be the size of the containing blocks if it's a block-level element because it's going to be auto and auto means, "Hey, be as big as you can be and stay inside your containing block."
Height, by default, if you have an empty div, the height of the empty div, what is it? It's zero. You can't even see the div. You could put a background on it, but you're not going to see it because the height of an empty div, a truly empty div, is going to be zero.
But the height of a headline, let's say we have a headline of six words. The height of the headline is going to be min-content size. It's going to be the size it needs to be in order to hold the content. If you make the browser windows narrower and if everything is flexible, then the width gets narrower of that headline. What happens? The height gets taller. The height gets taller because the words start wrapping.
We sort of have this sense of -- we know this. If you know CSS, you know this organically. You may just never have thought about it consciously. But that's what height auto does. Height auto is going to be min-content size. We're not switching writing modes. You can switch the writing modes, in which case everything will flip the other direction, in which case everything I've just said about width is height and everything I just said about height is width. It works both ways. All of this stuff works both ways perfectly. But, we're not going to talk about both writing modes because then we'll really break everybody's brain.
[Laughter]
Chris: Okay, so first of all, let's say you apply neither a height or a width to an element, but you do apply an aspect ratio, 2x1 or 16x9 or whatever you want. This is where I confuse myself. I thought that it wouldn't do anything, but it does do something.
Jen: It does.
Chris: Because the width is already -- the width is already, like, I know it's not actually 100% but it's kind of like 100%.
Jen: Yeah.
Chris: It's auto. It fills the whole area.
Jen: Yup.
Chris: If it's a block-level element, that is. Okay. Then, okay, so it's 16x9 then. That's beautiful.
Jen: Yeah.
Chris: You have background pink on it, you'll see a 16x9 pink box. But let's say the content in it then pushes it too big for itself.
Jen: Yep.
Chris: Does it behave like you put a height on it and lock that background color?
Jen: It is what we would want it to be.
Dave: Oh.
Jen: Let's imagine H2. You've got an H2. It's got six words in it. You have width of auto on it because most boxes--
Chris: Mm-hmm. Don't have a width at all.
Jen: What is a webpage? It's got a gazillion, trillion boxes. Even if you write CSS properties, you write width 100 times, you probably have 1,000 boxes, so the other 900 boxes have width auto on them, right?
Let's say you've got this H2. The H2 has no width applied. It has no height applied, but it's in a section element and the section element is going to have some sort of a size. The width of that H2 is going to be the width of the section element. Let's pretend it's some magical moment. It's 1,000 pixels wide.
The height of the H2 is going to be, without using aspect ratio, the min-content size. If the headline is one line, it will be the height of one line of text. If the headline is on two lines, it will be two lines of text.
If you say, "Aspect ratio 1:1," you could say, "Aspect ratio 1:1," which basically says, "Hey, I want you to be a square."
Chris: Yep.
Jen: Then what will happen is that headline will be 1,000 pixels tall. Let's say it's in a box. Let's say the section is now 400 pixels wide. Then the headline box will be 400 pixels tall. It will be hot pink, purple text because that's what you said.
Chris: Yeah.
Jen: The text maybe will take one or two lines and then you'll have a whole bunch of empty space so that the box for the headline is a square at all times. But then, let's say you make the browser window really, really -- you make the containing block -- the section, you make the section containing block really, really, really narrow.
Chris: Right.
Jen: It's only 200 pixels wide and your H2 is pretty big and it wraps 7 times.
Chris: Yep. Yep.
Jen: Your aspect ratio box is going to grow and be enough. It's still going to be min-content size and the min-content size--
Dave: It'll be a tall rectangle.
Chris: That's -- this is the moment. It now, for lack of a better word, ignores your aspect ratio. It doesn't care what you--
Jen: It ignores your aspect ratio. We debated that extensively.
Chris: Yeah.
Jen: It ignores your aspect ratio because that's what authors are going to want. They're not going to want aspect ratio. You're not going to want to have the H2 sticking out of its own box.
Chris: Right.
Jen: Especially because the paragraph that comes along after it is going to come along right underneath it and what you would get is colliding text. One of the main principles of CSS is that--
Chris: Avoiding data loss in that way.
Jen: Avoiding data loss.
Chris: Yeah.
Jen: Avoid data loss. That's why in the CSS's awesome meme, the word "awesome" sticks out of the box because if you truncated the word "awesome" and you cut off the sum part, you would get CSS's awe, and that doesn't mean the same thing. One of the core principles of CSS is to avoid data loss.
In this case, the aspect ratio, the height of that box will min-content. It's like min-content always and aspect ratio--
Chris: Right.
Jen: --if aspect ratio is more than min-content--
Dave: Cool.
Jen: --unless you write it differently because you can write additional syntax, which I don't remember right now, and tell it, "I want you to always be a square no matter what. I don't care if stuff sticks out. Always be a square."
Chris: Well, you can also do that with a max height or something.
Jen: Yeah.
Chris: If you were concerned about it growing too tall on you, you can force it not to.
Jen: Yeah. Sorry. I should know exactly how to do that because I did know before I was sick for two months.
Dave: Min-content wins or beats aspect ratio by default.
Jen: Yep.
Dave: That's awesome. That was actually -- no, that was just a concern because everyone wants a square and then--
Jen: You don't.
Dave: Then they resize it on mobile and they're like, "Whoops." [Laughter]
Chris: This is what does it for me. You know what? Aspect ratio never wins, ever. It's the weakest thing you can do. It's just a suggestion. But if anything else beats it--content, other properties, anything--it loses.
Dave: Mm-hmm.
Chris: It's just, yeah, that's what it seems like to me.
Jen: Maybe. Maybe. If Elika Etemad was on the call, she would know definitively the answer to that question.
Chris: There is also precedent for this growth thing. I know one of the most popular ways to do aspect ratio now without this, and we should talk about that too because the browser support for, like, Safari, which I guess you'll find out on Monday, we don't know what's happening with aspect ratio at Safari. At least I don't. There's no support at all, where there is support in the other browsers.
Jen: There's no support anywhere but Firefox is working on it. We were the ones who wrote the spec.
Chris: Yeah.
Jen: The Chrome team is also working on it. They … first, but yeah.
Chris: It's in Canary.
Jen: Yeah.
Chris: I'm looking at right now in Canary. That's why I was able to mess around with it.
Jen: I'm so happy. I'm so happy Chrome is onboard with it but it's funny sometimes when everyone thinks Chrome invents everything if they happen to ship it first. It's like, well--
Chris: Well, yeah.
Dave: Well, I'm looking forward to being released from this prison. Do you think--? I mean, I want to use it on video iframes. Is that a great use case? where would people be using…?
Chris: Oh, yeah. I would think so.
Jen: Right.
Dave: Like images, videos?
Jen: Before I answer that question, let me answer the other thing that comes up related to what we were just talking about. We were talking about when you have a width of auto or width of a defined length and a height of auto. The aspect ratio will transfer the height across. It will calculate the height based on the transfer size. If you have both are auto in the horizontal writing mode … there is a width, so it gets transferred.
But what if you say height. What if you say, "I want width of 100% and I want a height of 200 pixels"?
Chris: Mm-hmm. Yeah, you get the free -- it does it the other direction too, right?
Jen: No, you get what you ask for. You get width of 100% and you get height of 200 pixels or you get width of 500 pixels and you get height of 200 pixels and aspect ratio is ignored in that case. Aspect ratio only works -- the aspect ratio property only works if at least one of height or width is auto. If neither one of them is auto, it's not going to do anything.
Chris: Oh, right. Mm-hmm. Mm-hmm.
Dave: Because you said … override.
Chris: But if you use aspect ratio auto instead of height, you will get a width from it.
Jen: Right. Yes, if with is auto. That's an interesting use case where let's say you have a headline and you say 1:1. You say, "I want it to be a square," and the width is auto. If height is also auto, then width will be the size of the containing block and it will be a square, unless there's too much content, in which case it will grow. But, if you say height 200 pixels, and let's imagine that actually it's an empty div and not a headline, so we remove the content size, intrinsic size of the content from the imagined demo. If you have an empty div and you have width of auto and you have a height of 200 pixels and you have an aspect ratio of 1:1, it will transfer from the height to the width.
Chris: It will, yeah.
Jen: Yeah.
Chris: Just like responsive design, media queries, and stuff, I think that's going to be much rarer. The width aspect ratios are way more natural to the Web.
Jen: This is where you're tapping into what I've been trying to do for the last five years, which is, please stop thinking like it's 2010 and responsive Web design is the hot thing because I think there's a lot of potential creativity where you could say width auto, height 200, or min-height 200, aspect ratio 1:1, and you get yourself a whole bunch of squishy boxes that are never bigger than 200x200 pixels and sometimes are smaller when there's not enough space.
We should be thinking about where to set heights on things. We should be thinking about how we can -- you could put a height of 10 viewport units, viewport height units, VH units, 10 VH units, and have yourself 10 little squares. Transfer the width across using the aspect ratio property and make some really beautiful designs.
Dave: I think that's really cool because you make a grid or whatever. The default thing, it all just collapses or you have to set a height. If you're like, "If I just want these to be little squares everywhere or a rectangle-based mongering grid," you can start kind of doing that very easily with minimal code.
Jen: Yeah. Yeah, minimal code--
Dave: Two lines.
Jen: --and an incredible amount of robustness. You could do a layout where there's a whole bunch of squares and, any time there's the content, like they're all teasers for something and like that post, the jazz poster that I made a long time ago where there were all these squares and each one was a different event. There was the name of the event, the date, and the list of the artists at the event. You never know how much content there is or not. In the original poster design, all of those boxes were squares. Because it was laid out in Designer Core Express or whatever, you know the graphic designer could fuss with it until it worked perfectly. But on the Web, you can't. On the Web, you've got make sure that, hey, somebody puts three artists in there instead of one or they put a really long title instead of a short title. I just want it to work. I don't want to have to have them submit a bug report and me submit a hotfix to the CSS. It should just work.
You could be like, hey, there are all these squares with all these events in it and they're cool. In fact, you don't even need the content. If alignment would ship for blocks, which is a whole other thing, then you wouldn't even need -- you could have the content be vertically centered inside the square or you could throw a Flexbox at it to get this to work, or Grid. The content wouldn't have to be at the top with the empty space at the bottom. You could make the content sit at the bottom of the box with the empty space at the top.
Chris: Oh, wow.
Jen: You could vertically center the content, right?
Chris: I didn't even think of that outside the context of Grid or Flexbox.
Jen: Once you have height and you have extra height, then you have all sorts of artistic creativity of what to do with that extra space.
Chris: Mm-hmm.
Jen: Then, oh, if there's extra content, the content is longer, then sure, the box should grow taller. That's cool. Oh, you know what? It's in Grid. It's inside Grid, so actually, the whole row grew taller. Awesome. No problem. When you combine these things, there's so much potential there.
Chris: Fantastic. What I meant by precedent is that if you want to do this now that there are a couple of tactics. Generally, they involve setting a padding-top on an element, which is somehow just completely bizarrely a percentage of padding-top is based on the width, not the height.
Jen: Yeah.
Chris: Which is just a thing that is on the Web. Then you make -- you set the height to zero, so the only height it based on the percentage of the width. Then you absolutely position, probably, a child within that space. That's really limited and doesn't work like this because then if content hangs out of the bottom of it, it just hangs out of the bottom of it, which gave rise to another way of doing this in which that you use a pseudo-element that's one pixel wide or whatever that pushes the element down by 16x9. It's like it only does pushing. But if the content were to push farther, it can still keep going. It's kind of like min aspect ratio or something, which is interesting, but nothing comes close to it being this easy and this robust.
Jen: Yeah. This is very intuitive and makes sense where that padding hack is kind of an artifact of actually a mistake that the CSS working group made. It was a deliberate decision, but it was, looking back, probably the wrong decision about what to do if you have a top of bottom padding that's a percent because it's like a percent of what, a percent of the height of the box? But the height of the box is dependent. It's like a circular pattern, so they decided, instead of depending on the height, they just calculated off the width. It's this weird thing that's actually a way to transfer a size across, but I don't think the CSS working group would do that again.
Oh, but I wanted to talk about, because you asked about the video and iframes.
Dave: Yeah. I guess, where do you see people using it?
Jen: Here's where I want to explain the difference between a replaced element and a non-replaced element because it matters a lot when it comes to sizing and aspect ratio is part of sizing. An image is a great example of a replaced element where, if you just have the HTML file and you have no other files and you read the HTML file, the image isn't actually in the HTML file. Here I'm setting aside the data. There's a way you can actually encode your HTML file into this massive data thing and stick it in there but pretend that you can't do that. Pretend that the HTML says, "Image source equals quote," and then there's a URL to a file. But if you read the HTML and you look at the headline or the paragraph, the headline and the paragraphs are actually there. They're in the HTML.
When the browser paints, it puts everything together, it builds the webpage, it takes the H1s and the paragraphs, and it puts them on the page. Those are called a non-replaced element. That's actually the paragraph on the page. It's actually the headline on the page. It was not replaced.
Images--there are a few others as well, I'll talk about in a minute--are replaced elements. The image element is like a little note that says, "Hey, browser. You've got to go get the thing and stick it here. Go get the image file and stick it here. Go get the video file for a video element and stick it here. Go get the audio file for an audio element and stick it here." Not only the audio file and the video file, but also the video controls, the audio controls.
We were talking about this before with form fields. Go get that drop-down select-y thing and stick it here. Go get that radio button set that you have inside yourself and stick it here. Those are all replaced elements.
The way that sizing is handled with replaced elements and non-replaced elements is different. I think it's one of these things that, intuitively, we kind of know that. The way that sizing and the stuff around widths and percent widths and how tall is something for an element, for an image, for an image element is different than, say, headline element.
Images, for instance, are an element, a replaced element that has an intrinsic aspect ratio. If I go into Photoshop, I make an image, I make a square image, and I put it into the webpage, and we put a percent on that image, we put 100% width on that image, that image's height always adjusts with the width. It maintains its own because the image knows, "I'm a square. Hi, I'm a square. I know I'm a square. Oh, you want me to be 400 pixels wide? Guess what. I'll also be 400 pixels tall. You would like me to be 1,000 pixels wide? Guess what. I'll also be 1,000 pixels tall." It has an intrinsic aspect ratio.
This new aspect ratio CSS property is basically taking a lot of the mechanisms inside the browser that were already written, the ideas, the patterns that were already made for intrinsic aspect ratios and it's giving front-end developers, authors a tool, the aspect ratio property, to explicitly define an aspect ratio and to give an aspect ratio to an element that doesn't have an intrinsic aspect ratio. Headlines don't have an intrinsic aspect ratio.
Chris: No. Right.
Jen: Paragraphs don't have an intrinsic aspect ratio. You know what else doesn't have an intrinsic aspect ratio most of the time? Iframes.
Chris: Because they're just 300 pixels tall, right? You have no--
Dave: 300x150.
Chris: Yeah.
Jen: Right. You can give it a width and a height in the attributes, in HTML, but you can't give it an aspect ratio.
Chris: Right.
Dave: Yeah.
Chris: Fascinating. It's not a replaced element? I guess not, really.
Jen: I don't know. This is where I would find myself a browser engineer who knows these.
Chris: It's a gray area.
Jen: Yeah, maybe it is.
Chris: Will aspect ratio work on an iframe pretty well?
Jen: Yes.
Chris: Okay. That's cool.
Jen: And that's one of the major use cases because--
Chris: YouTube.
Jen: YouTube, Vimeo, embedded videos from any third-party service. Most of us don't use the video element natively because we want to do adaptive bitrate streaming, which means we actually want to have 14,000 separate little video files that get swapped out depending on the data rate or the bandwidth of the user, blah-blah-blah, screen size, blah-blah-blah, complicated-complicated. Go look up adaptive bitrate streaming if you're curious.
But you use YouTube. You don't make one copy of your video, put it on your server next to your CSS file and point to that one video using the video element. YouTube uses the video element, but it's like inside of this whole complicated, fancy thing that swaps out all the stuff depending on the speed of the data and the size of the screen. That all gets wrapped up inside an iframe. It probably isn't a replaced element, actually - probably, technically. But it doesn't have an intrinsic aspect ratio, iframes.
Dave: Yeah.
Jen: This is a way to explicatively give an iframe an intrinsic aspect ratio, which means you can say all of this complicated stuff is to basically say, hey, if I put a YouTube video on my webpage and I say width of 100% right now, the width will shrink and morph with the containing block and it will be awesome, except the height will stay 360 pixels and the video will get cropped. Then it'll be sad.
What's the solution? The solution is, usually people don't make their YouTube videos squishy. They make them a fixed size or they go get Fit JS or some JavaScript library and throw a JavaScript solution at it.
One the aspect ratio ships, instead we can say, "Hey, aspect ratio 16x9 for this video, this iframe, which is my video element, please." Or perhaps, you could even put a data element into the iframe and then you could say -- your CSS wouldn't have to say 16x9. Your CSS could have a variable in there or something or could have a data attribute in there.
Dave: Yeah.
Chris: Hmm.
Jen: It could have maybe an ATTR if ATTR would ship, ATTR. You could say, get the width and the height attributes from the HTML and put those into--
Chris: Yeah, like it does exist but the ones that are typed that you can actually pass a pixel value in.
Jen: Yeah.
Chris: Yeah.
Jen: It'd be nice to describe the height and width attributes off of the iframe code so you could have one line of CSS that's just like, "Take the intrinsic. Make explicit the aspect ratio that would be calculated from the width and height aspect ratios," which, hey, that sounds remarkably like what we shipped for image loading last December.
Dave: Wow.
Jen: Why? Oh, because we figured this out. This hit me. I figured this out while we were creating the aspect ratio CSS property. I was like, "Why don't we just -- why isn't this used to solve that problem with the image loading?"
Chris: This is a fascinating connection, right? Weirdly, that shipped first, but this was you and Elika being like, why don't images work like this? You bringing it up and having them be like, "Oh, they could." [Laughter]
Dave: Done. Yeah.
Jen: I was like, "Hey, let's just throw this line of code into the UA style sheet." Aspect-ratio:attrwidth/attrheight for all image elements. I'm like, that would solve the image loading problem. She was like -- then we went and found Emilio, an engineer at Mozilla, and he was like, "Oh, I could do that before the CSS property ships. I'll just do that in the HTML code," and he did. Then Chrome did and then Safari did. Then we all shipped it.
Chris: It'll be your legacy, Jen, if something bigger isn't because that is huge. It reminds me of how big scroll anchoring is, like scroll anchoring that shipped, which is when you scroll down in a browser. The browser really tries to keep you there even if crap happens above it and doesn't push you down. This is similar to that. That helped stop a lot of jank. So does this. It stops a ton of jank. Anyway, Dave?
Dave: I have a zinger. I have aspect ratio 1/1 on my image, image aspect ratio 1/1, and oopsy-doopsy, I loaded a portrait or iPhone photo in there. What happens to my image? Does it explode the aspect ratio or does it kind of squinch down? Do we know yet? Maybe we don't know yet.
Jen: We do know. Let's see if I can remember.
Dave: If I lied--
Jen: You're basically asking the question, hey, the image has an intrinsic aspect ratio. Let's say the image is inherently a square but I tell the image to be 16x9. Which one wins? I think the aspect ratio wins and then you can put object fit on it, for instance.
Dave: Hmm. Okay.
Jen: If you have a whole bunch of different sized images and you want them all to be square or you want them to all be 16x9, but--
Chris: Isn't there another keyword, though. There's something. I think contain aspect ratio or something like that is another keyword related to all this that is the object-fit equivalent of how it -- sorry. I don't know much about it but I know there's something on my radar to look. It's in the spec. It's another. It's not aspect ratio. I think it's contain aspect ratio. Really weird.
Dave: I am very enthralled by this. I need to play with it.
Jen: Yes!
Dave: I have all these situations. I had this bookshelf on my website and it's a bunch of book covers but, low and behold, some authors decide they're not going to just do a normal size book. They're going to do a weirdo size book. I'm like, "Oh, shoot. What would I do there?" Right now, I'm kind of doing a draw square or width auto and the height. But wouldn’t it be cool if these were all just square boxes that the image just filled and that's exactly what you're promising and so that's wonderful. That's what I want.
Jen: Here's the answer.
Dave: Good.
Jen: The attributes in HTML will set an intrinsic size and auto, if things are set to auto, auto will go and look for the intrinsic size and the intrinsic aspect ratio. But if CSS comes along and says, "I want you to have this width. I want you to have this height. I want you to have this aspect ratio," CSS is going to always win.
Dave: Okay.
Jen: That's what we're used to, right?
Dave: That makes sense. I mean that's the authored specified -- yeah.
Jen: Yeah, CSS will win. Right now, if you have an image that's actually square and you tell it to be in CSS 400 pixels wide and 17,000 pixels tall, it will do what you told it to do. This is the same where the aspect ratio in CSS will override the intrinsic aspect ratio of the image itself or the calculated aspect ratio coming off of the attributes in HTML. Yeah.
Dave: Awesome. Well, cool.
Jen: Oh, and then it gets even more complicated with SVGs.
Chris: Oh, gosh! That's for another show, probably. We're a little over.
Dave: Right. It'll be the sequel.
Chris: There's another thing that I want to talk about, but we're not going to have time, which is, is this a good candidate for at supports. I hate to be the bearer of bad news but because the fallbacks require some HTML and a very different approach that--
Jen: No.
Chris: --if you have to program it both ways, it's like you might as well -- I don't know. It doesn't feel quite right.
Jen: Well, I think it depends. It depends on the use case. It depends on what you're using it for. If you're using it to make your teaser boxes be squares every time that there's enough space, like the content will still fit inside the square, then the fallback would be, "Okay, well, they're not squares. They're their own intrinsic size."
Chris: Yeah.
Jen: That might not be bad at all in terms of graphic design.
Chris: But if you rely on the aspect ratio to make the shape at all because maybe they're contentless squares or something, then you'd be screwed.
Jen: Well, for instance, if you have YouTube videos that are squishy and the only solution you have to having them maintain their aspect ratio is to use a CSS property that's only supported in half of your users' browsers, then the other half of your users are going to get really messed up YouTube videos. That's not a solution.
It depends. It depends on what the consequence is for the lack of support and if it's bad enough. But you could use at supports to try that out and then you could apply the padding hack the rest of the time or you could apply a JavaScript library that only loads if needed. You could have a thing in your JavaScript that says, "Hey, run this JavaScript if this CSS property is not support. If it is supported, then don't do it."
That brings up a question, though, of, like, is it worth the engineering effort if there's not 100% coverage because you've got to do all the work for the hard way and then you toss in the easy way. Why? You already did the hard part. Why bother with the easy part?
But it's going to ship in multiple browsers almost simultaneously, so we might actually see it ship pretty rapidly, so we'll have to see how it goes.
Dave: It'd be cool. Thank you, Jen, so much for coming on the show. It's always good to get a picture of where HTML, CSS, and all that are going, so thank you very much.
Chris: Mm-hmm.
Jen: Thanks for having me.
Dave: For those who aren't following and giving you money, how can they do that?
Jen: I'm @jensimmons on Twitter, jensimmons.com website. I have a Layout Land YouTube channel with a lot of videos where I go into lots of things like how to use object-fit or how to do progressively enhanced CSS fallbacks.
We should probably in the show notes, too, a link to a video that explains what we were sort of--
Chris: That'd be cool.
Jen: --zipping past with the image loading and how it changed last December.
Dave: Yeah. Awesome.
Jen: Go take my HTML course on LinkedIn Learning. I think it's actually free right now.
Dave: Yeah. Check it out. Yeah, it's on the one-month trial. That's what I'm seeing. I might….
Jen: I think they put together some kind of, "Hey, COVID. You're at home learning stuff."
Dave: Oh, nice.
Jen: "Here's a set of courses that you should take. We're going to make them all free for a little while," kind of plan.
Dave: Cool.
Jen: Plus, a lot of people have access through their work or through their school or through their local library and don't realize it. I think every New Yorker can just use the New York Public Library System to get to LinkedIn Learning for free.
Chris: Oh, nice.
Dave: Heck yeah.
Jen: Yeah.
Dave: Wonderful. Well, thanks again, Jen. Yeah, this is great. Yeah, we'll put a link to that video, the aspect ratio video or image thing because it really -- the way we embed images is back to the old way, which is now the new good way.
Jen: Yeah.
Dave: So, that's good.
Jen: Yeah, people have been very confused. They think that the image loading thing with width and height attributes in HTML is somehow the same as the CSS aspect ratio property. It's like, no, no, no, no. They're technically similar and there was a story about the history of how it came about that is connected, but they're actually very, very, very separate things. One has to do with image loading and the other one has to do with layout in CSS.
Dave: Yeah. Awesome.
Jen: Watch the video all the way through and I explain it.
Dave: Perfect. Thank you. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you have anything else you'd like to say?
Chris: Nope. ShopTalkShow.com.