Most recently, I had a problem with autoplay of video elements in the browser for mobile. Instead of using gifs, we decided to use muted, looped videos and it worked fine.

At some point, we replaced them from mp4 to webm. Nothing crazy.

Just to find out a few days later that we’re having issues on iPhone devices that display a blank space instead of the video.

I went over the settings again, making sure it’s muted, it has autoplay, it has the poster in place, all that stuff.

Just to find out that iPhone will not autoplay webm files, and we need to revert back to the mp4 version.

This example below works, it will autoplay the muted video in a loop on your iPhone, as long as it’s not a webm.

<video poster="video-poster.png" autoplay playsinline loop muted>
    <source src="proxy.php?url=video.mp4" type="video/mp4" />
    Your browser does not support the video tag.
</video>

The post Issue with autoplay video element on iPhone using webm appeared first on DevMaverick.

I’m talking about cookieconsent from Orest Bida.

Since GDPR started to be a thing I looked for all kinds of solutions and used a lot of solutions to solve the consent step.

From the start, I have to mention that this is not a full solution for GDPR.
This library will allow you to manage the scripts and cookies on your site.

Some points in GDPR are related to the right to be forgotten and the rights of data: this library does not cover those.

Here is a list of features available in this library:

1. Easy Integration
   Plug it in right from the CDN files.
2. Highly Customizable
   Change colors, position, size, buttons, etc. It will cover all your needs.
3. Granular Consent Settings
   CookieConsent excels in handling granular consent settings, allowing users to personalize their experience by choosing preferences for different types of cookies.
4. Multilanguage support
   You’ll be able to customize the content based on the language required.
5. Rich in Callbacks and Events
   The library gives you enough callbacks/events to handle all the situations that might come up.
6. Script Management using attributes
   This is great for 3rd party scripts that you don’t have control over or those that are added directly via GTM. You can pass the attribute (data-category for example) and that script will be affected based on your logic from CookieConsent.
7. Custom Attribute
   Allowing you to trigger core functions without the use of a javascript code. It will use the API methods. One use example: trigger the modal for consent options from a button on the Cookie Policy page.
8. Revision Management
   Allows you to refresh the consent if there is a change in your cookie policy. You can also add a message that will displayed for the user.

The library has great documentation and a playground where you can test it.

If you want to try a free open-source library for cookies consent, I would recommend this one.

The post Best JavaScript cookie consent management library for your website appeared first on DevMaverick.

Table of contents

• Why lazy load assets?
• Browser native alternative
• Why lozad.js?
• How to use it
• Conclusion

Why lazy load assets?

This is one of the main aspects when it comes to page/website optimization. You don’t want to load extra assets that are below the fold. What is not in the initial view of your page can be lazy-loaded in most cases.

Extra assets mean more MB to be downloaded by the client, more MB results in a longer period until the page is functional, this then converts into a low-performance score and increased bounce rate. If you also factor in slower internet connections (3G) you will want to cut down on assets on the initial load as much as possible.

Browser native alternative

Modern browsers have a way to lazy load assets into the page, but there are some asterisks here.

For images

If you’re loading images you can use loading=lazy and any modern browser will be able to determine that the image needs to be loaded when it comes into view. The implementation might differ from browser to browser when it comes to when exactly the image is loaded, just before it comes into the view or after with some delay.

No support for background images lazy loading.

For video

If the video doesn’t autoplay and it started by the visitor by clicking on it, you can use preload=”none” and poster. This will lazy load the video

<video controls preload="none" poster="poster.jpg">

Now if you use the video as a GIF, on mute with autoplay, there is no native way to lazy load it.

For iframe

At the time of writing this, Chromium-based browsers support using loading=lazy on iframes so they are loaded when coming into view.

As you can see from the above examples, there is some native support for lazy loading but it doesn’t cover all the media types and it’s only available for modern browsers.

Why lozad.js?

Because it will cover all cases that at the moment are not supported by browsers natively and there is no downside to using it.

Lozad.js is a free lightweight library with no dependencies that helps you lazy load images, videos, audio, iframes, <picture>, background images, and responsive images (srcset). All these while having good support for all browsers.

I believe the only browser where you might encounter problems is IE 11 or lower and you might want to use polyfill to make this library work for those.

For me, lozad.js did the job when I had pages that were heavy on video content and background images. It also saved me a lot of time since it’s really easy to use and I don’t have to figure out how to deal with the lazy load issue on different asset types since the library can help me do it.

How to use it

Pretty straightforward install. It can be done via npm, Yarn, Bower.

# You can install lozad with npm
$ npm install --save lozad

# Alternatively you can use Yarn
$ yarn add lozad

# Another option is to use Bower
$ bower install lozad

or get the script from CDN.

<script type="text/javascript" src="proxy.php?url=https://cdn.jsdelivr.net/npm/lozad/dist/lozad.min.js"></script>

I always recommend to store libraries locally if possible.

Next, instantiate the library

const observer = lozad(); // lazy loads elements with default selector as '.lozad'
observer.observe();

You have lozad.js working on your site now, all you need to do is to add the class and data-src to your elements.

<!--  Video -->
<video class="lozad" data-poster="images/backgrounds/video-poster.jpeg">
    <source data-src="proxy.php?url=video/mov_bbb.mp4" type="video/mp4">
    <source data-src="proxy.php?url=video/mov_bbb.ogg" type="video/ogg">
</video>

<!--  Iframe -->
<iframe data-src="proxy.php?url=embed.html" class="lozad"></iframe>

<!--  Image -->
<img class="lozad" data-src="proxy.php?url=image.png" data-srcset="image.png 1000w, image-2x.png 2000w">

<!--  Background image -->
<div class="lozad" data-background-image="image.png">
</div>

Conclusion

Good library, easy to use, does the job, perfect for lazy loading.

I still use the native loading=lazy for images, but for everything else, I rely on lozad.js.

Resources

• Lazy-loading video (web.dev)
• ApoorvSaxena/lozad.js

The post Lazy load video resources with lozad.js appeared first on DevMaverick.

Table of contents

• Our workflow
• The issue
• ADR to the rescue
• Final thoughts and ADR example

TL;DR

We realized that there has to a better way to record past decisions made on a project. Clubhouse and Git are limited when it comes to this. ADR offers a better understanding of why something needed to be changed, when it happened, what options were available, how it was implemented.

Our workflow

In most of the cases when we start a new project there are a few things that get set-up.

• Each project will have a folder in OneDrive or Dropbox structured in a conventional way
• The project has a Git repository
• A Clubhouse workspace is set.

Other things are also done, password storage, contact details linked with the project, and so on, but that is not relevant for this article.

After that we have Clubhouse details set, stories added, epics created, milestones set and sprints.

Between Clubhouse and Git, there is enough control to see what happened or needs to be done, who did something and the immediate changes of files. If you also use version control on your app it’s even better, this way you can see what is new from version to version and follow the pull request (usually from dev to production or staging).

The issue

While all that sounds good, there still is a part that is left behind.

For example, you decide to change the payment gateway on your app. In order to have this change, there was a discussion that started for a reason (context), there were some options, a decision was made to go with one of the options, someone took that decision at a certain point in time, that decision has some consequences that you understood.

In the Clubhouse + Git setup you can’t catch all these details. Replace Clubhouse with any project management tool, it’s still the same.

Another example: you added an extra mandatory field in the registration form.
Why did you need that?
What other options did you have?
What decision was made?
When did it happen?
What consequences came from this?
Who was involved in the decision making?

ADR to the rescue

You might’ve already noticed that there is a pattern in the above examples and that will be present in the ADR structure.

What is an ADR?

Architecture decision record (ADR) is a document that will capture an important architectural decision in your project.

This document has some different structure options, but they all include the same elements.

• Context (*)
• Date (*)
• Status (*)
• Options
• Decision (*)
• Consequences (*)
• People involved

(*) – mandatory

Why use ADR?

It’s a good way to keep track of changes and put them in context.
Might not seem that important at the moment, but it will be really helpful when you came back to a project 3 months later and you can’t remember why those changes were made in the first place.

It will also provide insightful information for the people that might come after you to work on the project or for new team members. Having a quick scan over the ADR folder and see why some things are the way they are it’s good way to get up to speed with what happened.

ADR structure

We decided to create an ADR structure to use in your projects.
At the project parent level, we have a docs directory that includes an adr folder.
In that adr folder we create files with a certain name structure 0001-ADRNameDescriptive.md.
Each ADR has a certain file structure.

You can find all these details in our ADR structure repository + some VSCode snippets for ADR.

Final thoughts and ADR example

We literally stumbled upon the idea of ADRs. I didn’t know what you search for in order to find this. It was a tweet that came up and was mentioning ADRs and from there I just connected the dots, did some research, and found out about this way of keeping track of important architectural decisions.

The repository that we linked above has more information, structure, links to external articles about ADR and it also includes some VSCode snippets for ADR.

Give it a try in one of your projects. It might seem like some extra work, but it’s worth it in the long run.

The post How we came to use Arhitecture Decision Records (ADR) appeared first on DevMaverick.

Table of contents

• Understand the design/project
• Working with elements
• Mobile Content
• Isn’t mobile first the same as a responsive website?

The full question sounds like this:

Should you build your website/web-app mobile first and scale to desktop?

Why do we need another article about this, it has been covered a lot of times already?

To make things clearer, I’m only interested in the site structure, building the CSS around it and how it changes from one device to another. Not the PWA or other things that will take the mobile first approach and make it more like a mobile app.

It might be an obvious answer for a lot of you, but to my shame, it wasn’t for me. I didn’t see a reason to go mobile first in my approach. I’ve created lots of sites with the approach of desktop first and scaling down on mobile as I went along. We even had a full workflow where we have the desktop site ready, test it and after that, we move to mobile.

This workflow might’ve been influenced by the designers I worked with or the clients that focused on the desktop version first.

It all changed after I read Responsive Design: Patterns & Principles by Ethan Marcotte. I recommend this book if you are a web developer, especially front-end.

I was amazed by how much more can be accomplished if you have a different perspective when creating the site. And it so happened that I read it during a complex project where we had a lot of parts and elements that were structured to be re-used throughout the site.

Understand the design/project

It starts by getting a better understanding of the design or the project as a whole. You need to get as many details from the client and designer. They might think the site as page by page, but this is not true anymore. The site has pages but those pages are created by elements, and those elements are the ones that need your attention.

What is relevant for the user on a small device?

• On your newspaper site, you want to show the featured story on mobile and have it display as the first thing, not obstructed by anything else.
• If you have an e-commerce site you want to show the featured product(s) that are available on sale.
• Your book author might want to have a clear way to display the next event or book signing that she’ll attend.

This means understanding your project, getting to know exactly what matters, the core of the project. On mobile, you need to be able to deliver what’s important and not just fill the screen with everything. Providing the right content will keep the user engaged with your site, and it will also help you fix performance issues.

Working with elements

As you look over you will find elements that repeat themselves on different pages.

Once you identified the elements, you can start building the components. Get those components to live in their own space and create a structure just for them.

Then get them styled not in a relationship with the page or other elements, but as a standalone unit that will be placed on a page.

Why are elements important?

First of all, it’s like working with data: you want the actual data, not for it to be wrapped into something that needs to be adjusted when you want to display it.

You want the actual value from a field. Same with elements.

You want an element that does the Featured Story for the newspaper, Product on Sale for your e-commerce, Next Event for the author, that you can re-use wherever you like.

Having elements or components that will come together on a page will help you better manage the outcome.

Mobile Content

On a mobile first approach, the content on mobile devices is specially catered for mobile. You don’t just use what it’s on desktop but on a smaller screen.

There is an important difference here because you will need to take into account the fact that people might browse on 3G connections that are not that fast. This will make every extra resource that is loaded to take some extra seconds for the end-user.

We’re getting a better understanding of how the images are delivered and if you have to just hide content or eliminate it on mobile devices.

As you’re set on creating elements/components, you have to make sure that the media files you use are correctly optimized for screen size and enable/disable certain elements on mobile altogether. Don’t load them just to hide them on mobile.

Today this is even more powerful and easy to achieve with JS frameworks like Vue.

Isn’t mobile first the same as a responsive website?

Yes and no, mostly no. It’s kind of the same thing when you talk about the methods used (you’re still using a CSS framework for example), but it has very different outcomes.

I see the responsive way of creating sites as going from big to small and with this approach comes the idea of hiding elements on certain smaller screens or just move them around to fit. Nothing wrong with this, mobile has less space to display content.

But what do you hide on mobile?

You’re now faced with a problem that you didn’t have in mind at the beginning. You’re not aware of what is vital/relevant for your user on mobile.

The mobile first approach aims to solve this issue. You’re starting the site scaling from small to big, not downgrading the content. When you start with the small screen idea in mind, you realize what is important and what must be shown on the page. It’s not just about moving the content around so it will fit.

I’m aware that responsive is the easy way to do it. When you have a site that is already in use for some while and it has traffic on it, it’s the safe step to make it responsive, move things around to fit and just remove some elements on mobile.

I would love to cover more on this subject and break each idea into an article on its own, but for now I just wanted to offer a glimpse of what I took from that amazing book.

I really recommend reading the book. it’s around 100 pages with a lot of relevant examples and solutions from the real world. It might change the way you think about your current projects.

The post Should you go mobile first? appeared first on DevMaverick.

What it’s !important?

You can call !important a directive, a keyword, declaration, and it’s placed at the end of a CSS propriety to prioritize it, to add more weight to it over other proprieties that might be in the way.

CSS (Cascading Style Sheets) passes along some of the proprieties from the parent to child and so on. Similar to a cascade, if it wasn’t obvious enough.

In some cases, you need to overpower those proprieties and for different reasons, you end up using the !important solution.

.container h2 {
  font-weight: 600;
}

h2 {
  font-weight: 300 !important;
}

In the example above your h2 will take the font-weight of 300, even inside the .container element, because it has the use of !important.

This should give you a good idea of how it works.

When will you use !important?

You might end up using !important for different reasons.

A few that I might think of:

• Old code where you don’t know what else will be affected and you prefer to add an !important to fix your style and move on with your day
• Dealing with inline CSS added by some 3rd party JS
• Classes that are overlapping with another plugin or theme
• You are using a framework (Bootstrap)

It’s not always justified, but most of the times it will be an easy way to fix something.

I try to go out of my way and get it fixed correctly without using !important. Try using an extra class when you identify the element, let !important be the last resort.

Bootstrap, frameworks and visual builders

When you use frameworks on your project, you might be forced on using the !important propriety more that you want.

One way to avoid this is to learn more about CSS Specificity. This will allow you to style your files better without abusing !important just to get the things done as you want.

Apart from Bootstrap, you will stumble upon different visual builders for WordPress that will do you the immense ‘favor’ of adding inline CSS with !important in it.
This will be a recurring problem and you will have to decide if you want to edit the elements from the builder proprieties (adding background image, padding, margins) and deal with all the mess that comes with inline CSS (with important) or just assign a class to an element and do the whole work from CSS files.

Dark/Night Mode and !important

I can think of one example that will make the use of !important justified: Night Mode or Dark Mode.

Let’s say you want your site to have a Night Mode option, a simple switch that will change all the content into a dark background and white text.

You can have a simple switch that will add an .dark-mode-on class to the body and after that use a code similar to this:

body {
  background: #fafafa;
}

h2 {
  color: #dea62f;
}

p {
  color: #333;
}

.dark-mode-on {
  background: #000!important;
  color: #fff!important;
}

.dark-mode-on h2 {
  color: #fff!important;
}

Conclusion

Yes, you should use !important, just be sure not to end-up with proprieties cancelling eachother because that will be a nightmare to debug.

The post Should you use !important in CSS? appeared first on DevMaverick.