Monday, 14 October 2013

Is SASS making us over-specify??

So one of my bug bears is over-specification.  Why put in a bunch of classes to target an object when just one or two will do?

Over-specification causes:
  • bulky CSS
  • reduced re-use (if it's too specific, then nobody can reuse it, right?)

So I'm a card-carrying, flag-waving under-specifying CSS user.

And then along comes SASS.  SASS who wants you to encapsulate.

.myClass{someStuff:0;
    .ooAnotherSelector{someMoreStuff:0;}
}

Which compiles to:
.myClass .ooAnotherSelector{someMoreStuff:0;}

And while it's all kinda neat and cute and grouped in the .scss file, in the CSS file it comes out as over-specified annoyances.  Well, at least as far as I'm concerned.

The trouble is, the encouragement is to do this, and the compiler can't be modified to tell whether it needs that level of specification or not.  I'd like to tell it to rip out the non-required selectors, but how does it know if they're required or not.

Sigh.


Wednesday, 4 September 2013

Font licensing: a plea to designers

So, far be it for me to tell designers which fonts to use in their creations.  They have constraints I can't even begin to understand - brand, communication, etc.  But if they expect me to be able to take the lovely design and create a website out of it, especially for a high profile (read 'sueable') client, then I am going to have to be able to use any font they've chosen with the appropriate license.

Because we're all about @font-face these days, are we not?

Recently I get a design through - gorgeous design - using a font that's so expensive to use on the web that we have to substitute it for a cheaper alternative.  All good - client agrees.  Get to UAT (user acceptance testing) phase and suddenly it's all 'but the font doesn't look the same as on the PSD'.  DISASTER!!!

Yes.  That's correct.  Because it's NOT THE SAME FONT.

So.  Designers of the world?  Please check the licensing of the fonts you use.  It will make my job much easier and ultimately the client much happier.

And isn't that what we all want?

(the happy client)

(although my job being easier is good too)

Wednesday, 28 August 2013

Why I hate !important

So you're dealing with legacy code.  You've got to apply a new skin, and that's what CSS is all about, right?  Applying a new stylesheet and whaboompf you have a new spanky site with little to no HTML changes (see Zen Garden for a good reference).  Fabulous.

Occasionally you come across a site that's been built by a developer who hasn't figured the semantic thing out, and you find you're making declarations like:

.blue{color:red;}

Always a bit uncomfortable.

But nothing, nothing is as bad as:
p{color:green!important}

Oh bane of my life!! Oh curse you developer!!

My p.blue (which is supposed to be red - work with me here) is green.  Everything is green.  And now I have to start liberally sprinkling !importants all over the place.  The natural cascade is lost.  The very notion of !important is lost.

And I have a crazy urge to hunt down and pummel the lazy f-wit that decided green text was aaaall that site was gonna get.

That's why.