End Point

News

Welcome to End Point's blog

Ongoing observations by End Point people.

Firebug in Action: CSS Changes

When I work with clients, I encourage them to use tools to improve efficiency for web development. Sometimes my clients want styling (CSS) adjustments like font-size, padding, or orientation changes, but they aren't sure what they want before they've seen it applied to real content. I recommend embracing a tool such as Firebug for examining temporary on-page CSS edits. Here's a quick video that demonstrates Firebug in action as I try out a few adjustments to End Point's home page.

Some of the changes I test out in the video include:

  • Font-color changes
  • Deleting DOM elements
  • Padding, margin adjustments
  • Background color changes

Firebug offers a lot more functionality but the video covers interactive CSS changes only. Read more about Firebug's features here. Chrome has similar functionality with the Developer Tools included in the core software. There are similar tools in the other browsers, but I develop in Chrome or Firefox and I'm not familiar with them.

8 comments:

Jon Jensen said...

That's a good idea, Steph. I hadn't thought of having non-developer users try out different things in Firebug purely for experimentation.

After you do all those changes in Firebug, is there any way to save the changed version to disk? I looked around but didn't see a way, and if not, it seems it'd take a while and require painstaking work to track down what you changed and manually copy out all the customizations.

Brian Gadoury said...

Jon, I have looked for, but never found, a way to save those changes. To further complicate the manual mental tracking of your changes, Firebug re-orders any new CSS attributes you create in the HTML -> Style pane.

S.O.S. Steph!

(That stands for Save Our Style, FYI.)

("For Your Information")

("lol")

Steph Skardal said...

A slight clarification on Phunk's comment: Firebug re-orders styling rules based on CSS Specificity, so what you see in Firebug is the specific order of which CSS applies to your HTML (first is highest priority). But Firebug does include the line number of the CSS file, so usually it's pretty easy to find.

However, in Rails 3, because of CSS/asset compiling, Firebug's reference to line numbers in application.css (the compiled file) are not valuable because they do not reference individual uncompiled CSS files. Also, if you are using Sass in your application, you have to do a bit more sleuthing to determine where to make updates.

Jon - in general, I don't make a large number of changes at once via Firebug and backtrack. I typically write the majority of CSS in a shell, then I use Firebug to troubleshoot weird CSS issues, or to make minor adjustments on 1-2 elements at a time.

Brian Gadoury said...

Actually, Steph, I meant to say "Firebug re-orders any new CSS property you create in the HTML -> Style pane." It re-orders them alphabetically after that CSS rule loses focus. I wish it didn't do that, and I wish it highlighted properties-I've-just-modified in a different color.

That's still not as user-friendly as it could be, but I think it would help. Perhaps it's time for me to just Get Involved?

Greg Davidson said...

You can save the CSS changes you make in the Elements panel with the Chrome Developer Tools. It also highlights the lines of CSS that you changed. Check out a screen shot of this in action on the endpoint.com home page.

Steph Skardal said...

Greg - Thanks for the info!

But it still isn't extremely easy to to work with compiled assets in Rails even if you download the CSS.

Brian Dillon said...

Creating a great file structure for your Sass files can help to overcome the lack of accurate code line information.

Sass makes it easy to break up your style sheets into very specific chunks. So if you label them well and have them match up with certain partials then it will be obvious which sass file you need to look in.

Furthermore, the way sass allows for DRYer code through it's nesting intelligence means there is less code to comb through and its better organized then a big monolithic css file. Not to mention that if you set up your main styles and variables correctly you can leaner Sass files that focus mainly on layout and positioning, which can reduce the visual noise of the code in the file.

I personally think that the benefits of SASS and the asset pipeline make that approach more effective in reducing the time it takes to make changes and updates compared to benefit you get from getting a specific code line.

Either way the ability to inspect and make real-time modifications to the css in the browser is a big win with either approach.

Steph Skardal said...

Brian - I'm not disputing the value of Sass here. I think it's great and when I go back and forth from a Rails app to a non-Rails app, I frequently miss Sass.

But what I am saying is that in the context of this article and in a Rails 3.* application, the ideal workflow would not be to make a dozen or so changes on Firebug or Developer Tools, and then try to export and download the CSS.

When I'm working in Rails with Firebug, my typical workflow is to make a few tweaks and apply them to my Sass files, and yes, when they are well organized, it's easy to find those lines.