Confusion about style systems

[Mister-Hope]

First congratulations to beta stage. (Though I think it's a little quick)

I should start this dicussion days ago, but I was busy in the past days. I've been very confused about VuePressV2 style system. I see you want to decouple style system out of @vuepress/core and let developers choose what they want to built with styles. They can choose from sass, less, stylus or just css. That's good, but I am meeting some problems in developing, and I wish to find a way to solve it. Here are what I am confusing. @meteorlxy

A plugin can provide Global UIs like pwa-popup or back-to-top, or just providing components like vssue. Let us review what V1 is doing. In V1, all the plugin style system is mostly build in stylus(if they want to use varibales in palette.styl), and @vuepress/core has some built in stylus variables in it's own palette with break point varibles like $MQMobile layout varibles like $homePageWidth so all the vuepress plugins and themes can just use them. So when users config variables like $accentColor, $homePageWidth, themes and plugins can adjust they styles and still in a hamony. (Also they don't need to manually import styles and pattele)

But things are different in V2 now

• first, users may run in to a situation where they want to choose a plugin A using less and theme B using sass togerther. While pattele plugin is not allowed to have mutiple instance, I have to assume that only themeB's plugin is working and set with sass. In this situation, plugin A will probably throw out errors because there isn't a @vuepress/plugin-palette/palette.less.

  I am assuming you would say: plugins can use css variables like var(--accent-color). Yes, it do works in some situation, but it cannot deal with:

  • breakpoints

    as var() only works on property values, @media (min-width: var(--mobile-breakpoint)) won't work

  This is really important because most of the plugins and theme is showing diferent styles and layout on mobile and desktop, and it's really werid if they are not changing together.

  • Color adjustments

  Imposiiable to use color.scale (or functions like lighten and darken in stylus)

  E.g.: a lighten with accentColor is quite common (E.g.: hover or click on a button in accentColor)

  • propertys which need to be calculated

  e.g.: $navBarHeight + 1 rem will generate 4.7rem in sass with a 3.7rem default, but we must write calc(var(--nav-bar-height) + 1rem) in css and that will cause extra rendering work

• second, since the default pattele in core was broken the below is broken

  VuePress follows the principle of "Convention is better than configuration"

  Theme writers will likely to choose the style variable they like to, such as $homeWidth $homeContentWidth $homePageWidth, and there is no way a plugin developer could guess the varible name and set it in it's styles, so I think that users will met the below situations:

  • Plugins with UI often look werid in another unrelated theme
  • Users need to set different varibles in both plugin and theme with same value to let the project look well

The above is my worries about the new style design, And I am not catching up with any solutions solving it. And I am looking forward to your ideas towards them. I think some improvements should be made on the style system.

[meteorlxy]

Though I think it's a little quick

We need to get more feedback from community, so staying in alpha stage and waiting for a perfect release is not a good idea. I personally took "vite support" as the milestone of beta, so I think it's time to go ahead.

---

As you mentioned, css variables are not supported in media query, so we have to keep using pre-processor. However, I don't think the breakpoint variables is an important feature. Maybe we could remove them and use pure css solution like vitepress.

As for the color adjustments, you can provide more variables for them.

---

I found many theme authors are using less or scss to build styles, in such cases, the stylus dependencies and the palette system is just useless.

A cross-theme UI plugin is just not a real thing. Every theme has its own styles, a plugin cannot compatible with all of the styles, even with those global palette variables.

---

You have proposed so many points, I might not answer all of them one by one. I was just sharing some thoughts.

[Mister-Hope]

In short, the new style system is good when UI is all in themes, while plugins can not access pattele and hard to provide a convenient style customization.

I think we'd better provide a better way for plugins to provide style customization support.

[meteorlxy]

In fact, the palette is possible for plugins. Current palette plugin could be enhanced to support multiple instance

[Mister-Hope]

In fact, the palette is possible for plugins. Current palette plugin could be enhanced to support multiple instance

That's good.

My personal idea is that a pattele.styl, pattele.less and pattele.scss is better than plugin-A.less plugin-BC.scss, plugin-EFG.less.

So I hope the plugin should work well when the multiple instance is pointing to the same user file(e.g.: styles.scss), and no duplicated styles are generated.

[Mister-Hope]

If anyone have similar thoughs and confusion, you may use vuepress-plugin-sass-palette, as it's designed to share styles across different "sets" of themes and plugins, supporting both sharing in a set and not conflict with other sets.

Also, you are free to config both sass variables and css variables.