pollen VS csswg-drafts

Curious to know if anyone has compared this to Pollen:

https://www.pollen.style/

I’ve used Pollen as an alternative to the bulk of Tailwind and have been very happy with it.

So frameworks like https://www.pollen.style/ are doing this. Personally I still prefer the tailwind approach.

I do think that the real value of Tailwind comes from the utility classes, rather than css-in-html paradigm. You could achieve the same, for example, with Pollen.css [0] or Open Props [1].

[0] https://github.com/heybokeh/pollen

[1] https://github.com/argyleink/open-props

Tailwind is a great option to look into, I really enjoy it, but if you want something a bit more in-between, you can check out frameworks like https://www.pollen.style. There you get a framework of consistent CSS variables you can use, while still writing all your vanilla CSS yourself with full control of everything.

It uses UnoCSS (think TailwindCSS but super customizeable) with Pollen (which is similar to open props).

Very similar to Pollen (https://www.pollen.style), though it looks a little more complicated.

IMO the main value of Tailwind is that it's a step function over your units and colors, which helps bring better consistency and dev speed to UI implementation.

Tailwind's "write class names instead of CSS" approach makes sense in the component-based systems most apps are built in these days, where pretty much any repeated markup will be turned into a component. It performs better than scoped styles and is less complicated.

A CSS variable approach like Open Props or Pollen is, in my experience, better if you're not using a component-based system (ie. conventional HTML) and therefore have repeated markup patterns. Having a simple class name to apply to repeated markup is much more maintainable than trying to copy/paste a long tailwind string around.

Pollen and Open Props are two popular examples of such token first frameworks. If you are not familiar with CSS Custom Properties (also called CSS variables), I recently wrote about how to use them to create a CSS Style API layer.

In the last few years, a new set of frameworks with a radically different concept drew the attention of frontend developers. These frameworks are now extremely popular in the frontend world, and you’re likely already familiar with them: Tailwind CSS and Pollen.

The CSS Working Group developed a promising solution in the interactivity property draft. https://github.com/w3c/csswg-drafts/issues/10711

There's many factors in play from what your SDR white point is at, how your OS handles HDR video, what the content contains, and finally what your brain is doing.

HDR10(+) & Dolby Vision, for example, encode content at absolute luminance, so they are basically completely trash formats since that's an insane thing to expect. Sadly, they are also quite common. Mobile phones (both Android & iOS) are instead pushing HLG, which is better. Although then hilariously MacOS's handling of HLG was atrocious until the latest update which fixed it but only if the video contains a magic flag that iPhone sets, but isn't standard so nobody else sets it (the "avme" tag https://developer.apple.com/documentation/technotes/tn3145-h... )

There's then also just how your eyes & brain react. When HDR shows up and suddenly the white background of a page looks like a dim gray? That's 100% a perceptual illusion. The actual light being emitted didn't change, just your perception of it did. This is a very hard problem to deal with, and it's one that so far the HDR industry as a whole has basically just ignored. But it's why there's a push to artificially limit the HDR range in mixed conditions, eg https://github.com/w3c/csswg-drafts/issues/9074

related:

https://github.com/w3c/csswg-drafts/issues/10674

> Perhaps the authors can find inspiration by looking at CSS houdini, which tries to make CSS extensible

Pluggable layout algorithms are definitely something I'd like to enable in Blitz. I suspect JS for layout will be too slow in most cases. But this is an area in which we have an advantage with our API being in Rust. And our layout engine Taffy (https://github.com/DioxusLabs/taffy) is already highly modular.

Custom widgets would go beyond just layout and allow for fully custom layout, paint, accessibility, event handling, etc similar to a widget in a traditional GUI toolkit like GTK or Cocoa.

I also have a proposal to add a new unit to CSS itself (inspired by how many non-web UI systems do layout), which has the potential to greatly simplify web layout in the common cases https://github.com/w3c/csswg-drafts/issues/8267. It's been on the back burner for a bit, but I should really get back to it at some point (I really want to actually implement the algorithms).

Lets see how this will work ( according to the proposal ):

Github Issues Discussion

For more background, and some detailed discussion of the opposite argument ("display: masonry" over "display:grid"+"grid-template-rows: masonry") see https://github.com/w3c/csswg-drafts/issues/9041

The tracking issue: https://github.com/w3c/csswg-drafts/issues/8659

As noted there, okHSL/HSV keeps the perceptual uniformity by removing some peaks beyond the geometric limit of HSL/HSV, and it is unclear whether it is what users do expect or not.