and talk about it….

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.

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.

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>

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.

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…

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.

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.

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 sass-lang.com).

@IMPORT

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.

Don’t include the underscores for partials nor the .scss extensions in the file names.

NESTING& (the ampersand)

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

@at-root

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

SassScript

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

VARIABLES

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:

MIXINS

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

EXTENDING

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.

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:

However, you can do stuff like this:

You can play with this stuff at http://sassmeister.com/ 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.

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

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

Hint: always quote interpolated named colors if they are meant to become part of a selector.

OPERATIONS

Arithmetic

+, -, /, *, % (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.

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.

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.

THEN…

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.)

This:

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

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.

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

NOW…

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:

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 theis- 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.

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:

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.

I just recently stumbled across this article about the demise of Internet Explorer. Or is it evolution? Whatever. Moving forward, Microsoft is working on a browser dubbed Spartan and has plans of retiring Internet Explorer.

I’ve been waiting for this day for forever. Even currently working on a project at work with the luxury of using 11 as the minimum browser version of Internet Explorer, I’ve come across things that it still doesn’t support.

Grrrr. IE. Grrrr.

And that is the feeling amongst most web developers. I haven’t met one that writes code for the Internet Explorer browser. Most of us work in Webkit or Mozilla and test after-the-fact in IE.

But, it wasn’t always like that. There was a time when I thought Internet Explorer was the better browser.

Say WHAT?

That was back in the 90s when I was working with IE 3 and Netscape 4. It was much easier to get things to look right in IE 3. And, so, with that thought, I wanted to take a walk down memory lane with Internet Explorer.

I don’t really remember the blur of IE 3 to IE 5.5. It was a long time ago and I wasn’t just doing web coding then, I was also creating multimedia CD-Roms using Macromedia Director and similar programs. But I remember IE 5.5. Because I kept lobbying for us to drop programming support of it in my company. And when we did I was ecstatic. Little did I know how long IE 6 was to stick around. And yet, once IE 7 came into town I realized that IE 6 was actually the better browser. But I move too fast. We need to visit with IE 6 for a bit.

During all those years with IE 6 I learned of doctypes (there was an invalid one going around early on – Dreamweaver was generating it – that caused a lot of problems, basically putting your site into quirks mode), haslayout and the holly hack (and then the zoom fix), the acid test, css hacks for targeting IE (like *html), conditional comments, and more that I’m sure I’m forgetting. And then there were satirical sites like http://www.ie6death.com/, helpful sites like Position is Everything (thank you, Big John, you saved my sanity), and shims like IE7.js (it would have been nice if the real IE 7 actually supported the stuff this shim did!) by Dean Edwards.

As I mentioned, when IE 7 finally got here, I quickly learned it was a buggy browser. It was really broken in right-to-left languages, forcing me to resort to layout tables once in awhile. I think it was during that point I looked into Google Chromeframe, and decided it was probably too buggy to recommend to my employer after monitoring some forums for a bit. Disappointing, but it has been discontinued, so glad I made the decision I did.

The one upside to the IE 6 and 7 years is that I became the go-to person for IE issues. Not that I was an expert on them, by any means, but I was so used to figuring out workarounds that I could isolate the issue in no time. Nostalgic days, but I am happy I am not needed in that capacity anymore. I also created this site during that time, to document things I was running into so I could find the solution again.

So there you have it. I’ve dreamt of the days where we could code for modern browsers without looking back. And we are pretty much there. Onward, fellow HTML & CSS coders. It is a brand new day.

Hurrah!

This post has been a musing by Gertrude, a long-time HTML/CSS developer.