Before I start, I just want to say that this is not about new features, or features yet to be released. This is about things that have "always" been there, or new stuff that might have not gotten as much attention to some people, or just interesting things or fun facts about the language.

1. The "CSS is awesome" meme

I believe this is the most famous CSS meme out there, followed by the "css family guy" meme. You might have seen this somewhere, in a T-shirt, a mug or a sticker, and everybody can relate to it because it represents the frustration when trying to do a very basic thing in CSS and it doesn’t work properly, but what people don't realize is that the "CSS is awesome" meme is actually a feature, not a bug!

If you had a design software that couldn't to text overflowing a box, you'd be creatively limited and pissed off. CSS Tricks has a big post on the "CSS is awesome" meme if you want to learn more, but this happens basically due to 3 things

• The content doesn't fit into its container
• The container can't expand to fit the content
• The overflow CSS property has its default to visible.

2. Filters and gradients

It's amazing to see how many mainstream effects are possible to be done with CSS nowadays. You find yourself much more amazed if you're old enough to have coded websites using images for gradients, or for border-radius for example. Gradients have native CSS support, and you can actually add multiple gradients and have very fun compositions.

The example below is using the Dublin CSS logo, which has some gradients, and I've also added some cool effects on the codepen below that are now possible with CSS. I've also put some filters that you can play with and see them in action. If you happen to be in Dublin, please look for Dublin CSS events, it'd be really nice to have you there 😊.

3. Emojis as class names (or ids)

If you have been playing around with the codepens I've put here, you might have already noticed that I'm using emojis as class names and ids. HTML is a very powerful language and supports unicode symbols and icons.

I find this one very cool, because it makes your code more fun, but also because it's inclusive, enabling humans that don't use eastern alphabet to have their native alphabet at least for classes and ids on CSS. However, this is not a good practice, and people actually advise against using it, but for fun or on a personal project I'd say it doesn't hurt, right?

4. CSS Units

The CSS units available are pretty cool, starting by the relative ones: percentage, em, rem. The em and rem are relative to the font-size, and the percentage is relative to the parent. Interestingly enough, you can have block elements with widths in em and the font-size they're based on in percentage, then it can reach to a point where there's no parent, and I actually already wrote an article about it, which has the "CSS is awesome" meme as feature image 😄, so I'd recommend you to read it if you want to know more.

Then you have absolute units, like px which is the most used one, but you also have units that are based on physical measures, starting with Points (pt) which is 1/72 of an inch, and or picas (pc)(12 points). These are the less common one, but Quarter millimeters (q), millimeters (mm), centimeters (cm), or inches (in) are used in our everyday life, and on the web is quite useful when you need to print something that has a specific size.

Then there's these two that deserve a codepen, ex, ch: Respectively these are the height of a lower case x, and the width of the number 0. These are not as commonly used or well-supported, and I only see them being used when you have text content using a monospace font.

Lastly I just want to mention the fr unit. It is a short for fraction, and represents a fraction of the available space in a container. There's this great video from Jen Simmons that explains it and what problems it solves in a quite simple way.

5. Viewport Units

This one deserves a topic of its own. Viewport units are the vw (viewport width) and vh (viewport height), and they're a percentage of the viewport, meaning when a block element has a width of 60vw it means this element will have a width of 60% of the device's browser window width (in other words, its viewport width). It's just amazing! Before there was no way of doing this, and we had to use 100% everywhere to try to get this behavior, or use JavaScript. Now it just works!

The only gotcha I’ve experienced so far is, when you content grows a scroll bar will eventually appear, and this will change the vw value, which could cause a side scrolling. What people usually do is to overflow-x: hidden on the container, then this problem won't happen.

6. Alternative unit for rotate

I promise this is the last one about CSS units. CSS transform is an amazing CSS feature that allows you to do lots of stuff, and rotate is one of them. I've used and seen it being used a lot, and the majority of times I've seen it, people were using it with degrees, which is quite straightforward if you had proper math education and learned trigonometry at school.

transform: rotate(180deg); 🙃

However, you can use rotate with other units as well, and the second most common is the rad, short for Radians, and you can have also Gradians (grad). But these are all boring, you can rather use a cool one called turn.

Turn doesn't rely on your math skills, it's just a turn! So if you apply a half turn on the emoji 🙂, it would be rotated to 🙃.

transform: rotate(0.5turn); 🙃

7. CSS variables

They're officially called CSS custom properties, but let's be honest here, everybody call them CSS variables, the same way everybody says ES6 instead of ES2015 😁. This amazing feature brings natively one of the main reasons of using pre-processors: ability to have variables in CSS. Maybe that's why they're so known as CSS variables, but they have a bigger purpose.

There's an @ rule currently in draft called @apply. This pretty much enables mixins natively, which is the second main reason of using CSS pre-processors. CSS custom properties are available in all modern browsers, and they're scoped, meaning they can be at ::root level, or at an element level. You can tweak the codepen below to understand more. Lastly, they can be easily changed with javascript 🤩.

8. Pointer events

The pointer-events CSS property basically allows you to control if an element will react to the cursor or clicks. This one becomes really cool when you need to style something (like a select box) but the element has limitations on styling. You can simply put a div in front of it, disable pointer-events and done 😲. Other example is when you mix images and text, in some cases it may happen that the user wants to select the text but ends up dragging the image. If you disable pointer-events on the image, your problems are gone.

9. Calc

Calc is just amazing when you need to mix units to have a size of something. Say you have a sidebar of 300px width and you want the content of the website to take the rest of the browser width, you can use calc for that:

width: calc(100vw -300px);

You can use calc for other hacks, like having responsive font-sizes without media queries, or designing the medium full-width picture, as this video explains.

10. Shorthand Properties

Some CSS properties, like margin, background, font, allow you to declare groups of values in one shorthand property separated by spaces. This cool thing about CSS is specific to properties like margin and padding, where you have something like this:

margin: 15px 5px 2px 20px;

How do you know which ones is applied to what?

The pic at the top of this post gives you a hint 😉

This Stack overflow question has a list of techniques that the community uses to know which one is which, being the most common one the Clockwise rule.

A lot of people also use the TRouBLe technique, which relies on the fact that the word trouble has letters in an order that reminds the CSS shorthand order. Some other people use the North, East, South, West strategy, which is similar with the clockwise rule. I think the clockwise rule is more universal, I like watches with pointers, some people don't and some people can't understand it, so they might go to the other techniques, you do you 🙂.

Bonus cool thing

This one should've made into the list, but so have other cool stuff. However I'm adding this one anyway because my mind blew the first time I saw it.

Have you ever noticed that, in some websites, when you select some text the color of the selection is different than the default one?! The thing is that you can do this pretty easily with CSS by using ::selection property:

CSS is really awesome

This list could go endless here. As I said, this doesn't focus on the shinny new stuff, but could've been. I could've also included things like animations, 3d stuff, CSS clip-path, which are all mind blowing, or even the CSS Blend Modes. Let me know in the comments which one should've made to this list and I might do a round 2 of this post 😇.

References

• Don’t Use My Grid System or any others, Miriam Suzanne
• CSS is Awesome, CSS-Tricks
• 10 Must Know CSS and CSS3 Resources and Tools, Sitepoint
• Hasty Treat — CSS and JS Pointer Events, Syntax.fm
• CSS the 😎😎😎 Cool Parts, Syntax.fm
• Hasty Treat — Uses for CSS Variables, Syntax.fm
• Hasty Treat — CSS Units, Syntax.fm
• CSS Units, a brief digress, Sheldon Led
• CSS values and units, MDN
• FR Units in CSS Grid, Jen Simmons
• Alternative Units for CSS3 Rotation Transforms, Impressive Webs
• Fun with Viewport Units, Miriam Suzanne
• Viewport units: vw, vh, vmin, vmax, Tim Severien.
• calc() lets you do some real CSS magic, Kevin Powell
• Avoid Emoji as Class Names, Adrian Roselli.
• CSS pointer-events, MDN
• Clip-path, MDN

On 17th and 18th of November 2018 we had our DevFest in Dublin. If you don’t know what DevFest is, I suggest you to look for one near you, because they are community-led, developer events hosted by GDG (Google Developer Groups) chapters around the globe focused on community building and learning about Google’s technologies.

Although they’re supported and driven by Google and their technologies, you can find a lot of relevant knowledge that goes beyond that, if you’re not into Google stuff (which is quite an unlikely scenario these days isn’t it?!). The Devfest in Dublin happens at Google’s office, which is a cool venue, where the GDG Dublin meetups also happen every month-ish.

The 2018 DevFest in Dublin had 250 attendees in a 2 day event. The first day was a full day of talks, with great speakers from different parts of the world. The second day was a Hackathon day, in which we’d use any Google Technologies (preferably the ones tackled the day before) and the theme was “ Ireland Connected”.

First Day — Talks

People’s experience in conferences are different because of several aspects, like different backgrounds or interests, but on top of that, having more than one track increases the variety of what people would think about #DevFest18. This year we had 3 tracks with a mix of Android, Web and Cloud technologies.

I’ve focused on talks about Web, however the ones that have gotten my attention more were Marc Cohen’s Superpower User Manual, and Grant Timmerman’s All About Apps Script, being the latter the tech I used in my Hackathon project in the Second day. At the end I’ll link the max amount of slides I can find =)

Second Day — Hackathon

As said above, the hackathon had very few rules. Your idea should be related with “Ireland Connected” theme and use any Google Technologies. The teams were formed at 10:30am and the ideas were presented at 5:30pm. I don’t remember what the winner’s project were about in detail but their general idea was to connect people using cloud technologies. The winners earned a Google home device, being the first place 1 each team member, and second place one for the whole team (so they can fight to death for it :D ).

My team didn’t win any award, but we won the laughs. Our idea was to incorporate silly things into Google Sheets using App Scripts to be a resource for bored people. So we’d fetch information about the weather, funny random gifs, random jokes or phrases etc. Below you can see who it worked:

When we presented, everybody laughed at the random things appearing on top of a very boring spreadsheet. We thought that connecting Ireland was related to human feelings, and being bored is a frequent one, depending on what you’re doing.

Slides

• Building a Note Progressive Web App powered by Firebase, Juarez Filho: https://bit.ly/firelist-angular-slides
• Notions about Motions, Maurice Gavin: https://github.com/mauricegavin/NotionsAboutMotions
• Superpower User Manual, Marc Cohen: https://bit.ly/mco-superpowers
• All About Apps Script, Grant Timmerman: https://github.com/grant/talks
• Using Machine Learning APIs in the Google Cloud, Marc Cohen: https://g.co/codelabs/dublin
• Android Room with a View, Henna Singh : https://codelabs.developers.google.com/codelabs/android-room-with-a-view-kotlin/

I’ll update the list if I find more =)

Last year I changed my Javascript linter from JSHint to ESLint. I wasn’t so sure why this change would improve the project so I started my work by reading about both tools. I found some advantages on ESLint over JSHint, and I want to highlight here:

• JSHint rules are a bit confusing. Some of them do something if true (enforcing) and others do something if false (relaxing)
• ESLint has way more built in rules
• Some ESLint rules are more flexible and configurable
• ESLint makes it possible to write your own rules
• ESLint has more support for JSX and ES6 (we’d need these at some point)
• ESLint has a clearer error messaging, showing which rule is causing the error

Considering that the project was big, I couldn’t just turn off one tool and enable the other. I had to go through every rule on JSHint and configure its equivalent on ESLint. I found some sources on how to do that, but I decided to double check each rule. Also because I wanted to learn a bit more.

The project was using an older version of the JSHint default configuration file, as I went to JSHint website and saw more recommended rules there. So I mapped each rule enabled on the project JSHint file to ESLint ruleset and enabled all recommended ESLint rules that didn’t require refactoring .

The rules in JSHint that I didn’t find an equivalent on ESLint were:

• maxerr: Maximum error before stopping
• es5/esnext: They’re not rules in ESLint but environment sets.
• moz: Allow Mozilla specific syntax (extends and overrides esnext features). Unless you develop specifically for the Firefox web browser you don’t need this option

I borrowed the ruleset, changed a little bit (because it was tailored for this specific project) and used in my website. I’ll probably use this ruleset in some other projects because it’s very clear and explicit (doesn’t use “extend or plugins”), so I can easily use it and mix it to fit the needs of these future projects. Here’s the comparison between all the rules of JSHint and ESLint:

References

[Sitepoint] A comparison of JavaScript Linting Tools: https://www.sitepoint.com/comparison-javascript-linting-tools/

[Slant] JSHint vs ESLint: https://www.slant.co/versus/8627/8628/~jshint_vs_eslint

[vs-archive] JSHint rule mapper: https://github.com/vs-archive/eslint-rules-mapper/blob/master/lib/jshint/jshintRulesMap.js

[Rico Sta. Cruz] cheatsheet for JSHint: http://ricostacruz.com/cheatsheets/jshint.html

[Petar Bojinov] JSHint error messages: https://gist.github.com/pbojinov/9011392

Click here to share this article on LinkedIn »

It is very exciting to work with the web because it’s continuously evolving and we always have something new to learn. One of the most important things when it comes to software engineering on the web is performance, and in this post I’ll describe how some of these new technologies can improve the performance in your application.

Since these technologies are not very new (aging in the web is a bit faster than in real life) they have a very good browser support, meaning that you can implement them in your software today.

Performance on the web

Much has been preached about network performance. You have to minify your JS and CSS files to ease the download, you have to compress your images, you have to enable gzip, you have to enable caching etc, but not much word on what’s nice to do after that.

Let’s understand what happens when you request a page in your browser. Giving a short and simplified response, if the request is successful and you requested a HTML object, the browser will:

• Get the HTML;
• Parse the HTML and identify external resources;
• Download (server or cache) resources: images, fonts, JS, CSS…
• Parse / Render these resources (some of these tasks are concurrent, which may block the rendering)

This critical rendering path is the responsible for making you see a blank page when you hit enter in the browser address bar. This name is quite nice because it’s a path, from the moment the browser receives the text from the server, identifies it as a HTML document, parses it, encounters the resources, downloads them, builds the render tree, then mounts the layout of the page and paints it.

It’s critical because if it’s not optimized it does extra work before showing something to the user. It makes sense to wait for all the CSS to be applied to show the page to the user, because otherwise the user would see content in a way and then it’d suddenly change when the CSS is applied. Same for the font. But for the Javascript it doesn’t make sense. That’s why you should always defer or async your script tags.

Things are done in the main thread in the browser, so while your JS is being executed, it occupies the main thread and it blocks the user’s interaction with the page. There are two nice talks about how JS works in the browser, one by Philip Roberts and the other by Jake Archibald.

There are plenty of techniques to reduce the work on the critical path such as lazy load the images that aren’t in the user’s view, inline the CSS necessary to render the above the fold part of the website and lazy load the rest (via JS), lazy-load or load asynchronously the JS for the website, just to name a few. As mentioned in the beginning these are very famous techniques, but what’s next?

After you download the resources, they still need to be parsed and applied/executed. So the bigger your JavaScript is, the more the browser will work, it doesn’t matter how much you lazy load it. It might be fine to parse/eval this amount of code in your laptop, but mobile devices (and old devices in general) might struggle with that.

While you might have 8+ GB of RAM in your Desktop, with an i5 or i7 very powerful CPU, you’ll have between 2 to 4 GB in a Samsung device, even less in an iPhone, with a not that powerful CPU and you need to share this power with the opened apps, OS, and to add on top of that, mobile devices:

• Are not plugged (JS drains battery);
• Have less storage, less memory, less powerful CPUs
• Less reliable connection
• However they have very powerful (usually up-to-date) browsers

Perceived Performance

I believe that by now you’ve noticed the importance of clearing the critical path. A result of a short and smooth critical path is an improvement on the user’s perceived performance:

• People primarily consume the web visually;
• We have to focus on the content the user sees first (so called above the fold);
• Delay/async/defer download of resources: images, fonts, JS and CSS;
• Worry about Render blocking: JS and CSS;
• Be careful with Parsing & Painting

Paul Irish gave a short talk in 2015 on how users perceive the speed of the web. In this talk he mentioned the RAIL model.

So first the page loads (ideally in about one second), the user spend some time seeing what’s in the screen, then they interact with the screen by scrolling for example, then they click or perform some action, this might go to another page and the rhythm goes on and on.

You might not get your page to be rendered and interactive in 1sec but you should measure what could be better or if your website got worse after a few releases, and here are some tools:

• WebPagetest
• GTmetrix
• Page Weight (imgix)
• Lighthouse
• DevTools (i.e. Chrome > DevTools > Performance Tab)
• PWA checklist

Remember:

While you may not support non-JavaScript users, your users are basically non-JS while they’re downloading, parsing and executing your JS files

Estelle Weyl — JS Frameworks

Write Less Code

It feels like I’m trying to run away from the problem when I say “write less code” like “If there’s no code, there’s no bug,” but there’s some truth in this statement. You might not need jQuery or that other lib that you’re including just to perform a small job.

JavaScript has evolved a lot in the last couple of years and has implemented loads of things natively, so think twice before adding code to your app.

There is another approach to this, which is not exactly writing less code but delivering less code. Let’s say you work on an eCommerce, it’s very likely that you won’t need your JS code for the checkout in your item details page, or code for the search/filtering in your home page. It’s a technique that Katie Hempenius mentions in her talk on Smashing Conf (London 2018) that might be easy for you to implement.

But of course that the “no code no bug” is a benefit earned by writing less code. It’s less things your team need to care about. This code might also be dead code, so the user is downloading it to never use it, and a new joiner might think that it’s not dead, try to use it and won’t understand why it’s not working properly.

If you want to check how many code is being delivered but not used, try Chrome > More Tools > Coverage.

Grid Layout

(and flexbox as well)

If you’ve already been introduced to Grid Layout (I recommend you cssgrid.io) you already know that you can throw away any grid framework and use native solutions. Therefore the rule writing less code by leveraging native can be applied to CSS as well.

The golden rule for deciding to use display grid or flex is, if you need to layout the elements in 1 dimension, you can use flexbox, if you need to control the elements in 2 dimensions then better use grid.

Of course it’s deeper than that but you can start by asking yourself this. Also, they are not self-excluded, you can combine both types of displays, and it’s incredible what you can do with them.

Grid/flexbox can replace CSS frameworks but it can also replace some JS code, for example Foundation equalizer, (or any equalizer script), and Masonry. I Know Grid layout is not a replacement for Masonry, but I’ve seen some websites using masonry and I’m pretty sure that they could be using grid instead.

What about support? Well, you can work on some fallback strategy, but if your big enemy is Internet Explorer, you can have the basics working fine with some prefixes:

So far this is working quite well for me. I’ve used SASS to have some mixins and get my life easier

@mixin grid {

    display: -ms-grid;

    display: grid;

}

@mixin grid-template-columns($value) {

    -ms-grid-columns: $value;

    grid-template-columns: $value;

}

@mixin grid-template-rows($value) {

    -ms-grid-rows: $value;

    grid-template-rows: $value;

}

@mixin grid-column($value, $span: null) {

    -ms-grid-column: $value;

    @if ($span) {

        -ms-grid-column-span: $span;

        grid-column: #{$value} / span #{$span};

    } @else {

        grid-column: $value;

    }

}

@mixin grid-row($value, $span: null) {

    -ms-grid-row: $value;

    @if ($span) {

        -ms-grid-row-span: $span;

        grid-row: #{$value} / span #{$span};

    } @else {

        grid-row: $value;

    }
}

/**** in the elements ****/

.container {
  @include grid-template-columns(1fr 1fr 1fr);
}

I’m currently using it in my wife’s blog, if you want to check this in your device, here is the link: https://mariaquerviajar.com (Portuguese content).

Removing Javascript responsible for the layout is not only good because we’re reducing the codebase, but also because we’re executing less Javascript. Masonry and Equalizer have listeners on the window resize event. Other libs are even worse and have listeners on the window scroll. By removing such code we’re also making the interaction and flow more fluid.

Progressive Web Apps

Progressive Web Apps is a term used to define applications served through the web that leverage technologies brought by new browsers without loosing support for the old ones.

It’s progressive because you can progressively add new features without breaking the experience on browsers that don’t support it. It’s web because it’s served through the internet via a link, like any website. It’s app because it behaves like an app on browsers and operating systems that support it.

If you have watched more than 2 talks about PWAs you probably have seen the definition “the best of the web combined with the best of apps”, but indeed it’s a very good definition. To start with PWA the first thing you’ll need is HTTPS. This is a blocker and should be prioritized even if you’re not planning on transform you website into a PWA.

Enabling HTTPS brings several benefits beyond security, such as PWA (of course) and new browser APIs. It’s nice that those browser APIs (mentioning a few later on) are only allowed under HTTPS, because they are powerful and need to work in a more secure environment.

PWA is a set of technologies, you can choose what to implement and when. There are some talks that share some strategies like From Website to Progressive Web App (GDD Europe ’17) or Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017).

If you want to learn more about PWA, there’s a free introduction course on Udacity but the feature I want to mention in this post is Service Worker. Service Worker is basically a programmable network API that gives you power to control the requests on your app. It runs on background and is the bridge between the browser and the network.

With Service Worker you not only have a much better cache strategy, but also a much more reliable experience, that improves both the perceived performance and the actual performance.

The time has come to put FIRE on your old code

Having so many new things makes us feel like we need to put FIRE on our codebase and start everything from the scratch, doesn’t it? Well, there’s no need for that, we can progressively enhance our app like everything on the web. But the intention on using the word FIRE (and in upper case) is that PWAs use this other acronym to dictate how the experience should be:

Fast: Here comes all the performance techniques to mitigate the friction between network and your app

Integrated: By adding a Web App Manifest you can have your web app behaving like an installed app.

Reliable: By exploring all the power of Service Worker, managing cache, slow connections and network errors.

Engaging: By having push notifications you can lead the user back to your app.

HTTPS

By enabling HTTPS you’re not only providing a more secure experience, but you can also enable several APIs that are in the browser, starting by PWA, and to name a few others:

• Geolocation API
• Media Capture and Streams API (access to user’s audio visual input)
• Encrypted Media Extensions
• Bluetooth API
• Clipboard API
• Push Notifications
• Payment API
• Credentials API

Conclusion

I hope that this post has extended your vision on web performance beyond the well known barrier app vs network, and that this help you to rethink or improve your app architecture. Here’s this post checklist:

• Do all the homework to improve your Front-end performance;
• Clear the Critical Path;
• Write Less Javascript: By removing dead code, replacing libraries with native JS functionality, splitting your app.min.js and delivering only what that specific page needs;
• Write less CSS: by refactoring old code with new CSS features and replacing frameworks by native CSS;
• Use Service Workers: to manage your cache better, to have a fallback when network is off or bad. Leverage PWA to improve your user experience;
• Split your codebase. It’s easier to read, to reason about, to maintain, and less likely to introduce bugs.

It’s a daily progress. You could do like I said earlier and put fire on everything and start over, but it’s more likely to have an upgrade strategy in your team and technical improvements daily efforts.

It’s also good to have everyone in your team aligned with best practices and new technologies so they can implement them in a daily work, while developing any feature or solving any bug in your application.

Improving performance is a Journey. Lots of small changes can lead to Big gains. Addy Osmani.

References and useful links

• ViewSource Conf — London 2017
• Rachel Andrew on Into the Weeds of CSS Layout — (Slides)
• Jake Archibald on The Event Loop
• Philip Roberts: What the heck is the event loop anyway? | JSConf EU 2014
• Paul Irish — How Users Perceive the Speed of The Web (2015)
• Katie Hempenius on Improving Page Performance in Modern Web Apps — (Slides)
• Jen Simmons — Revolutionize Your Page: Real Art Direction on the Web. (ViewSource 2016)
• The Experimental Layout Lab of Jen Simmons
• https://gridbyexample.com
• https://cssgrid.io
• Rachel Andrew — Grid “fallbacks” and overrides
• MSDN — Grid layout for IE10 and IE11
• Eric Elliott — Native Apps are Doomed
• Progressive Web Apps — MDN
• PWA checklist (Google developers)
• Mariko Kosaka — Service Worker, what are you?
• Intro to Progressive Web Apps — Udacity
• Mythbusting HTTPS (Progressive Web App Summit 2016)
• From Website to Progressive Web App (GDD Europe ‘17)
• Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017)
• Payment Request API
• PaymentRequest.show()

For Fun

• http://www.flexboxdefense.com
• http://flexboxfroggy.com

How web performance, CSS Grid and PWA are related was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was afraid of writing this because it sounds too obvious to everyone that has some experience with CSS but I thought again and as it wasn’t obvious to me at a first sight it might not be obvious to someone else out there as well. I was not sure to write it also because there are already lots of content on this subject already available, but if we start worrying about that, we’ll never write anything. Actually you can scroll down to get lots of good references on this subject, so this article can be helpful in a way or another.

My research on the topic started when I was reading foundation stylesheets and realised that they use em as width unit in their media queries. I knew that em is relative to the font size of the element, but the element I was looking at had font size of 100% (which means 100% of the parent element) and when I started going up and up, I reached the html tag, that has font size of 100%. Then I thought: 100% of WHAT?!

I’ll not detail the explanation of the measures here because it’s already detailed in the links that I’m ‘attaching’ as references but, in summary, the root element receiving font-size: 100% and the em or rem measures are related. They all rely on an absolute length, and when it’s not explicit, it is defined by the browser.

In chrome, when you go to settings > show advanced settings > Web content > Customise fonts, you’ll see information about the default font-size, and this value will be the base for the relative lengths calculation. You can find the same information on Firefox by going to Preferences > Content, and I’m pretty sure that this setting is easy to find in any browser so I’ll stop on these two.

Using relative measures is a good practice and you can get to this conclusion quite intuitively. When you’re reading, let’s say your kindle, and you want to change the size of the font to have a better experience, it’s easy and straightforward. The same thing should happen when you’re in your browser and want to change the size of the visual elements you’re seeing.

Using EMs in Media Queries

This whole discussion leads me to the beginning, where I saw Foundation using EMs in Media Queries. I indeed thought it was weird but, as Smash Magazine’s Article says, they react to the font size of the browser that the visitor is using. This is actually logical when you think about it. If they reacted to the font size in the CSS, you could actually disable a media query from within a media query by increasing the font size.

There are some discussions if it’s really necessary/good standard to base your measurements on the browser’s default font size, and what I realised is that it seems quite a good standard to follow. You can read what people say about that and take your own conclusions, but it seemed really good for me to make everything depending on this unique value (browser’s default font size) to draw your website.

References

1. [Foundation] Media Queries: http://foundation.zurb.com/sites/docs/v/5.5.3/media-queries.html
2. [MDN] CSS Lengths: https://developer.mozilla.org/en/docs/Web/CSS/length
3. [w3c] The amazing em unit and other best practices: https://www.w3.org/WAI/GL/css2em.htm
4. [Stackoverflow] CSS: 100% font size — 100% of what?: https://stackoverflow.com/questions/6803016/css-100-font-size-100-of-what
5. [Zell] REM vs EM: https://zellwk.com/blog/rem-vs-em
6. [Nicolas Hoizey] People don’t change the default 16px font size in their browser: https://nicolas-hoizey.com/2016/03/people-don-t-change-the-default-16px-font-size-in-their-browser.html
7. [Smash Magazine] : https://www.smashingmagazine.com/2013/03/logical-breakpoints-responsive-design/

CSS Units, a brief digress was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years ago there was a fever about these web pages with a button at their top, and when you click it shows a menu in a slider effect. They were (and still are) called Hamburger Menus. Even though there are some articles saying you should avoid them, they are still in high usage and I decided to develop one, by myself, to put it in my website later.

The button

First, I have to code the button. I decided to use a round, blue, fixed at the top left of the page, with a little of box-shadow button. For the symbol I used font-aweseome:

#menu-button:before {
  position: relative;
  top: 8px;
  left: 12px;
  font-family:'FontAwesome';
  font-size: 25px;
  content:"\f0c9";
  color: white;
}
#menu-button {
  width: 45px;
  height: 45px;
  background-color: rgba(52, 152, 219,1.0);
  position: fixed;
  top: 10px;
  left: 10px;
  cursor: pointer;
  border-radius: 50%;
  box-shadow: 1px 1px 3px 0px rgba(0,0,0,0.3);
  z-index: 1;
}

The Menu

The menu is just a div with a list. Likewise the button, you can use whatever design, here’s mine:

#menu {
  width: 250px;
  height: 100%;
  position: fixed;
  left: -250px;
  top: 0;
  background-color: rgba(52, 73, 94,1.0);
  z-index: 0;
}
#menu.opened {
  left: 0;
}
#menu ul{
  padding: 0;
  margin: 0;
}
#menu li{
  list-style: none;
}
#menu a {
  display: block;
  padding: 10px 15px;
  color: white;
  border-bottom: 2px dashed white;
  text-decoration: none;
  font-weight: 600;
}
#menu a:hover {
  color: rgba(255,255,255,0.8);
  border-bottom: 2px solid rgba(255,255,255,0.8);
}

Disclaimer about usage of ID instead of classes

I don’t believe that IDs are demons and you must avoid them to the death. Beyond this fact, I like to use IDs because it easy to manipulate the elements with them, you’ll see below.

The effect

I thought about a simple effect on the menu. First the button should roll down to the bottom of the menu, and the symbol would be replaced by an X. At the same time, the menu would just slide smoothly and show itself. Now I used a class, to represent this state: .opened

#menu-button.opened:before {
  content:"\f00d";
}
#menu-button.opened {
  top: 90%;
  left: 200px;
  -webkit-transform:rotate(360deg);
  -moz-transform:rotate(360deg);
  -ms-transform:rotate(360deg);
  -o-transform:rotate(360deg);
  transform:rotate(360deg);
}
#menu.opened {
  left: 0;
}

Look at the pixels math, the button has 45px of width, the menu has 250px, so when I move the button to a left of 200px, it’s now at the edge of the menu. But for these animations work, you should add in the #menu-button and #menu the transition property, ex: trasition: all .5s linear;

The behavior/action

To give the button an action, I had to add an event listener and, therefore I used JavaScript. As I said before, I rather use IDs in my elements because it’s easier to manage the elements:

document.getElementById("menu-button")
   .addEventListener("click",function(){
      this.classList.toggle("opened");
      document.getElementById("menu").classList.toggle("opened");
    });

//For the desk
document.addEventListener("keyup",function(e){
  if(e.keyCode == 27){
    document.getElementById("menu-button")
      .classList.toggle("opened");

    document.getElementById("menu")
      .classList.toggle("opened");
  }
});

The result

Did you like it? Please hit the heart below and share this tip with your network =)

Have you ever wanted to list blog posts in your website or webapp? I wanted to show my blog posts as a feed in my home page, so I started looking on how I’d get this, and now that I got it, I’ll show you how I did it. I’m sure that there might be a better way to do this but I’m happy with the result I’ve got.

I’ve researched a little bit about Factories vs Services and I didn’t come with a conclusion about which one is better, maybe when creating a bigger application it would be clear. At the moment, as my last Angular example uses Factories, this one will use service.

First thing to do is getting the RSS Feed XML from the blog. Due to CORS problems, I had to build a small nodeJS script to get the RSS content through my server then make it available to my AngularJS script:

var http = require('http'),
    url = require('url'),
//Gets the content of an URL
    getContent = function(url,cb){
  var request = require('request');
  request(url, function (error, response, body) {
    if(error)
      cb(error.toString());
    else
      cb(body);
  });
},
//Writes something in the response
  write = function(response, data){

response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end(data);
};

http.createServer(function (req, res) {
  var queryData = url.parse(req.url, true).query;
  if(queryData.url){
    getContent(queryData.url, function(data){
      write(res,data);
    });
  }
  else
  {
    write(res,"Unkown request");
  }
}).listen(3000);

Now that I receive the RSS feed (mostly in XML format) I can use (new DOMParser()).parseFromString(data,"text/xml") and work with the content using DOM. Feeds have similar structure, and for my need I only had to get some tags (ex:items = xmlDoc.getElementsByTagName("item") ). If you see my codepen example, it will be pretty intuitive:

Medium maybe won’t show this embedded correctly so you can see it running in my website (clicking the arrow at the homepage) or checking the pen directly in Codepen.

I added a sort function in the array of blog posts because as it can download feeds of more than one site, it’s interesting to have it organized by date of publishing.

feedItems.sort(function(a,b){
  return (
    (new Date(b.pubDate)).getTime()
  - (new Date(a.pubDate)).getTime());
});

The only extra (and maybe unnecessary) thing that I added was a check for Medium. Medium’s RSS Feed doesn’t differentiates blog posts from comments, so I ignore ‘items’ that don’t have the tag category. To work fine you have to add tags/categories on all of your blog posts on Medium, or it will be ignored.

Did you enjoy it? Please leave me a feed back or just hit the heart below, I’ll be more than happy on knowing what you think about this code snippet.

Have you ever accessed a website and the design (or some functionality) was broken? Maybe it is OK but then you open an specific broswer (generally some Internet Explorer, lets be honest) and then it doesn’t work? Maybe you are a developer and knows how to fix the problem but can’t contact the owner of the website. I’ve been in those situations also, and maybe this can be our solution.

Web compatibility is about making sure websites work consistently across all browsers and devices, and sometimes with a little testing and some small tweaks to their site, developers can ensure that more users can have the full experience that is desired. Thinking about it, Mozilla has launched https://webcompat.com, a website that’s an open invitation for all web users, developers and browser vendors to get involved in the web compatibility effort.

With Chrome and Firefox extensions, the user can easily share an website issue with the community, so they can work on the solution and contact the site owner to suggest them the fix, or maybe it’s a browser issue, thus they will contact the browser vendor. You can also report a bug without installing any plugin, just visiting the WebCompat website.

With Web Compat, you can contribute in three ways: Reporting a Bug, Diagnosing a bug, Reaching the site owner/developer. There’s another way that’s contributing with the Web Compat site itself, contributions are always welcome.

If you want to know more, Follow WebCompat on twitter, login on the website, send a message to the WebCompat team. If you can attend, Mozilla Brazil will be on FGSL in November 19th, and there you can get some real experience with this and other Mozilla projects.

Before Firefox release any new features in the browser, they release them in an extension called Test Pilot so we can test out and give the engineers and creators some feedback. In other words you can actually help build Firefox, by giving your opinion on new features.

Mozilla believes in an open and accessible Internet for all, always committed with privacy, user choice and Open Source Development. This ideas makes Firefox the top browser available today. But it’s difficult to get users feedback giving this commitment with privacy, so that’s why they made Test Pilot.

With Test Pilot you can choose which new feature you’ll want to test, you can read about the data they collect for each experiment and tell them what you think. Test Pilot is more than just a web app to test new things. It’s a research, design, and development process aimed at making feature development a smoother and more transparent process.

This process consists of four phases. In phase one the Test Pilot team prototype and validate the ideas. In phase two they design and build the experiment. Phase three is the launching of the experiment, it’s when we get into the game. Mozilla then monitor the stats and listen to our feedback, to shape the feature so it can be perfect. At the moment Test Pilot have these experiments:

• Page Shot: Lets you take screenshots (of the page, only) cut it and share it.
• Min Vid: Enables a small view of the video you’re watching so you can use Internet while watching your video at the same time.
• Tracking Protection: Kind of private navigation without using a private window.
• Activity Stream: It shows your recent activity, highlights and top sites based in your history and favorites every time you open a new tab.
• Tab Center: Groups your open tabs in the left part of the browser.
• No More 404s: Try to show an old version of a link whenever it gets ‘Page not Found’.
• Universal Search: Just type a few characters in the Browser bar, and the most popular sites, people and Wikipedia articles will appear for you.

Want to know more? Some members of Mozilla Brazil will be at FGSL and they will show you how to be more involved. If you can’t attend, check Test Pilot on twitter, Test Pilot on Github and Test Pilot on Discourse.

In early 2014 I heard about this thing called IndexedDB. As soon as I heard about it, I started to try it out while learning about it on MDN. It was one of the firsts subjects that I studied on MDN, when I was discovering it, and I get to translate one big article about Using IndexedDB to Portuguese.

But this article isn’t actually about localizing articles, it is about building a Factory (do you know AngularJS Factories?) that can perform a CRUD (Create, Read, Update, Delete) using IndexedDB.

Why Factory?

I’ll not enter into the discussion about the differences between Factory and Service because there are tons of articles about it over the Internet. I chose Factory because I developed the feature the simplest way I could, therefore it’s not too abstract. It’s designed do work with one database only and one object store only.

Understanding IndexedDB

Again, for further information you should read some content like MDN’s about IndexedDB to know better. But basically IndexedDB is a low-level API for client-side storage using indexes to enable high performance searches of this data. The data is stored in your browser quite similar to cookies. If you compare to a Relational database, it will be something like:

• Database — Database
• Table — Object Stores
• Records — Objects

The steps you should keep in mind are:

1. Open a database;
2. Create (if don’t exist) an object store in the database;
3. Start a transaction to perform some operation;
4. Wait the transaction by using some event listeners;
5. do something with the results;

With that in mind, I developed the factory using a little more than 100 lines to perform the basic operations. The example is shown at the pen below:

Of course you can improve this Factory in million ways, this is just a bootstrap. IndexedDB is great when it comes to Offline First Applications and you should give it a try. I hope that this code helps you coding your apps.

Did you like it? Please hit the heart below or leave a comment. I can’t wait for your feedback.