有两种学派的思想。一些开发人员更喜欢使用 CSS资源。

我对GWT和多个项目有7年的经验后，我的强烈偏好是对所有样式都有一个外部CSS文件。我甚至不包含任何GWT样式表（包括DataGrid样式） - 我将它们的内容复制到我的CSS文件中。这些都是这种偏好的原因：

1. CSS被称为级联样式表，因为它是基于继承而构建的。专业的网页设计师从最顶层（html，body元素）开始构建应用程序设计，并为整个应用程序定义规则：要使用的字体或字体，调色板，标准边距和填充，标准网格（列宽），等等。这些规则必须在整个应用程序中传播。一旦开发人员开始在视图/小部件级别定义自己的样式，几乎不可能确保整个应用程序的任何设计一致性。

更重要的是，当CSS规则被分成许多不同的来源，很难预测它们之间的相互作用。为什么这个元素位置不正确或字体大小错误？是因为我在小部件CSS中使用了错误的选择器，还是因为某些其他CSS资源的其他规则会覆盖或冲突它？现在，您会发现自己在不同样式表之间跳来跳去，试图使其发挥作用。 的样式表，现在您必须检查此更改如何影响其他视图和小部件。在DOM树的顶部进行更改会影响底部的每个元素（同样，它是级联的！）。通常情况下，在每个浏览器中预测这种影响并不容易。 当您尝试使您的应用设计响应并使您的应用变得更加重要时，这些考虑变得更加重要很好地适应不同的屏幕尺寸。当您在主CSS文件中添加媒体查询时，您的视图或小部件级别的CSS会发生什么？ 另一个重要的点是开发速度。如果您使用专业设计的CSS文件，几乎不需要 CSS在视图或小部件级别。例如，当我添加一个新表单时，我从不需要任何CSS - 我只是抛出一系列标签和输入小部件，并且它们突然看起来正确，并且它们被正确定位，因为规则已经设置好了，它们适用于所有表单，输入元素，标签等。我不认为在小部件中使用什么字体大小或颜色。例如，我只是使用一个< h2> 标题，它在浅色皮肤中具有一种颜色，在深色皮肤中具有不同颜色，并且它改变其大小并且最后，从小部件中移出尽可能多的CSS使得在新项目中重用它们变得更加容易。使用相同的例子，如果一个头文件没有在一个小部件中指定的font-family，font-size，color或margin，它将从另一个应用的CSS文件中获取这些值（这可能与规则可能相同也可能不相同贡献项目的文件）。因此，您可以在不触及其代码的情况下在新项目中重新使用该小部件，这又加速了开发过程，并使维护变得更加轻松。

$总而言之，单个CSS文件可以更轻松地在整个应用程序中实施样式一致性并维护代码，并大大加快了开发速度。

We have a medium size application with around 30 views. We have many CSS files laying around. Some are specialized (popup styles) but the rest contains style for different parts of the application, in addition of the style embedded in the *.ui.xml and it's start to get pretty messy.

Is there any guideline on how to structure the styling in a GWT application and in a web application in general ? How do you structure yours ?

There are two schools of thought on this. Some developers prefer to use CSS Resources.

My strong preference, after 7 years of experience with GWT and multiple projects, is to have a single external CSS file for all styles. I even do not include any GWT stylesheets (including DataGrid styles) - I copy their content into my CSS file. These are the reasons for this preference:

1. CSS is called a cascading style sheet for a reason - it is build around inheritance. A professional web designer builds an app design starting from the very top (html, body elements) and defines the rules for the entire application: font or fonts to be used, color palette, standard margins and paddings, standard grid (columns width), etc. These rules must propagate throughout the entire app. Once developers start defining their own styles at the view/widget level, it's nearly impossible to ensure any design consistency across the app.

2. Even more importantly, when the CSS rules are split between many different sources, it becomes very hard to predict their interactions. Why is this element not positioned correctly or has the wrong font size? Is it because I used the wrong selector in the widget CSS, or is this because some other rule from some other CSS resource overrides or conflicts with it? Now you find yourself jumping back and forth between different stylesheets trying to make it work.

3. Even if you do find a source of the problem and fix it in one of the stylesheets, now you have to check how this change affected other views and widgets. Making a change at the top of the DOM tree can impact every element at the bottom (again, it's cascading!). Often it's not easy to anticipate this impact in every browser possible.

4. These considerations become even more important when you try to make your app design responsive and make your app adjust nicely to different screen sizes. What happens to your view or widget-level CSS when you add a media query in your main CSS file?

5. Another important point is the speed of development. If you use a professionally designed CSS file, you almost do not need CSS at a view or widget level. When I add a new form, for example, I never need any CSS - I just throw a sequence of labels and input widgets and they all suddenly look right and they are positioned correctly, because the rules have been already set and they apply to all forms, input elements, labels, etc. in the app. I do not think what font size or color to use in a widget. I just use a <h2> header, for example, and it has one color in a light skin and a different color in a dark skin, and it changes its size and margins according to the screen size.

6. Finally, moving as much CSS away from the widgets makes it easier to reuse them in new projects. Using the same example, if a header does not have a font-family, font-size, color or margins specified in a widget, it will take these values from another app's CSS file (which may or may not be the same rules as the contributing project's file). So you can reuse the widget in a new project without touching its code, which again speeds up the development process and makes maintenance so much easier.

To summarize, a single CSS file makes it easier to enforce style consistency across the entire app and maintain code, and considerably speeds up the development.