1. Responsive to ambient light with Media Queries and CSS variables

    Media Queries Level 4 are super exciting. In combination with Custom Properties (aka CSS Variables), they can help respond to the user’s environment in a very elegant way.

    Let’s say we want to boost the contrast when the environment is bright to make text more readable.
    On the other hand, when reading the content at night (or in a dark alley, as I am sure you often do), we want a dark background, easier on the eyes. Here’s what it could look like in code, using light-level Media Queries:

    :root {
        --body-copy: #555;
        --body-background: #eee;
    }
    
    body {
        color: var(--body-copy);
        background-color: var(--body-background);
    }
    
    @media (light-level: dim) {
        /* Night time… light text on dark background */
        :root {
            --body-copy: #eee;
            --body-background: #333;
        }
    }
    
    @media (light-level: washed) {
        /* Boost contrast in bright environment */
        :root {
            --body-copy: #000;
            --body-background: #fff;
        }
    }
    

    And here is what it would look like in browser depending on the light level:

    Adaptive to ambient light levels with CSS Media Queries and custom properties

    I think you can already accomplish this effect with JavaScript in some browsers, but isn’t that more elegant when done with CSS?

  2. In his presentation at O’Reilly Fluent Conference, Dan Tocchini goes through the weaknesses of current CSS tools for layout and then explains how GSS, Grid Style Sheets solves complex layout problems.

    "GSS reimagines CSS layout & replaces the browser’s layout engine with one that harnesses the Cassowary Constraint Solver — the same algorithm Apple uses to compute native layout.

    Very promising!

  3. On “Responsive design works best as a nip’n’tuck”

    DHH wrote a very interesting post about his view on Responsive Web Design. He says:

    By going with dedicated templates, we don’t have to include needless data or navigation that’s going to be hidden by the responsive rules. We have less variables to think about on the individual page. It’s just a simpler workflow where it’s easier to make changes without considering a smather of side effects.

    So the next time you’re marveling at a responsive design that’s able to make the best use of a 27” iMac at full screen and a fit neatly on a 3.5” iPhone as well, you might want to ask yourself why you’re trying to make one performer do so many tricks.

    I totally agree with his view. Being responsive should be secondary to being fast, maintainable, and beautiful.

    At the Guardian, Responsive Web Design has been sold as such a golden principle that we would not even try to serve different templates depending on what type of device our readers are visiting us.

    I wish we could try RESS or Responsive Delivery instead of building very complex responsive templates that become more and more fragile and slow down mobile performance.

    As I wrote a few weeks ago: RWD is not the answer, it is only part of it.

  4. Improving Sass code quality on theguardian.com →

  5. Net Awards: Sass “game changer of the year”

    Sass winner of the Game changer of the Year award at the net awards
    Friday evening was Sassy at the Grand Connaught Rooms!

    Friday, Sass won an award at the Net Awards, a ceremony that rewards the best technologies and individuals in the industry for their achievements. It doesn’t really mean anything, but what a great party!

    Although I think this type of competitive event is a bit wanky in our industry, let’s celebrate, and then take a step back to see why Sass won this award…

    Why is Sass a game changer?

    Large companies now openly use CSS pre-processors. In 2013 the discussion fully shifted from “Should I use a CSS pre-processors?” to “What CSS pre-processor should I use?”. Sass’ maturity, support, robustness and power have made such tools acceptable for teams that want a truly reliable front-end stack.

    What people don’t necessarily know, it’s that Chris and Nathan (the two current core developers of Sass) are included in discussions about new features with the CSS Working Group directly. What this means is that Sass can be a ground for experimentation, and if something is portable to CSS, it might get standardised by the W3C.

    CSS Custom Properties (aka CSS variables) are being implemented by browser vendors as we speak. I hope we can see selector nesting and mixins standardised at some point.

    Sass 3.3 was recently released. With all the great features bundled in this new version, I think it’ll be an even bigger game changer in 2014.

    Thanks to the community who voted for Sass! And most of all, a massive thank you to Hampton, Nathan and Chris. Guys, this award is yours!

    Kaelig holding the Game Changer of the year Net Award
    I wore a tie to collect the award. That’s how far I’d go for Sass.
  6. On April 24th, I spoke at Front-End London about how we bridge the communication gap between developers and designers at the Guardian.

    Here are a few resources I mention during the talk:

    A massive thank you to the organisers, Made by Many, for welcoming me at this event where I got to meet a lot of passionate developers.

  7. How the BBC should practice Responsive Web Design

    Tom Maslen writes:

    UX need to alter how they perceive responsive web design, they need to address the scenarios of hostile browsers, tiny screens, slow connection speeds and touch inputs by default. Responsive web design isn’t about mobile or desktop, rather its about adopting a more flexible approach to the web. It’s about accepting that we never really had any control over how the user consumed our content. And instead of trying to force users, browsers and their internet connections to work how we would like them to, its about designing an experience that moves in the same direction as the web, using the flow of the web’s current to move faster to our destination of larger audiences.

    Read More

  8. “In 2012 GitHub started using Sass. What started as an experiment in internal apps has become our preferred way to build and style our web applications. In this talk I’ll cover how we did it, what we’ve learned, performance tips, and what we think constitutes good code. We even use Sass when designing for native apps.”

  9. RWD is not the answer, it is just part of it

    Today, I tweeted:

    Following this tweet, I was asked by @lhid to provide some context. Here we go:

    Recently, responsive web design seems to have become the default strategy for a lot of large redesign projects. And they seem to be quite successful so far! Good for them.

    When building a responsive website and it is successful, we could mistake RWD for the reason behind its success. If we measure success by comparing a new shiny responsive site to crappy, old desktop and mobile sites, in a space where mobile and tablet usage is growing at an unprecedented pace… Of course the new responsive site will perform well.

    Recent redesigns reveal RWD shows good results when limited to mobile and tablet. Unfortunately it struggles to provide an optimal, clean and light output on desktop at the same time. Responsive sites tend to use cutting edge web technologies that may leave a lot of our desktop users behind (especially those in corporate environments). Can we afford to lose these desktop users so that we can satisfy more mobile and tablet users? And if we wish to support these older browsers, can we accept the hit on mobile performance that might flow from all the extra code? These are so many hard choices we should not have to constantly make…

    I have faith RWD will make sense in the future as a global strategy, but not today. Our tools and processes are too young and too poorly capable to help us delivering truly great experiences to all of our users on a fully responsive website. Design tools, web standards, browsers, development techniques and advertisement: they all need to mature a lot before RWD shows what it really is capable of. I also have hopes that the web will catch up with apps in many regards, as native apps are known to be a much higher engagement driver than websites (which is why they are still part of today’s equation).

    Responsive Web Design is not the answer, it is just part of it.

    There are viable alternatives to fully responsive websites. I’d encourage building multiple experiences on the same core architecture, catering for both users and business needs, respecting content and feature parity across platforms, using tools and processes we already know. It can help us understand technology and master new processes in agility, so that we are ready when the rest of the ecosystem finally is too.

    In the mean time, I really like the idea of a partially responsive site with dedicated experiences for the parts where RWD fails to provide an acceptable experience. If I have the chance to test this approach at the Guardian, I will write on this subject in the next few weeks.

  10. In his presentation at Take Off 2014, Patrick Hamann presents the problems front-end engineers are facing with CSS when developing high performance web applications. He goes through the techniques we use at the Guardian to stay off the critical path, improving the perceived performance for our users.