(One of my favorites is still Joshua Hibbert’s single element Macbook)

It’s all fantastic work, and enormously inspiring to see people getting so creative and clever with their code, showing us the powers of CSS and how it can (almost) eliminate the need for images or scripts; often by using pseudo elements, CSS3 animations/tranforms and box shadows.

However, pet peeve alert! Please, let’s stop calling it “pure CSS” — it never actually is PURE CSS.

Yes, the majority of the code in these examples are written in CSS. But sometimes, there are some images used in the CSS (example: Kushagra Gour’s Rotating earth using pure CSS). And in every single case, you’ll still need HTML code that uses the actual to show the result. Without the HTML, the CSS can’t show anything at all. No matter how small the HTML is; it’s still required.

And so with the definition of the word “pure” meaning “just that and absolutely nothing else“, I repeat: it never actually is pure CSS.

I know, you’re probably saying “who cares man, bitching about nothing!” and I can’t blame you. But hey, if you want to call it something and be exact about it, why not call it “no JS” or “no images” or something that it really is? Cause even though it’s often fantastic code — “pure CSS” it’s not.

The post Pure CSS is not really that pure appeared first on Mark Senff.

Since documentaries are my favorite (and most popular) “genre”, those are marked with an asterisk. Here we go:

1. Paradise Lost 3: Purgatory *
2. Prometheus
3. Paradise Lost *
4. Contagion
5. The Cabin In The Woods
6. Braveheart
7. We Bought A Zoo
8. The Adventures Of Tin Tin
9. Catfish *
10. Project Nim *
11. Savages
12. 21 Jump Street
13. The Amazing Spider-Man
14. Hodejegerne
15. The Dark Knight Rises
16. The Messenger
17. The Hunger Games
18. Friends With Kids
19. The Expendables 2
20. Mansome *
21. Looper
22. The Greatest Movie Ever Sold *
23. American Reunion
24. Capturing The Friedmans *
25. Låt Den Rätte Komma In
26. The Queen Of Versailles *
27. Chasing Ghosts *
28. Conan O’Brien Can’t Stop *
29. We Should Talk About Kevin
30. The Devil’s Double
31. Paradise Lost 2: Revelations *
32. The Other F Word *
33. Katy Perry: Part Of Me *
34. The Decline Of Western Civilization Part II: The Metal Years *
35. The Descendants
36. Iron Maiden En Vivo *
37. The Wave
38. Wanderlust
39. Alex Cross
40. The Bourne Legacy
41. Project X
42. The Swell Season *
43. Sound Of My Voice
44. The Vow
45. The Avengers
46. Contraband
47. Silent House
48. Arbitrage
49. Being Elmo *
50. Champion *
51. Helvetica *
52. Transformers: Dark Of The Moon
53. Comic-con Episode IV *
54. Special When Lit *
55. Madagascar 3
56. The Five Year Engagement
57. Captain America
58. Shame
59. Iron Man 2
60. Transformers: Revenge Of The Fallen
61. Galaxy Quest
62. Zoolander
63. Apt Pupil
64. Into The Abyss *
65. The Campaign
66. The Boys From Brazil
67. Jeff, Who Lives At Home
68. Freakinomics *
69. Shoot ‘Em Up
70. The Moth Diaries
71. Green Lantern
72. The Captains *
73. Iron Sky
74. Barbarella

A few notes, to put things into perspective (I’m sure there are some people who will say that this list can not be taken seriously when The Dark Knight Rises is lower than The Cabin In The Woods and something like The Avengers is only at number 45):

• Again, the list’s order is NOT from good to bad. I do realize that The Dark Knight Rises is a “better” film than, say, 21 Jump Street — but it was less entertaining to me. Same with all the other movies: watching a silly little low-budget ditty such as Katy Perry’s documentary simply entertained me a lot more than a sure-shot blockbuster such as The Avengers.
• Yes, I was the last person in the world that hadn’t seen Braveheart, until last month (now I’m just the last person in the world who hasn’t seen Dances With Wolves).
• Classics such as Barbarella or Zoolander are much higher on other people’s lists, but it’s the disadvantage of seeing them too late. Had I seen then when they were initially released, I’m sure I would have appreciated them a lot more.
• Of course, it’s all personal opinion. Don’t forget, I’m one of those people who actually liked The Phantom Menace.

The post Senff’s favorite 2012 movies appeared first on Mark Senff.

OK, that may not be the most exciting thing you’ve seen all day but hey, it’s a good step forward, at least for myself. Pretty tricky, I must say, and a lot more work than I really expected.

It’s definitely a lot more than just starting with a design that works on mobile, and then having a bit of different details kicking in at certain breakpoints using media queries. But no, it wasn’t that simple. So what have I learned?

(NOTE: I did a lot of “design in the browser”, meaning I did not have a design locked in for various devices or breakpoints — there was lots of “let’s see how this turns out“).

Breakpoints

The most important thing I figured out is that using the “default” breakpoints (320, 480, 576, you know…) for media queries didn’t work out well enough. Let’s take the sidebar as an example. Originally, I set it to be at the bottom on small screens, and then at the side for screens wider than 1024px (generally, at the bottom on mobile phones and iPad in portrait mode, and on the side on iPad in landscape mode and laptops/desktops).

Problem is, things didn’t look so great when the screen was about 950-1000 pixels wide. The main content just took up too much space. So, the breakpoint to move the sidebar from the bottom to the side was set at 950px.

(Sure, technically it doesn’t matter that much for the aforementioned devices, but hey, what if Apple will release an iPad Medium next year that has a screen width of 960px? Problem already solved!)

Hence, my answer to the ever-popular question “where should I set my media query breakpoints?” would be “at every point where your design breaks“. During design/development phase, resize your browser. Once you notice things look ‘off’, that’s your breakpoint.

Asynchronous breakpoints

(I really can’t come up with a more fitting name). The top menu changes at various breakpoints, and the sidebar changes at other breakpoints. In other words, it’s not like the whole page design changes at certain points. Instead, the various elements don’t seem to mind eachother’s changes in behavior and are fairly independent.

Although for some sites it may work to have all the elements (or the entire page layout) all change at the same breakpoints, for this site it made more sense to have them change, again, as design dictated. Just because the sidebar bottom-to-side change works best at 950px, doesn’t mean the top menu had to change at that point as well (and vice versa).

In other words, set your breakpoints for various sections on the page — not necessarily the page itself as a whole. Even though, of course, the full page design should look good at any point.

Test on REAL devices

While developing, it’s super handy to have a little tool that automatically resizes your screen so you can instantly see what things will look like on a small screen. My personal favorite is Malte Wasserman’s Viewport Resizer. However, this will only give you an idea. Just because it looks good on your laptop or desktop when your browser is only 320 pixels wide, doesn’t mean it will look like that on an actual iPhone (or other mobile phone).

Various devices have various behaviors. If you don’t test on actual mobile phones, you might miss the part where the device adjusts the font size automatically when you switch between portrait and landscape, something you wouldn’t be seeing with any viewport resizer.

For the record, the solution to that problem:

html{-webkit-text-size-adjust:none;}

So, always test on the actual devices you want to support. When creating a responsive site, I assume you want to support a bunch of Apple products, and a load of Android phones, so test your site on as many devices you can get your hands on. It’s the only way to notice the individual device’s quirks.

Well hey, it’s not your ultimate guide into responsive design, and I’m sure there’s still some mistakes in it (or it may be far from “best practices”), but there’s some tips that might help you.

The post New site, responsive and all! appeared first on Mark Senff.

The main issue is that at first (and second, and third) glance, Git is just not user-friendly with all its command line stuff and abundance of abstract terms (even with years of general version control experience, lines like “…the rebase in particular can be difficult to use correctly at first, since it does rewrite the history of a branch, and that changes the SHA1 which is associated with it: to a public branch, that means lots of merges from the other developers pulling from it…” just make me want to kick Git in the face, hard.

Yet, despite its (seemingly) complex nature, Git is incredibly popular among coders. I’m determined to find out why.

If I do manage to figure it out this time, I’ll be posting some (hopefully) helpful tips and tricks. Though, if I haven’t posted an update within a week or two, I probably jumped off a building out of frustration.

Wish me luck.

UPDATE: getting there! Expect new post soon in which I describe my experiences.

The post Git, here I come…again appeared first on Mark Senff.

Issue 232 of leading web development publication .Net Magazine (in stores now) features a short column by me, dealing with the eternal battle between good and evil.

As a frontend developer working on large-scale projects with backend devs, I’ve often found myself in situations where it isn’t really clear who’s responsible for a particular type of task or, perhaps, who should define how a certain piece of the coding puzzle needs to be solved.

I can only speak from the frontend point of view, but it seems there’s a bit of a silent battle where the notion is that backend devs do the ‘complex’ stuff, and that the only task of a frontend developer is to slice Photoshop designs. On the other hand, we [frontend devs] also probably think our role is more important than it really is. Still, where does that great divide come from?

In my view, it starts with the most fundamental question of all: where do we actually draw the line between frontend and backend development?

After all, what is the essential, defined difference between the two? Is backend everything that takes place on the server, and frontend everything that takes place in the browser? Is backend PHP and MySQL, and frontend HTML, CSS and JavaScript/jQuery? Is backend abstract programmatic code and frontend the look and feel?

Most likely, it’s a combination of all that, mixed with a grey area where both types of developers share the responsibility. But then why is there this constant conflict between me and the backend developers who think they are the only ones qualified to decide between Bootstrap and Boilerplate? Or the types of geniuses who feel they should rearrange my CSS file structure because it would be better for performance? Or, even, those who think it’s their call to decide which CSS preprocessor (or editor!) I should use?

Quite often I’ve felt underappreciated and disrespected by the so-called smarter backend guys. At times they talked to me as if I should simply follow their lead and just worry about using the correct colours and fonts. Is this God complex a standard feature the comes pre-installed with backend developers? Or is this inferiority complex something that frontend developers are born with? Or am I the only one who feels this way?

I can’t really complain at my current job (I still clash with backend devs at times, but at least the battles are healthy and constructive), so perhaps I’ve been unlucky with some of the guys I’ve worked with [in the past]. Maybe I should stop complaining and go back to slicing Photoshop files.

Terrible photo printed with the article though, which is placed in the section “Expert Advice“. Flattered but I would hardly call myself an actual expert, especially when compared to the rock stars that are usually featured in this magazine. But, glad to be in their company.

The post When front and back clash appeared first on Mark Senff.

Needless to say: SPOILERS ABOUND. If you haven’t seen the movie, just stop here. Right now.

OK, here goes.

1. Bane breaking Batman’s back. An enormously huge moment in Batman mythology. Yet, it’s treated like just a footnote in the movie — not really like a major, MAJOR event.

2. Bane’s final scene. For someone who’s presented/advertised as the major villain in this movie, he sure gets a whimper of an exit. Think about it — do you even remember how/where he ended up? Major characters like this deserve a more memorable ending.

3. You really can not recover from a broken back (and come back in tip-top shape) within the course of several months. Yes, yes, I know it’s not a documentary, but for a movie that takes itself this seriously, this is ridiculously unrealistic.

4. For a BATMAN movie, how many minutes of screen time did the BATMAN character actually get?

(5. BONUS GRIPE: the main poster, see image on the left, is actually pretty bad)

It’s not a bad movie, of course. Come on! And especially Tom Hardy and Anne Hathaway are excellent. But the four points above DO bug me, and what keeps me from calling this good movie a GREAT movie.

The post What’s wrong with The Dark Knight Rises appeared first on Mark Senff.

No dice.

Perhaps I wasn’t looking in the right places, but apart from meetup opportunities that were more focused (such as WordCamp) or were not in my language (the monthly meetings by HTML5mtl, which would be perfect if I would just speak more French), I could not find any ways of hanging out with front end peers, apart from my (ex-) co-workers.

Now, I don’t have the time or means to visit conferences around the world all the time, so only one option left: start something new. The result is a brand new group on Meetup.com, Montreal Front End Developers.

Basically, the group will be a starting point to meet and connect with other Front End Developers, by holding periodic meetings (casual bar meetups, presentations/seminars, conferences), all to discuss our favorite Front End subjects: HTML, CSS, Javascript, jQuery, WordPress, web design, plugins, Compass, SASS, Less, browsers, UX/UI, mobile…..the list is endless.

And that’s what it’s really about: Front End Developers hanging out and chat about what they like doing. For fun and education. Cause yeah, we like Front End coding. And so if you do too, join up! You’re even welcome if you’re not from Montreal (but it would help) or if you don’t speak English (that would definitely help).

The post Montreal Front End Devs unite! appeared first on Mark Senff.

Made up your mind already and you want to get started with Sass on your Windows PC? Skip the chit-chat and jump to the 5-step section to install it right away.

Or read on…..

Background

Currently super hot in web development: CSS preprocessors. With a preprocessor, you will write your CSS somewhat differently (shortened code, if you will), some software will convert it to “real” CSS and that’s it: lots of time saved, and your CSS file ends up being a lot more structured and efficient.

There are two main preprocessors to choose from Sass and LESS. Although I would encourage everyone to make a choice for themselves, I personally prefer Sass. You probably don’t need convincing to use a preprocessor (let alone use to a specific one).

The fact that you’re on this page, already tells me you want to use Sass on Windows, and it’s possible that you gave up before you even tried because it looked too much hassle to set it up and get it running. It’s what threw me back a number of times.

But wait, Windows?!

Most developers seem to prefer working on Macs. I’ve tried it myself, but for some reason after a year I decided to go back to Windows. Also, lots of people have a PC in the workplace and are stuck with it (even though I work at a super hip agency, it’s an all-PC environment. Then again, it’s Quebec, where a Front-end Developer is still called a Web Integrator, so who knows!). And, as much as I love Windows myself, it sometimes comes with a particular set of challenges.

Mainly: a lot of great development software is only available for Mac. Here’s a perfect example: watch Chris Coyer’s screencast on preprocessors and it’s almost guaranteed that you want to use CodeKit immediately.

But you guessed it: CodeKit does not have a Windows version. Now what? Don’t give up. Sass is still within reach.

The quest

Sometimes the wrong things can put you off. The first few times I looked into Sass, I didn’t even get to the installation procedure because the instructions told me to install Ruby and type all kinds of things on the command line. Ugh! There’s a reason why MS-DOS is history and the world is run by OS’es that have pretty windows, boxes, and buttons. I’m sure Ruby is great, but I bet there are easier ways too.

All I wanted is have a setup on my Windows PC where I would write Sass code and have that automatically compiled into proper CSS.

After trying left and right (and definitely, I did consider giving up and just go back to Mac), I finally found a Windows solution that looks pretty damn perfect to me, and that I will recommend to every Windows user who wants to get started with Sass without any hassle): Compass.app.

Let’s get on with it, here’s how to do it. It’s so simple, you have no idea.

Get Sass up and running

Here’s the only tricky part: you should set up your Sass and STYLESHEETS folders like this, or else it won’t work (unless you change all kinds of config stuff):

(Note: contrary to older versions, and what’s shown in the image above, more recent versions of Compass.app require you to name the SASS folder in lowercase! Hence, sass and not SASS)

Don’t rename the two folders sass and stylesheets and make sure there is at least one file with the extension .SCSS in your Sass folder (it can be your_stylesheet.scss, partyhard.scss, default.scss, anything.scss!) This is what we will call your Sass file.

Every time you save your Sass file, the resulting .CSS file will be placed in the stylesheets folder, so make sure your site points to that folder as the one containing your CSS.

Hard part’s over already! Let’s finish it up:

1. Get Compass.app. It’s only $10. Don’t be cheap.
2. When downloaded, extract it somewhere. It doesn’t even matter where.
3. Execute compass-app.exe.
4. A dark grey Compass.app icon should appear in your task bar. Right-click and select Watch a folder.
5. Select your_website_project (your entire website folder).

BOOM! You. Are. Done.

So what does it do really?

As the name implies, Compass.app is, well, watching your folder. Every time you save your Sass file (in this example, /Sass/your_stylesheet.scss), Compass.app will notice it has changed, compile it into proper CSS and save it to /stylesheets/your_stylesheet.css. And that’s really what Sass is all about.

Try adding the following lines in your SCSS file and save it:

$blood: #ff0000;
.horror { 
   color: $blood; 
}

Now look in your stylesheets folder and open the file your_stylesheet.css. Your Sass code has been beautifully compiled into nice, clean CSS:

.horror {
   color: red; 
}

See? You didn’t even need to type something silly like:

watch your_stylesheet.scss -n "party" 1138 V /burger

…or something during any single point in the process to get these results. It all happened automatically once you hit the SAVE button.

And that’s it already! It’s all set up now and you’re ready to dive into Sass on your fancy PC!

Advanced bonus feature: FREE mixins

Obviously, that’s not all there is to Sass or Compass. Many things to explore, investigate and discover. However, one thing I want to mention specifically: the mixins that ship with Compass.

Once you’re all into Sass and you have embraced the power of mixins, you can use some of these mixins that are already written for you. No need to write your own mixins for cross-browser rounded corners, box-shading, and so on; they are part of the Compass framework. In other words…..

This would be a perfectly good way of creating a new mixin for box shadows:

@mixin myShadow($x, $y, $b, $c) {
    -webkit-box-shadow: $x $y $b $c;
       -moz-box-shadow: $x $y $b $c;
        -ms-box-shadow: $x $y $b $c;
         -o-box-shadow: $x $y $b $c;
            box-shadow: $x $y $b $c;
}

.module {
    @include myShadow(10px, 10px, 0, black);
}

And it will be compiled into:

.module {
  -webkit-box-shadow: 10px 10px 0 black;
     -moz-box-shadow: 10px 10px 0 black;
      -ms-box-shadow: 10px 10px 0 black;
       -o-box-shadow: 10px 10px 0 black;
          box-shadow: 10px 10px 0 black; 
}

BUT WAIT! In Compass (and Compass.app), this type of mixin is already included, so you don’t have to create a new mixin for this type of thing. All you have to do is load the library and call it the proper way:

@import "compass/css3";
.module {
    @include box-shadow(10px 10px 0 black);
}

You’ll end up with even cleaner CSS, because Compass knows which vendor prefixes are not even necessary anymore:

.module {
    -webkit-box-shadow: 10px 10px 0 black;
       -moz-box-shadow: 10px 10px 0 black;
            box-shadow: 10px 10px 0 black; 
}

Genius.

Lots more

Obviously, this article just focuses on how to get your Sass going on Windows, and that’s where I want to stop; too much additional information in a short time could be overwhelming or confusing. Of course, there is lots more to Sass, and there’s a whole lot more to Compass and Compass.app. Auto-installation of included frameworks is just one of them.

Mac developers often have LiveReload installed to have their browser automatically (and transparently) refresh the page as soon as changes in the code are detected. Unfortunately, I have not found a proper Windows alternative (but keep in mind that this is not an essential tool for Sass development).

Hopefully with this article, the two biggest hurdles (Ruby/command line installation, and Windows software availability) are overcome and any reason to not go ahead with Sass on Windows environment are hereby eliminated. Compass.app has two very, very important features: it works, and it’s easy to setup/use.

Happy Sassing!

Further reading:

- Sass reference
- Musings on preprocessing
- Sass vs. LESS
- Chris Coyier’s screencast on preprocessing

The post Getting started with Sass on Windows, the easy way appeared first on Mark Senff.

2) Apparently I look a little bit like Tom Hardy (Inception, The Dark Knight Rises). Not when he’s playing Bane, the villain in the new Batman movie, but more like this. I’m not sure about this.

3) Creators of web development software such as CodeKit, LiveReload and Coda don’t seem to care much about serving developers who work on Windows.

4) The one movie I am looking forward the most this year, Prometheus, indeed started out as a prequel of Alien, but was stripped from most direct references along the way and is now just a story that takes place in the same universe.

5) A (proper) combination of custom post types and custom fields makes WordPress a lot easier for clients.

6) Lots of drivers use a cell phone while driving, and/or don’t use their flashers to indicate where they’re going. I didn’t care much about this before, but once you walk outside with your kid, you start noticing this a lot more often.

7) #BADA55 is not really that much of a badass color at all.

The post 7 things I’ve learned this week appeared first on Mark Senff.

The reasoning for this is “[...] we have experienced that many authors of (especially mobile) sites only use -webkit- prefixed CSS, thereby ignoring other vendor prefixes and not even including an unprefixed equivalent. This leads to a reduced user experience on Opera and Firefox [...]

(I guess Internet Explorer is not even relevant anymore, despite having a major market share.)

In other words: many web developers are doing it wrong and so Opera will basically support “erronous” coding structure. Faruk Ateş sums it up rather well in more detail, but what Opera is doing is “fixing” the websites that are supposedly breaking the web with their code by rendering poorly authored web pages “correctly”.

When you read it like that, it does seem like this is a proper attempt to move the web forward. But in my opinion, it is the exact opposite. This is not moving the web forward, it actually supports -maybe even encourages- writing “lazy” code. A developer who writes this sort of code, will not be inclined to fix it (for Opera) anymore if it looks fine in Opera anyway, and as a result, he/she probably will continue to code this way.

I understand why Opera made this decision -to give Opera users a better browsing experience, obviously- but I just disagree with it. Of course, -webkit-prefix support in Opera absolutely doesn’t make any sites break more (on the contrary), but it does break overall web progress. This is not working towards the solution of a problem; it’s surrendering to it, advocating it and caving in.

HELPING OPERA USERS…ONLY THEM

So what if a site looks bad in Opera because the author did not code it well? There are millions of examples where improper code is making things look bad in Internet Explorer 6/7/8 (despite the browser bugs itself, but that is a different story). In the past 2 years, developers have stopped supporting IE6 and IE7 in an attempt to say “That’s it, enough is enough. We’ve supported your prehistoric browser long enough, it is now time to upgrade. If you choose to keep living browsing in the past, it will have some consequences“. Giving the IE6/7 users some tough love. If we would keep spending time on making our sites look good in IE6/7, we’d not be making any attempts to move the web forward.

Supporting the -webkit-prefix in Opera because authors are lazy is almost the same thing. Although it might seem that NOT supporting the prefix will “punish” the Opera user for the author’s faults, this is not the case. If there even is talk of any punishing, it’s the author who’s punishing his/her users, and Opera should not jump in and say “no worries, we’ll take care of this for you“.

YET ANOTHER ANALOGY

Let’s say the road from NY to LA has a certain speed limit. Anyone who exceeds that limit it and gets caught, gets a fine. Now let’s pretend that Greyhound’s policy is that if one of their bus drivers is caught speeding, the company will step forward and pay the fine. Always. The driver will go free.

This surely won’t encourage the Greyhound drivers to stick to the rules and obey the speed limit. Sure it will give the passengers a “better” experience (after all, they end up in LA before the passengers in any other bus), but at what cost? The end result is that the drivers will continue to break the law, simply because they (or anyone else for that matter) won’t be punished for taking those liberties.

That can’t be right.

It’s the same with this situation — Opera is telling authors that it’s OK to write “lazy” code, because their browser will render it properly anyway and it will give Opera users a better experience.

IT’S ABOUT THE ENTIRE WEB

Come on, Opera. It’s great that you have the best intentions for your own users, but this should not go at the expense of progress of the entire web. Take a stand to tell web authors that it’s not OK to write bad code, and that if they continue to do that, their users will suffer from it.

If Microsoft can show web authors to stop supporting IE6 simply because phasing out IE6 is simply better for the web, you can show authors your support to come up with proper code. And that’s really, really easy to do: by not supporting -webkit-prefixes.

I admire Opera’s intent to make this whole thing great for their users. But creates a disadvantage in many other areas. OK, it’s not directly “breaking the web”, but it’s encouraging/supporting authors to. And these authors should just code properly (includes adding other prefixes than just -webkit-), if they want to do it right.

Further reading:
- .net Magazine: Opera confirms WebKit prefix usage
- Faruk Ateş: Opera Confirms WebKit Prefix Usage

The post Opera to support -webkit- prefixes appeared first on Mark Senff.