The biggest problem IMHO is how the unit system with regards to pixels and physical units is designed. A px is not a device pixel but a physical unit of length 1/96 inch. This nonsense is technical not a CSS-only thing but based on a 80s hack by Microsoft and Apple. As a result you can not specify device pixel sizes directly, (you have to calculate them from devicepixelratio in js), and physical units relate to UI scaling on screen.

A use case for specifying device pixel sizes are thin-lined grids, that can have inconsistent spacing and line width due rounding when you use px on hi-DPI.

How it should be (and OSes should do it) is:

- There is the device pixel e.g. "dp"

- There is a UI scaling unit "u" (the equivalent to CSS px, but not with a misleading name). It could be e.g. defined to be the height of a standard button. This is used for most screen-oriented elements, and u-based sizes can be optionally rounded to whole dp.

- There are physical units independent of u. There is a ratio of these to dp. For print the ratio is e.g. so that 1in = 300dp if it is a 300dpi print. For screen the ratio is based on the actual physical pixel density the OS can either derive from a display device, or the user calibrates it. Physical unit based sizes can optionally be rounded to whole dp.

- The user can obviously set the UI scaling and overwrite the physical unit scaling.

This way you can get display pixel based sizes simply and reliably, UI scaling is not based on a often misunderstood "virtual pixel", and physical objects can be displayed on screen with its actual size (or whatever scaling the user wants).

Hard disagree. Not having access to true device pixels is a feature, not a bug -- especially when you consider that common screens today range from 90 dpi to 600 dpi. And then not to mention browser zoom on top of that.

Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore. We use antialiasing instead to ensure that widths and weights maintain proportionality no matter what resolution and zoom level you use. Trying to snap to pixels is an anti-feature with modern screens. It made sense when everyone used low-resolution screens and antialiasing wasn't commonly used in OS's and programs. But it hasn't made sense for well over a decade now.

You already have access to device pixels, you just have to calculate it yourself.

Anti-aliasing is not a good solution for orthogonal lines with low device pixel ratios like 1.25 or 1.5. which will be around for a long time. Browsers disagree with you - they don't use anti-aliasing for orthogonal measurements, they round. Which means they do in fact pixel-snap.

I agree that it can be misused like using device pixels for UI, but my suggestions makes the distinction more explicit.

>Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore.

If you're trying to display pixel art (or make games with pixel art), being able to have integral upsizing is very useful. Antialiasing doesn't cut it, and the eye notices when you do non-integral nearest-neighbour upscaling and some pixels are the wrong size.

Enumerating all 7-Move solutions of today's puzzle, I expected some kind simple pattern, like some key moves with a few permutations. I found that it is far more complex:

- there are 1536 solutions

- almost all moves are useful, non are required

- for every row-xoring move there is exactly one column-xoring move that appears in the same number of solutions (and no move appears twice in a solution)

Here is the number of solutions a move appears in (0-based indices):

  C3→2    R2→3    0
  C3→1    R2→1    82
  C2→0    R3→0    93
  C0→3    R0→2    163
  C2→1    R3→1    342
  C1→3    R1→2    426
  C1→2    R1→3    558
  C3→0    R2→0    614
  C2→3    R3→2    640
  C1→0    R1→0    726
  C0→1    R0→1    810
  C0→2    R0→3    922

That's nifty! There's a lot of symmetry that can help to boil it down. For example, you actually only need row moves, and any solution with column moves can canonically be turned into one with row moves; post-composing with Ci→j is pre-composing with Rj→i.

One can think of the set of all possible board configurations as the vertices as a graph, with edges indicating how to move between configurations. Then your 1536 solutions are the 1536 distinct shortest paths between the starting and target configuration.

Then, you can also choose to consider not just board configurations, but board configurations up to simultaneous permutation of rows and columns; that will also reduce the number of unique solutions.