Browser Cache

I recently ran into a situation where some of my styles were broken in Internet Explorer 8. What makes this different from all the other times my styles broke in IE8 was that, as far as I could tell, it was correct. Consider the following code: %highlighted { background-color: #ff0; color: #333; } .keyword.is-active { @extend %highlighted; padding: 10px; text-transform: uppercase; } No problem, right? Then why isn't it working? I wasn't sure, until I looked at the compiled CSS and saw something like this: .some-list:nth-child(2n), .is-highlighted, .keyword.is-active { background-color: #ff0; color: #333; } .keyword.is-active { padding: 10px; text-transform: uppercase; } Since IE8 doesn't support the css selector nth-child , it ignores the entire rule . Without looking at the final output, there's no way of knowing if this will happen ahead of time. So what can you do? Well,

In Chris Coyier's recent article, " Fun with line-height! ", he mentions that we often use unitless values for line-height so that it's proportional to the font size. This is only part of the story, and I was reminded of a Stack Overflow question that got me investigating more about how line-height worked with regards to the various CSS units. If you're declaring the line-height on each element, you won't notice any difference. But if you're not crazy and using the first C of CSS (that's 'Cascading', by the way), then the inherited line-height might not work the way you expect. Disclaimer: This is my understanding after doing some research and testing. I may not be completely correct. TL;DR When using a relative unit (em, %), the line-height is calculated based on the font size of the element where the line-height is defined. This line-height is then inherited, unchanged, by each of its descendants. So we end up with a line

I recently had a strange problem after updating SASS. I have a modal dialog with a semi-transparent overlay behind it. For modern browsers, I'm using a CSS transition from rgba(0,0,0,0) to rgba(0,0,0,.5) For older browsers (namely IE8), I'm using some JavaScript to apply the transparency and animate the transition. To make sure the background gets set correctly, I'm using the standard fallback strategy of defining the background as background: rgb(0,0,0); right before the rgba line. This worked fine, until SASS optimized my code by changing background: rgba(0,0,0,0); to background: transparent; The reason? It's 2 characters shorter. Yes, we've now saved 2 bytes of easily compressible text in exchange for breaking my code. Why did it break? Well, if you haven't already figured it out, normally a browser that doesn't support rgba will simply skip that property and move on. But transparent is supported. So now, instead of h

Naming conventions are one of those little things that can become a big thing when you multiply the scale of the project and/or people involved. I was just looking through some code yesterday, and I saw a variable with a fairly typical boolean name that followed the format isObjectState This felt awkward to me, and I took a moment to consider why this is. In Logic, a boolean is a statement that is either true or false . However, this variable name is written as a yes or no question. It is an easy misconception to equate true with yes and false with no , but though they are similar, they are not exactly the same, and, especially as programmers, we should not treat them as such. When we expand our variables into full sentences, the awkwardness becomes more apparent. Especially when we insert them into control structures. Let’s rename our variable to: is this menu item active? So our control blocks will read: if is this menu item active?, then highlight it. while is this men

I ran into the problem, as I'm sure many others have, where I wanted to dynamically assign background colors to my components, but also needed to adjust the foreground color to be readable and visually appealing. It's easy for something to fall through the cracks when changing colors, and then we end up with unreadable text. So to try and avoid this, I put together a SASS function that selects a color for text based on the background color you give it. This also performs checks to make sure the contrast meets a given Accessibility spec (as per W3C rules). So far I've had pretty good results with it. Please feel free to tinker and use this in your own projects. It's far from perfect, but it has See the Pen Calculate Foreground Color by Thomas Pietrosanti ( @Rykus0 ) on CodePen .

I feel like one of the most common shapes that we can reliably create with CSS vs images is the triangle. One of the reasons for this is that it works as far back as IE7 (IE6 works, but doesn't support background-color: transparent ). Another is how frequently a little triangle icon can be used (e.g., ascending/descending buttons, expanding menus, open/close state, etc.) I'm not going to cover the techniques of creating triangles with CSS . That's been done already , and probably better than I would do it. What I'm going to share with you, is a little SASS mixin that I've been using to generate triangles. See the Pen SASS Triangles by Thomas Pietrosanti ( @Rykus0 ) on CodePen . I'm using a SASS placeholder ( %triangle-base ) as a base to contain the common styles. This makes it easy to extend without generating tons of extra code each time I want to make a triangle. When this compiles, it creates a rule that applies to all of th