Tag Archives: css

Progressive enhancement does not mean “works when JavaScript is disabled”

This topic came up last Sunday when we were recording an episode for WeCodeSign, but the episode will take two weeks to be published, and it will also be in Spanish, so unless you are able to follow my quickly spoken Spanish, you will miss my Important Insights™ on this topic. Which is why I’m writing about it here.

Apparently there’s a misconception in which progressive enhancement has been fully equated with “works when JavaScript is disabled”. That is not the case, but I could see how someone who hasn’t been programming their entire life and is lost on the fire between the two sides will be really confused.

Continue reading Progressive enhancement does not mean “works when JavaScript is disabled”

ColdFront 2016

I spoke at ColdFront in Copenhagen last week. I joked that I just accepted the invitation because I wanted to go back to Copenhagen, and it actually wasn’t far from the truth as it’s a lovely city and I had a great time when I went there for At The FrontEnd last May: going through the airport is easy, the trains and metros are spotless and easy to buy tickets for, the city is beautiful in its flat Nordic way (Stockholm and Oslo are quite hilly), lots of interesting design stuff to look at, people were super kind and nice to me at every single point, attendees were really polite and so on and so on. How would you not want to go back to a place like this?

So when Kenneth reached out to see if someone could talk about Servo and given that I was working on Servo this summer, it sounded like the Perfect Plan.

Fast forward a few months, and I was in Copenhagen again.

I unfortunately had to miss the first talks of the day as Perfectionist Sole was obsessing over her talk and her slides, but what I saw was really interesting. It was a very good exercise of curation.

Bruce Lawson delivered a very interesting talk loaded with facts about how to deliver the web for everyone—not just rich people on the Western world! Lots of technical insights about Opera Mini optimisations and infrastructure (this was fascinating), lots of research insights as to how do people with unreliable expensive networks use their phones and data plan, etc. Building Proper Web Apps (my new rebranding for PWA, haha) is the answer to these issues. So… learn your tools for a brighter, speedier and more reliable future!

Then there was the break in which we tested our laptops with the A/V system. It turned out that the system was having some fun and introducing random glitches and red jitter so things could occasionally look funny. I was happy with the aesthetics but “sadly” the technicians fixed it during lunch—while we were enjoying the tacos and rye bread sandwiches outside!

It was then the turn for Mathias Bynens who talked about ways in which your browser can be fingerprinted via timing attacks, and other terrible things that left all of us really scared. Good talk explaining complex topics quite clearly.

I talked about Servo and how it is solving many problems, one at a time. More to come…

Glen Maddern talked about strategies to avoid ending with “😈 Demonic CSS 😈”. He suggested a number of design ideas and even ‘tricks’ that you can actually use in most browsers (like currentColor), without having to add CSS preprocessors to a project. I think a gist could be: Just because you can write complicated stuff doesn’t mean you should. He also has started a series of screencasts where he talks about similar front-end topics in his funny and approachable way, be sure to check it out: Front End Center.

Finally Estelle Weyl talked about the need to go back to basics—again, to know your tools—for front-end developers. She asked urged people to reconsider bringing in another JS framework into a project if whatever they wanted to accomplish could not be done in a simpler way with “vanilla” JavaScript, and showed a few examples of ways front end developers are reimplementing things that the browser already provides support for, due to ignorance.

At the end of the talks, the two main organisers Kenneth and Daniel went on stage to tell us a bit about the history of the conference, how they started it, the debt they accidentally incurred in last year and how unhappy their accountant was, the terror of not selling tickets, and how this would be the last conference as Kenneth now lives in Vancouver and it’s very hard to organise a conference when you live so far away.

At this point everything got very emotional but fortunately Daniel and Kenneth hugged and said thanks, before we all broke down and started to cry. Then we clapped to thank them, Kenneth and Daniel took a deep breath and asked us to reposition to take the JS family photo, and we were off to the closing party which was at a well stocked brewery like 40 metres away (I had an alcohol free drink following my self-pledge).

It was lovely to talk with all the people there… I mean—I didn’t talk to all of them, but to the ones I talked to! Plus the weather was quite nice and we could be outside instead of yelling at each other inside the loud brewery.

Sadly, there won’t be another Cold Front so if you want to relive this, check the talks when they are published in their website. Or watch the talks from previous years in their YouTube channel!

Thanks for the lovely conference!

Web Animations: why and when to use them, and some demos we wrote

There’s been much talk of Web Animations for a long time but it wasn’t quite clear what that meant exactly, or even when could we get that new thing working in our browsers, or whether we should actually care about it.

A few weeks ago, Belén, Sam and me met to brainstorm and build some demos to accompany the Firefox 48 release with early support for Web Animations. We had been asked with very little time, but we reckoned we could build at least a handful of them.

We tried to look at this from a different, pragmatic perspective.

Most graphic API demos tend to be very technical and abstract, which tends to excite graphics people but mean nothing to web developers. The problem web developers face is not making circles bounce randomly on the screen, it is to display and format text on screen, and they have to write CSS and work with designers who want to play a bit with the CSS code to give it as much ‘swooosh’ as they envision. Any help we can provide to these developers so they can evaluate new APIs quickly and decide if it’s going to make their work easier is going to be highly appreciated.

So our demos focused less on moving DIVs around and more on delivering value, either to developers by offering side by side comparisons (JS vs CSS code and JS vs CSS performance) or to end users with an example of an style guide where designers can experiment with the animation values in situ, and another example where the user can adjust the amount of animation to their liking—we see this as a way of using the API for improving accessibility.

You can also download all the demos from the repo:

git clone https://github.com/mozdevs/Animation-examples.git

And should you use CSS or should you use JS? The answer is: it depends.

Let’s look at the same animation defined with CSS and JS, taken straight from the CSS vs JS demo:

CSS:

.rainbow {
    animation: rainbow 2s alternate infinite;
}

@keyframes rainbow {
    0% { background: #ff004d; }
    20% { background: #ff77ab; }
    50% { background: #00e756; }
    80% { background: #29adff; }
    100% { background: #ff77ab;}
}

JavaScript:

let el = document.querySelector('.rainbow');
el.animate([
    { background: '#ff004d', offset: 0 },
    { background: '#ff77ab', offset: 0.20 },
    { background: '#00e756', offset: 0.5 },
    { background: '#29adff', offset: 0.80 },
    { background: '#ff77ab', offset: 1 }
], {
    duration: 2000,
    direction: 'alternate',
    iterations: Infinity
});

As you can see, this is fairly similar.

CSS’s syntax for animations has been with us for a while. We know how it works, there is good support across browsers and there is tooling to generate keyframes. But once the keyframes are defined, there’s no going back. Modifying them on the fly is difficult unless you start messing with strings to build styles.

This is where the JS API proves its worth. It can tap into live animations, and it can create new animations. And you can create animations that are very tedious to define in CSS, even using preprocessors, or just plain impossible to predict: imagine that you want custom colour animations starting from an unknown colour A and going to another unknown colour B. Trying to pregenerate all these unknown transitions from the beginning would result in an enormous CSS file which is hard to maintain, and would not even be as accurate as a newly created animation could be.

There’s another advantage of using the Web Animations API versus animating with a library such as tween.js—the API is hardware accelerated and also runs on the compositor thread, which means incredibly smooth performance and pretty much perfect timing. When you animate DOM elements using JavaScript you have to create lots of strings to set the style property of these DOM elements. This will eventually kick a pretty massive Garbage Collector, which will make your animations pause for a bit: the dreaded jank!

Finally another cool feature of these native animations is that you can inspect them using the browser developer tools. And you can scrub back and forth, change their speed to slow them down or make them faster, etc. You cannot tap into JS-library-defined animations (e.g. tween.js) unless there’s support from the library such an inspector, etc.

Essentially: Web Animations cheat by running at browser level. This is the best option if you want to animate DOM elements. For interpolating between plain values (e.g. a three.js object position vector x, y, z properties) you should use tween.js or similar.

If you want to know more here’s an article at Hacks talking about compositors, layers and other internals, and inspecting with DevTools. And with plenty of foxes!

The full API isn’t implemented in any browser yet, but both Firefox and Chrome stable have initial support already. There’s no excuse: start animating things already! I’m also excited that both browsers shipped this early support more or less simultaneously—makes things so much easier for developers.

With mega thanks to Belén for pushing this forward and to Sam for going out of his internship way to help us with this 🙌🏼

Reading list, 5

13-19th April 2015

  • tableflip dot club by (╯°□°)╯︵ ┻━┻: “We’ve watched mediocre men whiz by us on a glass escalator […] we’re denied opportunities because we aren’t “ready” for them […] It’s time we take our potential elsewhere […] We’re sharing our long memories of all the creeps who’ve hit on us and the cowards who’ve failed to promote us”. Oh wow. This resonates so much with some of my experiences, wow. Yes. More tableflips are in order!
  • Of undocumented Chrome features and unreadable W3C specs by ppk: “this sad state of affairs prevents me from writing tests and reporting their outcome on all these new, exciting technologies”, or why new undocumented APIs without examples are a tragic failure
  • The newly created Web Audio London meetup has published videos with the talks from the first meetup! they are in its YouTube channel
  • There is also a Music Hackspace in London! I haven’t been so I can’t tell how good is it.
  • More music: my pal Andy Lemon made a series of Commodore 64-based covers of 80s tunes
  • Gifsicle – command line animated GIFs. We can always add new tools for our Animated GIF battles. Its website is pretty terse but the GitHub page is more detailed: “it can merge several GIFs into a GIF animation; explode an animation into its component frames; change individual frames in an animation; turn interlacing on and off; add transparency; add delays, disposals, and looping to animations; add and remove comments; flip and rotate; optimize animations for space; change images’ colormaps; and other things”… *swooooooooning*
  • More control over text-decoration by Chris Coyier at CSS-Tricks — where the text-decoration CSS property can be further controlled with three new sub-properties: text-decoration-color, text-decoration-line and text-decoration-style. This is fantastic! I’m going to start using text-decoration-style: wavy everywhere! 😉
  • More CSS! Gradients are sometimes hard to visualise, so Patrick Brosset wrote a tool which would do exactly that. This week, he moved it from codepen to a GitHub repository. Look at it–can you make it better?
  • Despoblados en Huesca – a website that collects all the abandoned towns and smaller settlements in Huesca, an Spanish province. I’m fascinated both by this and by the idea that some people do take over some of these settlements and make them inhabitable again. This notion of self-sufficiency has always intrigued me.
  • DiscoGS – I acquired a Sinology home NAS last week and I have been carefully rearranging and sorting my music collection. This website is a fantastic resource when you really start getting perfectionist and detailed about PROPERLY TAGGING the files.

Native smooth scrolling with JS

There’s a new way of invoking the scroll functions in JavaScript where you can specify how do you want the scroll to behave: smoothly, immediately, or auto (whatever the user agent wants, I guess).

window.scrollBy({ top: 100, behavior: 'smooth' });

(note it’s behavior, not behaviour, argggh).

I read this post yesterday saying that it would be available (via this tweet from @FirefoxNightly) and immediately wanted to try it out!

I made sure I had an updated copy of Firefox Nightly—you’ll need a version from the 28th of October or later. Then I enabled the feature by going to about:config and changing layout.css.scroll-behavior.enabled to true. No restart required!

My test looks like this:

native smooth scrolling

(source code)

You can also use it in CSS code:

#myelement {
  scroll-behavior: smooth;
}

but my example doesn’t. Feel like building one yourself? 🙂

The reason why I’m so excited about this is that I’ve had to implement this behaviour with plug-ins and what nots that tend to interfere with the rendering pipeline many, many times and it’s amazing that this is going to be native to the browser, as it should be smooth and posh. And also because other native platforms have it too and it makes the web look “not cool”. Well, not anymore!

The other cool aspect is that it degrades great—if the option is not recognised by the engine you will just get… a normal abrupt behaviour, but it will still scroll.

I’m guessing that you can still use your not-so-performant plug-ins if you really want your own scroll algorithm (maybe you want it to bounce in a particular way, etc). Just use instant instead of smooth, and you should be good to go!

SCROLL SCROLL SCROLL SCROLL!

Update: Frontender magazine translated this post to Russian.