Discover Web Inspector improvements

♪ Bass music playing ♪ ♪ Patrick Angle: Hi! I’m Patrick, an engineer on the WebKit Developer Experience team, and it is my pleasure to show you some of the many exciting features and improvements that are new in Web Inspector this year. Web Inspector is part of Safari on macOS and gives web developers and designers access to a rich set of tools to inspect their web pages and web applications. It allows you to inspect all the resources and activity on a web page, and works seamlessly across macOS, iOS, iPadOS, and tvOS. This year, I am thrilled to show you new features in Web Inspector starting with a new overlay for visualizing your CSS Grids, enhancements to breakpoints, and the ability to author and edit audits right in Web Inspector. Before I talk about these new features, if you haven’t used Web Inspector before, you’ll have to enable it. In the Advanced tab of Safari’s Preferences, enable “Show Develop menu in menu bar”. Web Inspector can then be opened using the Show Web Inspector item in the Develop menu. Now that Web Inspector is enabled, let’s look at our first new tool this year: grid overlays. Web page layout these days can be quite complicated. CSS Grid is a two-dimensional layout system that makes it easy for designers to lay out content in a way that is both incredibly powerful as well as instantly familiar to anyone who has ever worked in printed design. A structure of rows and columns is defined where elements are then placed or distributed in the grid to achieve a flexible yet predictable layout. Grid is a highly capable way to lay out your web page, but it can bring a host of new questions and confusion as your layouts become more complex. Like, Why is my column this size? Or, Why is this blue box down here? Previously in Web Inspector, the primary source of answers to these pressing questions was the Style sidebar in the Elements tab, which this year has moved to its own independent sidebar, allowing you to view matching CSS rules alongside other panels like Computed styles. If you look at a grid’s authored style, you can glean some information about its layout. But the grid’s authored style only gets you part of the way there. Wouldn’t it be great if there was a more visual way to digest this information with Web Inspector? Well, now there is! If you look at the elements in the DOM tree, you’ll see a new clickable grid badge next to each of the elements that are a CSS Grid. Here, we see the badge for one of the two CSS Grids on our page. If we click this new badge and return to our web page, you can see the new grid overlay on top of your existing content, allowing you to visualize the layout of the grid inline without the mental gymnastics of reading your authored CSS and hoping it does what you think it will. But what if this isn’t the exact information you want to see about your grid? What about grid areas, line names, and other options? To answer that, let’s return to Web Inspector. Here, you can find another new feature, the Layout panel, which shows all the options and controls related to grid overlays. First, let's take a look at the list of grids on the page. Here you have the option to toggle all of the grid overlays on or off all at once. Or you can toggle a single grid’s overlay off or on. Each grid is listed with its corresponding CSS selector to help identify it in the list. Next to each listed grid is a color swatch that allows you to interactively change the color of the grid overlay, and the badges on each element will use this color when that grid overlay is enabled. Web Inspector will remember your color for each element the next time the same page is loaded. Now let’s take a look at the options we have to control how these overlays are displayed, starting with track sizes, which show the authored sizes of each track -- which is a row or column -- of your grid. Like here, where a mix of fractional units and min-content are used. Next, line numbers show you the values that can be used to place child elements at specific rows or columns in your grid. We’ve placed negative line numbers -- which represent line numbers counting from the last explicit grid line -- inside the label, alongside the positive line numbers to allow you to choose how you want to place your item. Line names provide another way to refer to your lines in your grid based on area names as well as lines that have been explicitly named. Area names allow you to see each of the named areas in your grid, which is helpful if you want to place children in your grid without addressing the lines on each side of your desired placement. We’ve placed area names in the center of each area and outlined each area in a thick stroke. Lastly, turning on extended gridlines on this second grid container allows you to see the track lines extended to the edge of the page, allowing you to visually compare the grid’s alignment to other elements on your page. We’ve built our overlays with performance in mind, and you can enable as many as you need, all while smoothly scrolling through your page. Dozens of grids can be shown simultaneously, all while providing you buttery-smooth scrolling. They work for all writing modes like this vertically set text originally from Wikipedia, right-to-left text direction, and combinations thereof. And these overlays are also available on iOS 15 and iPadOS 15 when inspecting remotely from a Mac with Safari 15 or the latest Safari Technology Preview. We believe that grid is an incredibly important layout tool on the web, and that is why we have brought these tools to Web Inspector, enabling you to visualize and debug grid across all of our platforms to continue to create incredible layouts. Now let’s take a look at how grid overlays can help us to better understand and solve problems on our web pages. Let’s take a look at a web page I’ve been working on that gives me a quick overview of information I want to see each morning. I can see my commute, the weather forecast for the day -- looks like I’ll want a jacket tonight! -- and a list of things to pick up at the store after work today. This page is laid out with CSS Grid, which made it easy to create these varying sized tiles and place them on my page. But wait, it looks like I forgot to place one of these fun emojis I used to decorate my dashboard. It belongs down here with the rest of my emojis! No problem. I can use our new grid overlay to help me place it exactly where I’d like. To begin inspecting my page, I’ll right-click on my problematic element and select Inspect Element. If you don’t see Inspect Element, make sure to enable Web Inspector like we discussed earlier. I’ll then select the Layout panel in the Details sidebar, where I can see all the grid contexts on my page. I can’t quite remember which of these grids I want to work with, but I can enable all of the overlays at once by checking the top checkbox for all grid overlays. I now see the grid context I want to work with is the pink one, which holds all of my tiles. I’ll just turn off the other two overlays by unchecking them in this list of grid contexts. And now I’m left with only the grid overlay I’m interested in. If you're like me, you may only want to see exactly the information you need to perform the task at hand, so I’m going to disable Track Sizes labels so I can focus just on the line numbers for placing my stray emoji. And now the remaining line number labels let me see exactly where I want to place my emoji: at column track line 6 and row track line 4. Because I explicitly right-clicked and inspected the tile for my problematic emoji, it's already selected for me, and I can jump right to editing its style to test my fix. And with our new three-panel layout, I can keep the Layout panel visible at the same time, which is great for when I want to switch which labels or grid overlays I’m showing while testing different styles on my page without constantly switching between panels. In the Styles panel, I'm going to click in the Style Attribute section and add a new property, grid-area. I can then type a colon to jump to editing my new property's value where I will enter "4 / 6" for row track line 4 and column track line 6. Perfect, my emoji is right where I want it now. But now that I think about it some more, I really want to make sure this emoji is always in this corner, even if I add or remove rows or columns from my grid later. In the same labels that gave me values of row track line 4 and column track line 6, I see a second line number, -3, for each. This negative line number will actually keep my emoji three track lines from the end of the grid I’ve explicitly defined, and will be perfect for my situation. I’ll update my grid-area property’s value to these new values, "-3 / -3", and see that my emoji is still in the correct place, and will continue to be if I add another row or remove another column from my grid. This new overlay coming to Web Inspector helped me quickly adjust the layout of my page, and is great for understanding existing layouts as well as designing new layouts. Now let’s talk about improvements in JavaScript debugging with breakpoints. For scripts, we often start with console.log as we try to figure out why our script isn’t working the way we think it should. Alternatively, if you’ve never tried breakpoints, I highly recommend checking them out. They are powerful and, as we’ll see in just a moment, even more configurable than before. If you're new to breakpoints, the easiest way to get started is in the Sources tab by clicking in the line gutter of your JavaScript on a line at which you’d like to pause. This creates a breakpoint which, when reached, will pause your script at the beginning of that line, waiting to execute the line; allow you to step through your code one statement at a time; or dive deeper into a specific statement; and view the state of your variables every step of the way. But there's so much more to breakpoints! In fact, there are five different types of breakpoints, one for every occasion. There are breakpoints for debugger statements, exceptions, and assertions; JavaScript breakpoints, which you can set on lines of JavaScript; event breakpoints, which pause when an event like click, timeouts, intervals, or animation frames are handled; DOM breakpoints, which pause when actions related to a DOM node occur. These can be added in the Elements tab, or from the context menu for any node preview in Web Inspector. And URL breakpoints, which pause when a network request is about to be made for a URL via APIs such as XMLHttpRequest or Fetch. You can configure your JavaScript breakpoints by right-clicking on a breakpoint and selecting Edit Breakpoint. Here, you can control numerous aspects of the breakpoint. Let’s take a look at each of these options. We can set a condition, which must be true for the breakpoint to be hit. New this year, we now support using Web Inspector’s Console tab API inside expressions in breakpoint conditions and actions, like this one that refers to the currently selected DOM node in the Elements tab. In some cases, a breakpoint condition may be better expressed as a number of times to ignore the breakpoint before it is hit, like while inside a loop where we don’t want to stop until some number of iterations have been completed. This can be used in addition to or instead of a condition to control when the breakpoint will fire. When used in addition to a condition, the count of ignored invocations is incremented only if the condition was satisfied. Next, you can define actions that are taken when your breakpoint is hit, like evaluating JavaScript in context with access to variables, as if the code was inline in your JavaScript source; log messages to the console easily with a template string literal; play a system beep so you audibly know the breakpoint was hit; and define a probe expression, which is evaluated with its result saved in the Probe panel of the Details sidebar of the Sources tab, allowing you to see the results of the expression as it changes over the lifetime of your web page. New this year, the action types that support JavaScript expressions can be set to emulate a user gesture, which can be helpful when interacting with JavaScript APIs that normally require a user to have initiated them, like playing a video, enabling you to quickly test new behavior before implementing the change in the web page’s source. You can mix and match any number of these actions to customize your breakpoints, including multiple of any action type. Lastly, you can have your breakpoint automatically continue after evaluating and performing your actions for situations where you just wanted to add some logging or a quick patch to test without modifying the underlying web page. These options for configuring breakpoints are incredibly versatile, and this year I’m pleased to tell you that they are now available for all breakpoint types, not just JavaScript breakpoints. This enables you to set powerful breakpoint conditions, like only pausing on click events for a specific type of element, like button; or playing a system beep when a network request is made for a specific URL. These configuration options being available for all breakpoint types make already great debugging tools even better by helping you cut through the noise -- or even make a little noise -- at just the right time. Now, let’s return to my dashboard web page and take a look at an issue that these new tools will make a breeze to debug and test a patch for. I recently added a button to my commute tile that I want to use to share my estimated commute time with someone else. You never know when you might end up running late. Unfortunately, when I click my Share button, nothing happens. Even worse, it’s been a few days since I’ve worked on this tile and I don’t remember where I handle click events for this button. Fortunately, I can use an event breakpoint to pause in my click event handler to find my code. I can create event breakpoints here in the Sources tab. Clicking the plus in the top right of the breakpoint section of the Navigation Sidebar, and selecting Event Breakpoint, allows me to define a new event breakpoint. I’ll set the event to click, and then press the Return key to create my new breakpoint. I now see my click breakpoint listed in the Navigation Sidebar. This event breakpoint should pause when I click my button. But first, I want to make sure I’m sharing the most up-to-date time estimate for my commute, so I’ll click my Refresh button and -- Oops! My event breakpoint will actually pause for all click events, including my Refresh button, even though I really only want to pause when I click on my Share button. Let’s modify my breakpoint using the new configuration options that are available this year. I can edit my breakpoint by right-clicking on it and choosing Edit Breakpoint. Here, I get a popover with the configuration options for the event breakpoint. I need to add a condition to make sure I only pause when I need to. In this case, I can use some Web Inspector console API to get the current event with "$event", and check if the event’s target is equal to my Share button. Instead of hard-coding my breakpoint for this specific button, I’ll use another piece of console API to check if the event’s target is the currently selected DOM node in the Elements tab with "$0". I can click out of the configuration popover and all my changes are automatically applied. I’m still paused on my breakpoint from clicking on the Refresh button, so I’ll click the Continue button to resume script execution on my page. Now, when I click on my Refresh button, my commute time updates and my breakpoint isn’t hit. But if I right-click on my Share button, and select Inspect Element to make it the selected element, I can now click on my Share button and bingo! The breakpoint paused exactly where I wanted it to, and now I see why my Share button doesn’t work: I forgot to write this function. Breakpoints can save the day -- or at least this demo -- again, and help me patch sharing in right now to test my changes before I go back to the source to implement them. I’ll add a breakpoint in my share function by clicking in the line gutter, right-clicking on the breakpoint indicator, and choosing Edit Breakpoint. I don’t need a condition on this breakpoint, but I want to add an action. The default action type, Evaluate JavaScript, is exactly what I want here. I’ll add my JavaScript to the action, which will call "navigator.share" with an object I’ve already prepared with my data, "this.shareData". I don’t actually need to pause my script as part of testing this fix, so I’ll also enable Automatically continue after evaluating. Like before, clicking outside the popover saves my changes. I'm done with my click event breakpoint for now, so let's click on its indicator to disable it. I'll also click the Continue button to resume script execution on my page. I can now click on my Share button, and am presented with the Share menu. I'll select Notes to confirm my share data is correct. This looks correct, so now I can go back to my source code and make this change. Awesome! These enhancements to breakpoints made it possible to identify and test a solution without having to pepper my source with console.log statements. And now that I have a working solution, I can go add my fix to my source. Now let’s take a look at an exciting new feature for audits: the ability to create and edit your tests right in Web Inspector. Each test in the Audit tab is written in JavaScript and is run against the inspected web page. These tests can check for incorrect DOM structure, help enforce design system rules, or help make sure you haven’t missed accessibility attributes. In addition to individual tests, you can share and run groups of tests. By default, Web Inspector has two test groups: the Demo Audit, which provides a tour of the way audits work and the functionality they support, and a suite of accessibility tests that check for a subset of the DOM accessibility best practices in accordance with the ARIA specification, such as ensuring that a title or alternate text is set on all image elements. You can run a test by selecting it and using the Start button next to the audit name, or run all of your tests with the Start button at the top of the Navigation Sidebar. After your tests have run, you can see the results of each test as well as an overall summary of passes and failures. If there are any failures, you can see information about those failures so you can get them patched up. To share your tests, or to edit them in an external text editor, you can export the test, make your changes to the resulting JSON file, and then import the modified test back into Web Inspector. This process of exporting and importing is great for sharing your tests across your team or with the community. And this year, we are making creating and editing tests even easier with a new Edit mode. When you click on the Edit button in the bottom of the Navigation Sidebar, the Audit tab transforms into Editing mode, where you now have the ability to create new tests as well as edit your existing tests. Note that the default Demo Audit and Accessibility test groups cannot be deleted or edited, but can be duplicated and then the duplicate can be edited. For now, let’s look at creating a new test by using the Create item in the Navigation Sidebar. You can create a new test case, or a group of test cases. For now, let’s look at creating a new test case. When we create a new test case, you see that it is added to the Navigation Sidebar, and the default contents of the test appear for you to edit. Here you have several different things available to configure. The name, as well as the description of the test, and the minimum audit version the test supports, which makes sure the audit is not run in an older version of Web Inspector where some features may not be supported. The setup script is JavaScript that will be executed before every top-level test or test group. This allows you to perform common setup functions that all tests under this top-level test rely on. And last, but certainly not least, there is the test itself, which is a JavaScript function that can return true or false or a result object with more information about the test’s run. A special WebInspectorAudit object is also available, which exposes additional API specifically for tests to use in both the test itself as well as the setup for the test. You can learn more about this API in the Web Inspector Reference. Your changes are automatically saved, and all of this can now be done in Web Inspector without exporting. But to really get a feel for the flexibility of these tests, I’d like to show you them in action. Let’s return to my dashboard one last time and see how audits can help me catch some types of accessibility problems as well as design issues in my web page. The first thing I like to do when I open the Audit tab is to run the default Accessibility test cases. These will help me get a good baseline reading for how I’m doing on common accessibility best practices. I can quickly run these tests by clicking on the Run button next to the test group. And not bad, but I can do better. I can look at the test failures by clicking the Passed filter button to hide those results, leaving only my test failure to view. Let’s get this fixed. This test provides a list of DOM nodes that failed, making it easy to jump to that node using the Reveal in Elements Tab button that appears on hover. In the Elements tab, I’ll test adding a title to my image by right-clicking on the DOM node choosing Add > Attribute, and typing my new title.

I’ll return to the Audit tab and run the same test group again. And this time, I see that I pass all the tests. Another great use for audits is checking to make sure my web page meets my own design standards. One of my rules while working on this project was to make sure I was consistently using a small set of font families for all of my elements. Let’s use the new Audit Edit Mode, added to Web Inspector this year, to do just that. I’ll begin editing by clicking on the Edit button at the bottom of the Navigation Sidebar. Now I’m in Edit Mode. Here I can create a new test case using the Create button at the top of the sidebar. I’ll keep the default option of Test Case, and name my test case "Fonts." I can now edit the rest of my test case. I’ll start by adding a description to help me remember what this test case does. Now let’s insert my actual test code I’ve prepared.

My test will have three main steps. First, I’ll create an array of expected font families. Next, I’ll collect all the elements on my page with a font family that isn’t listed in my expected font families. Lastly, I’ll return my result object, including any elements that failed my test. When I’m done writing my audit, I just click Done at the bottom of the Navigation Sidebar. I can now run my audit by clicking the Run button next to its name. It looks like I have an issue with one of the nodes on my page, so let’s take a look at what's wrong. I can again use the Reveal in Elements Tab button to go to the element and look at its style. Well, this is embarrassing. Comic Sans! I really don't want to use this font, so let's change this to the ui-rounded font family instead.

Now, I’ll return to the Audit tab, run my test again, and perfect! The last thing I want to do is export my test using the Export Audit button so that I can share it with my colleagues to help them avoid the same embarrassing mistake I made -- although maybe I’ll leave out the Comic Sans part of the story. Not only were the built-in accessibility tests able to catch an issue I missed, I was able to write a test to enforce my own design system rules for my web page, making it even easier for teams to make sure everyone is on the same page before ever checking in their changes. And with that, we’ve covered these big new features in Web Inspector! A new overlay for CSS Grid helps make sure your content looks just right. Breakpoint improvements make it easier to find, debug, and test fixes for issues without leaving Web Inspector. And with the new audit creating and editing right in Web Inspector, you can quickly create tests to make sure web pages meet accessibility standards as well as your own standards. Along with these new features, we’ve made tweaks and enhancements as well as fixed numerous bugs to further improve Web Inspector. Before I go, there are some helpful resources I’d like to leave you with. You may not have realized that Web Inspector is part of the open source WebKit project, which is the fast, private, and secure web browser engine used by Safari, Mail, App Store, and many other apps on macOS and iOS. You can learn more about the WebKit project at webkit.org, where you'll also find blog posts about new features in WebKit, including this one about grid overlays in Web Inspector. In addition to blog posts about new features in Web Inspector, you can also find documentation which covers a wide range of Web Inspector’s features and interface, and goes deep on many of the features we discussed today, like audits and breakpoints. There's so much more depth to those features than I was able to cover today, and I highly recommend checking out the documentation if you’d like to learn more. We also would love to hear from you! If you come across a bug or have a suggestion on how we can improve Web Inspector, please file feedback for macOS in Feedback Assistant, and select WebKit as the area for your feedback. I’d also like to invite you to download Safari Technology Preview, released approximately every two weeks, which is designed specifically for developers to get early access to new WebKit and Web Inspector tools, features, and fixes before they appear in the version of Safari included on every Mac, iPhone, and iPad. Lastly, please check out these other great sessions, including “Design for Safari 15,” to learn how to adapt and design beautiful content for Safari; and “Develop advanced web content,” to learn all about new JavaScript and WebAssembly features you can use to further enhance your web pages. Also take a look at our session, “What’s new in Web Inspector,” from WWDC 2020 to see even more improvements we’ve made in Web Inspector. You can find these fabulous sessions, and many more, in your Developer app. Thank you! ♪