CSS 变量有哪些优点和缺点?

发布于 2024-09-07 02:30:03 字数 467 浏览 4 评论 0原文

我面临一个业务需求,我相信可以通过实现 CSS 变量来解决该需求。

基本上,虽然该项目的前端开发人员负责 CSS 实现,但设计师希望能够为网站引入不同的“主题”。

通过将一个主题替换为另一个主题,可以进行一系列更改(例如字体大小、字体颜色、边框宽度等),而无需更改太多代码。

目前,我们正在尝试通过将组件的样式拆分为不同的 CSS 文件来满足这一要求 - 例如,一个用于布局,一个用于排版,一个用于颜色,等等。

但我不喜欢这种方法。这使得 CSS 非常难以维护,并且很难将所有 CSS 分离出一个特定的组件,而这正成为一种常见的需求。

我希望引入一组标准的“变量”,它可以与特定的主题相关联。

CSS 将被预处理,变量将根据所使用的主题交换为实际值。

这将使我们的开发人员能够最有效地组织我们的代码,同时仍然保持足够的灵活性,以便根据设计者的品味进行定制。

对这个的优点/缺点有什么想法吗?

I'm faced with a business requirement that I believe may be solved by implementing CSS variables.

Basically, while the front-end developers on this project are in charge of CSS implementation, the designer wants to be able to introduce different "themes" for the site.

By swapping one theme for another, a range of changes (such as font-size, font color, border width, etc) can be made without having to change too much code.

Currently we're trying to fit this requirement by splitting up the styling of components into different CSS files - e.g. one for layout, one for typography, one for colors, etc.

But I don't like this approach. It makes the CSS quite unmaintainable, and it's difficult to separate out all the CSS for one particular component, which is becoming a frequent requirement.

I'm hoping to instead introduce a standard set of "variables", which can be tied to a particular theme.

The CSS will be pre-processed and the variables will be swapped for the actual value depending on the theme used.

This will enable us developers to organize our code most effectively, while still keeping it flexible enough to be customized according to the designer's tastes.

Any thoughts on the pro's/con's of this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

一场春暖 2024-09-14 02:30:03

我能想到的唯一缺点是必须使用或编写预处理器并适当管理输出的缓存以避免每个请求都通过预处理器,从而增加了复杂性。

当您使用新的变量语法时,您可能还会在编辑器中遇到语法突出显示的一些问题,但这或许可以解决。

除此之外,我想应该都是优点吧。

您可能有兴趣查看 LESS

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}

The only disadvantage that I can think of is the added complexity of having to use or write a pre-processor, and appropriately manage the caching of the output in order not to have each request pass through the pre-processor.

You might also have some issues with syntax highlighting in editors when you use your new variable syntax, but that can probably could be solved.

Apart from that, I guess it should be all advantages.

You might be interested in checking out LESS:

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}
执着的年纪 2024-09-14 02:30:03

预处理 CSS 似乎是个好主意。我看到的缺点是,这种额外的抽象会带来它自己的问题——处理代码中的错误可能会导致无效或有错误的 CSS。随着时间的推移,事情可能会变得难以维持。

您可能希望拥有一个不带变量的完全工作的 CSS,然后拥有另一个具有最少所需变量内容的预处理 CSS,它会覆盖原始 CSS。

Pre-processing a CSS seems like a good idea. The disadvantage I see is that, this additional abstraction will entail its own problems - bugs in the processing code might lead to an invalid or buggy CSS. Overtime things might become difficult to maintain.

You might want to have one fully working CSS without the variable, and then have another pre-processed CSS with the minimal required variable stuff, which overrides the original CSS.

凉墨 2024-09-14 02:30:03

我没有看到比为主题使用不同的 css 文件有任何改进:你说你只是添加一些变量来更改字体、颜色等。边界、对齐和许多其他东西怎么样?主题不仅仅是 2-3 个颜色变量。较大网页的主题可能会变得相当大,并且同一页面的不同主题可能不仅有一些颜色代码的不同。我认为这不是一个好主意。让前端设计师只需为主题创建不同的 css 文件并加载属于某个主题的 css 文件即可。

I don't see any improvement over just having different css-files for the themes: You say you just add some variables to change fonts, colors and the like. What about borders, alignment and a lot of other stuff? Themes are not just 2-3 color variables. A theme for a bigger webpage can get pretty big and different themes for the same page might not only differ by a few colorcodes. I don't think it's a good idea. Let the front-end designers just create different css-files for the themes and load the css-files that belong to a theme.

拍不死你 2024-09-14 02:30:03

一个很大的缺点当然是你不再编写CSS了。您正在使用一种可编译为 CSS 的专有语言进行编写。发明你自己的编程语言是一本关于商业的坏主意的书的第一页。如果你这样做是为了一个实验或个人项目,那么就继续吧,但否则我会说你是在自找麻烦。

我可以预见的一个具体问题是,开发人员可能拥有知道如何处理 CSS 的编辑器/IDE,但不知道如何处理您的 CSS 方言。这可能会在很大程度上限制上述开发人员。

但实际上 - 重点不是列出优点和缺点。关键是你正在进入未知的领域,从原则上讲,这是一个坏主意,除非这是你的核心业务。

编辑:

我只是想稍微调整一下我的回答。从技术角度来看,这很可能是一个好主意 - 取决于您对环境的控制程度、您回溯步骤的能力等等。这本质上是一种外部 DSL,它可以是一种非常强大的工具。不过,我认为我不会在这里应用它,因为您的目标是(前端)开发人员,并且我认为外部 DSL 更适合管理员/非开发人员。但它可以被成功使用。

我主要担心的是,您只是从技术角度来解决这个问题,这对于我们开发人员来说是一个常见的谬误。从商业角度来看(假设您是一家企业),这可能是一个非常糟糕的主意。这就是我试图表达的。

A big disadvantage is certainly that you aren't writing CSS anymore. You are writing in a proprietary language, that compiles to CSS. Inventing your own programming language is on page one of the things-that-are-a-bad-idea-for-business book. If you are doing this as an experiment or for a personal project, then go ahead, but otherwise I'd say that you're asking for trouble.

A concrete problem I could foresee is that developers might have editors/IDE's that knows how to deal with CSS, but don't know how to deal with your dialect of CSS. That could restrict said developers quite a bit.

But really - The point isn't listing up pros and cons. The point is that you're moving into uncharted territory, and that's - out of principle - a bad idea, unless it's your core business.

Edit:

I'd just like to moderate my answer a bit. From a technical perspective, it may well be a good idea - Depending on how well you control your environment, how able you are to retrace your steps and a lot more. This is essentially a type of external-DSL, which can be a very powerful instrument. I don't think I would apply it here though, since you're targeting (frontend) developers, and I think external-DSL's are better used at administrators/non-developers. But it could be used successfully.

My main concern is that you're only approaching this from a technical point of view, which is a common fallacy for us developers. From a business-perspective (assuming you are a business), it's probably a really bad idea. That's what I was trying to voice.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文