 Okay, can everyone hear me all right? Yes, no? Yeah, yes. Cool. All right, I'm going to get started. This is Layout Design Patterns, and my name's John Ferris. You can find me on Twitter at pixel underscore whip. I work for At Design Group, Design Strategy and Development Shop in Denver, Colorado. And we do a lot of work with organizations doing good work around the world. And a lot of these organizations are fairly large, they have a lot of content, a lot of them are sharing reports and data, they have different agencies around the world. And so the sites that we typically work on are fairly complex, rich in content, like reports with related graphs, we do a lot of mapping, a lot of stuff like that, and our sites, all the sites we work on are responsive. So with a lot of content and doing responsive design, we end up with usually some pretty complex layout challenges, a lot of problems to solve. So I spent a lot of my day trying to figure out how to get content in the right place on the page so it's still readable and usable. So it's a lot of thinking time about how things are going to rearrange and whatnot. And as I'm solving these different problems day to day, I find myself attacking the same problem over and over. Just to give you an example, this is a site we worked on for Colorado Public Radio. I guess in its simplest form, there's what you could call a side bar along the right hand side and then main content. But really when you look at this, it's just two columns of content. And again, when we look at some smaller pieces, we have this kind of marquee at the top that has navigation that changes the story, that's two columns. We have the latest news and a featured news story, two columns again. And these problems are typically recursive, so we have within that navigation, there's two columns. On the right hand rail we have, it's called an on-air block, it shows like whatever is currently playing on one of their three different radio stations. And we have whoever the host is at the time, what's on their plane or what showed their hosting, again, two columns. So it's the same problem over and over, which is in itself a design pattern. And all a design pattern is, is common solutions to reoccurring problems within a given context. The idea itself didn't come from computer science or graphic design, it actually came from architecture. An architect and professor at Berkeley University named Christopher Alexander. In the 70s came up with this theory that a lot of the great places in the world, places that you feel alive in, that you want to live in, you want to be in, at those places weren't necessarily designed by architects or probably designed by a farmer who built his barn or built his house, not a classically trained architect, he just built it out of these reusable patterns, kind of like rules of thumb. And so in 1979 he published this book, The Timeless Way of Building, that described this theory and if you ever get your hands on one of these books, I think they're pretty fascinating reads. The Timeless Way of Building describes this theory itself and pattern language is kind of a complementary to that in which it describes individual patterns for solving these problems. It starts on a grand scale, this is how we deal with problems on a region, what's the appropriate size for a city, how far should it be from another city, how many towns should be in between, all the way down recursively down to where do you put the lights in your kitchen, what do you hang on your walls. I find a lot of similarities when I'm doing layout design, that recursive nature of things. In 1994, this is probably where most people have heard about design patterns, this theory was applied to computer science by four developers in Silicon Valley, all about how to design software using object oriented programming. Again, it was applied to user interfaces, there's a pretty cool site, unfortunately it's pretty outdated now at uipatterns.com I believe, I don't think it's .org, but it describes these problems as they relate to user interfaces. You know, like if you have a bread crumb, what problem are you solving with the bread crumb? It doesn't matter what it looks like or anything, it's about the purpose of it and the problem that it's solving. Luke Rablowski wrote a blog post about multi-device layout patterns, which is layout as it applies to your tablet, your phone, how it breaks down into different screen sizes. Brad Frost wrote about it, responsive navigation patterns, these are patterns specific to how do you deal with complex navigations on a small screen and what the different options are. If you haven't read either of those, definitely go check them out. But today we're going to talk about just layout in general and some of the more fundamental concepts I think of CSS and how we can solve these problems. So what is a layout? A layout provides a structure to your screen. Essentially what it is is a bunch of containers that you put things in. I imagine a lot of you were probably in John Albin's session before this, he's talking about components, layouts of where you put your components. Again, layouts are recursive, you have layouts within layouts. Here we have the overall page structure of a layout. Inside that you probably have a node, if your node is complex it has a layout, it might have its own sidebar, header, image off to the side, whatever. But it's all defined by the markup of the page. So the order of your markup is super important. What elements are next to each other is important. We kind of manipulate it with CSS. These out of all the CSS properties, these are the main ones that deal with layout itself. So when you're creating your layouts in CSS, I find it easy to organize things if I keep these properties kind of bundled together and not intermixed with your typography, your font colors, your background colors, or border colors. Keep border width in here because that does affect layout. But your border style and border color don't. So let's look at some actual patterns. Let's start off super simple. And one that I call constrained elements. And again, these patterns, I would love to actually, if anyone's interested in this stuff, sit and talk and collaborate on some of this stuff and actually document it. But everything you'll see here is just stuff that I've found in my day-to-day working, stuff that I'm doing over and over again, so I'd love to chat about it afterwards. But so constrained elements, give an element a defined width to prevent it from expanding too wide. And that's super simple, it's one property, it's max width or width or whatever. So here we have just super long bit of text, the measure is a little bit too long for it to be easily readable. Simple solution, just add like a max width to it so it doesn't get too wide. So that's pretty straightforward. Here's another example of the same problem. This is a site that Ken Woodworth, our VP of design, just did for CreateUpState, which was a design conference up in Syracuse, New York. And using the same constrained pattern, we typically use a class, like the L with a dash dash is a naming convention we use, kind of came from SMACS. But this class is applied to each of these like horizontal regions to keep all that content from spilling out and bleeding all the way to the edge of the page. So if we wrap it and, you know, some outer div or whatever, we can apply like background or color to let it spill out, but our content is constrained in the middle. So this is something we use all over the place actually. This leads us to our next pattern, which is rows of relevant content. Divide the screen into rows of relevant content, such that the hierarchy and content relationships are preserved across different screen sizes. Back to that same example, we've divided the page up into horizontal rows so that when you do shrink it down onto a mobile site, that all your content in that row that's relevant to each other, you know, the time is relevant to the location, and all that kind of maintains its relationship down into like more of a linear format on a mobile phone. And this same concept on, this is, again, the Colorado Public Radio site. One thing, you know, if you look on the right hand side, it looks like there's just one long sidebar down the side and then one long piece of main content. What we realized is that if that were one sidebar, and we just did the simple wrap that around at the bottom, all of a sudden on the mobile phone, the ad was at the bottom of the page and sponsors don't want to buy ads that are at the bottom of the page. So what we ended up doing is splitting that up into horizontal rows so that, you know, the ad could wrap right underneath the main feature damage. We get the on-air block up there, which is important to a lot of people. That kind of hierarchy of the page, the important stuff is at the top, is maintained. This next one, layout modifiers has a lot to do with naming conventions. So following a naming convention for classes intended to modify layout. So what does that mean? Here's a simple layout. It's one container, and we have just three divs in it, primary, secondary, and tertiary. And depending on what class we apply to that outer wrapper, it's going to adjust the whole layout. So you see we can do three columns, change the class, and we can do the sidebars after. We can flip it over, put the sidebars before, all just with changing this one class or do a tryptic with the main content in the middle and each of the tertiary and secondary content to either side. So that L dash, dash naming convention, that's something we use a lot on very generic layouts that we can reuse throughout the site. I find generic layout doesn't always apply to every context. So sometimes we have an article note or an event or project or whatever that has kind of its own regions in it. So apply the same general solution using a slightly different naming convention in which we use whatever the component is. So in this case, it's article component with the teaser and we style each of the regions underneath that. And you probably notice that I'm using the direct child selector. That's very intentional. Like I said, layouts are recursive. If you have something like, say, a sidebar and you're using that throughout your page, you probably have a lot of different sidebars. You don't want styles from a macro layout, a large layout bleeding down into those micro layouts. So this specificity is very intentional in that it actually keeps styles from bleeding into other styles. So another one that I use quite often called the gutter pull. And that's position an element by pulling it into the gutter established by its parent container. So here's an example of another article. Just have a bunch of paragraphs with the block quote in it. And if we want to pull that block quote off to the side to emphasize it or whatever, first give it a defined width so it's not just fill in the whole area, float it to the left, and then add some negative left margin to pull it off into the side. You'll notice that when you float something, all that text kind of collapses out of it, takes it out of the flow, and just pulls it along with it. So we can use that to our advantage on, say, like an article layout or something. This is like a teaser for a book. And this is what you'd see on your mobile device where you don't want the text squishing around the image of the book or whatever. So if we want to apply that same principle to this, first we'll add some padding to the outer container itself to kind of create this gutter. Then we'll float the image off to the left to give it a width, and then pull that off into the side. And then you've created this gutter. All of the content is now going to left a line, even if it, because we're pulling it into that gutter and we've set padding on the container, that now any of the elements say our summary gets super long, that's not going to wrap underneath our cover. It's just going to continue down and align nicely. So that gets used a lot. You can do, say, if like your markup, if you wanted the title to come before the image and the image. So the image was in the middle, but on a larger screen like this, you still want it to the side. You could actually, after you pull that out, in fact, you don't even need to pull it out, but you could absolutely position it. You just need to make sure that you set like a min height on your content based on how big your image is going to be. So that's gutter pull. Another way we can exploit the margins. I guess one thing I did want to point out is that in advantage of this, you can't do it completely fluid. But one advantage to doing it this way is that you can have a fixed width gutter and the rest can be fluid. So your image is on the side. It's not going to get awkwardly large or small, but you can still expand and contract that. So margin overflow. Allow an element to overflow its container by applying negative margins to both the left and right sides. So this is just an example block that you might have on your site. We have a block title, the big red thing. If we apply negative margins to the outside of that, that'll actually grow the width of the element. So we can kind of exploit that and create this kind of wrapping around effect that you see here. Another place that this is useful, say we have three columns of text. I hope you guys can see those guys on the outer sides. So we have these three elements. All of them have a width. All of them have padding. They're all floated, just set to like 33% of the width to create three columns. If we add the negative margins to each side, that'll pull them out and kind of compensate for that outer padding. In advantage of this, you don't have to, there's a little bit more cross-browser support because you don't have to do like nth child or anything like that, or like first child, last child. Last child is pretty well supported, but last child is not supported, and I ate. So it kind of compensates for that. Another interesting one is intrinsic ratios. So this one's kind of hard to explain. But when the aspect ratio of an element is known, the target size is not. Use padding and absolute positioning to preserve the aspect ratio of an element. This is better explained with an example. So we have a YouTube video here. YouTube videos when you embed them, typically iframes. When a browser interprets an iframe, it doesn't necessarily know the aspect ratio of it. Whereas if you add an image to a browser, the browser knows based on the file what the height and width is, and it can figure out how to properly scale things if you do like max width or whatever. Not so much with an iframe. So what happens if the column that our video is in gets shrunk down, our video luckily doesn't squeeze or scale awkwardly, but it does crop off the edges. So we can fix that by exploiting the fact that if you set top or bottom padding as a percentage, it's actually a percentage of the width of the element, not the height. So knowing that most YouTube videos are, I think the ratio is somewhere around like 65.25% height to width. We can add that 65.25% to the top of the container, and then absolutely position the video itself and set the height to 100% height and 100% width, which collapses the actual height of the element because it's absolutely positioned. There's nothing there to create any content area, but our padding is still there. So now we can adjust that to fit wherever. So grid systems are kind of a large pattern in themselves. Essentially, we divide the screen into a series of vertical columns to facilitate the organization and alignment of components. Just to give an example, this is the Indianapolis Museum of Modern Arts, a 12-column grid. You can see how things are aligning to it. I'm not going to get into just why grids are awesome in themselves. I think there's plenty of that out there. If you want to read about it, Ordering Disorder by Coy Van and Practical Guide to Designing for the Web by Mark Bolton are both great. Definitely check those out. What I am more interested in are those underlying patterns to actually implementing grids. So there's a basic one, the gutter grid. For each grid unit and the grid system include a gutter to help space content. I'm sure you all are very familiar with this, both this site and this pattern. We have a grid with a bunch of columns and gutters in between. It just helps us space the content so our text doesn't run into each other. One thing that we've been doing more often lately, and I don't see a whole lot of, is the gutterless grid. So exclude the gutters from the grid unit, instead use empty columns as gutters. We've been using this on most of our projects lately. It typically requires more columns, like a lot of grids are 12 or 16 columns. Our gutterless grids are, we started with 24, we're actually using 23 column grids and if anyone wants to know why I can explain that. But essentially more columns, smaller space and that helps kind of with the sizing of gutters. As a front end developer, I find those much easier to work with than having to deal with those, like we saw earlier, the intricacies of outer paddings. I don't know what our designers think about it. Ken can answer that. So symmetric grid, construct a grid from equal width grid units. In same example, equal grid units, we have 24 columns here, they're all the same width. Again this other example, this is how most grids are. Asymmetric grid, so construct a grid from varied width grid units designed specifically for the content. This one, I think to implement a whole grid system has been challenging in the past but now with SAS and grid frameworks, this is way more plausible to actually implement. To give an example of this, this is from Mark Bolton's unfortunately not forthcoming book, I think it's a book you've been working on for a while and just announced that he's not actually going to finish it, which is a bit sad but understandable. So you see here that we don't have equal columns, there's actually, it's like a four column grid on top of a, I think five or three column grid, not sure. But anyways, the idea here is that the grid itself is designed specifically for the content. The equal column grid, the 12 columns and the 16 column grid, I think those were born more out of necessity and ease of implementation than anything. I think an ideal is actually designing your grid around the content. Do you have an ad on your site that needs to be 310 pixels or whatever ads have to be? So design your grid around that element and everything else is a ratio of that fixed point. So that's something we actually haven't implemented anything in that yet, but I definitely want to and I think hopefully have lit a fire under the designers to actually go out and explore some of these other grids. So another pattern with grid systems is the class-based grid system. So align elements to the grid by applying a system of predefined classes to markup. You probably recognize this from 960GS or Bootstrap or Foundation. The idea here is that your grid system is kind of contained in all these predefined classes that you apply to your markup to get the desired results. So this example from Foundation we have, I think it's, I can't read, like large-10 columns, large-8 columns, and so on and so forth. This is good for quick prototyping. It's very handy for that because you kind of have this grid structure that you can already work with and you just start slapping classes everywhere. Slapping classes everywhere implies that you actually have good solid control over the markup and I'm sure a lot of us in here know that's not always the case with Drupal. So it can be tricky in some cases to implement with Drupal consistently. There used to be issues with, I guess, the semanticness in these classes in that you would have classes like, I think Bootstrap used to use span, so like span-8 or span-4 that kind of applied to the desktop version of the site. And then when you shrunk that down, you know, what does span-8 mean on a mobile device? Do you still have 12 columns? Is it an 8-column grid? Like, what does that mean now? So there, I think both Bootstrap and Foundation have implemented this idea of, like, different systems of classes for the different grids so that, you know, if you have small, you get these classes prefixed with small, like, this applies to whatever your mobile breakpoint is. Again, this stuff's good for prototyping. The alternative is a semantic grid system, so align elements to the grid by applying layout properties to selectors using a grid framework. So the difference here is, here we're applying the properties directly to whatever selector we want before we're taking these predefined classes and applying them to whatever markup we had. This is, I find this much more flexible. You only get the styles that you actually need because you're applying them where you need them, so it's more efficient in that respect. And it also opens up, like, the underlying math to the grid. So say if we're adding this mix-in to something like, okay, span eight columns, starting at the first column, that's going to set, like, the appropriate width and margin on things. But a lot of these frameworks provide that underlying math so you can apply those widths, like, you know, four columns of a 12-column grid is 33%. You could apply that to, you know, text indenting or padding or margin, whatever we want. It doesn't have to be just, like, margin and width. So these are just examples. This is, all three of these are different frameworks. There's Singularity, which is co-maintained by Sam Richards, and I'm sure a lot of you know from Pierce, Nugget, Susie is another alternative, and Zengrids, which is John Albin's project. I'm not going to get into, like, which one's better or whatever. I think they're all great. John wants to know what I think this week, we can talk later. But essentially, all these, it's just different syntax. They do the same thing, and each has its own features. So one of those features is, like, a float layout. So this is kind of what we already looked at before, where you just, you're floating, floating elements like one after another. So create a column, or create columns by floating a series of elements with predefined widths. So just an example of that, again, we have three elements. Give them each a width of 33%. Float them left, and then you have your columns, and you can add padding within those. That works in a lot of cases. It works really well. Use it all the time. That is what Susie used to be built on, Singularity used to be built on it, and then added the option for the next pattern, which is isolation. So it's very similar, but given a series of floated elements, give each a negative trailing margin in order to reset the orientation of the following element. So again, this is another one that's hard to explain in words, better with an example. So this is what we had before. We have each of these elements, 33% wide, all floated. If we add left margin to, say, the secondary, it's going to push everything to the right. Everything gets over that fact by adding negative margin to each element, so that it pulls the following element back to, I guess you could call it the origin. So now we have three elements, they're all four columns, four columns wide, stacked on top of each other, but now they have a consistent kind of base starting point. So if we add left margin to any of them, it's going to push them over. So now we've isolated that primary element from the rest of them so that it can freely move back and forth without affecting the position of others. This is what allows you to do a lot of column rearranging and whatnot. So we can do quite a few different things. Some of these grid systems offer the ability to define the direction in which these are floated, which is good for just like right-to-left language implementations, but it's also good for just kind of giving you a little bit extra power on manipulating the markup or the CSS. So here what we're doing is we have, say, the primary element is eight columns wide, the secondary element is, I don't know, four, but the secondary element is floated to the right and the primary element is floated to the left. So the tertiary element can just clear the left column, and therefore it's actually, it's just clearing the primary element, but it's going to wrap around the secondary. So it allows the secondary to actually kind of run past the tertiary element. And that actually comes in handy in a lot of places. It's how we were able to do, on that CPR site, like get that on-air block to kind of wrap around some of the news stuff. So that kind of sums up some of the basic design patterns. I've got more, but wanted to get into some actual Drupal-specific stuff, and how do you actually, like, where do you apply this layout stuff to Drupal? I think there's kind of two main patterns with Drupal. One is simply template files. These will probably be the main template files that you're actually dealing with layout in terms of, like, actual core Drupal. Views could probably be included in here, but views is, like, in itself, you know, one view is, like, six different templates, so it's kind of a crapshoot as to where you would actually mess with layout and view. So yeah, the page template, in the page template, you'd probably be applying layout to your actual regions. So your regions have a bunch of blocks in them. So like some of these classes that we were looking at earlier, we'd apply those to regions themselves. Nodes, like, core nodes don't have the concept of regions, so you'll just be kind of creating regions in a template just by defining markup and manually sticking in whatever field you want in there. Main user profile is essentially the same thing as a node. So one thing to help manage this, I don't know if anyone here does, just out of curiosity, how many people, like, edit a lot of templates when they're theme in a Drupal site? Not too many. What do you guys do instead? Display suite? Panels? Cool. Okay. We actually, we used to use a lot of display suite, but we've gone back to doing node templates, and I think the secret sauce in that is theme hook suggestions, which again, I don't want to get too deep into this, but I just want to point it out. If you don't know what theme hook suggestions are, find them, figure them out, and use them. They're great. Essentially, it allows you to add, create whatever reusable template you want. So a lot of people get away from editing node templates because it's like, ah, doing the same thing to every template, and you just redo everything, but theme hook suggestions will allow you to say, I want nodes from this content type and this content type and ones on this page to use this layout. So a lot of you have used panels, like I mentioned, display suite. I think the other alternative to this kind of basic template approach is using C-Tools layouts. I'm a big fan of panels just because of the layout model. I think the big difference here, like so comparing a panel's layout to creating layouts in a page template, I'm sorry, so in a page template you have a bunch of regions. Those regions are defined by your theme. So you have one theme and you have however many layouts, that's not going to change from page to page. You can just not put some regions in there, but it gets kind of weird to maintain when you have just a ton of regions named whatever and you're kind of using them in different places and different layouts. What I like about C-Tools layouts is you actually define what regions you want per template. So you have a layout and say I have like a sidebar layout, say okay in this template I have sidebar region and I have a content region and then you can put whatever in that. These layouts can be used, so they can be used in panels and panels is great because you can put whatever the hell you want in a panel. It doesn't have to be a block, it could be a view, it could be a node, it could be individual fields. Display Suite, a little less flexible, I mean you could put anything that's an entity but essentially you're just dealing with fields and you can get blocks in there by making a block a field or making a view a field, which to me started feeling a little dirty. Omega 4x, personally I haven't used it but from what I understand it uses C-Tools layouts. I'm sure there's people in here that use it and can validate that claim. So actually creating your own layouts, super easy. For basic files needed you have your include file which defines your regions and just points to other files. You have your thumbnail, your PNG with the layout looks out like the CSS that it's applied to it and the template. So we'll look at those real quick. Sidebar after, again like I was just saying this has two regions, content and sidebar. I get a little careless with my naming there so main and content are the same thing. So this defines the title like the user friendly name of your layout, category that it's in and the interface, the icon is the thumbnail. The theme is actually the theme hook so whatever this is is going to be the name of the prefix of your template file. So in this case sidebar underscore after our template file is going to be sidebar-after.tpl.php. What CSS it uses you can actually use different CSS for admin screens which is handy. And then the actual regions. So again whatever regions you need in your template you can define them and they don't have to be the same as anything else. So here's just the thumbnail, pretty straightforward. Apologize for the crappy syntax highlighting for some reason, highlight.js thinks that these PHP tags within HTML are HTML comments. But I'm sure you guys all know what a template looks like and it doesn't exactly look like that. And then you have your CSS and this is super basic. I mean usually the CSS is a little bit more complicated than that but for illustration purposes. So I like the fact that you can use these templates in different places. It provides a consistent interface. It's consistent from a front end perspective. You can reuse these layouts across different sites. It's pretty good. So I guess in closing just like to say that design patterns can be applied to multiple contexts like we just saw. The idea with the design pattern is that it's super general and it can apply to different things. Design patterns are not actually designed. Design patterns are observed. So you don't go out there and figure out like I'm going to create a pattern. As you're working and you find yourself doing the same thing over and over, really I'm just floating columns. The width is changing, the spacing is changing, but it's the same thing and that can kind of help you create like if you're using SAS it can help you kind of create your mix-ins and find out how to like actually rearrange your code and what not. But dad, I encourage you to just as you're working, you notice these things, write them down, keep a notebook, document them somewhere. Like I said, I'm interested in collaborating with anyone that's interested in writing these down and getting like just some community feedback and actually testing to see if this is a good pattern, does it really apply. So that's it. If you don't mind, go to the site and go in the survey. This is the first time I've given this talk so I'd like to know if it's interesting or useful to any of you. That's it. Any questions? There were a number of places where you showed something and you might have like the HTML or something, but you didn't have the CSS shown on the slide. Yes. Is there a way to get a hold of the CSS that you used in each of the examples? There actually is no CSS, it's all a lie. Now actually, these slides are all up on GitHub and if you go to the same URL, there's a link to it and you can see it in there. I apologize for it not being very clean and organized. You mentioned with the gutterless grid, you're using a 23 column grid? You kind of, oh yeah. So you want to know about the 23 column grid? Yeah. So since you're using gutters or sorry, your columns as a gutters, if you have a 23 column grid, so two columns or like two 11 unit columns, you'd have one left over for the gutter in the middle, which is 23, so you'd have, you know, three columns would be seven units each, four columns, five units. So it actually worked out nice, but when our designer said it, it's a 23 column grid, I'm like, what the fuck are you thinking? It doesn't seem to be visible. It never worked. But it works. At the end, you gave the example of the sidebar after.inc and the .tpl files, it wasn't clear, how do you get to use actually that, so you write that inc file, what's the next step? Okay, well it kind of depends on where you're using it. You can either define your layouts in the theme or in a module, syntax is pretty much the same, but if you're defining them in your theme, you just create a layouts folder, and each layout will have its own folder, so you'd have a folder called sidebar after, and then in your .info file in the theme, I don't know what the syntax is off hand, but I think it's like plugins, layout, something, just like you were adding a CSS file or a JavaScript file, very similar. I find that the easiest way to do it. In your slides, you talked about class naming conventions based on the specifics of the layout versus class names specific to the content and view modes, and I think both require different ways of implementing them, so I guess which one do you have the most traction with, and kind of prefer to use, or is it kind of like a hybrid of both? It's pretty much a hybrid, like anytime I'm doing layout on like a node or a content type, I'll use that like article dash dash whatever, and if it's say the node, like if that layout applies to multiple content types, I'll come up with like a generic name other than article, or you can't get much more generic than article, but, and then for the L dash, those get used throughout the site, more on the page level and like the larger level stuff, but I use it for sidebars and whatnot. So I guess more specifically, if you want to use the same or similar layouts across multiple content types, do you just chain selectors together or do you try to force the classes you want that applied to that layout? I couldn't make that decision at the time, like we don't have a good solid rule for it, but I typically err on the side of like a component, like thinking that yes technically this could be used on another part of the site, but I'd also like this particular component to be completely independent of everything else, so I'm fine with a little duplication there. Okay, thank you. Yeah, you said responsive video, I think you said you were making the top and the bottom padding a percentage of the width, is that right? Yeah, so it's just you do one or the other, it doesn't matter which one, but so you would say top padding is like whatever the aspect ratio of whatever you're trying to make the video is? Yes, so of like your iframe. So for an example, like if it's a like 16 by 9 or something like that, like what would your top padding be? I can't read that up there, but it would be that point. Yeah, 56.25. So you just divide the height by the width. Okay, great, thanks. You're talking about the isolation method, is there somewhere I could read more about that? I'm not sure I'm fully comprehending how to implement that. Yes, that's, have you ever used in the theme? Okay, that was actually a credit John Albin with that, I can't see what I'm typing, so it's probably not something you want to type in on a live demo. So responsive designs, dirty little secret, I think has a good explanation of how that works. Well, thank you all very much.