I love baseball and I’ve been reading the Eephus League blog for a while. Thus I was excited to hear about the release yesterday of the Eephus League Magazine. I think Bethany Heck, the designer and founder of the Eephus League has done a wonderful job with the magazine, both in terms of its content and also design.
I wasn’t surprised to hear that she took inspiration from Ian Coyle’s equally wonderful Edits Quarterly. A lot of sites have made use of the “parallax” effect made popular by Coyle with last years Nike Better World site, but Edits and the Eephus magazine are amongst the best examples I’ve seen. They are both lightweight and don’t suffer from the scrolling lag that plagues so many parallax sites, but also subtle in their use of transitions and pagination (e.g. there is not something moving in the background at all times, making for a more pleasant reading experience).
Further commentary via WebMonkey
I wanted to expand on yesterday’s post about creating “sticky” elements with jQuery and CSS. I want to emphasize that 90% of the time the method outlined in the linked tutorial is the best way to go - e.g. using jQuery to give an element a ‘sticky’ class, and then CSS to apply a fixed position to the .sticky element.
However, sometimes this might not work for you. So it was yesterday for me, as I soon realized that the fixed position element would not behave as I wanted it to when I scrolled left and right (my canvas was wider than the screen size). Note: I realize that my expectations were incorrect, and that the behavior was exactly what it should be.
And so I had to devise a new solution. What I came up with was to add the .sticky class in the same way as before, but to position .sticky absolutely. I then used the jQuery .scrollTop() method to change the top position of .sticky as you scrolled up or down the page, thus replicating the position:fixed; functionality.
var top = $('div.targetElement').offset().top;
$(window).scroll(function (event) {
// what the y position of the scroll is
var y = $(this).scrollTop();
// whether that’s below the form
if (y >= top) {
// if so, add the fixed class and top positioning
$table.addClass(‘sticky’);
$thead.css(‘top’, (y - top - 48));
} else {
// otherwise remove them
$table.removeClass(‘sticky’);
$thead.css(‘top’, ‘auto’);
}
});
While this provided a working solution, when I tested it on chrome it was almost unusable. Specifically any scrolling was extremely slow and jerky. Again, this was to be expected, when you consider the number of DOM requests that would be firing as you scroll down the document. Props though to Firefox though which was seemingly unaffected (anybody know why?) and worked great!
The solution to this was to set a timer on the scroll event, which would immediately limit the number of requests to a manageable amount. The only small downside was a delay in the element positioning on each scroll event, but this was kept very short at 250 milliseconds. The result was a page that scrolled smoothly, and a fixed position element done without css.
var scrollTimer = null;
$(window).scroll(function (event) {
if (scrollTimer) {
clearTimeout(scrollTimer);
}
scrollTimer = setTimeout(handleScroll, 250);
});
var top = $('div.targetElement').offset().top;
function handleScroll() {
scrollTimer = null;
// what the y position of the scroll is
var y = $(this).scrollTop();
// whether that’s below the form
if (y >= top) {
// if so, ad the fixed class
$table.addClass(‘sticky’);
$thead.css(‘top’, (y - top - 48));
} else {
// otherwise remove it
$table.removeClass(‘sticky’);
$thead.css(‘top’, ‘auto’);
}
}
Nice tutorial for creating elements that become “sticky” (e.g. fixed position) as you scroll down the screen. The tricky part for me was always working out the distance between the target element and the top of the screen. This is done elegantly here with .offset() jQuery method.
It is often necessary to use a twig expressions as html class names. For example, if you wanted to style a list of items according to their category. However, sometimes those category names are not suitable for use as a class name as they might be capitalized and/or have spaces (e.g. if your category is ‘Healthy Living’).
Luckily twig has filters that you can use as a workaround, namely replace and lower. In the example below, we replace all spaces with hyphens (-), and make the output lowercase:
{{ category.name|replace(' ', '-')|lower }}
The svpply dashboard is really nice. I’ve done a lot of work recently on a seller dashboard for OpenSky. It’s out there (we are testing it with a select group of sellers) but we’re still iterating on it quite heavily.
I think the svpply dashboard shows the value of keeping a dashboard simple, strong visually (i.e. lots of images) and most importantly, easy to understand and to compare performance over time.
The newly designed Rdio website is beautifully crafted. As responsive designs go, I’d have to say it’s one of the best examples I’ve seen.
But is it enough for me to switch over from Spotify… Not yet anyway. I have a free account but at this time I’m a little too invested in Spotify (playlists, etc). Maybe someone will invent a way to export/import playlists between the two, but I’m not holding my breath.
Browsing experiences and implementations being different between actual WebKit browsers themselves, this kind of browser-engine-and-prefix fragmentation is absolutely the last thing I would want to have to deal with as an author of websites.
Regrettably, Opera—and perhaps Microsoft and Mozilla, too—put the blame on authors for being “too lazy to do the right thing”, without seemingly having tried to solve the problem the right way themselves. After all, it isn’t a shortcoming in developers’ willingness or efforts, so much as it has been, all along, a shortcoming in the tools we’re forced to work with. Our tools are incredibly out of date and insufficient to deal with the complexities of today’s World Wide Web.
If Opera, or Microsoft or Mozilla, would have put their full weight behind a set of open source tools that work better than hand-coding websites, tools that produce the right output for CSS, they would have actually been tackling the real source of the problem. Instead, they’re accusing authors of not collectively and massively supporting their browsers when, to be quite blunt, those browsers were too slow and too far behind WebKit at a crucial moment in time.
—
Faruk Ateş makes a keen point in light of depressing news from Opera,who today confirmed that they will start implementing support for the -webkit- prefix.
I wrote something about this issue previously.
Great video by Seb Lee-Delisle introducing “CreativeJS for non-coders” - a JavaScript programming course aimed at designers and artists with no previous programming experience.
I’ve signed up for the newsletter, would love to attend next time he comes to New York.
In my mind you need two things to become a nerd. Time, and an idea. That’s all: no specific knowledge or expertise. I didn’t know nor was taught about development or design when I started.
—Brilliant post by Daniel Howells on the satisfaction to be had from becoming a nerd (i.e. learning to code)