Switching to Chrom(ium)
Perhaps the most common task for which I need developer tools when working on Web applications is the ability to change HTML and CSS. That is, I see a page, and I wonder what would happen if I were to modify the tag, add a new tag or even add a new style to the tag via CSS. For example, if I were working on the Linux Journal home page, I might go to the "Trending Topics" headline and want to see how I could change it in a number of ways. With Chrome, I don't need to install a plugin; I always can right-click to get a menu over some text. One of the options is "inspect element". This divides my browser window in half, letting me see the HTML source on the bottom and the original site on the top.
If I want to change the text, I can just double-click on it within the lower (inspection) window and type what I want. Obviously, the changes I make aren't saved back to the server, but that's usually not what I want. Changing things within the browser gives me a laboratory within which I can experiment without having to change or modify my server program.
That's not all, of course. I also can change the tags or any of the tags' attributes. So where "Trending Topics" has a class of "title", I was able to change it to "awesome", which, of course, immediately reverted the style to have the page defaults, because no such class previously existed. I can see that right away on the right-hand side of the inspection window, which gives me a live view of the CSS styles that have been applied to the tag in question ("matched CSS rules"). If I change the class back to "title", the matches change accordingly.
Now, the "matched CSS rules" show me all of the rules that have been applied to a particular element, and that's really useful—especially since this list shows me each rule that has been applied and the file in which it was defined. But because of the cascading nature of CSS, multiple rules can apply to an element, and it can sometimes be hard to keep track of which rule was defined where. For this reason, Chrome provides a "computed style" section in that same area of the screen, allowing you to see the final list of styles that apply to a tag and text. You even can ask to see all of the inherited styles, which can sometimes provide additional insight.
The bottom part of the screen isn't just a tag-and-style inspection screen, but the initial tab of the "Chrome developer tools". These tools are constantly under development, and it's a bit of a challenge just to know what has been updated and improved in each version. (Although to be fair, the folks at Google do provide a changelog for each version they release.)
The second tab, after the initial "elements" tab, is marked "resources", and that refers to just about everything you can imagine. Through the list in the left frame, you can get to every HTML element on the page, including images, movies and stylesheets. But if you have been following the development and release of the HTML5 standard, you know that there have been multiple proposed standards for a number of features, including client-side storage. Well, the "resources" tab gives you access to some of these under the "Web SQL" and "local storage" lists. If your application uses these features, you can poke around inside their contents using this tab.
The other tabs are quite useful as well: "network" lets you see Ajax calls, and "sources" shows you which files have been loaded by the browser.
The "profiles" tab does two things. It checks the efficiency and speed of your CSS selectors, and it also checks memory use. The first can be quite useful when you have an extremely complex set of stylesheets, which can take a long time to render. You can optimize your style selectors and also concentrate on creating styles only for those elements that actually need them and which appear on the page.
The "Audit" tab is similar to the famous YSlow tool for Firefox, in that it checks a number of common problems that can lead to slow loading and delivery. Your page will be ranked on a number of different criteria, getting a score, detailed results and a handy red-yellow-green indicator showing how well you're doing on each of these criteria. If you're not sure whether your site is slow, or what you can do to speed it up, this tool can provide some quick fixes or at least advise you as to where you need to concentrate your efforts.
Now, none of these things are unique to Chrome. With the right combination of plugins, I can get all this, and more, with Firefox. But the level of polish, the rate at which these capabilities are expanding, and the fact that they're included by default with every copy of the browser has proven to be very useful in my day-to-day work.
But, that's not the full story. Chrome offers developers the chance to extend the browser in numerous ways, including by adding new developer tools and functionality. For example, I've been using the "Ghostery" extension to show me which external services (from advertising to auditing) are included when I load a page. This is less useful on my own pages than on others, but I actually have learned of several interesting third-party extensions in this way. The Google Chrome store, which is available to Chrome users (and less easily for Chromium users) offers a huge number of extensions—some are aimed at developers, and others are aimed more at end users.
Indeed, the true power of Chrome is in its openness to extensions, which are surprisingly easy to write and which offer a great deal of power to Web developers—either to add new developer capabilities or even to add specialized functionality for clients and users. In my next article, I'll show how to create such extensions and ways you might want to use them.
During the past year, I've found myself drawn more and more to Google Chrome. I finally took the plunge, making it my default browser, and I haven't been disappointed—as a developer or as a user. There are things that I miss, such as Firefox's ability to sync tabs between my Android phone and my laptop, but I can get over that. For the most part, I've found the transition to Chrome to be smooth and easy, and a very worthwhile one at that.
Some basic information about the developer tools is at https://developers.google.com/chrome-developer-tools.
Senior Columnist, Linux Journal
Web Development News
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- RSS Feeds
- Validate an E-Mail Address with PHP, the Right Way
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
27 min 15 sec ago
- Reply to comment | Linux Journal
59 min 37 sec ago
- All the articles you talked
3 hours 23 min ago
- All the articles you talked
3 hours 26 min ago
- All the articles you talked
3 hours 27 min ago
7 hours 52 min ago
- Keeping track of IP address
9 hours 43 min ago
- Roll your own dynamic dns
14 hours 56 min ago
- Please correct the URL for Salt Stack's web site
18 hours 8 min ago
- Android is Linux -- why no better inter-operation
20 hours 23 min ago