And now…back to it has to work in all browsers

As we struggled with trying to make advanced designs work in Internet Explorer (6 & 7), I think those of us developing for the web (at least at my job) finally convinced the designers to embrace progressive enhancement. It was a beautiful thing.

Now that we have lots of cool things getting adopted by more and more browsers, you would think, “this is awesome, progressive enhancement for the win!” But instead of designing that way, with fallbacks, we have reverted to the “make it work the same everywhere” mindset and are designing advanced UI with no fallbacks. So, once again, we are requiring javascript to create UI. (I’m not talking about our Javascript technologies like React, I’m talking about needing to code things that can be done in CSS in some browsers but not all.)

Wrong, wrong, wrong.

No, no, no.

I think web designers have a responsibility here that many are failing. They see a design on a site in their modern browser (or that someone used javascript to create) so figure it can be done and they will design something similar. Number one, they should know how the web works and what it takes to code that UI, or number two, if they don’t, they should listen to the people coding up their designs and work with them on graceful degradation or come up with another design that will work the same way everywhere. No javascript required.

Period. End of story. Let’s keep the web fast and make our sites only get better as more browsers implement the good stuff.

PS I haven’t used them much, but I have also decided today that I am going to start recommending using polyfills that can eventually be dumped. (If we are going to be using javascript, anyway.) When I can’t win the progressive enhancement argument. Like, um, most of the time.

Ditch the script, sweetie

So, here I am, feeling a lecture coming out of me. Or a cranky old lady rant? Or some common sense?

You decide.

As you may (or may not) remember, I am an html/css specialist. Javascript is for interactions. That’s my philosophy. You click on something, you do whatever you need to do on the back end, add a state class to a DOM element, and use CSS to handle the rest. Like hiding/showing/transitioning.

Lately, at work, I’ve been given designs that are impossible to realize using just CSS. But because I’m anal about not using script for layout, I try my darndest to make it work that way, first. Trying everything I know, googling for ideas, trying new things.

Sometimes I get up A LOT from my desk to take a walk. That’s what happens when my mind is stretched. It needs a lot of clearing.

I tell designers that this is not good. But they see these kind of designs out in the wild. (Thanks a lot Pinterest and Google+ and all the rest of you – you know who you are.) So my arguments don’t hold up. And other developers are on board, too. We can do this, yes we can! It’s a mindset of being up for a challenge. I love a good challenge myself. But not at the expense of compromising the code.

Has anybody ever thought about these things….?

If we create designs that are easy to code, we would be done with web UI in a fraction of the time.

If we create designs that are easy to code, it would cost way less money to develop and maintain them.

If we create designs that are easy to code, we have code that is really solid, and less error prone.

If we create designs that are easy to code, our code would be more lightweight, loading faster, which is important for mobile.

Plus web-friendly designs leave more time to make sites responsive, animated (not over-animated), and to focus on content, which is king.

Personally, I think all this stuff makes a website really cool!

Keep it simple. That is – and will always be – my motto.



Get out of that midcareer slump!

I was chatting with another old lady the other day and I was surprised to find out that work is “just a job” to her and that she works hard everyday not because she loves her work, but because she’s doing what she can to stay employed.

I think a lot of people end up in that state after racking up more than several years of working, probably even more so if they’ve stayed at the same company for all those years. (I may or may not be speaking from experience.)

Year 1 of employment: "Alright! Let's see what cool stuff I'm going to do today!"When you’re young and just starting out, you’re excited about the prospect of things you could accomplish…you’re promised a lot, and people have faith in you because you’re young and fresh and excitable.

After a few years under your belt, you start learning that not everyone is young and fresh and excitable, and that many people actually just want to do whatever the business needs from them so they can get home and do what they really love. So instead of spending your Years 5-10: "Ok...let's see what my boss wants me to do today..."time trying to convince people that something would be really cool to do and it will make a difference, you end up just doing whatever people ask, because it’s just less trouble.

You start to get really good at doing whatever people expect because it keeps things moving along, and at some point you wonder why you even bothered to try harder in the first place, because there are plenty of other cogs that Year 11 and beyond: "Let's see how long I can sit here without anyone realizing I'm not doing any work"slowly move together to keep the machine running. It’s not worth one cog to be bigger and more efficient, because the machine only works as hard as the least hardest working cog.

So by the time you’ve become a “seasoned” worker, you don’t have any reason to do things like push back against status quo or sit in long architectural debates with even more seasoned people, because you know you’ll lose anyway, and all of that stuff in the end doesn’t matter, since all you’re doing is collecting a paycheck from a place that doesn’t value your opinions or ideas, and is slowly starting to realize that you cost more money to them at your advanced age and salary level than two or three kids fresh out of college. Depressing.

So what can we as old ladies do about this, before our desks and laptops get soaked with drool?

Don’t forget where you came from. You were young and fresh once. You can get back there, just keep learning and keep your skills up-to-date. You have something that kids fresh out of college don’t have, and that’s experience. You know what’s worked, and you know some tips and tricks that can help others. Share your insights, even if you think people aren’t listening, because eventually people will. Don’t give up.

Find or start a network. There are people out there just like you. Some managed to get themselves past their midcareer slump, some are still struggling, some gave up. Listen to their stories and advice and you can learn what’s worked for people and what hasn’t. Maybe you can help others along their way also.

Love what you do, and if you don’t love it, don’t do it. I watched Jiro Dreams of Sushi and it was such a beautiful documentary about sushi and one man’s passion for it. It’s rare that you end up in a job that you love, but if you do, don’t let it go. Life is too short to work at job that makes you unhappy. I know people might not have a choice to change jobs or careers, but it will probably be worth the struggle if it means longer and more potential happiness in the future. Somethings aren’t worth the pain, so if your cons outweigh your pros in the career you’re currently in, it’s never too late to change. There’s some good reading about this in this HBR article.


No, there’s nothing wrong with just feeling like your job is “just a job”, because that’s what it really is. But if you’re like me and have the bizarre expectation that you could be happier with your job, then don’t sit around and get unhappier, do something about it.



Multi-line ellipses with max-height

If you have a fixed height on a text area, the options for multi-line ellipses are a little complex – a javascript solution, or this float-drop solution.

But what if you are using max-height?

Turns out the solution is easier!* You just need to absolutely position an ellipses pseudo element at max-height minus the height of the ellipses from the top (eyeballed, I didn’t set a height on the ellipses when I tried this, but you could). And they won’t show if you your content doesn’t reach the max-height you set on the element.

Here’s the code:

<div class="content">This is some shorter content.</div>

<div class="content">This is some longer content. See the ellipses? There they are, in the bottom right-hand corner.</div>

.content {
box-sizing: border-box; <--I usually set this globally
position: relative;
max-height: 3.75em;
overflow: hidden;
padding: 0 5px;
/the rest of these are just for demo purposes/
float: left;
width: 200px;
margin-right: 50px;

.content:after {
content: "\02026";
position: absolute;
top: 2.4em; right: 5px;
width: 3em;
background: linear-gradient(to right, rgba(255, 255, 255, 0), #fff 50%, #fff);
text-align: right;

Head on over to codepen to view.

*There is one use case where this falls apart, and that is if your content height exactly matches the max-height. This might be enough of an issue that you’d want to go with a javascript solution. 

Who reading this votes that CSS should give us a multi-line ellipses property?

New-fangled Front-End Development

There once was someone I worked with – who knows, he may read this – who said software engineers are ruining the web. I think the comment was motivated because he was showing me a page that was rendered with javascript and I asked him how it loaded, performance-wise.

There are some pretty smart people writing some pretty smart plugins for some pretty cool interaction patterns and also for helping to hide the complexities of cross-browser javascript. For me, in my prototyping role, I like that. I like that a LOT.

Kid: "Daddy, can you help me with my homework? I have to make a web page about ladybugs." Dad: " Of course, sweetie."But here’s what I don’t like. Where I once was able to download a set of files and plop them in a directory, whole install / build processes have been created to do essentially the same thing. And I’m not sure why. To me, that’s like handing control of your project over to someone else who has decided for you how you should set it up. And when developer of x plugin installs dependencies that conflict with developer of y’s plugin and with your version of Gulp, then you are screwed. Now you need to spend time untangling the mess. And if you’re like me, and you aren’t into writing your own build tasks, you are pretty much in a pot of hot water.

Here is an example. I just want that minimized js file. That’s all. Only it comes with all this other stuff…

file structure

Here’s the workflow I prefer.

1. Buy Codekit. The developer has done some pretty terrific work here and answers support questions and keeps things updated. Your browser auto-refreshes with each change you make. You can make use of autoprefixer, minimizers, syntax checkers. It really is a great piece of software. (There is also Prepos, which runs on Windows. I used to use that before another developer pointed me to Codekit.) Also, as someone who has used a gulp/watch task that a developer set up for a project, Codekit is much more robust. It doesn’t exit if you run into a syntax issue – and it is way easier to read the error log. Save the files in the wrong order when using Gulp and BAM! The process comes to a screeching halt and you have to restart your server/build tasks.

2. Download javascript files for the plugin you want to use, and link them into your files via a script (and sometimes a css) tag. It’s really not that hard. Sometimes these javascript files are hosted on CDNs (content delivery networks) but I’ve had stuff stop working on me, so I prefer to download my own versions and make sure things don’t start breaking as time goes by.

And number 3 is for the plugin developers.

3. KEEP IT SIMPLE! Don’t create stuff on top of other dependencies. Don’t require a certain compiler. Make your stuff work with Codekit and maaaaaaannnnnnnyyyyyy more people will be using your plugin. People like me, who prototype, who live in the design world more than the developer world. Make it easy for us. Please! Don’t complicate the web! You aren’t making it better with your complicated processes. You are only making it better for a small subset of people. Other front-end devs like you. And there are a lot of people that can benefit from your brain and your creations if you’ll KEEP IT SIMPLE!

Thanks for listening.

10 Hours Later...Dad: "Alright! We are almost there! I got Node running on Heroku with a MongoDB that's going to house your content. Now, I pushed everything to GitHub. so if you need to make edits, you need to create your own SSH key and upload that to GitHub. But before that..."

Yes, I know, it shouldn’t take a developer 10 hours to spin up Node and Mongo on Heroku, it just feels like it when you’re striving for simplicity.


Yes, ladies, we can do math!

I always get excited when I have to use math when I’m programming something, because then when my kids get old enough to complain “Augh, math?! When am I ever going to use this?!”, I’ll actually be able to tell them, “Hey, I actually use math at work!”

Ok, so this particular time it wasn’t something for work, but it’s still math! Here’s the basic problem:

Starting with a spider at point A, swiped to point B, how do you determine a point C offscreen where the spider ends up after being swiped?

This is how I solved the problem using…GEOMETRY! If you have two points, you can calculate the slope (m) and then use the same slope equation to find a y value given an arbitrary x. Here’s the equation to find slope between two points (x, y) and (x1, y1), in case you’re too lazy to google it:

m = (y - y1) / (x - x1)

So using that, we can calculate the slope of the line we create when we swipe the spider from A to B:

m = (A.y - B.y) / (A.x - B.x)

To figure out where point C is, let’s choose an arbitrary x value for C based on the direction of the swipe, and use the same equation to solve for the y value. In our picture above, we’re swiping left (A.x > B.x), so let’s say that C.x is at a position 100 pixels off the left side of the screen, or -100. If we’re swiping right (A.x < B.x), then let’s say that C.x is 100 pixels off the right side, or screensize + 100.

So now that we know the slope and the new x value, we’ll just reswizzle the slope equation above and solve for the new y value:

y = m * (x - x1) + y1

And in our case:

C.y = ((A.y - B.y) / (A.x - B.x)) * (C.x - A.x) + A.y

Here’s a CodePen using the same math I used above. The CodePen example constrains the spider to a box on the page, so I had to take that into account when writing the javascript. Another issue I had was that if your path was a vertical line, the slope ends up being undefined and calculating the y value ended with a value of “Infinity” or “-Infinity”. Did you even know that Javascript had these constants (Number.POSITIVE_INFINITY and Number.NEGATIVE_INFINITY)? I didn’t. Well, now we both know. 🙂


I actually really loved math in school, especially geometry in 7th grade, because we got to use rulers and compasses to draw graphs. There really is a lot of math you can use when you code, so keep taking those advanced math classes, ladies!

Gladys’ Old Lady Survival Guide for Meetings

I’ve been in many meetings throughout my career, and I’ve learned quite a bit about how to survive a long meeting and how to get yourself heard (despite being female! Gasp!). Here are a few tips to take to your next meeting so you don’t end up sitting in the back and being forced to take notes. Or get a man a soda.

Interrupt people. It’s ok. Really.
Google Chairman Eric Schmidt got some flak on the internet for interrupting USCTO Megan Smith during a panel at SXSW. Women can’t be heard because men constantly interrupt them. And women who try to be the interruptor themselves end up being seen as pushy and aggressive. Well, I’m here to say, it’s ok to interrupt people, people! You just have to do it in a way that makes the other person feel like they interrupted you:

Man: "...So how we will differentiate ourselves in the marketplace--" Woman: "--that's nice, but..."

Man: "!" Woman: "Oh, no, I'm sorry...go ahead..."

Man: "Oh no, you go ahead..." Woman: "As I was saying..."

Reiterate someone else’s good idea and make it your own.
I’ve actually had this done to me many times in meetings. Except that the person actually disagreed with what I said, but to make it seem like we weren’t in conflict, he said we were actually saying the same thing. It was bizarre. But in any case, the last person that states some big idea is usually the one that people attribute the idea to. So grab that last great idea you heard, reiterate it, and make it your own! Nothing wrong with that!

"I think we're both saying the same thing...let me reiterate so everyone understands..."

Even if you’re not paying attention, make sure people think you are.
This is pretty funny, because people say this ALL THE TIME. And no one seems to catch onto the fact that muting has nothing to do with listening. But, people buy it because they don’t want to contend with technology being the reason you couldn’t answer the question posed to you.

"Sorry...can you repeat that? I was on mute..."


No, of course I’m not being completely serious! Sometimes you have to let a little humor into your life to survive the daily grind. Life is too short to get hung up over whether an entire gender is out to get you or if maybe you’re just taking life a bit too seriously.

Getting Sassy

I’ve been learning a lot of new things at work these days. A LOT of new things. As a matter of fact, I’ve been waking up thinking of code. This. has. got. to. stop. I just had a couple of books come today from Amazon, so I’m looking forward to taking a break from the code and diving into them tonight.

But first, I want to write this blog post about SASS. It just really blows me away how much power it has. I came to SASS from LESS. I thought LESS was enough. But, now that I’ve seen the power of SASS, and now that I’ve seen how complex stuff other people have written that I’m trying to “install” is, I’m looking forward to writing some plain ol’ mixins and functions that can be plopped into a directory on my site without needing to go through some huge front-end dev complex install/build brouhaha. Kind-of like how I’ve always used jquery plugins. Pull them down from the web, plop them in a directory. Link to them. I like it like that. (Expect a future post from Gladys and I on this whole new era of front-end dev complexity.)

So, in preparation to go a little deeper with SASS, I decided I should learn all the parts of the language first. And there were many places I went to for that, and wound up taking copious notes and trying things out. I figured I’d share, because I’ve written them up in a different order than the official SASS documentation. And I’m sure I’ll be revising things as I learn more, but here is where I am with this right now.

SASS documentation, Gertified

As far as I can tell, the .sass syntax isn’t used much. One site said nobody uses it. So all this is based off of the .scss syntax.

And stuff in blockquotes is from the official SASS documentation (found at


  • Used to import other .scss files and partials into a .scss file.
  • Put these statements at the beginning of the file, in the order you want them included. It is also possible to nest them in a selector, but that restricts what is allowed in them.
  • Use the correct path to file.
  • _partial.scss – files beginning with an underscore aren’t compiled to .css files.
  • Don’t include the underscores for partials nor the .scss extensions in the file names.

& (the ampersand)



The & is replaced with the parent selector. In addition to what is shown above, you can also do this:




This can come in handy for flattening CSS specificity while still making it so you can group your selectors. It writes the selectors inside it out to the root level of the document. You can also use it for single selectors, like

@at-root .section-head { … }.


Read more about @at-root, here: There are also “with” and “without” modifiers when using nested directives like @media queries, which can be nested in CSS rules and inside each other. The latter will result in a combined media query…

@media screen and (orientation: landscape)


SassScript allows you to define properties using variables, math operators, functions, etc. Following are the features of SassScript…


  • Variables are scoped to the container they are defined in, unless you use the !global flag.
  • Variables defined outside of any selectors are global.
  • You can use !default after a variable assignment, which will make the assignment as long as the variable wasn’t already assigned or has a value of null.


Note the #{ } interpolation syntax, which allows you to use the value of the variable as part of a selector or property name. When using interpolation, quoted strings are unquoted.

It’s also possible to use #{} to put SassScript into property values. In most cases this isn’t any better than using a variable, but using #{} does mean that any operations near it will be treated as plain CSS. For example:

p { $font-size: 12px; $line-height: 30px; font: #{$font-size}/#{$line-height}; }

is compiled to:

p { font: 12px/30px; }



If a mixin doesn’t contain any arguments, or isn’t passed any values, you can omit the parenthesis.



You can extend a placeholder or a CSS selector. The % syntax defines a placeholder. It is not compiled to actual CSS, it is only valuable if used. But it allows you to extend a set of styles without basing them off of another selector. It’s sort of like a variable for a set of styles. In this example, column also extends sidebar, which means it picks up those styles as well as the stretch placeholder styles.

extend placholder

Extending makes use of selector combining so, if you don’t have to pass variables, use placeholders instead of mixins for repeating chunks of styles to generate less code in the compiled CSS.

You can’t extend concatenated selectors:

extend error

However, you can do stuff like this:

extend complexity

You can play with this stuff at to try and wrap your head around the nitty gritty of @extend.

The !optional flag after the extend is supposed to make the extend fail gracefully if there isn’t a class found to extend. No CSS was output in this case.

extend optional

My thought is that for best practices – and understandability and maintainability – keep those extends simple! As I always say, just because you can do something doesn’t mean that you should.


  • Functions are like mixins, only they return a value rather than styles. And you can do lots of processing in them.
  • Functions are called without the @include statement that mixins use.
  • Functions can be called with or without explicit keyword arguments. Keywords come in handy when you have a long list of arguments to pass and/or don’t want to pass all of them. (Named arguments can be passed in in any order.)


There are lots of built-in functions, too lengthy to list here. But these are the categories of functions:

  • Color functions – for manipulating RGB, HSL, and opacity values
  • String functions – a lot of these are similar to javascript string functions
  • Number functions – again, similar to what javascript offers for numbers
  • List functions – for manipulating lists of values, traversing, replacing values, joining two lists, etc.
  • Map functions – all list functions work on maps, too, treating maps as lists of pairs. Plus there are some additional map-specific ones.
  • Selector functions – work on CSS selectors, still trying to wrap my head around this.
  • Introspection functions – these really help you figure out if features, variables, functions, other things exist, or what type of data you are working with
  • Miscellaneous functions – there are only two if() and unique-id()

See all of them here:


SassScript supports seven main data types:

  • numbers (e.g. 1.21310px)
  • strings of text, with and without quotes (e.g. "foo"'bar'baz)
  • colors (e.g. blue#04a3f9rgba(255, 0, 0, 0.5))
  • booleans (e.g. truefalse)
  • nulls (e.g. null)
  • lists of values, separated by spaces or commas (e.g. 1.5em 1em 0 2emHelvetica, Arial, sans-serif)
  • maps from one value to another (e.g. (key1: value1, key2: value2))
Hint: always quote interpolated named colors if they are meant to become part of a selector.



  • +, -, /, *, % (addition, subtraction, division, multiplication, modulo) – these can also be used on colors
  • expressions are evaluated left-to-right, with multiplication and division taking priority over division and subtraction. You can also use parenthesis around operations to add clarity. Spaces are not required but also can add clarity.
  • You can’t multiply two pixel values together- e.g. 2px * 2px
  • When multiplying percentages, leave off the % – e.g. use $width * .75 instead of $width * 75%


A special note on division. Since CSS supports the / in separating numbers (as in font-size/line-height), There are rules to make it used as division. When in doubt, add parentheses!



Equality (for all types)

== and !=

Relational (works on numbers)

<, >, <=, >=


and, or, not


  • The + operator works to combine strings
  • If you combine a quoted and unquoted string, whichever comes first determines what you wind up with (quoted or unquoted).
  • If two property values are concatenated, they are concatenated with a space in between them.
  • Interpolation can be used to place dynamic content inside a string (null values are interpreted as empty strings)

string concatenation


Many of these have been covered already, but here are some more…

@debug, @warn, and @error that you can use with complicated SASS to help you debug.

@supports, but this is for the future (when CSS supports it, haha), to allow you to wrap CSS in @supports curly braces to supply alternate styles. For example:


@if, @else, @for, @each, @while – these are like javascript control structures

The if() function is a shortcut for a simple @if/@else. Like so:

if function

You can pass content (stuff inside curly braces) to a mixin and specify where it goes in the mixin with the @content directive. The classic example is a media query mixin:


Is there more? Yeah, there’s more. But this covers a lot of it. Go, read, play in Sassmeister and learn. There is great power here. Be safe!



Phew, that was a long post, huh? Well, I am known for my gift of gab. I do have to apologize, though, this post isn’t fully accessible because I used a lot of SassMeister screenshots. It was the easiest way. Please use the official Sass documentation if you need a more accessible reference.


CSS is Stylin’

I’ve been writing CSS for a long time. I’ve gone through many revisions of how I write it. It’s interesting how it has evolved over time.


Like not using underscores in class names because they caused issues in some browsers (I can’t remember the particulars, that was awhile ago).

Like putting all properties on one line with tight spacing. This had the dual effect of being able to see more related classes without scrolling and keeping the file size down. (Now with preprocessors that can minimize your files this is a non-issue.)



Instead of this:

.title {
  margin: 0;
  padding: 0;
  font-size: 24px;

I know, most people hate the tight one. But you got used to it, really. I did it that way for years.

Like using ids instead of classes for layout elements (e.g. #banner instead of .banner) until I learned that that the developers at my company needed to use ids for javascript handles. Ids also make the css have higher specificity. So now I use classes for most styling.

Like using object-oriented css (OOCSS) and making use of inheritance.

Like taking advantage of existing elements instead of classing everything.

Like writing a lot of reset styles.

Like nesting a lot of LESS styles to see the structure of a component.


I saw unintended consequences of some of the choices I made.

A guy named Matt showed up at my company and started questioning some of my ways. (This was a good thing. Hi Matt.)

I found SMACSS. Or maybe Matt did. Not sure, we read a lot of the same stuff.

And this style guide.

And it was funny, reading these, that their styles have also evolved, and that some of what they do I do, too.


Here’s where I am with my CSS. Which is some of what I have learned along the way, some new stuff, and some still-to-be-determined-if-it-sticks stuff.

I write minimal reset styles. I found that aggressive reset styles force you to write more overrides. And there was one issue with Internet Explorer where if you set a property, it could never be set back to auto. I can’t remember which property that was, sorry, it’s been awhile. But I’m guessing it was an issue with buggy IE 7.

I format CSS the way the rest of the world does. But I group my properties in a certain order, which makes it easier to find them when there is a big block of them. Like box model styles first, then visual styles, then fonts, etc. If I weren’t working with other people, I’d most likely also lump some of them on the same line, like so:

  position: absolute;
  top: 0; left: 0;
  width: 100px; height: 100px;
  border: 1px solid #eee;
  font-size: 12px;

I use more classes. I got in trouble with OOCSS and using elements instead of classes. So now I follow the SMACSS guidelines of creating a component where the name of the component is in the child styles. At least for the main child components. This also allows me to flatten my CSS. And it’s the opposite of where I was, trying not to class everything. I’m not sure where I’ll ultimately land but, for now, I’m leaning towards adding classes. It seems to be more future-proof.

So now I’m doing this:

.section { … }

.section-header { … }

.section-body { … }

instead of:

.section { … }

.section h1 { … }

.section div { … }

Yeah, you can already see the issues, right? .section div { … } is not smart. I wasn’t usually that generic, but for a small component where I thought there would only be one div or span or link or image, I fell into this trap. And usually got burned.

I use the is- prefix for state changes, like .is-hidden, .is-selected, etc. And ids are only in the html, for javascript / aria purposes.

I use a namespace for styles I create, so they don’t clash with any css I bring in externally. Like gert-btn, gert-heading, etc.

I’m trying the SMACSS l- prefix for layout classes. The thing is, I feel like sometimes the layout / component dividing line is gray, and I’m not sure I want to take the time deciding which bucket to put something in and then wishing I hadn’t. So this one is kind-of experimental at this point.

I comment, comment, comment. That’s one thing that’s never changed, since I was a young whipper snapper cranking out code. Only now I mix /* */ comments with // comments. The latter are used in LESS and SASS and don’t get written out to the final CSS file. Sometimes I want a comment to wind up in the CSS, but usually the disappearing comment is good enough. It just tells someone else – or reminds me – why I did something the way I did. I also like using them at the end of code blocks, in case indenting gets messed up. I really hate spending time finding matching braces. I do this same code block commenting with html comments.

Also, with preprocessors, I’m starting to put media queries right near where the adjustments need to be made.

And I’m using variables for colors, typography, and oft-reused styles, like standard padding. But I’ve seen this overdone, too, with variables for everything you might possibly want to change and variables using other variables. It can make things way more convoluted than they should be. But variables are great for theming!

Lastly, instead of integrating hacks – because there aren’t many needed anymore – I’m starting to use a hacks.css file. Or, as some like to call it, a shame.css file. Its for things you put in place in a hurry that you know can be done a better way but you just haven’t figured it out yet.

You know of what I speak.

So, do you think about your CSS? Or do you just write it any old way? I feel like having a system makes coding simpler and faster and easier to maintain.

Only don’t get set in your ways! Because there are always things that work and things that don’t. And things that change over time with browser and CSS capabilities.

Now go get stylin’!


You’ve got to try your own thing, I know, but it’s still worth listening to your elders and learning from their experience of what works and what doesn’t. And elders can also learn from the youngsters and their new ways of doing things. People who are open to learning and sharing make better coders. They make better everythings, really.


CSS Selector Behavior

Well, no matter how long you program CSS, you can get tripped up by the most basic of things. Today it was psuedo element selectors. I wanted to style the placeholder text of an element to be accessible. That meant I needed a darker color. So I did this:

   color: #666;

And it didn’t work. And I couldn’t figure out why. So I looked again at the code I created, and started eliminating things. I was in chrome, and so I did this:

   color: #666;

And it worked!

So I then I did this:

   color: #666;

And it didn’t work. So then I looked at some code on a site that did work. And I saw that they did it like this:

   color: #666;
   color: #666;
   color: #666;
   color: #666;

And so I did the same. And it worked. And I scratched my head. And then I stumbled across this explanation (scroll down to Chris Coyer’s comment).

Oh, good gravy!

We are so used to being able to list styles with browser prefixes, one after another in one style block, and ones that the browser doesn’t recognize get ignored. But this is not the same with element selectors in a group.

It was a trippy morning.


This post was duplicated from another blog of mine. From now on, I’ll be posting web help here, on this blog.

By the way, Urban Dictionary says “trippy” is a relatively new word with its roots in the word “trip,” from the 60s. That’s wrong. The word “trippy” comes from those days, too. Sheesh. Well at least all of you who think that is a new word don’t need it explained.