javascript

accessibility

html

performance

react

backend

gatsby

web-security

sustainability

astro

typescript

software-development

prisma

redux

testing


Recently, I stumbled over Kitty Giraudel's article
[On disabled and aria-disabled attributes](https://kittygiraudel.com/2024/03/29/on-disabled-and-aria-disabled-attributes/).
He explains the difference and when to use `disabled` and `aria-disabled`.

It depends on the the **intent** of the button. Here's a suggestion on when to
use `disabled`:

> If you have a form with plenty fields, and some of them become irrelevant
> based on the value of other previous fields, using the disabled attribute
> seems like a good option.

On the other hand, using `disabled` on the submit button for this form is a bad
idea. Instead, using `aria-disabled` is the better solution.

> This way, the button remains discoverable (it can be tabbed to) and
> interactive (it can be used to trigger form validation).

I had to think about this for a moment. It absolutely makes sense but I never
applied it in my projects. When I built forms, I always **disabled the submit
button** when the form was not valid.

Kitty mentions a
[lot of articles backing the point of not disabling buttons](#sources). One that
stood out to me was the article
[Disabled buttons suck](https://axesslab.com/disabled-buttons-suck/) by Hampus
Sethfors. It's from 2017 but still relevant today. Hampus lists a lot of reasons
why disabling buttons is a really bad idea:

- They fool users into clicking
- They are hard to see
- They don't give any feedback
- They give design teams a reason to rush through the error handling
- They make users think
- Disabled buttons disable disabled users

That's a long list of reasons. **But what to do instead?** I always thought to
myself:

> "If I disabled the submit button of my form, users will know for sure, that
> they are not done yet".

The solution is simple. **Don't disable the submit button!** Validate the user
input and show an error message when the user tries to submit the form. Let the
user click the button. Always.

## Sources <a name="sources"></a>

- [On disabled and aria-disabled attributes](https://kittygiraudel.com/2024/03/29/on-disabled-and-aria-disabled-attributes/)
  by Kitty Giraudel
- [Disabled buttons suck](https://axesslab.com/disabled-buttons-suck/) by Hampus
  Sethfors
- [The problem with disabled buttons and what to do instead](https://adamsilver.io/blog/the-problem-with-disabled-buttons-and-what-to-do-instead/)
  by Adam Silver
- [Making Disabled Buttons More Inclusive ](https://css-tricks.com/making-disabled-buttons-more-inclusive/)
  by Sandrina Pereira
- [Usability Pitfalls of Disabled Buttons, and How To Avoid Them](https://www.smashingmagazine.com/2021/08/frustrating-design-patterns-disabled-buttons/)
  by Vitaly Friedman
- [Disabled Buttons in User Interface](https://uxplanet.org/disabled-buttons-in-user-interface-4dafda3e6fe7)
  by Nick Babich


Today I learned that disabling buttons is a bad idea. There is a better solution to that.

Do not disable buttons


Scroll-driven animations are a new technqiue coming to CSS that I'm the most
excited about in years. It allows you to animate elements based on the scroll
position of the page.

The best thing about this is, that it's a new set of APIs that work with the
existing Web Animations API and CSS Animations API.

Most features of it are only available in Chrome so far but I'm sure other
browsers will follow soon.

I'm collecting all the resources I can find about scroll-driven animations and
plan to share a huge blog post about it on how to use them as soon as we have
major browser support.

In a recent blog post, Chris Coyier shares a
[great way to make use of this new technqiue to highlight text on scroll](https://frontendmasters.com/blog/highlight-text-when-a-user-scrolls-down-to-that-piece-of-text/).

He uses the `mark` element to highlight text and then animates the
`background-size ` of it.

```html
<p>
  <mark class="scroll-highlight">Scroll-driven animations</mark> are a new
  technqiue coming to CSS that I'm the most excited about in years. It allows
  you to animate elements based on the scroll position of the page.
</p>
```

```css
mark.scroll-highlight {
  background-size: 100% 100%;
  background-repeat: no-repeat;
  background-color: transparent;
  background-image: linear-gradient(purple, purple);

  @supports (animation-timeline: view()) {
    animation: mark-it linear;
    animation-fill-mode: forwards;
    animation-timeline: view();
    animation-iteration-count: 1;
    animation-range: contain 0% contain 25%;
  }
}

@keyframes mark-it {
  0% {
    background-size: 0 100%;
  }
  100% {
    background-size: 100% 100%;
  }
}
```

With this CSS he animates the `background-size` of the `mark` element from 0%
100% to 100% 100% when it's in the viewport. The `animation-range` property is
responsible for that and _starts the animation as soon as the element is fully
in the viewport and finishes it when it's 25% of the way up the currently
viewport_.

Here is a Demo of it on <CodePen id="mdoMQay" title="Home
Scroll Timeline <mark> Element" />.

This looks awesome and I can't wait to use it on my own site!


Chris Coyier shared a technqiue to highlight text on scroll using the upcoming scroll-driven animations.

Hightlight text on scroll


If you want to restrict the width of an element to it's content, you may have
used `display: inline-block` or `display: inline-flex`.

By using this, the element will shrink wrap to the content inside of it.

```css
.container {
  display: inline-block;
}
```

This is a valid solution to achieve this requirement. But there is a better way
to do this. Introducing: `width: fit-content`. The great thing about
`width: fit-content` is, that it leaves the `display` property available.

```css
.container {
  width: fit-content;
}
```

So it's not changing the position of the element in the layout, but it's just a
way to restrict the width of the element to it's content. Here is a **Codepen**,
where you can see the usage of it and it's effect:

<CodePen
  id="gOEGeJp"
  title="fit-content"
/>

### Sources

- [MDN: fit-content](https://developer.mozilla.org/en-US/docs/Web/CSS/fit-content)
- [12 Mondern CSS One-Line Upgrades](https://moderncss.dev/12-modern-css-one-line-upgrades/#width-fit-content)


The property fit-content is super useful if you want to shrink wrap an element to its contents.

fit-content


If you're like me you'll always set links to external pages to **open in a new
tab**. It's my personal preference and I always thought that this is the best
practice because **you don't want to lose the user to the external website**.

After reading Whitney Lewis article on
[How to make external links accessible](https://blog.pope.tech/2024/01/02/how-to-make-external-links-accessible/)
I gathered new information and learned that it's best to **always open external
links in the same tab**.

Whitney argues that it's not necessary to open external links in a new tab by
default because **users always have this choice**. If they want to open a link
in a new tab they can do so by right-clicking on the link and selecting "Open in
new tab". If we open external links in a new tab by default we **take away** the
users choice.

The W3C also recommends to open external links in the same tab in their document
[Opening new windows and tabs form a link only when necessary](https://www.w3.org/TR/WCAG20-TECHS/G200.html).

> In general, it is better not to open new windows and tabs since they can be
> disorienting for people, especially people who have difficulty perceiving
> visual content.

If we go back to my initial argument that we don't want to lose the user to the
external website, Whitney also argues that this is not a valid point:

_"If your user wants to leave the webpage, they will, and trying to keep them
there can feel like a ploy. On the other hand, if they want to stay on your
website, they will. Users can choose to open the link in a new tab."_

### When to use `target="_blank"`

But there are also some valid reasons to open external links in a new tab.

- If you fill out a form and you click on a link to an external website you
  don't want to lose the form data
- If you are on a secure website and it links to an external website that is not
  secure, for examaple if you are logged in to your bank account you possibly
  want to keep the login active
- If you need the information from both websites at the same time, for example
  if you are comparing two products

If you want to open a link in a new tab it's advised to add a **warning** that
it does so, Whitney states. This can be a simple text like "Opens in a new tab"
or an icon like an arrow pointing to the right.

If you choose the use an icon, you have to make sure to make it accessible to
non-visual users. Whitney shares a a great resource for this:
[A beginner’s guide to link accessibility](https://blog.pope.tech/2023/01/01/link-accessibility/)

### Sources

- [How to make external links accessible](https://blog.pope.tech/2024/01/02/how-to-make-external-links-accessible/)
- [Opening new windows and tabs form a link only when necessary](https://www.w3.org/TR/WCAG20-TECHS/G200.html)
- [Opening Links in New Browser Windows and Tabs](https://www.nngroup.com/articles/new-browser-windows-and-tabs/)


Today I learned that external links should always open in the same tab.

Why external links should always open in the same tab


There is a **fundamental difference** in how `width` and `height` work in CSS. I
recently stumbled over this blog post
[Width and Heigh in CSS](https://blog.jim-nielsen.com/2023/width-and-height-in-css/)
by Jim Nielsen in which he talks about the topic. He cites, that he got a great
explanation from Josh in his video
[Secret mechanisms of CSS](https://www.youtube.com/watch?v=Xt1Cw4qM3Ec).

To determine the `width` of an element, the browser **looks up** the DOM tree
and to determine the height of an element, the browser **looks down** the DOM
tree.

What does that mean?

If you set an element to `width: 100%` it will take the width of its parent. So
it's easy to tell an element to take the full width of the page for example.

But height does not work the same way. A lot of developers don't understand that
setting an element to `height: 100%` will not make it take the full height of
its parent. It will take the height of its content. So if you have a `div` with
a `p` inside, the `div` will only be as high as the `p` is.

To be honest, I sometimes still use `height: 100%` and then wonder why it's not
working. But now I know why and I hope you do too.


Width and height in CSS are easy to use but height if often misunderstood.

Width and Height in CSS


Recently, I started Sara Soueidan’s course
[Practical Accessibility](https://practical-accessibility.today/). In one of the
first chapters, she talks about **assistive technology**, the different types of
it, and how they’re used.

She suggests heading to the Tetralogical website to watch their videos about
[how people with disabilities use assistive technology to browse a website](https://tetralogical.com/blog/2021/12/24/browsing-with-assistive-technology-videos/).
Of course, I’ve heard of **screen readers** before and already used one to
browse a website. I’ve also used my **keyboard to navigate on a page**.

But their videos show even more assistive technology in usage, like **screen
magnifiers** and **speech recognition**. I recommend heading over there and
watching their videos.

I’ve learned a ton. It helps so much with **building accessible and inclusive
user experiences**, and I always think about it whenever I build a new feature
on a website.


Today I learned a lot about browsing the web with assistive technology by watching the videos from Tetralogical.

Browsing with assistive technology


The new generic `search` element is now available in
[Chrome 118, Edge 118, Safari 17.0 and Firefox 118](https://caniuse.com/mdn-html_elements_search).
It still lacks support on some mobile browsers, but it's now available in **all
modern browsers**!

Did you hear about the HTML search element? No problem, me neither until today!
Let me quote the
[MDN documentation](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/search):

> The search HTML element is a container representing the parts of the document
> or application with form controls or other content related to performing a
> search or filtering operation. The search element semantically identifies the
> purpose of the element's contents as having search or filtering capabilities.
> The search or filtering functionality can be for the website or application,
> the current web page or document, or the entire Internet or subsection
> thereof.

So, it's a correct semantic wrapper for search forms. When using it, there is no
need to add a `role="search"` to a form anymore.

It's also important to note that the search element should not be used for
presenting search results.

Here's a simple example:

```html
<header>
  <h1>Search for recipes</h1>
  <search>
    <form
      action="/search"
      method="get"
    >
      <label for="recipes">Search for recipes</label>
      <input
        type="search"
        id="recipes"
        name="recipes"
      />
      <button type="submit">Search</button>
    </form>
  </search>
</header>
```

It's so great to see that the web is evolving and that we get new elements like
this is to improve the **semantics** and **accessibility** of our websites and
applications.


The HTML Search Element is a new semantic element that can be used as a container for the parts of the document related to performing a search or filtering operation.

The HTML Search Element


The
[Sustainability Web Design Community Group](https://www.w3.org/community/sustyweb/)
announced the
[Web Sustainability Guidelines](https://www.w3.org/blog/2023/introducing-web-sustainability-guidelines/).
It’s all about _“how to design and implement digital products and services that
put people and the planet first.”_

> This guideline provides best practices and recommendations for reducing the
> environmental impact of web development and design, such as minimizing data
> transfer, optimizing images, using green hosting, and more.

The climate crisis is a real threat, and it’s fantastic that people exist who
care to share their ideas on **how to reduce the impact of our industry**. If
you’ve thought the internet is not a part of the problem, think again.

We are responsible for _“2-5% of global emissions, more than the aviation
industry”._ I want to quote some actions from the
[Web Sustainability Guidelines](https://w3c.github.io/sustyweb/) you can take
immediately to participate in this.

- Minify Your HTML, CSS, And JavaScript
- Avoid Code Duplication
- EnsureYour Solutions Are Accessible
- Use HTML Elements Correctly
- Choose A SustainableHosting Provider
- Optimize Browser Caching
- Be Mindful Of Duplicate Data.

These are just a few suggestions tailored to a **more environmental friendly
web**. The list is long, and I’m sure everybody will find something they can
apply there. The key takeaway I get from this is **anything you already do to
improve the accessibility of your website and the loading performance is also
good for the environment**.

If you’re interested in sustainable web design, check out
[https://sustainablewebdesign.org/](https://sustainablewebdesign.org/), listed
as the **Implementation** of the Web Sustainability Guidelines.


The Sustainability Web Design Community Group announced the Web Sustainability Guidelines. It’s all about “how to design and implement digital products and services that put people and the planet first.”

Web Sustainability Guidelines


You may have already heard that a new
[View Transitions API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API)
has been developed and will soon be available in all major browsers.

View Transitions help the user to stay in **context** when switching between
pages or states. For example, the user might click a link to another page, and
some elements might be animated to make the transition smoother and make it feel
less like a hard switch between the two pages.

It’s what makes most native apps **superior** in that case and looking so cool
and smooth. SwiftUI has had this kind of technology for years.

I have planned a whole blog post about the new View Transitions API as an
in-depth tutorial, but I will wait until every major browser supports them
(looking at you, Firefox), and we can use it in production.

Nevertheless, I’d like to discuss them briefly because
[Astro released a new major version (3.0)](https://astro.build/blog/astro-3)
last week. Part of this new release is enabling developers to use view
transitions inside Astro. That makes them the **first web framework to support
the View Transitions API**.

They offer these four different ways:

- **Morph** persistent elements from one page to another
- **Fade** content on and off the page for a less jarring navigation effect
- **Slide** content on and off the page for a bit more personality
- **Persist** common UI across pages, with or without a refresh

It’s straightforward to implement and use. You just have to import and add the
view transitions routing component on the page you want to use them.

```jsx
---
import { ViewTransitions } from 'astro/dist/components/view-transitions.js'
---

<h1>My Page</h1>
<ViewTransitions />
<div transition:name="fade">
  <p>Some content</p>
</div>
```

Astro will **automatically** create default page animations based on the
similarities between the old and the new pages. That’s all!

You can also identify the corresponding view transition element yourself. For
example, I wanted a view transition on the image in a blog post overview page
and on the image on the individual blog post.

So first, you view the list of blog posts, and when clicking on a specific blog
post, a view transition should happen on that image.

To achieve that, you only need to add the same `transition:name` value on both
image elements. It’s like magic!

If you want to see view transitions live in Astro, check out the
[Spotify clone built by Igor](https://github.com/igorm84/spotify-astro-transitions).
You have to make sure to use Chrome for that.

I’m curious how we’ll take advantage of this new possibility and if it will
change how it feels to browse the web.

## Sources

- [Astro 3](https://astro.build/blog/astro-3)
- [View Transitions](https://docs.astro.build/en/guides/view-transitions/)
- [Can I use view transitions](https://caniuse.com/?search=view%20transitions)
- [Spotify Astro Transitions on GitHub](https://github.com/igorm84/spotify-astro-transitions)


View Transitions will soon be available in all major browsers and Astro is the first framework to support them.

View Transitions are coming (Astro 3.0)


CSS has become way more **powerful** over the last few years. A lot of
significant improvements were added to the language, and I like the way where it
is going.

Recently, I stumbled over this
[CSS Selectors Visual Guide by Sébastien Noël](https://fffuel.co/css-selectors),
and I love it. I would have loved this when I started learning and working with
CSS!

As the name suggests, it is a **visual guide to all the CSS selectors**. You get
an example of the selector on the left and an image of the selected element on
the right. I'm surprised no one else has done this before.

This is a definite bookmark for me. Although I've been working with CSS for
years, I even **learned something new**. I learned about the
[lobotomized owl selector](https://fffuel.co/css-selectors/#lobotomized), which
selects all elements with a preceding sibling.

```css
* + * {
  margin-top: 1.5em;
}
```

It's a great way to select all elements, but not the first one in a container. I
can imagine that I will visit this guide a lot in the future because of the
great overview it provides. If you forgot about the exact selector for valid
inputs or attribute selectors just head over there.


Today I learned about this visual guide to all CSS selectors

CSS Selectors Visual Guide


This is technically not a "Today I learned" post because I already knew that
knowing semantic HTML is important. This post is more of a reminder to myself
and others that HTML is still the most important language to learn.

So today, I learned that learning and knowing semantic HTML is still important.

Every developer saw these websites where the DOM consists of a bunch of `div`s
and maybe even worked on a website like that themselves. I know I did. And I
wasn't proud of it. But thankfully, we can do better.

This week I stumbled over two blog posts. The first one is
[I'm betting on HTML](https://catskull.net/html.html), which highlights their
favorite HTML elements. The second one is
[A Blog Post With Every HTML Element](https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/)
by Patrick Weaver in which, as the title says, he uses every HTML element in a
blog post.

I'd like to share my favorite parts of these blog posts here, so let's jump
right in.

The range of input types is amazing. You get so much functionality without any
JavaScript.

### Different input types

<label htmlFor="color">Color:</label>
<input
  id="color"
  type="color"
/>

{' '}

<br />
<label htmlFor="date">Date:</label>
<input
  type="date"
  id="date"
/>
<br />
<label htmlFor="datetime-local">Datetime-local:</label>
<input
  type="datetime-local"
  id="datetime-local"
/>
<br />
<label htmlFor="range">Range:</label>
<input
  type="range"
  id="range"
/>

Built-in datepickers? Come on! Everyone who has ever built a datepicker knows
how much work it is to make it accessible and usable. And here we have it for
free.

### Meter

The `meter` element is also pretty cool.

<meter value="0.5">50%</meter>
<meter value="0.75">75%</meter>
<meter value="1">100%</meter>

Firefox shows them all as green, but Safari shows them as red, yellow, and green
depending on the value.

### Progress

And of course, the `progress` element.

<label htmlFor="progress">Progress:</label>
<progress
  id="progress"
  value="0.85"
>
  85%
</progress>

Make sure you use a label for it. Otherwise, it's not accessible.

### Mark

I've worked with JS libraries just to highlight some text. Did you know that's
possible with HTML? I didn't. What a shame.

<mark>highlighted text</mark>

Quick and reasy way to highlight text without any JS.

### Differences between elements

The difference between `strong` and `b` is also interesting. `strong` is for the
meaning of the text and `b` is for the presentation. So use `strong` if you want
to emphasize the text and `b` if you want to make it bold.

I think the same goes for `em` and `i`. `em` is for single words, and `i` is for
phrases.

### Samp

Have you ever used `samp`? I haven't. I didn't even know it existed until I read
Patrick's blog post. It's used to render the output of a computer program. I
always used `code` for that.

<figure className="flex flex-col">
  <figcaption>A little JavaScript program:</figcaption>
  <code>const name = 'Patrick'</code>
  <code>console.log(`Hello ${name}!`);</code>
  <samp>Hello Patrick!</samp>
</figure>

Looks all the same but the last line is rendered as `samp` instead of `code`.

### Wbr

Another one I have never heard before is `wbr`. It's used to tell the browser
where it can break long words. It's a gread thing to use for long URLs. The
points where it breaks are more clear which makes it more readable compared to
not using `wbr`.

These were the highlights of my weekly HTML digest. I strongly recommend reading
both mentioned blog posts above because they cover a lot more than I did here.

## Sources

- [I'm betting on HTML](https://catskull.net/html.html)
- [A Blog Post With Every HTML Element by Patrick Weaver](https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/)

- [Color](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color)
- [Date](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date)
- [Datetime-local](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local)
- [Range](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range)
- [Meter](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter)
- [Progress](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress)
- [Mark](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/mark)
- [Samp](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp)


Learn HTML! It is still the foundation of the web and the most important language to learn.

Learn HTML


I have **never used** **Web Components** before. I’ve heard of them, for sure.
I’ve seen several blog posts and coding examples about how to build web
applications with them. But I never actually used code that included Web
Components.

I never considered choosing them for a new website instead of React or any other
JavaScript Framework. I always thought: they seemed to be a general approach for
building web applications so we, as developers, wouldn’t need to rely on
independent frameworks anymore. But the point where they would overtake never
came.

Ever wondered why they haven’t succeeded yet? Dave Rupert has a lot to say about
this. He wrote a blog post,
[“If Web Components are so great, why am I not using them?”](https://daverupert.com/2023/07/why-not-webcomponents/)
where he shares his opinion on **why web components haven’t taken over yet**,
and what he’d done differently if he could turn back time.

I’ll summarize his key takeaways here, but make sure you’ll check out his whole
blog post and the included links because reading his take on the topic is super
interesting.

In general, Dave says Web Components have a **marketing problem**. That’s the
biggest problem. This can be broken down into the following points:

- Web Components were designed for framework authors, not the average WordPress
  user. But Framework authors **declined** to use them because their problems
  were already solved otherwise.
- They were marketed as a **Google thing** and a bit too heavy on bashing other
  frameworks and selling Web Components as the only true thing.
- It was hard to convince others to use Web Components without the ability to
  refer to popular products built with them.
- They have been around for a few years but only became indeed **supported
  recently**.
- Their development is **slow**. If you’re waiting for a new feature for them
  available in every browser, you have to wait a couple of years.

Dave made many interesting points, which made me understand better why Web
Components are not there yet where they were supposed to be. I’m curious how
they will evolve in the future!


Have you used Web Components? I have not and I wondered why. Dave Rupert has a lot on opinions why Web Components have not succeeded yet and in this post I summarize his blog post.

Have you used Web Components?


If you wanted to integrate a popover on a website before, you had to reach out
to a **third-party package** in the past because they made it easy to customize
things like positioning and enhancing functionality. This may soon be a tale of
the past!

[The popover API](https://hidde.blog/popover-semantics/) with the popover
attribute was introduced recently and is available in Chromium 114. By using
this new popover API, it will be **easier to integrate popovers into websites**.
It brings all the needed functionality and satisfies all the **accessibility
concerns**. And all of that without using any JavaScript.

To make use of the new popover API, three basic things are required:

- the popover attribute on the element containing the popover
- an id on the element containing the popover
- the element which opens the popover needs to have a popovertarget attribute
  with the value of the popover’s id

```html
<button popovertarget="popover">Open popover</button>

<div
  popover
  id="popover"
>
  <p>Popover content</p>
</div>
```

Implementing such a popover is **accessible by default** because the popover and
its trigger are **connected semantically**. Furthermore, closing the popover
with the ESC key is built-in, making it easy for keyboard users to dismiss it.

In addition to that, the new popover has a **light-dismiss functionality**. If
you click anywhere outside the popover, it will close and return focus. If you
open the popover, the next keyboard tab will stop inside the popover, so **focus
management is handled by default**.

Another great advantage of it is that the popover will always appear on a
separate level above the rest of the page, so there is **no need for manual
z-index handling**.

That’s such a great addition, I can’t wait until it’s stable in all modern
browsers and we can use it! It’s a big step into easier and faster ways to build
websites and improve accessibility by default.

It’s important to note that the new popover attribute **will only add behavior,
not semantics**. Popovers have no default role, and you’re supposed to add your
own semantics to it! Hidde de Vries wrote an
[excellent post about different semantics](https://hidde.blog/popover-semantics/)
that could make sense for popover-behaved elements. He takes a closer look at
menus, dialogs, and listboxes.

### Sources

- [Introducing the popover API by Una Kravets](https://developer.chrome.com/blog/introducing-popover-api/)
- [Popover semantics by Hidde de Vries](https://hidde.blog/popover-semantics/)


The popover API is a new HTML attribute that makes it easy to integrate popovers into websites without the need for JavaScript.

The popover API


If you browse the web, you'll notice quickly that **sticky menus are used
often**. Sometimes I'm happy they're on a website, so I can quickly reach
call-to-action buttons or other important information. But most of the time, it
feels to me that they **take up a lot of space** away, and I intend to
**remove** them.

Seeing them so much in the wild was a validation to me. If implemented this
often, they must be helpful and improve the user experience. But if you think
about it: every website uses cookie banners, e-mail sign-up modals, and other
kinds of overlays, and we all hate them and know it's terrible UX.

So I was curious when I stumbled over this post by Adam Silver:
["The problem with sticky menus and what to do instead."](https://adamsilver.io/blog/the-problem-with-sticky-menus-and-what-to-do-instead/)
He states several well explain arguments on **why to avoid sticky menus and
shares better alternatives**.

His key takeaways, why we should replace them are:

1. **They constantly take up space**
2. **They obscure content**
3. **They break when you zoom in**
4. **They're difficult to access**
5. **Internal page anchors feel broken when clicked twice**
6. **They appear closer than they are**
7. **They obscure links and other focusable elements**

While most are obvious and reasonable arguments, numbers six and seven stood
out. I wasn't aware that sticky menus not only **decrease user experience** in
general but they're also reducing **accessibility** by a lot.

Sticky menus make us think that they are always very close to reach. That might
be true if you're using a mouse. You just move to it and can click. But, ever
tried to navigate to a sticky menu with a keyboard? Oh boy! They are often way
out of the normal document flow and very **hard to reach using the tab key**.

More accessibility problems arise if you're trying to move up the page with your
keyboard. Chances are you reach content that's right below the sticky menus. So
links and other focusable elements are not visible to you because they get
obscured by sticky menus.

Adams's advice on what to do instead is:

- **Keep pages short. This removes the need for a sticky menu**
- **Just let users scroll.**
- **Scrolling is never a problem, is fast, and everyone does it anyway**
- **Instead of putting important CTAs into a sticky menu, put them in a context
  like a CTA at the end of a pricing section**

If you think about implementing a sticky menu, I hope this post helps you to
think again by summarizing Adams's points here and sharing his alternatives.
Because sticky menus can have serious issues!


Sticky menus are used widely on the web but come with some serious issues. In this post I learned about the problems they cause and what to do instead.

The problem with sticky menus


If you've been working with SCSS, you know that **nesting** in CSS is possible
by using this **extension** of the language.

In SCSS, you could write something like this to style the children of a parent:

```scss
.parent {
  color: red;

  .child {
    color: blue;
  }
}
```

To achieve the same thing in CSS, you would have to write something like this:

```css
.parent {
  color: red;
}

.parent .child {
  color: blue;
}
```

This is not a big deal if you only have one child, but if you have multiple it
can get **messy and very repetitive**.

The W3C worked on a new module to finally **enable CSS nesting without the need
of a preprocessor**.

Their main reason for doing this was to increase the "modularity and
maintainability of CSS stylesheets." Furthermore, they explain their motivation
as follows:

> The CSS for even moderately complicated web pages often includes lots of
> duplication for the purpose of styling related content.

Here's how you can nest CSS without the need for SCSS:

```css
.parent {
  color: red;

  .child {
    color: blue;
  }
}
```

It's the same as in SCSS, so if you're used to that syntax, you don't have to
re-learn a lot!

It's also possible to use relative selectors when using nesting:

```css
.parent {
  color: red;

  &:hover {
    color: blue;
  }

  + .sibling {
    color: green;
  }
}
```

The only thing that's not valid is to use nesting selectors that start with an
**identifier**:

```css
.parent {
  color: red;

  input {
    color: blue;
  }
}
```

You can look at all the valid nestings in the
[specification](https://www.w3.org/TR/css-nesting-1/#nesting-rules). They also
provided an in-depth explanation of why there is a need for **restrictions** on
nested rule selectors.

I think that's a great addition to the language. If you want to try it out right
away, you can test it in the latest releases of Chrome, Edge, and Safari. You
can check out the browser support here:
[Can I use - CSS nesting](https://caniuse.com/css-nesting).

### Sources

- [CSS Nesting Module](https://www.w3.org/TR/css-nesting-1/)
- [CSS Nesting](https://developer.chrome.com/articles/css-nesting/)


CSS Nesting is finally built into the language. No need for a preprocessor anymore! In this post, I'll look at the spec and valid selectors.

CSS Nesting


Today I learned about the tool [Image Carbon](https://imagecarbon.com/). It's a
tool that helps you to calculate the carbon footprint of your websites images.

After entering a URL it will show you the amount of CO2 you could reduce by
optimizing your images. It can achieve that by uisng the
[Sustainable Web Design](https://sustainablewebdesign.org/calculating-digital-emissions/)
model.

It checks every image on your page for the format and the size and tells you how
you could improve on that.

Here are the results for my website:
[https://www.imagecarbon.com/sites/marcoheine.com](https://www.imagecarbon.com/sites/marcoheine.com)

Reducing your image sizes by compressing them and using better formats is not
only better for your websites performance but also for reducing the carbon
footprint.


Image Carbon is a tool that helps you to calculate the carbon footprint of your websites images

Image Carbon


If you're working on websites where the content is very flexible, where editors
can add text, for example, via a CMS, you often don't know "the final size, font
size or language of text".

It's hard, especially for headlines, to make two lines consistent in the number
of words per line.

Often it looks weird when a headline breaks on a specific breakpoint and just
one word gets wrapped in the following line.

We always had to use techniques that felt more like hacks to enforce a more
consistent wrap. Using `<br />` tags or `&nbsp;.` Counting the words with
JavaScript and adding `<span>` tags around them.

Very soon, we will have a new CSS property called `text-wrap: balance` that will
help us with this.

To use this CSS property, you will need to apply it like this:

```css
.my-headline {
  max-width: 20rem;
  text-wrap: balance;
}
```

This will ensure that the text is balanced over two lines and that the number of
words stays consistent. At the same time, it does not affect the element's width
and will only affect the words within the element.

Only using this property may not be enough because the text needs to wrap and
therefore needs a max width.

Here's a direct comparison of the same text with and without
`text-wrap: balance`:
![a screenshot showing two headlines, the first one does not wrap nicely, the second does.](/images/text-wrap-balance.webp)

Both have set the same max-width but only the second one has the new property
set. The first one has a weird break where it wraps only one word into the next
line while the second one is balanced over two lines.

Ahmad has a lot of great examples of where this new property could be useful:
[CSS Text balancing with text-wrap:balance](https://ishadeed.com/article/css-text-wrap-balance/)

[Adam Argyle argues](https://developer.chrome.com/blog/css-text-wrap-balance/)
that balancing headlines is the primary use case for `text-wrap: balance.`

It's currently only available in Chrome Canary and behind a flag. But it looks
promising that we will be able to use this property soon in all major browsers.

### Sources:

- [CSS Text balancing with text-wrap:balance](https://ishadeed.com/article/css-text-wrap-balance/)
- [CSS text-wrap: balance](https://developer.chrome.com/blog/css-text-wrap-balance/)


Text-wrap balance is a new way to specify with CSS how lines of text are balanced.

Text-wrap: balance


As we all know, **the web is not accessible**, and that's a big bummer. A lot of
developers know way too less about accessibility, as we see if we look at the
HTML structure of websites, which often just consist of a ton of `divs.`

On the other hand, a lot of companies don't pay for or don't have the budget for
accessibility audits and improvements and the increased workload that comes with
building accessible websites.

It's our job as developers to **make accessibility a mandatory part of our
work** and create awareness for it. Sooner or later, new websites will have to
be accessible by law.

I'm not an expert in accessibility, but I'm trying to improve my knowledge of it
every day and with every new website or component I build.

Recently I built a modal dialog for a website, and here's everything I learned
and applied to make it accessible.

## Building accessible modal dialogs

There are a few key things to remember when building accessible modal dialogs.
First of all, we need to ensure that the modal dialog can be **accessed and
navigated with a keyboard only**.

Next, the **keyboard focus** should be managed properly. When opening the modal,
the focus should be on the first focusable element inside the dialog. This
enables keyboard users to navigate the modal dialog with the tab key right away.

Additionally, the elements behind the modal should be **hidden** from screen
readers and not be focusable so users who use assistive technologies don't get
lost in a sea of content.

To support this, the modal dialog should also be **full-screen on mobile**.

An obvious thing but often not implemented correctly is that the modal dialog
should be **closable with a certain close button** and also be able to be
**closed with the escape key**.

When you implement all of these things, you'll have a pretty accessible modal
dialog and help many of people who use assistive technologies to access your
content without any problems.

The important properties to enforce these things are the following:

### role="dialog"

First and foremost, if you're not using the
[html5 `<dialog>` element](#html5-dialog-element), you need to give your modal
dialog the `role="dialog"` attribute. This tells screen readers that the element
is a dialog and not just a regular div. The proper HTML element for your dialog
can be a `div` or a `section.`

### aria-modal="true"

You also need to give your modal dialog the `aria-modal="true"` attribute. This
tells screen readers that the dialog is modal and that the user needs to
interact with it before they can continue.

It also helps with getting lost in content, which I talked about earlier by
limiting the navigation to the modal dialog content and hiding elements in the
background.

### aria-labelledby and aria-describedby

Next, you need to give your modal dialog an `aria-labelledby` attribute with the
id of the title of the dialog. This tells screen readers which title belongs to
the dialog.

If you don't have a descriptive title element inside your modal dialog, you can
use the `aria-label` attribute instead.

If you have a description for your modal dialog, you can use the
`aria-describedby` attribute to tell screen readers which element contains the
description.

### aria-label="close modal"

Often, close buttons do not consist of descriptive text like "close". Instead,
icons, svgs, or images are used. In this case, you need to give the close button
the `aria-label="close modal"` attribute to tell screen readers what the button
does.

## What about the html5 dialog element? <a name="html5-dialog-element"></a>

There exists a new HTML5 element called `<dialog>.` It was introduced in
Chromium 37 back in 2014. Unfortunately,
[it's not yet widely supported by all browsers](https://caniuse.com/?search=dialog),
but we may be able to use it without any polyfills very soon. So if you're just
looking to support modern browsers, you can use it right now.

It then can be used instead of `role="dialog"` because it's the semantic html5
equivalent.

## Sources and further reading:

- [Technique: Accessible modal dialogs ](https://accessibility.huit.harvard.edu/technique-accessible-modal-dialogs)
- [Modal Dialog Example ](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/)
- [The a11y Monthly: Making modals accessible](https://yoast.com/developer-blog/the-a11y-monthly-making-modals-accessible/)


Today I learned how to make modal dialogs accessible so that they can be used by people who use assistive technologies to navigate the web.

Building accessible modal dialogs


I never was a big fan of Sliders and Carousels. Also, creating them as a
front-end developer was always a pain. So whenever possible, I suggested using
**horizontal scrolling** as an alternative.

Combining it with the `CSS scroll-snap properties` allows us to create **smooth
and precise scrolling experiences**, which is super cool.

To get started, you have to look at the two properties, and how they play
together to make these scrolling experiences.

The first property is
[scroll-snap-type](https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap-type).
It defines the type of scrolling behavior for the scroll container. It can be
set to `x, y, or both`. The default value is `none`.

for example if you set it to `x`, the scroll container will snap to snap
positions on its horizontal axis only.

The second property is
[scroll-snap-align](https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap-align).
It defines the alignment of the snap position relative to the scroll container.
It can be set to `start, center, or end`.

If you set it to `start` for example, the snap position will be aligned to the
left of the scroll container. So every item you scroll by snaps until its left
edge is aligned with the left edge of the scroll container.

So far, the theory. Now let's look at some examples to showcase the different
possibilities for creating these scrolling experiences.

Here is a CodePen with examples of the different scroll snap types and
alignments:

<CodePen
  id="WNgWjaM"
  height="800"
  defaultTab="result"
  title="CSS Scroll Snap"
/>

It's awesome see that we are able to create these scrolling experiences with CSS
only and without any JavaScript.


Today I learned about how you create a scroll snap effect in CSS with the scroll snap properties.

CSS Scroll Snap


**React Server Components** are one of the most talked topics in the React
community right now.

They are a new way to build React apps that will be released in the future. They
are not yet available, but we can already start to learn about them.

They were first introduced as an **RFC (Request for Comments)** in
December 2020. Here is the blog post, where they were introduced as a current
research:
[Introducing Zero-Bundle-Size React Server Components](https://beta.reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components)

And here is a link to the RFC, which is super interesting to read, to get the
idea behind them and how the concept developed since then:
[RFC: React Server Components](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md)

Dan Abramov, one of the React core team members, has been putting a lot of
effort into educating everybody on Twitter and answering questions about them.

He recently met up with Kent C. Dodds and Joe Savona, whos Tech lead in the
React organization in Meta. I totally recommend to watch the whole video:
[React Server Components with Dan Abramov, Joe Savona, and Kent C. Dodds](https://www.youtube.com/watch?v=h7tur48JSaw&t=427s)

They tried to answer all of Kents' questions about React Server Components and
there was a lot of insights to be learned.

In this post I want to summarize the most important things I know about React
Server Components so far.

In the future, we'll be able to differentiate between **Server Components** and
**Client Components**. Both will have different abilities and limitations. Let's
take a look on the things they can do:

### Server Components

- can directly access server data
- can use this data to generate html and return it to the browser
- read data on the server, pass it down by props
- each component can fetch the data that it needs
- they can hand of the rendering to the client by importing and rendering a
  "client" component
- includes the server into the unidirectional data flow
- maybe we don't need to build APIs anymore, when using server components
- they can't use state or effects
- they can't use browser-only APIs like the DOM
- help to reduce the bundle size, by giving us the ability of shifting
  third-party dependencies to the server

### Client Components

- are inside the server components
- can be interactive JSX components
- HTML created at runtime in the browser from JavaScript
- are marked with 'use client' at the top and therefore only included in the
  bundle if they are used
- can use state, effects, lifecycle methods, custom hooks
- the components we are already used to

To fully understand this new separation, lets take a look at a simple example:

```ts
// server
import db from './db'
import UserDetail from './UserDetail'

export const User = () => {
  const user = db.getUser(id)
  return <UserDetail user={user} />
}
```

```jsx
// client
'use client'
export const UserDetail = ({ user }) => {
  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  )
}
```

In this example, the server component `User` fetches the user data from the db
and passes it down to the client component `UserDetail`. The client component
then renders the HTML.

This is a very simple example, but it shows the basic idea of how server and
client components work together.

The split between server and client components will enable us again to **take
full advantage of the server**. By shifting several main tasks, like data
fetching, to the server, we can **reduce the bundle size** and **improve the
performance** of our apps.

I'm very curious to see how this will work in practice. I think it will be a big
step forward for React and the whole ecosystem. And maybe a totally new way to
build web apps in the future.


Today I learned about React Server Components, what they are and how they will be useful.

React Server Components


A good friend of mine, [Tommy](https://github.com/ItsTommyGun), recently built
this cool **SVG drawing animation**. I was curious how he did it because I'd
never done something like this before, and he was kind enough to explain it to
me.

First and foremost, you need an SVG with a stroke because strokes can be dashed.
Here's the SVG we are going to animate like it's being drawn:

<svg
  width="165"
  height="47"
  xmlns="http://www.w3.org/2000/svg"
>
  <g>
    <path
      stroke="#000"
      strokeWidth="2"
      d="m70.1895,4.65437c0,0 -2.48485,-0.39525 -6.58888,-0.67265c-4.99273,-0.33748 -8.23605,-0.67265 -10.70688,-0.67265c-4.11805,0 -8.18497,0.33517 -13.17771,0.67265c-2.46241,0.16644 -4.9458,-0.09537 -6.58885,0c-5.80915,0.33716 -8.2581,0.5181 -9.05968,0.67265c-3.58476,0.69114 -7.48447,2.55199 -11.53051,4.03588c-1.68001,0.61615 -2.62402,1.13847 -4.11802,2.01792c-1.88981,1.11244 -3.19367,3.40762 -4.11804,4.7085c-1.49051,2.09762 -2.05363,3.95418 -2.47082,6.0538c-0.39578,1.99189 0,4.03588 0,5.38117c0,0.67263 -0.47734,2.07563 0,3.36321c0.86053,2.3212 1.81754,3.2372 3.29443,4.7085c1.88267,1.87555 2.62402,3.15642 4.11804,4.03588c1.88978,1.11242 3.24017,2.78763 4.94163,3.36321c2.40622,0.814 6.48882,2.34985 9.05968,2.69058c1.62596,0.21549 6.596,0.23456 12.3541,0c8.26688,-0.33674 18.11936,-0.67265 25.53182,-0.67265c1.64722,0 2.47081,0.67265 9.05968,0.67265c13.17771,0 23.06097,0 28.82624,0c6.58885,0 14.83752,0.37197 23.061,0c7.44667,-0.33683 9.8939,-1.23755 10.70688,-1.34529c5.14167,-0.68144 10.79607,-1.92737 15.64853,-2.69058c4.35523,-0.68501 7.66779,-2.24494 9.88329,-3.36321c0.9908,-0.50011 1.5026,-0.73851 2.47081,-2.01794c0.43299,-0.57218 0.37788,-1.13908 0.82361,-2.01794c0.31518,-0.62143 0,-1.34527 0,-3.36321c0,-2.01794 -0.94246,-3.31891 -1.64722,-4.7085c-0.99668,-1.96517 -2.62752,-3.95618 -4.11802,-6.0538c-1.84875,-2.60179 -4.48905,-5.68417 -6.58885,-7.39909c-2.0998,-1.71492 -3.92127,-2.97033 -6.58885,-4.03586c-2.33965,-0.93454 -8.25684,-2.61075 -12.35412,-3.36323c-3.31308,-0.60845 -6.62075,-0.34941 -9.05966,-0.67265c-2.57086,-0.34073 -7.4325,-0.34125 -11.53051,-0.67265c-4.17915,-0.33796 -7.9421,1.13881 -12.8042,0.15254c-2.52765,-0.51275 -9.14435,0.40914 -14.06916,0.07626c-4.99273,-0.33748 -5.51904,-0.97084 -6.34265,-0.97084c-1.64722,0 -7.14913,-0.74891 -7.97274,-0.74891l-3.7274,0l-3.84628,0.45071"
      fill="none"
    />
  </g>
</svg>

And here's the HTML of it:

```html
<svg
  width="165"
  height="47"
  xmlns="http://www.w3.org/2000/svg"
>
  <g>
    <path
      stroke="#000"
      strokeWidth="2"
      d="m70.1895,4.65437c0,0 -2.48485,-0.39525 -6.58888,-0.67265c-4.99273,-0.33748 -8.23605,-0.67265 -10.70688,-0.67265c-4.11805,0 -8.18497,0.33517 -13.17771,0.67265c-2.46241,0.16644 -4.9458,-0.09537 -6.58885,0c-5.80915,0.33716 -8.2581,0.5181 -9.05968,0.67265c-3.58476,0.69114 -7.48447,2.55199 -11.53051,4.03588c-1.68001,0.61615 -2.62402,1.13847 -4.11802,2.01792c-1.88981,1.11244 -3.19367,3.40762 -4.11804,4.7085c-1.49051,2.09762 -2.05363,3.95418 -2.47082,6.0538c-0.39578,1.99189 0,4.03588 0,5.38117c0,0.67263 -0.47734,2.07563 0,3.36321c0.86053,2.3212 1.81754,3.2372 3.29443,4.7085c1.88267,1.87555 2.62402,3.15642 4.11804,4.03588c1.88978,1.11242 3.24017,2.78763 4.94163,3.36321c2.40622,0.814 6.48882,2.34985 9.05968,2.69058c1.62596,0.21549 6.596,0.23456 12.3541,0c8.26688,-0.33674 18.11936,-0.67265 25.53182,-0.67265c1.64722,0 2.47081,0.67265 9.05968,0.67265c13.17771,0 23.06097,0 28.82624,0c6.58885,0 14.83752,0.37197 23.061,0c7.44667,-0.33683 9.8939,-1.23755 10.70688,-1.34529c5.14167,-0.68144 10.79607,-1.92737 15.64853,-2.69058c4.35523,-0.68501 7.66779,-2.24494 9.88329,-3.36321c0.9908,-0.50011 1.5026,-0.73851 2.47081,-2.01794c0.43299,-0.57218 0.37788,-1.13908 0.82361,-2.01794c0.31518,-0.62143 0,-1.34527 0,-3.36321c0,-2.01794 -0.94246,-3.31891 -1.64722,-4.7085c-0.99668,-1.96517 -2.62752,-3.95618 -4.11802,-6.0538c-1.84875,-2.60179 -4.48905,-5.68417 -6.58885,-7.39909c-2.0998,-1.71492 -3.92127,-2.97033 -6.58885,-4.03586c-2.33965,-0.93454 -8.25684,-2.61075 -12.35412,-3.36323c-3.31308,-0.60845 -6.62075,-0.34941 -9.05966,-0.67265c-2.57086,-0.34073 -7.4325,-0.34125 -11.53051,-0.67265c-4.17915,-0.33796 -7.9421,1.13881 -12.8042,0.15254c-2.52765,-0.51275 -9.14435,0.40914 -14.06916,0.07626c-4.99273,-0.33748 -5.51904,-0.97084 -6.34265,-0.97084c-1.64722,0 -7.14913,-0.74891 -7.97274,-0.74891l-3.7274,0l-3.84628,0.45071"
      fill="none"
    />
  </g>
</svg>
```

The key to the animation are the
[stroke-dasharray](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-dasharray)
and
[stroke-dashoffset](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-dashoffset)
properties.

The `stroke-dasharray` property defines the **length** of the dashes, and the
`stroke-dashoffset` property defines the **offset** of the dashes.

```css
svg {
  stroke-dasharray: 372;
  stroke-dashoffset: 372;
  animation: draw 0.5s linear forwards;
}

@keyframes draw {
  to {
    stroke-dashoffset: 0;
  }
}
```

The `stroke-dasharray` property is set to 372, which means that the dashes are
372px long.

The `stroke-dashoffset` property is also set to 372, which means that the dashes
are offset by 372px, so the dashes are **not visible** at all.

The animation is set to 0.5 seconds, and the `stroke-dashoffset` property is
animated to 0, which makes the dashes **appear one after another**.

That's how we make our SVG look like it's being drawn!

The `stroke-dasharray` property can be set to any value. The higher the value,
the longer the dashes will be. The same goes for the `stroke-dashoffset`
property. The higher the value, the longer the dashes will be offset.

We set it to exactly the length of the path so that the dashes are the same as
the path, and there are no gaps.

Here's great article by CSS-Tricks that explains this technique in more detail:
[How SVG Line Animation Works](https://css-tricks.com/svg-line-animation-works/).

And here is the result:

<CodePen
  id="PodJEge"
  title="SVG Drawing Animation"
/>

The only drawback is that you need to know the length of the path. That's it, a
simple SVG animation without any JavaScript at all!


Today I learned how to animate SVG drawings using CSS.

SVG Drawing Animation


Vercel released [Cron Jobs](https://vercel.com/blog/cron-jobs) recently! That is
pretty cool. It's a feature a lot of people longed for because something like
this was not available yet when using serverless environment like Vercel.

Now you can automate repetetive tasks without having a backend. To get started
with Cron Jobs in Vercel you have to create a `vercel.json` file. Here are some
example Cron Jobs:

```json
{
  "crons": [
    {
      "path": "/api/backup",
      "schedule": "0 0 * * *"
    },
    {
      "path": "/api/weekly-mail",
      "schedule": "0 0 * * 1"
    }
  ]
}
```

Cron Jobs use a specific syntax to determine the time when the job should be
executed. The schedule string consists of five fields separated by spaces. They
stand for minute, hour, day, month and day of the week.

So the first job in the example above will be executed **every day at
midnight**. While the second job will be executed **every Monday at midnight**.

With the Hobby plan you get two Cron Jobs for free which each can be triggered
once per day, while the Pro plan offers 40 Cron Jobs in total with unlimited
usage per day.

Here's the full documentation of Cron Jobs in Vercel:
[Cron Jobs](https://vercel.com/docs/cron-jobs)


Today I learned that Vercel introduced Cron Jobs recently. So now you can automate repetetive tasks in a serverless Environment like on Vercel.

Vercel Cron Jobs


Filling forms can be an **annoying and painful user experience**, especially if
you're on mobile. If you've ever tried to fill a long form on your phone and the
inputs weren't set up correctly, you know what I'm talking about.

The wrong keyboard opens, and you have to switch to special characters or
numbers all the time.

But this can be made so much easier and user-friendly with some simple steps.
Using the right input type value for the input is the first and, in most cases,
the only step you need to take.

For example, `<input type="email" />` will open up the right virtual keyboard on
mobile. The same goes for `type="url"`, `type="tel"` or `type="number"`.

But there are more attributes you can offer to make the user experience even
better.

Big thanks to Jeremy for teaching me about these attributes in this great
article
[Three attributes for better web forms](https://adactio.com/journal/19842?skin=default).

### inputmode

Inputmode is an attribute that can tell the browser to show a **specific virtual
keyboard**. This is redundant if you've already set the type to
`email, tel, url` or `search`.

But if you have an Input with the type text and you want to tell your users to
enter numbers there, `inputmode="numeric"` is super helpful. You can even
enclose the input by using `pattern="[0-9]*"`.

The other possible values for `inputmode` are
`text, numeric, decimal, search, email, tel` and `url`.

To learn more about it, check out the
[MDN documentation for inputmode](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode).

### enterkeyhint

As explained above, the inputmode provides help to show the correct virtual
keyboard, whereas the `enterkeyhint` attribute provides help to specify what is
shown on the enter key on a virtual keyboard.

The possible values are `enter, done, go, next, previous, search, send`. This is
helpful in tailoring the user experience to the specific input. For Contact
forms, it's usually `send`, and for search forms, it's `search`.

Checkout the full documentation for
[enterkeyhint on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint).

### autocomplete

The autocomplete attribute is my favorite one. It doesn't specify the virtual
keyboard, like the previous attributes. Instead, it tells the browser that there
are values that could be used to pre-fill the Inputs.

This is such a great feature because it makes filling Forms a way more pleasant
experience.

There are several categories with different values you can use. For the `name`
category you can use
`given-name, additional-name, family-name, nickname, honorific-prefix, honorific-suffix`
and `username`. If you don't need to break it down into different parts, you can
use `name` itself.

The same goes for `tel` and `address`. Check out the available attributes on the
[MDN documentation of `autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete).

That's it; these are three awesome attributes you can use to make your forms
more user-friendly. I made a CodePen to showcase all the attributes explained in
this post. Check it out:

<CodePen
  id="wvEGPWK"
  title="Input Attributes for better Forms"
/>


Filling Forms on website can be an unnecessary pain. Recently I've learned about some simple steps to make Forms more user friendly.

Input Attributes for better Forms


If you haven't heard of Lighthouse before, it's a tool that helps you improve
the quality of your website. It's available as a Chrome extension and as a Node
module. It's also integrated into Chrome DevTools.

It's my go-to tool for improving the performance of my websites. I test every a
website with it before I publish it, and I test it regularly after that to make
sure, I don't regress.

[Lighthouse 10](https://developer.chrome.com/en/blog/lighthouse-10-0/) was
released recently and includes some major new features.

### TTI is being removed

One of the most significant changes is that
[TTI (Time To Interactive)](https://web.dev/tti/) is being **removed**
completely. Its 10% score weight is shifting to
[CLS (Cumulative Layout Shift)](https://web.dev/cls/) which will then account
for 25% of the performance score.

Here is a comparison of the metrics that are used to calculate the performance
in Lighthouse 8 and Lighthouse 10.

<Image
  src="/images/lighthouse8-vs-lighthouse10.webp"
  alt="Lighthouse 8 vs Lighthouse 10 performance score metrics"
  caption="Lighthouse 8 vs Lighthouse 10 performance score metrics"
  width={762}
  height={1014}
/>

Google explains the removal of TTI as "being overly sensitive to outlier network
requests and long tasks." They say that other metrics are better heuristics and
tend to correlate better to the Core Web Vitals.

The shifted and increased score weight of CLS will **improve the performance the
score of about 90% of all websites**.

### Back/forward cache

Besides the removal of TTI and the increased score weight of CLS, there are two
completely new features in Lighthouse 10.

**Back/forward cache** will be added as a **new audit**. It will navigate away
from the test page, go back to it to see if it's bfcache-able.

[Bfcache](https://web.dev/bfcache/) will restore the page layout and execution
state nearly instantly, improving the user experience dramatically. However, if
the website prevents the browser from restoring a page from bfcache, the audit
will be impacted negatively and list reasons for the failure.

### Paste-preventing Inputs

Another new audit is **paste-preventing-inputs**. It will check if users can
paste into any input fields on the page. Before that, there was only a check for
password fields. Paste-preventing is a net-negative user experience and should
be avoided.

Some significant improvements to Lighthouse! They are available in the CLI tool,
right away and they will land in Chrome stable in Chrome 112.


Lighthouse 10 was released recently and included some significant new features. In this Today-I-learned Post will have a look at everything new.

What's new in Lighthouse 10


Every week or so a new hot topic gets discussed eagerly in the web development
community. This week it was about the necessity of **return types** in
TypeScript.

A few years ago, when I learned TypeScript, my colleagues taught me that return
are absolutely necessary. I thought it was a no-brainer to define them. I felt
good writing a function and then specifically add the return type.

But as you might have already guessed, I got convinced otherwise last week. To
be clear, there seems to be no absolut consensus about this topic. But I decided
that return types in TypeScript are not necessary and I won't define them
anymore. I'll tell you why.

In TypeScript there are two ways to deal with return types. You can define them
**explicitely** or you can let TypeScript **infer** them.

After listening to all the arguments about the necessity of return types, I came
to a conclusion.

For most of the code I write, I don't need return types. Because if I define
return types I just tell TypeScript what it **already knows**.

But as soon as a function I write is more complex, like containing a switch or
an if statement I will define the return type.

The videos by Matt Pocock
[Don't use return types, unless...](https://www.youtube.com/watch?v=nwSe95uFN8E)
and by Theo
[The Dangers of Return Types in JavaScript](https://www.youtube.com/watch?v=I6V2FkW1ozQ)
helped me to understand the topic better.

As I already mentioned there is no right or wrong here, it just seems to be a
preference. My preference is infer return types whenever possible, define return
types only when TypeScript can't infer them properly.


Today I learned about the discussion if return types are necessary in TypeScript or not.

Don't use return types in TypeScript


I'm a bit annoyed by YouTube Shorts on my YouTube feed page. I'm there for for long-term format videos and Shorts just are not my kind of thing. 

Rach Smith recently shared this great post on <a href="https://rachsmith.com/remove-youtube-shorts/" target="_blank" rel="noopener">how to remove shorts from your YouTube Subscription feed with `:has()` &#8599;</a> and I was so happy when I stumbled over this post.

She uses it to set `display: none` on every on every item in the feed with child elements that are shorts. 

Here are the selectors she wrote, both for the grid and the list view:
```css
/* Grid View */
#items.ytd-grid-renderer>ytd-grid-video-renderer:has(ytd-thumbnail-overlay-time-status-renderer[overlay-style="SHORTS"]) {
  display: none;
}

/* List View */
ytd-item-section-renderer:not(:has(ytd-grid-renderer)):has(ytd-thumbnail-overlay-time-status-renderer[overlay-style="SHORTS"]) {
  display: none; 
} 
```

You'd need to add that to a browser extension to apply these custom styles and then you're good to go. Bye bye Shorts!



Today I learned how you can remove YouTube Shorts from your subscription feed with CSS!

Removing YouTube Shorts with CSS


Last year I subscribed to the <a href="https://www.smashingmagazine.com/the-smashing-newsletter/" target="_blank">Smashing Magazine Newsletter &#8599; </a>, and it was a great decision. The authors share **useful front-end & UX bits** once a week, and I could always learn something from them or find something interesting. 

In a recent<a href="https://mailchi.mp/smashingmagazine.com/your-interface-design-patterns-ux-training-final-details-1134401?e=c15e5575ff" target="_blank"> edition &#8599;</a> they shared what **frustrates** users the most, but also what **delights** them the most. 

The key takeaways by the authors concerning the frustrations were that **users generally don't trust websites**. They are most frustrated by pop-ups, modals, push notifications, access to camera/microphone/photos, or install app prompts. 

The authors derive from that that many users see websites as **unfriendly** and **hostile** and therefore see a need to block everything that a website wants from them. 

That is understandable. However, a lot of website opening experiences today could be better. Often before you can even start to consume the content, you get asked to allow cookies, subscribe to the newsletter, and allow push notifications; please disable your ad blocker and better install their native app.

It's our job as people who make websites to do better and try to make them friendly and trustworthy again.

But not everything is terrible. Users are delighted by a calm, fast and accessible experience. They like it when the text and the input elements are large and when they get helpful error messages. In general, users are delighted **when they are in control** and when a website is easy to use and does what they expect it to do.

This State of Usability shows a lot of great insights. It shows what not to do if you don't want to frustrate your users and what to do to make your users happy about the experience of visiting your website.

Today I learned about the State of Usability in 2023

State of Usability in 2023


My wife is a UX designer and wanted to integrate text gradients into her
designs. I've never created something like this before and didn't know any
method to achieve this.

My wife is also pretty knowledgeable in web development (although she would
never admit that). She always makes sure that the elements she integrates into
her designs are possible to implement. She researched a bit and found a way to
do it with CSS.

This article explains in detail how it works:

<a
  href="https://cssgradient.io/blog/css-gradient-text/"
  target="_blank"
>
  CSS Gradient Text &#8599;
</a>

Here is the basic syntax for it:

```css
h2 {
  background: -webkit-linear-gradient(#eee, #333);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}
```

And here you can check it out on Codepen:

<CodePen id="YzJEJzO" />

First, we create a linear-gradient on the background of the HTML element, in
this case, an h2. Then we use the background-clip property to clip the
background to the text. Finally, the text-fill-color property is used to make
the text transparent.

Combined, this enables the linear-gradient to be visible in the text. Awesome!
That's a great and easy way to create text gradients. And the best thing is,
it's also widely supported by all modern browsers.


Today I learned how to create beautiful text gradients with CSS

CSS Gradient Text


Today I learned about the **clamp css function**. A friend with whom I'm
currently working on a project,
[the aerosol alliance website](https://aerosolalliance.com) told me about it and
suggested using it for the project.

I'd never heard about or used it before, and was happy to learn something new.
The main idea behind using the CSS clamp function is that you no longer have to
define font sizes for every project.

Instead, using clamp gives you an easier way to define **fluid typography**.

The clamp function takes three values: **a minimum value, a preferred value, and
a maximum value**. The preferred value is the value that will be used if the
viewport size is in between the minimum and maximum values.

The minimum value will be used, if the viewport size is smaller than the minimum
value. Same logic is applied for the the maximum value.

The following example shows how to use the clamp function:

```css
font-size: clamp(1rem, 2vw, 2rem);
```

There is even a [generator](https://clamp.font-size.app/) available, which we've
used recently on the project mentioned above.

I'm really happy to have learned about this function, and I'm looking forward to
using it in the future.

Read more:

- [MDN Web Docs: clamp()](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp)


Today I learned about the clamp CSS function which enables fluid typography based on the viewport size without the need for media queries

Clamp CSS function


In a recent newsletter I stumbled over the blog post by Josh Collins <a href="https://joshcollinsworth.com/blog/never-use-px-for-font-size" target="_blank">Why you should never use px to set font-size in CSS &#8599;</a>.

I've used them all so far in my web developer career, px, em and rem. In recent years it's always been rem. But I've never really grasped the idea behind using rem and avoiding px. So this time I decided to read up on it and I'm glad I did.

Josh states right at the beginning that using the wrong unit can lead to **risking overriding user's preferences, making it harder for them to use your website and potentially harming the design with unintented visual side effects**.

These are some serious issues you risk when using px and I've never thought about it that much before.

He explains in detail what px, em and rem are and shows their differences. The basic bottom line is, that em and rem scale in relation with font size, while px values will not. In other words: **em and rem work with the user's font size; px completely overrides it**.

It's one of the best articles I've read recently and I highly recommend it to anyone who's interested in understanding the differences between these units and what to use when.

Today I learned about the website TechPays which aims to remove the taboo on tech compensation in Europe

Never use px for font-size


This Today I learned post is slightly different from the others. While the previous ones were about specific technologies, tools, or specifications I learned more about while working as a software developer; this one is about a great project I'd like to present to you.

It's about a website called <a href="https://techpays.eu/" target="_blank">Tech Pays in Europe &#8599;</a>. Talking about your salary, how much you earn and how much your colleagues earn is still mysterious, especially in Germany, where I work and live.

And with mystery, I mean many people don't talk about it. And that's not a good thing because, as an employee, you need to realize what you're worth to a company and what you can demand financially. A lot of people should be paid way more than they are. But they don't know that because they don't talk about it much with others, their peers and colleagues.

This is slowly changing, and more and more people are trying to start a conversation about it. Tech Pays in Europe tries to encourage that by enabling people to add their compensation to the website anonymously.

The website already has a lot of listings by people who submitted their salaries. You can filter it by countries; you can see their exact role and sometimes even the actual company they work for.

This is a great initiative to lift the taboo on tech compensation in Europe, and I hope more and more people will add their salary to the website to help people to realize the actual value of their job.




Tech Pays in Europe


URL validation is super important because it checks if a URL follows a proper URL syntax and is not malicious.
Nowadays URL-based vulnerabilities are very common and can be used to steal user data or redirect users to malicious websites.

Server Side Request Forgery (SSRF) is the main keyword on this topic. I won't go into too much details on this here, if you want to learn more about it, I recommend reading this definition: <a href="https://owasp.org/www-community/attacks/Server_Side_Request_Forgery" target="_blank">Server Side Request Forgery &#8599; </a>.

It's basically about attackers modifiying URLs so that they can access server data.

One way to prevent this is to do proper URL validation and this article by Mannan Tirmizi teached me so much about it: <a href="https://snyk.io/blog/secure-javascript-url-validation/" target="_blank">Secure JavaScript URL validation &#8599; </a>.

They suggest to use the `new URL()`constructor because it's one of the easiest ways to validate URLs. It throws an error if the URL is invalid and you can access the URL's properties like `protocol`, `hostname`, `port` and `pathname`.

Another way to validate URLs is to use regex. Altough they advice against it, because it's not as easy to use and an error-prone approach.

The great thing about the `new URL()` constructor is that is also works in Node.js and not only in the browser. So you can use it in your backend as well.

So if you're thinking about a great way to do URL validation with JavaScript check out the article by Mannan and the `new URL()` constructor <a href="https://developer.mozilla.org/en-US/docs/Web/API/URL/URL">here &#8599; </a>.

Today I learned about a secure way to validate URLs in JavaScript

Secure JavaScript URL validation



Today I learned that there exists something like the <a href="https://worlds-highest-website.com/" target="_blank">&#8599; worlds highest website</a>.

It's exactly 18.94 kilometers high, wow! You can scroll it for ages. I'm not sure how long it takes to scroll to the bottom. 

The most interesting fact to me is, how fast you can get to the bottom by using a standard anchor tag with an id link to a div at the bottom. It happens in just a blink of an eye. 

The website consists of just one HTML container with pure CSS styling and has a height of 2840 em. What a great idea, I would have never thought of trying to build the highest website. 

It's also interesting to see that Firefox starts shrinking the main container as soon as the website gets higher than 18.939583 kilometers.

Today I learned about the worlds highest website

Worlds highest website


This post is not an actual Today I learned because I knew about this tool for
several months. Nevertheless, I want to share it with you because it's a great
tool. I use it almost weekly.

If you ever wondered what tool to use to **improve your images for better
website performance**, you should check out the
[Squoosh App](https://squoosh.app/). The web app allows you to **compress**
images in various formats.

You upload your image and choose the compression settings you want. The Squoosh
App will then compress your image, and you can download it.

It offers a lot of settings, like resizing, choosing the format, quality, etc.
You can also compare the original image with the compressed one with a neat
slider.

One of the best things about Squoosh is if you're worried about **privacy**:
Images always stay on your device since Squoosh does all the work locally.

I use it to compress all the images on my website. I use the WebP format and
resize it to drop all my images below 100kb. So if you haven't already, check
out the Squoosh App and improve your website performance. I totally recommend
it!


The Squoosh App is a web app that allows you to compress images in a variety of formats.

Squoosh App


As a frequent reader of <a href="https://www.stefanjudis.com/" target="_blank">Stefan Judis blog &#8599;</a> I often come across the stats in the bottom right of his website. It shows for example the amount of ms for the first and the largest contentful paint of his website. 

I was curious about how he gets or calculates these values. Turns out it's an npm package you can easy implement on your own website. It's called the <a href="https://www.npmjs.com/package/web-vitals-element" target="_blank">web vitals element &#8599; </a>.

It's super cool to see that on your website and it kind of encourages others too to improve their performance and showcase their efforts. 

Web Vitals Element ist a component that displays the Core Web Vitals metrics of your website.

Web Vitals Element


Today I learned about the a11y project. As you might know a11y stands for accesibility. It has 11 characters that's where the short-hand name comes from.

The a11y project is a community-driven effort to make digital accesiblity easer. They provide a ton of information on their website: <a href="https://www.a11yproject.com/" target="_blank">the a11y project &#8599; </a>.

One of the greatest things they curate is a <a href="https://www.a11yproject.com/checklist/" target="_blank">checklist &#8599;</a>, where you can check your WCAG compliance. I'm gonna use this checklist for every new web project from now on. And it's a shame that I haven't used it before. 

Other than that they provide a big list of <a href="https://www.a11yproject.com/resources/" target="_blank">resources &#8599;</a>, be it books, newsletters, podcasts, talks, different tools or communities where you can participate to digital accessiblity.

So if you want to make the web more accessible, the a11y project seems to be a fantastic starting point to learn more about the fundamentals and principles of accessiblity.

a11y stands for accessibility - the a11y project is a community-driven effort to make digital accesibility easier

The a11y project


Today I learned that in the CSS Working Group Wiki exists an<a href="https://wiki.csswg.org/ideas/mistakes" target="_blank">incomplete list of mistakes in the design of CSS &#8599; </a>. If you check out that list you will notice a lot of things you maybe already thought about, why they were designed this way and it does not seem perfect.

The thing is: as the list says in the beginning, these "mistakes" can't be changed, because they would break the whole internet.

Imagine "correcting" one of these mistakes. It would be a breaking change. Some of these design desicions are VERY old, like they exist since the origin version of CSS, which was created in 1996. 

I can't even image how many websites would be affected by such a change.
 
So the only thing that is left for us to do here is look at this list, nod your head about the fact that `box-sizing` should indeed be `border-box` by default or `top` and `bottom` `margins` should never have been allowed to collapse and go on with our lifes.


There exists a list with mistakes made in the design of CSS, that can't be corrected because it would break the internet

Incomplete list of CSS mistakes


Having the ability to set the color of a whole section is a pretty common usecase in modern websites. If you're working with React there are two ways who come across your mind, when you think about developing this feature.

### Using the most basic approach in React: props

Imagine you have a bunch of components who are styled based on the theme color. We achieve that by using one of the most basic React features: props.

```jsx
...

// The component definition
const App = ({ themeColor }) => (
  <>
    <Header color={themeColor} />
    <Main color={themeColor} />
    <Footer color={themeColor} />
  </>
)

// Setting the theme color
<App themeColor='#9D3215' />
...
```

We just set the value of our themeColor on the root level, and this value is passed down to every child component. Than it's used to style the components.

### Using React.Context
Another well known approach is to use React.Context. You first define your context and wrapp your App component in a Context Provider.

```jsx
...

const ThemeContext = React.createContext('#9D3215')

const App = () => (
  <ThemeContext.Provider value='#9D3215'>
    <Header />
    <Main />
    <Footer />
  </ThemeContext.Provider>
)
```

Now every component is able to access this theme value by using the context hook.

```jsx
...

const Header = () => {
  const theme = useContext(ThemeContext)
  return <h1 style={{ color: theme }}>Logo</h1>
}

...
```

### Without any JavaScript

But wait! This is also possible without using any JavaScript. And with just plain CSS. The basic idea is to wrap your App with a section tag for example and set the color value on the section tag in specific css class.

Now every child component can check in their stylesheet, if the specific css class is present, and if it is, it can use the color value.
This is possible by setting the color value to currentColor! 

I created a working example on <a href="https://codepen.io/Mkuehb/pen/PoRXqrW" target="_blank">CodePen &#8599;</a>, check it out and let me know what you think.

And that's it! Setting the theme color for your whole app without any JavaScript! I think that's a pretty cool alternative approach. 


It's possible to set the theme color of your application without JavaScript. It just works with plain CSS.

Setting a theme color without JavaScript


Today I learned about eary hints! Early hints are a status code (103 Early Hints). They are sent by the server to the browser to notify the browser which sub-resources are likely to be used on the page (like a CSS file from a CDN). 

The browser can then warm up connections and request these sub-resources while it is waiting for the main resource. This means the browser can do some work in advance which will speed up the whole page loads.

Here is an example to understand this better. Without early hints, the browser has to wait because everything is blocked on the server while it's determining the response for the main resource. 

With early hints, the server can immediately send a partial response and the browser can deal with that right away, while the server is determining the final response. 

> Note: if your server can send a final response, like a 200 right away, using the `link rel=preload` or `link rel=preconnect` are better solutions. But if your server needs time to generate the main response, early hints can be great!

You can learn more about early hints on the chrome developers documentation: <a href="https://developer.chrome.com/blog/early-hints/" target="_blank">faster page loads using server think-time with Early Hints &#8599;</a>.

Eary hints is a status code (103 Early Hints) that can help improve the performance of a website, because it allows the server to sent hints to the browser about critial sub-resources.

Faster page loads with early hints


JavaScript provides us a ton of useful array methods. One of them is the
`.sort()` method, which as the name says sorts an array.

This is useful, if you want to sort a list in alphabetical order for example.
What I didn't knew about the `.sort()` method was that it modifies the original
array! As the
<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort" target="_blank">mdn
docs &#8599;</a> put it:

> The sort() method sorts the elements of an array in place and **returns the
> reference to the same array**, now sorted.

What does that mean? Let's see an example. Imagine you have a component that
renders a list of items and also has a select to filter items. The select should
be sorted alphabetically, but the list of items should not be sorted.

```js
const items = [
  { name: 'Spaghetti aglia olio', kitchen: 'italian' },
  { name: 'Bami Goreng', kitchen: 'vietnamnese' },
  { name: 'Pad Thai', kitchen: 'thai' },
]

const FavoriteFood = ({ items }) => {
  const sortedItems = items.sort((a, b) => {
    if (a.kitchen < b.kitchen) return -1
    if (a.kitchen > b.kitchen) return 1
    return 0
  })

  return (
    <>
      <select>
        {sortedItems.map((item) => (
          <option key={item.name}>{item.name}</option>
        ))}
      </select>

      <section>
        {items.map((item) => (
          <article key={item.name}>
            {item.kitchen} - {item.name}
          </article>
        ))}
      </section>
    </>
  )
}
```

What do you think happens here? Our intention is, to show the list of foods
sorted alphabetically in the dropdown, but not sorted below. But that's not what
is happening here:

![a screenshot of the example app with a select and a list of items](/images/screenshot-of-food-list.webp)

As I said before, the `sort()` method modifies the original array. This means
whenever you apply the sorting on the items array, the reference is also sorted.
That's why our list of items below the dropdown is also sorted.

To fix this, there is an easy solution. Create a copy of the array you want to
sort and sort that copy.

Do ✅

```js
const FavoriteFood = ({ items }) => {
  const sortedItems = [...items].sort((a, b) => {
    if (a.kitchen < b.kitchen) return -1
    if (a.kitchen > b.kitchen) return 1
    return 0
  })

  return (
    <>
      <select>
        {sortedItems.map((item) => (
          <option key={item.name}>{item.name}</option>
        ))}
      </select>

      <section>
        {items.map((item) => (
          <article key={item.name}>
            {item.kitchen} - {item.name}
          </article>
        ))}
      </section>
    </>
  )
}
```

Here our items array is copied by using the`spread operator`. This makes sure we
only have sorted items in our select, but not in our list below. Hope this helps
you, to prevent bugs in the future!


Today I learned, that when using the JavaScript sort() function on an array, it does not return a new array, but rather modifies the original one.

Array Sort modifies the original array


Today I learned that there is a <a href="https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API" target="_blank">HTML Sanitizer API &#8599;</a>.

It takes untrusted strings of HTML and sanitizes them to enable a safe insertion
into the DOM.

This is pretty cool as sanitizing strings on the client side previously had to
be done by using a third party module or writing your own functionality for
that.

Every web developer should at least know a little bit about web-security. The
term of XSS, also known as <a href="https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting" target="_blank">cross-site scripting &#8599;</a>
is one of the most common security issues on the web.

This new Sanitizer API can deal with XSS without any extra configuration.

You just initialize a new Sanitizer object and pass it the untrusted HTML
string.

```js
const sanitizer = new Sanitizer()
const untrustedHTML = '<script>alert("XSS")</script>'
const sanitized = sanitizer.sanitizeFor('div', untrustedHTML)
```

It's important to add that this is still an experimental technology. Which means
it's not available in most modern browsern. You have to set the `experimental`
flag to `true` to use it.

But still it's great to see that standard browser APIs like this will become
available in the future.


Today I learned, that there is a new HTML Sanitizer API which makes it easy to sanitize HTML to prevent cross-site-scripting.

HTML Sanitizer API


Third-Party JavaScript is one of the number one things that slows down modern
websites. And it's often hard to improve as you are unable to change the code
itself, because you know, it's not yours, it's from a third party.

Milica shares great ways to improve the loading of third-party JS in this <a href="https://web.dev/efficiently-load-third-party-javascript/" target="_blank">article &#8599;</a>.

She specifies two ways to deal with third-party JS. The first one is: if you're
able to and it doesn't add value, get rid of it, which seems to be the obvious
one. The second one describes the optimization of the loading process.

Therefore she explains several techniques which make use of modern JS and
improve the loading process of third-party JS drastically.

I learned a lot by following along with Milica's article and could improve my
own loading process of third-party JS.


Today I learned, how to efficiently load third-party JavaScript and share it on this post

Efficiently load third-party JavaScript


If you've worked with React you've possibly done something like this to fetch
data from an API:

```js
const [data, setData] = useState(null)

useEffect(() => {
  fetch('https://pokeapi.co/api/v2/pokemon')
    .then((res) => res.json())
    .then((data) => setData(data))
}, [])
```

With the release of React 18 a lot of people were wondering if this is still a
good practice. The confusion stems from the fact that React 18 renders
everything twice in strict mode in development.

In this react thread on the react subreddit, Dan Abramov, a member of the React
core team at meta, shares a lot of valuable information on this topic:

[What is the recommended way to load data for components in React 18?](https://www.reddit.com/r/reactjs/comments/vi6q6f/what_is_the_recommended_way_to_load_data_for/)

Here are the **key takeaways** from his post:

- Running effects twice shouldn't break your code. You should always ignore
  stale responses. If it does break your code, you have race conditions to fix.
  One way to do this, is to implement a cleanup function. This article offers a
  great explanation on how to do this:
  [react docs: fetching data](https://beta.reactjs.org/learn/synchronizing-with-effects#fetching-data)

* If you can, switch to server-side data fetching. Next.js and Remix both offer
  built-in solutions to deal with that, which are better suited than client-side
  data fetching in effects. If a server-side framework isn't an option, consider
  using a client-side cache like [React Query](https://tanstack.com/query/v4/)
  to fetch data.

**A final note:** these changes have nothing to do with the release of React 18.
In fact, these issues have existing much longer. The react team just started
documenting them now. The main issue here is, that we may have all used effects
like useEffect wrong the whole time.

I've already wrote about that topic on other posts like my blog post
[the mistakes I made using React](/blog/the-mistakes-i-made-using-react/) and my
Today-I-learned post:
[missusing useEffect](/today-i-learned/missusing-use-effect/).

Now's a great time to refactor and apply the changes mentioned above.


Today I learned, about the best way to handle data fetching in React 18.

Data fetching in React 18


Writing good alt text is hard. I get it. But not having any alt text is the
worst you can do. It's still one of the most common accessibility issues on the
web.

In this [blog post](https://jakearchibald.com/2021/great-alt-text/) Jake
Archibald explains how to write great alt text.

The key take aways for great alt text are:

- the context matters
- describing the emotion is important
- not to be afraid of trying

Check out the blog post of Jake, to get better at writing alt texts. I
especially liked one sentence of him at the end:

> "[...] if you're trying to do the right thing, you're almost certainly
> improving the experience for real people."

I think that sums it up perfectly. Now go, write your alt texts!


In this post, I'll show how to write great alt text, according to Jake Archibald.

How to write great alt text


Someone on Twitter shared this
[automatic ER diagram generator](https://github.com/keonik/prisma-erd-generator)
for prisma.

At my last job we manually updated our ER diagram on every change. And now I
learn that something like this exists? Mindblown 🤯

Would have loved to have this. You can imagine how much work is involved in
updating something so crucial to your business like this manually. And all the
times you forget it or update the wrong entities. This plugin is a lifesaver!


Today I learned that there is an automatic ER diagram generator for prisma

Automatic ER diagrams


Today I learned that Reacts `useEffect` is not meant for data fetching and is
not a state setter either!

This questions all my best practices I’ve applied over the last years since we
got useEffect.

David K. Piano held this amazing talk about
[our wrong understanding of useEffect](https://www.youtube.com/watch?v=Ck-e3hd3pKw&)
and what the alternatives are. So, good bye useEffect?

His key takeaways were the following:

- the default behaviour of `useEffect` is an infinite loop
- `useEffect` is not for effects
- `useEffect` is not a lifecycle hook
- `useEffect` is not a state setter
- `useEffect` should actually be called `useSynchronize`, because it's meant to
  synchronize React with external systems


Today I learned that Reacts useEffect is not meant for data fetching and is not a state setter either!

Missusing useEffect


The web is **not accessible**. That’s not new, that’s not what I learned today.
But the amount of accessibility errors did surprise me.

The [WebAIM report](https://webaim.org/projects/million/) states over **50
million errors** in the top one million websites.

Today I learned that all of these errors are **the most basic accessibility
issue**, you can fix so easy:

- low text contrast,
- missing alternative text,
- empty links and buttons,
- missing form labels and missing languages.

Hidde wrote a fantastic blog post about it:
https://hidde.blog/common-a11y-issues/


Most common accessibility issues


In a project I worked on recently someone mentioned it would be cool to have
some **confetti** after a **form submission**. I loved this idea and after a
quick research I discovered
[canvas-confetti](https://www.npmjs.com/package/canvas-confetti).

Really cool and easy to use plugin to implement some confetti to celebrate!

If you're working with React, there is even a
[React component](https://www.npmjs.com/package/react-canvas-confetti) for this
library.

Here's a small example, where you can see it in action:
[fireworks](https://codesandbox.io/s/fireworks-fn-react-canvas-confetti-w594u?file=/src/App.js).


Confetti


As I was recently part of a team developing a RESTful API, I stumbled a lot
about the **differentiation** between POST and PUT requests. I really tried to
find clear definitions for both of these CRUD Operations.

After searching the whole Internet, my **conclusion** was:

> _"Both PUT and POST can be used for creating."_

and

> _"POST should be used to create a resource, and PUT should be used to modify
> one"_

and

> _"PUT should be used to create a resource, and POST should be used to modify
> one"_

Great.

After searching some more I found this statement: "Better is to choose between
PUT and POST based on idempotence of the action.".

Idempotence? What's that now?

**Idempotence** or an **idempotent operation** means it has no additional effect
if it is called more than once whith the same input parameters. PUT is such an
idempotent operation.

Here is an example:

If a user sends a PUT request twice because the network failed at first and
nevertheless both request manage to make it to the server, that's not a problem.

If the same happens with a POST request, that can cause some bad side effects,
like updating different parts of an object.

So updating something twice is bad and you're doing it with POST? Use PUT for
that!

Other than that I'm still not 100% sure if I've understood the distinction of
PUT and POST, but the idempotent example clears a few things up.

I keep coming back to this
[stackoverflow thread](https://stackoverflow.com/questions/630453/what-is-the-difference-between-post-and-put-in-http)
where I think there is a lot of knowledge in there.


POST vs. PUT


Today I learned about headless wordpress. Wordpress now offers a REST API which
makes it possible to decouple the frontend completely from the wordpress
backend.

This is pretty cool, because I'm faster and more comfortable with JavaScript
when developing the frontend compared to the wordpress way where you mix you're
HTML with PHP.

For example: This makes it possible for me to use GatsbyJS for the frontend and
consume the content from wordpress through the API. Gatsby offers a plugin to do
all the heavy lifting for me and enables the bridge between wordpress and
Gatsby:
[gatsby-source-wordpress](https://www.gatsbyjs.org/packages/gatsby-source-wordpress/)

Of course this brings some pros and cons with it. I researched a bit and
collected a few articles which go into detail about using wordpress as a
headless CMS.

From the gatsby documentation:
[What is Headless WordPress?](https://www.gatsbyjs.com/docs/glossary/headless-wordpress/)

From Chris Coyier on css-tricks.com:
[Just How Niche is Headless WordPress?](https://css-tricks.com/just-how-niche-is-headless-wordpress/)


Headless Wordpress


Today I learned, that passing **unencoded text** into the body of a POST request
is a bad idea. It could result in security issues and therefore always should be
encoded.

One approach to resolve this is using `URLSearchParams`. You can learn more
about the API on mdn:
[https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams)

Jake Archibald wrote a blog post about this topic, where he explains it in more
depth:
[https://jakearchibald.com/2021/encoding-data-for-post-requests](https://jakearchibald.com/2021/encoding-data-for-post-requests)


Encoding POST request body


I can't believe I'm actually writing this but CSS container queries are coming!
🥳 🎉

At some point I stopped counting the times when I was building a website layout
and came to a point where I needed to adapt an element **depending on the size
of it's container**.

This was just **impossible** to do with CSS.

The time has finally come where this will change!

[Check out the draft for it here](https://github.com/w3c/csswg-drafts/issues/5796).

It's still in a draft status but no matter what, this means css container
queries are coming and these are some exciting news!

I'm already looking forward to the time when we can use this in production!


CSS container queries


When you are using GatsbyJS there is a really useful plugin to add **git
infomation** to your pages.

The
[gatsby-transformer-gitinfo](https://www.gatsbyjs.com/plugins/gatsby-transformer-gitinfo/)
plugin enables to query for `gitLogLatest` fields like `gitLogLatestEmail`,
`gitLogLatestName` and `gitLogLatestDate`.

```graphql
{
  allMdx {
    edges {
      node {
        parent {
          ... on File {
            fields {
              gitLogLatestDate
              gitLogLatestAuthorEmail
              gitLogLatestAuthorName
            }
          }
        }
      }
    }
  }
}
```

This returns the following results:

```
{
  "data": {
    "allMdx": {
      "edges": [
        {
          "node": {
            "parent": {
              "fields": {
                "gitLogLatestDate": "2020-03-25 17:17:56 +0100",
                "gitLogLatestAuthorEmail": "marcokuehbauch@gmail.com",
                "gitLogLatestAuthorName": "Marco Kühbauch"
              }
            }
          }
        },
      ],
    },
  },
},
```

I found this particuarly useful when I wanted to add a **"Last updated on"**
feature to my blog post.

I didn't want to add the updated date **manually** to every blog post I worked
on. So using the git commit date for this is super helpful.

By adding a **"Last updated on"** feature I wanted to make sure that my content
stays **relevant** and shows the users, if it's still **usable information** or
if it's outdated.

A great sideeffect is, that it's also good for **SEO** to tell search engines,
when your content was last updated and therefore rank it better.


Improving SEO with Gatsby Gitinfo


Today I learned about the `Set` object. It lets you store **unique** values of
any type, whether primitive values or oject references.

It's like a regular object, a collection of values. But the main difference is
that a value in a `Set` may only **occur once**.

So if you have to manage unique data, `Set` objects are they right thing for
you!

Here is a quick example:

```javascript
const names = ['Sabrina', 'Tereza', 'Tom', 'Paul', 'Sabrina', 'Tom']
const nameSet = new Set(names)

console.log(nameSet) // ['Sabrina', 'Tereza', 'Tom', 'Paul']
```

If you turn any data structure into a Set, it automatically filters out the
duplicates. I find this really useful.

The same goes for when you want to add a value, which is already present in your
Set.

```javascript
const names = ['Sabrina', 'Tereza', 'Tom', 'Paul']
const nameSet = new Set(names)

nameSet.add('Sabrina')

console.log(nameSet) // ['Sabrina', 'Tereza', 'Tom', 'Paul']
```

The Set prevents that values are added, which are already part of the object.

There is a lot more cool stuff you can do with sets, check out the
[Set Object mdn page](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set).


The Set Object


While
[Suspense for Data fetching](https://reactjs.org/docs/concurrent-mode-suspense.html)
is still an experimental feature in React and is not yet available in a stable
release, React 16.6 also added a `<Suspense>` component.

This `<Suspense>` component lets you specify the loading indicator in case some
components in the tree below it are not yet ready to render.

This is a super cool and easy way to add a loading state with a loading
component to your React application.

Here is a simple example:

```javascript
import * as React from 'react'
import { LoadingComponent } from './loading-component'

const ComponentWithAsyncData = React.lazy(() =>
  import('./component-with-async-data')
)

const App = () => {
  return (
    <React.Suspense fallback={<LoadingComponent />}>
      <ComponentWithAsyncData />
    </React.Suspense>
  )
}

export default App
```

While the `<ComponentWithAsyncData />` may not be ready to render yet because
it's still waiting for an API Request, React.Suspense will handle that and show
our `<LoadingComponent />` instead.

What's even cooler, is that React can also lazy load the component with the
async data by using `React.lazy`. So it's not even imported, until it's ready.
Awesome!

You rean read more about it in the
[official React docs](https://reactjs.org/docs/react-api.html#reactsuspense).

So that's what I learned today. What about you?

Just send me an [email](mailto:marco@marcoheine.com) or message me on
[twitter](https://twitter.com/home) about your learnings. I would really like to
here from you!


React Suspense Lazy Loading Components


Today I learned that the fetch API does only reject on a Network error or when
CORS is misconfigured on the server-side. This means requests which responed
with a 4xx or a 5xx status code are also treated as successful and won't be
rejected.

There is an additional _.ok_ method on the response you can check for `true`

So the best way to check, if a fetch request is actually successful, includes
checking if the promise resolved, then checking if the `response.ok` property
holds a value of true.

Here is an example which illustrates this:

```javascript
fetch(url)
  .then((response) => {
    if (!response.ok) {
      throw new Error('Network response was not ok')
    }
    return response.json()
  })
  .then((responseJSON) => {
    // do something with the response
  })
  .catch((error) => {
    console.error('There has been a problem with your fetch operation:', error)
  })
```

To learn more about this and the Fetch API in general, check out the
[MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Response_objects)
article about using fetch.


Fetch API response.ok


Today I learned that there exists this super cool tool which can help you to
decode JSON web tokens. Check it out here: https://jwt.io/

You just copy your encoded JSON web token, paste it into the websites encoded
input section and it automatically decodes it and seperates it into header,
payload and verify signature components.

I think that's super useful and interesting to see.


Decode JSON web tokes


Today I ~~learned~~ forgot, that the JavaScript array method

```javascript
Array.prototype.pop()
```

mutates the original array. This caused me a lot of trouble and some nasty bugs.
So here is an example to help you to not make the same mistake!

Let's say we have an array of animals.

```javascript
const animals = ['dog', 'cat', 'bird', 'alpaca', 'whale']
```

Now we want to do something with the last element of the array, while also doing
something with all animals.

I tried it this way:

```javascript
const lastAnimal = animals.pop()
```

What would you expect animals and lastAnimal are referencing now? Take your time
and think about it. Don't look!

```javascript
console.log(animals) // ['dog', 'cat', 'bird', 'alpaca']
console.log(lastAnimal) // whale
```

Oh no! The `pop()` method also changed our original array animals and kicked the
last element out of it. That's not what we wanted!

A better way to do this is to copy the original array with the spread operator
and work on the copy from that on. This prevents mutating the original array.

```javascript
const colors = ['green', 'blue', 'yellow', 'pink']
const copyOfColors = [...colors] // ['green', 'blue', 'yellow', 'pink']
const lastColor = copyOfColors.pop() // 'pink'
```

So copying arrays first, when you need to work with them is always a good idea.
Hope this helps you!


JavaScript Array Mutation


If you have worked with Promises in JavaScript, you know that Promises returned
by functions must be handled appropriatly.

Unhandled Promises can cause unexpected behavior. For example they can resolve
when you don't expext it.

So the best way to deal with Promises is to return them from functions that
start them and then handle them.

To enforce this behaviour and prevent unhandled promises, you can use this
tslint rule:
[no-floating-promises](https://palantir.github.io/tslint/rules/no-floating-promises/)

I find it really helpful and it can reveal a lot of bad code and potential
non-determistic behaviour.


No floating promises


Today I learned that the `flex-gap` property is finally here! Putting space
between flex items was always annoying and now it gets super easy!

The browser support is still not the best but with landing in Chromium, the
first step is done: https://caniuse.com/?search=gap

You can read more about it here:
https://css-tricks.com/chromium-lands-flexbox-gap/


Flex-gap


At a previous job I've worked on, there were clear lines between frontend
developers and backend developers. When being in a refinement meeting backend
developers would say things like "Oh I can't estimate this user story, it's
frontend!".

I always thought this made sense. At this time I never really worked in the
backend. It seemed "scary" to me, so I was absolutely fine with this
categorization.

[This article](https://www.thoughtworks.com/insights/blog/dividing-frontend-backend-antipattern)
arguments clearly against this. Frontend became way more complex than a few
years ago and it's not only about making things look pretty anymore, the article
states. We already do the same work in the frontend and the backend.

If you think frontend and backend should be separated clearly, I definitely
recommend this article to you. Read it here:
https://www.thoughtworks.com/insights/blog/dividing-frontend-backend-antipattern


Dividing frontend from backend is an antipattern


The optional chaining operator can now be used in production! Hurray! 🥳If you
have no idea what this is, here is an example for you:

Let's say we have an object about a person.

```javascript
const person = {
  name: 'Maria',
  age: '36 years',
  dog: {
    name: 'Hugo',
  },
}
```

If we wanted to get the dog's name, we had to do this:

```javascript
const nameOfDog = person.dog.name
```

If the dogs name wasn't defined, this would throw an error 👎🏻 Not cool.

To prevent the type error, we had to do this:

```javascript
const nameOfDog = person && person.dog && person.dog.name
```

Uff wow that's a lot of **logical and** there. Image having an object nested
even deeper. Would become really long eventually.

Optional chaining operator to the resuce!

```javascript
const nameOfDog = person?.dog?.name
```

That's a lot shorter and better to read, if you ask me. It works the same as the
dot operator, but instead of throwing an error when a property is nullish, it
short-circuits with a return value of undefined.

Really helpful while exploring the content of an object, which might have some
optional properties.

You can learn more about it here:
[optional chaining](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)


Optional Chaining


Do you find yourself having a hard time estimating user stories right in your
refinement meetings?

Does it feel more like a lucky guess if this feature should be a 5 or an 8?

![](https://media.giphy.com/media/4JVTF9zR9BicshFAb7/giphy-downsized.gif)

A great way to overcome this uncertainty is to keep track of all your refined
and estimated stories and group them by estimation.

So if your wondering in your next refinement meeting if this feature is really a
13, just check your table of reference stories and see what other stories got
estimated with a 13.

If you think the amount of work this requires comes close to the stories in
there, you can gain more confidence with your estimations.


Estimating tickets according to reference stories


Stefan Judis showed in a recent tweet how to write multiline git commit
messages.

Instead of writing one very looong commit message:

```js
git commit -m 'this is a very long commit message where I describe all the work I did and guess what it is a lot and this should be just a short description'
```

You can use the `css>-m` flag multiple times. For every usage of it, a new line
is added.

```js
git commit -m 'at first I did this' -m 'I also did this' -m 'oh and dont forget that'
```

That's such a cool git feature I always needed but never knew how to do it!

Comes in really handy when you did several things in one commit and makes the
commit history much more readable. I use it all the time now!


Multiline commit messages


When I started learning NodeJS and researched a lot on this topic, I stumbled
across this video from
[Philip Roberts](https://twitter.com/philip_roberts?lang=en):

[![What the heck is the event loop anyway?](https://img.youtube.com/vi/8aGhZQkoFbQ/0.jpg)](https://www.youtube.com/watch?v=8aGhZQkoFbQ)

I already watched it years ago but did not remember everything. Especially in
the context of learning NodeJS but also when you're learning JavaScript in
general this is one of the best videos teaching a topic about the language ever.

I rewatched it and learned a ton about the **JS event loop** and **asynchronous
programming**. So good!


What the heck is the event loop anyway?


Today I learned about Deno. Deno - what is that? Another React competitor,
another JS framework which will "make everything better and easer"?

No, not really. It aims to replace Node.js. Wait a minute. What?

Yep, you've heard right. Deno is a new runtime for executing JavaScript and
TypeScript outside of the web browser. It claims that Node.js has a lot of
design mistakes and was built at a time where JavaScript was a different
language. Therefore it is not fun anymore to build something with Node.js today.

Deno aims to simplify working with JS and TS outside of the browser and makes
working with it fun again.

My knowledge of Node.js is by far to small to be able to classify that but it
sounds interesting and I will keep an eye on it.

Learn more: https://deno.land/v1


Deno


Today I learned about an article from Tom MacWright, which is, in my opinion,
one of the most important and controversial articles about web development
in 2020.

I don&apos;t want to write to much about it here, just take 10 minutes of your
time, head over there and read it. It's absolutely worth it and will make you
think.

It's title is _Second-guessing the modern web_ and Tom writes about how the idea
of building a React single-page application with server rendering has swept the
internet and how he's increasingly skeptical of it.

Learn more: https://macwright.org/2020/05/10/spa-fatigue.html


Second-guessing the modern web


Tim Kadlec did an in depth analysis of the most common JavaScript frameworks
right now and their performance.

It&apos;s totally worth the read because he analyzed a lot of data, got some
interesting insights and conclusions. His final claim is:

> What is clear: right now, if you’re using a framework to build your site,
> you’re making a trade-off in terms of initial performance—even in the best of
> scenarios.

But the article is of course not about blindly bashing the current JavaScript
framework spectrum. It is more about analyzing current problemes and showing
ways to solve them. Very important and well researched article.

Check it out here:
https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/


The cost of JavaScript frameworks


Someone once told me: a great way to learn to code is to look at other peoples
code. A great way for doing that is, of course, GitHub. But GitHub is huge and
has so much repositories, where can you start?

Enter Grep App. This website makes it possible to search all GitHub repositories
for specific code snippets. So for example if you wanted to learn more about the
useEffect hook and how other people are using it, just search for useEffect on
grep.app.

Learn more: https://grep.app/


Grep App


Sarah Drasner wrote an awesome article on how to speed up your productivity with
terminal aliases.

A former colleague teached me already a lot on this subject and I started to use
terminal aliases mostly for git commands. It really made me faster and more
productive.

If you want to get started with terminal aliases, this article is a great way to
learn more about it.

Check it out here:
https://www.netlify.com/blog/2020/04/12/speed-up-productivity-with-terminal-aliases/


Terminal Aliases


ECMAScript 2020 was released recently which a brings a lot of cool new features
into the JavaScript language.

My favourites from the new release are

- **dynamic imports**,
- **Optional Chaining**
- and the **Nullish coalescing Operator**.

Check the link at the bottom which lists all new features and has links with
explanations of them.

Learn more: https://2ality.com/2019/12/ecmascript-2020.html
