Using The Ampersand With Compass

While much of working with Compass to generate the CSS for your site is straightforward, there are a few ways to use Compass the provide great power, but are not as easy to understand at first glance. This article discusses one such way, hopefully making it easier to understand.

The operator that we will be looking at first is the & operator. The & as part of a selector in Compass allows you to take the entire selector string at a higher nesting level than the & currently resides upon, and replace the & with that selector string. Typically, when this precedes a selector with a space between the & and the selector, it would operate normally as if the & were not present. However, if you remove the space, it allows you to select elements with multiple classes assigned to them as part of a single selector token.

.menu {
	li {
    	width: 100%;
        color: blue;
        &:hover {
        	color: white;
        }
    }
}

The above snippet of Compass would be converted to the following CSS.

.menu .li {
	width: 100%;
    color: blue;
}
.menu .li:hover {
	color: white;
}

While this is a simple usage of the &, there is a much more powerful way to utilize it. That would be to put the & at the end of the selector. This placement causes the complete parent selector chain to be added to the end of the selector. While it may just seem that you would properly nest your selectors instead, there are a few ways that this becomes important. The most impactful reason that I utilize this form of nesting is due to the need to occasionally target specific Modernizr classes that are added to the HTML element. As a result, if I want to check to see whether flexbox is supported in the browser with the above example, it would turn into something like this.

.menu {
	li {
    	width: 100%;
        color: blue;
        &:hover {
        	color: white;
        }
        .no-flexbox & {
        	padding: 0 10px;
        }
    }
}

The generated CSS would look similar to the following.

.menu .li {
	width: 100%;
    color: blue;
}
.menu .li:hover {
	color: white;
}

.no-flexbox .menu .li {
	padding: 0 10px;
}
Tags:

Related Posts

Jul 3, 2014
2 minutes

== and === in JavaScript and HTML Input Elements

If you read any current information about best practices in JavaScript, you will typically find the following advice somewhere in the list of things to do.

Always use === and !== while avoiding == and !=

While I will never argue against this advice, there are a few things that a developer shoule realize when using === and !== instead of == and !=.

  1. === and !== first do a check of the data type of the two objects you are comparing. JavaScript never forces you to explicitly define the datatype for an object you are creating as it will automatically assign one based on the contents of the object and how it was created.
  2. The output of all of the Math functions produce integers or floats as the datatypes for the resultant numbers. For example, Math.floor(10.39438) will produce 10.
  3. When retrieving the value of any select or input or textarea is always return as a string. This means that even though the value of the string may be a perfectly good number, it will never match a number data type. For example "10" is not equal to 10 when using the ===.

You should always use === and !== instead of == and !=, but you should make sure you understand the datatypes you are dealing with so that your comparison works as expected without any surprises at runtime.

#jquery #responsive-web-design #javascript
Read More
Jan 8, 2015
3 minutes

Write Bulletproof JavaScript

While display issues have long been the bane of a web developer’s existence, current web development projects tend to have much more client side interactivity, focusing ever more attention on the reliability and resilience of the JavaScript you write to deliver the complete interactive experience. Many things can cause unexpected errors in your carefully crafted code.

However, there are a few things that you can do to make sure that your site degrades gracefully and still provides a basic level of functionality when something in the browser goes wrong. The following snippet of code illustrates a few best-practices for defining your JavaScript namespaced modules.

#jquery #javascript #web-development
Read More
Mar 12, 2015
3 minutes

The Number 1 Cause of the Not Invented Here Syndrome

One of the quickest ways to get a new internal tool bootstrapped is to utilize an existing design, making slight adjustments to ensure the design matches the requirements of the current project. Instead of using another internal tool as the basis for the new design, I used a design that was purchased specifically for this project.

This particular design was unique in that there were multiple working examples using AJAX, pure HTML, and AngularJS. While it was nice having supposed working examples, when you start to look at the readme file for how to get this functionality working on your own hosting setup, thats when the niceties disappear. Specifically when lookng at the readme file for AngularJS, it effectively says: “Because this is a well-known JavaScript framework, we are not including any documentation for how it works or how to get started with our design”. Granted, the inner workings of AngularJS need not be covered in the readme, but a simple walkthrough of what to expect this design to do would make things much more user/developer friendly.

#magento #jquery #javascript
Read More