DEV Community: Ekaterina Vujasinović

Quiz📣: How Well Do You Understand Asynchronous JavaScript?

Ekaterina Vujasinović — Thu, 28 Oct 2021 13:37:47 +0000

Over the last few weeks, we had a lot of discussions on asynchronous JavaScript and patterns we use in our projects to build performant apps. It resulted in an article - 4 tips on writing better async/await code. Besides practical aspects like asynchronous coding patterns and best practices, one of the discussed topics was the importance of understanding how JavaScript handles asynchronous code under the hood.

Asynchronous code is passed to wait in one of the queues and executed whenever the call stack is empty. Tasks in the queues and call stack are coordinated by the event loop - the key mechanism used by JavaScript to avoid blocking the main thread. Learn more about it here.

We've collected 4 interesting examples of code (it looks like 4 is our favorite number 😉) that will help you test your knowledge of event loop and JavaScript asynchronous execution flow. Let's start ⏬

1. Which Queue Is Executed First?

Before diving deep into the event loop, call stack, and tasks, let's begin with a little warm-up question.

Not all queues were created equal. Knowing that setTimeout() callback is pushed to the task queue, and then() callback to the microtask queue, which one do you think will log first?

// Task queue 
setTimeout(() => console.log('timeout'), 0)

// Microtask queue 
Promise.resolve().then(() => console.log('promise'))

Show the answer 👇

promise 
timeout

The tasks scheduled in the task queue will run first. But wait, how come the output logged from the setTimeout() callback appears second in our example?

In each iteration, the event loop will run the oldest initially existing task in the task queue first, and all the microtasks in the microtask queue second. When the event loop starts its first iteration, the task queue contains only one task - the main program script run. The setTimeout() callback is added to the task queue during the first iteration and will be queued from tasks only during the next iteration.

To better understand these mind-blowing concepts, check this animated diagram by Jake Archibald.

2. What Is the Output of the Code Below?

To answer this question, you need to be familiar with the concepts like synchronous vs. asynchronous code order of execution and how the event loop is running tasks.

Equally important, you also need to know which code runs synchronously and which asynchronously. Hint: not all Promise-related code is asynchronous. 🤯

There are four console.log() calls below. What will be logged in the console and in which order?

let a = 1

setTimeout(() => {
    console.log(a) //A
    a = 2
}, 0)

const p = new Promise(resolve => {
    console.log(a) // B
    a = 3
    resolve()
})

p.then(() => console.log(a)) // C

console.log(a) // D

Show the answer 👇

/* B */ 1
/* D */ 3
/* C */ 3
/* A */ 3

The code inside the new Promise executor function runs synchronously before the Promise goes to a resolved state (when resolve() is called). For this reason example code logs 1 and sets variable a value to 3.

The variable value remains unchanged in all further console.log()calls.

3. In What Order Will Letters Be Logged?

How do DOM events fit in the event loop task handling mechanism? What we have here is a div container containing a button element. Event listeners are added to both the button and the container. Since the click event will bubble up, both listener handlers will be executed on a button click.

<div id="container">
  <button id="button">Click</button>
</div>

What is the output after button click?

const 
  container = document.getElementById('container'),
  button = document.getElementById('button')

button.addEventListener('click', () => {
  Promise.resolve().then(() => console.log('A'))
  console.log('B')
})

container.addEventListener('click', () => console.log('C'))

Show the answer 👇

B
A
C

No surprise here. The task of dispatching click event and executing handler will be invoked via the event loop, with synchronous code logging first and then() callback logging second. Next, the event bubbles up and the container event handler is executed.

4. Will the Output Change?

The code is the same as in the previous example, with a small addition of button.click() at the end. It is a weird UI design pattern where the button is clicked automatically. Do you think it's a game-changer or logging order stays the same? 🤔

const 
  container = document.getElementById('container'),
  button = document.getElementById('button')

button.addEventListener('click', () => {
  Promise.resolve().then(() => console.log('A'))
  console.log('B')
})

container.addEventListener('click', () => console.log('C'))

button.click()

Show the answer 👇

B
C
A

The strings are indeed logged in different order. button.click() is making all the difference, sitting at the bottom of the call stack and preventing microtask queue tasks from executing. Only after the call stack is emptied, () => console.log('A') will be queued from the microtasks.

Feel free to share your mind-boggling async & event loop related code examples in the comments ✍️. Don't forget to ❤️ and follow for more web dev content.

Dark Mode With One Line Of Code

Ekaterina Vujasinović — Sat, 22 Aug 2020 13:24:20 +0000

Dark mode can be implemented with a single line of code. Let’s see how it's done and the benefits and drawbacks of this simple approach.

filter: invert(100%)

invert() function as the value of the filter property will take the number from 0 to 1 or percentages from 0% to 100% to invert the colors of the element and its children. Applying filter: invert(1) or filter: invert(100%) results in fully inverted colors.

You can use this single line of CSS to switch the color scheme from light to dark (or the other way around).

To invert the colors of the entire website, you need to apply filter: invert(100%) on the highest-level element of the DOM:



:root {
  filter: invert(100%);
}

Applying filter with toggle button

To switch the theme, you need a toggle button and a class with dark mode styles to be toggled on the button click. Check the Codepen example below and click the button in the middle to change the color scheme:

The filter property inside the .dark-mode class is responsible for changing the colors.



/* this class will be toggled */
.dark-mode {
  filter: invert(100%)
}

We must employ some basic JavaScript by targeting the document.documentElement inside the listener function. Then we can toggle the .dark-mode class on the top of the DOM hierarchy to apply the filter: invert(100%) sitewide.



let button = document.querySelector('.btn')

// press the button to toggle the .dark-mode class

button.addEventListener('click', () => {

  document.documentElement.classList.toggle('dark-mode')

})

The pros and cons of inverting all the pixels

The benefits of making your entire site switch from the light to the dark mode with filter: invert(100%) are obvious: it's a quick and dirty solution. And, like every quick solution, it also has some significant downfalls.

filter applied on the top of the DOM tree is going to cascade down and affect all the child elements. It’s going to invert all the colors. It results with the following list of problems (and let’s pretend that every bullet point ends with: “Additional code is necessary to fix this”):

Media like images and videos gets inverted, and it never looks good (but you probably still want to have the SVGs inverted).

All pixels are inverted, including the image

All dark box-shadows will become highlights.
If your website has colors other than black, white, or grayish nuances, you might be surprised by how bad some colors look inverted.

Light blue color becomes not-so-pretty brown color

Where there was once a sufficient contrast on the light background, things can change when color gets inverted and when it's against the dark background.

The contrast of the inverted color on the dark background is very low

Think about hover, focus, active, visited, and all other special element states. Do colors convey the state of the elements when inverted or is the color meaning lost? What about interactives?
Some advanced UI advice by Steve Schoger that adds to the point
https://twitter.com/steveschoger/status/1151160261170126850

This list could go on and on, dealing with all kinds of usability and accessibility details that would be sorely missed when inverting the entire color scheme. The point is - you expected to implement the dark mode with a single line of code and spent the entire day writing CSS to fix all the problems.

To invert or not to invert?

The final verdict for filter: invert(100%) is: it is super-useful for making the details look good. You could use it to switch the colors of the entire site though if your site is very simple and monochromatic.

In all other cases, you should probably try some content-aware techniques instead. For example, here is the Dark Mode - The prefers-color-scheme Website Tutorial article (and its GitHub repository) I wrote on implementing the dark mode with prefers-color-scheme media-query, variables, and JavaScript.

CSS Comparison Functions clamp(), max() and min()

Ekaterina Vujasinović — Tue, 19 May 2020 12:34:08 +0000

We use relative length units to build responsive/fluid layouts. Besides being flexible, elements whose size depends on the size of another element or the viewport, also have a bad habit of sometimes growing or shrinking more than we would like them to. For example, if we define the font size with vw unit alone, text can easily become illegible if viewport size gets too small.

Breaking a bad habit is tough - and in this case it may require some serious thinking and calculations. We usually solve these problems with media queries or different calc() techniques to achieve more fluid effect. It's especially true when it comes to the elements that don't have width property (and consequently max-width and min-width), like the above-mentioned font size.

Comparison functions can help us build responsive designs with less time and fewer lines of code. Functions clamp(), min() and max() (specified in CSS Values and Units Module Level 4) set upper and/or lower value limits, compute and compare values of the arguments passed to the function, and apply the calculated value to the property.

clamp(), min() and max() can take values or math expressions as arguments (or basically anything that resolves to a value). They can be used, let me quote MDN here: anywhere a <length>, <frequency>, <angle>, <time>,<percentage>, <number>, or <integer> is allowed. That’s a lot of possible use cases to consider, and in this post I explored the most obvious ones.

clamp()

Function clamp() takes three parameters: a minimum value, a central, preferred value, and a maximum value. The resolved value will always remain between the minimum and maximum.

clamp() calculates property value based on the central value. If the calculated value falls between the minimum and maximum, the central value will be applied to the element. If the calculated value falls below minimum or exceeds maximum, minimum or maximum will be applied respectively. There is no need for calc() function when passing math expressions in the comparison function.

The syntax is simple and logical:

/* css */
.element {
width: clamp(100px, 50vw, 600px); 
/* width: clamp(min, preferred, max); */
}

Depending on the viewport size, the upper CSS ruleset will apply the following widths to the element:

Viewport	Applied width clamp()
200px - 1200px	50vw
< 200px	100px
> 1200px	600px

Try it for yourself in the clamp() demo below:

Check another demo to see how both the paragraph text and the heading are being smoothly resized between the value limits. No jumps as with media queries. The ratio between the font size of the headline and body text grows as the viewport gets bigger but nothing will ever get too big or too small.

This is a simple example and is far from perfect - vertical rhythm, modular scale, line length, and bazillion other typography related things - it all could be implemented better. But if I ever decide to improve it, I will probably use comparison functions for much of the above.

max() and min()

Function max() calculates and applies the largest value from the provided range of values. Likewise, function min() calculates and applies the smallest value from the range. They can take one or more parameters.

Check the Codepen demo below to see both functions in action:

Yes, both min() and max() can be replaced with max-width or min-width if the element has width property and only two parameters are passed into the function. It sounds a bit counterintuitive, but max() actually sets the lower size limit and min() the upper size limit.

/* css */

/* min() */
.element {
width: min(50vw, 500px);
}
/* gives the same result as: */
.element {
width: 50vw;
max-width: 500px;
}
/* max() */
.element {
width: max(50vw, 500px);
}
/* gives the same result as: */
.element {
width: 50vw;
min-width: 500px;
}

The upper CSS code applies following width values to the element, depending on the viewport size:

Viewport	Applied width max()	Applied width min()
> 1000px	50vw	500px
< 1000px	500px	50vw

You can pass multiple parameters into both max() and min():

/* css */
h1 {
 font-size: min(3rem, 3em, 4vw);/* the smallest value will be applied */
}

max() and min() with multiple parameters are potentially capable of doing some serious responsive stuff with a single line of code. However, I find them a bit incomprehensive - it's hard to set the right arguments and it's even harder to check which value gets applied 🤯. Maybe there are some best practices I'm not aware of.

In the following demo the rectangle changes its width and color as the width property takes three different values:

Comparison functions can be nested within other comparison functions. For example, function clamp() can be alternatively written as max(minimum, min(preferred, maximum)).

Conclusion

Comparison functions are new to me and I still haven't find time to fully explore them. They have only recently entered some major browsers but already have decent browser support.

I can imagine comparison functions being used in web typography. It's not like it will absolve us from using media queries or calc(), but in many cases they can make our job a lot easier.

Potential use cases of comparison functions probably stretch far beyond responsive width and font-size. I was thinking about how to use them with colors (still thinking 🥴). Maybe you have some interesting ideas? Share your thoughts in comments.

How can object-fit property save you from misusing the background images

Ekaterina Vujasinović — Mon, 17 Feb 2020 11:44:40 +0000

It's a very common situation - you have an image that needs to fit its content box without losing the aspect ratio. It seems that the easiest way to solve the problem is to insert your picture via CSS background-image and give it the background-size: cover property. There are also other background-* properties that can help you with positioning and styling.

However, inserting images with CSS is not always the most appropriate choice. It's how the purely decorative images should be handled. When it comes to the images that are providing any kind of meaningful information, 👉 object-fit gives us the ability to manipulate the content inside the <img> tag in a very similar way as background-size does with CSS-inserted background images.

TL;DR: Don't use background-* for images, videos or other replaced elements that are providing any kind of information, concepts or functionality. 👉 Use inline images and style them in CSS with object-fit and object-position instead.

For the sake of brevity, I will write mostly about handling images, instead referring to each kind of replaced elements separately. The main idea is the same, though.

Summary

👉 background-* vs object-fit
👉 Background images are not accessible
👉 Background images are not SEO-friendly
👉 Are there any performance issues with background images?
👉 Conclusion

Background vs object-fit

object-fit is used to fit image or video (and every other replaced element) to its content box. Images with non-decorative content should be inserted like this into the HTML document and further styled in the CSS stylesheet 👇

<!--index.html-->
<img src='meaningful-image.jpg' alt='this text describes the image' 
 class='.my-html-image'/>

/*style.css*/
.my-html-image {
 object-fit: cover;
 object-position: left 10%, top 15%;
}

Check the CodePen demo below for working example of object-fit values:

Decorative background images should be inserted like this into the CSS stylesheet 👇

/*style.css*/
.my-div {
    background-image: url(my-special-image-url.jpg);
    background-repeat: no-repeat;
    background-position: left 10% top 15%;
    background-size: cover;
}

As you can see, it's not the amount or the complexity of code that makes a difference between those two ways of inserting images. The thing is that using background-* for non-decorative content have some serious drawbacks.

Background images are not accessible

Background images are meant to be purely decorative and it would be incorrect to make them "audible". It can be tempting to simply build a pie chart with conic gradient in CSS, but by doing it you are probably excluding people who cannot see the chart.

Screen readers and other assistive technologies rely on structural markup, and therefore, it is your responsibility as the developer to ensure that your HTML is semantically correct in describing the functional purpose of the content. Background images don't have a corresponding markup element - you set them in CSS directly - so, they are 'invisible' to the screen readers.

Besides proper HTML structure, there are other important accessibility features, like alt attributes for images, that cannot be used with background-* properties.

Browsers do not provide any special information on background images to assistive technology. This is important primarily for screen readers, as a screen reader will not announce its presence and therefore convey nothing to its users. 👉 If the image contains information critical to understanding the page's overall purpose, it is better to describe it semantically in the document.
-MDN, https://developer.mozilla.org/en-US/docs/Web/CSS/background

Background images are not SEO-friendly

Google parses the HTML of your pages to index images, but doesn't index CSS images. 👉 If you want your images to rank in Google Image search then you best use <img> tag with the src attribute pointing at the image. That said, it would be a shame to hide your visual content behind the background-image, especcially if it's a custom content that is additionally backing up your message.

As previously mentioned, background is purely CSS property and doesn't have a corresponding HTML tag or attributes. 👉 For good SEO results images should be placed near relevant text, have alt tags and maybe a caption - you can't do any of those with background-*.

Are there any performance issues with background images?

Yes, but there is hope on the horizon. There are some significant shortcomings regarding performance of background images:

👉 Background images are discovered by browser only after all CSS in page's <head> element has been downloaded and parsed. If there is a substantial amount of CSS, it may cause slower loading of the background image.

👉 Likewise, it is impossible to provide high-res images without writing a bunch of device pixel ratio media queries, which is a non-standard feature.

image-set() is a new feature that allows us to use different background images for different screen densities (just like srcset attribute in <img> tag) - hence solving the second problem. Even more so, image-set() can be used with the new preload feature 👇

The preload value of the <link> element's rel attribute lets you declare fetch requests in the HTML's <head>, specifying resources that your page will need very soon, which you want to start loading early in the page lifecycle, before browsers' main rendering machinery kicks in. 👉 This ensures they are available earlier and are less likely to block the page's render, improving performance.
- MDN, https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

So, hopefully, if the browser support ever gets just a bit better for both image-set() and preload, we can consider both issues solved.

For more information, read this article on Google Developers.

Conclusion

Background images are not "bad" per se, they just have some shortcomings when implemented in the incorrect way. You should definitely choose them for abstract background pattern, background color / gradient, or some blurry, decorative image. But for your hero image or any other meaningful content, you might consider the <img> and <picture> tags, together with object-fit and object-position. The latter provides much more opportunities for accessible, easily discoverable and performant images.

Lesser-known CSS display values

Ekaterina Vujasinović — Mon, 10 Feb 2020 12:29:02 +0000

If you are just like me and have spent a last couple of years coding without being aware of how many CSS display values are out there, this could be a useful post for you. I will leave out the values that are most widely used (block, inline, inline-block, flex, grid, table with all the internal display values and none) since there are already so many great articles about them.

👉 What display is all about
👉 display: inline-flex and display: inline-grid
👉 display: flow-root
👉 display: list-item
👉 display: contents
👉 display: ruby

What display is all about

According to the CSS Display Module Level 3 spec 👇

The display property defines an element’s display type, which consists of the two basic qualities of how an element generates boxes:

👉 the inner display type, which defines the kind of formatting context it generates, dictating how its descendant boxes are laid out.

👉 the outer display type, which dictates how the principal box itself participates in flow layout.

In other words, the inner display type describes the behaviour of element's children, while the outer display type defines whether the element is block-level or inline-level, that is, how it interacts with other, outer elements.

Right now, display property single-value syntax feels kind of incomplete and doesn't always let you specify both inner and outer display type explicitly. Sometimes it's hard to figure out right away how the element behaves.

Luckily, the CSS Display Module Level 3 also defines new, two-value syntax for setting display values, with outer and inner display type values set separately (e.g. block flex instead of just flex). This feature has already been implemented in Firefox, but other browsers don't support it yet.

display: inline-flex and display: inline-grid

Both flex and grid containers are behaving like block items by default, as both flex and grid display values are setting the outer display type to block. This means that each container will occupy the full width available, even if its corresponding HTML element is an inline item (like <span>).

In case we need to modify the outer behaviour of the grid / flex containers, e.g. to position them side-by-side in the same row, 👉inline-flex and inline-grid display values will make them behave like inline elements, without affecting the layout of items inside the containers.

display: flow-root

flow-root is an inner display type value, which means that it sets the inner flow of the elements. In order to properly understand flow-root, we need to dig into something called Block Formatting Context (BFC). There is a definition in the spec, but it's easier to explain with an example.

There are two red <div> elements in CodePen below, with identical children elements and formatted in the same way, except for the display value. The first container has default, block display value, while the second one is an inline-block element. Do you see collapsed margins in the first container? 😱

Top margin of the blue square and bottom margin of the paragraph are somehow ending up outside of the parent element. In the second container, we avoided margins collapsing, since it occurs only between blocks belonging to the same Block Formatting Context and 👉 display value of inline-block creates a brand new BFC.

inline-block is not the only property creating a new BFC, though. What if we want to keep the margins from collapsing, but also keep our container block element, remaining in his own row in layout? Among other hacks, we could do it by setting overflow to hidden, but apparently, this method may have unwanted side effects.

👉 flow-root display value is a solution to our problem as it always generates a block container box and establishes a new BFC for its content. As an inner display type, it is actually short for block flow-root, whereas inline flow-root is identical to inline-block value.

Now we can use display values to create new BFC on both block and inline elements, which can be useful not only when handling margins, but for example, when we need to contain floats without using the clearfix hack.

Rememeber, the two-value syntax is not quite alive yet, so you can't use display: inline flow-root (except in Firefox). 👉 Use display: flow-root (but check the browser support first) and display:inline-block instead.

display: list-item

list-item is the default display value for <li> element. It generates a block box for the content and a separate inline box for the marker. In Firefox, the <summary> element also has list-item default display value, but only if it is the first child of the <details> element.

You can specify image, position and type for the list marker, but not distinct styles (like colors or fonts). However, in Firefox list-item creates a ::marker pseudoelement, which has a wider set of allowable properties.

Yes, I use this one quite a lot, but most of the time I wasn't aware that list items use this special display value. Why does it even matter? Well, in the two-value syntax list-item can be combined with both outer and inner display types, making really long display values (like inline flow-root list-item).😄

display: contents

Display values of contents and none define whether an element generates display boxes at all.

While element with display:none will be removed from the layout together with its descendants, 👉 display value of contents removes only the element from the document tree and its children are replacing it. Use it with care as it is marked as an experimental feature on MDN 🧪, although with fairly good browser support.

It makes it especially beneficial to use with Grid or Flexbox, since only the direct descendants of grid or flex containers are behaving as flex /grid items. In case we need to go down one level and make 'the grandchildren' behave as flex / grid items of the main container, 👉 display:content on the direct child of the main container will prevent it from generating a box, and its children will take its place.

In the example below, both purple rectangles are grid containers with orange rectangles as children and grid items. Yellow rectangles are children of the first orange rectangle. In the second container,👉 first orange rectangle is given display value of contents and is no longer visible. His children (yellow rectangles) are taking his place as grid-items, acting as if they were direct descendants of purple rectangle.😎

display: ruby

Ruby annotations are used for adding explanation or pronunciation to base text (usually to East Asian characters). There are two ways of adding a ruby annotation:

👉 with HTML <ruby> element (and corresponding <rt>, <rb>, <rtc> and <rbc> elements for the internal structure)
👉 with CSS display value of ruby (and corresponding ruby-text, ruby-base,ruby-text-container and ruby-base-container display values for the internal structure)

When to use CSS display: ruby?

For document languages (such as XML) that **do not have pre-defined ruby elements **like HTML does, corresponding elements can be translated to ruby elements with the CSS display: ruby property.

When to use HTML <ruby>?

In all other cases. If you have <ruby> element available, you should use it.

Authors using a language (such as HTML) that supports dedicated ruby markup 👉 should use that markup rather than styling arbitrary elements (like <span>) with ruby display values. Using the correct markup ensures that screen readers and non-CSS renderers can interpret the ruby structures.
—W3C, CSS Ruby Layout Module Level 1

That is, the two aren’t mutually exclusive, but I probably won't use CSS display: ruby very often. I tried them both in Firefox and found some subtle differences in default behaviour, which indicates there is still room to further investigate this matter.🤯

It seems like HTML <ruby> alone is good enough for a simple ruby structure, along with some optional ruby-related CSS properties to fine tune the positioning of the ruby text.

DEV Community: Ekaterina Vujasinović

Quiz📣: How Well Do You Understand Asynchronous JavaScript?

1. Which Queue Is Executed First?

2. What Is the Output of the Code Below?

3. In What Order Will Letters Be Logged?

4. Will the Output Change?

Dark Mode With One Line Of Code

filter: invert(100%)

Applying filter with toggle button

The pros and cons of inverting all the pixels

To invert or not to invert?

CSS Comparison Functions clamp(), max() and min()

clamp()

max() and min()

Conclusion

How can object-fit property save you from misusing the background images

Summary

Background vs object-fit

Background images are not accessible

Background images are not SEO-friendly

Are there any performance issues with background images?

Conclusion

Lesser-known CSS display values

Table Of Contents

What display is all about

display: inline-flex and display: inline-grid

display: flow-root

display: list-item

display: contents

display: ruby