When I wrote Regaining focus I figured, from my past experience using user defined style sheets, things would be as straight forward as I remembered them being. Why isn’t anything as simple as the utility demands? And for the record, I know relying on memory alone is largely a sloppy move to make. And I hope to correct myself with this post today.
But I didn’t fully realize my error until I went to write up the README for a Github repository I wrote for a solution for such a problem. Using the bit of code I provided in my post I linked to above, I wrote a style sheet (FOCUS.css) that would provide a user the same experience in the same browser from one site to another.
The problem being the ways to implement user defined focus styles vary quite a bit from browser to browser. From easy to complicated. Read “Defining focus” in its entirety
During the latter part of this past week, I performed an accessibility “audit” for an organization I’ve done this type of work for in the past and unfortunately haven’t done much for in recent months. It feels good to be at it again.
And the web developer’s work I was evaluating was missing one of the most basic concepts of accessible web design. They removed the focus indicator from their links. I thought I’d share how I got around this potential show stopper with a little browser feature I’ve had to use possibly a couple other times for situations not quite as serious as this proved to be, but I think this will be worth the effort.
But before I drone on, it seems this needs to be said at least one more time. You really should avoid removing the focus indicator from web sites. Now I understand why one would do it. In some browsers the outline shows when you click on a link and that complicates certain aesthetic goals. And there are ways around this (largely).
But, as the link above demonstrates, this isn’t a new concern. This is merely me taking my sweet ass time at getting to a point. Which isn’t my main point, bear with me, I’ll get there. Revisiting practices that have since passed “pressing” relevancy can sometimes help your current processes. Take my “audit” this past week as a perfect example. Read “Regaining focus” in its entirety
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
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
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