search

readthedocs / addons

JavaScript client to integrate with Read the Docs nicely
https://readthedocs-addons.readthedocs.io/
MIT License
20 stars 5 forks source link

CSS: next steps for CSS and styles #39

Open agjohnson opened 1 year ago

agjohnson commented 1 year ago

Some items that we're not yet focusing on, and should save for some later work:

Introduce [Less.js]()

We could further reduce the amount of CSS that we're maintaining with the help of a preprocessor. Less.js is lightweight, used in other projects of ours ^1, and avoids complications from using the wrong SASS/gyp/python/etc. SCSS is indeed comparable, but there is confusion around SASS (and subsequent issues with gyp) and Dart implementations.

Responsive design

We'll want to come back and add media rules for more responsive elements. Our elements/web components will need to work down to mobile, most ideally. This shouldn't be difficult for warning messages, will be slightly harder for a flyout, and most difficult for a responsive search input box.

Publish more on customization patterns

We're starting to experiment with web component CSS styling customization through variables. We'll need to decide if we need to implement anything between this level of customization and pushing the user towards consuming our API.

zanderle commented 1 year ago

We might also want to consider using less.js along with postcss for some extra capabilities (like auto-prefixing)

agjohnson commented 1 year ago

Yeah, certainly if there is a benefit we could get out of postcss, that could be considered. Not just here either but in other repositories/projects.

If we add more tooling, I lean towards keep our tooling stack the same or at least very similar on all of our other front end or JS projects. Without a lot of core team experience on JS and front end tooling/libraries, keeping our stacks similar will help avoid spreading the team too thin on knowledge.

I certainly think there is room to adopt new tools though, so this is worth keeping in mind. Be sure to note any areas here, or other repositories, where a tooling change could help!

For prefixing specifically, the shadow DOM helps tremendously here. I actually don't even know if I have hit an area where I really wanted to use Less. Our styles have felt far more maintainable with the shadow DOM providing us isolation, but if anything changes our minds it will be search and the flyout.

zanderle commented 1 year ago

Sounds good 👍

For prefixing specifically, the shadow DOM helps tremendously here. I actually don't even know if I have hit an area where I really wanted to use Less. Our styles have felt far more maintainable with the shadow DOM providing us isolation, but if anything changes our minds it will be search and the flyout.

With prefixing I meant vendor prefixing (which granted, is not necessary either, depending on our CSS)

agjohnson commented 1 year ago

Aye, that would be a more likely case for sure. I'm so far assuming we won't get too fancy with our styles, but I'd certainly let the UI/UX design dictate our needs too. We've used SASS/Less mixins for similar in the past, so could also always start there if we hit that particular wall.