For example ::placeholder is not supported in Edge and causes a syntax error (flems).

Would be nice if we handled this automatically, and replaced with prefixed versions automatically like we do with css properties.

This might be the time to look into prefixing special css values as well.

I am considering removing them from a new version of zaftig and tightening up the API a bit.

Plan would be to add them back as a helper plugin in a static safe way.

I say it isn't safe because a change to the browser could result in styles breaking, because shorthands are derived from the browser APIs based on their order.

https://developer.mozilla.org/en-US/docs/Web/CSS/@supports

Currently selector gets combined incorrectly, and causes a syntax error.

The name zaftig was chosen initially because it was fairly unique, and justified the use of z but it's not particularly meaningful to what it does, and a bit hard to type (based on some reports).

Currently considering:

• zafty

First of all, what I mean by "theming" is:

1. being able to define variables which influence the style
2. allow components to be notified (for e.g. re-rendering) when those variables change
3. when the active theme's variable change, this effect is propagated automatically to all the interested parties

So going by that concept, by reading the README, I've understood this library does not offer a theming solution.

I've tried to implement it in React

Interesting files

constants.ts

defines the variables for the theme [1st item].

theme.ts

useThemeVariable subscribes to themeChangedCallbacks [2nd item]; due to the fact that it's a hook leveraging useState, the 3rd item is also satisfied.

Button.tsx

Due to useThemeVariable, this components re-renders everytime the theme changes.

What motivated me to do this, initially, was wondering how I'd use Sass' helper functions (darken, lighten, saturate, etc) outside of SCSS files, since that's not directly available with CSS-in-JS. I later found there's the color package for that, so you'd just need to post-process the variable's value after every theme change.

If you feel interested in bringing similar ideas into the library somehow, let me know! And thank you for this project.

Useful for shadow dom or iframes.

Off topic: is generation of inline styles just for file size or are there other performance benefits?

Would be nice to have a section detailing the different coding styles possible with zaftig.

• classic: most styles go inline inside view, directly on the element the style is for
• defining single top level class outside of component and assigning to root element, use nested styles / classes to define styles beyond that
• etc

Currently zaftig doesn't support @import statements, would it make sense to do so? They only work if they're declared as the first rules in the stylesheet.

So would they only work in z.global? I feel like it probably doesn't make sense to implement, since links work fine, and there's less uncertainty about how they can be included..
Including an external stylesheet kind of goes against CSS in JS anyway...

https://developer.mozilla.org/en-US/docs/Web/CSS/@import

Not particularly useful, hurts compatibility with helper libraries, and adds a bit of bloat to the code base (pretty minimal though).

Currently (particularly in prod mode) if one rule has a css syntax error in it the whole style will fail to generate and nothing will be applied, also the syntax error in unclear, because we spit out the whole style string instead of just the rule that failed.

Would be nice to add a try catch to insertRule to log which specific rules failed, and prevent the whole style from failing just because of that one rule.

when I was using this library for the first time, I thought the z.helper API was neat

however, can't the same be done by interpolating expressions directly into the string?

e.g., instead of

z.helper({
  bo: 'border'
})

z`
  bo 4 solid red
`

do

z`
  ${bo(4, 'solid', 'red')}
`

collateral benefit: also results in straightforward type-checking if you're using e.g. TypeScript

this could also be z.style in the "post-processing" phase for effects which depend on updated values (after a hook has triggered an update, for instance)

Is there some advantage I'm failing to see in there? My current impression is that those custom functions are more flexible and also would help in reducing the API.