Getting up to speed on CSS tools

I did this backwards. It should have been mixins, Sass, Smacss, Compass, Singularity. Then again, sometimes starting and the end and working your way back lets you see the bigger picture and understand how it all fits together. Says the girl who started Drupal with core contributions.

Singularity (compass extension)- ratio-based grids (quick walkthrough video here), very easy to make different widths $grids: 1 2 3 2; Also can use px, pt. Integrates with breakpoint- add an @include breakpoint(30em){@include grid-span(2, 3);}. Very cool, super easy way to get responsive design out fast.

Mixins-  A mixin is an at-rule used to define a ruleset than can then be *reused* in other rulesets. Yay reusable code. I think mostly as a n00b I'm always surprised when things like this aren't a given- it makes perfect sense to be able to define a thing and then plug it in wherever you need that thing. But is this the same thing as the mixins Compass is using?

/* define a mixin */
@mixin .muffinstyle {
display: inline-block;
background-color: blue;
}
/* use a mixin */

p .bakery {
include: .muffinstyle;
border: 1px solid red;
}


ok, Stackoverflow question on the CSS at-rule here. So basically anything preceded by an @ is an instruction for the user agent, rather than styling rulesets. I've been using @media, @font-face and so on, but hadn't really thought about the construct itself. Here's MDN on at-rules and W3C on CSS syntax (this one's really helpful). There's a very handy graphic and description here on CSS statements and their subsets, at-rules and rulesets.

Compass- Ok, so there are CSS mixins, then there are Compass mixins... which are just a predefined set of CSS mixins? oh. And then Singularity pairs with Compass. I get it. /several hours of digging and reading later.

Sass- This also makes all kinds of sense. Things like variables to hold info in a more logical spot while you're writing, then output a fully fleshed out CSS file at the end. Saves on typing, mistakes, and again with the reusable code. Compass is for writing Sass. Got it. Wow, nesting. So logical, so tidy. Ah, and we're on the new version that uses curly braces, which seems a lot better than just indenting anyway. I do not generally approve of dropping semi-colons and such even if it *is* more minimalist.

Smacss- I really appreciate this- organizing, categorizing, approaching css in a logical fashion rather than throwing properties left and right and hoping it all works out. See my next post on approaching a problem, too. I might disagree with a couple things Snook says (and this book is a little old already), but his general point is spot on. I think this will fit into my brain even better after my next two or three tabs, too... Things start getting interesting once we drill down to the "module" level. Goals: increase semantics and decrease reliance on specific HTML

Next: More depth from Legacy CSS with Sass and SMACSS and modular SASS development using SMACSS and BEM.

In other predictable news, something here needed homebrew to install... I think it was a Ruby update. I have Ruby 1.8.7, but would like to have the current. Probably doesn't matter. But I think to update I need homebrew and homebrew last I checked needed xcode and 10.6.8 does not the xcode have. BUT. I think I can install the sass/singularity/compass package with just ruby. I hope. Later. Not now. Because this is always ridiculous, and generally why I'd rather stick with simple, low-level stuff.

Next: Creating a Drupal 8 Theme with Sass, Singularity & Breakpoint

An Introduction to jQuery [notes]

inally getting on to actual jQuery! This about sums it up: "...we can use jQuery to perform its core functionality: getting some elements and doing something with them." All this reading is well and good, but I need to actually be querying and scripting in order to really understand. Therefore, I think it's time to go back to Codecademy for the jQuery lessons as soon as I read through jqfundmentatals.

The jQuery Fundamentals page links to the CSS2 spec on CSS Selectors, but there are some changes in the CSS3 spec. Memorizing the spec details isn't the most critical thing for me right now, and I have a pretty good grasp of combinators and pseudo-elements, IDs and classes.

The trouble with W3C specs, of course, is that user agent (UA, aka browsers) implementations may vary. Pseudo elements: I should try out :first-letter for drop-caps (though it wont help with my image drop-caps).

Q: So what exactly is a jQuery object? What does one do with it once it's created? Where is it stored and what is its lifespan? Backing up slightly, what does a regular old JS object look like?

A: As usual, I'm complicating things. Your generic JS object looks about like the code below, using literal notation to make the comparison easier. "All objects in JavaScript are descended from Object; all objects inherit methods and properties from Object.prototype, although they may be overridden" (MDN reference) "Objects are a collection of properties, and properties are associations between a name and a value"(more MDN). If a property is a function, then it is a method for that object. Pretty much everything in JS is actually an object. (see also: prototypes and classes)

var Bunny = {
ears : "long",
tail : "puffy",
hop : function (height) {
console.log("Hopped "+ height);
}};

The jQuery object is a JS object in that it stores elements and has methods, but it is an array-like object that just lists the DOM elements from the query. An array-like object has key:value pairs, but the key in this case seems to just be the index.

var a = $('div');
console.log(a);
/*returns from my blog homepage, more or less:
{
0: div#navbar.navbar section,
1: div#Navbar1.widget Navbar,
2: div#navbar-iframe-container,
3: div.body-fauxcolumns...}
*/

The jQuery object can be stored as a variable, or just called once and used, otherwise it disappears after use (?). I'd like to better understand memory and troubleshooting leaks (StackOverflow discussion). Basically, it looks like as long as there's a reference to an object, that object has memory allocated to it.

"Truthy" and "falsy" are a little ridiculous sounding... what's the difference between those and just true/false? Anything that evaluates to True is truthy, to False is falsy, but there are other possible evaluation results as well, like NaN, undefined, null, and any number of things – these are not specifically True or False, but they have trueness or falseness ascribed to them. It's descriptive instead of referring to the specific True/False booleans that you might return. This short article from 2011 explains it much better than I am (and I like his zebra).

Helpful tidbits:

• $() is a function. Functions in JS are objects and have methods and properties. $() always returns an object, and objects are always truthy.
• $( 'li' ).eq( 0 ).is( '.special' ); to find whether the selection using .eq() to select a specific single{ element matches the parameter in the .is() method (selector, DOM element, jQuery object, function); returns boolean.
• Use getters and setters (methods) to do things with jQuery objects. Iteration over elements can be explicit (.each();)or implicit (.html();), and you can chain methods together on a single selection. 
• Then we also have filtering, .not(); .filter(); .has(); on selections, which are more or less "without," "within previous selection," and "contains," respectively. ...many more methods here in the top hit on Google for "jQuery cheatsheet" (includes CSS selectors!). I'm a visual person.
• Plus, find other items/make other selections relative to a previous selection with things like .children();, .next();, .parent(); etc and add to existing selection with, by george, .add();
• More on how to use jQuery in the context of your basic HTML page here from the jQuery folks.

That's probably enough for now. I have a bit more of the jqfundamentals page to read through, then back over to Codecademy, then moving on to "JavaScript: The Good Parts." Please comment if you notice something I've got wrong or that could use clarification.

Moving on, letting go

he hardest part of a project for me is deciding that it's finished. Usually it takes getting distracted by something new for me to really move on (this probably goes for some other stuff, too...) because otherwise I just can't let myself stop futzing, adjusting and perfecting. Translation: beating my head against something that just isn't making any more progress. So I have to learn to let it go, move forward.

In case you haven't been following along, in this case I'm referring to my "One Week Website" series of posts (clearly the timing didn't quite work out, but I never really expected it to). I started designing a new resume, and made great leaps of progress... until I ran into a wall attempting to make it perfectly responsive. This actually would have worked fine except that in keeping it super simple I was avoiding @media queries and pretty much everything except some basic CSS (see below).

And it was all going pretty well until I went to make a PDF. I have no idea how print formatting works, from web page to print dialog to PDF, but the margins didn't behave properly, it didn't fit on one page, and the white space looked weird instead of stylish (at least I hope the HTML version looks decent). So I reformatted a bit with those 800px min-widths on the #page-wrap and #content sections. Of course, now the #web and #general skills lists don't float and switch from side-by-side layout to being a single column, which means the 50% layout looks darn silly on mobile.

I tried using sections and header and h1-h6 instead of a flock of divs, and since this is a one use document, I just went with ids rather than classes. Feels wrong, though. At the very least, I have a resume that looks a little better than an old Word document, even if it isn't actually responsive. And! I did finally stop poking at it and just hit print.

body {font: normal 1em Times, serif;}
#page-wrap {width: 75%; margin: 5% auto; min-width: 800px;}
#me {display: inline-block; width: 100%; position: relative;}
#logoname {float: left; width: 25%; min-width: 165px;}
#logoname span span:first-of-type {color: #6C8771;}
#logoname span {color: #4D4D4D}
#contact {text-align: right; position: absolute; right: 0; bottom: 0;}
#content {width: 75%; float: right; min-width: 800px;}
#skills li {text-indent: -0.5em; padding-left: .5em;}
#web {float: left; width: 50%; clear: both;}
#general {float: left; width: 50%;}
#experience {clear: both;}
#learning li {display: inline; padding: 0 0.5em; border-left: 1px solid black;}
#learning li:last-child {border-right: 1px solid black;}

section {border-top: 1px solid black; padding-bottom: 20px;}
h1, h2, h3, h4, h5 {font-family: Baskerville, Palantino, serif; border-top: 1px solid black; margin: 0; padding: 0; display: inline-block; margin-bottom: 2%;}
h1 {font-size: 2em;}
h4 {float: left; font-size: 1.17em;}
h5 {padding-top: 3px;}
a {text-decoration: none; color: black;}
a:hover {color: gray;}
ul {list-style: none; padding:0; margin: 0;}
li {margin-bottom: 1%;}
dl {padding: 0; margin: 0;}
dt {padding-bottom: 1px;}
dd {padding-bottom: 1%;}

Now I just need to figure out if I really want to make my entire resume public on the internet. My feeling is no, not one bit, but then part of the point of doing it in HTML is lost. Still, it was fun to put together, and that's more important anyway.