GOV.UK 提案页面
目的
生成一个自包含的 HTML 页面，用于论证方向、解释想法或推介变更，采用真实的 GOV.UK 设计系统样式和少量可复用组件。
核心原则：展示内容，而非叙述内容。 团队拥有的东西列表变为卡片网格；一系列步骤变为流程图；对比变为带差异高亮的表格。散文是连接组件的纽带，而非主要信息传递方式。
描述内容；本技能负责外观。
输出是一个 HTML 文件
使用本技能制作的页面以文件形式共享，通常上传至 SharePoint 或类似文档库并通过链接分享。因此：
- 所有内容都在一个
.html文件中。 CSS、字体和图像均内嵌（字体和图像作为 base64 数据 URI）。无外部样式表、脚本、字体或图像。 - 页面必须在禁用 JavaScript 的情况下正确显示。 某些文档库在预览中会剥离或阻止脚本。交互式组件（如视图切换器）是增强功能：无 JavaScript 时的默认状态必须能独立理解。
- 读者无需构建步骤。 文件直接在浏览器中打开。
文件
page-starter.html是一个空白页面：包含 GOV.UK Frontend CSS、内嵌为 base64 的 GDS Transport 字体、完整组件 CSS、状态横幅、英雄区和带变更日志的页脚。每个新页面都从此文件复制开始。GDS Transport 仅限 GOV.UK 内部使用；在 GOV.UK 外部，请替换为其他字体（参见NOTICE.md）。docs/index.html是本技能的文档页面，且由本技能构建。其“组件”部分是视觉参考：每个组件均有名称和标签，并说明何时使用、何时避免以及实时示例。请从gx-specimen__demo代码块中复制组件标记。不要复制gx-类；它们仅用于文档页面的样式。它使用与起始文件相同的组件 CSS，因此复制的标记无需修改即可工作。
文档结构
在选择组件之前确定论点。大多数提案遵循此顺序；删除不需要的部分。
| 部分 | 作用 | 常用组件 |
|---|---|---|
| 状态与英雄区 | 说明文档内容及唯一要点 | 状态横幅、英雄区 |
| 是什么 | 如果受众可能不了解，则解释想法 | 分类、扇出、分层、代码对比 |
| 给我们带来什么 | 对每个群体而言早期即可获得的收益 | 收益网格、宽卡片 |
| 为什么现在 | 当前问题及证据 | 孤岛、统计、对比表格、多对一、研究引用 |
| 如何运作 | 提议的方法 | 流程、前后对比、中心辐射、扇入、实例演练 |
| 谁负责什么 | 职责分配 | 职责、面板 |
| 从何开始 | 范围与顺序 | 阶段、时间线 |
| 风险 | 可能出错的地方 | 风险 |
| 未决问题 | 需要读者回答的问题 | 未决问题 |
| 成功衡量 | 如何知道成功 | 成功衡量、成果 |
| 页脚 | 版本与变更日志 | 变更日志 |
仅当读者已经理解解决方案领域时，才将“为什么现在”放在前面（参见“编辑原则”）。
组件目录
每个组件都有一个名称。使用本技能的人可以按名称请求组件（例如“使用扇入来展示应用程序来自何处”），并且您应在建议时使用相同的名称。docs/index.html 的“组件”部分展示了每个组件的实时示例，包括其类、何时使用以及何时避免。请从那里复制标记。
页面装饰
| 名称 | 类 | 使用场景 |
|---|---|---|
| 状态横幅 | pt-topbanner | 每个页面。显示版本和一行文档说明。 |
| 英雄区 | pt-hero | 每个页面。包含眉毛标签、标题和文档中最尖锐的句子。 |
| 辅助说明 | pt-note | 图表、表格或统计数据下方的元信息：来源、注意事项、“说明性”。 |
| 变更日志 | pt-footer | 每个页面的页脚。最新条目最前。 |
卡片
| 名称 | 类 | 使用场景 |
|---|---|---|
| 收益网格 | pt-owns-grid | 三项或四项交付、拥有或获得的内容。 |
| 宽卡片 | pt-owns-card--wide | 某项目需要比同行更多空间，或避免一行中只有一张卡片。 |
| 原则 | pt-works-grid | 三项原则或工作方式。 |
| 分类 | pt-categories | 某事物的类型，每个类型带有小型视觉元素显示类别。 |
| 面板 | pt-card | 需要比网格卡片更多空间的要点，样式与其他卡片一致。 |
| 风险 | govuk-inset-text pt-card pt-card--warning | 需要防范的风险，基于经验直接陈述。 |
| 成果 | pt-card pt-card--success | 如果成功将达到的状态。 |
数字
| 名称 | 类 | 使用场景 |
|---|---|---|
| 统计 | pt-baseline-grid | 关键数字。每个数字带有清晰标签，若可能，集合总和等于指定总数。 |
图表
| 名称 | 类 | 使用场景 |
|---|---|---|
| 扇出 | pt-fanout | 一个来源产生多个输出。 |
| 扇入 | pt-fanin | 多个来源汇聚成一个东西：决策输入、数据汇入一条记录、团队协作提供一个服务。最佳适用于三到五个输入。示例绘制四条曲线，起始 y 坐标分别为 12.5、37.5、62.5 和 87.5；若输入数量不同，每条曲线从其输入中心起始（三个输入时：16.7、50 和 83.3）。 |
| 中心辐射 | pt-hub | 一个中心事物，最多四个部分与其连接。 |
| 孤岛 | pt-silos | 同一事物在多个地方分别持有，彼此无连接。标记差异副本。 |
| 多对一 | pt-many-to-one | 多个名称或路径指向同一事物：重复、别名、重叠工作。 |
| 前后对比 | pt-before-after | 同一事物的当前状态与提议状态并排对比。 |
| 分层 | pt-layers | 相互构建的层次，通过带标签的箭头连接。连接器标签为常规粗细。 |
| 流程 | pt-flow | 带有编号步骤和最终状态的过程。未决定的终点标记为开放，并附上“待定方案”标签。 |
| 阶段 | pt-phases | 按实际顺序排列的工作阶段。当前阶段填充。 |
| 时间线 | pt-timeline | 带日期的里程碑。过去里程碑填充，未来里程碑空心。 |
| 频谱 | pt-spectrum | 事物在两个极端之间的范围位置：成熟度、工作量、风险。 |
| 团队 | pt-squads | 团队之间的关系，尤其是重组。状态变化的团队用虚线标记。 |
表格与列表
| 名称 | 类 | 使用场景 |
|---|---|---|
| 对比表格 | pt-compare | 多个选项或地方并排对比。按行分组，高亮整个单元格中的异常值。 |
| 职责 | pt-split | 谁负责什么，两组并排。 |
| 未决问题 | pt-questions | 您希望得到回答的问题，每个问题标记给谁。 |
| 成功衡量 | pt-check-list | 五到六项可勾选的成果。 |
示例与证据
| 名称 | 类 | 使用场景 |
|---|---|---|
| 实例演练 | pt-example | 具体案例：先展示视觉，然后说明每个地方当前如何处理。 |
| 研究引用 | pt-quote | 用户、同事或利益相关者的真实陈述，附上说话者。 |
| 代码对比 | pt-code-pair | 数据、代码或配置，单独或并排显示。简化片段标记为“说明性”。 |
| 色点 | pt-swatch | 内联显示的颜色或状态，在表格或句子中。始终与文本标签配对。 |
交互式
| 名称 | 类 | 使用场景 |
|---|---|---|
| 视图切换器 | pt-views | 在图表的两状态间切换，如“当前”和“提议”。可选，需要 JavaScript。 |
如果内容不适合以上任何组件，可写一个短段落（适度使用）或添加组件（参见“扩展库”）。
编辑原则
结构
- 一个文档，一条主线。 每个组件应服务于核心论点。如果某内容有趣但非关键，则删除。
- 在论证之前先解释想法，当受众可能不了解该想法时。问题优先适用于人们已理解解决方案领域的情况。当他们不理解时，问题部分读起来像一串没有出路的抱怨。参见“文档结构”中的默认顺序。
- 将收益放在前面。 读者在前一两屏决定是否关心。
- 在第一个示例中展示完整范围。 如果第一个示例范围狭窄，读者会假设整个提案范围狭窄。当想法广泛适用时，以暗示广度的示例开头，然后将狭窄案例作为证据。
- 删除不需要的部分。 如果某部分是关于另一决策的讨论，则省略。
语言
- 在使用术语之前先介绍它。 这包括标题、标签和表格分组。如果术语在解释之前出现，请改用简明描述。
- 每个术语只分配一个任务。 如果两个相似词都出现（例如“决定”用于单个选择，“方法”用于整体方式），请确保在全文保持各自含义。
- 将方法描述为“一种常见方式”，而非“唯一方式”，除非它确实是唯一方法。这样更准确且鼓励讨论。
- 使用描述而非指责的词汇。 “有些地方有定义，有些没有”描述了一种情况。“缺口”或“缺失”暗示有人失败。
- 当作者提供了措辞，按原样使用。 仅修正语法，并说明您更改的内容。
证据
- 使用来自来源的真实数据（系统、电子表格、导出），而非回忆或估计的数据。说明数字来源。
- 标记任何从截图或摘要中读取的内容，以便在页面共享前进行核对。
- 不要夸大状态。 如果某事物受到好评但未正式同意，请准确说明，或省略状态。
- 将未决定的选项标记为未决定。 在选项上添加“待定方案”标签，总比将猜测呈现为决策好。
面对混合受众的语气
- 保持公正。 当展示涉及多个团队或地点的问题时，展示各自的部分。针对单个群体的页面会使该群体产生防御心理。
- 为房间里的每个群体描述共同收益。 用他们自己的语言描述每个群体获得的收益。不要在文档中提及群体之间的摩擦，即使这是真实动机。收益可以在不描述摩擦的情况下解决它。
文体规范
默认文体，可根据需要调整：
- 英式英语，句子式标题，牛津逗号
- 不使用长破折号；改用逗号、冒号、分号或句号重构
- 不使用“不是 X，而是 Y”的句式
- 不使用军事或战斗隐喻
- “government”小写，除非是名称的一部分
- 简洁、直接、自信；每个词都有其位置，引言行不重复总结行
视觉规则
- 所有卡片采用统一样式。 卡片为白色，带 1px 灰色边框、4px 蓝色顶部边框、可选图标、小标题 (
govuk-heading-s) 和小号正文 (govuk-body-s)。不要发明一次性卡片样式；修改新内容以匹配。 - 网格中不允许孤行卡片。 如果网格会导致一行仅剩一张卡片，请将该卡片设为宽卡片或更改列数。
- 色样为圆形， 与 GOV.UK 设计系统色彩页面一致。
- 对比表格高亮整个单元格， 而非文本后的内联背景，以确保每列的值对齐。每个单元格和组标题共享相同左边缘。
- 图表中的连接器标签为常规粗细。 粗体用于标题和被指向的事物。
- 辅助说明 (
pt-note)：16px 小号正文，使用次要文本颜色 (#505a5f)。用于图表、表格或统计数据下方的元信息：注意事项、来源、“说明性”标签。 - 并排代码块高度一致。
- 图表使用
box-sizing: border-box（在组件 CSS 中设置），以确保内边距和边框不会使组件超出其盒子。 - 英雄区标签保持在一行内。 GOV.UK 标签默认最大宽度 160px；组件 CSS 为英雄区和横幅提升该限制。
- 自定义字体或图像必须内嵌， 且仅在其许可允许时。先检查许可。自定义字体通常需要手动垂直居中：测量渲染文本并调整内边距。
- 无障碍： 为图表提供文本替代（
role="img"加上aria-label描述图表内容），在交互控件上保持可见的焦点状态，不单靠颜色表示差异（高亮单元格同时加粗）。
交互式组件
视图切换器 (pt-views) 允许读者在图表状态间切换，例如“当前”和“提议”，或“浅色”和“深色”。它是可选的：
- 默认状态必须是即使无 JavaScript 也能理解的状态。
- 使用真实的
<button>元素，带aria-pressed。 - 保持脚本内联且小巧；起始文件包含一个可复用的脚本。
构建工作流
- 首先收集内容：论点、证据、受众以及您希望他们做什么。在内容明确之前选择组件会产生表面精致但内容空洞的页面。
- 使用“文档结构”规划各部分，并从目录中按名称选择组件。如果某人已要求特定组件，请使用这些。
- 将
page-starter.html复制为新文件。填写横幅、英雄区和页脚。 - 从
docs/index.html的“组件”部分复制每个组件的标记，并替换占位内容。绝不要在页面中留下占位文本。 - 如果页面使用了视图切换器，则保留起始文件末尾的脚本；否则删除。
- 在浏览器中检查页面。