• Switching to Stylus and Grunt

    Nothing important; just converted the site to Stylus.

    At long last I’ve replaced a few components of my personal site workflow. I’ve ditched Sass in favor of Stylus (which we use at Bolster Labs), and I’ve set up Grunt to handle building Stylus and Jekyll, and deploying the output to S3!

  • My Brain on BEM

    I don't understand BEM very well, and I acknowledge this, and I am trying to be better.

    At Bolster, we’ve incorporated BEM as part of our frontend methodology, and I’ll admit that I’ve probably had the most trouble adapting to it.

    I’ve read all the articles and seen all of the diagrams of how to name things according to “bemmy” principles. The problem I found I had, however, was that by giving every element on a page a unique name, I was left uncertain of how to share styles between similar page components.

    Getting specificity vs. reusability through my thick skull:

    Let’s say I have a feed-item on one page, and on another page I have a slightly different variation of a feed-item (let’s call it feed-item--compact). As I understood BEM, feed-item--compact wasn’t supposed to share styles with feed-item. This way, feed-item-compact could be moved around and reused independently of any other code.

    I realized that the answer to my problem rested with how I interpreted BEM’s guidelines. While my variations on feed-item should most definitely carry modifiers (like --compact), there’s no reason tht I couldn’t also have the feed-item class on the component’s HTML, and simply use feed-item--compact as a place to put the styles that differentiate it from the default one.

    Honestly, I’m not sure why it took me this long to realize it, but it’s something that I don’t recall seeing explicitly mentioned in many articles on BEM. You can have as many classes on an element as you need, and I would say that ideally you should have a class for each level of specificity you may require:

    <div class="feed-item feed-item--compact">...</div>

    …which, if you ask me, is every level of specificity… because you never know when you’re going to need it. It’s easier to simply not write some CSS for a class than to have to add that class to your markup later down the road, when you realize you needed the specificity (durr, again, that’s BEM for ya).

    Of course, if feed-item--compact really is supposed to look completely different than feed-item, then by all means re-specify those styles.

    How I’m probably abusing modifiers:

    I’m also not sure if this is mentioned anywhere, but I have a tendency to use --modifiers on both blocks and elements. So I may write something like:

    <div class="user user--premium feed-item--compact__user--premium">

    I’m probably wrong about it, but hey, it works for me and I’m trying not to step on any BEM toes in the process.

    In which my OCD about things hinders progress:

    Okay, here’s one thing that really bugs me about BEM: the misuse of _ and -. Multi-word tokens in a BEM classname are separated using hyphens, which breaks double-click selection behavior in most editors. Trying to double-click the feed-item in feed-item--compact is a pain.

    Here’s something more like what I’d rather do (though I’ve had trouble convincing anyone else to do this along with me):

    <div class="user user__premium feed_item__compact--user__premium">

    This way, each component (complete with its modifier) is quickly selectable by double-clicking. The underscore is used to represent spaces between words (as intended) and a hyphen is used to represent the combination of two independent components (again, as they are intended to behave).

    If you really wanna get fancy… let’s use the em dash rather than __ and keep our block-from-element separator down to a single, tidy hyphen:

    <div class="user user—premium feed_item—compact-user—premium">

    Isn’t that nice? Though—to be fair—for that to work most coding fonts would need to better distinguish the em-dash from en-dash or hyphen, given their fixed-width nature. I’d be open to suggestions.

    In the past with our CSS, we usually used the hyphen to separate our crude, un-bemmy element names from our unenlightened block names… like menu-item. Now, we’re using the hyphen within the element name, or within the block name. To me this seems like a common mistake in syntax styling that needs correcting.

    But that’s just me. ;-)

  • Post-Modern Font Management in OS X

    I'll probably still miss Fontcase, but it turns out I never really needed it to begin with.

    Despite its many quirks, I had grown to become a fan of Bohemian Coding’s Fontcase. While not as feature-rich as its bigger “Pro” cousins FontExplorer X or Suitcase Fusion, it did one thing better: it put the fonts front-and-center, behaving less like a file browser and more like a photo album. I suspect that I’m not the only person who prefers to view them this way, either.

    Unfortunately, at the beginning of this month Bohemian Coding made the decision to discontinue Fontcase, and to replace it with Fonts.app. The proffered reasoning seemed, to me, to be somewhat of a cop-out; surely there was a technical solution to the sandboxing issue? Even if there wasn’t a solution, and even if they had to remove the app from the App Store solely on those grounds, it seemed there was more to the decision.

    One of the main functions of Fontcase is font activation, and from the day we introduced the app we’ve had a large percentage of our customer base who just didn’t get the idea of font activation and why such a thing was ever needed.

    I wasn’t quite sure how to interpret this. Perhaps, as they said, their customer base was largely unclear about the purpose of Fontcase. I suspect, however, that the customer base built from offering Fontcase on the App Store was likely not representative of the users who find an app like Fontcase useful in the first place: designers. As a result, their customer base was uneducated on how an app like Fontcase would serve them.

    As a result, we’ve come to the realisation that Fontcase’s main features are just not needed or appropriate in this day and age, and the time has come to retire it.

    Not needed! Font-management has been a core activity in the lives of designers for decades—how could this be “not needed”‽ Much of Bohemian Coding’s explanation felt like superfluous rationalization for why they had to pull the app from the App Store.

    Although I and many other font-savvy individuals enjoyed the features that Fontcase brought to the table (primarily, activation and deactivation of fonts in our font menus)—and despite my initial indignant disbelief of the above quotations—I have begun to suspect that Bohemian Coding is actually on to something.

    It appears that—despite what we are taught in our design educations—our Macs are indeed fully capable of handling large numbers of installed fonts, and always have been. Let’s take a look at OS X’s original documentation about OS-level font management (PDF):

    No limits. There are no font limits in Mac OS X. Theoretically, it is possible to place an entire font library in a single folder and use it; because Mac OS X provides virtual memory, the subsystem simply uses more memory when necessary. (p.3)

    To be quite honest, I have always suspected this. I have used and enjoyed Fontcase and other similar applications for years, all the while activating fonts as I need them—and rarely taking the time to deactivate them again. It turns out I’ve been quite the delinquent about font activation, and never has this caused me any trouble.

    “Wait a minute!” you might be saying, “What about organizing my fonts?” Another feature that Fontcase offered is their ability to sort fonts into a comprehensible folder structure, or a “font library,” so that when you actually needed to track down some .otf file, you weren’t faced with a loose hodge-podge of unorganized files in your ~/Library/Fonts folder.

    Another look at OS X’s documentation reveals that we’ve been allowed to organize our fonts into nice folders all along.

    Mac OS X also supports hierarchical font folders so users can create multiple levels of font folders within font directories. Mac OS X makes all fonts installed in any of the font folder locations, or specific application locations, active. (p.5)

    So, when we add new fonts to our collection, we can just put them into folders named after the family ourselves, and drop that right into our font library. We can even organize them into alphabetical order, if so compulsively-inclined.

    With Mavericks, we could tag them, too… though, that admittedly might be a bit much. There’s no reason to use file-system level tagging for organizing our fonts—and that’s where Fonts.app comes in. It lets us browse our installed fonts in much the same way that Fontcase did, and we can organize them into logical categories based on things like mood, period, foundry, etc. for the purposes of making font selections. It offers only the things that (as we’ve now learned) OS X doesn’t already do.

    So, perhaps font management really isn’t a necessary evil anymore. As I recall, Font Book was not originally included in OS X. If OS X could not handle all of our fonts—as many designers have unquestioningly believed for years—why would something like Font Book not have been included in OS X from the beginning?

    Designers—free your fonts from their libraries! No more are our “iTunes for fonts” needed—there never was a need to begin with.

  • qft

    “Falling Back to Earth”

    Lauren Herda, www.herda.me

    A cross-post of an article of mine published on Medium—on why “Gravity” is a farewell to the space program as we knew it.

  • Introduction to JavaScript

    A couple of weeks ago, I conducted an introductory JavaScript workshop at the Baltimore Women In/Tech summit, part of Baltimore’s second-annual Innovation Week.

    I was thrilled to see so many women came out to the event, and just how many of the attendees of the summit were interested in getting into JavaScript. This was one of my first times presenting/teaching, and it was quite an exciting and rewarding experience to be able to introduce others to something I love.

    For posterity, here’s where you can check out the presentation I put together to go along with the workshop. I tried my best to make the slide deck understandable on its own, so hopefully others (maybe you) can pick it up and gain a new skill!

    Happy coding!

  • Want to read more? Check out the archive. »