Developing a responsive, Retina-friendly site (Part 2)

http://paulstamatiou.com/responsive-retina-blog-development-part-2

by PStamatiou • 13 years ago

121 31 13 years ago

niggler• 13 years ago

Do people just scale down the 2x icons to create the 1x series or actually change the icons (emphasizing certain aspects in the 1x version)? Based on my experience on the rMBP, it seems as if the icons are actually different.

roc• 13 years ago

The people who currently care about retina-friendly graphics tend to be those who have long cared about carefully hand-tweaking every variant-scaled version of every graphic they produce.

But as hi-dpi concerns become more mainstream, I doubt there will as much overlap and we'll see a lot more naive scaling.

WiseWeasel• 13 years ago

I just use SVG for all icons, so I don't have to worry about it. I design them on a low-DPI display and am usually pleasantly surprised when I check in high-DPI.

mddw• 13 years ago

I feel always a little lost when I read tutorials which use SASSy/LESSy CSS. Illustrating exemples with a preprocessor means lots of web developers won't be able to read you.

Moreover these developers are not in the hype bandwagon (or they would be able to read SASSy/LESSy/whatever fashionable now), so they may need the most the said tutorials.

aaronbrethorst2• 13 years ago

You should learn one of them. It'll make your life so much easier that it's not even funny. They're also really straightforward (for the most part).

So you know that Sass and Less allow you to nest rules, right? e.g.:

    .foo {
        p {
            // rules go here
        }
    }

translates into .foo p { rules go here }

Here are the examples from the article:

    &:hover { opacity: 1; }

The ampersand simply means 'I am applied in the context of whatever rule I happen to be in'. So, .home { &:hover { } } is equivalent to writing this normal CSS:

    .home:hover {
    }

@include is like #include in C. It literally includes the referenced content in the rules you're writing. That means that

    .home {
        @include bg-size(60px,auto);
    }

is including something that (inferring from the name, here) sets the background size for the element. Given the parameters, it probably expands into:

    .home {
        background-size: 60px auto;
    }

plus another rule for handling 2x images in Webkit.

This is a variable. Nuff said.

    $sprite_url_2x: "http://turbo.paulstamatiou.com/assets/pstam-sprite-v2-@2x.png";

make sense?

showerst• 13 years ago

I'd guess that it's not the actual idea of LESS/SASS that most people don't grok, it's the integration into their deployment workflow.

Since they don't use it every day due to setup woes, they can't easily read it fluently.

CJefferson2• 13 years ago

Given I don't understand SASS and Less, you seem to have, in each case, replaced some CSS with something which is longer, and less easy to understand.

I am sure these is some extra magic you are not telling us, but given that you are assuming we don't know about SASS and Less, you are obviously missing something important :)

mnicole• 13 years ago

Compass' docs' code snippets have little tabs that allow you to switch between the SCSS and Sass syntaxes that I think would be great for people like you that need to see the CSS output. I wonder if anyone's made something like that (possibly with Stylus in addition to LESS), even though I agree with the sibling comment that suggests learning one (I prefer Sass).

michaelbuckbee• 13 years ago

It sounds kind of weird, but I'm actually really passionate about CSS pre-processors. Switching to LESS from plain CSS was one of the biggest and clearest productivity improvements I've ever made to my dev toolkit.

I was reluctant to try it as I feel like there are already so many moving configurable layers to my dev stack and all I could think was "I have this nice static css file here - I just include it and everything works" and the only real exposure I had had to LESS/SASS was exactly the same sort of context free dozen lines of mixin code that does something awesome in some blog post just like you are describing (which made it seem much more intimidating than it actually was).

Now here's the real kicker: I didn't realize that I already know how to code css in LESS. Since LESS is a superset of CSS you can take any CSS file (even one from an existing application) and put it through a LESS processor and get back a usable CSS file. This is awesome as it makes it possible to start using LESS in the middle of a project and it makes it very easy to slowly stop doing all of the soul crushing find+replace that takes forever working with CSS as you ramp up with LESS.

I'd really encourage you to give LESS (or SASS or whatever you find fashionable) a try - I think you'll like it. If you get stuck or need help shoot me an email (on my acct page).

danso• 13 years ago

I've loved this series, it shows how complex web-design has become but has a considerable amount of actionable information on what the latest libraries/hacks available are.

It's also a bit deflating. Just when you thought the kind of arcane knowledge needed to survive the IE-compatibility-era was over, the explosion of new resolution and screen types have made web dev -- even just the design and display side -- something with considerably more moving parts than I remember from ten years ago.

kadavy• 13 years ago

I realize Paul is doing it for the sake of learning, but that seems like an insane amount of consideration to display and bandwidth.

I remember seeing an article that argued that you should just serve up big images, and that slow cellular data networks scale down and optimize images pretty well already.

Basically it argued that it wasn't worth the trouble. Even with some Googling I can't seem to dig it up.

Thoughts on this, anyone?

kalid2• 13 years ago

I began retina-ifying my website (http://betterexplained.com). I'm serving up the high-res images. Something like a logo should be downloaded once and cached for a long time.

I have a lot of LaTeX-generated images, which is too painful to set using CSS rules. Also, for RSS/email readers, they don't have the full stylesheet available (feed-to-email service), so I want the image dimensions specified via attributes, not CSS.

papsosouid• 13 years ago

>Something like a logo should be downloaded once and cached for a long time.

The cache on mobile browsers is tiny (4-85MB), your logo will likely only be cached for that visit. I'm finding sites claiming IOS didn't even have a disk cache for safari until IOS 6? So in that case it is certainly only getting cached for one visit.

WickyNilliams2• 13 years ago

Despite the advice in the article, never use an <img> tag with an empty src attribute - it causes the page itself to be requested, which is probably a larger request than just serving up a low res image in the first place.

Otherwise lots of interesting points here, and a lot of thought given to the fine details a lot of us would otherwise skip over. Good work mate

PStamatiou• 13 years ago

Wicky and I chatted on Twitter -- I think this is only a case for certain older browsers. Haven't seen an issue with anything like this in recent browsers in the last few years

WickyNilliams2• 13 years ago

I've done some investigation and you're right, it seems that it's been fixed in the majority of modern desktop browsers. As far as I can tell Chrome, FF, Opera, Safari and IE (9+) have resolved this issue [1][2][3][4]. Can't find any data on mobile browsers, haven't got the patience.

[1] http://www.nczonline.net/blog/2009/11/30/empty-image-src-can...

[2] http://www.nczonline.net/blog/2010/03/16/empty-string-urls-i...

[3] http://www.nczonline.net/blog/2010/07/13/empty-string-urls-b...

[4] https://code.google.com/p/chromium/issues/detail?id=38144

crazygringo• 13 years ago

This level of complexity for images (1x and 2x) is madness. And the real kicker is, it doesn't even account for the kind of variable zooming people do on their phones, which can result in 1.73x, 2.79x, 4.23x, etc.

I've found it vastly simpler to adopt a much more flexible and simpler approach. Just include single images (not multiple versions), and pick resolutions that are appropriate for the image -- that convey the level of detail the image deserves. And when you up the resolution, knock down the JPEG quality.

Sometimes this means 3x or 4x for bullets or icons mixed in with body text. Sometimes it means 1x for photographs. Sometimes it means 3x for small illustrations and 1.5 for larger ones.

Don't worry about things being pixel-perfect, because pixels don't exist anymore. Just aim for whatever resolution communicates the necessary meaning of each element. Good judgment is your friend.

Developing a responsive, Retina-friendly site (Part 2)

Related Stories