custom-properties package exports properties with invalid (for CSS custom prop) names

This could be a feature (or documentation update) request.

Describe the bug Technically this bug is about custom-properties package but it stems from theme property names.

To Reproduce To reproduce this issue we can follow the example form the Usage section of the package readme file.

The only thing to add is some kind of logging, i.e.:

module.exports = () => {
  const customProperties = toCustomProperties(theme, 'theme-ui') // prefix provided

  console.log(customProperties) // the only line added

  return customProperties
}

In the corresponding log you will see generated object properties with names like these (theme-ui prefix was used):

  '--theme-ui-size-1/2': '50%',
  '--theme-ui-size-1/3': '33.333333%',
  '--theme-ui-size-2/3': '66.666667%',
  ...
  '--theme-ui-button-3D-&:hover-transform': 'translateY(-1px)',
  ...
  '--theme-ui-style-th-': first-child-pl: 0, << different issue here: value itself is invalid

While such property names are perfectly fine for JS/TS objects they can’t be used as custom CSS properties wo modification (or filtering out) cause custom CSS property names can’t contain certain special characters. & and / in particular.

Expected behavior To be honest I’m not sure what behavior to expect here. Some property names could be modified (by replacing special chars with - for example) or omitted automatically.

May be nothing needs to be done besides adding a note in the README regarding recommended transformation/filtering steps required before/if the output (customProperties) object is used for setting custom CSS props on the HTML document.

Not sure if there is any public documentation on this package besides README and #1234. Hence it is hard to tell if dumping the output into <style> element is common/supported use case. However naming of the package and the fact that every property gets automatically prefixed with -- implies that it was at least considered.

Screenshots

Chromium v. 90.0.4430.93 on Ubuntu

Additional Context

This should not matter but for my particular scenario (Gatsbyjs website) I was using theme-ui packages this way:

import { merge } from 'lodash';
import { Theme } from 'theme-ui';
// @ts-ignore-next-line
import { toTheme } from '@theme-ui/typography';
import makeCustomProperties from '@theme-ui/custom-properties';
// @ts-ignore-next-line
import { tailwind } from '@theme-ui/presets';

import { options as typographyOptions } from '../utils/typography';

const styles = {} as Record<string, Record<string, any>>;

const themeWoStyles = merge(
  tailwind,
  themeUITypography,
);

// apparently `styles` make it into custom properties export
const customProps = makeCustomProperties(themeWoStyles, 'theme-ui');

// exporting custom properties into HTML through style element
styles.root = {
  ...customProps,
};

const theme = merge(
  themeWoStyles,
  { styles },
);

// eslint-disable-next-line import/no-default-export
export default theme as Theme;

[hasparus]

I really dislike the “silent failure” that’s currently happening, and I think we have two ways to move forward.

1. Escape CSS Custom Properties to emit to make sure we always emit valid properties, and document the transformation in the docs.
2. Document the corner case and declare it as unsupported in the docs. Print an error to user’s console if process.env.NODE_ENV === "development".

[hasparus]

Hey @amalitsky, thanks for the issue!

I could introduce you to the repo or help you with the implementation, but quite frankly I have no opinion on how it should work.

@lachlanjc @atanasster @fcisio? What do you think?