search

jupyterlab / jupyterlab

JupyterLab computational environment.
https://jupyterlab.readthedocs.io/
Other
14.07k stars 3.31k forks source link

Adopt a CSS library that provides nesting, etc. #5703

Open gnestor opened 5 years ago

gnestor commented 5 years ago

We have discussed many times that something like LESS/SASS would make our lives much easier, mainly because the nesting feature that they provide. We can use this issue to discuss those technologies and develop a plan for potentially adopting one of them.

Some options:

Some features that we want:

bollwyvl commented 5 years ago

It would be great to have some better tooling.

Would like to enter jss in the running:

https://github.com/jupyterlab/jupyterlab/issues/5549#issuecomment-434305039

Otherwise: +1 to postcss/cssnext -1 to less/sass (in 2018, these still flake, and have heavy binary deps built/downloaded at install time)

gnestor commented 5 years ago

Thanks for the feedback @bollwyvl! Yes, JSS looks pretty good but that opens the floodgates to all of the different JS-in-CSS options. Do you have a sense of how JSS compares to others?

ellisonbg commented 5 years ago

A bit more background about this issue. This last summer some interns explored the typestyle library. Conceptually it is similar to jss, but with the strong typing that typescript provides. We have decided to hold off on adopting typestyle broadly, but in the meantime we would like to be able to begin to Nest our css rules. As a result I think for now we don't want to consider jss. instead we should focus on a simple approach that will enable us to write more maintainable CSS through nesting. My own preference is less because of its long-term stability and simplicity.

On Thu, Nov 29, 2018 at 2:55 PM Grant Nestor notifications@github.com wrote:

We have discussed many times that something like LESS/SASS would make our lives much easier, mainly because the nesting feature that they provide. We can use this issue to discuss those technologies and develop a plan for potentially adopting one of them.

Some options:

Some features that we want:

  • Nesting
  • Autoprefix
  • Webpack plugin for compiling to CSS
  • Scoping?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab/issues/5703, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0K2q9Sv9IG91FDQwwUp-MCfL4OBJks5u0GX2gaJpZM4Y6rTr .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

bollwyvl commented 5 years ago

Thanks for the feedback on my armchair architecture. I'd throw my actual vote behind post-cssnext, as it only adopts standards-track syntax. I haven't used less in anger for a while.

Not to flog a dead horse, but jss can also target static CSS files: https://github.com/cssinjs/cli/blob/master/readme.md#convert-jss-to-css

No idea on it's speed, etc. And, like I said, I definitely wasn't looking for js-extensible executable style, just something that could handle nesting and standard variables and look decent encoded as JSON.

bollwyvl commented 5 years ago

Hm, re: cssnext vs standards track, some of the ones it implements have been abandoned:

http://tabatkins.github.io/specs/css-apply-rule/

Guess you can't win.

gnestor commented 5 years ago

It looks like postcss is already in our staging yarn.lock (it looks like css-loader is using postcss) and it's being used in the _travis build.

ellisonbg commented 5 years ago

Do we have a sense of where that usage of coming from?

On Wed, Dec 5, 2018 at 3:43 PM Grant Nestor notifications@github.com wrote:

It looks like postcss is already in our staging yarn.lock https://github.com/jupyterlab/jupyterlab/blob/master/jupyterlab/staging/yarn.lock#L3905-L4148 (it looks like css-loader is using postcss) and it's being used in the _travis build https://github.com/jupyterlab/jupyterlab/blob/1593760ac731234e48ba9c3701bb8dea1d5861ae/scripts/travis_script.sh#L67 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab/issues/5703#issuecomment-444694169, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0G4ZAgL2-jkawF1nzw8C-X7VSeqRks5u2FoGgaJpZM4Y6rTr .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

gnestor commented 5 years ago

webpack css-loader

ellisonbg commented 5 years ago

Ahhh, interesting. I would say we could try to use it, but this stuff worries me:

https://moox.io/blog/deprecating-cssnext/

On Wed, Dec 5, 2018 at 4:17 PM Grant Nestor notifications@github.com wrote:

webpack css-loader

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab/issues/5703#issuecomment-444701010, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0P2TSqakg6nea5MhOM-am6RWwwyvks5u2GIngaJpZM4Y6rTr .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

jasongrout commented 5 years ago

Do we have a sense of where that usage of coming from?

For future reference, you could use yarn why postcss

gnestor commented 5 years ago

It appears that cssnext is a postcss plugin. It looks like the postcss project is alive and well but cssnext is deprecated and replaced by postcss-preset-env.

bollwyvl commented 5 years ago

Great, deprecation is a superb reason not to use cssnext!

The replacement looks fine, though, and indeed we have already opted into the core postcss, so the integration risk seems low. Certainly worth exploring vs adding another thing-with-binary-deps to the on-every-user's-machine build chain. Indeed, I wish there was a yarn-why-downloading-random-binaries (e.g. svgo) so we could start to gate adding more of those...

ellisonbg commented 5 years ago

try postcss then?

gnestor commented 5 years ago

Sure, I'll create an issue and submit a PR soon 👍

javag97 commented 5 years ago

Hi! Not to flood the gates on even more CSS-in JS solutions, but that I've wanted to mention that I've of heard of other tools such as styled-components, or emotion.