 Hello, thank you. I have kitten pictures behind me because when you're debugging things sooner or later you need something nice to look at. They will be relevant later on. Thomas wants a dog picture instead, no? What? No, sorry I didn't listen. Kittens make you feel better. Yeah. This is something I got really stuck with and I just used PlaceKitten to put some kitten pictures in there to make you feel better about it. So we're probably going to run like 10 minutes up. We'll try to be quick. So scenario, you've written some code or actually someone else probably has. He does everything. Layout isn't what you want it to be. What do you do? What is this even about? Introduce the topic. What is debugging CSS? To me it seems fairly broad. You've got a visual problem basically. Something's not rendering quite how you'd expect it to render. Your development browser of choice is probably the one that you're looking at at the time. You might be further on in the dev process. But what's your first thing that you're actually going to get stuck into? Something's not quite right. So what do you do? Right click on it and it's back. That's a good start. Then you see a bunch of things and you change a bunch of things. So you're looking at what the browser thinks it's rendering and what's actually going on. The code looks wrong. Then it's easy enough to go fix it. If the code looks right and you think it's something else is wrong, what do you do now? I have something. I don't want to start because I'll just keep talking. Usually why right click inspect and then change something in the browser to see until it's fixed. Then I fix that in the actual code sometimes through copy and paste. Why that works for me very well is because I rarely use CSS in multiple places on the same page. I don't create massively deep inheritance stacks of CSS. Meaning my componentization of CSS re-use it, or however you want to call it, is rather minimal. Usually you can just fix that CSS and you're going to be fine. You're not breaking much else. That's how I do it. I'm rather careful with which CSS rules I reuse or inherit through my DOM tree in that sense. That makes it, I guess, a bit easier. Actually if you can close the JavaScript bit because we don't need that. Just get rid of that whole thing. Just scroll to the top so we don't see the kittens anymore. The kittens will always be there. Here's a scenario. Basically you want to constrain the width of this input field. Your first port of call is to try, what is the first port of call? Just restricting the parent. Actually the first one's got no constraints so you might put a max width on the thing. I'm using inline block to actually make sure it will have a width because normally form fields are inline. It's not rendering correctly. It's not at the width it's expected to be. What do you do now? This is when things get hard in CSS. Use this as an arbitrary example because it could be pretty much anything. My approach, I don't have an exact answer for this. CSS is rather complicated language. I don't think anybody can just look at something and go, obviously just without looking at the CSS and not looking at how the DOM has constructed itself. You can't easily diagnose what that issue is. Whenever I'm trying to figure out what the hell is going on in CSS, and I assume that this is pretty much how everybody does CSS, just trial and error. You open the panel, turn things on and off again. Change stuff out of this? Sometimes one of the things which happens is you'll change stuff and nothing happens. That's usually when you start to get a bit worried. If you're looking at sizes, you usually want to look at the bottom model panel when your inspector, also because it forms a nasty. Forms are nasty because forms are nasty. No, because your browser has its own user agents, style sheets, and that one for forms is quite extensive. Things like box sizing, for example, is different for forms, usually for legacy reasons. So if you want to check your normalizations, style sheets are check statements. The box sizing is reset locally for forms. And then your box model panel, obviously. Wasn't there a good talk on forms by somebody called Chris from two years ago? I've been writing forms for longer than anyone should, and you see that switch kind of developing. It's not fun. Another thing which I'll try to do is make sure I actually understand what's going on. So like if I open that panel and, you know, sure, maybe it looks visually correct, but if when you start inspecting things, you've got bits poking out of other bits, and like... It says it's awesome. Yeah, exactly. If you've got containers which are being exploded and all this kind of stuff, this is usually... It's very difficult to work in an environment where it's being rendered messy. So I usually try to understand what's going on, make sure it's sort of nice and clean before I go any further. Can I do a quick survey? Anybody using BEM? One, two, three. Come on, let me shy. You really put your hand up. You'll have happy Russian friends. It was good. It was created by Yandex, so I'm just a fan of that. Did they steal it from the Democrats in the US? No. Who's using any kind of componentization assistance that kind of tries to, through post-CSS or any kind of pre-compiler, componentize CSS? Like CSS modules maybe being the most popular one these days. One, two, three, four... Five, six... Okay, who doesn't use CSS? It's got a face level here. Okay, what does everybody else use? Just freestyling? That's one more for not using CSS. Do you want to join the panel? Because you might have unique answers on how to debug CSS. There might be violence if you join the panel. Because I've never used Bootstrap and I'm not quite sure I'll never will because I fear debugging CSS with Bootstrap. Okay, I can talk first-hand at debugging CSS with Bootstrap. What you do is you work out what's going wrong, you fix it, and then you realize that Bootstrap is actually doing something completely contrary to good sense. So you end up fixing the thing for Bootstrap and writing your own custom code on top of it. And then you wait until Bootstrap changed something and then your custom code doesn't work anymore and then you hate the world and you probably burn something. That's my first-hand experience. I slowly understand why the creator of Bootstrap doesn't do talks anymore. My experience with Bootstrap is that the whole thing is because we're going to pick and choose what to use. So what I usually do is I use Bootstrap's S and I just comment out all the components that I don't want. If I was able to hit the buttons, I just comment out the line that you pause the buttons there on my own, that's fine. It's all the same with good size, not really that much, but yeah. And secondly, you sort of have to, like, the part which Bootstrap does, you don't want to do anything to them. That means you don't want to override Bootstrap's styles. Instead you want to customize variables. I think that's sort of a good practice overall. If you've got some kind of, if you're using some system to help you and then you end up overriding large amounts of that system or even just once, that's sort of where broken windows. Anytime you're overriding stuff, that's bad news. I've had a Bootstrap project where there was more code undoing what Bootstrap was doing than Bootstrap was actually doing. Just do the variables. If you find yourself overriding, then you probably want to comment at line calls and then just spread it on the styles because it's not mind-fighting Bootstrap. The problem with a lot of CSS modules is namespacing or lack thereof because everything in CSS is global unless you're Sebastian using CSS modules. They say it's actually a bunch of components. Because generally speaking CSS is global. If you have a framework and it does something in a global namespace, you have problems. Bootstrap does things in a global namespace. So even if you just use one little bit of Bootstrap, you've tainted your entire browser. Can I pick you up on the web components? If you want to reuse a bit of CSS from one web component in other web components, is there a way to do that? No. Let's say you have a style on how a header looks like or a header font looks like in a web component and you want to reuse that in another web component to have a standard header style in different components. How would you do that in web components? I generally avoid that completely, that pattern of reusing across files. I just have a very particular way of writing CSS where I take all the HTML elements and write an equivalent selector and then write the properties so you never share across the whole namespace by selector now by element. Say you didn't want that, it would be like you're including a CSS library in multiple components. You would do it across multiple pages and have to do it as a page for it. You can use imports as well if you've got a file that you want to share stuff. But again, the same thing applies as before, it's better to use variables than to pull stuff in that way. I only know the way out to do it in CSS modules, which I like, which is the Composers keyword, where for those that have used CSS modules that you might be familiar with, for those that you aren't, you can in any CSS class definition say Composers and then you reference a class from a different file. And because it's all pre-compiled, it will assign both classes from that one file and from the one file you're currently in at the element in the end. So that still makes it super easy to debug because you can kind of see from which file it's applying the styles in the output because they have two classes now and that makes it really quite nice to work and pull in styles. So we have shared CSS module files that just have stuff that you want to use in other components. And you just put all of those variables. You could use it like variables, right? You just have a color font in a shade of blue and wherever I want that font color applied, you compose from that file into any other CSS module that you want. So what's the difference with CSS modules doing that and just applying multiple classes directly? Right. You can do that. You need to import the different files though. And I was just wondering how that works. Conceptually. I think the answer is that CSS modules, I believe, has the order that you compose them in is the order the styles are applied. And that's not true for normal CSS. So the order that styles are applied with CSS is totally dependent on the order that they appear in the CSS file. Well, I imported. Yeah. So this can lead to confusing non-deterministic things happening as well. Whatever you're using, you plug some other plugin in or you require things in a different way. Something can end up in a different part of the file and then suddenly everything's red and you don't know why. And that's one thing that CSS modules does solve. I have a question for people who don't seem to use any BEM or anything along those lines if anyone can answer. When things go pear shaped how do you actually work it out? I'm curious because I've been using known spacing for a very long time. Are you using specific space ringers? It's not BEM. There are lots of variations. If you listen to Jonathan Snook who's written SMAC's Harry Roberts with his basic known spacing Yandex, they're all basically doing the same thing and they all say that about each other. None of them will say bad things about each other other than basically, well this is my way that's more or less the same. I mean even pause for a moment and say something good about Bootstrap they actually use a decent naming structure within their system so it's pretty easy to work out what's going on if you try and override it or make it work properly. A good one I find is star, space open curly bracket outline colon, space 1BX, solid blue semi-colon, closed curly bracket as in apply everything on the page and this can be a good way of going that's what's going on. The reason why we use outline as opposed to border is because border adds an additional pixel if you're in the default box sizing mode which adding that additional pixel can completely change the layout so outline is a really good way of having a read-only way of analyzing where the edges of everything is without having to go in and manually inspect everything. Wasn't there also this 3D inspector in Firefly? Oh yeah, that makes me think. You can look at the DOM depth in 3D and it's got the Facebook button and it's like 20,000 items deep. The tower of Facebook. This is what we're going to talk about, pixel. What if you're going to design for different screen sizes? Ah pixels versus RAM versus everything else. The quick answer is a pixel is now a variable unit of measure. It used to be not but now it is so you can just use pixels and resizes anyway. There wasn't one that you ever tested. It doesn't matter what you're going to use, you just have to test it. Back to our scenario. We have something that we think we know should work. It doesn't and it's really number 2 that we're looking at because the code is more or less the same between these. The first one has nothing on it so it's going to take out the full width. The second one's got a max width of 90% within its block. It's not working. The third and fourth are, what do you do now? What are we supposed to be doing? Look at it on this screen because I think they want to put it into the grey box that you don't see on this screen. Okay, I got it. I'm going to ding somewhere along here. That would make more sense. I was wondering what was wrong with it when I was looking at it. Okay, but it seems that this screen doesn't stretch with the full width. It's not as plain as the full width. It's contrast, really. Can you change the colour of the background? Just invert the colours. I'll change it. Just to form that ground. Dark brown. Why don't you just make it sandy brown? Sandy brown. Sandy brown. That's the name and the colour. There we go. Accessibility lesson, everyone. Yes. One technique you could use to isolate where the problem is. It should be working so that you could delete all of your CSS and see if it stops working and then, first, you know... I've done that. Reordering CSS includes also really good. This is really useful when you're on third-party code as well. I've got a site I've inherited which is nasty. I basically ended up commenting pretty much everything just to work out what on earth the particular thing was. It's not good. CodePen is awesome, though. Especially if you're going to ask someone for help. There's JS Fiddle, but JavaScript is not that exciting. So we want CodePen instead. When you're asking for help, if you can isolate it even for yourself just to recreate the problem away from your other influences, if you had bootstrap in place and you saw the situation, how do you know it's bootstrap doing it? How do you know it's something else? How do you know it's using some library to do some form thing? And form, sooner or later, you're probably going to use a library. Dropping that same code into pure isolation like this is really, really helpful for that. In this situation, it still didn't help. Yeah. This is a size defined on HTML which probably won't be a result because usually it's not good to define your element styles in HTML. You can start like this. Size. That's a standard CSS property. Sorry, an HTML property. Yeah, it is quite simple. It's a good thing to have in forms and trust me because I know way too much about forms because it basically gives the user an indicator of how much information they should be filling out on the form. Look, so just double-check in here and it says here that size is actually visual size, not size in the sense of features. Well, it's... What's your site for that? Yeah, it is a visual. Max length is the one that actually gives you a proper restriction. The visual and the max length can be two very different things. If you've got an email field, you might have a max length of 100 characters. In practice, you probably only want to have size of about 30. So the two are very important still. Visual is very significant. Yeah, MDN. But in this case, I'm actually overriding anyway because this is basically a test to have something that's responsive. When my screen is wide enough, I just want the thing to take up whatever size it is. When it's not, I want to actually restrict it and this is where we're running into this problem. How do we proceed from here? We've isolated it, it's still not working. We haven't opened the DevTools and just turned everything on and off again. This is the only way to do it. Just scroll down the HTML path. Re-written in CodePen at this point? Yeah. Just scroll down. It's not so fast. If you've got a laptop, you can play along at home. If you look on CodePen, the IR is much cleaner. You're trying to find the solution? I didn't get too fast. I didn't get too fast. I just didn't get the problem. Just scroll down a little bit. That's very hard. There we go. The fields, as far as anyone's concerned are one and the same, basically. Have you guys ever gone this far where you actually had something great like this? Has anyone actually had a bug where they've isolated and it's still failing? What do you mean? At this point, you know what it's meant to be doing. You've probably checked on MDN which is a really good way of having a look. It's still not actually behaving correctly. You've got an isolation and it's still failing. So what do you do now? As in it is definitely you. It's not somebody else's fault. Well, this is a good question though because you've probably stuffed up somewhere. At this point, what I'd usually do is I'd have it in CodePen. I'd check every other browser and see if they're actually consistent. Because sometimes you're going to come across a browser bug. And if it's a browser bug, it's a relief because at least it's not me. It's not a relief because then I need to actually possibly submit a bug or something like that. Sometimes it's just like a missing prefix or something. Yeah. I'm pretty sure I went through that with several lines of disreleasing. I was wondering if there's any other problem ever in CSS other than that one where like, oh, this is supposed to work but it somehow doesn't. This one's actually been submitted as a browser bug. It is a browser bug. If we scroll down now to the kittens. Kittens. We're actually seeing exactly the same markup. There are any difference instead of a form field we're looking at an image. And example two is exactly the same code where it's doing the right thing. You tricked us. Yeah. Okay. So your next step from here do you pick up your laptop and throw it out the window? Do you gaze into the eyes of the kitten until everything's okay? What do you do? If it's something like that, usually there's something like you just change display mode or put it, set it to position relative or anything like that. Add a Z-index. These things, seriously, like sometimes adding that can convince the browser to do the right thing. Translate. Z. Seriously. That was a fix. Yeah, there's so many fixes with IE. We're not talking about that. IE's dead, IE6 is gone. My favorite CSS debugging is animations and transitions. When they start flickering or not doing what you wanted. That's a whole different story. Oh no, not performance. It's just genuinely good. My favorite is when in Safari the font starts becoming bolder and thinner. When it transitions between graphics card memory and CPU. It's anti-aliasing. It's just flickering. Whereas you don't have the correct transform origin and something will half animate three dimensionally into the background. One good one the other day where the thing just became 100% transparent. I'd set a blend mode on it. But instead of blending it just disappeared until the transition was over. Once the transition was over then it was there. I think in anything, trying to determine the state of something when it's sitting there is one thing. It's a whole lot more difficult. It's also the browser bugs are much more common there and inconsistencies in how the rendering of transitions and animations works is super different in the browsers. In this situation we've got our browser bug. We've confirmed that the behavior is inconsistent. Our next step is to jump on to the various browser bug sites and pretty much every browser's got their own these days. We've got one which is good. If you find it then that's great if not you submit the bug as I did with this one. What do you do now? Because that's great that your thing might actually get fixed or not. What's your solution? I'll do my own patch on the normalize sheet. But you can't fix the browser out in a few users. I mean you can do like a hacking second thing like the index and stuff and I think she's still trying to do like patch stuff. But your behavior is basically... Yes this is usually the half window on the fields. Yeah, but you don't want to. Usually there's another solution that works. That's your answer. You basically have to completely rethink. That's all the other examples are there for. Completely rethink how you're actually trying to do that. Well that's how you debug CSS. You have any other questions? The cat's not cute enough. That's showing that behavior with nothing else on it. The next one is showing the behavior. Six is the one that's correct. Five is correct also. But if you scroll up... The second one is wrong. Yeah, number two is wrong. Well the second one you have to put a display block on the key and fix it. Well inline... But you shouldn't have to. You should be able to just set an inline block and it works. Because if you have an image with the same properties it works. It's a default disclaimer. Inline block is the child itself that's inline block. The parent is inline, the paragraph is inline block. Oh yeah, you're right. But it should work. It works on the image, it works on any other element except for a form field. What's actually happened with this one and this is the really frustrating thing about what happens when you submit a browser bug is there's an old South Park episode The Simpsons did it. Basically everything the South Park creators came up with they found it was a Simpsons episode that already covered what they wanted to do. And the browser world works exactly the same way except it's Chrome did it. If Chrome has the behaviour you'll get it replicated in every other browser. If Chrome doesn't have the behaviour it's not going to happen. This is not going to get fixed as far as... My bugs are rejected in every single browser. Because Chrome just didn't want to fix it because they said oh it's always been like that so why should we bother? There's one thing we have to do because you see if you have been consistent if right between share and yes you find that they are not consistent then you can get the Simpsons. This is the classic inconsistency because number two and number six are in direct contrast with each other the only difference is the type of element. There are no CSS properties different between them their behaviour should be absolutely identical but they're just not. You have to use the Simpsons. Everything is exactly the same. Did your Edge bug also go close? Everything. Even Edge exactly the same comment where Chrome haven't done it. I know Edge there are statistics on how much stuff is used in a certain way so they could look at data on how often people actually implement it. It's an Edge case because most forms are terrible. I was going to say I was going to say most forms are terrible. We watched Chris's talk from 114 CSS has come about forms. That's true. Very good talk. You'll find me crying in a bar somewhere and talk to you about forms. Thank you very much.