The web site of jiawp

Tactics and Tools for Troubleshooting Front-end Web Development

An Introduction to Front-end Developer Tools Introduction Hello, and welcome to this course where you will learn tactics and tools for troubleshooting front-end web development. This course will introduce you to the most popular professional tools available to help you troubleshoot issues in CSS, JavaScript, and cross-browser and device compatibility. You will learn how to determine the cause of and fix the most common front-end web development issues. You will also learn techniques to help troubleshoot more advanced and complex issues. In this introductory module, I will show you the tools that we will use throughout this course and walk you through installation and configuration. You will also see the sample website that you will begin with which includes a lot of errors by design that you will learn how to fix to create a fully-working and polished website by the end of this course. The benefits of learning these tactics and tools cross many different roles in web technologies. HTML, CSS, and JavaScript are the backbone of any front-end or back-end developer's toolkit. Whether you are working with ASP.NET, PHP, or some other webdev technology, you will be working with HTML, CSS, and JavaScript, so having a good understanding of the common errors and how to fix them will really help you level up your skills and forward your career. Let's go ahead and get started.

Front-end Developer Tools The tools that we will use in this course are the standard set of tools that professional front-end developers use. During this course, I will provide you with the most common troubleshooting scenarios, and show you how you can use these tools to fix CSS problems, JavaScript errors, and also fix cross-browser and device compatibility issues. First up is Chrome. The standard installation of Chrome includes the Chrome Developer Tools, which are my personal favorite, and I use these tools on a daily basis. The Chrome DevTools are a set of web authoring and debugging tools that provide web developers information about the internals of the browser and how it runs their website. These tools can be used to efficiently track down layout issues, debug JavaScript, and get insights for code optimization. Then there's Firefox and Firefox Developer Edition. The Firefox Developer Tools are very similar to the Chrome Devtools, but there is also a very popular add-on called Firebug, which provides even more tools for web developers. We will discuss the differences between the regular installation of Firefox versus Firefox Developer Edition as we go through the course but the main difference that you should be aware of right now is that the Firefox Developer Edition includes a WebIDE, which stands for Integrated Development Environment. Using this WebIDE, you can develop, deploy, and debug web applications. Next up is Internet Explorer. In the past, you had to install the developer tools separately, but they have now included them in the regular installation. These tools are much like the Firebug or the Chrome DevTools. However, if you have ever done any front-end development, you know that cross-browser compatibility is quite the pain for Internet Explorer, because it just doesn't render webpages in the same way as a standard browser. So, having the IE devtools at your disposal is very handy in troubleshooting IE's specific issues. The IE devtools are also available in the newer Microsoft Edge browser. So those are the three most popular browsers and tools, but what about cross-browser compatibility with Safari or Opera? What about compatibility across mobile, tablets, laptops, and desktops? That's where BrowserStack comes in. This one is the showstopper with so many features that I gave it two modules at the end of the course. BrowserStack is a tool that enables you to run your web application on any device, operating system, and browser combination. It also has a great reporting feature that automatically tests your website and produces a list of cross-browser and device compatibility errors. Using these five tools will enable you to troubleshoot any front-end development issue. Now let's a look at these tools, where you can download them and configure them for optimal use.

Installing and Configuring Front-end Developer Tools Let's go ahead and install Notepad++, which is a tool that we will use to edit our HTML, CSS, and JavaScript files. You can download it from notepad-plus-plus.org, and it's just a really simple tool that most developers use to edit simple markup files, such as HTML or XML. It gives the look of an IDE without all the features that are unnecessary for a simple markup file. In this course, you will be working with a very basic static website written in straight HTML, CSS, and JavaScript. It uses a Bootstrap theme and jQuery libraries, but we will focus on errors with CSS and JavaScript. After Notepad++ installs, go ahead and open the sample website file home.html to view the code for the website that we will use throughout this course, entitled The Convention. Using this website, we will fix common errors across HTML, CSS, and JavaScript files. By the end of this course, this website will be a fully-functional Comic-Con-style website, where guests can register for convention events. One thing I like to do with Notepad++ is turn on text wrapping. You can do that by clicking View and then Word Wrap. This will ensure that you do not have to scroll left and right to see your code and it just makes it easier to view. And I'm just going to increase the font size here using the shortcut control and then the plus key, but that's just my personal preference. While we're at it, let's also check to make sure encoding is set to UTF-8, which is just standard ASCII encoding. You can find this setting under the Encoding menu. Next you should install Chrome from google.com/chrome. There's no extra configuration here. The Chrome DevTools are installed with the standard installation of Chrome. Now let's go ahead and open up the home.html page from our sample website. If you right-click on any element, you can select Inspect Element to open the Chrome DevTools. Using these tools, you can view the CSS styles applied to any element on the page, the JavaScript debugging console, as well as information about what resources your website has loaded and even how long it took to load these resources. Next, let's install Firefox from firefox.com. While Firefox includes devtools in the standard installation we're also going to install Firebug, which is an add-on that includes more advanced devtools. Okay, Firefox is installed, so let's go ahead and install Firebug from getfirebug.com. After it's installed, we will look at the main features by inspecting our sample website. With the homepage loaded in Firefox, right-click the heading and then select Inspect with Firebug. You can see that most of these tabs are similar to the Chrome DevTools, but we have some new ones: the DOM panel, which is useful for debugging JavaScript, and the Cookies panel, which is a great tool if you are working with server-side code that stores cookies. Now let's install Firefox Developer Edition, which you can download from developer.mozilla.org. This tool has some nice features that I like to use when I'm trying to figure out more advanced issues, especially dealing with responsive design. Now that has installed and I have the homepage loaded, you can access the devtools by clicking the settings icon. As you can see, there are many tools available here beyond what we have seen so far in Chrome and Firebug. I especially like the eyedropper tool, which is useful for when you need RGB color codes for CSS. When we get to troubleshooting JavaScript, we will use the browser console and scratchpad to enable us to write, execute, and debug JavaScript directly in the browser. Next up is Internet Explorer, which you can download from windows.microsoft.com. In this course we will be using the newer incarnation of IE called Microsoft Edge, which I already have installed with Windows 10. But the same tools are available in previous versions of IE as well. Once that is installed, go ahead and open the homepage. If you're using Edge, you will need to open the HTML file from the folder, because the control O shortcut doesn't work in the browser. Now go ahead and right-click the header, and then select Inspect Element. Does that look familiar? The IE devtools are basically the same tools that are included with Chrome and Firebug, but the best tool here is the emulator which allows you to view how a webpage would load in previous versions of IE, as well as a few other choice browsers and devices. This is a great tool in a pinch, but if you need to make your website fully cross-browser and device compatible, BrowserStack is the tool for you. BrowserStack is not an application that you install. You access it by navigating to browserstack.com in any browser, but of course, I prefer Chrome. There's a free trial that you can sign up for, and I suggest that you do so, so that you can follow along with the demos at the end of the course. The first time you log into BrowserStack, you will want to install the Chrome extension, which we will dive into later in the course. Okay, so here I've logged into my BrowserStack account, just to show you a quick demo before we move on. On the left, you can choose from a list of devices and operating systems. From there, you can select any browser, any version. Here I have the convention sample site loaded in Safari on an iPhone 6. Pretty cool, huh? As you can see, we have a device compatibility issue to resolve. When you're loading a local website or HTML file, as I have done here, BrowserStack requires a bit of configuration and I will show you how to do that later in the course.

Summary In this quick introductory module, we listed the five most used troubleshooting tools for front-end developers: Chrome Developer Tools, Firefox with Firebug, Firefox Developer Edition, Internet Explorer Developer Tools, and BrowserStack. I walked you through installing and configuring these tools for optimal use. We also talked about some of the key differences in each tool and throughout this course, we will deep-dive into specific scenarios and tactics that you can use along with these tools to troubleshoot any front-end development issue.

Troubleshooting CSS Introduction Now that we have learned how to install and configure our front-end developer tools, let's put them to the test and troubleshoot some of the most common CSS errors. Using the Chrome developer tools, Firebug, Firefox Developer Edition and Internet Explorer developer tools, we will view HTML elements, their assigned styles, inherited styles and computed styles. We will not use all four developer tools for each individual error. Instead, we will focus on the tools that are most useful to help troubleshoot each error. To experience the full potential of this course, you should already be familiar with CSS and Bootstrap. If you're not familiar with CSS and Bootstrap, there are many courses available on Pluralsight to help you get started.

Troubleshooting Stylesheets Not Loading Let's start by looking at the page where the stylesheet is obviously not loading. There are a few things that cause this error, and we will use our developer tools to lead us to the cause of the error. We will use the console in the Chrome DevTools to view file not found errors, Firebug to view the CSS files and Firefox Developer Edition to view all resource requests. If you have not done so already, go ahead and open up Chrome and load the homepage of our sample website. Right-click anywhere on the page and click inspect to open the dev tools. Or alternatively, you can press the hotkey F12. Let's take a look at the console, which will list any errors found when loading the page. You can get to the console by just clicking the tab, or on the elements tab you can click the menu bar and then show console. You can also use the hotkey Escape. So using the console, you can see the path that is rendered from each link element on the home page. If you can pair this path with the actual file path, you can see that the render path needs to go down one more level. Let's look at the HTML to see what may be causing this issue. It looks like the href attribute for the bootstraps stylesheet link is pointing to one folder above the current folder where the homepage is. We needed to look in the CSS folder that is in the same folder as the homepage. Remove the two dots before the forward slash and save. This time, let's open the homepage in Firefox. The change that we just made didn't work, so let's open Firebug to inspect. You can do that by right-clicking anywhere on the page and selecting Inspect Element with Firebug. Just like the Chrome DevTools, you can also use the hotkey F12. Now click the console tab. In Firebug, the console tab does not show resource errors. So to figure this out, we need to look at the CSS tab. Click on the file name drop down to see a list of the files available. Plus, this list includes the path and, as you can see, now the browser is looking for the CSS file in the webroot. This would work if we had a real hosted website where the webroot is configured. But since we're working with the local file system, we need to remove the forward slash before CSS in stylesheet link hrep attribute. This will force the browser to look for a CSS folder in the same folder as the homepage. Back in the HTML file, remove the forward slash before the CSS folder in the stylesheet link href attribute. And this time, let's open the page in Firefox Developer Edition. The stylesheet is loaded, which is great, but there are still two other style sheets that we need to fix. Now let's open up the developer tools from the settings menu. Click the red box showing the number of errors to open the full developer tools. By default, Firefox Developer Edition will not log the missing CSS file error, but we can figure out the problem in another way. What we need is a list of resources including the rendered file path to troubleshoot the issue. We can get this by clicking the console tab and then enabling log in the net drop down. After you refresh the page, the console will display a list of all of the resources that were requested when the page loaded. This is a list of every resource that was requested. So to figure out which ones are causing the problem, we can click the links to open the files in new tabs. If the file loads, it is not causing an error. But if you click a link to open the file and you see a file not found error, you have found the file that is causing the error and can use the rendered file path or URL to fix it. In this case, the browser is actually rendering the tilde in the file path, which of course will not work. Back in Notepad++, let's remove the tilde and forward slash so the browser will look in the CSS folder in the same folder as the homepage. We still have one more stylesheet link to fix, and we will continue to troubleshoot the issue using the Firefox Developer Edition. Reload the page and look at the files requested in the console tab. In the list of resources, we're looking for a file called custom CSS. This file includes all of the styles for our sample website that are custom for our site and therefore not included in the bootstrap stylesheets. So why isn't it in this list? Let's go back to our HTML and look at the link. There are few problems here. First, this line is missing, the rel equals stylesheet attribute. Without this, the browser will not know to load an external stylesheet. Second, the href is wrong. This is similar to the error we saw with the tilde. And if we were on this page now, the two forward slashes would be rendered within the file path. So we just need to remove those and we're good to go. Save the file and refresh the page. Now you can see all three of our CSS files in the resource list with their proper file paths. However, if you click on any of the other pages in our website, you will see the CSS files are missing. Your homework for this lesson is to fix the rest of the pages in the sample site, including events, schedule and confirmation.

Troubleshooting Missing Styles In this lesson, we will work with styles that are missing from the navbar. We will use the eyedropper tools in both the Chrome DevTools and Firefox Developer Edition to figure out the color codes for the navbar, background, text color and link background color on hover. We will use the rendered HTML and associated styles, and we will even use our DevTools to test styles directly in the browser. Let's open the homepage in Chrome. On the elements tab, make sure you have the navbar div selected, and then scroll through the list of styles to see what has been applied. What we need to do is add a background color that is equal to the color of the text in the page header. That background color is normally handled by the bg styles in bootstrap. And here, we already have bg inverse added to the classes of our navbar div. In the styles pane, you can see that there's no bg inverse style listed so let's add one to custom CSS. But before we do that, let's use the eyedropper tool to get the color of the page header text. When you hover over any style in the styles tab, you'll see a little menu icon pop up. Click the icon and then select add background color. Toggle the color picker on and then position your mouse cursor over the header text, and you can see the RGB value. What's neat about this tool is that you can also see the RGBA value. If you're not familiar with RGBA, the main thing to know is that the A stands for alpha channel, which sets the transparency of the color. Click the down arrow to the right of the RGB color to see the RGBA value. Remember this value and let's add the bg inverse class to our custom CSS stylesheet. To turn off the eyedropper tool, press the hotkey Escape. With custom CSS loaded in Notepad++, from the CSS folder of our sample website, go ahead and add a new style bg inverse. Here, all we want to do is set the background color that we got from the eyedropper tool. Save and reload the page to see our improved navbar. I still think the text color of our navigation links could use a little change. Let's go back to Firefox Developer Edition to look at the link text. We want to make it the same color as the background in the page header. There's also an eyedropper tool here that you can use, so go ahead and click settings and then eyedropper. Hover over the page header to see the color in standard RGB format. If you right click, the color will be copied to the clipboard. Just like crow's eyedropper, you can turn off the eyedropper using the Escape hotkey. Now that we have the color, let's figure out where the style should be applied. Click the inspector tag and navigate to the navbar elements. Let's take a look at the first line item in the navbar. Expand the item to look at the anchor element. In the rules panel on the right, you can see the CSS styles that are applied to the selected element. Using this panel, you can also test out styles by typing them directly into the rules that you want to test. Let's try this with the navbar nav li, a style. Click inside the style to add a line. Type color then press Enter and paste the RGB color code from earlier. As you can see, the style is applied immediately so we can see that this works. Note that you can do this in all four of the developer tools that we're working with. Since this is just a testing tool, no updates are made to our website files so if you refresh the page, your changes are lost. Always make sure you have transferred your work to your actual website files before refreshing the page. Let's go ahead and make our change to the CSS file now. In the custom CSS file, add a new rule called navbar nav li a. Then just simply add the RGB color code we got from the eyedropper tool. Save that and refresh your page. It's starting to take shape, but if you have over any of the navbar links, the text now disappears because it's the same color as the hover background color. This time let's use Chrome to look at the hover styles. Right click any navbar link and select inspect. The elements tab opens automatically with the element selected and the applied styles. If you scroll down the list of applied styles, you can see that there's no hover style defined, so we're free to add one to our nab li a rule. Before we do that, let's figure out what background color to use for the link however. It should be the same color as the text, but use a transparency so that you can still read the text. In that case, we need the RGBA color code for the RGB color, which is what we are currently using for the page header background and navbar text. Let's use the eyedropper tool again to get the RGBA color code that we need. You know the drill by now, click and enable the eyedropper tool and then hover over the page header background. You can see that the RGBA color that we need is 238, so let's go and add that to our CSS file. In custom CSS, add the new rule navbar nav li a hover. Add the background color in RGBA format, but instead of the transparency set to one, which would be fully opaque, let's set it to .1, which would give it a very light transparency. Save and reload the page. Hover over any navbar link to see the hover background color and transparency in action. The last thing we need to fix is the unnecessary white space beneath the navbar. This time, let's use Firebug. Right-click anywhere in the navbar and select Inspect Element with Firebug. If you click on the selected element in the HTML tab, Firebug will highlight the element in blue, show the padding in purple and them margin in yellow. Click the layout tab in the right pane. This shows a handy box displaying the width and height of the selected element. Surrounding that, you can see the padding, border, margin and position values on all four sides of the container. This comes in very handy when you're dealing with size replacement issues. Here you can see that there is a bottom margin of 10 pixels. Let's see what happens if we remove the margin. Back in the style tab, scroll down until you see the rule that sets the bottom margin. If you hover over margin bottom, you will see an icon pop up that allows you to turn off this rule. Go ahead and click that to see if it helps with our extra white space issue. Well, that didn't help, it actually made it worse. So let's reenable the margin bottom rule. This time, let's edit the style like we did earlier in Firefox Developer Edition. And let's replace the 10 with a zero to see what happens. Great, that worked. The style panel also shows where each rule can be found, including the line number. Let's finish up by updating the navbar rule in the custom CSS file. So all we need to do here is change margin bottom to zero in the navbar rule. Go ahead and save that and reload your page. Now we have a perfectly working navbar and it looks great. Keep in mind as we continue to use our DevTools. There's a lot of functionality that is the same or similar in each tool. For example, you can view the rendered HTML and applied styles in all four tools, and you can also edit CSS styles in line for testing. In the next lesson, we will look at troubleshooting styles that are applied to too many elements, and we will start to move away from the homepage and have a look at everything else our sample site has to offer.

Troubleshooting Styles Applied to Too Many Elements In this lesson, we will talk about how to troubleshoot a style that is applied to too many elements. We're going to look at the events page where there's an issue with the paragraph styles. The style for the paragraph in the header should be different from the other paragraphs on the page to display the event descriptions and schedules. Anyway, to troubleshoot the paragraph text, we will use the Firefox Developer Edition and Chrome DevTools to view and highlight HTML elements, their assigned styles and computed styles. Go ahead and open the sample website in Firefox Developer Edition and click the events page. This page lists the events using collapsible bootstrap panels. Click the first event, the Batdude versus Flyguy Q&A panel. Now I'm going to show you a neat trick that will help you view every element on the page that is using the paragraph rule that you can see in the rules tab. In the commandline, type highlight p, and then press Enter. This will show you all of the paragraph tags. If you click to expand any of the other events, the paragraphs inside of those panels are also highlighted. What we want to see is the normal default text within each panel and the header text should remain the same. Now that we know what the problem is, we can turn off highlighting. To do this, type unhighlight in the commandline. There are a lot of other useful commands that you can use here, and you can view them with all of their descriptions by typing help. I highly suggest you explore these commands. They are super useful. Since we want to use the default paragraph style for the paragraphs in the panels, all we really need to do here is to change the existing rule so that it is specific to the h1 in the header only. In the inspector tab, you can see the paragraph element in the header does not have an assigned style but the containing div does. So we can simply change the paragraph style in the rules tab to specify the header class. That looks pretty good, so let's go ahead and add that to custom CSS. Back in our custom CSS file, all we need to do is fix the paragraph style. Once that's done and saved, let's make sure the paragraph styles look good across the entire website. Let's use Chrome this time. Click the schedule page. One thing I should explain here is that the events page let's you register for one event at a time, but the schedule page lists all of the events in a table so that you can select multiple events to register for. We will get to that more in the next module when we look at JavaScript errors. The schedule page looks okay for now. Let's go back and look at the home page. On the homepage, the paragraph text under events and schedule should stand out a little bit more. However, we do not want the text to be as large as the header paragraph text, so we can't just combine the two rules. Looking at the styles panel, you can see that the paragraph font size is set by the body rule. If you have a long list of rules, another good way to figure out where a style is coming from is to use the computed panel. This panel lists the styles, and here you see font size. If you go ahead and expand that, you can see that the body style is overriding the HTML style. So now we know that we need a new rule that overrides body. Look over the elements panel and you can see that this paragraph is inside of a div with a class col md 6. In the styles panel, click the plus sign to add a new style for testing. It automatically uses the appropriate class for the selected element. That's pretty handy. Let's specify the font size as 16 pixels. The style is applied and you can see that it is overriding the font size from the body rule. Now we know what style to use, so let's go ahead and add it to the custom CSS file. In the custom CSS file, add a new rule using the CSS class col md 6 and the paragraph element. Enter the font size of 16 pixels and save. Reload the home page to view the changes. This is now shaping up to be a great website. Next, we will talk about troubleshooting issues with HTML element alignment.

Troubleshooting HTML Element Alignment In this lesson, we will talk about how to align HTML elements horizontally, vertically and centered. We will use the IE Dev tools to view the dom and their applied styles, plus add styles for testing directly into the IE dev tools. Last but not least, I will show you a quick way to view all of the CSS changes that you have created for testing. Open the sample website in Internet Explorer and navigate to the schedule page. Inspect the register button. In the dom explorer, you can see that the register button is inside of a div with a class called registration. This div is outside of the container div, which is causing the alignment problem. We could simply move the register button inside of the container div, but if you drill down into the HTML elements, you can see that there is a hidden div inside of the registration div. This confirmation container div will be used in the next module when we talk about JavaScript. The point here is that a new div is necessary because we need to separate the schedule content from the registration content. Otherwise, we could just put the registration div inside of the container div, and the alignment would be fixed. Instead, we're going to leave the div placement as is and create the registration rule. Since we want the register button lined up nice and neat with the event table, we need to align the div in the center of the page horizontally. When I was researching common CSS errors for this course, this one came up the most. How do I center my HTML element on the page? Let's take a look at how the container div achieves this. Inspect the container div in the dom explorer. In the styles tab, scroll down to see the styles that are applied. What we're going to do here is what I like to call process of elimination. We're going to turn the applied styles off and on to see their effect. That way, we can narrow down the style that we can use to center the registration div. The first activestyle that you should see is the width that is set in the container class that is included in bootstrap. Uncheck the box next to it to remove the rule. Okay, that did not do much because the next rule that was previously overridden is now active. So let's turn that back on and move on. Continue to scroll down, and next you should see the container class. Let's go ahead and uncheck all of the rules one at a time to see what happens. So now we know the margins are centering the div on the page, setting the left and right margins will center the element horizontally, the top and bottom margins will center it vertically. Let's add the registration rule to the IE DevTools to test it out. Select the registration div in the dom explorer. Then in the styles tab, right-click anywhere and select Add Rule. This works the same as in Chrome when we added the col md 6 paragraph style. All you do is enter in the rule as you would in any CSS file. So go ahead and enter registration for the name and then margin left auto and margin right auto. Hmmm, so why didn't that do anything? Remember earlier when we removed the width from the container div? I mentioned that the next width rule was now available because it was no longer being overridden. Go ahead and add a width of 1170 px to the registration rule. Now the div is centered. So in a nutshell, you need a container with a calculated width, plus auto margins to center HTML elements. The auto margins on the left and right need the width of the container to calculate the center point to place the container based on the width. If we wanted to center a container vertically, we would need a height and auto top and bottom margins. And let's just clean this up a bit and take care of the padding. So go ahead and add padding left and padding right of 15 pixels to the registration rule. Now this looks like what we wanted. Before we make this change to our custom CSS file, take a look at the changes tab. This is a really neat little tool that shows you any style changes you have made so you don't have to try to remember them or find them again by clicking around on the dom elements. You can also right-click any rule to copy it, or you have the option to copy all of the new rules. That's really handy, so now we can just paste it into our custom CSS file. In our growing custom CSS file, paste the registration rule, save and reload the page. That's it for this lesson. In the next lesson, we will talk about centering text within a div.

Troubleshooting Centering Text Within a Div In this lesson, we will use Firebug to troubleshoot centering text within a div. We will use the search bar to search for CSS rules. We will also talk about the difference between centering elements on a page versus centering text within elements on a page. Navigate to the schedule page and press F12 to open Firebug. On the HTML tab, go ahead and type h1 in the search bar. The schedule h1 element is highlighted, so go ahead and click on it and the assigned styles are shown in the styles tab. Since this is using the default h1 rule, we now know that we can add a new rule specifying header h1 to override the default rule. Right-click anywhere in the style tab and click Add Rule. Here is where we will test a few different methods to center the h1 text. First let's use width and auto margins like we did in the previous lesson. Go ahead and set the width to 100% and then left and right margins to auto. And as you can see, that did not work. Let's take a look at the layout tab to find out why. Here you can see that the margin applies to the area outside of the border so that would never center text within an element. Looking at the box structure, you can see that the padding is within the border. What would happen if we use auto for left and right padding similar to what we did with margins earlier? Back in the style tab, let's go ahead and update the header h1 rule to add auto padding on the left and the right. Hmmm, that didn't work either. And if you click around a bit, you'll see that Firebug removed the style that you just added. The reason for that is simple. Auto is not a valid value for padding. However, you could possibly calculate the padding yourself. Go ahead and try a few different values in the header h1 rule to see what happens. So as you can see, this would get the job done in the end, but there is a better way. We do not want a fixed center point, which is what would happen if we used padding to center the h1 text. We want something that will auto align the text in the center of any size element or container. So in the header h1 rule, turn off or remove the padding we were testing and add text align center. Now you can see the text is perfectly centered within the header div. So now if you play around with the width of the h1, you will see that the text placement changes based on the width. Just like with centering elements on a page, centering text also requires a width to center the text horizontally. If you're having trouble centering text, you should look at the width of the element and the containing div. If the text is not centering at all, then either no width is set or it is too small and the text is overlapping. That wraps up this lesson. In the next lesson, we will discuss tools to help you troubleshoot the height and width of a div that is within another div.

Troubleshooting Div Height and Width In this lesson, we will talk about troubleshooting the height and width of a div that is within another div. We will look at the header on the homepage and style it a bit more to make it stand out. We will use the Chrome DevTools and Firefox Developer Edition, and I will show you how to use the ruler feature to view the actual height and width of elements in pixels. Go ahead and open the sample website in Chrome and navigate to the homepage. What we want to do here is change the header so that it is the same width as the container below it showing events and schedule. We also want to make the corners rounded so that they look current. Inspect the h1 welcome text to open up the dev tools. Now let's turn on the ruler feature to help us calculate the width we want for the header. Click the menu icon and go to settings. On the preferences tab, in the elements group, make sure show rulers is checked. Now when we go back to the elements tab and click on an element, the ruler is displayed both horizontally and vertically. The ruler shows pixels in increments of 100. If you click on the container div within the Jumbotron div, you can see that there are gray markers that go up to the ruler across the top and the left to show the exact position in pixels. You can also see the width that the container div is set to, so let's try making the Jumbotron just a bit larger. In the styles tab, edit the existing Jumbotron class and add a width. And since we want it centered of course, we need auto margins on the left and the right. And for good measure, let's also add a border radius of 80 pixels to make rounded corners. Now that looks great. Let's open our custom CSS file and add this before we move on. Back in our custom CSS file, let's add the new Jumbotron class. We need to give it a width and left and right auto margins. We will also need to give it a border radius. And while we're at it, let's also give it a top margin so that it's not pushed up against the navbar. Next, let's update the footer so that it is aligned properly. We will use the rulers in Firefox Developer Edition to view the placement in pixels of the footer on the page. To turn on the rulers in the commandline, type rulers. What I like about the rulers here versus Chrome is that they persist so that you can click around and scroll and they're still present. In Chrome, they only pop up when you have an element selected. First, let's take care of the horizontal placement of the footer. So we need a width and auto left and right margins as we know. We won't worry about the image for now. We'll take care of that in the next lesson. So go ahead and add the style to the rules tab. The width should be 1170 pixels. And of course, margin left and margin right set to auto. Before we move on to fix the image in the footer, let's go ahead and add the footer class to our custom CSS file. Set the width and auto left and right margins. Save that and go ahead and reload your page. Note that when you reload the page, the rulers automatically disappear. Now let's take care of the image. We want to display it to the left of the text and have the text centered vertically next to the image within the footer. First let's take a look at the inspector tab at the HTML. You can see here that the image is outside of the footer. If you click on the image tag and look on the styles applied, you can see vertical line is set to middle. What's important to note here is that the image tag itself is outside of the footer. So to display it in line with the span in the footer, we simply need to move the image inside of the folder. Right-click the image, click copy and then select outer HTML. Select the footer element, right click, and then select paste and first child. And just so everything looks nice and clean, go ahead and delete the original image. So now you can see that we have achieved what we wanted, but how? Click the new image tag and look at the rules. Bootstrap is smart enough to know that most of the time, you do want text aligned in the vertical center next to an image, so they went ahead and included vertical align middle in the default styles. If you change that to any other value, you will see that the text changes position. Sometimes when you're troubleshooting CSS, keep in mind that the actual style rules may not be the problem. You can always use the HTML editor to play around with your markup to troubleshoot any issue. This time, instead of updating custom CSS, we need to update the home.html file. So if you don't have it open already, go ahead and do that. Cut the image tag from the bottom of the code and paste it into the footer above the span containing the footer text. Go ahead and save that and reload your page. That's it for this lesson. Next up is a quick review before we move on to the next module.

Summary In this module, we used our four developer tools to troubleshoot CSS. Troubleshooting CSS can be much easier when you know how to use these tools to view applied styles and computed styles, show the container layout and even test CSS and HTML changes directly in the browser without having to update your source files. In the real world, when you're troubleshooting CSS, it's good to know how to use the developer tools for the top browsers so that you can easily fix cross-browser compatibility errors. That's it for this module. In the next module, we will continue to build the sample website and work on fixing errors with the event and schedule registration process using JavaScript.

Troubleshooting JavaScript Introduction Next, let's use our developer tools to troubleshoot JavaScript. You've already seen the power of the DevTools at work with CSS, and there are even more tools to help you troubleshoot JavaScript. Until now, we have only made our sample website look good. Now, we're going to make it fully functional. To experience the full potential of this course, you should already be familiar with JavaScript and jQuery. If you are not familiar with JavaScript and jQuery, there are many courses available on Pluralsight to help you get started.

Troubleshooting Functions Not Firing In this lesson, we will troubleshoot JavaScript functions not firing when they are called. We will use the Chrome DevTools to view JavaScript errors in the console, and the Network tab to view the status of resource requests. We will also use Firebug to view the Document Object Model. To start, you should use the sample website files that are specifically for this module. I have provided you with before and after copies of the sample website for each module, and in this module, we will begin with some new JavaScript errors that I have added, so that you can learn how to troubleshoot them using Chrome, Firebug, Firefox Developer Edition, and the IE DevTools. Navigate to the events page in Chrome. First, we need to fix the page so that it loads the names of the events in the collapsible bootstrap panels. Let's open the Chrome DevTools using the hotkey F12 to troubleshoot. The console tab lists JavaScript errors, and it's telling us that the loadEvents function is not defined. If you click the link in the error message, it takes you to the line that is causing the error in the sources tab. This is a very common error that has to do with the Document Object Model, or DOM. Let's look at the DOM using Firebug. The DOM provides a structured representation of an HTML document in a way that is accessible by programming languages, such as JavaScript. I like to use Firebug to view the DOM because it shows a nice visual representation that's easy to follow. As you can see here, the loadEvents function is in the DOM, so why isn't it firing when the page is loaded? The answer is simple. If you go back to Chrome, and look at the error, you can see that the script causing this error is in the head section. Since this is before the loadEvents function in the script tag at the bottom of the page, then the loadEvents function did not exist when it was called. So to fix it, we simply need to move the call to loadEvents after the loadEvents function is defined. This is a very common error, and the key point to remember here is that the DOM is structured top-down, and you cannot access a function or property via JavaScript until it exists in the DOM. To fix this error, all we need to do is move the line calling loadEvents after it is defined. Go ahead and save that, and reload your page in Chrome. Now try clicking on one of the collapsible bootstrap panels to view more information about each event. You should see that the panels are not working. On the console tab, you can see the bootstrap is causing an error because it requires jQuery. There's also an unspecified error with the GET request for the standard jQuery library. To view the specific error, we can look at the resources requested in the Network tab. The jQuery library is failing, so let's make sure the link is correct. Before we even look at the HTML link in Notepad++, we can get the correct link from the jQuery website. Navigate to jquery.com. We're looking for the URL of the jQuery library that is hosted by Google. We can find that information on the download page. There's a handy list here with links to all of the various content delivery networks available that host jQuery. We want the Google one, so click Google CDN. This link takes us directly to the bookmark in the Google Documentation, so we just need to copy the script link for the version that we are looking for, which is the latest release for version 2. Now in Notepad++, open the events.html file, scroll down until you see the jQuery script tag, and simply replace it with the copied version from your clipboard. Go ahead and save that, and reload your page. Now you should not see any errors in the console. Let's test to make sure bootstrap is working, by clicking a collapsible panel. Great! That's working nicely, so we can move on to event registration.

Troubleshooting Object is Null or Undefined In this lesson, we will troubleshoot the very common object is null or undefined error. We will use the console in our Chrome DevTools to log different types of errors and information, and also customize error logging. Finally, we will compare console logging in all four DevTools. Now let's test event registration. So go ahead and click the Register button for any event. A bootstrap modal shows up, asking for your name, so put that in and click Register. Also notice that the event is wrong in the modal. We will fix that later in this module. On the confirmation page, you can see that we have a few undefined values in the text. The event is also not the one that we signed up for. Open up the DevTools and let's troubleshoot. You can see that the console is not logging any errors, which is pretty common. So, in order to figure this out, we are going to need to implement some error capturing of our own. Let's go back to the events.html file in Notepad++ to add error logging. In Notepad++, I have added some simple error capturing to the confirmRegistration function that is fired when the Register button is clicked in the event registration modal. First, I check to make sure no variables are undefined, and if that is true, go ahead and pass the variables to the confirmation page. If one of the variables is undefined, I added that information to the console using console.log. Logging information to the console is a great way to view the values of your variables at specific points in the script execution, so that you can easily troubleshoot errors. Now let's go back to Chrome and test this out. Refresh the events page and open the console. Then click on a collapsible panel, and attempt to register for an event. Enter your first name and last name and then click Register. Look at the console, and you can see that the information from our console.log statements has been added. The console is a very powerful debugging and troubleshooting tool, and you can log more than just information. Let's go back to Notepad++ and talk about some different types of console logging. Here I've added some addition error logic in the confirmRegistration function. First I added a warning to mark the beginning of the error logging. Then I check to see if each variable is equal to undefined, and if so, adding error to the console, versus just logging the information. To help us figure out why the event is wrong on the confirmation page, the events object in the array matching the eventId will display in the console as info. Let's go back to Chrome and reload the events page to view the changes. Try to register for an event, and view the error logging in the console. First we have the warning that we added to mark the beginning of the error logging, then the standard console logging to display the eventId. Next is the info displaying the object, and you can click to expand the object, so that you can view it in its entirety. And finally, we have the two errors that were logged when we tested to see if the first and last name were equal to undefined. There is one more type of error logging that I want to cover in this course, and that's custom error logging. Let's go back to Notepad++. To mark the end of error logging for the confirmRegistration function, I have added some custom console logging. Console.log allows you to set %s for a string, %i for integers, and %c for custom style. You could just simple type out the entire console.log code for every error that you want to apply a custom style to; however, I like to write a custom function that takes in the message as a parameter, and then logs the error using the pre-defined custom CSS that I added already. Back in Chrome, reload the events page, and attempt to register for an event. Now you can see the custom error marking the end of the error logging. Keep in mind that, using custom errors, you can specify any custom CSS to style console logging to fit your needs. Next, let's compare how this works in all four of our developer tools. Console logging does work in all four of our developer tools. As you can see, Firebug and Firefox Developer Edition both work pretty much exactly the same as Chrome. The IE developer console does support the regular console logging, including warn, log, info, and error, but it does not support custom error logging. Okay, so now let's move on to fix the actual error that is causing the first and last name values to return undefined. Back in Notepad++, let's look at where those variables are set. They're being set using the .text property, and that is the problem. We want to get the value of the input, not the text attribute of the HTML element. There is no text attribute in our inputs, which is why they are returning undefined, so let's just change .text to .value, save, and let's go test. Refresh the events page, and attempt to register for another event. The confirmation page comes up, and now the correct first and last name values are being shown. Plus the console is clean, and does not show any errors. Before we move on, I want to show you where you can find information on other types of console logging. We will fix the wrong event showing up on the confirmation page in the next lesson. The Google Developer API has a great reference detailing all of the different types of console logging that is available. Using this list, and the information that I have provided you already, you can account for any types of errors or debugging information in the console, to help you troubleshoot any JavaScript issue. Keep in mind, when you encounter an object that is null or undefined, you can always use the console to view the object or variable. Previously, front-end developers used JavaScript alerts to help debug code, but if you use an alert to show an object, all it shows is the word object, because it cannot show the actual object itself. That's just another reason why the console is such a powerful troubleshooting tool.

Troubleshooting Incorrect Variable Values In this lesson, we will troubleshoot incorrect variable values. We will use the Chrome DevTools to step through the JavaScript code using the debugger. We will also be able to view the variable values in the debugger, to help us troubleshoot an issue where the wrong event is displayed on the event registration confirmation page. Now let's work on fixing the incorrect event showing up in the confirmation page. In the last lesson, I showed you how to log variables and objects to the console, but in this lesson I will show you how to use the debugger to view the values as the code is being executed. Let's continue working with the Chrome DevTools. Click on the Sources tab, and double click the confirmation.html page in the list of sources to open it for debugging. Scroll down to the JavaScript section, and look for where the eventId is set in the loadRegistration function. If you click on the line number in the gray bar to the left, this will set a breakpoint. Refresh the page, and you can see that execution has stopped on your breakpoint. Click the down arrow to execute the current statement, and move the next statement. Continue to step through the code that is executed in the function GetQueryStringParams, and you can see that the result of each line is output right next to it, and it is returning an eventId value of two. You can also look at the locals in the right pane to view the value of local variables. Set another breakpoint where the event information is output to the div and then click Resume Script Execution. This way, you will not have to continue to step through the GetQueryStringParams function for the remaining variables. Hover your cursor over the events array, and you can see the array detail in a pop-up. Expand the objects until you find the one for the costume contest. Here you can see the index for this event is one, which is the value that is expected when you try to access an object in an array. We are passing the ID value, and not the index value. Let's go back to Notepad++ to fix this issue. Back in Notepad++, in the loadRegistration function in the confirmation.html file, let's simply subtract one from the eventId, which would result in the correct array position, because we are working with a static array for now. We will talk more about how to properly match an eventId with the array index later in this module. Save that, and refresh the confirmation page. When the confirmation page refreshes, we still have some breakpoints set, so the code execution is halted. All we need to do is click Deactivate Breakpoints to remove all breakpoints, and allow the code execution to continue. If you wanted to deactivate one breakpoint at a time, you can just click on them individually to deactivate them. Great! Now the page loads, showing the correct event information for registration. We can also apply the same logic to the singleEventRegister function in the events.html file, to fix a wrong event showing up in the registration modal. That wraps up our work on the event page. In the next lesson, we will move on to registering for multiple events using the schedule page.

Troubleshooting Arrays In this lesson, we will troubleshoot arrays. We will use Firefox Developer Edition to test small snippets of code in Scratchpad. We will also talk about the difference between the Delete operator and Splice method, and use cases for both. Let's move over to Firefox Developer Edition, and navigate to the schedule page. You can see in the event table, there is an extra test event that should not be there. If you look at the JavaScript, in the schedule.html file, you can see that the array is hard-coded, so we could just delete the test record. But, if this were a real world situation, you would be getting data from a data store, so let's take some steps to troubleshoot deleting this test event object. Open the developer tools, and click the console tab. To make this easier to view, let's dock the DevTools on the right. Then click the Settings icon, and then Scratchpad. The Scratchpad is a really nice tool that you can use to test bits of JavaScript before you add them to your source file. So, let's delete the object in the array with an index of four, since the index starts at zero, and the test event is the fifth down in the list, we can deduce that the index of this event is four. Let's also log the events array to the console, so we can view the output. Click Run to execute the script, and you can see that the array has been added to the console. Click on that, and take a look at the indexes in the array. The reason you would not want to use the Delete operator to delete from an array, is because we would end up with a hole in the array, as the indexes do not shift automatically to reflect that change. Let's go back to the Scratchpad and try something different. Refresh the page, so that the events array is repopulated, and then open the Scratchpad. This time, let's try Splice. Another nice thing about the Scratchpad is that it gives you information on the parameters available for any JavaScript, which is pretty helpful. Using this information, we know that the Splice method takes in the position, which we know is four, and the amount or number of items to remove from the array, which in our case is just one. If we left this optional parameter blank, then all items, including and after position four, would be deleted. Run this code and view the array output in the console. So you can see, by using the Splice method, the array has now re-ordered its indexes, so that they are in order. You should always use Splice when removing objects from arrays, to ensure that the indexes are ordered appropriately. The Delete operator should only be used to delete from a single object. Back in Notepad++, let's splice the events array before the events are displayed on the page. Save that and reload your page. So that's a wrap on the Scratchpad. I use it all the time to debug my code, and I like that you don't have to copy all of your code into it. The Scratchpad has access to any JavaScript code that is already loaded in the browser. That's why I didn't have to copy the events array into the Scratchpad, and I was able to execute a few lines of code very quickly to help me debug.

Troubleshooting Array Index Position In this lesson, we will troubleshoot array index position. We will use the Scratchpad in Firefox Developer Edition to test some snippets of code, and the debugger to step through code. We will also log the events array in the console using a table format. By the end of this lesson, you will have a fully function sample website. Let's continue using Firefox Developer Edition. On the schedule page, go ahead and select a few events, and then click Register. A bootstrap modal shows up asking for your name, just like the events page, so go ahead and enter that information and click Register. Unlike the events page, which redirects to a new page, the schedule page displays the confirmation information on the same page by hiding, populating, and un-hiding the confirmation div. Here you can see that the wrong events are displaying in the confirmation, and you should know by now that is because we are using the eventId, and not the array index. Until now, we have fixed that error by subtracting one from the eventId, but in the real world, you would want to match the eventId with the appropriate index programmatically. It would be helpful to see the entire array in a nice, readable format all at once, so let's open up the Scratchpad. Instead of using console.log to output the events array, try console.table, and execute the script. In the console tab, the events array is added as a nice, linear, readable table. That's pretty neat. Next, let's use Scratchpad to test a function I wrote to find an array index by attribute value. This function takes in three parameters, the name of the array, the name of the attribute to search for, and the value of the attribute to search for. Then it simply loops through the array, checks for a match on the attribute value, and when that happens, returns the index of the current item in the array. Then, I have just used my function to get the eventArrayPosition, and logged that to the console. And I have left the events array table, because that will help us troubleshoot. Run this script, and the info is now logged in the console. So now we can see that the current eventArrayPosition is one, and if we look at the table row with an index of one, that is the correct event that we registered for. So now we just need to apply that logic to our source file in Notepad++. Let's go ahead and edit the schedule.html file. In the confirmRegistration function, you can see that I have updated the eventArrayPosition variable to use the findWithAttr function, which I have also added to this page. I passed in the events array, the id string, because that is the name of the attribute we're searching for, and I'm getting the eventId from the data-id attribute of the current input, which in this case is a check box. Save that, and reload your page. Let's use the debugger to set a breakpoint, and step through the findWithAttr function, similar to what we did earlier in Chrome. Open the DevTools and click the Debugger tab. Click on the schedule.html page to load it in the debugger, and put a breakpoint where the eventArrayPosition is set. Now select a number of events, and move through the registration process. When you fire the confirmRegistration function, the breakpoint will be hit, and execution will stop. Go ahead and step through the code, using the Step Into button, or you can use the hotkey F11. This should take you to the findWithAttr function, and before we keep stepping through the code, set a breakpoint on the return command. Then click the Resume button, and execution will again resume until the next breakpoint is hit. On the right, in the Variables tab, you can see the values for all of our variables. As you can see, we passed in the events array, ID attribute, and the value. The return statement is returning the value of one, which you can see here. Everything looks good here, so we can continue. Go ahead and click the icon to disable all breakpoints, and resume to allow the execution to finish. Great! The schedule page is working. Remember that we had the same problem with the array index on the events page in the event registration modal, and also on the confirmation page. Your homework for this lesson is to go back, and apply the same logic to those pages, so that the eventId and index array position are matched programmatically. Now that we have made our website functional, we'll have a quick summary before we move on to the next module.

Summary In this module, we used our four developer tools to troubleshoot JavaScript. Troubleshooting JavaScript can be much easier when you know how to use these tools to view and log errors in the console, step through the code using the debugger, and test snippets of JavaScript using the Scratchpad in Firefox Developer Edition. In the real world, when you're troubleshooting JavaScript, it's very handy to know how to use these tools to debug, especially now that there are so many JavaScript-based libraries available, including jQuery and Angular. In the next module, we will use BrowserStack to test cross-browser compatibility.

Troubleshooting Cross-browser Compatibility Introduction In this module we will test and troubleshoot cross-browser compatibility issues using BrowserStack. Now that we've used our developer tools to troubleshoot CSS in JavaScript, we're going to apply your knowledge of these tools to fix cross-browser compatibility issues.

BrowserStack Functionality In this lesson we will review how to use the BrowserStack dashboard and Quick Launch bar. Then we will configure a Mac and Safari testing environment to load the sample website from a local folder. If you do not have a BrowserStack account you can sign up for a free trial so you can follow along with the exercises in the rest of this course. Okay, so now I'm logged into my account and here you can see the BrowserStack dashboard. On the left you have the option to select from a number of operating systems that run on mobile devices, tablets, Windows and Mac. In this module we will focus on cross-browser compatibility with Windows and Mac but we will cover device compatibility in the next module. In the top left corner of the dashboard there's a Quick Launch menu. Here you can organize the operating systems and browser versions that you test most frequently so that they're easily accessible. You can delete items from the Quick Launch menu by dragging them to the delete bar. To add an item to the Quick Launch menu just select the operating system and drag any browser version down to the Quick Launch bar at the bottom of the dashboard. Go ahead and select the Yosemite Mac operating system and the Safari 8 browser and add it to the Quick Launch menu. Open the Quick Launch menu to verify that it has been added and it has. Now open the Safari browser testing environment that you just added to the Quick Launch. When you first open a BrowserStack test environment you will see an error because we haven't configured it for local folder testing. To do that, all you need to do is click the settings icon in the toolbar. In a real world situation, you would probably turn on Server Testing so that BrowserStack would resolve URLs through your local development server. In this case, we are loading our site from local folders so click Browse and then navigate to the folder where your sample website is located. Please note that you should use the sample website files specifically for this module, located in the demo zip file for this course. Since BrowserStack is pointing to the root folder and we have no index or default page you will see a list of files in that folder. Click on home and let's take a look at how this page functions in this environment. The homepage looks pretty good so let's go ahead and move on to events. And you can see here that the text is not loading. Before we work on fixing it, let's look at how you would use BrowserStack to organize issues.

Real World Workflow In this lesson we will talk about a real world workflow and how BrowserStack helps you capture bugs and track issues including screenshots. These tools will enable you to pinpoint specific issues and code blocks so that they can be fixed quickly. On the events page in BrowserStack, click on the camera icon to load the screenshot and bug tracking tool. You can use these tools on the left to add call outs and text to the screenshot to provide information about the bug. Let's try this out and add a red call out to the empty bootstrap panels. If you wanted to change the color of this call out, you would use the color picker at the bottom of the tools. Let's also add some text to describe the issue to help us troubleshoot later. And also change the color of the text using the color picker. Go ahead and click Save and this issue automatically added to the issue tracker. On the events page, click the issue tracker and your issues will be loaded in a popup. Go ahead and click show all issues. Here you can see a list of all of your open and closed issues. I think that this is handy because it automatically adds the operating system, browser version and even resolution to the screenshot so that you can easily keep track of any issue on your website. If you click on an issue you can view it in a modal and you can download the screenshot. When you finish fixing the issue you would close it and it would be added to your closed issue list. I like the fact that it's not just deleted because it's good to have a history of bugs in case they ever reoccur.

Real World Workflow Continued In this lesson we will talk about a more automated method of testing for cross-browser compatibility using rapid screenshots in BrowserStack. I will also show you how to view the history of any rapid screenshot test that you have previously executed. What we have been doing so far is the BrowserStack live single browser test mode but what if you had a great number of operating systems and browsers that you wanted to test? Testing them all one at a time manually would take a very long time. With BrowserStack you can use the rapid screenshot feature to automatically generate screenshots for any URL on your website in up to 25 testing environments at a time. You can get to the rapid screenshot feature by clicking more and then screenshots. In the URL you will see the URL of your BrowserStack account. While we're at it, let's make sure the server and folder options are checked next to local testing and the folder is mapped correctly to our sample website. Then select a combination of 25 browsers in any version of Windows or Mac. We will cover iOS and Android in the next module. When you have your browser selected, click Generate screenshots. This will take a while to load all 25 screenshots of the homepage so let's come back after it's finished. When the test is finished, you can click on the screenshot thumbnails to open them in a modal. At the top you can see the test environment specs and you can also navigate through all of the screenshots. It looks like we have a few issues with the width of the homepage nav bar and jumbotron. Now go ahead and run the same test on the events and schedule pages. You should see that we have a few more errors to deal with including the text not loading, the header paragraph text color and the page is cut off showing the width is not rendering properly but this one is actually a responsive design issue and we'll cover that in the next module. Another nice feature of rapid screenshots is the ability to view the entire history of any previous test that you have run. Test run with the rapid screenshot tool are not added to the issue tracker but they are always available here in the history and you can download a zip file containing all of the screenshots, or you can share the URL with a team member. In a nutshell, for single browser testing use the issue tracker and for rapid screenshots use the history.

Fixing Cross-browser Compatibility In this lesson we will fix all of the cross-browser compatibility issues that we've found in our BrowserStack test. We will use all of the dev tools that we have learned so far within the browser that we are testing in BrowserStack. Let's start by fixing the issue with the event titles not displaying on the events page. Go back to the BrowserStack dashboard and select the Yosemite Mac OS and Safari 8. Once that loads, navigate to the events page. Keep in mind, your local folder testing settings do not persist between sessions so you may need to select your sample website folder again in the local folder settings. One thing I love about BrowserStack is that you're in a full test environment so you do have access to the browser developer tools just the same as if you were working on your own desktop. Safari has developer tools similar to what we've seen so far and to help us troubleshoot the text not loading let's right click any bootstrap collapsible panel and select inspect element. Let's look at the rendered HTML. Drill down and expand all of the elements in the panel. As you can see, the text in the anchor tag is not rendering but the description and the schedule are rending. Let's go back to Notepad++ to compare how all of these elements are being rendered. Looking at the loadEvents JavaScript function in the events.html file, you can see that the event titles are being rendered using the text attribute of the event1Title anchor tag. Whereas the description and schedule are using innerHTML which renders inside of any HTML element. Let's try changing text to innerHTML for all of the titles. Once that's done, we will save and retest in BrowserStack. Back in BrowserStack reload the events page. Great. Now as you can see the page is fixed. All right, let's go ahead and move on to the next issue. From our rapid screenshot test we can see that the header paragraph text is too light on multiple browsers but mostly on Mac and Safari and Firefox. Go ahead and open a new live test environment for OS X Mountain Lion and Firefox version 45. Font rendering is an incredibly common issue for cross-browser compatibility. Because each browser does not render fonts in the same way you can never fully achieve the same exact font but you can get closer than we are right now with the schedule page header text. Right click the header paragraph text and inspect the element with Firebug. Let's use process of elimination to figure out which style is causing the issue. In the header P class, turn the styles off and on to see which one is the culprit. You'll quickly find that the font weight rule is causing the text to appear lighter than we want however if we turn that off, then the text is too dark. Let's go back to Notepad++ and talk about how to fix this issue using vendor prefixes. Since font weight was causing an issue let's go ahead and remove that from the header P class. We're instead going to fix the font weight issue using a very common font smoothing rule applied to the body. Here you can see that I've used the vendor prefixes for webkit and moz osx. Webkit applies to Safari and moz osx applies to a Firefox browser on a Mac operating system. I've set webkit font smoothing to antialiased which smooths the font on the level of the pixel as opposed to the subpixel. I set Firefox to grayscale which renders text with a grayscale antialiasing as opposed to the subpixel. This is a very common CSS rule implementation that is used to unify font rendering in specifically Safari and Firefox. Let's go ahead and save and test again. If you run a rapid screenshot test again on the schedule page and compare the new screenshots with the previous test that you ran, you can see that the font is now uniform across all browsers. The width issue that you see here on the schedule page is actually a responsive design issue and we will cover that in the next module. So that wraps up this lesson. After a quick review we will move on to the next module.

Summary In this module we used BrowserStack as well as our developer tools to test, troubleshoot and fix cross-browser compatibility errors. Using live operating system and browser test environments plus rapid screenshots gives you the ability to capture issues quickly without having to build your own test environment. It's very useful to be able to use developer tools in all of the browsers within BrowserStack test environments because that way you can troubleshoot easily, fix the issue and then run another series of tests to make sure that you haven't impacted any other browser with the change that you just made. In the next module, we will continue to use BrowserStack to troubleshoot issues with responsive design across all devices.

Troubleshooting Device Compatibility Introduction In this module, we will test and troubleshoot device compatibility issues and responsive designs using BrowserStack. By the end of this module, we will have a fully functional website that will render correctly on any browser or device.

BrowserStack Functionality In this lesson, we will use BrowserStack's responsive test mode to look for errors in the CSS of our sample website across a number of mobile devices and tablets. We will also talk about media rules and how they can help you design a fully responsive website. In BrowserStack, on the dashboard, click more and then responsive, this will open the responsive design testing dashboard. Unlike rapid screenshot testing, where you have to select up to 25 browsers to test, responsive design testing automatically tests all of the most popular devices and operating systems. Let's start by testing the homepage, so go ahead and configure the test to use the sample website from the local folder and then add /home.html to url and then click, view. This test will take awhile to load so let's come back after it's finished. Here you can see our sample website as it would look on an iPhone 5S. The responsive design test mode allows you to test in both portrait and landscape, so go ahead and click, landscape to see how it would look. Landscape looks fine, but in portrait mode, we would want the text to be larger and the event and schedule containers should stack on top of each other and not side by side. If you click on live interactive testing, that will open up a live testing environment for the selected device's operating system and browser. Before you can use this environment for testing the sample website, you may need to configure the local folder setting again, because it does not persist between sessions. Using the simulator test mode, you can use the mouse cursor to scroll the page, just like you would do with your finger on the device's touchscreen. As you can see, this is riddled with problems. We do not have access to the developer's tools here to help us troubleshoot, but if you stop this testing environment and go back to the dashboard, you can open the full testing environment with the dev tools from there. Here in the full testing environment, you can click dev tools to open the developer tools as you would see them in any browser. This is the main difference between the simulator testing environment that we just used in the full testing environment. While the simulator is good to pinpoint problems with the full testing environment, you can have access to the browser dev tools to help you troubleshoot. If you get an error saying that you have too many tabs open, just close the extra browser tabs that you are not using as you would normally on the device. Now we can troubleshoot the issue. Remember we added a width to the jumbotron and now we need to account for the width on any size screen. This can be fixed with one simple line of code. Let's go back to notepad++ to fix this issue. Back in notepad++, you can see that I've added a new rule, that wraps any rule that we have added to custom CSS that set a static width. The media query was introduced in CSS 3 and it enables you to enclose a group of CSS rules within an if statement. In this case, if the screen is larger than 1,200 pixels, then we want to include the custom rules for the jumbotron and footer. If the screen is smaller, then we want to revert back to the default styles included with bootstrap for devices with a smaller screen. Go ahead and save that and let's run another test in BrowserStack. Run another responsive design test on the homepage and you should see the homepage now renders perfectly in portrait mode on the iPhone 5S. Check landscape mode to see how that's working and it looks perfect. Move onto the next device and test in both portrait and landscape mode, so it looks like there's another issue with width here, let's keep going through the rest of the devices to see if this is a problem with just this one or multiple. So, the next device looks like it has the same problem. Let's open up interactive testing to check it out. When the device testing environment loads, navigate to the homepage, no errors here as expected. Now click rotate and let's have a look at landscape view. Hmm, no errors here either. So a good rule of thumb, when at dealing with the responsive design tester in BrowserStack, is always double check E tissue to make sure that there is actually an issue. The system is not completely flawless and sometimes you may need to double check reported errors in the live testing environment. The live testing environments have 100% accuracy while the rapid testing is very close, but I like to error on the side of caution and double check. Now let's go back and do a rapid screenshot test, but this time, include a few devices as well. Go ahead and add a few iOS and Android devices and generate your screenshots. To finish up, test the rest of the pages on the sample site, using the responsive and rapid screenshots test mode. You should see little to no errors left, so we now have a fully responsive website. Another quick way to test the responsiveness of your website, is to open a browser like Chrome and just play around with the width and height of the window. As the window shrinks, you can see that the media rule kicks in and the jumbotron reverts back to the regular bootstrap version without the rounded corners we added. If you continue to make the width smaller, you will see the schedule header and text move under events to compensate for the new width.

BrowserStack Functionality Continued Now let's test the functionality of our sample website across all browsers and devices, to make sure that the event registration process is working on the events and schedule pages. Navigate to the events page in any mobile device live testing environment. Select any event to register for and go through the registration process. When you click register and open the moodle dialogue, you can see that the fields are not lined up properly. Let's go ahead and open up the dev tools and troubleshoot this issue. This is a very common issue that can be fixed easily, in the elements tab, drill down into the moodle content and select the first name input. In the styles tab, enter a new rule and give the input a width of 75% and a bottom margin of 5 pixels. Now click the span, and enter another new rule. In this rule, all we need to specify is, float left. Now the fields are properly aligned, so let's go ahead and add this to notepad++. Add a new media rule and set the max width to 600 pixels because we want this rule to run when the screen is smaller than 600 pixels and enter in the values we tested before in BrowserStack, a width of 75% and margin bottom of 5 pixels, and then also add the rule for the span as well, so that it floats on the left. Save that, and let's go back to BrowserStack. Reload the events page and go through the registration process again. This time you can see that the inputs are nicely aligned in the moodle. Go ahead and enter your name and then click register. When you are re-directed, you may see a 404 not found error. At the time of this recording, this is a known bug that the BrowserStack team is working on. The bug has to do with the query string parameters and the url of a local website. When you test live websites or websites through your local server, you will be able to fully test the functionality of your website. If you see this error, I have provided you with a confirmation test HTML page and the sample website files for this module. So you can either use the confirmation test HTML page or take my word for it, but this page is working properly and looks great. Okay, onto the next page. Last but not least, let's test the schedule page to make sure it's working properly. Go ahead and select a few events to register for and then click register. Enter your first and last name in the now, nicely aligned inputs and click register. Scroll down the page a bit and you can see that everything is aligned and working properly. Great job! Next up, is a quick review before the final course summary.

Summary In this module, we use BrowserStack plus our developer tools to troubleshoot device compatibility and responsive design. Having the ability to test your website on any device is very powerful and the fact that you can test both the responsiveness and the functionality, will help you account for errors that you would otherwise not have found. In this new age of access to websites, via mobile, tablets, laptops and desktops. It is very important that you make websites that are fully responsive to provide the customer or client with the user experience possible. In the next module, we will have a short course summary and I will provide you with some resources that I like to use to help me troubleshoot issues with CSS and JavaScript.

Course Summary Summary In this module, we will review the developer tools that we learned in this course. We will also take a look at the sample website that we started with and list the types of errors that we learned how to fix using the developer tools. Finally, I will provide you with additional resources that I like to use to help me troubleshoot front-end issues. In this course, we used our four developer tools, to troubleshoot CSS. We used these tools to view applied styles, computed styles, and the container layout. We also tested CSS and HTML changes directly in the browser without having to update the sample website source files. In the real world, when your troubleshooting CSS, it's good to know how to use the developer tools for the top browsers, so that you can easily fix Cross-Browser compatibility errors. Next, we used our four developer tools, to troubleshoot JavaScript. We viewed and logged JavaScript errors in the developer console, stepped through the code using the debugger, and tested snippets of JavaScript using the Scratchpad in Firefox Developer edition. Then, we used Browser Stack as well as our developer tools to test, troubleshoot, and fix Cross-Browser Compatibility errors. We used Live operating system in browser test environments plus Rapid screenshots to capture issues quickly without having to build our own test environments. Last but not least, we used Browser Stack, plus our developer tools, to troubleshoot Device Compatibility and Responsive design. We tested the responsiveness of the sample website using Browser Stacks Responsive design test mode, and we also tested the functionality, using Browser Stacks Live device testing environments. Using these tools, we were able to find errors, that we otherwise, would not have found. At the beginning of this course, we started with the sample website that was riddled with problems. We fixed errors such as disappearing text, and missing styles, as well as errors with Cross-Browser and Device Compatibility. Now, you should have a fully functional website, that is compatible with the most popular browsers and devices. Here is some additional resources that I like to use to help me troubleshoot front-end issues: caniuse.com is a great place to search for any CSS property and view a list of browsers that property is compatible with. Rapidtables.com has a RGB color code chart that I've had bookmarked for as long as I can remember. This is useful if you need a color, but you can't get it from a color picker. I use this when I need different shades of the same color to achieve a gradient look. W3schools.com is my go-to place for HTML, CSS, and JavaScript references. This site helps me figure out how to implement code using standard practices. Stackoverflow.com is where developers go to get help from other developers around the world. When you ask a question, you usually get an answer within 24 hours, which is useful when you are on a tight deadline. Thank you very much for viewing this course. I hope you found it helpful for your career in front-end development. If you need additional resources, there're many other courses available via Pluralsight that cover HTML, CSS, and JavaScript as well as Cross-Browser and Device Compatibility.