Tag Archives: Style

Accessible font icons

I recently posted a somewhat personal post on my other blog that I wrote concerning “creative constraints.” And how a renewed interest in typography specifically has made me realize the value limit can play in my life.

Leading a life with creative aspirations foremost in mind hasn’t always been the most productive or fruitful of endeavours. Meaning at times it can be quite frustrating. Add to that a level of technical detail I seem to need to keep my interest piqued merely adds complexities to a situation that, if anything, would benefit from less difficulty rather than more.

But it would seem this interest in type, and web fonts in particular, will be quite the challenge for me going forward. There’s no shortage of nerdy details to occupy my mind with for years to come. I’m actually quite looking forward to it.

And if that wasn’t enough there is also this thing I’ve recently been made aware of called font icons. “Font icons are awesome.” But more to the point of this post today, they are “accessible” (but they come with some things to watch out for, hence the quotes). And that really makes my dorky side drool. Details, details, details… Read “Accessible font icons” in its entirety

The efficiency of CSS interest

As 2013 quickly approaches I can’t help but wonder where 2012 went. Actually this past year was quite an eventful one. One not so focused on the computer — if you take the regularity in which I have blogged since June as indication. But for the purposes of this post, and its home on this blog, I’ll keep this relevant.

With the first half of this year fully involved with my volunteer gig at the Fluid Project, and building Fluid Studios specifically, I was pretty overwhelmed at times. That’s not necessarily a bad thing. Or looking back on it now, it wasn’t. I learned a few valuable lessons. Most important of which was how lacking my CSS skill set was, and in some cases still is, in terms of thoroughness. And testing specifically. Namely with the dreaded IE — precisely with versions 6 to 8.

Anyway, as I said, it wasn’t all bad — albeit very frustrating at times (which comes with the territory). But I really can’t complain. I received a new appreciation and a renewed interest in CSS. I’m all in. With everything. And my approach, especially. It’s all about Object-oriented CSS and writing efficient code now. Gone are the days of writing a selector, then all the rules that apply to that single selector. Make your CSS work for you, not the other way around. (Do me a favour? Don’t look at the CSS for Fluid Studios. Thanks.) I’m still learning but I haven’t been this excited about poking out code in a long time. A really long time. Read “The efficiency of CSS interest” in its entirety

An issue using rem

Some time ago I came across an article by Jonathan Snook titled Font sizing with rem. Not so long story short;

In the early days of the web, we used pixels to size our text. It’s reliable and consistent. […] To get around that1, we can use em units. […] The problem with em-based font sizing is that the font size compounds. […] CSS3 introduces […] the rem unit, which stands for “root em”. […] The rem unit is relative to the root — or the html — element. That means that we can define a single font size on the html element and define all rem units to be a percentage of that…

A pretty sweet solution, regardless of not ever having any significant issues with the em compounding dilemma, none that I can reliably recall anyway. And I’ve used it on a few projects since reading it. It is a very tidy solution to what could potentially become quite a messy problem. For organizational’s sake, at the very least, I’m really quite fond of this solution. Read “An issue using rem” in its entirety

Mobile first with a twist

Frankly between the two of us, while I do see the merits in designing a mobile website first — in terms of a website’s information architecture as well as the aesthetic appeal, especially for the sake of its usability and appearance on a small screen — I’m not sold yet on whether a mobile site has to be designed first. That said, it does need to be designed at the same time. Semantics, eh? I’m hilarious, I know. But thanks for thinking it.

So what’s this “mobile first with a twist” schtick? Basically it’s a bunch of borrowed idea’s from Ethan Marcotte’s amazing little book, Responsive Web Design, Luke Wroblewski’s “equally” little book, Mobile First, (by the way, me calling each author’s book “little” isn’t a slight in the least, both book’s strength lie in their size, and that’s the point) and something I’m sure Harry Roberts wrote a little while ago but I can’t relocate now. About designing for less capable browsers first then adding on top of that base for more capable browsers — or specifically how such an approach plays with Internet Explorer 8 and below.

Anyway the “mobile first with a twist” approach is quite simply a matter of designing a website for mobile, meaning for small screens (not just visually but functionally too), then tweak it larger, with the least amount of effort and the most basic — yet responsive — CSS possible. This as your starting point. A base from which to build. The thinking is this is what a visitor will see and use who is using a less capable web browser. Read “Mobile first with a twist” in its entirety

Links: fixing what ain’t broken

I started my initial “webucation” simply by learning virtually the only consistent (meaning “sure-footed”) language on the web, at the time. Hyper Text Mark-up Language (HTML). As I wrote here previously, just over a month ago in fact (where is the time going?), CSS resets and the manner for which I have and do rely on them have undergone quite the shake up. And as sort of an addendum to said post, not for any other reason than consistency, I’ve reinstated the FSS reset, well half of it anyway, back into FSSFive. But another approach of mine that has experienced quite a realignment is what had to be my very first lesson on HTML. Links. But more specifically how links look in a webpage.

It was 1997. Arguably during the early days of the web. At least with respect nearly everything web related was in flux. Everything still needed to be figured out and settled upon (well as much as anything on the web can be or actually is “settled”). And when I started to learn HTML it was in the dying days of version 3, just prior to the “ratification” of the new specification — version 4 — that saw use for a good 12 years. Version 4 came out in very early ’98, if I remember correctly, and 5 still hasn’t, and won’t for years, reached final draft status. But portions of the web are currently, and have been for a bit, moving to the next “iteration” of HTML, version 5.

As an aside, there is plenty of “in between” stuff I’m failing to mention in the years from 1998 to 2010, XHTML 1 & 2 being the most significant occurrences. That is on purpose. Honestly by the time I graduated College, in the winter of 2001, I had Photoshop on the brain. Bad. It wasn’t until 2005 when I got back onto web design. Previous too ’05 I was “listening” to what was happening but not with enough interest to accurately recall most of it. And not too much before ’08 I was entirely consumed with re-learning how to do develop on the web, again. Read “Links: fixing what ain’t broken” in its entirety