- From: Brendan Falkowski <notifications@github.com>
- Date: Mon, 30 Sep 2019 14:59:41 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/843/536770313@github.com>
Frontend developer here. I wouldn't mind if native specs actually kept the same naming as a widely used library. Most of the time it's the opposite and the standardized name is worse IRL (sorry, CSS custom properties) but with a really great explanation why. If we choose to use web components someday and it conflicts with a project that already uses the CSS modules library, then that's ok. There will probably be a way to transpile the old to new code. None of this works without a constantly maintained build + dependencies, but I understand if the standards process requires that no toes are stepped on if it could break the web. Tough call. I suppose CSS modules could adapt to the spec's use of reserved words. — — — — — — — — — — Aside, I've never liked using the terms `styles` or `stylesheets` when I had an option to say or write CSS. It reminds me too much of the old majority that viewed CSS developers as decorators. So a project we inherit components from writes: `import styles from './button.css';` And we tend to prefer: `import css from './button.css';` If I didn't have to name the import at all (which I wouldn't 99% of the time in a component) then I would prefer it be available as `css`. Styles would make me die a little inside. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/843#issuecomment-536770313
Received on Monday, 30 September 2019 22:00:03 UTC