01 / 03

Editorial

适合新闻专题、文化杂志和深度报告页，严整编辑网格配精致衬线标题、黑灰对比与克制留白，优雅耐读。

通用设计极简主义

设计语言预览

Editorial Foundation

Editorial Black

#111111

标题、主行动、粗分隔线和最强结构对比。

Reading Ink

#111827

正文和长篇阅读的高对比文字颜色。

Paper White

#ffffff

页面、文章与编辑工作区的主要纸面。

Soft Gray

#f1f1f1

目录、辅助面板和编辑分区的克制底色。

Explicit Status

Success

#16a34a

只用于完成、通过和发布就绪，并同步提供文字。

Warning

#d97706

只用于待核对、权利确认和编辑风险。

Danger

#dc2626

只用于错误、阻断和发布失败。

字体层级

feature-title

Gelasio · 40 / 600 / -3%

一页好文章，先有节奏，再有装饰。

section-heading

Gelasio · 24 / 600 / -1%

网格安静地组织阅读

body-reading

Gelasio · 16 / 400 / 1.65

正文以舒适行长和稳定基线承载观察、证据与叙述。

label-caps

Ubuntu Mono · 14 / 700 / +8%

ISSUE 24 · FIELD NOTE 06 · READY

间距、层级与形状

xs 8px

sm 16px

md 24px

lg 32px

xl 40px

2xl 48px

形状

full

按钮、字段和紧凑标签使用 4px；文章面板、封面图与编辑容器使用 8px；正文分栏和全宽出版带保持直角。

层级

Level 0 · #ffffff 纸张画布Level 1 · #f1f1f1 目录与编辑辅助分区Level 2 · #111111 粗规则、主行动与封面图形，不依赖投影

组件样张

button-primary

黑色填充、白色文字、4px 圆角和至少 44px 高度，用于主要阅读或出版行动。

button-secondary

白底、黑色 1px 边框与 4px 圆角，用于浏览、预览和次级编辑操作。

button-icon

文章、目录、字段和出版状态覆盖 default、hover、focus-visible、active、disabled、loading 与 error。

text-input 搜索内容

content-row

一行核心内容保持清晰标题。

元信息 · 状态 · 更新时间

布局与响应式

严格编辑网格负责秩序，精致衬线字体负责声音与阅读温度。

桌面端使用双栏封面、文章分栏与编辑工作台；平板减少并列栏目；移动端按期号、标题、导语、正文、来源和操作顺序单列。

断点	宽度	关键变化
移动端	< 768 px	标题降至 32px，长文改为单栏，期号与来源保持可扫描，交互目标至少 44px。
平板	768 - 1099 px	保留主封面和核心文章，减少边注与并列目录，维持 8pt 基线。
桌面端	>= 1100 px	完整双栏封面、两栏正文、编号目录和编辑工作台，最大标题 40px。

使用边界

应该

以 #ffffff 纸面、#111111 结构黑和 #f1f1f1 辅助灰建立现代编辑基底。
Gelasio 承担标题与正文，Ubuntu Mono 只用于期号、来源、状态与参数。
严格采用 14/16/18/24/32/40 字阶，并让所有间距落在 8pt 基线网格。
用分栏、细线、编号、栏宽和留白建立杂志层级，不依赖装饰性卡片。
按钮、字段和状态保持清楚标签、可见焦点和至少 44px 目标。
长文在移动端回到单栏，并保留标题、导语、署名和正文的阅读顺序。

不要

不要使用 IBM Plex Sans 等通用 SaaS 无衬线替代 Gelasio 编辑字体。
不要加入彩色渐变、大面积品牌色或与内容无关的插画装饰。
不要把每段内容都包装成软圆角卡片；分隔线和留白才是主要结构语言。
不要使用低对比灰色正文，也不要让过宽行长破坏长篇阅读。
不要脱离 8pt 基线随意堆叠间距，或用过多字重制造层级。
不要只靠绿色、橙色或红色表达出版状态，必须同步提供明确文字。

---
name: Editorial
colors:
  primary: "#111111"
  secondary: "#f1f1f1"
  success: "#16A34A"
  warning: "#D97706"
  danger: "#DC2626"
  surface: "#FFFFFF"
  text: "#111827"
  neutral: "#FFFFFF"
typography:
  h1:
    fontFamily: "Gelasio"
    fontSize: 2.5rem
  body-md:
    fontFamily: "Gelasio"
    fontSize: 1rem
  label-caps:
    fontFamily: "Ubuntu Mono"
    fontSize: 0.875rem
  sourceScale: "14/16/18/24/32/40"
  weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  sourceScale: "8pt baseline grid"
---

## 概览

杂志式的编辑布局：精致衬线字体 + 结构网格，塑造优雅的阅读体验。

## 风格基础

- **视觉风格：** 现代、编辑
- **字号级差：** 14/16/18/24/32/40
- **字体：** primary=Gelasio, display=Gelasio, mono=Ubuntu Mono
- **字重：** 100, 200, 300, 400, 500, 600, 700, 800, 900
- **色板：** 主色、辅色、中性、成功
- **间距级差：** 8pt 基线网格

## 色板

- **Primary (#111111)：** 来自"风格基础"的 Token。
- **Secondary (#f1f1f1)：** 来自"风格基础"的 Token。
- **Success (#16A34A)：** 来自"风格基础"的 Token。
- **Warning (#D97706)：** 来自"风格基础"的 Token。
- **Danger (#DC2626)：** 来自"风格基础"的 Token。
- **Surface (#FFFFFF)：** 来自"风格基础"的 Token。
- **Text (#111827)：** 来自"风格基础"的 Token。
- **Neutral (#FFFFFF)：** 由 surface Token 派生，以兼容官方格式。

## 技能指引

<!-- TYPEUI_SH_MANAGED_START -->
# Editorial 设计体系技能（通用）

## 使命
你是 Editorial 的资深设计体系规范作者。
输出可直接落地、工程师和设计师都能直接用的实用规范。

## 品牌

## 风格基础
- 视觉风格：现代、编辑
- 字号级差：14/16/18/24/32/40 | 字体：primary=Gelasio, display=Gelasio, mono=Ubuntu Mono | 字重=100, 200, 300, 400, 500, 600, 700, 800, 900
- 色板：主色、辅色、中性、成功 | Tokens：primary=#111111, secondary=#f1f1f1, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
- 间距级差：8pt 基线网格

## 无障碍
WCAG 2.2 AA、键盘优先交互、可见的焦点状态、先语义化 HTML 再补 ARIA、经屏幕阅读器验证的标签、支持减弱动效、触控目标不小于 44px、支持高对比模式

## 文字调性
简洁、自信、有帮助、清晰、友好、专业、行动导向、少术语

## 规则：应当
- 优先使用语义 Token 而非原始值
- 保持视觉层级
- 让交互状态明确可见
- 为空态/加载/错误场景做设计
- 默认支持响应式行为
- 记录无障碍决策的依据

## 规则：不应
- 避免低对比度文字
- 避免不一致的间距节奏
- 避免含义模糊的标签

## 期望行为
- 先遵循风格基础，再关注组件一致性。
- 不确定时，优先无障碍与清晰度，而非追求新颖感。
- 提供具体默认值，并在存在备选方案时说明取舍。
- 保持规范鲜明、精简，且面向实现。

## 规范撰写流程
1. 在提出规则前，先用一句话复述设计意图。
2. 先定义 Token 与基础约束，再给出组件级规范。
3. 明确组件结构、状态、变体与交互行为。
4. 包含无障碍验收标准与文案撰写要求。
5. 补充反模式，以及既有不一致 UI 的迁移建议。
6. 以一份可在代码评审中执行的 QA 清单收尾。

## 输出结构要求
生成设计体系规范时，请按以下结构组织：
- 背景与目标
- 设计 Token 与基础
- 组件级规则（涵盖结构、变体、状态与响应式行为）
- 无障碍要求与可测试的验收标准
- 文案与调性规范，附具体示例
- 反模式与不允许的实现
- QA 清单

## 组件规则要求
- 定义必须实现的状态：default、hover、focus-visible、active、disabled、loading、error（视需要）。
- 描述键盘、指针与触屏下的交互行为。
- 明确说明间距、字体与色彩 Token 的使用方式。
- 覆盖响应式行为与边界场景（如长标签、空态、内容溢出）。

## 质量门禁
- 规则不应只依赖含糊形容词；必须以 Token、阈值或示例作为锚点。
- 每一条无障碍主张，在实现中都必须可测试。
- 优先保证体系一致，而非局部的一次性优化。
- 当美观与无障碍冲突时明确指出，并以无障碍为先。

## 约束语言示例
- 用"必须"表述不可协商的规则，用"应"表述建议。
- 每条"应当"规则至少配一个具体的"不应"反例。
- 引入新模式时，同步提供既有组件的迁移指引。

<!-- TYPEUI_SH_MANAGED_END -->