What’s new in Web Inspector

♪ ♪ Razvan: Hello! I'm Razvan, an engineer on the WebKit Developer Experience team, and I'm here to tell you about some of the new features and improvements we've made to Web Inspector this year. Web Inspector is part of Safari on macOS, and it provides a powerful set of tools that allow you to inspect all the resources and activities of a website, web app, web extension, or home screen web app. I'm excited to show you some of the new features and improvements we've added since last year, like new typography inspection tools, a way to emulate user preferences, new badges for elements with event listeners and scroll containers, and we've improved the JavaScript debugging experience with enhancements to breakpoints. If you haven't used Web Inspector before, you'll have to enable it. Open the Settings window of Safari and switch to the Advanced tab. At the bottom, you'll find the setting to "Show features for web developers." Click the checkbox to enable this. The Develop menu is now available in the menu bar. You can open Web Inspector using the menu item called Show Web Inspector or by pressing the keyboard shortcut Option+Command+I on any web page.

This year, we've made many improvements to all of the developer features in Safari, including a streamlined way to pair and inspect web content on devices, a quick way to open a web page in a Simulator, a refreshed Responsive Design Mode, and many others. To learn more, watch this session titled "Rediscover Safari developer features" from this year's WWDC. Now that Web Inspector is enabled, let's start by looking at the new tools for typography inspection.

Web developers use custom fonts to create beautiful content with type that is both legible and makes it stand out. But getting typography on the web just right is not always easy. First, the right font file needs to be loaded. It must be in a format supported by the browser and with the right features. And it should include the right glyphs for the characters of the written language it's going to represent. Then, there are many CSS properties that influence the way a font renders on screen. And most of them are inheritable through the cascade, sometimes leading to confusion, like, "Which font face was actually used?" Or "Why is this bold?" Or "Is this style really italic?" Web Inspector can help with a host of typography inspection tools. You can find them in the Details sidebar of the Elements tab, in the Font panel.

It shows properties and capabilities of the font used on the selected element, such as the name of the primary font used. You can reference this to quickly check if the font you expected was indeed used. Keep in mind that this only identifies the primary font. If the selected node includes characters for which the primary font does not have glyphs, a fallback font will be used for those. Next, the Font panel shows a summary of the basic font properties, like font size, style, weight, and stretch.

There's also a section that shows the supported font feature properties and their used values. These toggle special aspects of a typeface such as ligatures, small caps instead of lowercase characters, special numeric styles, and many others, depending on what the font supports. New this year, the Font panel shows warnings for synthetic bold or oblique styles. What's a synthetic style? Let's take italic as an example.

Italic styles are often supplied in their own font files, separate from the ones for the regular upright styles. When a suitable italic style is missing, WebKit generates an artificial representation for that. It runs an algorithm over the regular upright font style and skews the individual glyphs to produce an oblique style. This is called a synthetic oblique.

Font designers pay a lot of attention when crafting italic styles. Often, these aren't slanted versions of the upright style, but instead they're cursive, specially designed to convey a particular aesthetic. Something similar happens for synthetic bold, where the stroke of the glyphs is made artificially thicker. Keep in mind that not all fonts support this. Web Inspector now displays a warning when a synthetic bold or oblique is used. It shows up next to the synthesized weight or style in the basic properties section of the Font panel. This warning can be a hint that the expected font file was not loaded. But sometimes, it may be that the font file just doesn't support the exact values you asked for. That's where variable fonts can help. What's a variable font? Put simply, it's a font format that can include, in a single file, all the information needed to generate multiple style variations for a font, such as weight, width, slant, and others.

And for each supported style, variable fonts provide a spectrum of values compared to just a few discrete values in static font files. This gives you a lot more flexibility to choose the exact style that's right for your content. Variable fonts are even more capable. A font designer can make almost every aspect of a font configurable, from the thickness of the stroke, the curves of the glyphs, the width of the characters, and many others. The possibilities really are vast. All aspects of a variable font that can be configured are expressed as variation axes. To know which are available, you'd either have to read the font's documentation or use a special tool that reveals this information.

Web Inspector can help here. When you inspect an element that uses a variable font, the Font panel shows you a list of the supported variation axes. For each, it shows its axis tag-- a four-character identifier-- an optional axis label, the supported minimum and maximum values, as well as the current value, or the default value if one is not specified in CSS.

This year, we added interactive controls to edit the values of variation axes and see the results live on the inspected page.

This gives you a great way to tweak the font styles until they're just right. Let me show you. Here's a web page I'm building for a travel photography blog. I have the layout just as I want, with a photo gallery and navigation by labels, but I'm still not sure about the look of the title. I'll right-click to inspect the heading element.

In the Font panel, I can see this is using a variable font.

I can tell because I have these controls for the available variation axes that I can play around with. For example, I can drag the slider for the Weight axis. This immediately changes the font weight of the title live on the inspected page.

Notice how the corresponding CSS font weight property is written to the Styles panel. A static font would have just a few font faces for weight in increments of 100. But with a variable font, I can chose any value within the range of the variation axis. Let's also try the variation axis for Width to see how this looks wider or narrower.

I can also type in the axis value input field or I can hold the ArrowUp or ArrowDown keys to change the value in precise increments.

I like this slightly condensed version. I'd like it a bit bolder, but I want it to keep this width. This variable font also provides a custom variation axis to change the Grade of the font. When I drag the slider for this, notice that the individual characters get thicker in-place without shifting position like they did when I changed the Weight axis.

This looks nice. To integrate these changes back into my project, I can copy the new CSS properties from the Styles panel or from the Changes panel.

We've seen how to inspect typography and how to tweak font styles with variable fonts. Now, let's move on to another new feature in Web Inspector that allows you to emulate user preferences so you can make sure the content you're building adapts to user needs. All Apple products offer a variety of settings that allow people to configure their devices to adapt to their needs and preferences, like the Accessibility settings on macOS which control things like the built-in screen reader, VoiceOver, or Display preferences, which control reduced motion, increased color contrast, color filters, and many more. One of the most popular things people do on their devices is to browse the web. So it makes sense to build websites and web apps that strive to welcome everyone. To do that, you sometimes need to experience the web the same way other people do when they set user preferences.

To test your website with, say, the preference for reduced motion, you could go to the Accessibility Settings on macOS and set it there. But that will influence the entire system, not just Safari and your website. What you often want is to set it just for the page you're testing.

To help you with that, we've introduced a new tool in Web Inspector to emulate user preferences. Click the new icon in the Elements tab to reveal the User Preference Overrides popover. Here, you'll find a set of toggles to override user preferences just for the inspected page while Web Inspector is open. These preferences map to CSS media features which you can use to adapt the style and behavior of your web page. For example, the preference for color scheme maps to the prefers-color-scheme media feature in CSS. Here's how to use it: you can set an element's styles for the default light color scheme. Then, use the prefers-color-scheme media feature to check if a dark color scheme is preferred and update the styles. Check how the page adapts by using the User Preference Overrides popover. In the Appearance section, override the color scheme preference to Dark. The icon changes color to indicate an override is applied. The styles for the dark color scheme will be applied while the override is active and Web Inspector is open. This control for color scheme used to be a standalone button. It now joins the other controls for preference overrides in the popover.

Next, I'm going to show you how to override the preference for reduced motion. This next section displays an animation with a lot of motion. If you are sensitive to this, you may want to skip the next three minutes of this video. Back on my page, these animations that run when I click on a photo to enlarge it are perhaps a bit too much.

Some people can get disoriented by animations with quick and sudden motion, particularly when it happens on the z-axis. It can cause discomfort, like nausea or headaches. This is definitely not a welcoming experience for them. People can set the preference for reduced motion on their devices to signal that they want websites and web apps to adapt. Us web developers should respect that. This is where the prefers-reduced-motion CSS media feature is useful. If the animation is just for decoration, you can remove it. But remember, some animations are useful to convey meaning in an interface. Removing them can affect usability. A slower and more subtle fade animation may still work well to communicate change and also satisfy people's needs. Let's try that change on my web page. First, I'll inspect the photo and select the figure element in the Elements tab of Web Inspector.

This reveals all its matching CSS rules in the Styles panel. Here's the CSS property that sets the animation with a lot of motion. It runs for everyone now. Next, I'll click on the source code location of this CSS rule to jump to where it's defined in the stylesheet.

This opens the Sources panel and puts me right next to that CSS Rule which has the animation I want to change. I'll uncomment this block of code I prepared earlier. It's guarded by a prefers-reduced-motion CSS media feature. Here, I change the animation to a fade, instead of the one that zooms the photo, and I also increase the animation duration so it doesn't feel as sudden.

Now I'll click again on an image on the page to see how that looks.

Oh! It still runs the same animation. That's happening because I defined the new animation guarded by the prefers-reduced-motion media feature. But the page still respects the default system value for this preference, which is set to Off. Let's adjust that. I'll click back to the Elements tab. Here, I'll open the User Preference Overrides popover.

In the Accessibility section, I'll open the popup menu to override the user preference for "Reduce motion." I'll change it from the default value on my system and set it to On.

Now, I'll click again on a photo on my page.

And look. The photo now slowly fades into view. No more disorienting movement. This is a better experience for those who prefer reduced motion. I'll remember to integrate these changes back into my project. The last item in the User Preference Overrides popover, "Increase contrast," maps to the prefers-contrast CSS media feature. Ideally, you want to build content that has a high level of color contrast for everyone. But if your design system constrains you, use this media feature to adapt your styles for people who benefit from increased contrast. Then, check that the styles on the inspected page adapt accordingly. Override the preference for "Increase contrast" to On. We hope you use these features to build content that even more people can enjoy using. Next, I want to tell you about the new element badges in the Elements tab of Web Inspector. In the node tree view of the Elements tab, you can already see badges next to elements that act as CSS Flex or CSS Grid containers. Element badges provide a quick way to identify at a glance nodes of particular interest. In this case, nodes that create a CSS Grid or Flex layout context.

You can click on the grid and flex element badges to toggle the specialized page overlay for that node. The highlight color of the badge matches the color of the page overlay. The CSS Grid and Flexbox page overlays show guides that reveal the lines, gaps, and the available space which determine the layout. To learn more about how to debug CSS Grid and Flexbox layout with page overlays, watch these sessions from previous years. One of the trickiest CSS layout issues to debug is unwanted scroll, like a container that scrolls horizontally because the content inside it doesn't fit the available width. This type of issue can lurk undetected for a long time when scroll bars are not visible by default. To help you identify unwanted scroll, we've added a new element badge that shows up next to scroll containers. It provides a quick visual hint in the node tree when an element's content overflows its bounds and a scroll bar is applied. Let's look at a common example of unwanted scroll and how to fix it. Back on my page, I see these labels at the top of the photo gallery appear be nicely laid out to use all available horizontal space. But when I try to swipe, I notice there's a short horizontal scroll in this container. This is something I don't want. And the last label is slightly cut off. It gets even worse when I resize the window. In the node tree in the Elements tab, I notice there's a "scroll" badge next to the container for the labels. I'll click this element to reveal its matching CSS Rules in the Styles panel. This Flexbox container looks right. How about its flex items, the labels themselves? This overly precise value for the minimum-width property looks strange. It was probably my naïve attempt to tell the browser exactly what to do instead of telling the browser what I want and letting it do the math.

To fix this, I'll comment out this minimum-width declaration. Now, each label takes up as much space as it needs. But there's a lot of unused space left. To fix this, I'll add a flex property with a value of 1.

This distributes the unused space to each of the labels so they fill up the container. And there's no more unwanted horizontal scroll, as confirmed by the now missing "Scroll" badge next to the container in the node tree. Next, I'd like to tell you about the new Event badge. It appears next to elements which have JavaScript event listeners attached to them. It works both for built-in events, like pointer or UI events, as well as custom JavaScript events that you dispatch in your code. Look for elements with the Event badge next to them in the node tree and click on the badge to show a popover with all the event listeners attached to that element. Here, you can get an overview for each event listener: the event type, the name of the JavaScript function which handles the event, and the location in the source code where that function is defined. The various configuration options for the event listener, like whether it bubbles through the DOM tree or if it's automatically removed after running just once. Then, there's the option to disable the event listener so you can debug your code without it running. Or if you want to debug it step-by-step, you can set an event breakpoint for it. This will pause JavaScript execution next time the handler is invoked. This is a good time to talk about the improvements we've made to the debugging experience with breakpoints. When debugging JavaScript, you may be used to adding console.log() statements to your code. Breakpoints, on the other hand, are a powerful way to debug by pausing and stepping through JavaScript without having to make changes to your source.

If you haven't used breakpoints before, the easiest way to start is by clicking on a line number on a script file in the gutter of the Sources tab. This sets a JavaScript breakpoint on that line of the script. Next time that line is about to run, Web Inspector will instead pause JavaScript execution at that point. While paused, you can observe the call stack, inspect the state of objects and variables in scope, and even make changes to them through the Console.

You can resume JavaScript execution, or you can step through the code one expression at a time, using the stepping controls at the top. You can configure a breakpoint by right clicking on it and selecting Edit Breakpoint. Here, there are many options you can set to control when the breakpoint is hit and even run actions when it does.

Let's look at a few of them. You can control when a breakpoint is hit by setting a condition for it. This evaluates as JavaScript in the same scope where your breakpoint is set. When the condition is true, the breakpoint will hit. Sometimes, you may find it easier to skip the breakpoint for a number of times. For example, while inside a loop where you're not interested in stopping for the first few iterations. Here, you can set the number of times to ignore the breakpoint. You can also run actions when a breakpoint is hit, like evaluating a piece of JavaScript. This runs in the same scope where the breakpoint is set. You can use this to modify the state of your script before continuing. You can also log messages to the console with expressions that have access to the state of variables and objects at the moment when JavaScript was paused. This is similar to adding a console.log() statement to your code, but without having to modify your source. Instead of logging variables and objects to the console, you can also use the Probe Expression action. This allows you to inspect the state of the given expression in the details sidebar panel of the Sources tab. Of course, these actions are very useful, but sometimes you just want to run them without actually stopping at the breakpoint and having to resume manually. In those cases, use the option to automatically continue after evaluating expressions. This option makes the Log messages action behave like a console.log() statement: it logs, but it doesn't pause. Likewise, you can evaluate some JavaScript at the breakpoint location and continue as if it were already in your source code. There are many other types of breakpoints you can set. Click the Plus button in the Breakpoints section to show a list of all the breakpoints you can set, such as URL Breakpoints that trigger when a network request is about to be made via methods like fetch() or XMLHTTPRequest, event breakpoints like the one we saw earlier from the Event badge for "click," breakpoints that trigger when micro tasks, animation frames, timeouts, or intervals are handled, and new this year, we've added Symbolic breakpoints to pause before a function is about to be invoked. Symbolic breakpoints are helpful to debug calls to built-in JavaScript functions or to pause in multiple functions with the same name. When adding a Symbolic breakpoint, you can be as specific or as generic as you want. Either match the function name exactly, including case sensitivity, or use a regular expression if you want to break at multiple functions that match the pattern, or if you don't quite remember the complete function name. Let's see how Symbolic breakpoints help debug a problem I have in my code. Each photo on my page has a share button that lets me share a link to it with friends. But I've received a bug report that the URL they get doesn't point to the photo page. Let's investigate. It's been a while since I worked on this, and I don't quite remember how it's built. There are multiple ways to debug this, but I'm going to try a Symbolic breakpoint. I'll switch to the Sources tab and click to add a new Symbolic breakpoint.

Whatever code runs on my end, it has to eventually call the navigator.share() browser API which shows the system popover. Let's set a breakpoint before the share() function is invoked. I'll click away to set my Symbolic breakpoint. And now I'll click the share button on a photo on my page. And look, Web Inspector has paused before navigator.share() is invoked. I'll hover over the data object passed to this method. Here, I can see the contents of the object. It seems the value for the URL key that gets shared is indeed wrong. Where does this come from? In the Call Stack section of the Sources tab, I can see the chain of functions that were called to get to this point. Looks like the click event handler was called before. I'll select its entry in the Call Stack to jump to that function. Here, I can see the code that builds the data object which gets passed to the sharePhoto() function. And by the look of the code comment here, I meant to implement this, but I forgot. Let's fix that now. I'll click to set a breakpoint on this line. Then, I'll right-click and select Edit Breakpoint.

I don't need to set a condition, but I'll configure it to run a JavaScript action. Inside the expression field, I'll modify the data object to fix the url property before it gets passed along to the share function.

I don't need this breakpoint to stop here, so I'll click the option to automatically continue after evaluating this expression. Next, I'll click the button to resume JavaScript execution. Now, when I click the share button, the Symbolic breakpoint I set earlier is reached again. But now the data object it gets has the right URL value. The JavaScript action from the other breakpoint modified the value and sent it along to this function without pausing. This confirms that the change I made there does indeed fix the issue. This was just one example of the many great debugging workflows enabled by breakpoints. There are so many more, and I encourage you to try them out in your projects. We've covered a lot in this session, from the new typography inspection tools, to overriding user preferences, using the new element badges, and we looked at breakpoint enhancements. And that's just scratching the surface. There are many other new features and improvements in Web Inspector this year that we didn't have time to cover in this session.

And there's so much more that Web Inspector can do. If you want to learn more about these and the many other features you can use, go to webkit.org to find in-depth blog posts and documentation. We'd also like to hear from you. If you encounter an issue or have ideas for how we can improve Web Inspector, please let us know by filing an issue on WebKit's bug tracker for the Inspector product. I'd also like to encourage you to download Safari Technology Preview. It is released every few weeks and contains the latest tools and technology in WebKit, as well as bug fixes and improvements, before these reach the next version of Safari.

Before I go, if you want to learn more about what's new for developers in Safari this year, check out these great sessions: "Rediscover Safari developer features" and "What's new in CSS." Thanks for watching.