问题就在标题中。投票小部件在大屏幕上显示在侧边栏，在小屏幕上则显示在下方某个位置。
“修改”指的是
- 实际编写和编辑 CSS。
- 或者，是 CSS 的积极使用者。您/他们编写 HTML 并使用现有的 CSS，因此对实际的 CSS 具有既得利益，而不仅仅是结果。
这可能与您组织、项目或前端团队中的人数不同。可能存在一些规模惊人的大型组织，其中答案仅为 1 或 2。也可能存在一些小型组织，其中许多人会频繁修改 CSS。
与我们所有简单的一次性调查一样，我们不会获得任何交叉参考。但是，我们将了解大量前端开发人员的现状。我非常好奇结果会如何。老实说，我无法猜测曲线会是什么样子。
如果您参与了许多项目，请选择其中一个。选择最大的项目，或您花费最多时间或最重视的项目。
作为一个独立的自由职业者，我将弃权。我非常好奇结果会如何。希望一些评论也能带来一些见解！
这将会很有趣，可怜的 26+ 人……我们的 CSS 曾经一团糟，所以我们实施了“scss-lint”，然后一切顺利。只需确保在 Grunt 编译/构建项目时抛出错误，否则他们可能会将未经 lint 的 CSS 推送到上游。
您漏掉了“太多人”。
我们有一个大约 12 人的开发团队，团队外也有几个人会修改代码。只有我们四个人 *应该* 编写 CSS。我们试图通过限制对 css 目录的权限来锁定它，但这导致了数百个流氓 css 文件、-page css 定义和大量内联代码。
我们现在正努力清理所有这些，因为我们需要对网站进行快速品牌重塑。
在重新设计中，我们使用了一种方法，即使用框架并将添加的样式尽可能地原子化和易于记忆，以避免出现问题。
该网站非常庞大，每天都在发生变化。除了添加一个扫描程序来查找和在部署周期中查找 style="" 之外，我真的不知道我们如何才能保持代码整洁。
欢迎提出建议。
设置一个 标头并使用 CDN
–
default-src *–
style-src {CDN URL}– 限制对 CDN 的访问
这意味着任何内联样式以及同域 CSS 都将无法工作。
您可以跳过 CDN 并使用
style-src 'self'来去除内联样式。我在一家企业工作，参与一个大型内部项目。15 名开发人员中，有 2 人积极修改我们的 CSS。这是一个 Rails 项目，我们使用一个独立的 gem 来加载所有 Sass。
我是一个大约十名软件工程师团队中唯一的 Web 开发人员。如果涉及前端，都是我负责。我不认为这里还有其他人 *了解* CSS。
作为 Smashing Magazine 的唯一开发人员，有多少人修改我们的 CSS 非常明显。=D
抱歉，无法回答这个问题……我们没有“主要”项目，我们会参与许多项目。通常是 3-5 人，但我们经常接手其他人遗留下来的烂摊子。例如，今天早上，我深入了一个项目，之前的人员大多（很好地）注释了他们的 CSS。除了最初编写代码的人之外，还有 10 人参与了该项目。其中 9 人与我们的组织无关。但今天只有我和审查代码的人。
我们有一个小型团队（5 名开发人员），他们都会参与代码库。我们已经切换到使用预制模板，并且只使用我们自己的少量调整来覆盖预构建的 CSS。这些调整针对每个开发人员的子项目都是特定需要的，以确保它们不会覆盖其他人的工作。
我认为所有回答“一人”的人都是自由职业者。我们是唯一有时间在互联网上阅读这类文章的人。 :)
哈哈，不是。我以前在公司工作的时候也阅读过。在最后一个项目中，我是唯一编写 CSS 的人，因为他们都不理解 Sass，他们剩下的只有我从 compass 生成的压缩后的 CSS。即使他们想修改 CSS，也做不到。
仅供参考，我回答了“一人”，我并不是自由职业者……
我回答了一人，而且我不是自由职业者。我负责我们公司的所有 Web 开发和设计工作。我们是一家非常小的公司，所以我身兼数职。如果我们公司其他人打开 css 文件，也只有一人能理解他们在看什么。
我的午休时间是我留出来赶上进度和阅读文章的时间。这比边工作边吃午餐要好得多。
对我来说，这个问题很难回答。我们有一个小型开发团队（总共 7 人，但并非所有人都修改 CSS），但产品和营销团队都根据第二个定义“使用”CSS，以便使用现有 CSS 类创建基于 CMS 的页面，所以我不得不选择 11-25 人。
当项目处于积极开发阶段时，只有一人负责 CSS。项目发布后，我们不会那么挑剔，3-4 个不同的人可能会参与其中。
我独自开发，但许多团队（7-10 人）使用我的 CSS。
我很想知道这与使用 Git 的关系。根据大量推文，每个人，包括设计师，都应该使用 Git。但是，我从未找到一个愿意解释小型团队良好 Git 工作流程的人（因为它涉及的内容不仅仅是使用基本的 Git 命令）。另一方面，我无法理解两个或更多设计师、前端开发人员……如何在没有某种形式的版本控制的情况下处理同一个 CSS。
我们办公室大约有 20 名开发人员，几乎每个人都期望在项目需要时编写 CSS，导致至少一半的开发人员（大约 11 到 20 人）定期修改我们的 CSS。我们有严格的编码标准，因此我们编写的新的代码质量还不错（我希望是这样……）
我有一个小型团队（3 名开发人员）
但只有 2 名开发人员会修改我们的 CSS
在我工作的地方，情况非常混乱。我们大约有 2000 个基于 WordPress 的客户（个体经营者、建筑商等），数百个是遗留客户，这意味着大约有 10 个实习生参与过这些客户，他们的技能水平参差不齐，因此有大量的内联样式、不正确的嵌套，以及糟糕的代码，这使得修改任何方面都非常困难，而且时间紧迫，清理代码更加困难。我们有 4 名前端开发人员（包括我），但只有 2 个经常修改 CSS，我的另一位开发人员的技能也值得怀疑。这不是最好的工作……
任何类型的代码仓库（Git、Mercurial 或其他……）都会让你的生活变得轻松很多。我是一个 8 人团队的一员。代码仓库是我们一起工作的唯一方式。就像我说的，自从我们开始使用它以来……好多了。
啊，很有意思，看到 1500 人（截至目前 53%）和我一样，是唯一负责触摸 CSS 的人。在我的团队中，JavaScript 也是如此。我的团队中只有另外两个人具备（基础）HTML 技能（他们经常使用<
font> 标签，悲伤脸）。Chris，似乎很多前端的讨论（以及本网站的大部分内容）都侧重于帮助**团队**管理难以驾驭的代码库，而针对那些独自奋斗的“独行侠”的讨论则较少。这使得许多人对管理 CSS 和 JavaScript 的最佳策略以及哪些工具最值得投入时间学习感到困惑。就我个人而言，我发现自己做了很多心理过滤，筛选所有最热门的趋势，试图找到与一人编码操作相关的内容，而且我知道我肯定会感激更多专注于帮助我们这些并非独一无二处境的人的博文。
我喜欢听到大家的工作流程。
我的项目通常有 2-3 个前端开发人员。
我们使用 Git + Gulp 与 Sass 和代码风格检查。我们为每个页面创建一个 Sass 部分文件。如果页面比较复杂，有时我们会将页面部分分解成部分文件。Git 与 Sass 部分文件在很大程度上避免了合并冲突。这种工作流程对我们来说非常有效！
26+ 人会非常有趣……才怪！