When Matt and I were building WillyWeather, we religiously used GitHub—in particular, GitHub Issues—for logging, assigning and organising tasks and bugs. We both craved a better experience from our mobile phones. Neither of us could bear to use any of the existing apps and with GitHub abandoning their official client, the demand for such a tool became even greater.
So, we built it. Here is just a hint at what’s already available in the first major release:
Instant filtering, sorting and searching
Markdown editor for issues and comments
Collaborator mentioning and issue referencing
We’re already working on bug fixes, interface issues and performance shortcomings and have many great features in the pipeline, including Background Refresh, GitHub Enterprise support and more.
For now, we think you’ll really like the first cut of Hubbub.
I’ve been working hard on the biggest update to this site since it launched, with some improvements I’ve wanted since the very beginning.
The feature banner on the home page has been redesigned, rewritten and now makes use of the HTML5 History API. I dropped iScroll and built it around hammer.js which made gesture recognition relatively simple, not to mention being a much lighter library.
Lastly, all graphics have been re-drawn using Sketch, which was a great way to dive in and learn this brilliant tool. As an aside I’m now using Sketch across my projects more than Photoshop, which is simply great.
The current design is a year old, but this update has left nothing untouched giving it a brand new vibe once again.
A common practice in software design is to display an infinite activity indicator while a server or client task is being performed with an unknown completion time. On the web, this often comes in the form of an animating image which obviously must itself be loaded.
There isn’t much more jarring to a user than making a request and waiting, even for a fraction of a second, for part of the interface to catch up. This small lapse can be masked by preparing the loading indicator before the users’ action requests it. There are several ways to achieve this with pseudo-elements. Here is one:
This will render the pseudo-element invisibly, but ensure the browser has already pulled down images/loader.gif for when it’s needed. When an event has been fired that requires the element to display as active, all we need is a class to pull the indicator into view instantly.
To define the button’s :active state, one might change it’s colour, dim the type or reduce the gradient. This approach is fine, but as soon as you introduce alternate button styles with different colours, or apply the same logic to other UI components, you need to define the pseudo-classes for those too. Then, if you want to tweak any of the attributes further down the track, you must also change those of the :active states.
It’s worth creating the pseudo-element directly on the button and then altering it’s background on the :active state, rather than writing it all solely to the :active state so that the browser has less work to do on demand.
This technique can be used in conjunction with last week’s trick by setting both ::before and ::after pseudo-elements and will, of course, work with :hover, :active or any other state.
Pseudo-elements are a powerful yet underused feature of CSS. If you design for the web, you’ve probably at least used them for clear-fixing or creating complex shapes, but there are so many more practical uses if we explore just a little outside of the box.
One application of a pseudo-element is to define an invisible hit area around an interactive element, like so:
This creates invisible bounds that extend from all edges of the element by 12 pixels. No matter what you do to the original element, so long as it’s position is anything other than static, it will maintain the extended hit area.
A good use case for this is to guard against the dead pixels between navigational items so that the chance of missing them—especially via touch input—is reduced.
Note that as above, CSS Selectors Level 3 specifics a syntactical difference between pseudo-elements and pseudo-classes:
A pseudo-element is made of two colons (::) followed by the name of the pseudo-element.
This :: notation is introduced by the current document in order to establish a discrimination between pseudo-classes and pseudo-elements.
This is just one way that I take advantage of pseudo-elements in my work, every day. Over the next couple of weeks, I’ll publish some more of my favourites.