styled-components / spec Goto Github PK

I expect the pure css folk (like myself) to ask simple, basic questions, regarding how they'd do what they already do easily in css, with xyz css-in-js solution. I'm just starting the same for glamor, but sharing the qn titles to get some feedback -

how do I -

• apply a style to a single element
• apply a style to a class of elements
• attribute selectors
• pseudo classes
• specificity
• apply style based on relationships with other elements
• font faces/keyframes/media queries

what am I missing? cheers.

I just wanted to make it more explicit that it is in the Readme:

This org's purpose is to collect discussion about all the possible requirements of a component-oriented CSS solution for JavaScript. There are a lot of libraries out there already, many of which solve most of these problems, but all the discussions around them are fractured across twitter, medium, issues and gists.

So we're trying to approach it from a different perspective: collect the ideas and discuss the issues in a single place, making it easier for the community to follow and engage with.

Hopefully, one (or more) of the current crop of libraries evolves to a point where they meet the goals & requirements we work out through this collaborative process. If not, maybe we have a spec to build one. If any of the existing libraries have either (a) technical limitations preventing them from being the whole solution, or (b) different design goals, that's cool - that is no judgement on them, and it's very unlikely a "one size fits all" solution is possible.

If you lead, or know of, a library that works well for css components, shout out here and consider adding an implementation to the comparison repo!

Of the listed competing solutions, two are essentially runtime solutions in JS (CSS in JS and inline styles) and two are available to be handled by generic build tools (css + postcss and sass).

Should cross-language be a concern?

Which item in the dot points does CSS modules not meet?

So I guess because of the Cascade and Selector parts of CSS, no matter what's chosen there's no real way to restrict someone including a stylesheet that styles a "pre-styled" component.

Are there more specific features desired when it comes to overriding styles?

One caveat with frameworks that inject CSS at runtime (v those that use inline styles or generate styles at compile time) is that they can leak implementation details if they make use of buffering.

Aphrodite notes this caveat here: https://github.com/Khan/aphrodite#style-injection-and-buffering

we need to write code(pseudo code) for component which will show identified problems
And focus the description of all the problems

Based on a discussion in styled-components/comparison#31 (comment), I think we might need to rename the lightweightness category. In the comparison repo I changed the Checklist for the different methods to be this:

- ✅ No build requirements
- 😕 Small and lightweight
- ✅ Supports global CSS
- ✅ Supports entirety of CSS
- ✅ Colocated
- ✅ Isolated
- ✅ Doesn’t break inline styles
- 😕 Easy to override
- ❌ Theming
- ❌ Pre-build
- ✅ Server side rendering
- ❌ No wrapper components

_{Legend: ✅ = Yes, ❌ = No, 😕 = Kinda, refer to notes or parentheses}

But I think what we really want to say with lightweightness is setup complexity. None of the current methods is anywhere near "too big" imo.

/cc @kof

cc @jquense @threepointone @vjeux @JedWatson @ryanflorence

ref Medium article, @Vjeux Gist, @taion Gist (esp. @threepointone comment), css-modules/css-modules#147

It's somewhat difficult in the current componentized CSS solutions to handle cases like:

<InlineForm>
  <EmailInput />
  <PasswordInput />
  <LoginButton />
</InlineForm>

or

<InlineForm>
  <EmailInput />
  <PasswordInput />
  <SomeComponent>
    <LoginButton />
  </SomeComponent>
</InlineForm>

There may well be styling that you want to attach to buttons that render in specific contexts. With normal CSS, you'd write selectors that look like .form-inline > .btn or .form-inline .btn.

With componentized CSS, it can be more difficult. Depending on use case, sometimes this styling should go in <Button>, and sometimes perhaps it should go in <InlineForm>.

You can achieve similar behavior to these selectors with various combinations of React context and cloning children with additional props. However, for more complex selectors including e.g. :first-child or :last-child, the equivalent code gets a bit more complicated.

I think the question becomes:

• Is it possible to make a nice JS API that can cover similar use cases to CSS selectors, with a similar level of ease-of-use
• Is it possible to just incorporate CSS selectors while still keeping styles encapsulated, and while limiting the scope for overriding styles

Well, that's the best high-level summary I can synthesize. Let me know what I got wrong.