Patrick Brosset

Le mystère des marges CSS

2005-12-13T00:00:00Z

Eric Meyer, figure du CSS, sur son site complexspiral reprend tous les détails techniques du comportement des marges en CSS. Sujet souvent obscur qui après cet article devient limpide!

À lire absolument pour tous ceux qui ne comprennent pas pourquoi les marges disparaissent subitement...

Bon, puis il va falloir que je commence à poster d'autres choses que des liens hein... merde c'est un blog quoi...

MyDBO, Generateur de code PHP

2005-12-13T00:00:00Z

MyDBO est pour tous les développeurs PHP/MySQL qui en ont marre de faire et refaire les mêmes fonctions ajout/édition/liste/... sur leurs bases de données pour chaque nouveau site ou application web.

Cette application a été créée en PHP, est gratuite, et s'installe très facilement.

Une fois installée et le wizard lancé, vos tables MySQL seront analysées et un code complet orienté objet sera généré pour vous!

Une fois ce code sous la main, les opérations typiques de gestion de base de données deviennent beaucoup plus faciles et rapides, et surtout, on peut aborder son projet d'un point de vue business et non par requêtes SQL.

De plus, car ce n'est pas tout, MyDBO est basé sur des templates (modèles), ce qui veut dire que l'on peut créer autant de modèles que l'on veut et les rendre adaptés à ce dont on a besoin de faire.

Avec MyDBO est aussi inclus un plug-in qui génère une section d'administration complète. Pour ceux qui recherchent un moyen rapide de lister, ajouter, éditer ou effacer des entrées de tables MySQL, MyDBO est pour vous.

Faire des photos macro avec une boite de Pringles

2005-12-13T00:00:00Z

Toujours voulu faire des photos macros? Jamais eu l'argent pour acheter l'objectif?

Cette entrée blog donne une recette DIY (do it yourself) economo-pringlo-dangereuse-mais-bien-coolos pour arriver à de superbes resultats. L'idée est bien trouvée en tout cas! A voir!

La photo ci-dessus donne une idee du résultat obtenu avec un simple objectif bas de gamme Canon, une boite de pringles vide et du bricolage.

Handling large files while avoiding memory shortages in PHP

2005-12-22T00:00:00Z

I've recently had to create a generic text data file uploader in PHP (namely to import tab-delimited fields into a database). After experiencing a few problems related to memory issues, I came up with a solution that might be of interest to some people. Here it is.

The idea is to parse the file chunk by chunk. For example, let's say I have a 10 000 lines file that I'd like to parse. For each file I'm calling some database-related functions or so. As a result, each line can take quite some time to be processed and the whole loop can eventualy fail to finish due to limited memory or timeout.

So, what I do is I create a set of delimiters: m and n, m will be the line number to start from and n the maximum number of lines to read.

For example, if n=500 the first run would read from line m=0 to line m+n = 0+500. Now 500 lines should be quite easy for PHP to parse even though each line needs quite a lot of processing.

Great, we've got our first 500 lines done, how do we process the rest now? Well, that's the main idea here, we need PHP to free its memory and reset its timeout, so what we do is simply reloading the page!! header("Refresh: myscript.php?new_m_value=500&new_n_value=500");

Just call the same script again with different m and n values and you're on! Of course, we'll need some variables to be carried accross, for that we have PHP sessions. Now, enough text, let's see a little example of how I use this method:

// Number of lines to parse in this run
$maxline = $_GET['max'] ? $_GET['max'] : 500;
// Offset line to start parsing from
$startline = $_GET['start'] ? $_GET['start'] : 1;
// Number of already parsed lines
$parsedlines = $_GET['aparsed'] ? $_GET['aparsed'] : 0;

// Is the parsing finished ?
$parsingdone = false;

// PHP session to pass variables from step to step
session_start();
if(!$_SESSION['dataFileReader'])
{
    $_SESSION['dataFileReader'] = $_POST;    // This is a bit brutal, but it's an example. just carry any variable you need ...
}

// File to work on
$temp_filename = $_SESSION['dataFileReader']['tempFileName'];

if(is_file($temp_filename))
{

    // Opening the data file
    if($handleReader = fopen($temp_filename, "r"))
    {
        // Counting the rows
        $count = 0;
        $parsed_count = 0;

        // Reading the file line by line with fgets function
        while(!feof($handleReader))
        {
            $buffer = fgets($handleReader, 4096);    // Reading one line
            $line = explode("\t", $buffer);        // Line is tab-delimited

            $count ++;
           
            // This is where I know which chunk of lines to process
            // This can be seen pretty much like the SQL clause: LIMIT m,n
            if(($count >= $startline) && ($count < $maxline + $startline))
            {
                foreach($line as $k=>$field)
                {
                     /* DO SOMETHING WITH THE FIELDS HERE */
                }

                $parsed_count ++;
           }
        }

        // Closing the file
        fclose($handleReader);
        
        // Here, we redirect or end the process
        if($parsed_count != 0)
        {
            // Redirecting to process the next part of the file
            header("Refresh: 1; script.php?start=".($startline+$maxline)."&max=".$maxline."&aparsed=".($parsedlines + $parsed_count));
        }
        else
        {
            // the parsing is done
            $parsingdone = true;
        }

        // Displaying number of lines parsed
        if(!$parsingdone)    echo ($parsedlines + $parsed_count)." lines parsed so far ... continuing ...";

        if($parsingdone)
        {
            // End message
            echo "Data file parsed (".($parsedlines + $parsed_count)." lines)!";

            // killing the session
            $_SESSION['dataFileReader'] = array();
            session_destroy();
        }

    }
    else
    {
        echo "ERROR: Couldn't open the data file - Nothing was uploaded";
    }

}
else
{
    echo "ERROR: Couldn't find the temporary data file - Nothing was uploaded";
}

DevTools for creative people

2015-02-12T00:00:00Z

Browser DevTools are pretty complex. There are reasons for this though, they're not just complex to annoy people.

They contain within one tiny UI (often docked in the browser) various tools, often having very little in common with each other. All of these tools are needed, but having all of them together at all times in one application makes for a complex UI to grasp.
These tools are sometimes very low level. They need to be low level, users need to understand how things work or, most often, why they don't, and that means explaining how it was interpreted by the browser, at the lower level.

Add to this the number of new APIs and libs that appear constantly in the web platform, it's easy for devtools to become more and more bloated and harder to use for creative people, people that are perhaps used to a more visual set of tools.

Modifying a page's structure and style in devtools right now requires knowledge of HTML and CSS. This may sound obvious, but I'm convinced this could be made a lot simpler, or let's say more visual than having to write code. Why would you want to write a color hex code when you can pick it from a color wheel or an existing palette? Why would you tweak an element's position pixel by pixel when you can grab and move the element instead, and have it snap to a grid?

Bridging the gap

I think there's work to do if we want to make the devtools be more accessible for everybody, and in particular be more efficient for creative people.

Here are examples of features I think would help, some of them are already present.

Animations

An animation panel where you can play, pause, loop, seek or slow-down animations and tweak each keyframe's properties makes adjusting animations in the browser a lot simpler and more natural.

In time, I think a flash-like timeline to author animations from scratch is inevitable.

Below is the animation inspector in Firefox 37:

Similarly, editing animation timing functions (the rate at which the object moves during the animation duration) feels a lot more natural when you can change the cubic-bezier curve and have visual feedback rather than having to write numbers in a matrix.

https://www.youtube.com/watch?v=LemdYmcRrb0

Transforms

transform is one of the most often animated CSS property, and that's because it offers a lot of flexibility to move, reshape or resize an element in a very high performance way. But writing a transform function is often hard and again, much better solved visually.

Since Firefox 33, you can visualize the effect of a transform in the page:

https://www.youtube.com/watch?v=OC3ZNbnDHt0

Being able to visualize how a given transform function affects an element comparing its original and transformed shape and position is a step in the right direction, but ultimately, being able to transform elements by freely distorting them in the page is what devtools should aim for.

Colors

This is one of the more obvious examples, but it's still worth noting how much better if feels to be able to tweak colors on a web page by choosing from a wheel or picking from the page rather than remembering color names or trying to guess the hex code.

Images

Right now browser devtools don't offer much when it comes to image assets management on a site. However positioning sprite backgrounds or assembling multiple css background images are not always easy problems and they are typically better solved visually than by going through code. I think devtools should be helping more here.

Layout

This seems to me like it's the area that lacks devtools support the most.

Some people use CSS floats for their layouts, but I don't see any tool that helps with understanding the notions of block formatting context or how to clear floats. It seems like it would be useful to at least have a mode that highlights contexts, floated and clearing elements, to at least visualize the global structure of the layout.

Some sites start to make use of flexbox, which is awesome, but flexbox isn't totally straightforward. Here again, devtools could help represent the structure of the layout in the page and allow modifications to be made visually (if that sounds like something you could help implement in FirefoxDevTools then check out this bug).

What about z-index? Here again there are some technical details that make the concept not always so easy to grasp, and it's easy to fall into common traps.

Seeing your page in 3D, with elements ordered by z-index, can definitely help sometimes. But what about a mode where you'd clearly see the stacking context elements and the various z-indices marked?

Finally, layout is all about sizes, grids and aligning things.

So the least the devtools can do to help is provide tools to verify that things are aligned correctly. Drawing guides around elements that match a given selector is one way. Adding rulers and guides is another nice option (check out this bug).

Element size and position

The last topic I'd like to touch on is positioning. Obviously if you're not going to position anything in the page and rely on the default flow, then you're not too likely to need any special help from your favorite devtools, but as soon as you start absolutely positioning elements, or using fixed or even sticky positioning, then some visual tools would be nice.

Work-in-progress in Firefox 38: the element geometry editor:

https://www.youtube.com/watch?v=zsNhGllr2-g

What if the devtools provided a way to fine tune the position or size of an element by moving or resizing it in the page? Wouldn't that make more sense? Obviously there are lot's of cases where typing a number is going to be more efficient than moving something with the mouse, but I'm convinced the opposite is also true. Ever tried to resize an element to the size of its background image? Ever tried to find the perfect position for a logo?

In conclusion, I'd say I'm pretty hopeful with the direction the various browser devtools are heading right now and I'm certain we can bridge the gaps in many places to help creative people get more out of their experiences using their browsers as a creative tool.

After all, if the content is going to be consumed in the browser in the end, why not create it there in the first place?

But there's still a lot of ground to cover so, get involved, submit your ideas, or start hacking!

Breaking-down CSS animation demos with Firefox DevTools

2015-02-13T00:00:00Z

I have recently started this series of videos with the idea of showing how various features of the FirefoxDevTools could be used to break-down and understand how seemingly complex CSS animations were done.

Multiple box-shadows and animated ::before and ::after pseudo-elements:

https://www.youtube.com/watch?v=eYYTKEIS6zw

Preview transforms, and highlight selectors:

https://www.youtube.com/watch?v=lyQINNjv-Fo

Work with iframes and pause animations:

https://www.youtube.com/watch?v=pfIrK_2nRRc

That’s it for now. More to come.

Follow my channel on YouTube!

DevTools for designers, again!

2015-02-25T00:00:00Z

I wrote a couple of weeks ago about how browser devtools should be thinking about addressing the needs of designers and it looks like that post was right on time!

Indeed, it seems that the ChromeDevTools team is starting to invest in this area more and more. This is brilliant!

And on this trello page the ChromeDevTools team is looking for people to submit and comment on ideas on this area.

Here are some screenshots from that page:

Knowing that on the Firefox side, we’ve set ourselves goals to ship creative tools this year too, designers who work for the web should be in a better place really soon!

Understanding the CSS box model for inline elements

2015-03-24T00:00:00Z

Read the full article at https://hacks.mozilla.org/2015/03/understanding-inline-box-model/

Do you really understand CSS linear-gradients?

2015-03-27T00:00:00Z

Want a nice gradient background on your site?

background-image: linear-gradient(red, blue);

BOOM, done!

Ok, it’s a little boring. So if you want more, I recommend this css-tricks article and MDN page.

Still here? Alright, let’s go and have a look at some of the details of how linear-gradients actually work.

First of all, let’s remind ourselves of the syntax allowed in the linear-gradient function:

linear-gradient([<angle> | to <side-or-corner>]? , <color-stop-list>)

The function accepts an optional first argument which determines the angle of the gradient, which can be expressed either as an angle with a unit (deg, rad, grad, turn) or as a side-or-corner keyword.

The function then accepts a list of color stops.

The gradient box

A gradient image has not dimensions, it is infinite, unlike traditional background images. What gives a visible dimension to the gradient is its gradient box i.e. the area where it is displayed.

Typically, when you apply a linear-gradient background-image to a DOM element, that area is the border-box of the element (which is the same area a background-color would be displayed, or where an image identified by a URL would).

However, if you also use the CSS property background-size and set it to, say, 200px * 200px, then the gradient box will have this size and will be positioned at the top left corner of the DOM element by default, unless you also set background-position.

So, just remember when reading through the next sections that the gradient box isn’t always positioned and sized like the DOM element the gradient applies to.

The gradient line

In the gradient box, the line that passes through the center and along which color stops are distributed is called the gradient line. This line is more easily explained when talking about the gradient angle, so more about this in the next section.

The gradient angle

Quite obviously, the angle of a linear-gradient is used to determine in which direction is the gradient going. But let’s go into more details.

If C is the center point of the gradient box, then A is the angle between the vertical line that passes through C, and the gradient line that also passes through C and along which the gradient color stops are distributed.

You can define this angle in 2 ways:

by using one of the keywords: to top, to bottom, to left, to right, to top right, to top left, to bottom right, to bottom left,
or by defining the angle with a number and a unit, e.g. 45deg, 1turn, …

If the angle is omitted, it defaults to to bottom (which is 180deg or 0.5turn):

In this picture and the following ones, the gradient box is the bordered rectangle, and the gradient line is the thick grey line that passes in the center and has the color stops displayed along.

In the example above, the angle is missing, so the white-to-red gradient goes from top to bottom, which is the same as using the to bottom keyword, as shown below.

And, as shown in the following 2 pictures, to top is equivalent to an angle of zero degrees:

Another important point when using angle keywords is that to top right for example (or any of the other corner keywords) depend on the dimensions of the gradient box.

The logic is that if you wanted a red to blue gradient towards the top right corner of an element, then that element should be exactly blue at the top right corner, and the violet color in the middle of the gradient should form around a line that passes through the top left and bottom right corners.

Let’s look at this with a picture:

So, to top right doesn’t mean that the gradient line passes through the top-right corner and it doesn’t mean that the gradient angle is 45 degrees either!

Let’s look at how the gradient line moves when the angle changes in the following animation:

In this animation, the angle is incremented from 0 to 360 degrees, by steps of 10 degrees. The low-resolution of the GIF even allows to better see how the various colors are displayed as “lines” always perpendicular to the gradient-line.

Let’s recap on gradient angles:

The angle is measured between the gradient line and a line that starts at the center of the gradient box and extends towards the top.
0 degrees therefore means to top.
The default value for an angle, when missing, is to bottom, which is the same than 180 degrees.
Corner keywords depend on the gradient box dimensions.

The gradient line length

Before we can take a look at how color stops are distributed along the gradient line we need to explain one thing.

You may have noticed in the previous animation that the colors stops are sometimes positioned outside of the gradient box, which may sound weird at first but is logical once you know the reason.

Consider this example:

We want a gradient from red to blue, at 45 degrees and because of the aspect ratio of the gradient box, the gradient line cannot pass through the top right corner.

But what the browser wants to do here (well, what the specification tells it to do) is make the top right corner exactly blue.

If we had made the gradient line only start and end at the edges of the box, then the color blue would have covered a greater area of the box, and the gradient wouldn’t have been spread out as much.

Therefore, in order to do this, the gradient line sometimes has to extend out of the gradient box.

It’s easy to know where it starts and ends though. Just draw a line that passes through the nearest corner and that is perpendicular to the gradient line. The point where that line crosses the gradient line is the start/end position (this is explained quite nicely in the specification).

In fact, if you let W be the width of the gradient box, H its height, and A the gradient angle, then the length of the gradient line is:

abs(W * sin(A)) + abs(H * cos(A))

Color stops

Color stops are organized in a coma-separated list where each item can be defined as:

<color> [<percentage> | <length>]?

It is therefore not mandatory to specify where the color should be placed on the gradient line. For instance, this is ok:

None of the color stops have positions, so the browser determine positions for them.

In the simplest case, with just 2 colors, color 1 would be placed at 0% (the start of the gradient line), and color 2 at 100% (the end of the gradient line).

Then if you add a third color, you’d have color 1 still at 0%, color 2 at 50% and color 3 at 100%, and so on.

In the example above, 5 color stops have been defined, and the browser has calculated their respective positions as 0%, 25%, 50%, 75%, 100%. The reason it does this is to distribute the colors evenly along the gradient box.

Now, of course, stops can have custom positions. A position can be expressed either with a percentage (relative to the size of the gradient line), or a CSS length (where any CSS unit works).

Consider this example:

As you can see, each of the 5 color stops have positions, in pixels. These positions are calculated from the start of the gradient line.

Using these positions, you can come up with all sorts of nice effects. One thing you can do for instance is use a gradient to not draw a gradient at all, but have multiple colors:

In the above picture, there are 7 stops, and they are organized in a way that the next color starts exactly at the same position as the last one which means that the browser doesn’t have to fill the space between 2 stops with a gradient of colors.

But of course this is all nice and fun, but what happens if you mix positioned stops with un-positioned stops? Then you make the browser work some more and ask it to distribute the stops for which you omitted a position automatically:

In the simple example above, the 2nd stop (orange) has no position, and so the browser makes up for it and finds the right place between the previous positioned stop and next positioned stop. Here it’s very easy because the immediate neighbors of the 2nd stop have positions, but it gets more complex if only a few stops have positions, or if there are no previous or next positioned stops.

Let’s take a look at a few examples:

Above, only the 3rd stop (yellow) is positioned at 30%. So to nicely distribute the rest, it puts the first one at 0%, the last at 100%, and distribute the stops in between at mid-positions (so the orange ends up right between 0% and 30%, and the red ends up between 30% and 100%).

Above, the first and last stops are positioned, so the rest is distributed evenly in between those two.

Of course it would be too easy if 0% and 100% was a hard range you couldn’t go out of. But as seen in the previous example, the last stop is positioned at 120%, and so all other stops have to be distributed according to this position (the default start position remains 0% in this case).

And if you want to make your browser work even more, why not specify out of order positions?

Indeed, color stops are expected to be ordered, but nothing prevents you from not doing it, and nothing horrible is going to happen if you don’t. Your browser is simply going to correct you, as seen below:

Let’s start from the first stop (red), positioned at 30% which is fine, then the second stop is positioned at 10%, which is wrong because, as said above, stops are supposed to be given in increasing positions. So here the browser corrects the second stop position and sets it to the same position as the preceding positioned stop (30%). Then comes the 3rd stop (yellow), at 60%, which is fine, but it is followed by the 4th stop (blue) at 40%. So there again the position is corrected and set as the one of the preceding positioned stop.

Finally, in the above example, the last stop (blue) is incorrectly positioned and so the browser sets its position to be the same as the preceding positioned stop, which in this case is not its immediate neighbor (yellow), nor the stop before that (orange), so it has to go all the way back to the 1st stop (red). Therefore, all stops between red and blue are also given the position 30% and are therefore not visible.

Tooling

All the screenshots in this article are from a simple tool I made on codepen which lets you input a linear-gradient function and see the gradient box, gradient line, angle and color stops information as an overlay on top of the element.

There’s all sorts of bugs and limitations in the tool (see the TODO comments in the javascript), so don’t expect too much ☺

The future of layout with CSS Grid Layouts

2015-08-26T00:00:00Z

In this article we'll take a look at the wonderful world of the CSS Grid Layout, a relatively new W3C specification that has partially started to see the light in some browsers.

But before we dive into what this new CSS technique is all about and how to use it, let's quickly review grid theory.

My really short introduction to grid theory

I am not a designer nor did I know much about grid theory before stumbling upon the CSS Grid Layout specification, so don't take my word for it and go look it up yourself, but if you don't care to, here's my pitch about it:

In essence, a grid is a set of invisible vertical and horizontal lines that the various design and content pieces of a web page, magazine or newspaper are positioned on. The goal of a grid is to serve as a base for placing the various pieces of content and to make sure these pieces are aligned and spaced out evenly. A grid, even if not visible, provides the viewer with a way to navigate content visually.

So what has CSS got to do with it?

CSS is getting a set of entirely new properties that, when used together, allow you to define grids for your web content to go onto. These properties are defined in the CSS Grid Layout specification.

CSS hasn’t particularly been known for its ability to handle complex layouts. Although this may not have been a problem when CSS first came out, it has evolved to be a pretty common one over the years as all sorts of complex layouts couldn’t be easily implemented. People have been very creative at getting around the lack of support by using floats or absolute positioning and a variety of CSS layout frameworks emerged.

So it’s about time CSS got some proper layout solutions to support today's use cases.

Can I use it?

Yes you can start using it today, but only Chrome has implemented the specification far enough to play with grids, and you need to turn the experimental Web Platform features flag on.

IE has an early implementation (dating back to IE10) too but the spec has evolved since it was added and so it’s not entirely compatible with it anymore.

Firefox has started implementing it too so it shouldn’t be too long before you can use it in this browser.

Finally, a polyfill exists, so you have no excuses not to start experimenting (and I strongly encourage you do)!

So what's a CSS Grid Layout?

To its core, a grid layout in CSS is a set of vertical and horizontal lines that define cells that content can be arbitrarily positioned on. So it looks like a table in a way, except for a few key differences we’ll see later.

The previous figure shows the building blocks of a grid:

Lines: in this case there are 4 vertical lines and 3 horizontal lines. Lines are given numbers starting from 1. Vertical lines are shown from left to right, but this depends on the writing direction. Lines can optionally be given names, which helps with referencing them in CSS as we’ll see later.
Tracks: a track is simply the space between 2 parallel lines. So in the above example, there are 3 vertical tracks and 2 horizontal tracks. Lines are useful to say where content starts and stops, but tracks are ultimately where content goes.
Cells: a cell is where a horizontal and a vertical track meet. In the figure above, only one cell has been highlighted, but there are 6 cells in the grid.
Areas: an area is a rectangular shape that can span an arbitrary number of cells. Areas, like lines, can be named. In the above grid, we could for example define areas A, B and C as shown below:

Now that we know these simple definitions, let’s take a look at what makes grids so powerful.

One key advantage of CSS grids is that they enforce real separation of layout and markup.

Indeed, the grid itself is completely defined purely in CSS. This means that apart from the parent HTML element the grid is applied to, there's no need for defining any extra elements for the columns, rows, cells or areas.

When you think of it, that’s a really interesting property. One aspect of it is that the visual order of elements on the page is decoupled from the order of elements in the markup. That’s important because on a page the source order is used for things like speech and tab navigation, so CSS Grids allow you to optimize the markup for accessibility without compromising your ability to manipulate the visual result. One other point is that the markup will be somewhat lighter and easier to understand, and therefore easier to maintain.

But more importantly, this gives a very powerful tool for separating the content from the layout, effectively decoupling them in a way that making a change to any of them doesn’t impact and otherwise break the other. As a designer, you could easily experiment with new layouts without having to change anything else than CSS, as long as your new layouts provide the expected lines and areas the content uses. And as a developer, you would simply need to use the numbered or named lines and areas to position your content on the grid.

Imagine the simple following grid layout:

In this layout, named areas have been defined, allowing content to be positioned in them simply by referencing these names. This means that not only can we change this layout relatively easily in the future, as long as we maintain the named regions (here the named regions act as the layout’s public API in a way), but media-queries can also be used to change this layout dynamically too. Remember, the whole layout is defined in CSS, so media-queries play with grid layouts very well.

For instance, using a media query, the previous layout could be switched to something like this on smaller screens:

Enough with the theory, let’s see how grid layouts are actually defined using CSS.

Creating grids with CSS

Defining a grid requires only one HTML element to be present: the grid container. That’s the element the layout is going to be applied to. Any HTML element that’s a child of the grid container is a grid item. Grid items are what go onto the grid.

Setting an element as being a grid container is as simple as:

.container { display: grid; }

Just doing this though isn’t nearly enough, we also need to define what this grid looks like, how many columns and rows it has, and how big they are. This can be done by using grid templates as shown in the following example:

.container {
  display: grid;
  grid-template-rows: 200px 100px;
  grid-template-columns: repeat(4, 100px);
}

In the example above, we’re explicitly defining a grid that has 2 rows and 4 columns. Note how the repeat() function is used here to avoid repeating a fragment of the tracks 4 times, this is equivalent to 100px 100px 100px 100px.

Each of the defined tracks is given a size, and so we end up with a grid structure that looks like this:

Note that grids can also be implicitly defined like in:

.container {
  display: grid;
  grid-template-rows: auto;
  grid-template-columns: repeat(4, 100px);
}

In this case, the browser will keep on adding rows as needed to fit the content.

Let’s go back to our simple, explicit, 4 by 2 grid and let’s add some content. As we said previously, we only need 2 levels of elements, the container and the items, so let’s use this:

<div class="container">
  <div class="item1">item 1</div>
  <div class="item2">item 2</div>
  <div class="item3">item 3</div>
  <div class="item4">item 4</div>
  <div class="item5">item 5</div>
</div>

Which, without any specific CSS code to position the items, leads to the following arrangement:

As you can see above, since we didn’t define where these items should sit on the grid, the browser has positioned them automatically by putting one item per cell until the first row got filled in, at which point it decided to put the rest of the items on the next row.

The spec defines an algorithm for automatically placing items on the grid if they haven’t been given a position and that is sometimes useful when, for example, you have either many items or a dynamic number of items and don’t want to or can’t define the position for them all.

Let’s see how our items can be positioned on the grid.

.item1 {
  grid-row-start: 1;
  grid-row-end: 2;
  grid-column-start: 1;
  grid-column-end: 3;
}
.item2 {
  grid-row-start: 1;
  grid-row-end: 2;
  grid-column-start: 3;
  grid-column-end: 5;
}

Here we’ve defined the position of the 2 first items, which means that the other ones will still be automatically positioned by the browser, as shown below:

The above example uses line-based placement in that it uses numeric indexes of lines to place items. Items 1 and 2 are defined to be positioned between horizontal lines 1 and 2, and between vertical lines 1 and 3 and 3 and 5.

What happens now if we keep on adding items, but there aren’t any grid cells defined to receive them?

The grid keeps on adding rows and columns as needed. Note that these new tracks will have their sizes depend on the content size.

So that’s all well and good, but one thing that’s really useful when it comes to CSS Grids is grid areas as we saw earlier. Let’s take a look at how grid areas can be used in CSS.

First of all you’ll need to define the grid container and its tracks and areas:

.container {
  display: grid;
  grid-template-rows: 100px auto 100px;
  grid-template-columns: 100px auto;
  grid-template-areas:
    "header  header"
    "sidebar content"
    "footer  footer";
}

In this example, we’ve defined 3 rows, the top and bottom ones being 100px high, while the middle one will just adapt to its content. We’ve also defined 2 columns, the left one 100px wide, and the right one adapting to its content.

We’ve also introduced the grid-template-areas property that may look strange at first, but it’s really simple when you realize it’s only a representation of the grid with names on it. Let’s explain this.

We said we had 3 rows and 2 columns right? Let’s represent them in ascii-art like this:

+---+---+
| . | . |
+---+---+
| . | . |
+---+---+
| . | . |
+---+---+

Each dot is a cell where areas can be defined. So let’s define areas for a typical website layout:

+--------+--------+
| header | header |
+--------+--------+
| sidebar| content|
+--------+--------+
| footer | footer |
+--------+--------+

We want the header and footer to span the whole width, so we’ve repeated them in the 2 columns. Now, if we just remove all the useless ascii-art style borders and include each line in double-quotes, we get something like this:

"header  header"
"sidebar content"
"footer  footer"

which is exactly how grid areas are defined in CSS using the grid-template-areas property. It helps thinking about it as a 2D representation of the grid in ascii-art and aligning area names.

You can also use dots ‘.’ when a cell isn’t covered by an area. Here’s an example of this:

.container {
  display: grid;
  grid-template-rows: repeat(5, 100px);
  grid-template-columns: repeat(5, 100px);
  grid-template-areas:
    ". . . . ."
    ". . . . ."
    ". . a . ."
    ". . . . ."
    ". . . . .";
}

In this example, there are 25 cells and 1 area that is defined to occupy only the center cell.

Now, going back to the previous header, sidebar, content, footer example, let’s add some markup to it:

<div class="container">
  <div class="header">header</div>
  <div class="sidebar">sidebar</div>
  <div class="footer">footer</div>
  <div class="content">
    <p>Lorem ipsum dolor sit amet...</p>
 </div>
</div>

The last thing that needs to be done now is position each grid item in the right named areas (we’ve conveniently used class names that correspond to area names here):

.header { grid-area: header; }
.sidebar { grid-area: sidebar; }
.footer { grid-area: footer; }
.content { grid-area: content; }

Which would produce something like this:

Now, if we wanted to change this layout at any point, or make it adapt to variable screen sizes thanks to media queries, we would only have to change the grid declaration. Maybe to something like this:

.container {
  display: grid;
  grid-template-rows: auto;
  grid-template-columns: 100%;
  grid-template-areas:
    "header"
    "sidebar"
    "content"
    "footer";
}

Which, without any other changes to the CSS or markup, would produce this:

We could even completely reshuffle the order of items in the grid without having to change the order in the markup.

CSS Grids in the real world

So far we’ve only seen simplistic examples of grids, but websites making use of grid systems often have much more complex grid structures. It’s not uncommon for such websites to be based on 12 columns, each of them separated by gutters (narrower columns used to space things out).

Take dribbble.com for example, this design showcase website makes use of a grid to display the designs uploaded by their users. Here the grid is very easily visible because each design occupies exactly one cell (excluding gutter rows and columns):

Dribbble’s grid layout is also responsive, so if the viewport size changes, the size and number of columns changes gradually, as shown in the following animation:

Using the new properties that come with the CSS Grid Layout implementation, we can try and create a dribbble-like layout. For an added twist, let’s try and insert a piece of text content on the second row, and make that content span the whole row.

First of all, our markup will be something like this:

<ul class="dribbbles">
  <li class="dribbble">...</li>
  <li class="dribbble">...</li>
  ...
  <li class="dribbble">...</li>
  <li class="advert">Some text ....</li>
</ul>

Where the .dribbbles element is the main container for all items, and each .dribbble element represents one of the designs showcased on the page. The last item, .advert, is the piece of textual content we want to show on the second row.

Now, let’s make a grid for it.

.dribbbles {
  display: grid;
  /* Let's assume the default design has a fixed width */
  width: 880px;
  grid-template-columns: repeat(4, 220px);
  grid-template-areas:
   ".      .      .      ."
   "advert advert advert advert";
  justify-items: center;
}
.advert {                                          
  grid-area: advert;                                         
}

Here we’ve defined 4 columns in our grid. We haven’t said anything about rows, so the browser will automatically create rows as needed. We did, however, define a couple of rows using the grid-template-areas property and that’s because we need to place our advert text content on the second row. So we’ve just said that we want a first row with empty cells that are going to be filled in automatically with grid items, as they come, and then a second row that defines an advert area that spans all 4 columns.

Finally, the second rule in there uses the grid-area property to place the grid item that has the class advert inside the advert area.

Given the markup we created earlier, this should end up looking something like this:

Pretty simple, right? Of course this requires some styling code to make the items look nice and all, but the layout CSS code is really short and there’s no extra markup required.

Now, we can make this responsive too. Let’s say we want to jump to a 3-columns layout for smaller screens:

@media (max-width: 880px) and (min-width: 660px) {
  .dribbbles {
    width: 660px;
    grid-template-columns: repeat(3, 220px);
    grid-template-areas:
      ".      .      ."
      "advert advert advert";
  }
}

And so on, for all the screen sizes we want to support. And so, just adding a couple more short media queries, we could end up with something like this:

Sites like Dribbble don’t use the CSS Grid Layout yet, but there are well known CSS libraries that provide grid systems.

A good example of a grid system in CSS is the Bootstrap CSS library but there are others like PureCSS, 960 Grid System, Responsive Grid System, Materialize, and more.

These grid systems unfortunately have to use arrangements of carefully sized and floated DIVs, and need extra DIVs for columns and rows, as well as pseudo-elements for clearing floats. It’s not that it’s all that complex, after all the tricks that these libraries rely on have been known for years, but they’re just this, tricks, and it’s about time we get a proper built-in solution and get rid of them. Don’t get me wrong, these libraries are awesome in all sorts of way, and most importantly, they are the ones which made it clear we needed a new CSS feature for defining grids in web layouts, and were therefore the ones which ultimately made the CSS Grid Layout specification possible.

Closing words and references

As we saw, CSS grids are a pretty good tool for defining layouts that have nice characteristics like authoring simplicity, maintainability, separation of content and layout and that play well with responsive design. But we’ve only barely scratched the surface of what is possible with CSS grids. The various properties and syntax possibilities allow for a lot of really cool things to be done, and I hope this article made you want to dig further by yourself.

Here are some interesting references if you wish to know more:

The spec: http://dev.w3.org/csswg/css-grid-1/
Some grid examples by Rachel Andrew: http://gridbyexample.com/
Bug to follow for the implementation in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=616605
How to use it in IE: https://msdn.microsoft.com/en-us/library/hh673533%28v=vs.85%29.aspx
If there’s one talk you need to watch, it should be this one by Rachel Andrew:

https://www.youtube.com/watch?v=GRexIOtGhBU

And Manuel Rego’s talk is also very useful:

https://www.youtube.com/watch?v=9js_5MjiGFo

Contribute to Firefox DevTools, become a better web developer

2015-09-03T00:00:00Z

If you’re a web developer and you’re interested in open source projects and you commonly use browser devtools in your activities then you might want to read on.

In this article, I’ll go over some of the things that make the Firefox DevTools open source project special, and how those things can make you better at web development.

(If you’re already convinced and just want to get started right away, scroll to the bottom for the list of links)

It feels like Web Development anyway

The whole thing is written as a client-server application. It has a front-end part that’s all written in HTML, CSS and JavaScript, and it connects to a server that’s written in JavaScript too.

Those two parts communicate via a TCP protocol but from JavaScript, it’s encapsulated in a way that you just end up calling asynchronous functions.

The client-server separation comes from the fact that DevTools is not only able to debug your local browser tab, but also a tab on a remote device (maybe you have a FirefoxOS phone you want to test an app on, or need to fix a bug on a site on Firefox for Android, etc.), and so the front-end isn’t guaranteed to have access to the page it’s inspecting.

Reasoning about this is simple if you think of it this way:

the front-end is the toolbox UI: the panels, the things you click one, where you see previews of DOM nodes, and script breakpoints, etc.
the back-end however is what runs on the page/device/tab you are targeting. It’s a series of JavaScript objects that live next to the content page you are inspecting, so it has access to DOM nodes, stylesheets, scripts that are running, can listen in on network requests, etc.

As I said earlier, the whole code is written using the languages of the web, so you’ll feel right at home.

Fun fact: we actually use DevTools to debug DevTools! In fact you can use DevTools to debug the whole Firefox UI, because that’s written in HTML, JavaScript, CSS too!

https://www.youtube.com/watch?v=nxB1hj3UC4w

That’s a really cool way to test your own work. Because DevTools is an app for developers, you’re not such a bad user to test it on! Knowing the complexity and volume of the Firefox UI, if the tool you work on is up to the task when debugging it, then that’s a pretty good field test too.

In terms of code management, whether you’ve used Git or Mercurial in the past, that’s no problem, the project can be contributed to using any of them, and tools and procedures exist for both:

Here are the docs for using Mercurial
Mozilla has a long history of using the Mercurial MQ extension. While it’s useful, it’s not recommended anymore and instead you should use the much more git-like workflow with branching, bookmarks, rebases and history rewriting.
If you want to use git, there’s a mirror repository on GitHub and hear that the git-cinnabar tool is really useful for working with Mercurial repositories directly from Git.

Live on the edge — Learn the newest technologies

One of the great parts about working on a piece of the browser is that you can take full advantage of that browser’s functionalities. DevTools run in a sort of a privileged mode that makes it possible to use all the new and shiny web platform features.

If you’ve wanted to try new implementations of the EcmaScript standard, know that the DevTools code makes use of pretty much all the new syntaxes introduced in ES2015 supported in Firefox. Just looking at the code is a great opportunity to learn.

The project makes extensive use of things like modules (with a common-JS like module loader), promises (as well as tasks which is an awesome way to write asynchronous code using yield and generator functions). Of course things like let, const, arrow functions, Map, Set, spread operator, and more, get used a lot too.

DevTools is also uniquely place to make use of all the latest CSS features that are implemented in Firefox. Some of these are CSS variables (extensively used for theming the app), Flexbox layout, CSS filters, animations, transforms, etc.

And if you’ve wanted to learn about SVG, DevTools also makes use of those for pretty much all the icons in the app now, and Canvas is used quite a lot for drawing graphs in places like the performance tools.

Go over the edge — Learn how browsers work

Why stop there when you can go even further? Working on DevTools is a unique opportunity to learn the web from the inside.

The web platform evolves rapidly, new APIs and features are specified and implemented on a regular basis, and most of them need some sort of tooling support. Something that helps users debug problems when using these APIs or features for the first time. And so, working on DevTools means that you not only get to learn about these new things early, but also get to know more about how they work. Three examples come to mind:

DOM Promises are new, and they’re not particularly easy to debug, so there’s some work going on right now about adding a new promise debugging panel. The people working on this panel not only have the chance to learn more about promises, but also get to work with the very people that are implementing them in Firefox (in C++). A promise debugging panel needs some special platform APIs to list promises and their status, which is a sure way to dive into interesting implementation discussions.
Web animations are getting a whole new API specified and implemented at the moment that will change the way animations are created, sequenced, dynamically changed and provide a much more compelling way to animate things on the web. Similarly to the previous example, working on a tool to list, inspect and edit animations means that you get to use this new API, but also get into low-level discussions about how it’s implemented and how specific platform APIs can be added to allow the tool to dig in more useful information about them for developers.
Working on the performance tool is also a great way to learn how browsers work. Especially what the rendering pipeline of a browser is like, and this has direct consequences on the way you’ll approach web development in the future (also note that browsers share an almost identical rendering pipeline, so you wouldn’t be learning things that only apply to Firefox). This tool shows the internal operations the browser executes when rendering a page, and so you get to learn about things like restyles, reflows, compositing and painting and what takes time, as well as what can be optimized.

Generally, working on DevTools means that you’re writing code that’s at the frontier between the content code (the code that runs in the page) and the browser C++ APIs that are exposed to JavaScript.

Maybe C++ is already your thing, maybe it’s not but you’d like to find out more. Well, at the very least you’d come upon C++ APIs you’ll need to use, which will give you gradually more knowledge on how browsers work which will, in turn, make you a better web developer. And if you want more, there are always DevTools features that require some sort of C++ platform support which you can get mentored to hack on yourself.

Get involved in an awesome community

Mozilla is known for its really big and active community of Mozillians, and DevTools, being a Mozilla project, is no exception.

This means you get to work with both Mozilla staff and volunteers, distributed all over the world, reporting and fixing bugs and landing awesome features in DevTools. And you can get in touch in various ways:

Come and join the #devtools channel on IRC
Join the conversations happening on the mailing list
Tweet at @FirefoxDevTools
Report ideas and vote for existing ideas on the uservoice site
Tell the world about your cool new feature on the Mozilla Hacks blog
Or even meet some of the DevTools people in person by getting invited to Mozilla events (there are 2 bigs ones per year, and an important number of volunteers get invited).

If you’re not too sure yet but feel like looking to get an idea, I highly suggest joining IRC and/or the mailing list and just getting a feel for the types of conversations that happen there.

Remember, it’s open source which means everything is done in the open, you can tell the world what you’re working on, share early demos and get quick feedback. That is a powerful motivation tool right there.

How hard is it to get started?

It’s not that hard at all. It comes down to:

reading some docs
checking out a repository
building Firefox
making changes to DevTools
posting patches on bugzilla

Of course I’m not going to lie, like any reasonably sized project that has been going on for a few years, there are complexities attached to that. Docs may sometimes be scattered around, the first build may take a long while, posting patches requires some preliminary configurations, etc. But it’s not rocket science either, and there are always people on the mailing list or #devtools or #introduction IRC channels that can help.

Also, there’s an ongoing project aiming at removing even more barriers to entry for new contributors. In the end, getting the code, building and making DevTools changes that can be reloaded in Firefox will be even quicker and simpler.

Alright, I’m convinced, where do I start?

First things first, go through our (short) wiki page, especially take a look at our hacking guide
Then find a bug to work on (or ask on IRC)
Ping people on bugzilla if you need mentoring or just pointers to get started
Learn how to submit a patch for it

That’s it! Welcome on board!

Inspecting animations in Firefox

2015-09-18T00:00:00Z

CSS animations and transitions are awesome, but they’re also hard to get right. You want your animations to be sequenced a certain way, to last the right amount of time, and to progress at the right pace.

That’s where tooling comes in. What if you could slow down, rewind, or pause your animations anywhere, so that you could inspect the animated elements more easily?

That’s what we started to work on a while back in the Firefox DevTools. In fact, I already mentioned an earlier version of the animation inspector tool previously (by the way, this article also mentions some of the other ways you can inspect and edit animations in Firefox DevTools, like editing keyframe rules, or visually changing the cubic-bezier timing function, so go check that out).

I now want to introduce a new version of the tool that’s going to see the light in Firefox 43:

https://www.youtube.com/watch?v=T2jykykN3yc

The main features of this version are:

all currently animated nodes are displayed automatically, and when new animations are created or removed, that’s reflected too,
animations are displayed in a timeline user interface which is the obvious choice for representing animations,
while animations are running, a scrubber is displayed and moves with time, you can also drag and drop the scrubber to any point in time,
animations are color-coded so you know if they are CSS animations or CSS transitions,
animation delays and iterations are also displayed in the timeline,
there’s also a tooltip that provides more details about the animations,
finally, each animation is displayed along with its target DOM node which you can use to highlight the corresponding element in the page, or select it in the inspector tool.

There’s so much more to do however, this is still an early version of the tool. Don’t hesitate to file bugs if you see anything weird. Here are some of the things we’d like to add:

the ability to edit or even create animations,
add the ability to change the playback rate of all animations,
display and edit the keyframes and timing-function (with the cubic-bezier editor),
display and edit the animated properties,
support more animation types (the Web Animations API will soon allow web developers to create animations from script, and the tool should support those too).

If you want to follow the development, or even contribute, here is the main bug.

Revisiting the Firefox DevTools

2015-12-30T00:00:00Z

Read the full article at https://www.smashingmagazine.com/2015/12/revisiting-firefox-devtools/

Le positionnement dans les Grilles CSS

2016-02-23T00:00:00Z

This is the French translation of Manuel Rego’s (@regocas) post “Deep Dive into Grid Layout Placement”, published on February 1st, 2016. All images and code samples come from the original article, with the author’s permission. Translation: Patrick Brosset (@patrickbrosset).

Ceci est la traduction française de l’article “Deep Dive into Grid Layout Placement” par Manuel Rego (@regocas), publié le 1er Février 2016. Toutes les images et extraits de code viennent de l’article original avec la permission de l’auteur. Traduction: Patrick Brosset (@patrickbrosset).

Une revue complète des différentes méthodes de positionnement offertes par les grilles CSS

Manuel Rego

1er Février 2016

Ces derniers mois, dans le cadre de mon travail à Igalia, je me penche sur les derniers détails d’implementation du positionnement des éléments au sein d’un layout de type CSS Grid dans Blink. En résumé, il s’agit principalement de travailler sur ces 2 choses:

Supporter d’abord les grilles implicites avant les grilles explicites. Cela afin qu’une grille puisse ajouter des pistes si besoin, pas seulement dans la direction où la grille grandit (en général vers la droite et le bas), mais aussi dans la direction opposée.
Faire fonctionner la résolution des lignes inconnues de la grille. Ceci peut arriver lorsqu’un élément est placé sur une ligne nommée “foo”, mais que cette ligne n’existe pas au sein de la grille.

À première vue ces tâches peuvent paraître simples, mais elles ont demandé une refonte assez importante de l’implémentation interne. Elles m’ont même finalement poussé à remanier tout le code de résolution du positionnement dans une grille. Pour l’occasion j’ai même écrit un document expliquant tout le plan et les détails techniques. Vous y trouverez les liens vers tous les changements effectués.

Maintenant que le gros du travail est terminé, il est temps d’expliquer comment placer des éléments dans une grille. Bien que mon collègue Sergio ait déjà publié un article à ce sujet en 2014, la spécification ayant changé depuis, je pense qu’il est bon d’expliquer à nouveau les mécanismes de placement au sein d’une grille. Cet article est en quelque sorte un résumé (avec des exemples) de la partie “Placing Grid Items” de la spécification CSS Grid Layout.

Les lignes d’une grille

Probablement l’un des concepts les plus importants de la spécification. Les lignes d’une grille sont celles qui la séparent horizontalement et verticalement. Ces lignes sont numérotées, la première étant numéro 1.

Utilisons une grille de taille 3x2 afin d’expliquer comment cela fonctionne :

<div style="display: grid;
            grid-template-columns: 300px 200px 100px;
            grid-template-rows: 100px 50px;">
</div>

Les propriétés de positionnement dans une grille

Afin de positionner des éléments à l’intérieur d’une grille, il va falloir utiliser des propriétés de positionnement. Ces propriétés sont les suivantes :

grid-column-start: Sert à définir la ligne verticale où l’élément commence.
grid-column-end: Sert à définir la ligne verticale où l’élément s’arrête.
grid-row-start: Sert à définir la ligne horizontale où l’élément commence.
grid-row-end: Sert à définir la ligne horizontale où l’élément s’arrête.

Grâce à ces propriétés vous pouvez définir la zone où un élément va venir se positionner, en utilisant les numéros des lignes.

La valeur initiale de ces propriétés à auto. Cela rend possible le positionnement automatique d’un élément (au sein de cellules disponibles dans la grille). Pour plus d’information à ce sujet, vous pouvez consulter un article précédent.

Il existe aussi des propriétés raccourcies :

grid-column: Raccourci des propriétés grid-column-start et grid-column-end.
grid-row: Raccourci des propriétés grid-row-start et grid-row-end.
grid-area: Raccourci servant à définir les 4 propriétés à la fois.

Ajoutons l’élément suivant dans la grille définie précédemment :

<div style="grid-column-; grid-column-end: 4;
            grid-row-start: 1; grid-row-end 2;">
</div>

Ou, plus simplement, en utilisant les propriétés raccourcies :

<div style="grid-column: 2 / 4; grid-row: 1 / 2;"></div>

Ce qui signifie que l’élément sera positionné sur la première ligne, et sur les deuxième et troisième colonnes.

Le recouvrement de cellules

Grâce aux numéros de lignes, l’élément précédent a recouvert 2 colonnes (la 2ème et la 3ème). Nous pourrions faire la même chose en utilisant le mot clé span et en indiquant le nombre de cellules à recouvrir.

En effet, l’élément peut être positionné de manière identique avec :

<div style="grid-column: 2 / span 2; grid-row: 1;"></div>

Dans l’exemple précédent, nous n’avons défini que le numéro de ligne où l’élément commence. Cela signifie que grid-row-end prend la valeur auto, et dans ce cas auto couvre par défaut 1 cellule.

Lignes négatives

Pour le moment, nous avons uniquement numéroté les lignes avec des nombres positifs, mais les lignes peuvent aussi être référencées avec des nombres négatifs, permettant ainsi de référencer des lignes depuis la fin de la grille.

En utilisant l’exemple précédent, nous pouvons positionner une nouvelle fois l’élément au même endroit en utilisant des nombres négatifs :

<div style="grid-column: -3 / -1; grid-row: -3 / -2;"></div>

Cela peut s’avérer très utile dans certaines situations. Par exemple, afin de positionner un élément dans la dernière colonne, sans pour autant connaître le nombre total de colonnes de la grille, il nous suffira de définir : grid-column-end: -1.

Nommage des lignes

Non seulement les lignes peuvent être référencées grâce à leurs indices (positifs ou négatifs), mais elles peuvent être nommées. Nommer une ligne permet de ne pas avoir à en connaître le numéro lorsqu’on la référence.

Modifions à présent la définition de notre grille, en gardant les mêmes tailles mais en nommant cette fois les lignes :

<div style="display: grid;
            grid-template-columns: [start] 300px [main] 200px [aside] 100px [end];
            grid-template-rows: [top] 100px [middle] 50px [bottom];">
</div>

Ainsi, pour placer l’élément à la même position que précédemment, il nous suffit simplement d’utiliser le nom des lignes :

<div style="grid-column: main / end; grid-row: top / middle;"></div>

Une même ligne peut avoir plusieurs noms différents, il suffit pour cela de les lister dans la définition : grid-template-rows: [top start] 100px [middle center] 50px [bottom end];.

De plus, les noms de lignes peuvent être répétés. Afin de référencer une ligne dont le nom a été utilisé à plusieurs reprises, il faudra utiliser un nombre (positif ou négatif). Prenons un nouvel exemple pour illustrer cela :

<div style="display: grid;
grid-template-columns: [col] 200px [gap] 50px [col] 200px [gap] 50px [col] 200px [gap];">
</div>

Et imaginons les éléments suivants :

<div style="grid-column: col 2;"></div>
<div style="grid-column: col 1 / gap 2;"></div>
<div style="grid-column: col -1;"></div>

Bien entendu, il est aussi possible de recouvrir plusieurs cellules jusqu’à une ligne nommée :

<div style="grid-column: col 2 / span 2 gap;"></div>

Les aires

Les aires de grille sont encore plus intéressantes, il est possible d’y positionner directement des éléments. Pour cela, il nous faudra utiliser la propriété grid-template-areas qui permet de nommer différentes zones (les aires) de la grille. Il est ensuite possible d’utiliser la propriété raccourcie grid-area pour positionner les éléments dans ces aires.

Utilisons une grille légèrement plus grande (5x4) dans cet exemple :

<div style="display: grid;
            grid-template-columns: 100px 100px 100px 100px 100px;
            grid-template-rows: 100px 100px 100px 100px;
            grid-template-areas:
              'title  title  title  title  aside'
              'nav    main   main   main   aside'
              'nav    main   main   main   aside'
              'footer footer footer footer footer';">
</div>

Et positionnons 1 élément au sein de chacune des ces aires :

<div style="grid-area: title;"></div>
<div style="grid-area: nav;"></div>
<div style="grid-area: main;"></div>
<div style="grid-area: aside;"></div>
<div style="grid-area: footer;"></div>

Aires et lignes nommées

L’un des points intéressants relatif aux aires est qu’elles créent des noms implicites pour les lignes qui les entourent. Ces noms implicites utilisent les suffixes “-start” et “-end”. Il est donc possible d’utiliser ces noms pour positionner un élément à la place d’utiliser l’aire elle-même.

Par exemple, l’aire “title” de l’exemple précédent génère 4 noms implicites pour les lignes qui l’entourent (2 par axe) :

Ligne de gauche : “title-start”
Ligne de droite : “title-end”
Ligne du haut : “title-start”
Ligne du bas : “title-end”

Nous pourrions donc positionner un élément en utilisant ces noms de lignes :

<div style="grid-column: aside-end;
            grid-row: title-start / nav-end;"></div>

De plus, la même chose est possible dans l’autre sens. En nommant explicitement des lignes avec ces suffixes, les aires correspondantes seront générées implicitement. Il est donc possible de créer la même grille que précédemment en utilisant uniquement des noms de lignes :

<div style="display: grid;
            grid-template-columns: [title-start nav-start footer-start] 100px [main-start nav-end] 100px 100px 100px [aside-start title-end main-end] 100px [aside-end footer-end];
            grid-template-rows: [title-start aside-start] 100px [nav-start main-start title-end] 100px 100px [footer-start nav-end main-end aside-end] 100px [footer-end];">
</div>

Tous les exemples d’éléments positionnés précédemment se retrouveront exactement au même endroit dans cette nouvelle grille.

Grille implicite

Grâce aux propriétés de définition d’une grille (grid-template-columns, grid-template-rows et grid-template-areas), il est possible de déterminer les colonnes et rangées d’une grille. Cependant, la spécification prévoit aussi la possibilité de positionner des éléments en dehors de cette grille explicite. Pour cela, de nouvelles colonnes et rangées sont créées implicitement et automatiquement, et leurs tailles sont contrôlées par les propriétés grid-auto-columns et grid-auto-rows. Dans les exemples qui suivent, nous utiliserons la couleur rouge pour représenter les lignes implicites.

Utilisons une grille très simple de 2x1 :

<div style="display: grid;
            grid-template-columns: 200px 200px;
            grid-auto-columns: 100px;">
</div>

Maintenant, imaginons placer un élément dans la 5ème colonne (grid-column: 5;). Cette grille n’ayant que 2 colonnes, 3 nouvelles colonnes implicites sont créées afin de positionner l’élément.

Il est aussi possible de créer des colonnes et rangées implicites en positionnant des éléments qui recouvrent plusieurs cellules. Par exemple, prenons un élément qui commence à la 2ème colonne et en recouvre 3 (grid-column: 2 / span 3) :

Notons que la grille peut être implicitement étendue dans les deux sens. Par exemple, en plaçant un élément avec grid-column: -5;, 2 nouvelles colonnes seront ajoutées sur la gauche de la grille et l’élément sera positionné dans la colonne -2.

Grille implicite et lignes nommées

Ce que nous venons de voir n’est pas la seule façon de créer des colonnes et rangées implicites. Il est aussi possible de les créer en utilisant des lignes nommées non définies. Ceci relève plus d’une manière de trouver des erreurs de CSS plutôt que d’une fonctionnalité, mais certains pourront trouver cela utile. L’idée sous-jacente est que toutes les lignes faisant partie de la grille implicite se retrouvent nommées avec tous les noms utilisés pour positionner les éléments.

Utilisons un exemple simple : plaçons des éléments qui référencent une ligne non existante appelée “foo”. Créons 3 colonnes implicites (1 avant et 2 après la grille explicite) avec les éléments suivants :

<div style="grid-column: foo;"></div>
<div style="grid-column: 2 / span 2 foo;"></div>
<div style="grid-column: -1 foo;"></div>

L’élément ayant grid-column: foo est positionné sur la 4ème colonne (une colonne vide ayant été rajoutée juste après la grille explicite). En effet, la première ligne considérée comme ayant le nom “foo” est la première ligne implicite (ligne 4), la dernière ligne de la grille explicite (ligne 3) n’étant pas incluse.

De plus, le dernier élément grid-column: -1 foo est positionné dans la colonne -1. La raison pour cela étant que la recherche de ligne nommée “foo” démarre au bord de la grille explicite. Les lignes -1, -2 et -3 sont ignorées (puisqu’elles ne portent pas le nom “foo”) et la ligne -4 est donc celle qui prend ce nom (la première ligne de la grille implicite).

Les choses se corsent un peu lorsque la ligne existe vraiment car, dans ce cas, la ligne est prise en compte quand l’élément est positionné. C’est d’autant plus complexe lorsqu’il y a du recouvrement de cellules en jeu, et qu’une ligne nommée est recouverte mais qu’il n’y a plus assez de lignes. Dans ce cas, seules les lignes implicites se trouvant dans la direction de la recherche sont considérées comme ayant le nom en question.

Un exemple devrait aider à la compréhension. Dans l’exemple précédent, donnons un nom à la ligne du milieu :

<div style="display: grid;
            grid-template-columns: 200px [middle] 200px;
            grid-auto-columns: 100px;">
</div>

Maintenant, positionnons quelques éléments référençant cette ligne “middle” :

<div style="grid-column: 3 middle;"></div>
<div style="grid-column: span 2 middle / 5;"></div>
<div style="grid-column: -4 / span middle;"></div>

Le cas le plus étrange ici est grid-column: span 2 middle / 5;. Comme indiqué sur le schéma, l’élément occupe la place de la colonne -1 à la colonne 4 (incluses). L’élément se termine à la ligne 5, et doit recouvrir 2 lignes s’appelant “middle” afin de trouver son point de départ. Peut-être devrait-il simplement compter les lignes 4 et 2 comme étant les 2 lignes “middle” recouvertes? Non, puisque comme expliqué auparavant, la recherche se fait en partant du bord de la grille explicite. Donc la ligne 2 étant dejà prise en compte dans le recouvrement, la prochaine ligne considérée est, dans le sense de la recherche, la ligne implicite à gauche de la grille explicite : ligne -4.

Cas spéciaux

Les propriétés de positionnement peuvent donner lieu à certains cas spéciaux qui sont alors résolus par la section de la spécification sur la gestion des conflits.

Par exemple, si un élément se retrouve positionné avec une ligne de fin se trouvant avant la ligne de départ, les deux lignes sont inversées. grid-column: 5 / 2; devient alors grid-column: 2 / 5;.

De plus, s’il y a recouvrement à la fois aux positions de départ et de fin, le span de la position finale sera ignoré. Donc grid-column: span 2 / span 3; devient grid-column: span 2;. Ceci aura pour effet d’utiliser algorithme de positionnement afin de trouver une zone vide pour placer l’élément (une zone de 2 colonnes dans cet exemple).

Le dernier cas spécial se produit lorsqu’il y a recouvrement uniquement vers une ligne nommée. Dans ce cas, le recouvrement est remplacé par span 1. Par exemple grid-column: span foo; devient grid-column: span 1;.

Récapitulatif

Si vous avez lu jusqu’ici, vous êtes visiblement très intéressé par les grilles CSS. En conclusion, le point le plus important de cette spécification est la grande flexibilité offerte quant au positionnement des éléments sur la grille. En effet, comme nous venons de le voir, il y a de nombreuses manières de positionner un élément au même endroit. Il est probable que les utilisateurs s’habituent à quelques-unes de ces manières et oublient les autres.

De mon point de vue, le positionnement simple (à base d’indices de lignes, noms de lignes et aires) est plutot aisé à prendre en main. Le concept de grille implicite n’est pas si compliqué non plus. Les indices négatifs rajoutent un côté amusant. Par contre, le comportement des lignes indéfinies est assez complexe (mais avec un peu de chance, ce n’est pas quelque chose qui se révélera très important dans l’utilisation des grilles). Cela dit, mon avis est forcément biaisé, puisque je travaille depuis maintenant longtemps sur les grilles CSS.

Pour finir, j’ai pensé qu’il serait intéressant de terminer par un exemple complexe qui utilise la plupart des concepts décrits dans cet article. Si vous êtes capables de le comprendre complètement, vous maîtrisez alors le positionnement dans les grilles CSS. Félicitations!

Voici la définition de la grille que nous utiliserons dans cet exemple :

<div style="display: grid;
            grid-template-columns: [left] 200px [main-start] 100px [center] 100px 100px [main-end] 50px 50px [right];
            grid-template-rows: [top title-start] 50px [title-end main-start] 200px [main-end center] 150px 100px [bottom];
            grid-auto-columns: 50px;
            grid-auto-rows: 50px;">
</div>

Dans le schéma suivant, vous pouvez voir la manière dont les différents éléments sont positionnés.

Vous pouvez essayer la démo sur notre site d’exemples : http://igalia.github.io/css-grid-layout/grid-placement.html

État des lieux

Comme je l’ai déjà dit dans l’introduction l’implémentation dans Blink devrait désormais supporter (Chrome 50+) toutes ces possibilités de positionnement. Igalia y a travaillé, et nous sommes maintenant en train de transposer l’implémentation vers WebKit.

De plus, Gecko, développé par Mozilla, supporte aussi ces possibilités de positionnement.

Enfin, j’aimerais préciser à nouveau que ce travail a été réalisé grâce à une collaboration entre Igalia et Bloomberg. Merci beaucoup pour votre support!

Measuring elements and distances in Firefox DevTools

2016-05-25T00:00:00Z

There’s a few ways you can measure elements or distances between elements in Firefox DevTools. In this article, you’ll learn about them and hopefully discover some things which are useful.

Using the rulers

The rulers tool is useful to have around at all times. It provides a way to quickly check how tall or wide a page is, how big are the various columns or sidebars, and how much you’ve scrolled.

The rulers tool is not ON by default, so you have to enable it first. To do this:

open the toolbox (I often use ctrl+shift+I as a quick way to toggle the tools, but that’s just me, F12 works too, and of course right-click on the page and select “inspect element” is often an easy way to do it),
switch to the options panel (that’s the cog icon in the toolbar, far right, or ctrl+shift+O),
there are many options in there, don’t be scared, just scroll down to the “Available Toolbox Buttons” section and make sure the “Toggle rulers for the page” box is checked,
once done, you’ll have a nice little icon in the toolbox toolbar that you can just click to toggle the rulers.

Once you have enabled the rulers tools, it’s really easy to use. Click on the rulers icon to display the rulers, and click again to hide them:

Measuring elements

Whether you’re debugging a layout problem or arranging elements in a new page’s layout, you may need to measure elements to verify they are the right size and aligned correctly. Sometimes an alignment problem is subtle enough that you just can’t see the problem with the naked eye and you need detailed information.

The Firefox DevTools have you covered in a few ways that you may find useful.

First of all, by hitting ctrl+shift+C or by clicking on the cursor icon in the top left corner of the toolbox, you enter the element picker mode.

This tool obviously allows you to select new elements in the page by clicking on them, this is what people use it for, but while moving your mouse over elements in the page, notice that elements are highlighted:

This highlighter also appears when you simply hover over elements inside the inspector (in the DOM tree that’s displayed in the main panel).

What’s interesting about the highlighter is that:

the element’s box-model is highlighted, which means that you get different colors for each of the element’s content area, padding, border and margin,
vertical and horizontal guides are displayed around the element’s content area.

The guides are particularly nice if you’re using the rulers tool at the same time, because they extend all the way up to the rulers so it’s easy to quickly visualize how tall or wide an element is:

Secondly, as you saw in the previous screenshot, as you hover elements in the page, a tooltip appears next to them. We call this tooltip the node info bar and it’s useful when it comes to measuring elements because it contains the dimensions of the element being hovered.

It’s worth noting that these are the dimensions of the border box of the element. So if an element has a content of 20px and 10px padding to the right and left and 5px border to the right and left, then the width displayed in the node info bar is going to be 50px. The reason for this is that it’s often more useful to know the size of the thing you see, and padding and border are often visually part of the element.

If you need even more information about an element’s box model, head over to the “Box Model” tab that you’ll find in the inspector’s sidebar tab panel.

Indeed, while an element’s size might seem right, you might be wondering about it’s margin, or border size.

This panel gives you information about all of the computed element’s box model regions:

But what’s also pretty useful in this view is that you can simply hover over the different colored regions to see them being highlighted individually in the page, with the vertical and horizontal guides around them:

Measuring arbitrary distances on the page

Finally, I wanted to highlight one last tool that might prove useful when you want to get a quick measure of anything on the page: the distance between 2 elements or the size of a given area, whether or not those things are DOM elements or not.

This is the measurement tool, which you need to activate first (just like we did with the rulers tool at the start of this article):

in the options panel, scroll down to the “Available Toolbox Buttons” section,
make sure the “Measure a portion of the page” box is checked,
once done, you’ll have a new icon in the toolbox toolbar which you can click on to display or hide the measurement tool.

The measurement tool is useful to know how tall or wide something is, or how far apart two things are, as illustrated below:

There’s also an experiment going on at the moment on a measurement tool that would detect edges of various things on the page and provide distances between them (which may sound familiar to people using Sketch or xScope, because that’s where the idea comes from).

That’s it! I hope you find these useful. Don’t hesitate to dig around in the toolbox, there are many features that aren’t immediately visible but that might really ease your workflow.

Visual Tools — Prototyping in the browser

2016-05-27T00:00:00Z

Today, browsers come with built-in tools that allow to inspect and debug existing web content.

In this post, I’ll argue that these tools could also allow creating content and working on this content in more visual ways. Ways that offer alternatives to having to deal with code too much, or rather help you deal with complex code in more intuitive ways.

I think visual tools address 2 specific use cases:

Some people already use web technologies today to prototype, create layouts and design ideas. But browser devtools are often complex and intimidating. There is a mismatch between what these people want to use the browser for and what the tools offer. Therefore, when prototyping things in the browser today, the usual “a) edit some code and b) refresh the page” workflow is still the best tool around. We can change this.
And on top of this, there are even more people not using the web at all for this type of work. Designers in particular often feel much more at ease with other tools. Tools made for them specifically. I think browser devtools can reach this audience, and ultimately get more people creating within the browser, with web technologies directly.

Using the browser to our advantage

The web is weird in some sense, there are specific rules that define how a web page behaves if you compare it to other media:

input is often undetermined (user-generated content),
output is almost always unknown (various viewport and font size).

Non-browser tools that attempt to let users create web pages have to deal with this in some way. Often hiding these aspects behind abstractions, generating magic code (that no-one is supposed to look at or understand) on the user’s behalf.

I think we owe it to users to let them understand and write the code that’s used for re-arranging a layout when the page size changes for example, just make it easier to write it in the first place.

Browsers know how to deal with these things anyway, and ultimately, the content is going to be consumed by users in a browser, so it makes sense that we would create it there in the first place.

What would it look like?

What’s a typical prototyping user story? What should prototyping in the browser look like? These remain open questions. I think browser devtools will need to create their own very specific answer.

Right now though, browser devtools sit on one end of the spectrum, with a very technical set of features, mostly developer-oriented, and very little creation abilities. On the other end of the spectrum, we find general prototype and design tools where pretty much any workflow can exist, and that people use to do pretty much anything from logos, to illustrations, to comics, to web page mockups. In the middle, there’s some exploration worth doing.

From a very high level, when you’re creating something for the web, you’re going through these steps:

adding content to the page,
defining a layout for this content,
polishing the design,
adding interaction animations,
testing and debugging,
and shipping.

Browser devtools have a part to play in each of these areas. Here’s what a user flow could look like:

Adding content: create a page directly in the browser to start prototyping, add elements to it, text and images, rename tags, add class names and move them around in the DOM tree (much like you’d move and groups layers in, say, Photoshop).
Defining a layout: resize and move elements (or classes of elements) in the page, add padding, margin or borders, give elements a position, arrange things in a flexible, grid or column layout.
Styling the content: fiddle with colors and gradients, add blur or shadow filters, change opacity or blend-modes, and have live previews while doing so.
Animating interactions: create and adjust animations on elements or transitions between states.
Testing, debugging, adjusting: use a responsive-design mode to test the page under various screen size and user agent combinations. Visually create breakpoints in your design with media queries.
Shipping: finally save or export your prototype.

We’re not starting from scratch

If you really know your devtools, the above flow isn’t too far from being possible today, but it’s not trivial and you can’t do everything. Also, a lot of it still requires coding.

But we’re definitely not starting from scratch. Some designer-oriented features have started to appear in browser devtools in the past, and some really good work has been done.

I work on the devtools for Firefox, so here’s a review of what we’ve done about this in Firefox until now:

Edit HTML to create new content.
Edit tag names and other attributes like classes.
Add, duplicate or delete nodes easily from the inspector.
Drag and drop nodes in the markup to reorder them.
Select elements visually from the page with the highlighter.
Edit padding, border and margins in a visual box-model view.
Move absolutely/relatively positioned elements in the page by dragging them.
Highlight all elements that match a given selector on the page.
Add new CSS rules.
Edit CSS selectors.
Preview how CSS transforms impact elements’ size, shape and position.
Display rulers along the page.
Measure distances.
Change colors with a color picker.
Sample colors from the page with the eye dropper.
Add or edit CSS filters by choosing from a list or reusing saved presets.
Previewing background images.
Previewing fonts.
Displaying all current animations in the page in a timeline.
Listing the animated elements and pausing, rewinding, slowing down or speeding up the animation on them.
Seeing the keyframes and animated properties in animations.
Editing cubic-bezier curves for tweaking how animations and transitions progress through time.
Resizing pages in the responsive design mode, and emulating user agents and touch devices.
Getting help from MDN on any CSS property.
Screenshot the viewport, or the full page or a single DOM node.

What are the next steps?

Well, the above was a mouth full, but as I said before, there’s much to be done before we can truly prototype in the browser. Here are some of the things we have in mind for the future:

Better color pickers with palettes and color extraction from the page.
Border, gradient, blend-modes or shadow visual editor.
Background image, repeat, size, position, clip visual editor.
Font visual editor for font-family, letter and word spacing, line-height and vertical alignment and text decoration and style.
Better screenshot tool.
Visualize and create media-query breakpoints.
Tweak responsive images’ rules.
Extract changes or saving to disk.
Easily resize element’s box-models with the mouse.
Display elements’ relationships to other things in the page.
Find font glyphs and enable opentype features.
Transform and move elements in the page, snap to edges.
Draw gradients in the page by moving the gradient line and color stops.
Editors for grids and flexible layouts.
Create animations from scratch.
Edit durations and delays and keyframes.

Does this sound exciting? It definitely does to me. Make sure to watch future versions of Firefox DevTools as we try and ship more of these.

I hope this was useful or interesting, thanks for reading!

When does white space matter in HTML?

2016-10-21T00:00:00Z

As a web developer, you don’t often spend time thinking about white space, right? I mean, how often do they actually matter? Well, hopefully with this article, you’ll think of them more often, or at least will know when they do matter and know how to track them down!

What is white space?

White space is any string of text composed only of spaces, tabs or line breaks (to be precise, either CRLF sequences, carriage returns or line feeds).

As someone who writes code, you probably know the vital importance of these characters. They allow you to format your code in a way that will make it easily readable by yourself and other people. In fact much of our source code is full of these white space characters (that is, unless you write obfuscated code). They’re most often used for breaking the code on multiple lines and indenting lines to represent the nesting of elements.

But, because these characters are important for people who read the code doesn’t mean they’re important for people who visit your web page. These formatting-only characters wouldn’t look too good if they did impact the layout of your page, right?

Let’s take a simple example:

<!DOCTYPE html>
    <h1>   Hello World! </h1>

This source code contains a line feed after the DOCTYPE and a bunch of space characters before and inside the h1 tag, but the browser doesn’t seem to care at all and just shows the words Hello World! as if these characters didn’t exist at all!

Unlike a word processing application, the browser seems to completely ignore white spaces (most of the time at least).

How does CSS process white spaces?

If most white space characters are ignored, not all of them are. In the previous example the space between Hello and World! still exists when the page is rendered in a browser. So there must be something in the browser engine that decides which white space characters are useful and which aren’t.

If you’re the kind of person who likes reading specifications, you might like the CSS Text Module Level 3 spec, and especially the parts about the CSS white-space property and white space processing details, but then again, if you’re that type of person, you’re probably not reading this article right now.

Let’s take another really simple example (to make it easy, I’ve illustrated all spaces with ◦, all tabs with ⇥ and all line breaks with ⏎):

<h1>◦◦◦Hello◦⏎
⇥⇥⇥⇥<span>◦World!</span>⇥◦◦</h1>

That’s how this example markup is rendered in a browser:

The h1 element contains only inline elements. In fact it contains a text node (consisting of some spaces, the word Hello and some tabs), an inline element (the span, which contains a space, and the word World!) and another text node (consisting only of tabs and spaces).

Because of this, it establishes what is called an inline formatting context. This is one of the possible layout rendering contexts that browser engines work with.

Inside this context, white space characters are processed as followed (this is overly simplified, the specification goes into much more details):

first, all spaces and tabs immediately before and after a line break are ignored so, if we take our example markup from before and apply this first rule, we get:

<h1>◦◦◦Hello⏎
<span>◦World!</span>⇥◦◦</h1>

then, all tab characters are handled as space characters, so the example becomes:

<h1>◦◦◦Hello⏎
<span>◦World!</span>◦◦◦</h1>

next, line breaks are converted to spaces:

<h1>◦◦◦Hello◦<span>◦World!</span>◦◦◦</h1>

then, any space immediately following another space (even across two separate inline elements) is ignored, so we end up with:

<h1>◦Hello◦<span>World!</span>◦</h1>

and finally, sequences of spaces at the beginning and end of a line are removed, so we finally get this:

<h1>Hello◦<span>World!</span></h1>

Which is why people visiting the web page will simply see the phrase Hello World! nicely written at the top of the page, rather than a weirdly indented Hello followed by an even more weirdly indented World! on the line below that.

In fact, using Firefox DevTools (since version 52 which now supports highlighting text nodes), you can see how the space separating the 2 words is part of the node that contains Hello just like the markup we ended up with after applying the white space processing rules:

<h1>Hello◦<span>World!</span></h1>

Now we know how white space is processed within an inline formatting context (which, remember, is basically an element that contains only inline elements).

You might be wondering how white space is processed in other types of contexts and what these contexts even are. Well, if an element contains at least one block element, then it establishes what is called a block formatting context!

Within this context, white space is treated very differently. Let’s take a look at this example (see live at https://captainbrosset.github.io/white-space-article/example3.html):

<body>⏎
⇥<div>◦◦Hello◦◦</div>⏎
⏎
◦◦◦<div>◦◦World!◦◦</div>◦◦⏎
</body>

We have 3 text nodes in there that contain only white spaces, one before the first div, one between the 2 divs, and one after the second div.

Browser engines may be optimizing this differently, but for the sake of understanding, I’ll go with the following explanation:

Because we’re inside a block formatting context, everything must be a block, so our 3 text nodes also become blocks, just like the 2 divs. Blocks occupy the full width available and are stacked on top of each other, which means that we end up with a layout composed of this list of blocks:

<block>⏎⇥</block>
<block>◦◦Hello◦◦</block>
<block>⏎◦◦◦</block>
<block>◦◦World!◦◦</block>
<block>◦◦⏎</block>

We can simplify it further by applying the processing rules for white space in inline formatting contexts:

<block></block>
<block>Hello</block>
<block></block>
<block>World!</block>
<block></block>

The 3 empty blocks we now have are just not going to occupy any space in the final layout, because they just don’t contain anything, so we’ll indeed end up positioning 2 blocks in the page only. And people viewing the web page will see the words Hello and then World! on 2 separate lines as you’d expect 2 divs to be laid out.

So in this case, the browser engine has essentially ignored all of the white space that was added in the source code.

Why don’t we see white spaces in devtools?

We’ve seen in the previous section how white space was often ignored when rendering the layout, but we’ve said that it still played a role in the DOM tree. Text nodes are still being created in the DOM tree of the page, so the following code:

<body>⏎
⇥<div>◦◦Hello◦◦</div>⏎
⏎
◦◦◦<div>◦◦World!◦◦</div>◦◦⏎
</body>

still generates the following tree:

element node: <body>
 ∟ text node: ⏎⇥
 ∟ element node: div
    ∟ text node: ◦◦Hello◦◦
 ∟ text node: ⏎⏎◦◦◦
 ∟ element node: div
    ∟ text node: ◦◦World!◦◦
 ∟ text node: ◦◦⏎

And the primary job of any inspector panel in any devtools out there is to display the DOM tree, but if you try for yourself, you’ll see that these text nodes are just not there.

The reason being that if the browser engine ignores these white space only text nodes when creating the layout, then it’s probably safe for devtools to ignore them too. After all, authors only use them for formatting, and visitors don’t see them. So there’s no real need for devtools to show them.

Now, there are in fact cases where showing white space text nodes in devtools could be useful. The following sections will describe what they are.

Spaces between inline and inline-block elements

In fact, we’ve seen this already with the very first example in this article, when we described how white space was processed inside inline formatting contexts.

We said that there were rules to ignore most characters but that certain spaces staid in order to, basically, separate words.

So, when you’re actually dealing with text only, paragraphs that may contain inline elements such as em, strong, span, etc. you don’t normally care about this because the extra white spaces that do make it to the layout are actually helpful to separate the words.

But it gets more interesting when you start using inline-block elements. These elements appear as inline elements from the outside, but behave like blocks on the inside, so they are very often used to display more complex pieces of UI than just text side by side on the same line (just like if you floated blocks).

I think the expectation from web developers is that because they are blocks, they will behave as such, and just stack side by side (rather than on top of each other), but really they don’t. If there is formatting white space in the markup between them, then that will create space in the layout just like between text.

Consider this example:

<style>
  .people-list {
    list-style-type: none;
    margin: 0;
    padding: 0;
  }
  .people-list li {
    display: inline-block;
    width: 2em;
    height: 2em;
    background: #f06;
    border: 1px solid;
  }
</style>

<ul class="people-list">⏎
                        
◦◦<li></li>⏎
                        
◦◦<li></li>⏎
                        
◦◦<li></li>⏎
                        
◦◦<li></li>⏎
                        
◦◦<li></li>⏎
                        
</ul>

If you open this in a browser, you’ll see the following result:

Which is most probably not what you intended. Let’s assume this is a list of people’s avatars and you wanted them displayed like this instead:

Well, this is a very common CSS layout problem and questions and articles have been written about this. There exist solutions, things like getting rid of the white space altogether, setting your font-size to 0, or using negative margin, etc.

What is interesting here isn’t really the solution to this common problem, but the fact that this is a common problem at all, and that many web developers have spent at least a little bit of time confronted to. Suddenly white space does show up in your layout in a way you didn’t expect and it may take you a while to figure out the problem.

Because the corresponding text nodes aren’t in devtools, people loose time on this common problem if they haven’t faced it before. They’ll check if there is margin somewhere but won’t find any.

So that’s one example of when showing white space text nodes in devtools would actually be useful. Let’s see another one.

Controlling white space rendering

Using the CSS white-space property, you can control how white space characters are processed when a given inline formatting context is laid out.

css-tricks.com has a nice article about this property.

The important thing is that if you set this property to pre, pre-wrap or pre-line, this will actually honor some or all of the white space character in the source HTML code, and they will start taking space in the layout.

If we take a simple example from earlier:

<h1>◦◦◦Hello◦⏎
⇥⇥⇥⇥<span>◦World!</span>⇥◦◦</h1>

But add the following CSS rule:

h1 { white-space: pre; }

We then end up with the following layout:

Using Firefox DevTools to highlight text nodes, you can see exactly what space is occupied by the “Hello” text node. See live at https://captainbrosset.github.io/white-space-article/example5.html.

As you can see above, the layout inside the h1 element respects the formatting of the source HTML file. There is some space before the word Hello, then a line break, then more space and the word World!.

In fact, as you can see, the first node shown in devtools inside the h1 element is a text node and hovering over it does highlight the space taken by that node in the page.

Hovering over the span element also highlights the space taken in the page, and in particular, you can see the space before the word World! coming from:

<span>◦World!</span>

Therefore, that’s a second reason why devtools should show white space text nodes. Indeed, someone trying to understand the layout and not knowing about the white-space property may be confused.

Firefox DevTools to the rescue!

Starting with version 52 of Firefox, the inspector panel shows white space text nodes when they do have an impact on the layout and also highlights them in the page.

How does the inspector know when a node impacts the layout? It simply checks if that white space text node has a size. When a text node is ignored, it’ll have a width and height of 0, but when it participate in the layout, it’ll have some dimension. So, using this simple heuristic, Firefox DevTools can show the white space text nodes that are important.

As you can see above, the white space text nodes that do have a size in the page are now shown in the inspector panel and, if you hover over them, they are also highlighted in the page so you know exactly where they are and how big they are.

This way, if you were originally confused about why the avatars in the page didn’t sit next to each other, it will now be very obvious why that is. No more loosing time looking for margins that aren’t there or crafting the right google search query that will give you the answer.

In fact, you can even remove these text nodes and see that the inline-block elements are now displayed exactly as you wanted them to.

Firefox 52 is now available as a Nightly build, so go ahead and grab it and take it for a spin.

Hopefully this new feature and this article have been helpful, thanks for reading!

Visualize animations easing in DevTools

2016-11-28T00:00:00Z

Read the full article at https://hacks.mozilla.org/2016/11/visualize-animations-easing-in-devtools/

Firebug lives on in Firefox DevTools

2016-12-20T00:00:00Z

Read the full article at https://hacks.mozilla.org/2016/12/firebug-lives-on-in-firefox-devtools/

DevTools: What you need to know

2017-01-31T00:00:00Z

Read the full article at https://hacks.mozilla.org/2017/01/devtools-what-you-need-to-know/

Where is DevTools headed?

2017-02-01T00:00:00Z

Lately I've been thinking more about the future strategy for Firefox DevTools, and so I decided to write this article. Hopefully you find it inspirational, and motivating.

Using standard web technologies only

Browser devtools have historically always been part of browsers' user interfaces and, as such, are desktop applications, not web applications. Now, if you look under the hood at Chrome or Firefox, you'll find that they actually are rather close to how web applications are built. Sure, they use some special APIs or languages, but their user interfaces make use of markup, CSS, and JavaScript.

Firefox DevTools is still making use of XUL markup in some places (instead of HTML), and special privileged javascript APIs or Firefox-only CSS features that haven't yet become available to web sites.

At Mozilla, we're in the process of changing this. We are aiming at only using standard and cross-browser HTML, CSS and JS. In particular, our new debugger is already just web, our inspector doens't have XUL anymore, and our console and network monitor are in the process of being converted too.

We're building tools for web developers, we need to be web developers ourselves, not Firefox developers only. We therefore need to be confronted to the same problems, and use the same technologies.

Additionally, standard web technologies allow us to run the tools anywhere the web is supported. That means, being able to run the tools in any browser, therefore turning DevTools into just a web site.

This opens up the door to so many potential ideas: our tools could run in standalone electron-based applications, or be embedded in code editors, or run as web extensions in other browsers, or even be hosted on a web server so they can benefit from the web shipping model. Additionally, Mozilla's research browser: Servo, does not support XUL or privileged JS, so if we want DevTools to be able to debug pages in Servo, this is needed. Finally, using non-standard technologies makes it harder for web developers to contribute to DevTools.

Shipping and experimenting better/faster

Browsers have a rather long release cycle. Mozilla Firefox for instance ships every 6 weeks and has 4 channels. So when an engineer adds a feature, it lands on the Nightly channel and will stay there for 6 weeks (or less depending on when during the cycle they land it). Nightly then merges into Aurora and the code stays there for another 6 weeks so it can get more testing. After that comes the Beta channel, itself also 6 weeks. If everything goes fine and the feature was not removed at any stage of the way, it ends up in our release channel and becomes available to all our users. Other browser vendors have similar release processes.

Today, DevTools is part of the browser. So it follows the same release cadence.

However, we know that the majority of our users use the Firefox release channel. This means if one of those release users runs into a bug with our tools it will take more than 4 months for us to ship that fix (assuming we actually identify and fix the problem immediately).

So we want to ship things faster. Make it possible for important fixes to make it to our release users as fast as possible. And experimenting with new features faster too.

Speed is not the only factor here. If we take the example of the web console panel for instance. We want to be able to ship new experimental console features to the users out there who actually care about and use the console. We have systems in place that gather usage statistics, we should make use of them more intelligently in order to drive how our new features are getting enabled.

Right now, we ship our new things to pre-release channels (nightly, aurora, beta), but we have very few users there. And the ones we do have are not necessarily heavy console users. So if we ship a new console feature enabled by default only on these pre-release channels for a bit, we can't really get much feedback, and we have no way of knowing if we can trust it.

We have to wait until release for people to find out the new console feature and potentially not like it. By this time, it's too late for us to address the problem quickly. The incremental changes we will make then will have to follow the usual release cycle.

So DevTools features should ship quickly, and target users who actually need them, and be generally available behind some kind of experimental flag for a while, until they stabilise and we gather enough feedback.

Going out of the central browser code repository

I think we need people to hack on devtools more than ever. It needs to be easy, a lot easier than it is now. DevTools is for web developers. They are the ones who need it, they have the ideas for it, they report the bugs, they should have the means to fix/enhance DevTools on their own.

Asking them to clone a huge browser repository and build the whole browser is too much, this isn't what web developers are used to.

For instance, Firefox lives in the mozilla-central mercurial (or Git) repository. It is several gigabytes big, and takes a long while to build.

We've made several improvements to this, artifact builds take seconds/minutes instead of hours because you don't build the C++, or you can just download Firefox nightly and use our addon-based development workflow. But still, we'll be making more changes to this in the future.

Contributors should have access to an enjoyable and familiar development environment. The DevTools project should be part of the current web ecosystem. We provide the tools for it, but we're not even part of it, or use it all that much. This needs to change, big time.

Moving to GitHub seems like the right choice for this. Obviously, it's not as simple as moving code from one repo to the other. There are many questions associated with it, and we're allowing experimentation time right now to figure this out.

Having said this, we already have some really strong evidence of the benefits of GitHub. Our new debugger is a very popular project. It's not just a bet, it actually works really well. Now, imagine moving the inspector to GitHub! The debugger is really great, but way more people use an inspector than a debugger, so this is bound to generate even more excitement.

Debug anything

Web developers don't just run their code in one browser, and they write code for both server and client. Right now, they need to learn multiple tools and switch between them often (or they don't, and web compatibility suffers).

They need a cross-browser testing and development environment. We can give it to them, we can work out the differences between debugging protocols, and we can provide single tools that they can use to target anything: NodeJS, Firefox, Chrome, Safari on iPhone, Edge, tomorrow things like Servo, etc.

If you care for the web, doing this makes sense. DevTools are for developers, not for browsers, they should help developers get the work done, not be completely different from one browser to the other just because they decided to invest in different things.

Now, that doesn't necessarily mean that there shouldn't be any differences between browser DevTools either. Browsers do invest in different things and are best at implementing different web APIs and features. And they can, in turn, make these great features available for debugging to Devtools. After all, DevTools is just an app that connects to a debugging target that might expose different things. Firefox may have a really cool CSS layout tool, while Chrome may have better service-worker debugging. There just happens to be common tooling that can target both.

Conclusion: an independent product

What I've described so far is nothing else than a web-based standalone product.

And this is how I think of DevTools now, as its own product. At least that is the long term vision for it. It doesn't mean that we should start creating a product right now, stop everything and do this. It just means that if everything we do brings us a little closer to that vision, step by step, then we'll be in a great position in the future. A position that allows us to do more than we do today, faster and better, and be much more of an ally for the web development community.

We need tools that web developers can enhance, reuse, customize, embed, and more. We should be web developers building a web app for web developers.

A quick history of Firefox DevTools

2017-04-05T00:00:00Z

Read the full article at https://medium.com/mozilla-tech/a-quick-history-of-firefox-devtools-620d3074b510

Demystifying CSS alignment

2018-01-11T00:00:00Z

Aligning things in CSS has been a common source of frustration, fun and even memes for a long time. However CSS evolves quickly and new specifications are written and implemented in browsers all the time. As a result, aligning things in CSS today isn’t quite what it used to be. We now have to take more modern ways to do CSS layout into account, like Flexbox and Grid among other things.

In this post, I’d like to talk about alignment a little bit. What it means in Flexbox and Grid and how to think about it more generally too, so you can be equipped for the future, when aligning in Blocks, Multi-Columns, Tables, Grids and Flexbox all works the same.

Note: if you’ve read this already and all you want is a quick access to my cheatsheet, click here.

The context

The context here is essentially the W3C specification called CSS Box Alignment. And within that spec, the justify-content, justify-items, justify-self and align-content, align-items, align-self properties.

I’ve been reading this spec over the past few days, and I thought I’d write about it. (On that note, reading specs and trying to explain them to people is a really good exercise you can try if you want to make sense of CSS and really understand what's going on rather than trying stuff out until they work).

Justify or align?

You probably have come across these names if you have used Flexbox before. Indeed, they are the first part of CSS property names like justify-content and align-items.

If you’re like me, you’ve visited css-tricks’ Flexbox guide many times and now remember things like justify-content:center; align-items:center; by heart because they do cool things (like, in that case, center elements).

But you might not know which direction justify and align apply in.

Two directions

First, let’s learn about the two directions of a web page. You should keep it in your mind that there are two, perpendicular, axes on your page, and that content runs along them (I'm ignoring the Z axis here which z-index can be used for).

Reading Jen Simmons’ Writing-Modes article on that topic will help you a lot.

One of the axes is the inline axis, it's the one each line of text runs on. By default on a web page, if you don't specify any writing-mode, this axis is horizontal, from left to right.
The other one is the block axis and it’s the one along which blocks are stacked. Again, by default, this axis is vertical, from top to bottom.

Remembering which direction is justify and which is align

If at any point in your life you’ve used a text processing application (like Microsoft Word), you are already equipped to remember this.

Indeed, these applications almost always have a button to justify text on a line. What it does is distribute words along a line. Therefore, justify works along the inline axis. That's the trick I now use to remember this (thank you Chen Hui Jing for explaining it this way to me a few weeks ago).

And by a very elaborate process of elimination, align works along the block axis.

So, if you know which way is inline, and which way is block, then you know where justify and align apply.

(Note: if you use flex-direction:column in a Flexbox container, then this isn’t true anymore, the inline and block still point in the same direction they did before, but align and justify now don’t work along these directions. But for the sake of simplicity in this article, let’s ignore this for now).

Content, self or items?

Now we've only looked at the justify and align parts of the CSS properties that interest us here. Let's look at the rest of these property names.

Taking the justify-content:center; align-items:center; example again, you now know which direction justify and align correspond to, but you might be confused as to why one property ends with content and the other with items.

To explain why that is, we need to first understand a general concept about alignment.

Containers and subjects

This is a generic way of thinking about alignment that will apply to any layout where these properties can be used. It's very useful to understand this without necessarily only thinking about Flexbox. This way you gain a better understanding of how things are defined holistically and you can apply this knowledge to other layouts in the future.

A container is a rectangle within which a subject is being aligned.
And a subject is the thing (or things) that is (are) being aligned within the container.

Pretty simple, right? Now, how do these correspond to content, items and self?

Content

When you see content in the property name, then that means this property applies to an alignment container. It defines how subjects are aligned or distributed within this container.

The spec calls this content distribution.

So, in a way, it's a bit like setting the padding on an element. It applies to the element itself and ends up aligning the content within this element.

Self

If, instead you see self in the property name, then that means it applies to a subject instead. It defines how this particular subject is aligned within its container.

The spec calls this self-alignment.

In a way, you can think of it as margin, because it applies to an element but aligns it within its container.

Items

And finally, the properties ending with the items word are a special case. They apply to containers like content does, but doesn't impact them at all. Instead, this is a way to set the default value of self for all subjects within a container in one go.

So, this is self-alignment too, but the property just goes on the container instead of the subject, and sets the default self-alignment of all the subjects inside this container.

Example

So far, this has been a lot of theory and may be hard to reason about. So let's look at one example, and then in the next section we'll dive into more details with different types of CSS layouts.

Let's go back one more time to our common Flexbox centering example:

justify-content:center; align-items:center;

What you learned so far should make it possible for you to make sense of these two CSS declarations now. Let's decompose them below:

justify-content:center;

content means content distribution. This applies to a container which, in the case of Flexbox would be the Flexbox element container itself (e.g. the <div> with display:flex),
justify works along the inline axis (so, horizontally by default),
finally the value is center.

So, as a conclusion, this piece of CSS means we're centering content within this Flexbox container along the inline axis. In this case, the content we're centering is the various Flexbox items themselves.

This is defined in the spec and we'll look at it in the next section. For each axis and for each layout type, the spec tells us what is the alignment container and what are the alignment subjects. Here, the subjects are the Flexbox items.

align-items:center;

items means self-alignment, right? But if you remember from before, it is a special part of the property that really applies to subjects, even if it is set on the container,
align works along the block axis (vertically by default),
and the alignment value is center.

As a conclusion, this piece of CSS means set the default self alignment of all items inside this container to be centered along the block axis

Now, you might be thinking align-content:center; should do the same as align-items:center; right? I thought that too, but reading the spec provided a reason for why that is not the case in this simple example.

It comes down to knowing what is the alignment container and subject you are currently dealing with. And that's exactly what I'll be focusing on in the next section.

Flexbox alignment

Let's start with Flexbox since we've talked about it already. We'll go over the 2 types of alignment: content distribution and self-alignment.

Content distribution (justify/align-content)

Along the inline axis (justify-content), things are quite simple. The alignment container is the Flexbox container. And alignment subjects are the Flexbox items. So, justify-content can be used on the Flexbox container to align its items along its inline axis, as shown below:

Along the block axis (align-content), things get a bit more complicated. In this case, the alignment container is still the Flexbox container, but the alignment subject is something called the Flexbox line. Let’s explain this a bit:

In a lot of cases, Flexbox is used with all items being on just one line. But sometimes wrapping happens, and in those cases it’s important to realise that items on each lines are wrapped into a Flexbox line. This is a thing that contains items, is as tall (or wide) as the tallest (or widest) of them, and that can be aligned within the container. So, in the case of align-content, we’re aligning Flexbox lines within a Flexbox container as shown below:

This explains why align-content doesn't work in the case where a Flexbox container only has one line. When it does, that line has the same size as the container, so aligning it anywhere has no visible effect.

Self-alignment (justify/align-self)

In Flexbox, self-alignment can only be used on the block axis. Indeed, justify-self can't be used to align one item, because there might be other items on the same line.

Along the block axis however, align-self can be used to align a given item. In this case, the alignment container is the Flexbox line that the item current is in, and the alignment subject is the item itself.

Grid alignment

Content distribution (justify/align-content)

Content distribution, if you remember correctly, is a thing you do on a container to distribute/align subjects within itself.

Well, in the case of content distribution in a Grid layout, the container is the Grid container itself (the element with display:grid on), and subjects are tracks (the columns and rows). In this case we're controlling where space goes between rows or columns, just like grid gaps would.

So, justify-content controls the space along the inline axis, between column tracks, and align-content controls the space along the block axis, between row tracks, as illustrated below:

Note that content distribution might not always be possible in a grid. For instance, if the rows are defined in a way that they cover the whole grid height, then there is no space in between those rows to be distributed.

For instance, grid-template-rows: repeat(2, 1fr); will make the 2 rows take an equal share of the available height, until no space is left.

Self-alignment (justify/align-self)

Self-alignment, on the other hand, is the act of determining where inside a container a given subject is aligned.

In the case of CSS Grids, subjects are Grid items themselves (the children of the display:grid container), and containers are defined as grid areas.

What that means depends on where the item currently is. If the item is positioned in a grid cell, then that grid cell is the alignment container. If the item is placed in a grid area, then that grid area is the alignment container.

This works the same on both axis, so justify-self and align-self are easy to reason about in a CSS Grid: it simply allows you to align an item within its cell or area along both axis, like illustrated below:

Multi-column alignment

If you don't know what CSS multi-column is or haven't used it yet, I recommended heading over to the "Using Multi-column layouts" MDN page for more information.

Essentially, it's a set of CSS properties that together allow to break a block layout into several columns so that text (and other sub elements) can flow through them like newspaper or magazine articles often do.

Although I'm not aware of browsers out there supporting the justify/align-content/self/items properties in multi-column layout yet, the spec defines these properties for this type of layout too.

As I said earlier, it's useful to think of these properties globally across all sorts of layouts, because it makes it easier to reason about them. And at some stage in the future, these alignment properties will start to work for multi-column layouts too.

Content distribution (justify/align-content)

When distributing content in a multi-col layout, the alignment container is the block element that has the columns, and subjects are the columns themselves.

Along the inline axis (justify-content), what happens is a bit similar to Grid layout. The property controls spacing between columns (just like it controls spacing between column tracks in a Grid layout).

Along the block axis (align-content), the alignment container and subject are the same than before. The property becomes useful when not all columns have the same height. Indeed, there may not be enough content to fill up all columns to the same height. So align-content can be used to align the column boxes inside the column container along the block axis like so:

Self-alignment (justify/align-self)

Self-alignment doesn't apply to multi-column layouts.

Indeed, self-alignment is something that applies to alignment subjects, where those subjects are actual elements in the page that justify/align-self can be applied on. There's nothing like this in a multi-column layout. The column boxes themselves can't be styled with these properties individually.

Block alignment

So far we've talked about rather advanced layout types, but the spec also defines how alignment works in simple blocks (really just any element with display:block; on it).

Note that there's no browsers out there that allow block alignment this way yet. But implementations will come at some stage.

Content distribution (justify/align-content)

With this type of layout, the alignment container is the block element itself, and the alignment subject is the entire content of the block, as one unit.

It's very easy to think of this as setting the padding on the block element. Except here, we're using the align-content property instead, in the same consistent way we've done it with other layout types too.

The spec however says that justify-content doesn’t work in this case.

Self-alignment (justify/align-self)

Along the inline axis (justify-self), self-alignment happens between the subject: a block, and its container: another block.

Like before, this is very similar to setting the margin on the subject:

Along the block axis however (align-self), this has no effect. Indeed, there can be more than one block along this axis, and it is therefore not possible to align one differently than the others.

Conclusion

Well, there we go, I hope this was a useful and not too boring read.

I really hope I accomplished my goal of making it easier for you to reason about these various CSS properties. I know writing this article and reading the spec really did it for me, I can now center, distribute and align things in Grid and Flexbox very easily without trying random things until it works. Now, my code works the first time.

I created a cheatsheet that contains all of the diagrams above in a small and more easily usable format. So go check it out!

Thanks for reading. Bye for now.

CSS Grid + CSS Multi-Columns = ♥

2018-01-15T00:00:00Z

In this short article, I am exploring the relationship between two CSS layout features: CSS Grid and CSS Multi-Columns.

These two features can be used together in very interesting ways for building responsive web designs.

Let’s start by reviewing what each of those features do.

CSS columns

CSS has had the ability to organize content into columns for a while now and support is really good all across the board (apart from the need to use vendor prefixes still).

The main use case for CSS columns is to break long sections of text into several columns in order to avoid lines from being too long and therefore hard too read.

The great thing about CSS columns is that the columns are defined with CSS only, and they don’t require any additional markup. Content just flows from one column to the next naturally and automatically depending on the currently available width.

For instance, you can define a really simple multi-column layout by using the CSS property column-width: 150px; and the browser will just add as many columns as it needs to fill the available space:

CSS Grids

CSS Grids is this awesome new CSS layout system that allows web authors to organize items on a 2D grid very easily.

If you haven’t heard about it at some point during this past year, you have probably been living under a rock. The sheer amount of articles, documentation, videos and talks has ben phenomenal, and it’s been really hard to miss.

Check out Jen Simmons’ website, Rachel Andrew’s website, or Mozilla’s Grid Playground to learn all about grids.

Columns + Grids = ♥

Let’s start by creating a simple grid layout that positions a series of labels and their input fields next to each other, in 2 columns:

<style>
.grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  grid-auto-rows: 2em;
  grid-gap: .5em;
}
</style>
<div class="grid">
  <label>label</label>
  <input type="text">
  <label>label</label>
  <input type="text">
  <label>label</label>
  <input type="text">
  ...
</div>

The CSS above creates 2 equally sized columns which all of the items are going to flow through as shown below:

Now, here comes the interesting part: you can actually put a grid in a column layout! And it’s pretty amazing.

Basically, grid supports fragmentation, which means that a grid will also flow into a multiple columns layout. It will become fragmented as needed, with one fragment per column. These fragments are just parts of the same grid.

So, with the simple grid-based form example from before, let’s see what happens if we put it inside a multi-column layout with column-width: 150px:

See how, as space becomes available, the grid gets fragmented to occupy the available columns.

Here’s what the entire code could look like:

<style>
.columns {
  column-width: 200px;
  max-width: 800px;
  margin: 0 auto;
}
.grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  grid-auto-rows: 2em;
  grid-gap: .5em;
}
</style>
<div class="grid">
  <label>label</label>
  <input type="text">
  <label>label</label>
  <input type="text">
  <label>label</label>
  <input type="text">
  ...
</div>

One of the nice things about this is all the content is in the same grid, even when the grid is broken down into multiple fragments. So, the size of the grid columns, for instance, will always be the same across fragments.

Fragmenting padding and border too

If you wanted, for some reason, to add some borders and padding to the grid itself, then something like this would happen:

Indeed, the element the grid is applied to is being fragmented into the multi-column container, but there’s still only one top and one bottom sides to it. So the bottom-border only applies to the bottom side of the grid element for example.

Obviously that doesn’t look so good. Fortunately, CSS provides a way to solve this too: box-decoration-break. This CSS property can be used to define how things like background, borders, margins and paddings work in fragmentation cases (or in cases like an inline element wrapping on several lines of text).

Using box-decoration-break: clone; we get the effect we want:

That’s it! You can play with the complete example here on codepen, it also includes some fun little CSS counters which I used to number the labels via CSS only.

Happy coding, bye for now.

When CSS doesn't do anything

2020-03-09T00:00:00Z

Read the full article at https://blog.logrocket.com/when-css-doesnt-do-anything/

My career at Mozilla

2020-03-18T00:00:00Z

Over the past 6,5 years, while working at Mozilla, I was involved in a lot of different projects related to Firefox DevTools.

During that time, a lot happened, and so much of it was really amazing to be a part of. I had a lot of fun, met so many wonderful people who shared my passion for web tooling.

My career in numbers

I filed more than 1100 new bugs on bugzilla.
I commented 15000 times over 5400 different bugs.
I fixed almost 500 bugs.
I reviewed about 1800 commits that landed in the mozilla-central repository.

My different roles

I started as a software engineer, moved on to become one of the leads for the Inspector part, and then the DevTools module owner (in Mozilla linguo, this means the technical decision maker for the entire DevTools codebase). I finally ended up as an engineering manager for a few years.

I have been involved in pretty much all of the phases that make up the product engineering lifecycle and I have learned so much from each of them. I implemented new features, fixed bugs, fixed tests, worked with other engineers, ideated on new user features, ran user tets, built prototypes, communicated with designers, QA, management, product managers, and managed amazing engineers.

The things I helped build

The list below is, by no means, a list of the things I, personally, implemented. I did do some of them myself, but for a large part, they were team efforts, and I only contributed to them in some way or other (managing the team, reviewing patches, etc.). This list is also not complete. A lot of the work that happened (and this is true for any codebase) was hidden: fixing tests, fixing bugs, cleaning things up, etc.

A bunch of smaller features

Color picker for CSS
<img>, <canvas> and CSS background-image preview on hover (in Rules, Computed and DOM)
.cls panel in the Rules sidebar to edit classes
Flashing of elements in the DOM when mutations occur
Ability to highlight all elements matched by CSS selectors in the Rules sidebar
Displaying whitespace text nodes when they impact layout (more about this here)
Highlighter for text nodes
Copy images as data-uri strings
Copy various css paths and xpath for elements
Highlight DOM nodes from properties in the Console and Debugger panels
Expand all nodes in Inspector with alt+click
Display non-rendered nodes differently in Inspector
Make URLs clickable in Inspector
Highlight the corresponding box-model region in the page on hover of Box-Model panel
Button to insert new DOM nodes
Paused debugger page overlay
Display offset parents for positioned elements in Box-Model panel
Reveal font usage on the page on hover in the Fonts sidebar
New scroll badge in Inspector to find elements with overflows

The bigger features

New cross-browser Compatibility sidebar to show all compat issues on the page
Wysiwyg editor for positioned nodes
Tooltip to edit CSS filters
Tooltip to edit animation cubic-bezier timing functions
Grid Inspector
Flexbox Inspector
Fonts Editor
Shapes Path Editor
CSS Changes sidebar
Inactive CSS
CSS Transform visualizer
3-pane layout
Animation Inspector
First version of the Performance monitoring panel
RDM handling
Accessibility Inspector panel
Valence, a protocol adapter to debug Chrome and Safari from Firefox DevTools

3 things about CSS variables you might not know

2020-09-21T00:00:00Z

CSS variables (or custom properties, depending on how you prefer to call them) are really cool, and chances are, you're already using them in your projects.

In this article, I'll talk about 3 things that I think a lot of people might now know about:

what happens when a var() function uses an undefined variable,
how fallback values work,
and how browser DevTools can help you.

Undefined variables

There are several reasons why you may be trying to use an undefined variable in a var() function. We'll look at a few in a minute. But before we do that, it's important to know that when this happens, CSS falls back on its feet.
CSS and HTML are super resilient languages where mistakes are forgiven and one tiny error doesn't prevent the entire page from rendering.

So, using an undefined variable won't lead to a parsing error, it won't prevent your stylesheet to load or parse or render. In fact, you might not even realize that something went wrong without a lot of investigation.

Some of the reasons using an undefined variable might happen are:

you've simply made a typo in the name of the variable,
you're trying to use a variable you thought existed, but doesn't,
or you're trying to use a totally valid variable, but it happens to not be visible where you want to use it.

Let's go over that last example.

Variables participate in the cascade. This means, for a variable to be available to a var() function, that variable needs to be declared in a rule that also applies to the element being styled, or to one of its ancestors.

For the sake of giving an example, let's look at this:

ol li { --foo: red; }
ul li { color: var(--foo); }

Of course your particular case will likely be more complicated than this, with many more rules and much more complicated selectors. But what happens here is that for ul li elements to have the color red, they would also need to match the rule ol li where that color is actually defined. And that will probably not happen.

Now, in many cases, CSS variables tend to get defined in some top-level selector like :root or html and are therefore available throughout the DOM tree (those selectors match ancestor elements of all other elements in the page).
In this case, the problem of a missing variable almost never occurs.

However sometimes it's handy to declare variables in other places and when you do this, you've got to start paying more attention to whether your variable will actually be visible (via the cascade) to where you intend to use it.

So, with this out of the way, let's see how browsers deal with undefined variables:

If the property is not inheritable (like border), then the property is set to its initial value.
If it is inheritable (like color), then the property is set to its inherited value. If there isn't any, then it is set to its initial value.

Let's look at 2 examples to illustrate this:

:root {
    --main-color: #f06;
}

.my-lovely-component {
    border: 1px solid var(--main-colo);
}

In this first example above, a typo was made in var(-main-colo) and as a result the browser cannot tell what the final value for the border property should be. Because the border property is not inheritable in CSS, the browser finds itself in case 1 from above. It therefore sets the value to its initial state which happens to be medium none currentColor (see the initial value on MDN).
So, even if only the color part of the border was missing, the border will be missing entirely.

Let's look at a second example now.

:root {
    --main-color: #f06;
}

body {
    color: gold;
}

.my-lovely-component {
    color: var(--secondary-color);
}

In this one, an undefined variable was used in .my-lovely-component for the value of color.
Now, because this property is inherited, the browser will traverse the DOM up through the element's ancestors until it finds one that does define a color value. The <body> element has a rule applied to it that specifies gold as a value, so that's what will end up being used.

In both of these examples, the hard part is figuring out what's happening exactly. In the last part of this article, I'll explain how DevTools can help, but without specific tooling here, it would be really hard to understand the problem.

The source of it is that, even if those var() functions use invalid properties, when the browser parses the stylesheet, it has no way of knowing this. As far as it's concerned, those border and color properties are totally valid. So we're left with wondering why the border is missing in the first example, and why the color is black in the second.

Property names or values are only considered invalid by the style engine in a browser when those are not known. But since a var() function can resolve to pretty much anything at all, the style engine doesn't know whether the value containing the function is known or not.
It will only know when the property actually gets used, at which point, it will fall back to an inherited or initial state silently, and leave you wondering what happened.

Thankfully, we'll see later in this article how some new DevTools can help with this.

Fallback values and nesting

Here is another thing about CSS variables that doesn't seem to get used a lot, and therefore is probably not very well known either: var() functions accept a second, optional, parameter.
So you can write something like this:

color: var(--theme-color, red);

What happens in this case is: if --theme-color is not found by the browser, it will fall back to using the value red.

Now, why would you use this? I can see a few reasons why this could be interesting:

It might come in handy if you're creating a component that gets embedded into a bigger system and can be customized with variables, but you still want some safe defaults.
Or maybe you're styling an element that has several states, with the default state using a var() with fallback value, and the other state defining the variable.

Let me give an example to clarify that second case:

.my-component {
    color: var(--active-color, black);
}
.my-component:hover {
    --active-color: red;
}

In this example, while the element isn't being hovered, its color property uses an undefined variable (indeed, the --active-color property does not apply to the element yet), so the browser uses the fallback value. As soon as the user hovers over the element, the second rule starts to apply, and --active-color becomes defined, so the element switches to red.

Of course, this is a dummy example, and you could simply have defined color: red in the second rule and let it override the first one. But sometimes you need to use the variable in several properties at once.

Now, let's look at a second weird thing that happens with fallback values: nesting var() functions.

Have you ever seen something like this:

color: var(--foo, var(--bar, var(--baz, var(--are, var(--you, var(--crazy)))));

This is totally valid, but probably completely useless.
What's happening here is that the fallback value is, itself, another var() function. And because it is, it (in turn) can also use a fallback value, and so on...

To be honest, I don't think I've seen var() functions used as fallback values very often, if at all. Fallback values themselves are probably rarely used to begin with.
But at least you know this is possible, and hopefully won't be surprised if you ever see this.

Let me conclude on fallback values by looking at a third aspect which I think is rarely known and may lead to confusion: using commas.

A CSS variable is, basically, any text you want. Because a variable can be used anywhere a value would go, it doesn't have any strong typing at all, and therefore the only important rule is that it shouldn't contain a semicolon, since that signifies the end of the value (in reality, it's more complicated than this).

As a result, something like this is valid:

--my-variable: one, two, three;

The interesting thing here is that fallback values also follow the same rule in that they can be any text you want. So the above example could also be used as a fallback value:

content: var(--foo, one, two, three);

Even though it really looks like the one, two, three part is three different parameters to the var() function, it's really just one. Don't get confused by that.

DevTools tips and tricks

In this last section I'll go over some of the DevTools around CSS variables that you might now know about and which should make your life easier.

Autocompleting variable names

This one is super useful when doing some quick changes in the Elements/Inspector panel and your site defines a lot of different variables:
DevTools will automatically suggest the list of existing variables when you start typing var(.

The above screenshot is in Firefox, but both Edge and Chrome also support this feature.

Knowing what the computed value is

When looking at a var() function in DevTools, it's not necessarily easy to know what final value it computes to. The variable it uses may be lost in a really long list of rules, or it may itself point to another variable, making the hunt for the final value more difficult.

You can switch to the Computed tab in DevTools to see what the final computed value of the entire property is. But if you want to know what the computed value for just that var() function is, you can simply hover over it in DevTools:

The above screenshot is in Edge, but the same thing happens in Chrome and Firefox too.

Interestingly, if no tooltip appears, then that's a good clue that the variable used is undefined.

Color types

A little earlier, I said that variables accepted any text at all, because when they're defined, variables don't really have a type yet.

A consequence of this is that what looks like a color may actually not be used as a color.
Consider the following example:

:root {
    --i-look-like-a-color: black;
}

Even thought black is a valid color, at this point, we can't assume that it will actually be used as one. It may end up being used in a animation-name property, or somewhere else.

That said, DevTools still show a little color swatch next to css variables that look like colors. That is done as a convenience, because they are very likely to actually be colors! And even if they aren't, it's not going to be a problem for users.

Future features

Now, 2 things that, I think, would be super useful but don't exist yet is:

jumping from a var() function to where the variable used in it is declared,
quickly seeing that a var() function uses an undefined variable.

As it turns out, I'm working on exactly that right now in the DevTools for Chromium-based Edge and Chrome! You can check out the bug entry to follow along if you want.

Hopefully this article has been useful and you learnt a few things! Happy coding!

A few web console tricks

2020-12-22T00:00:00Z

The console panel in your favorite browser's DevTools can be a very powerful ally when troubleshooting problems in a web app. Log data, send requests, manipulate DOM elements, you name it, the console can do it all!

There are so many ways to get interesting information out of the console, and I know I use only a few of them. So I asked around for what made people more productive in this tool, and I'm sharing the results with everyone here.

Note that there are many resources online already about tips and tricks with devtools, but I hope this one will prove useful to you because:

rather than being a complete and overwhelming reference to all the features, it's a small subset of the things some people agreed were the most useful to them, and
it's not just a list of the built-in commands, but also some code snippets that you may find useful.

$ and friends

$ and its friends are probably the most used tricks in the console. It pays off to know some of them as they can really help you get more out the tools.

$() is a function that's essentially a shortcut to the longer document.querySelector() native function. It's nice and short, and for those of you who worked with jQuery in the past, it will feel familiar.

$$() acts as a shortcut to document.querySelectorAll() but returns an array of nodes rather than a NodeList which means you can use things like map() or filter() right away on the returned list of elements.

I often use it to retrieve all elements on the current page and then filter it depending on what I'm looking for:

$$('*').filter(n => getComputedStyle(n).display.endsWith('flex'));

In this example, you'd end up with the list of all of the elements on the page that are Flexbox containers. Pretty handy right!

$0 is a super useful reference to the element that's currently selected in the Elements panel (in Edge or Chrome) or Inspector panel (in Firefox). If you want to know things about the element that aren't available to you in one of the other tools, then $0 is your friend.

$_ is a cool shortcut that accesses the last result that got printed out in the console.

Make HTTP requests with fetch

The fetch API (which is basically XMLHTTPRequest but easier to use) makes it really easy to go and get resources from the network. What's really nice is that the console (both in Firefox and Chromium-based browsers) now supports top-level await statements, which means you can write something like this:

await (await fetch('https://api.github.com/repos/microsoft/vscode/issues?state=all&per_page=100&page=1')).json();

And you'll have the parsed JSON from that github API call straight in your console!

Normally, you'd have to wrap the await statement in an async function, but for convenience, you don't have to do here in the console.

Format data like a pro

Dealing with lot's of data on the console isn't particularly easy. DevTools does a nice job at formatting objects, arrays, strings, numbers, etc. in useful ways, but sometimes you need more. And for those times, console.table might be what you need.

console.log(array) displays the provided array as a sortable table, expanding properties of items on multiple columns if possible.

If we take the fetch example from above, the call returns 100 objects, in an array, each with a lot of properties. But let's imagine you're only interested in a few properties (the number, title and state). The console.table function accepts a handy second argument that allows you to list which properties of the items you want to see in the resulting table:

await (await fetch('https://api.github.com/repos/microsoft/vscode/issues?state=all&per_page=100&page=1')).json();
console.table($_, ['number', 'title', 'state']);

Copy things

This is probably one of the lesser known console tricks. Sometimes you need to copy the result of something you just did in the console. Maybe you need to send it to someone, or paste it in a text editor. You can, of course, use your mouse to select text and then hit ctrl/cmd+C to copy the selection, but there's also a built-in function that might make your life easier: copy().

This function copies whatever you pass to it to your clipboard, as a string.

For me, it comes in very handy when I spent time listing elements or objects in the console, and massaging the data to find what I'm interested in.

Let's assume I was looking for all flexbox containers on the page:

$$('*').filter(n => getComputedStyle(n).display.endsWith('flex'));

and then wanted to list all of the classes that these elements have:

// Get all individual classes from classList
$_.map(e => [...e.classList]).flat();

// Reduce the list to unique classes only using a Set
[...new Set($_)]

and now I want to copy the result out to paste it in some code I'm working on:

copy($_)

At that point, my clipboard will contain the following content:

[
    "_23tra1HsiiP6cT-Cka-ycB",
    "c-uhfh-gcontainer-st",
    "c-uhfh-actions",
    "mectrl_header",
    "m-page-bar",
    "pagebar-module",
    "c-sequence-indicator",
    "c-group",
    "drawerheader",
    "c-glyph",
    "glyph-chevron-right",
    "cli_default_focus",
    "tileproductplacement",
    "mini",
    "f-sticky"
]

Debug JavaScript functions with `debug()` (⚠ only in Edge and Chrome)

Sometimes you need a little more help when troubleshooting an issue, and need to step into the code to inspect what's going wrong. Logging data from the code using console.log is often enough, but sometimes using a debugger is requires.

If you're a heavy console user and spend most of your debugging time there, you might enjoy the debug() function.

If the function you are trying to debug is accessible from the console, then you can just pass a reference to it to the debug helper, like debug(path.to.my.Function).

The next time your function gets executed, the JavaScript debugger will pause its execution and DevTools will switch to the Sources panel.

Advanced screenshot features with `:screenshot` (⚠ only in Firefox)

Nowadays there are many ways to take screenshots of the viewport, the full page, or a DOM node. But none of these methods really compare to the advanced features the :screenshot built-in command give you in Firefox.

You can simply type :screenshot in the console and it will go ahead and grab a screenshot of the page with the default configuration. If you have a specific need you can:

either take a full page screnshot with --fullpage or just an element with --selector,
either save to a file and specify the name with --filename or copy the image to the clipboard with --clipboard,
grab the screenshot only after some amount of time with --delay,
set the image resolution with --dpr.

You can read the full documentation on MDN or learn more from Eric Meyer's blog post.

Know when data gets evaluated

This one isn't a trick but more a gotcha that may save you a lot of time lost if you don't know about it.

The gist of it is that when you expand a property of an object in the console (by clicking on the little triangle next to it), that property gets evaluated when you click. As a result, what you are going to see then might not match what the value of that property was at the time the parent object was logged.

Let's go through an example to understand what that means.

Let's assume you have a function that deals with some object, and you need to log that object out at some point to check what the properties are:

function someFunction() {
  const obj = {
    foo: 42,
  };
  console.log(obj);
  
  return obj;
}

When the function gets executed, you'll see a nice little log in your console showing you a preview of that object.

Now, if, later on in the execution of your program that same object gets updated like this:

obj.foo++;

And let's assume you click the object in the console to expand its properties only at that point, you'll be seeing something that might surprised you:

The reason is the properties of that object got read 2 times by the console. First when the object was logged, and the console printed the preview of the object. And secondly when you clicked on the expander icon. Knowing that the value of the foo property changed between these 2 points in time, you get this weird result.

If this becomes a problem for you, one solution is to create a copy of the object when logging it, like this:

function someFunction() {
  const obj = {
    foo: 42,
  };
  console.log({ ...obj });
  
  return obj;
}

Now, when you click, even if the original obj object was changed, what you're expanding is only a copy of that object that hasn't been modified since it was logged.

Write on multiple lines

If you're feeling adventurous, you might want to write longer pieces of code in the console to execute more complex code. There are a few ways that will make your life easier if so:

Use shift+Enter to create a new line without executing the expression.
Use Firefox's multiline editor:

Create code snippets in Edge or Chrome's Sources panel. The added advantage of this technique is that code snippets are saved on your disk, and therefore can be used even after you've restarted the browser:

Access your history

This last trick really made a huge difference for me a while back. I often use similar pieces of code in the console over and over again, and typing these commands every time is getting tedious.

Thankfully, the console panel maintains a history and you can access it. Here's how:

The simplest but also most limiting way is pressing the Up arrow on your keyboard. This will cycle through all of the latest commands you've entered, one by one, and you can stop pressing when you found the one you were looking for. Simple, fast, and very useful for repeating things over and over again. However if you're looking for something you used a long time ago, this method will prove very time consuming.
If you know (at least part of) what you're looking for, just start typing it in Chrome or Edge and the autocomplete suggestion box that appears will contain all of the past commands you typed that match:

Firefox also has a useful reverse history search that mimicks Bash's ctrl+R reverse search. Pressing F9 on Windows/Linux or ctrl+R on Mac lets you type text and displays the matching results based on that.

That's it for now! I hope these were useful to you. If you know other tricks, I'd be happy to edit this article to include them. You can find me on twitter.

4 Weird Tricks To Become A 10x Flexbox Engineer

2021-02-02T00:00:00Z

Do you ever find yourself trying stuff out until they work? Did you make css-tricks’ guide to flexbox your default new-tab page (or even better, purchase the poster)?

If so, these tricks are for you!

Maybe you’re not going to become a 10x engineer like I promised. I do promise, however, that you’ll get more confident when authoring and debugging flexbox layouts in DevTools.

Authoring vs. Debugging

I believe DevTools sits in a unique position between our authoring and debugging workflows.

Traditionally, we write our code in text editors and then debug problems in DevTools. But with CSS more than with anything else, the line between these 2 steps in our dev cycle is a little blurry.
Sometimes we find ourselves writing lot’s of CSS code in DevTools and only then copying it back into our editors.
When it comes to JavaScript, or network calls, or even HTML structure, most of what we do in DevTools is debugging. But with CSS things are different.

The reason for this is when we edit CSS in the browser, something magical happens: debugging information appears right when we need them! Colors and sizes change in real time and computed values can be accessed as we type new properties.

This is something text editors have trouble doing. They act at the source file level, as they should. They don’t (and often can’t) know where the particular piece of code we’re writing will end up running.
But in DevTools, the piece of code we write is running at the same time. No compilation and download needed, we can re-write an entire piece of code, with logic and variables and see it take effect live.

So, even if DevTools will likely never become a full blown text editor, that supports saving, running extensions, with keyboard shortcuts and everything, it does something that no text editor can thanks to its ability to provide runtime debugging information.

That’s why tooling for the more complicated scenarios involving CSS is very interesting, it feels like Bret Victor’s "Inventing on Principles" where you write code, run it and debug it all at the same time and there’s no mode you have to be into to do these things.

With that in mind, let’s look at the usual problems people tend to have with flexbox: it’s hard to remember what properties do and we often have to try them all until the desired effect is reached.

Now, DevTools has access to the runtime environment, it knows which element we are working with, and the type of flexbox layout we’ve defined, as well as other things like text direction. Because of this it knows what the various flex properties will do when we use them. That means we can build tools that guide you while writing CSS, thanks to the runtime information available, with the goal to eliminate the trial and error process usually involved.

So, at the end of 2020, after we had shipped new css grid tooling in chromium, we formed again our small crew of designers, PMs and engineers, across Google and Microsoft, and set out to create a first series of tools for flexbox.

These features are now available in Edge 89 (which is, at the time of writing, available on the Dev channel), and in Chrome 89.

Turning on the features

For now, the features are still hidden by default since this is the first version and we wanted to slowly roll them out. They’ll soon be enabled by default, and when they are, we’ll be listening to feedback to address issues and work on an even better v2.

So, first things first:

Open DevTools
Click the cog icon to open the settings
Click on the Experiments tab
Check the "Enable new CSS Flexbox debugging features" box
Reload DevTools (there should be a button at the top letting you do that, but you could also just press F12 twice)

Trick 1 - Overlay

This might be the first one you see after you’ve enabled the feature. The easiest way to experience it is by clicking on the "Select Element" button in the toolbar and then moving your mouse over the page.
As soon as the element below the mouse is a flexbox container, the usual blue/green/purple highlight that appears on most elements will look a bit different.

We call this thing the overlay, and for flexbox containers, it shows a few more things than for other elements:

it draws a dashed border around the flexbox container itself,
it draws a border around each flex line (if there is wrapping with flex-wrap:wrap) and around each flex item, so it’s easy to see what’s an item and what isn’t (indeed, there are cases where it’s not obvious when e.g. absolute positioning is involved, or text nodes are present),
it displays a hatching pattern in the empty space caused by the various alignment properties you use.

You will also see the overlay as you move your mouse over elements inside the Elements panel.

It’s convenient because it’s right there when you need it and already gives you quite a number of interesting layout visual debugging information.

Trick 2 - Alignment icons

You can experience this new feature when editing CSS in the Styles pane of DevTools.

After you’ve put together a layout in your text editor and realize there’s a bug when you test it in the browser, that’s usually when you start messing around with the various properties available to you.
At this point, trial and error is usually required until you figure out the right property and value that you need.

With this new feature, you will get a little help right there. As you start typing property names in the Styles panel, you will notice icons in the autocomplete popup to tell you exactly what to expect from the various values.

These icons are very convenient because they make it immediately obvious which direction a CSS property apply in.

This works with a number of properties like align-items, justify-content, align-content, align-self or flex-direction.

It’s also worth noting that these icons will always be correct even if your layout is in column direction rather than row, and even if you were to use a vertical writing-mode.

Trick 3 - CSS properties highlight

Another feature we added that goes hand in hand with the previous one is the ability to highlight parts of the page that result of certain flexbox CSS properties.

The situation is the following one: you’re looking at a website and notice a problem with the layout. You open DevTools on the element that has the problem and a number of CSS rules and properties are displayed, but you’re not sure which one is responsible for the problem.

Instead of changing the value of these properties at random, you can now just move your mouse over the properties and you will see parts of the page starting to light up.

For example, as seen above, if you hover over the justify-content property, the areas around and in between flex items (along the main axis of the flexbox container) will get highlighted in the page. It makes it easy to see the way space is distributed between items, and exactly what justify-content influences.

Hovering over align-items draws a line with an arrow pointing in the direction where the flex items are aligned along the cross axis.
So when you can’t remember what direction align-items works in, just hover over it and you’ll see.

What’s nice about this too is it works regardless of the direction of your flex layout or your text direction.

This works with other properties too, like align-content or gap as demonstrated below:

Trick 4 - Badges and Layout panel

My final trick for you today is something that already exists for CSS Grid and now also works for Flexbox.
It is the ability to quickly find elements in the page that define flebox layouts.

As pictured above, the Elements panel in DevTools now displays little flex badges next to elements that are flexbox containers. I find it very useful when navigating the DOM tree, it avoids having to click on each node and looking through the Styles pane looking for a display:flex declaration.

If you’re looking for a specific element but don’t know or remember where it is in the DOM, instead of expanding the tree, it might be quicker to head over to the (recently added) Layout panel.
This panel gives you the entire list of all flex and grid layouts in the page, in one place:

In addition, both the badges and Layout panel give you a way to toggle a persistent overlay. It’s basically a version of the overlay you see on hover when selecting element that persists on the page while you do other things.
You can show overlays for as many flexbox layouts as you want.

It makes it easy to debug the position or alignment of flexbox layouts while being able to see the boundaries of your containers and items as you mess with CSS properties.

That’s it for now! I hope you enjoy those new features, and please do let me know on Twitter if you have feedback about them.
There’s more to come in this area too, so stay tuned for even more helpful features.

How we built the DevTools Tooltips

2021-03-08T00:00:00Z

Read the full article at https://medium.com/web-on-the-edge/how-we-built-the-devtools-tooltips-4e9933abbd8a

A Year at Microsoft

2021-03-22T00:00:00Z

I'm almost coming up to a year at Microsoft, and I thought now would be a good time to look back and talk about it a little.

(spoiler alert: things are great!)

How it all started

2020 was a very difficult year for a lot of people, but it also was the year when Mozilla had to layoff a lot of employees.

At the end of 2019, I had been at Mozilla for 6 years and I realized I was ready for my next job. I was looking to switch teams inside Mozilla, but also looking around for other jobs. So, in January of 2020, when the first wave of layoffs was announced, it made me double down on my effort to switch.

I remember our All Hands meeting in Berlin in January 2020 as a very sad one. It took place a couple of weeks after we all found out about the layoffs.
Of course it was, as always, very nice to see everybody face to face and spend some quality team time, but it was also sad to have to say goodbye to colleagues and friends, and several of us (including myself) didn't yet know whether they would be part of the layoffs. Indeed, France has a very complicated and slow process in this case, and us Mozilla France employees didn't know if our roles were going to be eliminated or not at that point, and not for another month.

Before knowing if I was going to be part of the impacted people, I had already contacted a lot of different companies and was interviewing in various places. One of which being Microsoft!

Two pretty wild things happened.

First, I learned just one week after I interviewed at Microsoft that, yes, I was going to be part of the Mozilla layoffs 😢. Thankfully, I already knew the interviews with Microsoft had gone well, and I was going to be getting an offer. But this was cutting it pretty close!
Secondly, I flew to Seattle for the interviews literally days before the covid-19 outbreaks started in several places, including Seattle! Just a few days later, and I wouldn't have been able to fly at all.

Anyway, I got the job 🎉

Out of all the jobs I was interviewing for, this was by far my number 1 choice, so I couldn't be happier. I was going to join the Microsoft Edge Developer Tools team which meant I could continue to use my knowledge in the field of browsers and web dev tools, and do this at a company that I respected very much.

The first few days

I'm not going to lie, the first week or so was a wild ride.

First of all, I didn't get a laptop from Microsoft until the second week, so I had to connect to the corporate network from my personal computer which didn't get me access to everything. Secondly, all of my team, including my manager, was in Redmond, USA (and still is) while I live in France. That means I didn't have anybody to ask for help during my working hours.

You can imagine how stressful this was at the beginning when all I was trying to do was be productive. I know I wasn't expected to perform from day one, people were fine with me needing time and there was a lot of training for me to do anyway. I guess it's compulsive, when you start a new job, you want to live up to the expectation you think people have of you as soon possible.

I am thankful to my colleagues and managers who took the time to chat with me, be friendly and teach me all sorts of internal knownledge I needed. If you're welcoming a new person on your team, take the time to answer any questions they have, even if you have a lot of work, this is the most important thing you can be doing for them right now.

Knowing that I wasn't going to be meeting people for real any time soon, I spent time introducing myself personally to each and everyone on the team, one by one. I learned a lot about people doing so, we would share stories of what we'd been working on before, etc. and this helped a lot feeling like I started knowing them a little better.

I also made it a point to have several one-on-one meetings per week. First of all with my manager of course, but also with other colleagues. I still do this today, and I really enjoy being able to see people every once in a while.

To this day, I still haven't seen anybody from my team for real! Ok, I did see my manager, and her manager, when I interviewed, but I never once met the other engineers on the team for real. What's more, people here often face mute during our daily Teams calls, so there are a few people who I've literally never seen.

Here's what I usually see when I'm on a call, initials or avatars, and sometimes a couple of people who have their cameras on:

Note that I totally understand why someone would face mute and I also need to do it from time to time. It's just that in my situation I lack the human element a little bit.

Things I've done

After settling in the new job, I quickly became productive. I was assigned to a project that I really liked, with people who helped me learn the environment and become comfortable with the day to day work.

My background working on DevTools at Mozilla became immediately useful to me as the things I worked on now were very similar, and I had expertise in this domain that proved useful.

I couldn't be happier to be working on CSS Grid tooling again, but this time for Chromium. This was in collaboration with the Google team, which was exciting. I could use my CSS layout knowledge, my experience from having built something similar in Firefox, and work with a super smart team of PMs, DevRels, designers and engineers across 2 companies.

Since then I've participated in several projects. Here's a quick list:

CSS Grid tooling: new overlay to see rows, columns, gaps and areas and a new Layout panel.
Flexbox tooling: same as above, but for flexbox, and we also added abunch of Styles pane features to make sense of the various flexbox properties (learn more in this other article I wrote).
Jump to CSS variables: a way to jump from a CSS variable usage to where it's defined in the Styles pane.
Focus Mode and DevTools Tooltips: a new UI for Edge DevTools, to group similar tools together in presets, and a help mode that gives documentation about the tools, directly within the tools (if you're curious, I wrote about how we made the tooltips).
Fixed a bunch of bugs in the CDP screencast methods to make size and colors more predictable.
And fixed many different bugs across DevTools.

Going back to coding

Prior to joining Microsoft, I had been a manager for 5 years. In fact, I have been going back and forth between management and coding a couple of times already, even before Mozilla.

Even if I originally wanted a management role at Microsoft, there wasn't one for me to fill at the time. Microsoft is quickly re-inventing itself when it comes to working remotely and across timezones, but it isn't ready yet to have managers who are remote from their teams. So I came in as a senior software engineer, and that's great. I far prefer knowing what it's like to be coding in this environment before becoming a manager again maybe one day.

Overall going back to coding hasn't been as hard as I expected it to be. I've needed to flex some muscles that had atrophied a little bit lately, but I knew JavaScript and CSS so that part came back quickly. TypeScript was new to me, but I immediately liked the comfort that gave me while working in VS Code, and it is sufficiently similar to JavaScript that it was simple to make sense of it.

The hardest part was C++. I had done a little bit at Mozilla, but C++ has so many features that it's sometimes really hard to read. I had to step up my game quite significantly since the entire DevTools backend was written in this language. I had no choice but to dive in. Thankfully, browsers are such huge codebases that whatever you want to do has probably already been done somewhere else in there, so it's usually a matter of finding the code you need and adapt it (and for this the chromium code search website is invaluable).

Now, after almost 1 year coding again, I have to say I still really enjoy it but I also know that this is not the end game for me. I love working on the product side of things, writing articles, communicating with users, planning work, defining strategies, managing people and projects, and more. There are many aspects of the software development world that attract me greatly on top of the pure technical part.

The pros and cons

Let's wrap this up with a simple list of pros and cons related to this year at Microsoft.

Take this with a grain of salt: this is based on my own experience and may vary for you if you're starting at or looking to join Microsoft.

The good stuff

Customer focus:
I don't think I've ever worked at a company that is more customer-focused than Microsoft. It is very reassuring to know you're working on the right features for your end users.
No after thoughts:
Microsoft takes things like accessibility super seriously. A lot of places don't really think of this as part of the normal coding work and often forget about i, or just do it as a best-effort-when-we-have-time kind of basis. It's not the case here, we've got processes and tools in place to track this and work on it along with the other "normal" coding tasks, and you just don't get to ship without it.
Investment in DevTools:
Edge invests in its DevTools, it isn't just a thing we need to do because other browsers have it too. We're based on Chromium, so we could very well not do anything. But we do invest in it. We have our own strategy for it and dedicate a fair level of investment for it.
PM-driven:
The work we do is driven by our product managers. We can count on them to give us the right priorities and requirements. At the same time, we also have flexibility as engineers. We can dedicate a bit of our time to work on side projects, we can come up with prototypes and propose new features and we have opportunities to learn. Our PMs and managers are also very receptive of us spending time on paying off technical debt, so we got secured time for this as well.
Google:
Collaborating with the Chrome DevTools team (since we both work on Chromium) has been great. It's exciting to make the tools better for many more people than just the ones using Edge.
Evolving:
Microsoft is constantly evolving. Even though it's huge and old, it moves really fast. I think we get the best of both worlds: we're allowed to make changes to how we work and be more agile, but we also have access to all of the services we need by virtue of being part of such a huge company.

The not-so-good stuff

Timezones:
I'm used to working remotely and with a geographically distributed team, but this is different. Now (almost) all my colleagues are in Redmond so their days start when mine ends. I can't really shift my working hours because I've got family stuff I want to do. Being shifted from my team means that:
- Emails, messages, notifications, etc. start getting super intense right when I'm supposed to be winding down and helping the kids or cooking dinner. It makes it hard to be in the moment with my loved ones, hard to disconnect.
- In the morning, when I get back to work, I have a ton of email and chat messages to sort through. Sometimes it can be hard to even start when you see this, you feel sort of blocked, like you suddenly have so many different things to do at once (my coping mechanism for this is going through them slowly, not all at once, to avoid forgetting about things or feeling too stressed out).
Seeing people:
I still haven't seen anybody from my team in real life! This has nothing to do with Microsoft. I'm sure that, barring covid-19, I'd already have gone to visit them a few times. I can't wait for people to be vaccinated and for borders to be open again. I'm longing for a week of team building/morale event somewhere nice together where we can get to know eachother for real and not only talk about work through a video camera.
Remote friendly:
Microsoft isn't super remote friendly yet. Covid-19 is forcing it to be a bit more, but it's obvious that it hasn't traditionally been used to this way of working.
Google:
I said collaborating with Google was good previously, but it has also had its down points. We used to have co-ownership of the codebase, because we know parts of the code as much as they do. But they recently decided that DevTools was a "part of the product" and they wanted to be able to move fast without having to ask permission. What that means is they took away any non-Google owners from the code. It doesn't mean we don't collaborate anymore, Chromium is still open source and we still send a lot of changes to it, but we don't really have a say in where Chromium DevTools is going now.

Let's end on a positive note 😊: I love my job, my colleagues are super smart and nice human beings, our team is functioning well, and I work on things that motivate me! On top of this, Microsoft as a company has not disapointed me at all, on the contrary, I've been surprised by how well things have been and the level of support I'm getting. I also think there are nice opportunities for me here to keep evolving my career. I would definitely recommended working here.

BlinkOn 14 Talk - Flexbox and Grid Tooling in Chromium

2021-05-14T00:00:00Z

Last year, a crew of engineers, designers and PMs got together across Microsoft and Google, and we worked together on adding tooling dedicated to CSS Grid and Flexbox.

These are 2 of the most used layout techniques in CSS, and we wanted all web developers using Chromium-based browsers to have the tools they need to debug problems and understand how these techniques work.

This week, for BlinkOn 14, I gave a short talk about why we implemented those tools, the features they have, and how we implemented them.

Here's the talk, hope you like it!

https://www.youtube.com/watch?v=D5x1Fa-Atew

Improving contrast in Microsoft Edge DevTools: A bugfix case study

2021-06-15T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2021/06/15/improving-contrast-in-microsoft-edge-devtools-a-bugfix-case-study/

Introducing DevTools Tips, for all your cross-browser DevTools tips and tricks

2021-07-01T00:00:00Z

I recently launched https://devtoolstips.org/ (and on twitter) and made it an open-source project that anyone is welcome to contribute to on the github repo.

The site is meant to be a collection of nice and simple cross-browser tips and tricks to get anyone more comfortable and productive with using the DevTools of their choice.

My goal is for the site to contain tips for everyone, whether they are seasoned developers or only starting, whether they do mostly CSS and HTML development, or JavaScript, performance improvement, and anything in between.

Browser vendors do have reference documentation for their DevTools already, and it's great and I'm definitely not trying to compete with those.
You can find those reference documentation here:

I strongly suggest going through some of the docs there as there is a lot to be learned about each tool.

My observation though, is that a lot of people don't really take the time to read those docs. They get introduced to the tools by co-workers, or blog posts, or on their own, and go from there, clicking around and discovering on their own. And reference docs can sometimes be daunting as there is a lot to read.

Short and specific articles about how to do certain things is a way for people to learn new and useful things that seems to work better.

I've seen a lot of people share tips on their blogs, at conferences or on twitter, and it's a great way to discover new things and raise awareness about other tools you might not be using.
Here are a couple you might like:

These are great, and I wish we could join forces. For the moment though, I haven't found one that was based on an open-source project that anyone could contribute to, and they tend to be mono-browser.

With DevTools Tips, I'd love to create a community of web developers who care about sharing their learnings with others in the form of quick tips, no matter what browser they happen to be using.

After a couple of weeks of working on this as a side project, I've already received contributions from 4 different people, which is awesome, and the site already counts more than 30 different tips.

If this sounds exciting to you, please don't hesitate to send ideas on twitter, or on GitHub, and if you feel like it, send me a PR.

What’s New With DevTools: Cross-Browser Edition

2021-09-07T00:00:00Z

Read the full article at https://www.smashingmagazine.com/2021/09/devtools-cross-browser-edition/

Make Microsoft Edge DevTools your own

2021-09-14T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2021/09/14/edge-devtools-93-personalization/

Minding the gap

2021-09-16T00:00:00Z

Read the full article at https://css-tricks.com/minding-the-gap/

Learn to build great Progressive Web Apps

2021-10-19T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2021/10/19/pwa-summit-learn-progressive-web-apps-documentation/

10 Ways to Handle Files on the Web!

2021-10-22T00:00:00Z

Websites usually don’t use files much. Files are usually a thing that desktop applications like working with. In fact, mobile devices also don’t usually use files, they prefer sharing data between apps directly, and putting everything in the cloud where things are just images, movies, songs, or messages with no information whatsoever as to how these are stored on the disk.

It’s come to a point where younger people, who have mostly been exposed to technology via mobile devices, Google, and the web, don’t even know what files and folders are.

But files are still extremely important and millions of people use them every day, creating documents and organizing them in folders.

So, even if the concept of files itself may, one day, disappear, it is still important for applications to know how to deal with them effectively. And because the web is, more and more, the go to technology for software development, even on desktop, it is equally important for it to handle files.

Now, working with files using web technologies isn’t very new, it’s been possible to upload and download files to and from websites for a long time, but new APIs have emerged lately that make it possible for web applications to provide more engaging app-like experiences.

In this article, we’ll go over all techniques that make it possible to work with files on the web. We’ll also review browser support and look at demos (we’ll be using the same demo application throughout the article, you can try it here).

Because this article is long, here's a table of content to jump to specific sections:

Relevant interfaces

Before diving in, it’s important to review how files appear to JavaScript code. There are multiple types of objects that one need to work with when working with files, and knowing the interfaces to these objects can be helpful.

DataTransfer

A DataTransfer object is passed in with the event object when listening to drag/drop and pasting events. This object is used to get access to File objects.

DataTransferItemList and FileList

Both can be retrieved from a DataTransfer object, and can be used to get the dropped or pasted files.

The latter can also be retrieved by listening to the change event on an <input type=file>.

DataTransferItem

This object is one of the items inside a DataTransferItemList, and can be used to get the associated file object with the getAsFile() method.

File

A File object is used to access the content of a file. It’s retrieved by either using the DataTransformItem.getAsFile() method, or by iterating over a FileList collection object.

FileSystemHandle

While similar to the File object we saw just before, the FileSystemHandle is different in that it represents a file on the actual operating system file system. It is retrieved by using the File System Access API when asking the browser to show the file picker with showOpenFilePicker().

It is a parent interface that both the FileSystemFileHandle and FileSystemDirectoryHandle extend.

Uploading files

Let’s review 3 different ways in which a browser can “open” a file. Open isn’t necessarily the right word here, upload works better. Indeed, the browser doesn’t open the file in the same was as, say, Microsoft Word opens the file. The browser doesn’t lock the file for editing, and cannot write in it.

Using an input element

The <input type=file> has been around for a very long time, and can be used nested inside a <form> to upload files to web servers.

But the input can also be used to access the content from the uploaded files directly using JavaScript code in the browser.

First, we need to add the input somewhere in the page:

<input type="file" id="input-file" accept="text/*" multiple>

The multiple attribute is useful when you want to allow users to select more than 1 file in the file picker. And the accept attribute allows to restrict the types of files that can be picked to a given mime-type.

As a side note, you can use CSS to style the input and label and make something a little better than what that code generates by default.

Next, let’s listen to changes in the input so we know when a file (or files) has been selected. This can be done by listening to the change event.

document.querySelector('#input-file').addEventListener('change', handleFile);

When files are selected by the user, and the listener is called, the input’s files property will contain the information we need to access the files.

It is then possible to iterate over the list of files and, for each, create a FileReader object to access the content. If the file contains text (text/* mime-type), then the FileReader’s onload event listener will give us access to the content of the file directly. Otherwise, we might have to decode the content using a TextDecoder object.

function handleFile(event) {
    const input = event.target;
    const files = input.files;
    if (!files.length) {
        return;
    }

    for (const file of files) {
        const reader = new FileReader();
        reader.onload = e => {
            let text = e.target.result;
            if (typeof text !== 'string') {
                const enc = new TextDecoder('utf-8');
                text = enc.decode(text);
            }
            // Do something with `text` here
        };

        reader.readAsText(file);
    }
}

Overall, this is a very simple and effective way to let the user choose a file and upload it to the site. It uses the familiar file picker pattern and is supported in all browsers.

Demo: using the demo app, click the “Browse” button in the top left to select one or more text files from your file system. Once selected, the content of the files is accessed and displayed in the text area in the middle of the app.
Link to the source code.

Dropping files

Another way to upload a file to a web page is by dragging it and dropping it into the browser window. By default, this will make the browser navigate away from the current site and open the file, but the site can actually listen for the drop event and cancel this default behavior.

To indicate that files are accepted by drag and drop, it can be useful to use the dragover and dragleave events, to highlight the drop zone temporarily.

const dropEl = document.querySelector('.content-wrapper');

dropEl.addEventListener('dragover', e => {
    e.preventDefault();
    dropEl.classList.add('drag-over');
});
dropEl.addEventListener('dragleave', e => {
    dropEl.classList.remove('drag-over');
});

Now, to actually handle the dropped file we should listen to the drop event. When it occurs, it will receive an event object of type DragEvent. This type of event has access to a dataTransfer property which can be used to iterate over the dropped items.

dropEl.addEventListener('drop', e => {
    dropEl.classList.remove('drag-over');

    // Prevent default behavior (Prevent file from being opened)
    e.preventDefault();

    handleDroppedItems(e.dataTransfer.items);
});

Note that dropped items don’t have to be files, so our code needs to check the type of the items before processing them.

async function handleDroppedItems(droppedItems = []) {
    for (const item of droppedItems) {
        if (item.kind === 'file') {
            const text = await item.getAsFile().text();
            // Do something with `text` here
        }
    }
}

As you can see above, after getting the File object with file.getAsFile(), we access its text content with the text() method. This method returns a promise as it is asynchronous. This is why we made handleDroppedItems an async function.

Support for dropping files in the browser is very good on desktop, and that’s what matters here anyway.

Demo: select one or more files from your file system and drop them in the demo app text area. Once dropped, their content is displayed in the text area.
Link to the source code.

Pasting files

Files can also be pasted in the browser window. Pasting and dropping files are very similar and they use the same DataTransfer object, so the code is very similar.

First, listen to the paste event on the document.

document.addEventListener('paste', e => {
    handlePastedItems(e.clipboardData.items);
});

And then, handle the pasted items just like we’d handle dropped items.

function handlePastedItems(pastedItems = []) {
    for (const item of pastedItems) {
        if (item.kind === 'file') {
            // Note that we're not using await here.
            // The DataTransferItemList passed on a paste event  becomes empty 
            // after an sync step, so we have to access all items synchronously.
            item.getAsFile().text().then(text => {
                // Do something with `text` here
            });
        }
    }
}

Support for the paste event is great.

One limitation of both dropping and pasting files in the browser is that it isn’t as natural to users and requires the site to let them know that it is even possible.

Demo: copy one or more files in your file system and paste them in the demo app (use the ctrl+V keyboard shortcut). Once pasted, their content is displayed in the text area.
Link to the source code.

Downloading files

Now that we’ve seen how files can be uploaded to a site, let’s see how they can be downloaded.

If you’re making a site that can edit photos, or text, and you’ve used one of the above uploading mechanisms, you might want to allow users to save their changes again by downloading a new file.

To do this, you can use the download attribute on a link (<a> element). The download attribute allows browsers to trigger a file download instead of navigating when the link is clicked. The attribute can also have a value that will be used as the name of the downloaded file:

<a href="file-path" download="file-name.text">Download</a>

If your JavaScript code has access to the content of the file as a string, you can do all of this programmatically too. First, create a data url from the text content:

const data = new Blob([text], { type: 'text/plain' });
const url = URL.createObjectURL(data);

And then, create the link element and activate it:

const link = document.createElement('a');
link.setAttribute('download', 'file.txt');
link.setAttribute('href', url);
link.click();

Note that the link doesn’t even have to be in the DOM for the above to work. So this is a great little piece of utility code you can put in a function, and call it anytime you need to make some text content available as a file download. Also, while you're at it, make sure you design your downloaded file names in a way that makes sense to your users!

The download attribute is supported across the board.

Demo: In the demo app, click the “Download” button in the top-right corner to transform the current text content in a file and make the browser download it.
Link to the source code.

Full file system access

While the methods listed so far are great ways to access the content of a file on a site, they don’t allow making changes to it and saving those changes back to disk in a way that desktop applications normally do. VS Code doesn’t require you to download a new file in your Downloads folder every time you make text changes, it has full access to the file on disk.

The File System Access API was made to fill this gap in the web platform, and allow web apps to open and save files.

This API is part of the Web Capabilities project (aka project Fugu 🐡) which aims at giving web apps the capabilities that compiled apps normally have.

The File System Access API’s browser support is limited still, but it is implemented by Chromium, which means that Microsoft Edge or Google Chrome can use it already (or other Chromium-based browsers - note that Brave, however, has the API disabled). It is not behind a flag, and can be used right away simply by checking that the feature exists.

Note that Firefox hans't yet sent positive signals around implementing this API and discussions are still ongoing. Safari, however, started implementing the API (based on an origin-private file system for now though).

Opening a file

Opening a file can be done by the using the window.showOpenFilePicker function which triggers the OS-specific file picker, like when using an <input file>.

const openButton = document.querySelector('#open');

// Make sure the API exists
if ('showOpenFilePicker' in window) {
    openButton.addEventListener('click', async () => {
        const [fileHandle] = await window.showOpenFilePicker({
            multiple: false
        });

        const file = await fileHandle.getFile();
        const text = await file.text();

        // Do something with `text` here
    });
}

The above code only deals with one file. That’s why the multiple property is set to false, and also why we only used the first FileSystemHandle object returned by showOpenFilePicker.

If you want to be able to save back to disk, always keep a reference to the FileSystemHandle object. That’s the object that represents the file on the actual device file system.

Using this object you can get the File object (using getFile()), which can, in turn, be used to retrieve the file content as seen above.

Interestingly, a DataTransferItem object can also be used to get a FileSystemHandle. Using the getAsFileSystemHandle() method, you can get a reference to the file handle from a dropped file. This means that your app can allow saving changes back to disk for a dropped file too.

Saving back to disk

If you have the file handle object stored somewhere in your app, you can use it to make changes to the file on disk by using the createWritable() function, as seen below:

const saveButton = document.querySelector('#save');

const newText = 'foo bar';

saveButton.addEventListener('click', async () => {
    if (!fileHandle) {
        return;
    }
    const writable = await fileHandle.createWritable();
    await writable.write(newText);
    await writable.close();
});

As seen in the 2 code snippets above, using the File System Access API is rather simple.

Saving as

The API also allows to save the content as a new file using the window.showSaveFilePicker function. This function works like window.showOpenFilePicker in that it returns a new file handle.

const saveAsButton = document.querySelector('#save-as');

// Make sure the API exists
if ('showSaveFilePicker' in window) {

const newText = 'foo bar';

saveAsButton.addEventListener('click', async () => {
    // Ask the user to select the new location.
    const newHandle = await window.showSaveFilePicker();

    // And save the file to this new file handle.
    const writable = await newHandle.createWritable();
    await writable.write(newText);
    await writable.close();
});

Demo: Open the demo app in Microsoft Edge, and click the “Open” button in the lower left corner to select a file from the file system. Its content is displayed in the text area. You can then edit the content and save the changes back to disk by clicking the “Save” button in the lower right corner.
You can also click the “Save as” button instead to save the content under a new file name.
Links to the source code: open, save and save as.

Handling files like compiled apps with PWAs

Progressive Web Apps (or PWAs) are meant to help make websites feel like applications that integrate more deeply within the operating system.

Now, with the PWA File Handling feature, they can also handle files like non-web apps can. Simply put, this means that double-clicking on a file on your desktop can launch the associated PWA automatically.

Enabling the feature

PWA file handling is, for now, only supported in Chromium and is still an experimental feature. It therefore needs to be enabled first. You can enable it by going to about://flags in Microsoft Edge or Google Chrome and enabling the “File handling API” flag.

Defining which files your app handles

Because this feature only works with PWAs, you first need to make sure you have a web app manifest file. Using the manifest, the PWA will tell the operating system which files it wants to handle using the file_handlers manifest member.

{
    "file_handlers": [
        {
            "action": "/",
            "accept": {
                "text/*": [".txt"]
            }
        }
    ]
}

In this example, the app registers a single file handler that accepts text files and tells the OS to go to the app root (using the action property) when one is launched.

Handling the files on launch

When the PWA launches, it can check if there are files to be handled. This is done using the window.launchQueue object.

// Check that the launchQueue object exists. 
if ('launchQueue' in window) {
    // Consume the launchQueue.
    window.launchQueue.setConsumer(params => {
        if (!params.files.length) {
            return;
        }
        for (const file of params.files) {
            handleFile(file);
        }
    });
}

The launchQueue parameter passed to the setConsumer function gives us access to the list of files, and each file within that list is a FileSystemFileHandle object. This means we’re dealing with the same object types as when using the File System Access API. We can therefore access the file content like this:

async function handleFile(fileHandle) {
    const file = await fileHandle.getFile();
    const text = await file.text();

    // Do something with text here.
}

Having access to a file handle also means you can save changes back to disk using the createWritable() method we used before.

Demo: Open the demo app in Microsoft Edge, and install it as a PWA (click the “install app” button in the address bar when it appears). Now, choose any text file in your file system and double-click on it. You can also use the context menu (right-click) and select “Open with” to choose the demo PWA app.
Links to the source code: manifest, launchQueue handling.

Sharing files

Finally, let’s talk about sharing. Sharing originally appeared on mobile devices where passing information between apps isn’t very easily achieved with a file system. On mobile, apps are able to share content with other apps directly.

For example, you can share an event stored in your calendar with somebody on a text messaging app. The sharing happens automatically without you having to save a file from the calendar app, and then open it from the message app. Instead, the calendar app knows how share its content, and the message app knows how to accept shared content.

It is now possible to do both of these things on the web. Let’s see how.

Sharing with other apps

Using the Web Share API, websites can share content. This API can be used to share a url, some text, or even a file, and have all of this content be handled by the operating system’s share utility, so that other apps can consume this shared content.

Before using the API, check that it is available:

if (navigator.share) {
    // The Web Share API can be used
}

The type of data that can be shared with this API is an object with the following properties: title, text, url, and files. All of these properties are optional, but you should at least provide one. It’s up to the target application to do what it wants with this data. A message app may decide to use the text and url for example.

Use the navigator.share() method to share your content. If you aren’t sure about the data, you can also use the navigator.canShare() method to test it.

const shareButton = document.querySelector('#web-share');
async function shareFile(files) {
    if (navigator.canShare && navigator.canShare({ files })) {
        try {
            await navigator.share({ files });
        } catch (e) {
            console.error('Error sharing the content', e);
        }
    }
}

shareButton.addEventListener('click', () => shareFile(someFiles));

In the above code, the someFiles array is a list of File objects, just like the ones we used when dropping and pasting files in the browser (the ones retrieved from DataTransferItem.getAsFile()).

You can also construct a file object from text if you need:

const file = new File(text.split('\n'), 'shared-file.txt', {
  type: 'text/plain'
});

The navigator.share() function is well supported across Edge, Chrome, Firefox, and Safari, but it’s worth noting that Edge and Chrome only support it on Desktop, and that Firefox does not support sharing files (or the navigator.canShare() function).

Demo: In the demo app, click the “Share” button in the right sidebar. The text content of the textarea will be used to create a file which will be shared with the operating system’s share dialog.
Each app handles shared content differently, but if you select Microsoft Mail for example, the file will appear as an attachment to a new email.
Link to the source code.

Accepting shared files

Sharing files with other apps is just half of the story. The other parts is accepting shared files. It is possible to do so by using the Web Share Target API. This API is, for now, at an early draft stage and only supported on Chromium browsers (Firefox’s intent is positive though).

Being recognized by the operating system as a potential target for shared content only works if the app is a PWA. It isn’t possible for a website in the browser to be a share target, this only works with installed PWAs.

So the first thing you’ll need is a web app manifest file and, in it, a share_target member:

{
    "share_target": {
        "action": "/share-target",
        "method": "POST",
        "enctype": "multipart/form-data",
        "params": {
            "title": "title",
            "files": [
                {
                    "name": "file",
                    "accept": [
                        "text/*"
                    ]
                }
            ]
        }
    }
}

When the OS installs the app, it will look at the share_target manifest member, and register the app is one that handles text files. When the user shares a text file from another app, the OS will prompt the user to choose from a list of apps that can handle text files, which will include this app.

Now, when the app starts, a POST request will be sent to the action specified in the manifest (/share-target here). Your server could handle the form submission at this point, but because the app is a PWA, you can also intercept the request from the service worker, and handle the file there.

self.addEventListener('fetch', event => {
    const url = new URL(event.request.url);

    if (event.request.method === 'POST' && url.pathname === '/share-target') {
        event.respondWith((async () => {
            const data = await event.request.formData();            
            const file = data.get('file');
            // ...
        })());
    }
});

Above is a fetch event listener in the service worker. It handles the /share-target POST form submission and use the request.formData() function to access the shared file.

At this point, you might need to pass the file to the front-end code (rather than the service worker code). There are multiple solutions for this. You could read the content as text and use postMessage to send it to the client or you could store it in IndexedDB (by the way, working with IndexedDB can be hard, I recommend using the LocalForage library which makes it much easier).

Demo: Make sure you installed the demo app as a PWA first, then choose a text file from your file system, and share it. On Windows, you can use the context menu (right-click) and select “Share” to do this. The operating system’s share dialog will appear and list the demo app as one of the possible targets. Selecting the demo app will launch it and display the content of the file.
Links to the source code: manifest, service worker, client code.

And, that’s it! We’ve reviewed all of the current ways that web sites and apps can work with files today. There are many so it can be a bit confusing. Hopefully this article was useful in understanding the differences and which of these ways might be best suited for you.

Picking colors of any pixel on the screen with the EyeDropper API

2021-10-27T00:00:00Z

Read the full article at https://developer.chrome.com/docs/capabilities/web-apis/eyedropper

How I built an Eye Dropper browser extension

2021-11-24T00:00:00Z

I recently wrote about the EyeDropper API, this great new little JavaScript API that allows users to pick colors from anywhere on their screens.

In a few words, by executing just a couple of JS lines of code, web devs can make an eye dropper tool appear, letting users click on a pixel, and the color of the pixel is returned to the code, for the devs to use.

The API was implemented in Chromium-based browsers, including Edge and Chrome, in version 96. This version is now available to all! No need to install a pre-release channel of the browser, or turn on any flags. You can just use it! Of course, this is only Chromium, so don't rely on it in production just yet, but it's definitely a great time to experiment with it.

Back when I worked on the article, I got interested in whether the API would also work in browser extensions, which it does! So I built a small extension that lets you grab colors from your screen, and store them locally for later reuse. It's great to build a color palette from an image for example, and always have those colors handy.

➡️ Get the extension here (for both Chrome and Edge) (it's for Chromium-browsers only for now because the EyeDropper API only works there).

➡️ And browse the source code.

There are of course other existing software that do this, but since web developers spend most of their time in the browser, I figured having an icon right there, in the browser toolbar, would be quite handy. After using myself for a while, I have to say it is very useful, at least to me.

Now, let's dive into some of the interesting details behind this extension.

Building a browser extension

If you're interested in building one, but don't quite know where to start, I think the most important thing to know is that they're built using HTML, CSS, and JavaScript! So you can reuse the knowledge you already have.

There's a bunch of specific extension stuff added on top too, but if you're looking to create an extension like this one, it's really not that much.

The entry point of any extension is its manifest file. This file is used by the browser to know what the name, description, author, icons, etc. of the extension are.

Here is the manifest of the Eyedropper extension:

{
    "name": "Eye Dropper",
    "description": "A browser extension to copy colors from your screen",
    "homepage_url": "https://github.com/captainbrosset/eye-dropper-ext/",
    "author": "Patrick Brosset",
    "version": "0.1",
    "manifest_version": 2,
    "icons": {
        "16": "icons/icon16.png",
        "32": "icons/icon32.png",
        ...
    },
    "browser_action": {
        "default_icon": {
            "16": "icons/icon16.png",
            "32": "icons/icon32.png",
            ...
        },
        "default_title": "Pick a color!",
        "default_popup": "popup/popup.html"
    }
}

It is also used to list the various entry points of the extension. In particular, my extension shows an icon in the toolbar. To do this, I used the browser_action property in the manifest file as seen above. This property needs an icon, and either an action to execute on click, or a popup to display on click.

Adding the popup.html file and this browser_action property was all I needed to have the icon in the toolbar. It's therefore quite simple to use, and we can then focus on the HTML of the popup and the CSS and JS code embedded in it.

As for many other things, MDN is a great place to learn more about writing extensions in the browser. The main documentation entry point can be found here: Browser Extensions. You there's documentation about the manifest, and the browser_action property.

Using the EyeDropper API

The core part of the extension is the eye dropper. To make it work, I used the new EyeDropper API (which I documented on MDN recently too).

It takes just a few lines of JS code to use the EyeDropper API. This API doesn't have a lot of extra features for now, and that's good. This may change in the future depending on the feedback received on the specification but, for now, here is the code I'm using the display the eye dropper on click:

async function pickNewColor() {
  let result = null;
  try {
    const ed = new EyeDropper();
    result = await ed.open();
  } catch (e) {
    return;
  }

  if (result) {
    const color = result.sRGBHex;

    // after this, store the color, copy in clipboard, etc.
  }
}

document.querySelector('button').addEventListener('click', pickNewColor);

So, using the eye dropper requires to:

Instantiate the EyeDropper class.
Call the open method.

Now, open returns a promise. It's useful because the promise will resolve when the user has picked a color. If the user decides to not pick a color after all and presses ESCAPE on the keyboard, the promise rejects.

In the code sample above, I'm using an aync function which makes working with promise-based asynchronous code really nice. It reads like synchronous code, and avoid the nested callback hell we normally deal with when using promises with the .then handler. Learn more about async functions here.

When the promise resolves, it returns an object with the sRGBHex property on it. This property is a string containing the color value in hex format.

Using the Clipboard API

The second most useful piece of code in the extension is its use of the Clipboard API. That's what makes the extension useful. Without it, you'd only be able to pick colors, but not use them anywhere.

The extension uses the API to store the color value of a newly picked color, and also when you click on a previously picked color, in the popup.

There are 2 steps to doing this with the API:

Requesting permission.
Writing text in the clipboard.

Here is the code I used to do it:

async function sendToClipboard(color) {
  const result = await navigator.permissions.query({ name: "clipboard-write" });
  if (result.state == "granted" || result.state == "prompt") {
    try {
      await navigator.clipboard.writeText(color);
    } catch (e) {
      // Failed to write to the clipboard.
    }
  }
}

As you can see, the first line is used to request the user's permission to write to the clipboard using the Permissions API.

This part is asynchronous and returns a promise. This is because asking for the user's permission requires them to manually interact with a popup, which takes time. The promise returned by the query method does not resolve before this happens, and the returned value contains the state of the user's permission.

I used an async function here again to make dealing with this asynchronous code easier.

The second part is using the Clipboard API. In my case, I need to write to the clipboard, so I used the navigator.clipboard.writeText function (documented here), but there are other methods to read too.

In terms of code, that's about it. The extension does only one thing, and it relies on APIs to do the heavy lifting, so its code is pretty short. I hope the extension helps you! Let me know on the GitHub repo if it does, or if you have bugs.

Breaking Out of the Box

2021-12-09T00:00:00Z

Read the full article at https://alistapart.com/article/breaking-out-of-the-box/

Debug memory leaks with the Microsoft Edge Detached Elements tool

2021-12-09T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2021/12/09/debug-memory-leaks-detached-elements-tool-devtools/

Looking back at Microsoft Edge for developers in 2021

2022-01-19T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2022/01/19/looking-back-at-microsoft-edge-for-developers-in-2021/

What’s New In DevTools?

2022-01-25T00:00:00Z

Read the full article at https://www.smashingmagazine.com/2022/01/devtools-updates-2022/

CSS Custom Highlight API: The Future of Highlighting Text Ranges on the Web

2022-03-01T00:00:00Z

Read the full article at https://css-tricks.com/css-custom-highlight-api-early-loo/

PWA Debugging Tools

2022-03-02T00:00:00Z

Read the full article at https://microsoft.github.io/win-student-devs/#/30DaysOfPWA/dev-tools/03

Say Hello to selectmenu, a Fully Style-able select Element

2022-03-03T00:00:00Z

Read the full article at https://css-tricks.com/the-selectmenu-element/

Improving DevTools together: Announcing the new Edge DevTools feedback repository

2022-03-09T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2022/03/09/improving-devtools-together-announcing-the-new-edge-devtools-feedback-repository/

30 days of PWA: Fall in love with Progressive Web Apps

2022-04-14T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2022/04/14/30-days-of-pwa-fall-in-love-with-progressive-web-apps/

Better error stacktraces for faster debugging

2022-05-05T00:00:00Z

The problem

Web devs debug their code in different ways. Some people will tell you that stepping debuggers and breakpoints are better, more powerful, ways to find the root cause of a problem. But let's face it, most of us just console.log our way out of it, and it's fine!

I've been on the fence myself, I started my career with alert() debugging, and these days I do a mix of using breakpoints and just writing logs in the my code. Sometimes, when I remember this feature even exists, I use logpoints too, and this saves me a trip to my editor and shame when I realize I committed a leftover console.log().

But whichever debugging technique you use, I believe both are limited and there should be a better way. Let's review a quick example that will help make the point.

Let's imagine we have a function that retrieves a collection of items and then highlights them.

function start() {
  const els = getAllItems();
  els.forEach(highlightItem);
}

Now the highlighting function is quite simple: it is given a DOM element and adds a background color to it:

function highlightItem(el) {
  const color = "#" + Math.floor(Math.random() * 16777215).toString(16);
  el.style.backgroundColor = color;
}

Now let's imagine that the getAllItems function calls through to other functions which, themselves call yet other functions. The idea here is the process is not straightforward. Few codebases are. These could be spread across many files, authored by different people, with lots of complexity involved, such that bugs can creep in unnoticed.

In the example below, I've just added 4 extra functions to make my point. Even just 20 or so lines of code make it hard to spot the problem at a glance, so imagine if this was a much more complicated code base.

function getAllItems() {
  return getAppItems();
}

function getAppItems() {
  return [...getWrapperItems(), ...getListItems()];
}

function getWrapperItems() {
  return [
    document.querySelector("ul"),
    document.querySelector("body"),
    getMiscEl(),
    document.querySelector("html"),
  ];
}

function getMiscEl() {
  return undefined;
}

function getListItems() {
  return [...document.querySelectorAll("li")];
}

Here the problem is that getMiscEl returns undefined, and that this values ends up in the list of items returned by getAllItems. So one of the items that we'll try to highlight later will cause a runtime error.

Opening DevTools and checking the console would produce an error stack trace similar to this:

Uncaught TypeError: Cannot read properties of undefined (reading 'style')
    at highlightItem (test.html:112)
    at Array.forEach ()
    at start (test.html:81)
    at test.html:115

The error message is quite clear, we know the highlightItem function failed and we know exactly where it failed and why.

But this trace doesn't tell us anything about where the root cause actually is. We know highlightItem was called in a forEach loop, but which item failed? Which of our many functions returned undefined? Where did we go wrong?

At this point, whether you're a breakpoint kind of developer or a console.log one, you're faced with the same problem: reading your code backwards from where it failed, randomly pocking at it, adding more breakpoints and logs hoping they're in a place near enough the actual root cause to make you see the problem.

Replay takes a really interesting, and very different approach to this by constantly recording and letting you just "step back" through your code at any point, reviewing variables. You can just add logs after the fact and get immediate results without re-running the code. It removes the need from setting breakpoints or altering your code with more logs. But to some extent, it's still a bit of a shot in the dark. You're still hunting for the root cause.

Stack traces

All errors that originate from the JavaScript engine you use come with a stacktrace. The engine collects information about the most recent functions that have been called so that when an error occurs, it can give you this information.

You, as a developer, can even access this via the non-standard Error.stack API. Learn more about the stack trace API in V8 here.

In fact, this stack trace is what the DevTools in your browser use to display errors in the console. They somehow parse the string returned by the API to give you a more interesting representation of it.

Because JavaScript engines are finely tuned machines that are trying to go as fast as possible, not all function calls are recorded, and only a minimal amount of information about them is recorded: there is no information about arguments and returned values.

Moreover, and this is crucial here, the engine only cares about the functions that correspond to the current call stack. In our case, highlightItem failed, and we only get information about what called it: forEach, and before that start. We have no information whatsoever about the fact that getAllItems was called before. That call worked fine and returned, it's long been popped from the stack.

Tracing instead?

What if we could move beyond the error stack trace performance limitation and add more information to it?

What if we could also keep previous stacks in memory, so that the information about getAllItems having been called is still here when the error occurs.

And what if we also recorded the arguments and return values for each function in the trace.

We don't want to slow down the engine at all, so that's a concern. But I want to believe that in a "developer" mode we could get to a trace like this:

start (test.html:81), args '[]'
    getAllItems (test.html:84), args '[]', return '[Node,Node,undefined,Node,Node]'
      getAppItems (test.html:88), args '[]', return '[Node,Node,undefined,Node,Node]'
          getWrapperItems (test.html2), args '[]', return '[Node,Node,undefined,Node]'
              getMiscEl (test.html:101), args '[]', return 'udefined'
          getListItems (test.html:105), args '[]', return '[Node]'
    Array.forEach ()
        highlightItem (test.html:112), args '[Node,Node,undefined,Node,Node]
            /!\ Uncaught TypeError: Cannot read properties of undefined (reading 'style')

In this trace, not only do we have the same information we have in normal error stack traces (i.e. the fact that highlightItem failed because the provided element was undefined), but we also see preceding calls and their return values.

We can clearly see that getAllItems returns a list that contains one undefined item, but we can also track this undefined item all the way down to getMiscEl, and that's our root cause!

No more need to hunt for places to put breakpoints and console.logs in, we can zero in on our root cause much quicker.

This is nothing more than a trace. Tracing debugging is already a thing, but unfortunately not often used in our JavaScript ecosystem. I vaguely remember Firefox having a tracing debugging feature back in the days, but it got removed at some point.

The Performance profiler in Chromium browsers comes close, it records the entire execution of a program and provides a nice visualization of it, but it's not possible to get the arguments or return values.

I'm not saying we should introduce (or rather re-introduce) tracing debuggers, but I do think we should mix traces and error stacks together when errors are logged to the console by the JavaScript engine. Because tracing has performance impacts on the engine, we should only do this if DevTools was already opened before. Perhaps we should even only do it when an option is turned on. And I don't think we should trace everything (like the Performance tool does) but instead only capture the most recent traces since those are likely to contain our root cause anyway.

The Console is one of the most used tools by JavaScript frontend developers. Teaching everyone about breakpoints isn't necessarily the way to go, we've tried it and not only does it not seem to work but it's not the best debugging experience either. I believe there are other ways in which we can improve the JavaScript debugging experience that doesn't rely on making people feel dumb for not using a real debugger.

Sure, what I'm proposing here might not always be THE way, and it may not always be helpful. But hey, if it helps in even 50% of cases, I think it's a huge win for everyone.

Styling Image position Image Rotation Number of blades
At the end of the day though, I still suck at doing any kind of complex maths in CSS. If you want to get your mind blown, check out Ana Tudor, Temani Afif, or Amit Sheen on CodePen. These folks are on another level.

What I love about these experiments is how often they reveal hidden layers deep within what would otherwise appear as ordinary parts of the web.

CSS box-shadow is an example of one of these parts which, at first sight, may seem familiar, almost boring. But it also comes with hidden complexity and extra capabilities that, at least for me, only playing for no other reason than fun could reveal. Among them: the `box-shadow` syntax, the ability to layer multiple shadows, the way they spread from each other, and the ability to animate shadows.

So, here is a demo that's all about taking the smallest possible unit: a single CSS property, and seeing how weird I could make it:

There are twenty circles in the above visual. Each is a `<div>` element with rounded corners and is randomly positioned. Each has three different shadows applied, and the shadows are animated. For extra fun, I used `mix-blend-mode` to get some interesting interactions where the circles overlap, and you can also click the area to colorize it.

Playing with this taught me a few things:

I finally remember the syntax for `box-shadow`. It is: `box-shawdow: <x offset> <y offset> <blur radius> <spread radius> <color>;`

I love that you can reset the blur radius to draw a shape around any element. For example `box-shadow: 0 0 0 10px red` draws a 10px red "border" around an element.

I also now understand how multiple shadows stack. Subsequent shadows are drawn below previous ones. And the spread value is relative to the size of the previous shadow too.

`mix-blend-mode` is really fun when drawing abstract stuff like this.

These experiments aren't just toys. They're reminders that the web platform is alive and kicking, full of features and capabilities that are just waiting to be discovered. They're also a reminder that we can all be creative people, given the right mindset and the right tools, and that learning through play is a powerful way to grow as a developer.

Take an hour to play. Try something weird. Learn something new. If you do make something fun, share it with others, on your personal website, on social media, on codepen, or with your colleagues.

Alright, one last silly experiment before I wrap this up. Meet a new special kind of popup hell!

Try moving the red popup above. And click below to make it even worse:

Anchor positioning is very new and not quite ready for prime time yet. To me, this means it's the perfect time to learn more about it. I've seen countless messages on social media, talks, and demos about anchor positioning already, but I have never tried it myself.

In this demo, there's one hundred popups (remember the good old days of popup hell on the web?), and they're all chained together using anchor positioning. They're randomly tethered to other popups, and randomly placed respective to their anchors. When you move the red popup around, all other popups randomly follow it because they're indirectly anchored to it via other popups, possibly through multiple levels of anchoring.

This is obviously not something you'd ever need to do in a real project. But in trying to achieve the exact look I was after, I learned a lot about anchor positioning. It made me realize that you can tether multiple elements to the same anchor, it made me use properties like `anchor-name`, `position-anchor`, the `anchor()` function, and it also made me aware of other capabilities, such as the `position-try` property, but also the `anchor` HTML attribute.

Don't forget to play

The web is an amazingly playful app platform. That's what it was to me some 25 odd years ago, and that's what it still is. A platform where a text editor and a browser of your choice is all you need to start creating. No gatekeepers, no approval processes.

Every silly experiment, demo, and useless project I've shown here and others I've worked on over the years have taught me something new about the web, and have kept my passion for it alive.

The web is still magic, and it still matters. Even today when it feels like AI is replacing how people consume and create content.

Go create something ridiculous, learn by playing, keep the web weird and wonderful.

Microsoft Edge and Interop 2026

2026-02-12T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2026/02/12/microsoft-edge-and-interop-2026/

Embrace the chaos — The shape and flow of masonry layouts

2026-02-23T00:00:00Z

Masonry is a cool looking layout that can create visually stunning designs. It's not for every use case, that's for sure, but it has its place in a web designer's toolbox, and people have been wanting to do this for a long time.

The good news is, masonry is finally getting implemented for real in browsers, and should be usable very soon thanks to display: grid-lanes;

In this article, I want to explore how masonry relates to other types of layouts, and to do this, I'll focus on something I don't see being talked about often: shape and flow.

Shape and flow of a layout

The shape of a layout is the visual structure that it creates for its items. For example, if a layout container makes its children elements appear in columns, then the shape of that layout is column-based.

The flow of a layout is the path which items follow to appear within the layout's structure. For example, in a column-shape layout, the items might fill each column one by one, or they might fill rows first, going left to right.

When using a CSS layout on a webpage, what's more important to you? The visual shape of the layout or the way that the items flow within that shape?

Both are important, right?

The final shape of the layout is important because that's what users see and that's what designers want.
The flow of the items is also important because that's how users read and interact with the content.

So, ideally, any type of CSS layout should allow you to define and customize, to some extent, both of these aspects.

Layout types

Let's consider the following layout types (I'm ignoring tables, and positioning techniques like absolute/fixed in this article):

Normal flow
Flexbox
Grid

And then compare this to masonry.

They all have their specific shapes and ways of handling the flow of items through the layout.

Normal flow

Normal flow is the default layout type in CSS that's used anytime you don't specify a different layout.

Shape: the normal flow layout has no predefined shape beyond being a box, like any element on the web. A box, nothing more, nothing less. Normal flow doesn't impose any specific structure to its items.
Flow: the way items flow through the layout depends on the items themselves, not the layout shape (which doesn't exist). Block-level items stack vertically, one after the other. Inline-level items flow horizontally, wrapping to the next line when they reach the edge of the container.

Normal flow is how the web got started, it's great for documents where different sections are stacked on top of each other, and text is the main content.

Flexbox

Shape: just like normal flow, flexbox doesn't have a predefined shape and doesn't impose any specific structure to its items beyond its size and rectangular shape.

At least, as long as you don't use flex-wrap. If you do and if you have enough items, then flexbox creates multiple flex lines to place these items. This creates a structure which your items have to follow.
Flow: the way items flow through a flexbox layout is determined by the flex-direction property. If set to column, items stack vertically, one after the other. If set to row, items flow horizontally.

Flexbox also supports row-reverse and column-reverse values, which changes the starting edge of the layout.

Grid

Shape: grid is different from the two previous layout types in that it does impose a very specific shape, or structure, to its items. Grid lets you define a two-dimensional shape by using the grid-template-columns and grid-template-rows properties. With this, you create rows and columns of specific sizes, and items can't escape this structure.
Flow: the way items flow through a grid layout is highly customizable.

You can either place all items in specific cells by using grid-column, grid-row, or grid-area.

Or you can decide how the items flow through the cells by using the grid-auto-flow property. When not set, the default value makes the items fill each row one by one before going down to the next row.

Masonry

Shape: masonry is similar to grid in that it imposes a specific shape to the items, but it's also similar to flexbox in that it only does this along one dimension. The shape is either made up of columns or rows, depending on whether you define grid-template-columns or grid-template-rows. This creates lanes where items are placed, and which they can't really escape.
Flow: the way items flow through a masonry layout is determined by the masonry algorithm.

This algorithm picks the right lane for each item based on which lane has the most space available. Because of this, you don't really get to decide how items flow through a masonry layout. It's imposed by the packing algorithm, and depends on the shape of the layout.

The masonry packing algorithm

Let's go back to the algorithm which masonry uses to place items in the layout.

This algorithm places each item one after the other, and at each step, finds the lane where the most space remains.

For example, in a vertical masonry layout that already has 19 items, the 20th item will be placed in the column where the total height of all items is the shortest. In the illustration below, that's the second column from the left:

In case of ties, the lane that's closest to the starting edge will win. In a left-to-right layout, the leftmost lane wins ties; in a right-to-left layout, the rightmost lane wins ties. You can also influence this by using the flow-tolerance property, but let's not get into that here.

It's pretty interesting to think of this algorithm as being opportunistic. In masonry, the emphasis is on optimizing to reduce empty space, rather than on controlling the order of items.

For example, it's easy to end up in situations where items which follow each other in the DOM appear far apart visually, or even in seemingly random order:

There may very well be cases, though, where items of a masonry layout logically follow each other in a natural reading sequence, especially if items are of similar sizes. But that's probably the exception rather than the norm:

Is masonry more like grid or flexbox?

Masonry is its own thing, but finding similarities with other layout types can be helpful. Indeed, masonry is still largely being defined by the CSS Working Group, and there are parts of it which are still up for debate. Resolving the remaining open questions take a deep understanding of other layout types, and existing CSS properties because reusing existing syntax and being consistent can make a big difference for developers.

So let's try to find consistency with other types of layouts.

Is masonry like grid?

Well, first of all, masonry and grid have a pretty similar display type name:

display: grid;
display: grid-lanes

But they're also similar in that you define the shape of both layouts by using grid-template-columns or grid-template-rows. You can also place items in specific lanes of a masonry layout by using grid-column and grid-row, just like you can use these properties to place items in specific cells in a grid layout.

It also kind of looks like a grid, at least sometimes, and if most of your items are about the same size. If items are of very distinct sizes however, the grid-like appearance quickly breaks down:

However, unlike grid, masonry doesn't have a notion of cells. You can't place items in specific cells, only in specific lanes. And when you do, the items are placed at the end of that lane, following other items that might already be there.

Also, as we've seen before with masonry, you don't get to decide how items flow through the layout. The flow is always determined by the packing algorithm, which places items in the shortest lane available at each step.

But anyway, let's entertain the idea that masonry is similar to grid.

In a grid, you describe the shape of the layout by using grid-template-columns and grid-template-rows. If you want two columns and ten rows, you use grid-template-columns: repeat(2, 1fr); grid-template-rows: repeat(10, auto);

This defines the scaffold of the shape you want to see. You get to define it explicitly, with keywords that make sense: columns and rows.

And then, you can change the flow of the items within that shape as we've seen before, either by positioning items explicitely by using grid-column and grid-row, or, by using the grid-auto-flow property:

In grid, flow and shape are independent, and you get to define both separately. That's because the grid-template-* properties completely describe the shape of the layout, and the grid-auto-flow property only describes the flow.

Masonry is kind of like that but different. For starters, you only define one dimension of the shape, not two. So you either use grid-template-columns or grid-template-rows, but not both. And once the lanes are defined, you don't get to change the flow of the items because it's determined by the masonry packing algorithm.

The only aspect of the flow you can change is the starting edge of the layout: which lane gets filled first in case of ties.

So is masonry more like flexbox then?

Flexbox and masonry share quite a few similarities:

They're both one-dimensional layouts meaning that you only define one dimension of the layout shape, not two.
You don't get to define the flow of items beyond the starting edge and the direction of the layout.

In flexbox, you use the flex-direction property to define both the shape of the layout and the starting edge. For example, row creates a horizontal row of items that start from the left edge of the layout container (in western left-to-right languages), and row-reverse creates the same shape but starts placing items from the right edge instead.

The flex-direction property also supports the row-reverse and column-reverse values, letting you change the starting edge of the layout.

Finally, flexbox also supports the flex-wrap property which lets you reverse the wrapping direction for multi-line flex containers, which in a way is also a way to set the starting edge of the layout.

So with flexbox, you get to define the shape of the layout only (row, column, wrapping) and the edges from which items start to be placed. But, you don't get to define the flow of the items beyond that.

Masonry is kind of similar to flexbox in that you only get to define one dimension of the layout. The layout is either made up of columns or rows.

And then, you can decide which of the edges should the items start to be placed from. But you don't get to choose how they actually stack up beyond that. The packing algorithm always determines the flow of items.

This makes flexbox and masonry pretty similar in my opinion. Does that mean that masonry should be made consistent with flexbox and therefore support grid-lanes-direction and grid-lanes-wrap?

Overall though, masonry is its own thing

Overall though, masonry is its own thing. It shares a few aspects of both grid and flexbox, but it also has some unique characteristics.

Masonry kind of feels chaotic, both from a developer's and a user's perspective.

From a developer's perspective:

It's hard to control the reading order of items, because the packing algorithm is opportunistic and depends on the sizes of the items already placed in the layout.

If you have very precise control over the number of lanes and the exact size of your items, perhaps you might be able to customize the reading order to what you want. But in that case, wouldn't you be using a CSS grid instead?

The whole point of masonry is that it's easy to use for cases where you don't really care about the order of the items.
And from a user's perspective:

It's also hard to know in which order to read items. An English reader might try to start from the top left and go right, then down. But because of the way items are packed, there might not always be a clear path to follow, and the user might have to jump around the layout to find the next item.

That's why masonry is usually best for image galleries, portfolios, and other cases where the visual arrangement is more important than the reading order.

As a developer, you don't really control the flow, just the direction of packing. And as a user you don't really see the flow either, it looks chaotic and you don't know which order to scan items in. There's no clear reading order. So why trying to set one?

Embrace the chaos!

WebMCP updates, clarifications, and next steps

2026-02-23T00:00:00Z

Six months have pased since I wrote about WebMCP. Both an eternity in the world of AI, and a blink of an eye in the world of web standards.

In my earlier post, I introduced the general idea: letting you, web developers, register tools on your pages so AI agents can use them. The proposal is still evolving, and I wanted to provide a quick update, as well as some corrections to my original post.

If you've heard about WebMCP recently, that's likely because Google Chrome announced their early preview. Keep in mind, however, that WebMCP isn't from a single vendor. It's Microsoft and Google working closely together through the Web Machine Learning Working Group at W3C. That's many people collaborating to shape how AI agents will soon interact with the web.

WebMCP and MCP: clearing up the confusion

In my first post, I said that the browser acted as an MCP server. That's not exactly right. I was simplifying how WebMCP relates to the Model Context Protocol.

The spirit of it is correct. The browser does become an agent-accessible interface to the page. But the reality is more nuanced:

MCP is three layers stacked together:

Primitives: the tools, resources, prompts, etc.
Data layer: how the MCP client and server talk.
Transport layer: how messages move around.

WebMCP only really cares about that first layer. A WebMCP tool looks almost exactly like an MCP tool. Same name, same description, same input schema, same implementation function.

But the browser handles the other two layers for you. The spec even says this outright:

Implementation of the data layer to arbitrate access to these primitives for an Agent is left to the browser.

Why does this matter? A few reasons:

The browser can stay compatible as MCP evolves. You don't break when the protocol changes.
The browser can enforce web-specific security policies, for keeping users safe.
You don't implement MCP yourself. You just write JavaScript functions. That's it.
The API feels natural for web development.

So what is WebMCP really? It's an API for exposing tools from a webpage. The browser then translates those tools into MCP format when talking to agents. Under the hood, the browser is doing the protocol work for you.

The spec uses the term Model context provider. Through navigator.modelContext.provideContext() (and other APIs), your webpage provides context. It provides the tools that an AI agent then uses, but it's the browser that talks to the agent.

What's new since August 2025?

As a result of the collaboration, the spec keeps getting better. It's still in draft form as of early 2026, but the core API design is taking shape. Here are the highlights of what's new since August 2025:

API naming: The API now lives at window.navigator.modelContext. Earlier versions called it window.agent.
User interaction built-in: The spec now has agent.requestUserInteraction() to let tools ask the browser to get user confirmation before doing something. This is to keep the human in the loop, and prevent an AI agent from completing a purchase without asking you first.
Smarter tool management: You still have navigator.modelContext.provideContext() to set all tools at once, but now there's also registerTool() and unregisterTool(). This is great for single-page apps where you want to enable or disable specific tools based on what's happening in your app.
MCP relationship spelled out: The spec now has a whole section on "Intersection with MCP".

What's next?

AI agents are already using the web, that much is true. On the Edge team, we care about keeping not only the human in the loop, but developers too. That's why we care about WebMCP and will continue to collaborate with the community to improve it.

The best way to make it great is by testing it with real scenarios and then providing informed feedback. Google's early preview is a great step towards this, and stay tuned for more news from the Edge team as well!

In the meantime, if you have ideas, feedback, concerns, or just want to get involved, please take a look at the proposal and reach out, for example by opening a new issue or jumping into existing discussions.

Making keyboard navigation effortless

2026-03-05T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2026/03/05/making-keyboard-navigation-effortless/

Using CSS animations as state machines to remember focus and hover states with CSS only

2026-03-09T00:00:00Z

Recently, I was searching for a way to style an element depending on whether it was ever focused.

I wanted to do this without JavaScript, just with CSS, because I was going to use it in a demo about the new focusgroup web platform feature. Focusgroup handles a lot of keyboard navigation logic for you, for free, with only an HTML attribute. So adding a bunch of JavaScript code to track past focus states to that demo felt like a step back.

I kept thinking about this problem, but couldn't find a solution. See, storing a click state is easy. You can use a checkbox element and then apply styles based on whether its :checked pseudo-class matches. You can also hide the checkbox itself and only show its corresponding <label> element if you prefer. Heck, you can even put your checkbox anywhere you want and then use the :has() pseudo-class to style other elements based on that checkbox's state.

But, I couldn't find anything similar for tracking if an element had been focused. And then, it hit me: what if I used a CSS animation for this?

Using CSS animations as state machines

CSS animations are basically state machines. They can change the value of any property over time. The trick is advancing the time to the right point, in order to reach the state you want to remember, and then keep it there.

Fortunately, CSS animations come with two very useful properties:

animation-play-state, which we can use to pause the animation in its initial state.
animation-fill-mode: forwards, which we can use to keep the animation in its end state after it finishes.

Let's use these properties to set up our animation:

.remember-focus {
  animation-name: remember-focus;
  animation-duration: .00001s;
  animation-timing-function: linear;
  animation-fill-mode: forwards;
  animation-play-state: paused;
}

Or, using the shorthand syntax:

.remember-focus {
  animation: remember-focus .00001s linear forwards paused;
}

The .remember-focus class sets an animation on the element, keeping it paused for now, but filling forwards so it retains the end state once it runs.

Notice the weirdly short animation duration of .00001s. That's because we want the animation to reach its end state immediately after starting. The duration needs to be short enough to be effectively instant to the user.

Whenever we're ready to change the state, all we have to do is play the animation. Let's say we want to do this when the element receives the user focus:

.remember-focus:focus {
  animation-play-state: running;
}

Now all we need to do is define the animation itself, via the @keyframes rule. Let's use background colors for now, to make things simple:

@keyframes remember-focus {
  from {
    background: red;
  }
  to {
    background: blue;
  }
}

And there we have it. By default, the element on which the .remember-focus class is applied will have a red background. And then, when it receives focus, the animation will run and immediately change the background color to blue. Because of animation-fill-mode: forwards, the element will stay blue even after it loses focus.

The cool thing is that that state of the animation is associated to its element, so even if multiple elements have the .remember-focus class, each one will remember its own focus state independently.

Demos

Here's a live demo of the code we've just seen. Click or tab to focus the box: the color changes. The color stays even if click somewhere else or tab to another element:

Click or tab to focus me

This technique works with the :hover pseudo-class as well. Just change the selector to .remember-focus:hover and the animation will run on hover instead of focus.

Here's a demo that uses hover instead of focus, and has multiple elements with the same class. Try hovering over the boxes below to see them change color:

Animating other properties

Of course changing colors is just a simple thing you can do with this. But, CSS animations are capable of changing any property, including custom properties, and even properties that can't be animated.

For example, to display an icon next to an element that was focused, you could use the technique to animate the content property of the element's ::after pseudo, even if content is not animatable.

Try it yourself: focus the first box below, and then use tab to navigate to the next boxes. You'll see the icon next to the boxes you've already focused change:

Box 1

Box 2

Box 3

Box 4

Box 5

Using style container queries as an `if` statement

Let's conclude by refactoring the code a little bit so it's easier to reuse in multiple places.

First, let's use the technique to swap the value of a custom property called --was-focused:

.track-focus {
  --was-focused: false;
  animation: track-focus .00001s linear forwards paused;
}
.track-focus:focus-within {
  animation-play-state: running;
}
@keyframes track-focus {
  to { --was-focused: true; }
}

Now, we can use this by applying the .track-focus class to any element we want to track the focus state of. For example, a couple of form labels with inputs in them:

<form class="my-form">
  <label class="track-focus" for="name">
    Your name
    <input type="text" id="name">
  </label>
  <label class="track-focus" for="email">
    Your email
    <input type="text" id="email">
  </label>
</form>

Then, to actually use the --was-focused property, we can use a container style query. This way, we can conditionally apply styles to the element itself or to any of its descendants, depending on whether it was ever focused:

@container style(--was-focused: true) {
  input {
    background: lightgreen;
  }
}

And here is the result:

That's it. Let me know if you find a cool use case for this technique, or if you have other ideas to improve it.

Make custom elements behave with scoped registries

2026-03-09T00:00:00Z

Read the full article at https://developer.chrome.com/blog/scoped-registries

Abusing customizable selects

2026-03-11T00:00:00Z

Read the full article at https://css-tricks.com/abusing-customizable-selects/

Monitor and improve your web app’s load performance

2026-03-17T00:00:00Z

Read the full article at https://blogs.windows.com/msedgedev/2026/03/17/monitor-and-improve-your-web-apps-load-performance/

Install web apps with the new HTML install element

2026-05-13T00:00:00Z

Read the full article at https://developer.chrome.com/blog/install-element-ot