I'm not sure if you've misunderstood. Designing around a baseline (whatever value you choose) is not very difficult. I'm talking about implementation, especially at larger projects. It becomes relatively messy and very convoluted to support it. At smaller projects that focus on such details it can be definitely worth it (see here for example: How We Implemented a Baseline Grid Using CSS or CSS Baseline: The Good, The Bad And The Ugly ).

In the end it all comes down if you want put in the effort and time to support and update this.

It can definitely work, but only if you have very few text styles and sizes. Basically you just make sure that your line-height is a multiple of 4.

It is, however, extremely impractical for development work, so I don't really understand why anyone would advocate for it in digital. Visually, they align nicely if you design with a baseline grid in mind. But why would any dev implement a work-around just to make this happen for minor visual improvements?

Just make sure that the "soft" grid (individual relative spacing between elements) aligns to the 8-point grid and you're good to go.

What you're describing is a rigid, "hard" grid, where each element sits perfectly on the underlying grid. Doable in your design software by cheating a bit, but since it's also not really technologically feasible, I'd advise against it.

It would be better to use a "soft" grid, where you space your elements relatively to their position, rather than rigid.

Here's a quote from spec.fm about the 8-Point-Grid:

There are actually two prominent versions of this system. One that places elements into a system-displayed grid defined in 8-point increments (we’ll call this the “Hard Grid” method) and another that simply measures 8-point increments between individual elements (we’ll call this the “Soft Grid” method).

The primary argument for the Hard Grid method is that by using additional transparent background elements and then grouping them to small groups of foreground elements, you can keep track of margin and padding on a per-element basis and just snap these containers to the grid like bricks. Material Design - where everything is already designed to a 4pt grid - naturally conforms to this method.

The argument for the Soft Grid method is that when it comes time to code up an interface, using an actual grid is irrelevant because programming languages don’t use that kind of grid structure - it’ll just get thrown away. When the speed at which you arrive at a high-quality, programmable set of mockups is a priority, bypassing Hard Grid’s extra overhead of managing additional layers in favor of Soft Grid’s more fluid, minimal structure can be an advantage. This also can be more favorable to iOS where many system UI elements are not defined by an even grid.

By cheating I mean you could use 0% opacity rectangle layers as background elements and draw 1px shadow or inner shadow. This way the group will remain the "right" size, but you'll have your divider in there.

Area17, for example, solves this "problem" similar to this, just by setting lines off by 1px:

Image listing with 1 pixel horizontal separation lines → Lines are on the 5 x 5 pixel grid which creates asymmetric spacing above and below the lines (like 30 versus 29 px). Here it is possible to “cheat” and forget about 1 px spacing difference, rather keeping the content on the 5 x 5 pixel grid. This is easier to work with and developers will know the space should be the same.

Maybe simply GitHub?

But that has nothing to do with what he asked for?

Might I ask where you got this from? Is this a current one?

Thank you so very much. I haven't come around to test it out yet, but this is a really important feature to have.

To add something of value to this comment: please add the possibility to have the padding set to an arbitrary amount (x, as it was in Paddy). This way we don't have to add empty bounding boxes and it would allow for some really cool possibilities with differently sized chatboxes, for example.

While I agree that any type of vague commitment by companies should be definitely taken with a grain of salt, the context and – I would say – the wording seem to indicate that it is actively pursued (as is corroborated by the statement linked by Ravi Shanker below).

However – and I would certainly like to be wrong on this – I think this kind of feature would warrant another major release, which would mean waiting a long time.

Would you mind elaborating what you mean by that?

Of course it's limited to Mojave – it's built upon native technology that comes with it. Otherwise there would be no dark mode.