What is <dialog> element for?

In short, the dialog aims to alleviate the eternal problem of modal complexity (anyone who has been through it knows what I am talking about) and introduces a minimal API for opening and closing it while keeping everything simple and reliable. There is not much magic going on: by default, the modal is not visible, but this is caused by the default CSS (display: none), so you are free to override it if needed. Adding the open attribute (not a recommended way, but possible) does nothing special either, it just changes the display to block.

The real magic comes with the javascript methods that can be called on the HTMLDialogElement instance. There are two for opening the modal and one for closing it. The show() method just adds the open attribute, but the showModal() method is about something else.

showModal()

It renders the modal outside the HTML into a "top layer" while keeping the original HTML intact (the top layer element references the dialog element). The dialog element is also provided with a pseudo-element ::backdrop, which is given a basic styling. The dialog itself is centered and can be adjusted to the needs of the design. Also, the backdrop can be styled like any other element, and you could say that the backdrop-filter CSS property finally serves its purpose.

The modal can be closed using the javascript close() method on the element, or more clumsily, using the form inside the modal with action="dialog".

Pitfalls

However, there are some caveats to consider before you start replacing all your existing modals with dialogs. The good news is that it may satisfy all your needs. The problem is that for certain behaviors you may have to accept some workarounds and even give up some of the benefits that dialogs offer.

Top layer positioning

When displayed in modal mode (using the showModal() method), the dialog is displayed in a separate layer on top of any HTML elements. This prevents you from showing anything on top of the dialog. Do you have flash messages you want to show while the modal is open? They won't be visible. Do you have a custom cursor (typically created by positioning an element on the mouse position when moving)? You won't see it. Do you have an overlay effect or something that should cover the whole document? Or even a CSS filter applied to body or html? It won't apply to the dialog.

If you need one of these, the only way is to abandon the modal mode and implement it yourself with the non-modal dialog. This means creating your solution for background and positioning. The only advantage you are left with is the simple show/close API, but let's be honest, is it that much of an advantage over toggling a visible class? If you use some fading effects, you will probably have to deal with custom classes anyway.

Backdrop clicks

The second issue concerns the backdrop. Any reasonable modal that allows the user to close it should be able to be closed by clicking on the backdrop (among other possibilities, like clicking a close button or the Esc key). Although the dialog already implements closing with the Esc key, clicking on the backdrop is not easily achievable: There is no way to listen for events on pseudoelements. Of course, we can listen to the dialog itself and distinguish the dialog from its content.

modal.addEventListener('click', e => {
    if (e.target !== modal) return;

    modal.close();
});

However, this already forces us to have some element inside the dialog and also to remove a padding from the dialog element, because then clicking on the padded area would still open it. This may be a small problem, but considering how often this feature is used, it would be better to have it natively available.

On the other hand...

Rather than just mentioning problems, I would like to emphasize perhaps the biggest advantage of using dialog elements: It preserves the DOM structure as it is. So there can be an element with its modal placed inside, and this can do a great job of keeping the relationships between elements straightforward. With an ordinary modal, you either negotiate a good display from inside a deep element structure using some CSS hacking, or you place the modal at the top level in the HTML, torn away from its scope. Dialog is especially great for encapsulated or scoped components like in some javascript frameworks (Angular, React or Stimulus).

I would recommend going with the dialog element if you think all the possible drawbacks are unimportant. Even then, keep them in mind, because the result might be different from what you expected, and you don't want to refactor all your modals just to find out that some things don't work for you.

Becoming a Copilot Convert

I've been using Github Copilot for over a year now - since March 2022, to be exact. At first, I was wary of it and didn't use it very effectively, but over time it has become an integral part of my workflow. In that time, I've found that, when used correctly, Copilot can be an incredible time saver and unleash creative thinking. I can still code without Copilot, but I find it an immense waste of time. It's like driving through an unfamiliar city without navigation. Sure, you can rely on the signs and street names. But you may have to stop now and then and look up the route on your paper map before you can continue your journey. And there is (most likely) no way back for me. I got used to Copilot the same way I got used to Waze.

The First 'Tragic' Date

A programmer friend of mine has yet to use Copilot, despite my persistent recommendations. He recently wrote me to say that he had finally installed it on a trial basis, but described the result as "tragic". I was not that surprised: Copilot doesn't have to be love at first sight (it took me about a month to learn how to use it so that we didn't get on each other's nerves).

For many people, getting started with Copilot can be difficult. Some may be bothered by the frequent suggestions, others by the error-prone nature of the resulting code, or by a certain unpredictability. It is also important not to expect miracles from Copilot right away, as these will appear after a while of use. Copilot is a tool like any other, and as such it is good to know exactly what it can and cannot be used for.

For this purpose, I have written down some of the most common use cases that I encounter daily and that make the most of Copilot's power.

For the sake of simplicity, I will write most of the following snippets in Javascript.

Imitation

A natural feature of AI models is the ability to mimic faithfully, and therein lies the power of Copilot. If we provide it with an understandable blueprint, we can get it to mimic it any way we want.

Let's imagine that we have an array of animals and one of the animals selected (currentAnimal - it can be different each time).

const animals = ['badger', 'otter', 'bear', 'racoon'];

let currentAnimal = 'bear';

Now we will write a moveRight() function that will be called every time the right arrow is clicked. If there is no element left, we will start with the first one:

function moveRight() {
    let index = animals.indexOf(currentAnimal) + 1;

    if (index > animals.length - 1) {
        index = 0;
    }

    currentAnimal = animals[index];
}

It probably won't even be necessary to write the function declaration for Copilot to understand what's going on: I just added two newlines after the closing brace of the moveRight() function, and Copilot already suggests the following:

function moveLeft() {

This is probably not a big surprise. But if I accept, Copilot will propose the whole function body:

function moveLeft() {
    let index = animals.indexOf(currentAnimal) - 1;

    if (index < 0) {
        index = animals.length - 1;
    }

    currentAnimal = animals[index];
}

Ok, so what is the big deal here? Let's break down what has Copilot done.

1. Pair completion: Copilot tends toward completeness. If I have something that describes one half of the problem, it likes to suggest the other half. This can be annoying in the rare case that it wasn't my goal, but very useful when I simply forget to finish it and am about to start writing some other code. In that case, this serves as a friendly reminder that I might be about to accidentally leave out an important part of the desired result.

2. Maintaining code consistency: This function can be written in many ways, many of which are probably even better than our solution. Copilot doesn't try to outsmart us and respects our code style.

3. Identification of the divergence: These two functions are similar, but there are some key differences. Copilot is very good at deciding what is similar and what is different about these functions. It correctly reverses the endless circle logic for the opposite direction.

On the other hand, you should not expect Copilot to fix your bad code if not asked to. For example, if I had written the first function like this:

function moveRight() {
    let index = animals.indexOf(currentAnimal);

    if (index >= animals.length - 1) {
        index = 0;
    }

    currentAnimal = animals[index + 1];
}

it would have given me the following moveLeft() without hesitation:

function moveLeft() {
    let index = animals.indexOf(currentAnimal);

    if (index <= 0) {
        index = animals.length - 1;
    }

    currentAnimal = animals[index - 1];
}

What is the problem here? It may not be clear at first, but if you go right from the last one back to the first one, the first one is skipped. Likewise, if you go back to the last one from the first one to the left, it will also skip it.

Don't blame Copilot for your own mistakes. If you are not sure about your code, you can always ask Copilot to refactor it.

Refactoring

I don't use Copilot to refactor my code very often, relying instead on my intuition and experience. However, in some cases, you might find it very useful. Nevertheless, you should always be suspicious of any code that Copilot generates, and double-check that it meets your expectations. Be critical and optionally ask it to improve until you are satisfied with the result.

You shouldn't just accept Copilot's output as is; always explore its essence to empower your future coding

Let's rewrite the moveRight() function first. Start by writing a comment with the request.

// rewrite moveRight better

It offers us this simple solution

// rewrite moveRight better
function moveRight() {
    let index = animals.indexOf(currentAnimal);

    index = (index + 1) % animals.length;

    currentAnimal = animals[index];
}

However, we might want to have the function as a one-liner. So we will specify it:

// rewrite moveRight better as a one-liner
function moveRight() {
    currentAnimal = animals[(animals.indexOf(currentAnimal) + 1) % animals.length];
}

This seems fine, but it is starting to look pretty unreadable. It is our job to keep things simple, so we should decide which solution to choose.

A good example of why we shouldn't always rely on Copilot uncritically is this:

// rewrite moveRight better, but without using indexOf

Let's not be mistaken, this is completely possible. But the result does not reflect that:

// rewrite moveRight better, but without using indexOf
function moveRight() {
    let index = animals.indexOf(currentAnimal);

    if (index >= animals.length - 1) {
        index = 0;
    }

    currentAnimal = animals[index + 1];
}

This proves that you need to know, at least approximately, what you are doing when you use Copilot. Let's fix the "prompt":

// rewrite moveRight better, but without using indexOf and using a loop

The funny thing is (and this happens to me quite often) that when Copilot has to enter unknown territory, it tries to show some resistance, similar to a person who is forced to jump into unknown water. When I wrote the first comment and pressed Enter, it did not give me a function but added a similar comment for moveLeft and then started repeating it indefinitely.

// rewrite moveRight better, but without using indexOf but using a loop
// rewrite moveLeft better, but without using indexOf but using a loop
// rewrite moveRight better, but without using indexOf but using a loop
// rewrite moveLeft better, but without using indexOf but using a loop
// rewrite moveRight better, but without using indexOf but using a loop
// rewrite moveLeft better, but without using indexOf but using a loop

So I had to force the desired result by writing function just below my initial comment. Here it had no turning point, so it finally committed itself to this task.

// rewrite moveRight better, but without using indexOf but using a loop
function moveRight() {
    let index = 0;

    for (let i = 0; i < animals.length; i++) {
        if (animals[i] === currentAnimal) {
            index = i;
        }
    }

    if (index >= animals.length - 1) {
        index = 0;
    }

    currentAnimal = animals[index + 1];
}

Is this solution the best? If you don't know, don't rely on Copilot to know any better.

I was more interested in the graphic design of web pages, which was booming at the time, and felt that knowledge of programming was more of a necessity if I wanted to apply my graphic designs.

Strange as it may seem today, at that time a significant proportion of websites were still laid out using HTML tables, the absolute minimum of websites had a responsive display and it was not uncommon to use inline styles.

At least that's how it seemed to me.

The thing is, it's not hard to learn the basics of any language these days. There are plenty of online courses, boot camps, YouTube tutorials and Q&A sites. The roads are trodden and paved.

Back then, it was much harder for a complete beginner like me to learn all the "best practices" and adapt to new trends as they emerged.

At the time, I was unfamiliar with module bundlers and javascript frameworks and usually worked with a single CSS file whose structure was determined only by clumsily written comments.

So it was almost a revelation when I discovered CSS preprocessors. I dabbled with Less for a while but quickly settled on the best of the holy trinity: Stylus.

Discovering Stylus

I've been using Stylus since 2014 for over seven years and have always been dismissive about any other CSS preprocessor.

Stylus was simply the best. Not only did it allow the nesting of selectors and the use of mixins. It radically stripped down CSS syntax to the bare minimum. It removed semicolons, compound brackets, and even colons, and replaced them with indentations and spaces.

It allowed the programmer to think spatially, in the context of the DOM. While chaining class names is hell in pure CSS, in Stylus it's all about structured and logical code. I was also able to write the style first and then write the HTML for it.

For example, when styling a contact box, I can write simply:

.contact
    &-box
        &-heading
            font-size 1.5rem

            &:hover
                color midnightBlue

        &-info
            font-size 1.1rem

Which already defines the HTML structure. The same properties written in pure CSS would be flatter and less understandable.

.contact-box-heading {
    font-size: 1.5rem;
}

.contact-box-heading:hover {
    color: midnightBlue;
}

.contact-box-info {
    font-size: 1.1rem;
}

Of course, other CSS preprocessors had this kind of superpower. The winning difference was that Stylus got rid of all the annoying nonsense that stifled creativity and flow such as curly braces, dollar signs, colons, and semicolons. Even variables didn't need to be denoted by special characters - they were just simple words.

But you could still use them. Another advantage of Stylus was that you could put pure CSS into Stylus code and it would still work.

Soon I also started using stylus packages that allowed me to create layouts on a professional level: among others, mainly the jeet package for grid and columns (this was before grid and flex were supported in most browsers) and rupture to make breakpoints handling much easier.

The best thing is that I wasn't forced to use some pre-baked solutions and I built everything from scratch.

I have worked with Stylus on more than 30 projects, some of which have been very large, with more than 200 individual .styl files. Stylus has proven to be robust and scalable, easy to use with or without a module bundler, time-saving and highly rewarding.

Farewell

By 2020, problems began to emerge. The first was that compilation errors became more and more common. This was mainly caused by misplaced whitespaces or bad indentation. The problem was that the IDE's formatting and linting plugins were out of date and didn't recognize some syntactical features. Also, the hinting was often broken or did not include some of the newer CSS properties.

Sometimes Stylus was impossible to use because the helper plugins were driving me crazy. It is also important to note that Stylus has never seen a major release: at the time of writing, the latest version is 0.59.0. Also, the project was poorly maintained and Stylus wasn't even that popular anymore: according to The State of CSS of 2021, only about 15% of all developers used Stylus and satisfaction reached only 35%. In comparison, Sass was the preprocessor of choice for 70% of developers and enjoyed 84% satisfaction.

I ran out of patience when I set up a new project in Angular and found out that Stylus is no longer offered for writing styles. It was still possible to set it up for use in the application at the time, but the Angular team had clearly stated that it would not be supported in the future (only 0.3% of all users were using it).

I choose you, Sass!

I had to make a difficult decision to move from Stylus to another preprocessor. I chose Sass for a number of reasons.

Firstly, as I mentioned, it is the most popular of them all. I'd always been put off by its ugly sibling, SCSS, and I had no idea what the difference was.

But SASS is great. It is very similar to Stylus, except for the use of colons and syntax strictness. It has some of the same drawbacks as Stylus, such as delayed support for new CSS features. However, it wasn't hard at all to migrate most of the custom mixins to Sass.

The IDE plugins are well-maintained and the community is huge. I'm confident I won't be forced to switch to anything else for years to come.

What do I miss

There are still a couple of features that I really liked in Stylus that I would like to see implemented in SASS.

Hashes

The most painful are the hash objects. In Stylus it was a piece of cake:

/** Stylus **/

foo = {
  bar: hi,
  baz: hey
}

foo.baz
// => hey

foo[baz]
// => hey

foo['baz']
// => hey

Not so in Sass. It has maps that are limited compared to Stylus hashes.

$foo: ("bar": "hi", "baz": "hey")

map.get($foo, "baz")

// => hey

Worst of all, Sass requires maps to be written on a single line. I got used to creating hashes for colors with both light and dark mode variants, and that was no longer possible with Sass. Ultimately, I ended up putting the multi-line map in a .scss file and importing it into a .sass file.

Imports and files structure

I like being able to import my styles into a single file since I use Webpack as a module bundler for most of my projects. When I was using Stylus, I was used to a certain directory structure that I couldn't reproduce with Sass:

There were some main directories (base, layout, partials etc.) containing subdirectories named after the function or purpose.

├── styles
│   ├── base
│   │   ├── color
│   │   ├── reset
│   │   └── typography
│   │
│   ├── layout
│   │   ├── body
│   │   ├── footer
│   │   └── navbar
│   │
│   ├── partials
│   │   ├── container
│   │   ├── flash
│   │   └── form
│   │       ├── checkbox
│   │       └── input
.   .
.   .
.   .

Each subdirectory contained another subdirectory or an index.styl file. All I had to do was to import all the files in the main directories using a wildcard. This represents a pattern called screaming architecture, where the names of the folders represent the function of the files in them.

/** Stylus **/

@import "./base/**/index.styl"
@import "./layout/**/index.styl"
@import "./partials/**/index.styl"

No explicit import was required. Unfortunately, this is only partially possible in Sass, so now I have to explicitly import each file I create. I prefer to keep my styles separate and organized. People who do not separate their Sass files into specific directories are beyond my comprehension although I know that many are quite happy about it.

I had to adapt another way of storing stylesheets that is ultimately very similar to the original, with an extra step of manually importing each newly added file.

├── styles
│   ├── base
│   │   ├── _color.sass
│   │   ├── _reset.sass
│   │   ├── _typography.sass
│   │   └── all.sass
│   │
│   ├── layout
│   │   ├── _body.sass
│   │   ├── _footer.sass
│   │   ├── _navbar.sass
│   │   └── all.sass
│   │
│   ├── partials
│   │   ├── _container.sass
│   │   ├── _flash.sass
│   │   └── form
│   │   │   ├── _checkbox.sass
│   │   │   └── _input.sass
│   │   │
.   .   └── all.sass
.   .

@import 'base/all'
@import 'layout/all'
@import 'partials/all'

Operators and built-in functions

Compared to Stylus, Sass has fewer built-in functions and mathematical operations. Also, interpolation is more cumbersome in Sass, and all the at-rules are less straightforward. But that may just be a matter of habit.

Noteworthy are the loops: Sass has @each and @for. I kind of hate it. The stylus for is much more versatile.

/** Sass **/

$colors: "red", "green", "blue";

@each $color in $colors
    .#{$color}
        color: $color


/** Stylus **/

color = ( red green blue )

for color in colors
    .{color}
        color: color

As for the range:

/** Sass **/

@for $i from 1 through 3 
  .branch:nth-child(3n + #{$i})
    margin-left: #{$i * 10}px

/** Stylus **/ 

for i in (1..3)
    .branch:nth-child(3n + {i})
        margin-left: {i * 10}px

Other than that, I think the sass is great and I have gotten completely used to it by now.