这完全取决于您使用 CSS 的方式 - 如果您需要应用一些小的更改,请首先在 Firebug/类似工具中“实时”测试它们。在设计阶段(当您还没有最终确定应用程序样式的视图时),您可能希望使用普通的 CSS 文件,但一旦明确了一般样式,您应该切换到 ClientBundle/ CSS资源。
为什么?让我通过写一些关于CssResource 文档页面上列出的目标的想法来回答:
基本的
- 与不支持 GWT 的 CSS 解析器的兼容性(即任何扩展都应该是有效的 CSS 语法)
这并不意味着如果您只是在浏览器中显示样式表就一定有意义- 意思是,我们只想使用有效的 CSS 语法,不是一些对其他解析器来说是胡言乱语的语法糖 - 从您的角度来看可能不是那么重要(尽管因此,您不需要更改现有样式的语法)
- 语法验证-非常重要的一点,恕我直言。您会得到诸如检查丢失(可能拼写错误)的 CSS 类、语法错误等的东西——这些东西必须(通常,痛苦地)通过某些浏览器特定的开发工具(Firebug)来追踪。在这里,您可以在编译时及早发现这些错误(或者在 Google Eclipse 插件的帮助下甚至更快)。
- 缩小- 这不是您的常规缩小,您还可以合并选择器和属性。也请参阅下一点。
- 利用 GWT 编译器- 如果不使用 CSS 类(GWT 编译器可以做出这样的区分,因为它具有整个应用程序的概览),它会被修剪并且不包含在编译的代码中。您有多少次发现在一些设计更改后留下的 CSS 类?这会解决这个问题(另请参阅 CSS 模块化点)
- 自动为不同的浏览器使用不同的 CSS - 由于以这种方式生成的 CSS 包含在您的 JS 代码中,因此它可以(并且已经)针对目标浏览器进行了优化 - 无需在每个排列中都包含冗长的 IE hack!
- 内容的静态评估- 之前已经提到过
中学
- 基本 CSS 模块化
- 通过依赖注入 API 样式- 您可以根据需要注入 CssResources(例如,以促进应用程序中的自定义主题)
- 小部件只能在需要时注入它们自己的 CSS——这是我最喜欢的一点,虽然起初我没有看到它的意义——你将(通常)巨大的、单一的 CSS 文件分成小模块,每个小模块一个使用 UiBinder(它反过来在
CssResource
内部使用)加上一个全局 CssResource 用于应用程序范围的样式。这导致更清洁、更易于维护的 CSS 样式(至少,根据我的经验)。这也意味着,如果您的代码不使用特定的 Widget(可能是因为您使用了 ocde 拆分并且尚未加载它),您将不会下载这些样式。
- BiDi(Janus 风格?) - 双向文本支持,尚未使用,但文档看起来很有希望 :)
- CSS 图像条- 自动生成图像精灵- 我还能说什么?;)
- “改进 CSS”
- 常量——我一直错过 CSS 规范中的这个特性——当你改变你的原色时,你必须在整个文件中找到并替换它(可能会导致一些错误,你想在某些地方) - 这使得它更直观,恕我直言,通过引入常量(通过有效的 CSS 语法并且没有任何运行时损失)
- 简单的表达式——你应该浏览一下文档,看看那里的可能性,真的很酷的东西
第三
- 运行时操作(StyleElement.setEnabled() 处理许多情况) - 在样式表注入时(在运行时),评估一些值 - 这允许蒙皮等。
- 编译时类名检查 (Java/CSS) - 已经提到了这个的(明显的)好处
- 混淆——这个也很酷,GWT 编译器可以安全地混淆 CssResources 中的所有样式,因为它具有整个应用程序的概览——因此,名称冲突是不可能的。这意味着您可以使用长的(但不能太长;))、有意义的类名,而不必担心这将如何影响应用程序的大小——它都会被混淆为漂亮、短(甚至 1-2 个字符长),随机字符串。这也使您能够
.warning
在两个 Widget 中定义一个样式,编译器将理解这两种样式位于不同的命名空间(不同的 Widget)中,因此应该区别对待(即混淆为不同的名称)。
关于样式注入
该类StyleInjector
允许在运行时注入样式。此外,CssResource
允许(至少根据文档,我还没有尝试过)运行时替换。例如,当您注入CssResource
包含以下内容的 a 时:
@eval userBackground com.module.UserPreferences.getUserBackground();
div {
background: userBackground;
}
将userBackground
被评估和注入(与在运行时解析的常量相反)。