feat: IMAP mail sync with thread-to-contact matching (PRD §6.1)
Real IMAP connection via imapflow library: - Connects to IMAP server (IMAPFlow, TLS on port 993) - Fetches recent messages (configurable limit, default 20) - Extracts: from, fromEmail, subject, date, snippet (200 chars) - Thread-to-contact matching (PRD §6.1): 1. Match sender email against persons table 2. If no person match, extract domain and match against company.website 3. Returns matchedCompany + matchedPerson for each email - Audit-logged (action: crm.mailsync:imap) - Zod validated (host, port, user, password, folder, limit) - 502 on IMAP connection failure with detail - 400 on validation failure Tested: invalid creds → 502 'IMAP connection failed', missing host → 400
This commit is contained in:
Z User committed
1 parent
7acc0c5451
commit
e45b68bb8b
1089 files changed
+260614
No files matched your search
Executable
+92
@@ -0,0 +1,92 @@
|
||||
# Horizontal Craft
|
||||
|
||||
Horizontal craft files are cross-cutting design constraints. They are not artifact skills, templates, or scenario principles.
|
||||
|
||||
Use them after a lightweight design understanding step has determined what the artifact needs. Do not read every file by default.
|
||||
|
||||
```yaml
|
||||
skill_bundle:
|
||||
horizontal_craft:
|
||||
# Always for Chinese artifacts
|
||||
- horizontal-craft/chinese-typography.md
|
||||
|
||||
# Generative craft, loaded when needed
|
||||
- horizontal-craft/color.md
|
||||
- horizontal-craft/icon-system.md
|
||||
- horizontal-craft/animation-discipline.md
|
||||
- horizontal-craft/laws-of-ux.md
|
||||
- horizontal-craft/technique-library.md
|
||||
|
||||
# Guardrail craft, usually applied during review or when triggered
|
||||
- horizontal-craft/anti-ai-slop.md
|
||||
- horizontal-craft/accessibility.md
|
||||
- horizontal-craft/state-coverage.md
|
||||
- horizontal-craft/form-validation.md
|
||||
- horizontal-craft/data-integrity.md
|
||||
- horizontal-craft/link-and-proof.md
|
||||
```
|
||||
|
||||
`quality-gate.md` verifies whether the relevant horizontal craft checks passed. It should not duplicate the full rulebooks.
|
||||
|
||||
## Loading Priority
|
||||
|
||||
Do not read every horizontal craft file by default. Load only what the task needs.
|
||||
|
||||
### Baseline for Chinese visual design
|
||||
|
||||
- Read `chinese-typography.md` whenever the artifact contains meaningful Chinese text.
|
||||
- Read `reference/fonts.md` when font choice materially affects the visual direction: font-related user requests, typography-led covers/posters/cards/deck covers, official documents, classical/literary content, academic/report tone, industrial/technology display type, or when title/body font attitudes must differ.
|
||||
- Do not read `reference/fonts.md` for every Chinese task; for ordinary Web/App/Dashboard output without font intent, use a safe system font stack.
|
||||
- Read other deep files in `reference/` only when their trigger conditions apply.
|
||||
|
||||
### Generative craft
|
||||
|
||||
Read these before or during drafting when their trigger applies:
|
||||
|
||||
- `color.md` — read when no strong design system is provided, when color direction is vague, when semantic colors/status colors are used, or when the artifact risks default blue-purple gradient styling.
|
||||
- `chinese-typography.md` — read for all Chinese-language artifacts.
|
||||
It provides principles and diagnostics, not a universal type-scale preset; concrete sizes should come from the artifact skill, template, design system, or canvas/device registry.
|
||||
- `icon-system.md` — read when the artifact uses icons, pictograms, status marks, or icon-like decoration.
|
||||
- `animation-discipline.md` — read when motion, transitions, scroll reveal, microinteractions, or animated H5 behavior are requested or implied.
|
||||
- `laws-of-ux.md` — read for decision-heavy or interaction-heavy surfaces such as pricing pages, onboarding, dashboards, forms, H5 tools, and product flows.
|
||||
- `technique-library.md` — read only for advanced front-end effects such as GSAP, Three.js, shaders, rich motion, or data visualization technique selection.
|
||||
|
||||
### Guardrail craft
|
||||
|
||||
Usually apply these during review, or earlier only when the task clearly triggers them:
|
||||
|
||||
- `anti-ai-slop.md` — use as an anti-default check, not as the primary creative direction.
|
||||
- `accessibility.md` — apply as a final baseline check for web artifacts.
|
||||
- `state-coverage.md` — read for interactive, data-driven, form, tool, dashboard, or prototype surfaces.
|
||||
- `form-validation.md` — read for signup, login, checkout, calculators, input-heavy H5, settings, admin forms, or any artifact with validation/error messaging.
|
||||
- `data-integrity.md` — read when charts, metrics, benchmarks, forecasts, calculations, or proof-like numbers appear.
|
||||
- `link-and-proof.md` — read when links, CTAs, customer proof, testimonials, logos, awards, or external claims appear.
|
||||
|
||||
### Removed boundary
|
||||
|
||||
There is no standalone `chinese-copy.md`. Copywriting is not a core design craft. Only short copy-related failure smells that visibly affect design quality remain in `anti-ai-slop.md`.
|
||||
|
||||
## Boundary with Scenario Principles and Templates
|
||||
|
||||
Templates live outside horizontal craft in `templates/`. They provide optional concrete structure seeds.
|
||||
|
||||
Scenario principles decide business priorities. Horizontal craft decides cross-cutting execution quality.
|
||||
|
||||
Horizontal craft files are universal constraints that can apply to any scenario or template. `technique-library.md` is here because advanced front-end technique selection is a cross-cutting implementation rule, not an artifact skill.
|
||||
|
||||
## Reference Loading Rule
|
||||
|
||||
Deep reference files are not passive appendices. When a selected horizontal craft file contains a clear trigger condition, add the matching reference file to `required_reference_files_to_read`. Do not rely on the summary file alone for typography-heavy, publication, report, fixed-image, or punctuation-sensitive work.
|
||||
|
||||
For normal UI work, read only the top-level craft file. For typography-heavy work, read 1–3 relevant files from `horizontal-craft/reference/`.
|
||||
|
||||
## Deep Reference Files
|
||||
|
||||
`reference/` lives inside `horizontal-craft/` because these files are deep typography and layout references used primarily by `chinese-typography.md`. Keep them here instead of the design root.
|
||||
|
||||
- `reference/directions.md`
|
||||
- `reference/title-and-breaking.md`
|
||||
- `reference/punctuation.md`
|
||||
- `reference/grid-system.md`
|
||||
- `reference/text-detail.md`
|
||||
- `reference/fonts.md`
|
||||
+134
@@ -0,0 +1,134 @@
|
||||
---
|
||||
name: accessibility
|
||||
description: Accessibility baseline for generated HTML artifacts. Covers contrast, focus, keyboard behavior, labels, touch targets, motion safety, semantics, and common failure patterns.
|
||||
mode: reference
|
||||
platform: web
|
||||
scenario: horizontal-craft
|
||||
preview:
|
||||
type: none
|
||||
default_for:
|
||||
- accessibility
|
||||
- a11y
|
||||
- WCAG
|
||||
- focus visible
|
||||
- keyboard
|
||||
- form labels
|
||||
fidelity: system
|
||||
sources:
|
||||
- adapted-from-open-design/craft/accessibility-baseline.md
|
||||
---
|
||||
|
||||
# Accessibility
|
||||
|
||||
This file defines the accessibility baseline for generated design artifacts. The active design system decides how it looks; this file decides what cannot be broken.
|
||||
|
||||
Target **WCAG 2.2 AA** as the practical working baseline unless the user specifies another compliance target.
|
||||
|
||||
---
|
||||
|
||||
## Contrast
|
||||
|
||||
Minimums:
|
||||
|
||||
| Pair | Minimum |
|
||||
|---|---:|
|
||||
| Normal text | 4.5:1 |
|
||||
| Large text | 3:1 |
|
||||
| Non-text UI and graphical objects | 3:1 |
|
||||
| Focus indicator vs adjacent state | 3:1 |
|
||||
|
||||
Do not round up. `2.99:1` fails a `3:1` check.
|
||||
|
||||
Avoid low-contrast muted text, especially opacity-based text on dark or colored backgrounds.
|
||||
|
||||
---
|
||||
|
||||
## Focus visibility
|
||||
|
||||
- Every interactive element must have visible `:focus-visible` styling.
|
||||
- Never remove focus outline without an accessible replacement.
|
||||
- Focus indicator should be visible by shape, outline, underline, or offset — not color alone.
|
||||
- Modals must trap focus while open and return focus to the opener when closed.
|
||||
|
||||
---
|
||||
|
||||
## Keyboard behavior
|
||||
|
||||
- Native `<button>` for actions.
|
||||
- Native `<a href="...">` for navigation.
|
||||
- Do not use `<a>` without `href` as a button.
|
||||
- Do not use `<div role="button">` unless keyboard handlers, focus, and pressed state are implemented.
|
||||
- Escape should close dismissible modals, popovers, and drawers.
|
||||
|
||||
---
|
||||
|
||||
## Labels and names
|
||||
|
||||
- Every form input needs a visible `<label>` or an accessible name.
|
||||
- Placeholder text is not a label.
|
||||
- Icon-only buttons require `aria-label`.
|
||||
- Decorative icons use `aria-hidden="true" focusable="false"`.
|
||||
- Meaningful status changes use live regions when needed.
|
||||
|
||||
Recommended field pattern:
|
||||
|
||||
```html
|
||||
<label for="email">Email</label>
|
||||
<input id="email" type="email" required aria-describedby="email-hint email-error" aria-invalid="true">
|
||||
<span id="email-hint">Used for receipts only.</span>
|
||||
<span id="email-error" role="alert">Email must include @ and a domain.</span>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Touch targets
|
||||
|
||||
- Minimum practical target: `24×24 CSS px`.
|
||||
- Preferred mobile target: `44×44 pt` / `48×48 dp` equivalent.
|
||||
- Adjacent tiny targets need enough spacing.
|
||||
- Primary mobile actions should be thumb-reachable.
|
||||
|
||||
---
|
||||
|
||||
## Semantics
|
||||
|
||||
- Use one logical `<h1>` per document / screen when possible.
|
||||
- Heading levels should not skip randomly.
|
||||
- Use lists for lists, tables for tabular data, buttons for actions, links for navigation.
|
||||
- Avoid ARIA when native HTML does the job.
|
||||
- Do not use positive `tabindex`; fix DOM order.
|
||||
|
||||
---
|
||||
|
||||
## Motion safety
|
||||
|
||||
- Add `prefers-reduced-motion` fallback when using animation, transform, transition-heavy interaction, smooth scroll, or scripted motion.
|
||||
- Do not flash more than three times per second.
|
||||
- Do not block input with decorative animation.
|
||||
- Auto-playing motion longer than 5 seconds needs pause/stop/hide controls.
|
||||
|
||||
---
|
||||
|
||||
## Forms and errors
|
||||
|
||||
- Validate on blur by default, not on first keystroke.
|
||||
- Preserve user input after errors.
|
||||
- Move focus to the first invalid field after submit.
|
||||
- Provide a summary for multi-field forms.
|
||||
- Error copy must say what happened and how to fix it.
|
||||
|
||||
---
|
||||
|
||||
## Quality checks
|
||||
|
||||
```text
|
||||
[ ] Color contrast passes for body, labels, captions, buttons, focus rings.
|
||||
[ ] :focus-visible exists and is visible.
|
||||
[ ] Keyboard can reach and operate all controls.
|
||||
[ ] Inputs have labels.
|
||||
[ ] Icon-only buttons have accessible names.
|
||||
[ ] Decorative icons are aria-hidden.
|
||||
[ ] Reduced-motion fallback exists when motion exists.
|
||||
[ ] No href-less fake links are used as controls.
|
||||
[ ] Semantics match behavior.
|
||||
```
|
||||
+200
@@ -0,0 +1,200 @@
|
||||
# Animation discipline craft rules
|
||||
|
||||
Universal rules for when motion earns its place in a UI and what numbers
|
||||
constrain it. The active `DESIGN.md` decides brand-specific motion
|
||||
personality; this file decides whether motion should run at all and at
|
||||
what duration, easing, and accessibility floor.
|
||||
|
||||
## Scene tier first: this file's discipline is calibrated for functional UI
|
||||
|
||||
The research and "minimal motion" stance below is calibrated for **functional / productivity UI**
|
||||
(dashboards, tools, forms, apps) — there, motion must earn its place and decoration is waste.
|
||||
|
||||
But a large share of design work is **expressive** (brand sites, campaign/promo pages, portfolios,
|
||||
landing-page heroes, editorial/cultural features, social covers). For these, **a polished one-shot
|
||||
entrance is part of the deliverable, not decoration**. A fully static expressive page is
|
||||
under-delivered, not "safe". Do not score "no animation" as pass for an expressive scene.
|
||||
|
||||
| Scene | Entrance choreography | Microinteractions | "minimal/none" verdict |
|
||||
|---|---|---|---|
|
||||
| Expressive (brand, campaign, portfolio, landing hero, editorial, social cover) | **Expected** — one choreographed entrance (staggered reveal of hero elements) | hover/press feedback welcome | **not pass** — page feels dead |
|
||||
| Restrained (dashboard, tool, form, admin, report, notice, data) | Avoid; motion only on functional micro-feedback | functional only | **pass** — calm is correct |
|
||||
|
||||
So the "don't animate to decorate / fill silence" rule below is about **functional UI**. In an
|
||||
expressive scene, one well-built entrance is the opposite of slop — it is the job. The rest of this
|
||||
file still governs *how* (duration, easing, reduced-motion); it does not forbid the expressive entrance.
|
||||
|
||||
### Paste-ready expressive entrance (CSS-only, staggered, reduced-motion safe)
|
||||
|
||||
```css
|
||||
@keyframes riseIn {
|
||||
from { opacity: 0; transform: translateY(24px); }
|
||||
to { opacity: 1; transform: translateY(0); }
|
||||
}
|
||||
.rise { opacity: 0; animation: riseIn 0.6s cubic-bezier(0.2, 0, 0, 1) forwards; }
|
||||
.rise-1 { animation-delay: 0.05s; }
|
||||
.rise-2 { animation-delay: 0.18s; }
|
||||
.rise-3 { animation-delay: 0.31s; }
|
||||
.rise-4 { animation-delay: 0.44s; } /* stagger hero → tagline → subject → CTA */
|
||||
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
.rise { animation: none; opacity: 1; transform: none; }
|
||||
}
|
||||
```
|
||||
|
||||
Apply by giving the hero's key elements `class="rise rise-1"`, `rise-2`, etc. in visual order. This
|
||||
one choreographed entrance is usually enough; do not also scatter scroll-reveals on every block
|
||||
(that is the slop pattern the lint rules below still forbid). For thematic motion (petals falling,
|
||||
shimmer, etc.) keep it one-shot and reduced-motion safe.
|
||||
|
||||
---
|
||||
|
||||
Universal numeric rules follow. They apply to *how* motion runs in both tiers.
|
||||
|
||||
> Grounded in primary sources: Tversky/Morrison/Bétrancourt 2002
|
||||
> (IJHCS), Heer & Robertson TVCG 2007, Harrison/Yeo/Hudson CHI 2010,
|
||||
> Doherty & Thadani IBM Systems Journal 1982, Chang & Ungar UIST 1993,
|
||||
> Material 3 motion tokens, IBM `@carbon/motion`, Apple SwiftUI
|
||||
> Animation API, W3C View Transitions, WCAG 2.2.2 + 2.3.3, WebKit's
|
||||
> 2017 `prefers-reduced-motion` rationale.
|
||||
|
||||
## When motion earns its place
|
||||
|
||||
Tversky/Morrison/Bétrancourt's 2002 meta-analysis (IJHCS 57, pp. 247-262)
|
||||
found that every study claiming animation aids comprehension had a
|
||||
broken control — the static version had less information, different
|
||||
procedures, or hidden interactivity. When equalised, animation does
|
||||
**not** beat static for teaching complex systems. The single use case
|
||||
the paper endorses is real-time spatial or temporal reorientation:
|
||||
page transitions, container morphs, viewpoint changes, progress
|
||||
indicators (p. 257).
|
||||
|
||||
A follow-on hazard: Palmiter & Elkerton found animation-trained users
|
||||
*declined* one week after training, while text-trained users *improved*
|
||||
(Tversky 2002, p. 255). Animation's apparent short-term parity hides
|
||||
worse retention.
|
||||
|
||||
So animate when the user is moving through space, time, or state —
|
||||
navigation, container expansion, progress feedback, gesture
|
||||
follow-through. Don't animate to teach, decorate, signal "premium",
|
||||
or fill silence.
|
||||
|
||||
## Duration thresholds
|
||||
|
||||
The cross-design-system convergence is **150 ms** — Material 3 `short3`,
|
||||
IBM Carbon `moderate-01`, Shopify Polaris `150`, Tailwind default,
|
||||
SLDS `duration-fast` all land here. Use it as the default duration for
|
||||
state-confirmation feedback.
|
||||
|
||||
| Duration | Use |
|
||||
|---|---|
|
||||
| 50–100 ms | Instant feedback (button press, toggle commit, hover) |
|
||||
| 150 ms | Default for state-confirmation |
|
||||
| 200–300 ms | Entering UI (modals, sheets, dropdowns) |
|
||||
| 300–500 ms | Cross-screen transitions, container morphs |
|
||||
| > 500 ms | Reserved for cross-screen, staged, or platform-native transitions (e.g. M3 `long2`-`extraLong4`, Heer & Robertson 2007's per-stage recommendation). |
|
||||
|
||||
Non-navigation microinteractions — hover, press, toggle, validation,
|
||||
chip selection, row expansion — should stay under 500 ms. Past that the
|
||||
user notices the motion as motion and waits on the UI rather than
|
||||
working through it. Two qualifications: frequent animations (a hover
|
||||
effect seen 50 times per session) need to stay ≤200 ms; mobile
|
||||
animations should run 20–30% shorter than desktop equivalents because
|
||||
travel distances are shorter.
|
||||
|
||||
## Curve vs spring
|
||||
|
||||
Use a curve for opacity, color, and any property that changes value
|
||||
between two known points. Use a spring for position, scale, rotation,
|
||||
and gesture-driven motion — anything that should feel physical.
|
||||
|
||||
Material 3 standard easing is `cubic-bezier(0.2, 0, 0, 1)` — front-loaded;
|
||||
the trailing zero makes the curve hit its target instantly and settle.
|
||||
M2 standard was the symmetric `cubic-bezier(0.4, 0, 0.2, 1)`, preserved
|
||||
in M3 under the name `legacy`. Anyone shipping the M2 curve and calling
|
||||
it "M3" is on legacy tokens. M3 `emphasized` is a **two-segment Bézier
|
||||
path**, not a single cubic-bezier; single-cubic approximations silently
|
||||
lose the front-loaded character. CSS `linear()` (Chrome 113+) is the
|
||||
only way to replicate it on a single property.
|
||||
|
||||
Apple's published SwiftUI default spring is
|
||||
`(response: 0.5, dampingFraction: 0.825, blendDuration: 0)`. The widely
|
||||
cited `.snappy = 0.25 s, .smooth = 0.35 s` numbers are wrong — Apple's
|
||||
docs assign all three presets a 0.5 s base, differing only in bounce
|
||||
(0 / 0.15 / 0.3).
|
||||
|
||||
Spring framework defaults disagree. motion.dev's physics-mode default
|
||||
is ζ ≈ 0.5 (bouncy). React Spring's `default` is ζ = 0.997 (critically
|
||||
damped). Same word "default", opposite feel — React Spring's `wobbly`
|
||||
is the actual feel-equivalent of motion.dev's `default`. Pick
|
||||
consciously.
|
||||
|
||||
## Reduced motion
|
||||
|
||||
Every animation that translates, scales, rotates, or parallaxes must
|
||||
respect `@media (prefers-reduced-motion: reduce)`. WebKit shipped this
|
||||
in 2017 to address vestibular triggers; the W3C MQ5 spec lets the UA
|
||||
or author **strip motion entirely or substitute static imagery** —
|
||||
the spec does not mandate which.
|
||||
|
||||
Working rule: strip motion-on-an-axis (translate, scale, rotate,
|
||||
parallax). Keep opacity/color crossfades as substitutes when a state
|
||||
change still needs to be conveyed. Be explicit — the View Transitions
|
||||
API does **not** apply `prefers-reduced-motion` automatically; the
|
||||
author must add a query override on the pseudo-elements or skip
|
||||
`startViewTransition` entirely.
|
||||
|
||||
WCAG calibration: 2.2.2 (Pause/Stop/Hide) is Level A — the legal floor
|
||||
under ADA Title II 2024 / EN 301 549 / EAA — but it names cognitive,
|
||||
attentional, and reading populations, not vestibular. Vestibular
|
||||
language lives in 2.3.3, which is **AAA**. Don't conflate the two.
|
||||
Building for vestibular users is a craft commitment beyond the legal
|
||||
floor, not a WCAG mandate.
|
||||
|
||||
**Flashing limits.** WCAG 2.3.1 (Level A) permits flashing only when
|
||||
there are no more than three flashes within any one-second period, or
|
||||
the flashing area stays below the general and red flash thresholds.
|
||||
WCAG 2.3.2 (AAA) forbids flashing more than three times within any
|
||||
one-second period, regardless of area or brightness. The protected
|
||||
concern is photosensitive epilepsy; the legal floor isn't negotiable. For gamified UI, onboarding celebrations, sparkles,
|
||||
confetti, level-up bursts, and shimmer: avoid rapid flashing unless
|
||||
tested against the thresholds, and prefer one-shot animations over
|
||||
loops.
|
||||
|
||||
## Repeated and ambient motion
|
||||
|
||||
The rules above target one-shot transitions. Looping motion (skeleton
|
||||
shimmer, idle backgrounds, autoplay, reward bursts) has different
|
||||
constraints.
|
||||
|
||||
- Cap iteration count: carousels at 3-5 cycles then pause; skeleton shimmer until content lands, never indefinitely.
|
||||
- WCAG 2.2.2 (Level A) requires a pause control for any motion running longer than 5 seconds — moving, blinking, or scrolling content, not only video.
|
||||
- Cancel ambient motion on route change.
|
||||
- Reward animations are one-shot. Confetti, sparkles, level-up bursts fire once and dismiss; no looping timer.
|
||||
- Spinners must not run indefinitely. Escalate to progress/cancel states and stop animation at 60 s, matching `state-coverage.md`.
|
||||
|
||||
## Cross-platform handoff
|
||||
|
||||
Native conventions diverge.
|
||||
|
||||
- **iOS** uses spring physics with perceptual `(response, dampingFraction)` parameters. Apple HIG documents principles, not numerical curves; the SwiftUI Animation API JSON is the source for actual numbers. UIView curve cubic-beziers commonly cited online are reverse-engineered, not Apple-published.
|
||||
- **Android** uses cubic-bezier curves through M3 motion tokens (50–1000 ms range, 16 named durations). Predictive back is a *gesture-progress primitive*, not a transition primitive — `BackEvent.progress` is sampled per-frame from the touch stream and the destination is rendered behind the current surface while still on it. Cancellation is a first-class lifecycle state.
|
||||
- **Web** has the View Transitions API (default 0.25 s, no easing specified by the spec — falls through to CSS `ease`). Same-document support 90.94%; cross-document 87.82%. Cross-document is same-origin and user-initiated only.
|
||||
|
||||
A "one curve fits all platforms" approach loses on each. If the brief
|
||||
specifies platform fidelity, follow the platform; if it specifies brand
|
||||
consistency, pick one motion vocabulary and apply it everywhere.
|
||||
|
||||
## Common mistakes (lint these)
|
||||
|
||||
- "Skeleton screens feel 11% faster" — Harrison/Yeo/Hudson CHI 2010 measured *backwards-decelerating ribbed determinate progress bars* (n=16). The induced-motion mechanism doesn't transfer to skeletons.
|
||||
- "Heer & Robertson recommend 300–1000 ms eased transitions" — they tested 1.25 s and 2 s only. Their recommendation is "~1 second per stage".
|
||||
- "Doherty Threshold = 400 ms" — the 1982 paper does not contain "400". The lowest threshold actually measured is 300 ms.
|
||||
- M2 standard easing `cubic-bezier(0.4, 0, 0.2, 1)` labelled as "Material 3". M3's standard is `cubic-bezier(0.2, 0, 0, 1)`.
|
||||
- Animations that *perform* a state change rather than *confirming* one that has already happened. Optimistic UI first; motion second.
|
||||
- More than 500 ms on any non-cross-screen transition.
|
||||
- Animation as the only signal of state change. Reduced-motion users miss it; always pair with a static affordance (color, position, label).
|
||||
- Ignoring `prefers-reduced-motion` on transform-based animations — the highest-cost vestibular triggers.
|
||||
- Curve-based animation on a `transform: scale()` that should feel physical. Use a spring.
|
||||
- Hero choreography in **productivity tools**. In a tool/dashboard the motion budget belongs on functional micro-feedback, not on decorative landing-style sequences. (This does not apply to expressive scenes — see the scene-tier section at top; an expressive brand/campaign/portfolio page is expected to have one choreographed entrance.)
|
||||
- Decorative motion in the working canvas of a productivity tool.
|
||||
+299
@@ -0,0 +1,299 @@
|
||||
---
|
||||
name: anti-ai-slop
|
||||
description: Anti-AI-default design craft rules. Use during generation and again as a quality-gate check to avoid generic model output, fake proof, decorative emoji, template layouts, and unearned visual effects.
|
||||
mode: reference
|
||||
platform: any
|
||||
scenario: horizontal-craft
|
||||
preview:
|
||||
type: none
|
||||
default_for:
|
||||
- anti AI slop
|
||||
- AI味
|
||||
- 反AI味
|
||||
- generic design
|
||||
- template-looking design
|
||||
- design polish
|
||||
fidelity: system
|
||||
sources:
|
||||
- adapted-from-open-design/craft/anti-ai-slop.md
|
||||
- extracted-from-previous-quality-gate.md
|
||||
---
|
||||
|
||||
# Anti-AI Slop
|
||||
|
||||
This file is a generation-time craft reference. It defines what **not** to do by default.
|
||||
|
||||
`quality-gate.md` should reference this file, not duplicate it.
|
||||
|
||||
Core test:
|
||||
|
||||
```text
|
||||
Did this design choice come from the brief, scenario skill, design system, content, or user request?
|
||||
If not, it is probably model autopilot.
|
||||
```
|
||||
|
||||
A slop item is not always forbidden. It is forbidden when used as an unearned default.
|
||||
|
||||
---
|
||||
|
||||
## P0 hard failures
|
||||
|
||||
Fix these before delivery.
|
||||
|
||||
1. **Default indigo / purple AI accent**
|
||||
- Avoid `#6366f1`, `#4f46e5`, `#4338ca`, `#3730a3`, `#8b5cf6`, `#7c3aed`, `#a855f7` as generic accent colors.
|
||||
- Use the active design system token or a content-driven palette.
|
||||
|
||||
2. **Generic blue-purple hero gradient**
|
||||
- Avoid purple→blue, blue→cyan, indigo→pink hero gradients unless the brand or brief explicitly earns it.
|
||||
|
||||
3. **Emoji as UI icons**
|
||||
- Do not use `✨`, `🚀`, `🎯`, `⚡`, `🔥`, `💡` as feature icons, section markers, button decoration, status labels, or deck bullets.
|
||||
- Use inline SVG, typographic numbers, CSS shapes, or no icon.
|
||||
|
||||
4. **Invented proof**
|
||||
- Do not invent “10× faster”, “99.9% uptime”, “3× productivity”, fake customer logos, fake testimonials, fake awards, fake press quotes, fake benchmarks, or fake market data.
|
||||
- Use `horizontal-craft/link-and-proof.md`.
|
||||
|
||||
5. **Filler content**
|
||||
- No `lorem ipsum`, “feature one / two / three”, “placeholder text”, fake console handlers, TODO comments, or empty demo logic.
|
||||
|
||||
6. **Rounded-card dashboard default**
|
||||
- Avoid the reflexive pattern: rounded white card + 1px border + subtle shadow + colored left border.
|
||||
- Use hierarchy, spacing, typography, and state semantics instead.
|
||||
|
||||
7. **Unlabeled placeholders**
|
||||
- If content is demo or missing, label it visibly. Do not disguise it as real proof.
|
||||
|
||||
---
|
||||
|
||||
## Color and palette failures
|
||||
|
||||
Avoid as defaults:
|
||||
|
||||
- purple / blue two-stop gradients as hero, button fill, text gradient, progress bar, or accent
|
||||
- generic AI dark mode: near-black background + indigo / purple glow
|
||||
- mesh gradients without a strong reason
|
||||
- pastel pink / lavender / peach as automatic “soft polish”
|
||||
- black + gold / muddy bronze as automatic “premium”
|
||||
- dirty earth tones on dark backgrounds
|
||||
- Tailwind / Vercel tutorial defaults: indigo, slate, gray ramp, emerald accent, tutorial-blue
|
||||
- low-contrast muted text, especially opacity `0.4–0.6`
|
||||
|
||||
Prefer:
|
||||
|
||||
- a nameable color territory
|
||||
- product- or content-driven palettes
|
||||
- solid color fields when conviction matters
|
||||
- material metaphors: paper, ink, cinnabar, brick, forest, phosphor, steel, terminal amber
|
||||
- explicit CSS tokens instead of scattered magic hex values
|
||||
|
||||
---
|
||||
|
||||
## Typography failures
|
||||
|
||||
Avoid as defaults:
|
||||
|
||||
- Inter, Roboto, Open Sans, Arial, `system-ui`, PingFang SC, HarmonyOS Sans, Microsoft YaHei as the visible display identity
|
||||
- Space Grotesk / Fraunces / Playfair / Instrument Serif as automatic taste markers without reason
|
||||
- italic serif accent word inside a sans h1 as a reflex move
|
||||
- gradient text inside h1
|
||||
- tracked all-caps section labels everywhere
|
||||
- Chinese body text that is too light on dark backgrounds
|
||||
- Chinese display text without an intentional display font or accepted fallback
|
||||
|
||||
Allowed:
|
||||
|
||||
- common fonts as fallback stack positions
|
||||
- system fonts when the design system explicitly chooses a neutral product voice
|
||||
- expressive fonts when loaded and tied to the visual direction
|
||||
|
||||
---
|
||||
|
||||
## Layout failures
|
||||
|
||||
Avoid:
|
||||
|
||||
- generic Hero → Features → Pricing → FAQ → CTA sequence with no variation
|
||||
- three equal feature cards with icon / title / description as filler
|
||||
- bento grid unless the information is genuinely modular
|
||||
- centered `max-width: 800px; margin: auto; text-align: center` across all sections
|
||||
- card grids where every card has the same size and rhythm
|
||||
- fake macOS window chrome with traffic-light dots
|
||||
- top nav default: monogram left + four links right + hairline rule
|
||||
- floating phone / device mockups with reflection as default
|
||||
|
||||
Prefer:
|
||||
|
||||
- asymmetric grids
|
||||
- meaningful density variation
|
||||
- editorial rhythm
|
||||
- one strong signature surface
|
||||
- exact-ratio frames for key screens
|
||||
- visual choices based on actual content hierarchy
|
||||
|
||||
---
|
||||
|
||||
## Component failures
|
||||
|
||||
Avoid:
|
||||
|
||||
- decorative emoji as icons or UI ornament
|
||||
- pill chip with colored dot as the universal badge
|
||||
- gradient primary button + outline ghost button with equal weight
|
||||
- colored rounded status pills for every state
|
||||
- fully rounded plastic CTA buttons with shadow
|
||||
- fake avatars, fake quote cards, fake testimonial blocks
|
||||
- icon grids that add no information
|
||||
|
||||
Use instead:
|
||||
|
||||
- inline SVG icons
|
||||
- typographic numbers
|
||||
- CSS shapes
|
||||
- hairline labels
|
||||
- text links for secondary actions
|
||||
- real component states
|
||||
- no icon when text is clearer
|
||||
|
||||
---
|
||||
|
||||
## Imagery failures
|
||||
|
||||
Avoid:
|
||||
|
||||
- stock photos used as fake product evidence
|
||||
- Unsplash desks, sticky notes, laptops-with-coffee, moodboards, gears, Pantone flatlays
|
||||
- fake product screenshots with fake proof
|
||||
- screenshots without captions or real source context
|
||||
- three-quarter floating device mockups as default
|
||||
|
||||
If real imagery is missing:
|
||||
|
||||
- use type-only hero
|
||||
- use honest product UI with demo-labeled content
|
||||
- use SVG diagrams
|
||||
- use typographic plates
|
||||
- use honest placeholders
|
||||
|
||||
---
|
||||
|
||||
## Chinese copy smells that affect design quality
|
||||
|
||||
This is not a copywriting rulebook. Only fix copy when it makes the artifact feel generic, breaks hierarchy, or weakens CTA clarity.
|
||||
|
||||
Common visual-quality smells:
|
||||
|
||||
- 赋能、打造、匠心、极致、丝滑、惊艳、震撼、颠覆、革新、引爆、解锁、加持、沉浸、深度、全方位、一站式
|
||||
- 闭环、抓手、心智、链路、生态、矩阵、势能、心智占位
|
||||
- 全新升级、隆重推出、强势来袭、火热进行中
|
||||
- 「X，让 Y 更 Z」
|
||||
- 「不止 X，更是 Y」
|
||||
- 「重新定义 X」
|
||||
- 「X，从未如此 Y」
|
||||
- 「为 X 而生」
|
||||
|
||||
Prefer concrete verbs:
|
||||
|
||||
- 查、算、生成、对比、导出、预约、上传、筛选、复盘、发送
|
||||
|
||||
---
|
||||
|
||||
## Motion failures
|
||||
|
||||
Avoid:
|
||||
|
||||
- fade-in on every section as the only motion idea
|
||||
- parallax by default
|
||||
- bouncing hover curves everywhere
|
||||
- decorative background motion unrelated to the task
|
||||
- animations that delay input or obscure results
|
||||
|
||||
Use:
|
||||
|
||||
- one purposeful signature motion
|
||||
- tactile button feedback
|
||||
- result reveal for tools
|
||||
- view transitions for multi-view artifacts
|
||||
- reduced-motion fallback
|
||||
|
||||
---
|
||||
|
||||
## Background and texture failures
|
||||
|
||||
Avoid:
|
||||
|
||||
- full-page repeating grid / dot / line patterns behind text
|
||||
- high-contrast patterns behind body or display text
|
||||
- multiple noise layers
|
||||
- blobs, orbs, gradient spheres, floating rings
|
||||
- background decoration used only to fill empty space
|
||||
|
||||
Allowed:
|
||||
|
||||
- one subtle material texture on an isolated surface
|
||||
- edge hairlines
|
||||
- paper grain at low opacity when the visual world calls for it
|
||||
- no texture when solid color is stronger
|
||||
|
||||
---
|
||||
|
||||
## Over-addition decision table
|
||||
|
||||
| Tempted to add… | Default decision |
|
||||
|---|---|
|
||||
| gradient | probably not; use solid field or grounded palette |
|
||||
| emoji | no; use inline SVG, type, or nothing |
|
||||
| rounded card + left-border accent | no; use hierarchy or divider |
|
||||
| blob / hand-drawn hero illustration | no unless the visual direction needs it |
|
||||
| testimonial quote | only with real user-provided quote |
|
||||
| icon feature row | only if icons clarify information |
|
||||
| bento grid | only if information is genuinely modular |
|
||||
| hero + 3 cards + CTA | redesign from actual content |
|
||||
| scroll reveal on everything | no; use one choreographed motion if any |
|
||||
|
||||
Rule of thumb: if you are unsure whether to add it, do not add it.
|
||||
|
||||
---
|
||||
|
||||
## Emoji scan
|
||||
|
||||
Before delivery, scan visible text and labels for emoji characters.
|
||||
|
||||
Forbidden emoji usage:
|
||||
|
||||
- feature icons
|
||||
- slide icons
|
||||
- section headers
|
||||
- navigation icons
|
||||
- status labels
|
||||
- CTA decoration
|
||||
- fake excitement or “friendly” ornament
|
||||
|
||||
Allowed emoji usage:
|
||||
|
||||
- user-provided content contains emoji
|
||||
- product/content is emoji-based
|
||||
- chat/social content uses emoji as actual content
|
||||
- user explicitly requests emoji-led style
|
||||
|
||||
Replacement priority:
|
||||
|
||||
1. inline SVG
|
||||
2. CSS shape
|
||||
3. typographic number
|
||||
4. text label
|
||||
5. no icon
|
||||
|
||||
Mandatory scan ranges:
|
||||
|
||||
```text
|
||||
U+1F300–U+1F6FF
|
||||
U+1F900–U+1F9FF
|
||||
U+1FA70–U+1FAFF
|
||||
U+2600–U+26FF
|
||||
U+2700–U+27BF
|
||||
U+2300–U+23FF
|
||||
U+FE0F
|
||||
U+200D
|
||||
```
|
||||
+226
@@ -0,0 +1,226 @@
|
||||
---
|
||||
name: chinese-typography
|
||||
description: 给中文排版做决策时使用。覆盖：版心 / 页边距 / 字号 / 字重 / 字间距 / 行距 / 行长 / 段落缩进 / 标点占格 / 网格系统 / 字体选择与搭配 / 横排直排混排 / 标题断句 / 破折号 / 全角半角 / 避头尾。触发场景：书籍排版、长文/文章页、PDF 报告、H5/海报、PPT/Keynote、网页正文、画册、招股书、PRD/技术文档、古籍/文言、公文、邀请函、博物馆图录，或任何"中文阅读体验不舒服"的诊断与修正。
|
||||
---
|
||||
|
||||
# 中文字体排版 Chinese Typography
|
||||
|
||||
"模数 → 网格 → 版心 → 文本造型"方法论。核心一句话：**把一个页面的所有空间要素（版心、页边距、字号、行距、字距）都关联到一个共同的模数（基因）上**，让秩序看得见、看不见地存在。
|
||||
|
||||
> **格 = 工具属性的网格（理性）；律 = 设计师对格的使用（灵性）。美比严格按网格排列更重要。**
|
||||
|
||||
## 什么时候启用本 skill
|
||||
|
||||
- 用户让你"排个版面 / 做个文档 / 调下样式 / 设计 H5 / 写一份正式 PDF / 做古籍样式 / 排公文"，且文本主体是中文
|
||||
- 用户指出"这页看着乱 / 难读 / 不专业 / 不像出版物 / 字太挤 / 行太长 / 标题断得奇怪"
|
||||
- 用户在 CSS / Tailwind / InDesign / Figma / PPT / Keynote / Word / Typst / LaTeX 上做中文长文样式
|
||||
- 用户问"用多大字 / 多大行距 / 多宽的栏 / 留多少白 / 横排还是直排 / 标题怎么换行"
|
||||
- 用户做"中国最美的书"风、出版社风、博物馆图录风、学术风、商务报告风、古典/书法风的设计
|
||||
|
||||
## 触发时务必先问自己 3 个方向题
|
||||
|
||||
1. **横排还是直排？** 古籍今译、文言、诗词、邀请函、传统书法集、博物馆图录的部分内页 → 优先考虑直排；现代长文、教材、商务文档 → 横排。
|
||||
2. **是否有混排？** 横排中嵌入直排（标题/匾额、对联、引文造型）、直排中嵌入横排（西文术语、数字、图注）都是常用手法，不是"破格"，是基础语法。
|
||||
3. **地区风格？** 大陆简体（横排标点偏左下、直排偏右上、开明式标点）/ 港台繁体（标点居中、可不严格避头尾）/ 日文（标点偏左下/右上、严格避头尾）。差异主要在标点位置与避头尾松紧，不要混着用。
|
||||
|
||||
详见 `reference/directions.md`。
|
||||
|
||||
## 九条最关键的规则（按重要性）
|
||||
|
||||
### 1. 先决定排版方向，再决定一切版心
|
||||
- **直排**：文字上→下、行右→左；页面右翻、装订右侧；图/表标题左右侧；点号"，。；："偏右上；引号用直角「」『』
|
||||
- **横排**：文字左→右、行上→下；页面左翻、装订左侧；图/表标题上下方；大陆点号偏左下；引号用弯""''
|
||||
- **混排**：直排中遇 1 字英文/缩略词 → **正立排**；遇 2–3 位数字 → **纵中横排（tate-chu-yoko）**；遇整段西文 → **顺时针 90° 旋转**
|
||||
- 不要把日文标点规则套到中文（如直排冒号转 90° 躺下是日文做法，中文要直立）
|
||||
|
||||
### 2. 标题断句必须按词，不按字数
|
||||
**用户最常踩的坑。**
|
||||
- 正文：默认按字断行，不要按词；汉语双音节词约占 60%，按词断会变锯齿状不美。
|
||||
- **标题：必须按词断**，否则会出歧义（反例："我外交部强烈谴责伊拉克 / 大使馆被炸事件"）。
|
||||
- 虚词位禁忌：**"的"不入行首；"和 / 与 / 及 / 或"不入行末**；地名/人名/书名/术语严禁拆开。
|
||||
- 标题占行必须是正文行高整数倍：一级 4–5 行、二级 2–3 行、三级 1–2 行、双行题 3 行。
|
||||
- 大标题必出现在奇数页（横排左翻书 = 右页 / 直排右翻书 = 左页）。
|
||||
- 写 HTML 时手动加 `<wbr>` 或 `<br>` 控制断点；CSS 不可断字符之间用 `⁠`（U+2060 WJ）。
|
||||
|
||||
详见 `reference/title-and-breaking.md`。
|
||||
|
||||
### 3. 先定模数（modulus），再定一切
|
||||
所有字号、行距、页边距、版心宽高，都必须是同一个模数（典型 1.5pt 或 0.5pt）的整数倍。模数像"基因"贯穿全书。
|
||||
- 入门默认：**模数 = 1.5pt**，正文 9pt（= 6×1.5pt），图注 6pt，小标题 12pt
|
||||
- 不要用 1.618pt 这种带小数的"黄金比"做模数——汉字是定宽方格，多位小数会让单元格宽算不齐
|
||||
- 1–5pt 字号用 0.5pt 步进，6–12pt 用 1pt 步进（铅字时代沿用至今的可整除性）
|
||||
|
||||
### 4. 行长必须是字号整数倍
|
||||
**这是 W3C《中文排版需求》§2.3.5 明文要求，不是建议。**
|
||||
- 公式：`行长 = 字号 × 字数`；不整倍会导致两端对齐时末行字距异常（错版信号）。
|
||||
- **横排正文 17–40 字最佳，硬上限 ≤48 字；直排正文 ≤55 字；行长最小 ≥10 字**（少于 10 字回行频繁、易疲劳）。
|
||||
- 在 CSS：`max-width: 30em` 是对中文最稳的护栏（西文是 65–75 字符 ≈ 35em）。
|
||||
- 拉宽页面就增加栏数，不是无限拉长行。
|
||||
- 框架高公式：`高 = (行数 − 1) × 行高 + 字号`，末行只占字号高度，不要把高度凑整成 mm。
|
||||
|
||||
### 5. 行距 = 字号的 50%–100%（即 1.5–2 倍行高）
|
||||
- W3C 标准：行距（行间空白） = 字号的 50%–100%，**对应行高（含字本身）= 字号的 1.5–2 倍**。
|
||||
- 现代屏幕舒适：`line-height: 1.5`；长文/文学：1.7–2.0；密集表格：1.33。
|
||||
- **超过字号 100% 不增易读性**（即 line-height 超过 2）；过窄（< 1.2）密集；过宽（> 2.2）章节断裂感。
|
||||
- 直排带注音时，**行距 ≥ 1.5 × 基字**。
|
||||
- 行间有专名号 / 着重号 / 书名号甲式时，单面装行距 ≥ 1/2 字号，双面装 ≥ 5/8 字号。
|
||||
|
||||
### 6. 版心位置略偏上、内紧外松、上紧下松
|
||||
- 横排书籍：版心**略往上**移取得视觉最佳点
|
||||
- 对页（书籍/PDF）：**订口（内）< 切口（外）< 天头（顶）< 地脚（底）**（典型比例 3:5:8:13 或 2:3:5:8）
|
||||
- 直排对页相反：天头 < 地脚（与横排相同），但订口（右页右侧 / 左页左侧）< 切口
|
||||
- 页边距太小，文字会"扑面而来"产生压迫；版心是负形的留白决定优雅程度
|
||||
- **先定版心再余白**（中式）——不是西式"先留边距后剩版心"
|
||||
|
||||
### 7. 字间距：原则上不动（密排）
|
||||
- 现代汉字字体的字面率 92%–96%，字与字之间已天然留白；**正文不要再加 letter-spacing**
|
||||
- CSS：`letter-spacing: 0`（不要设 `0.05em` 这种"看着精致"的间距，会破坏字号节奏）
|
||||
- 只有标题、Logo、空间表达情绪时才主动加字距
|
||||
- 疏排（增加字距）的合理场景：标题求平衡、图说求平衡、短诗词、儿童读物；常见 1/4 em / 1/3 em / 1/2 em / 1 em
|
||||
|
||||
### 8. 字重和字号联动选择，控制纸/屏对比度
|
||||
- 小字（6–7.5pt 印刷 / < 14px 屏幕）：中等字重（Regular / 55S）辨识度最高，避免极细字重
|
||||
- 大字（≥ 9pt 印刷 / ≥ 16px 屏幕）：可以用 Light/45S 取得优雅感
|
||||
- 屏幕白底深色文字 ≥ 4.5:1 对比度（WCAG AA）；纸面看"字的黑能否压过纸的白"
|
||||
- 同一段文本只用 1 个字体家族的不同字重，不要混 4 个字体
|
||||
- **正文最小字号下限**：W3C 规定 6 号 = 7.875pt（≈ 2.8mm），更小汉字结构难辨
|
||||
|
||||
### 9. 标点必须按"加法模式"做宽度调整，并严格避头尾
|
||||
**横排中文易忽略的最大问题。** 大陆默认开明式（句末全宽、句内半宽）；港台默认居中式；行末标点一律半宽（GB/T 15834-2011 §5.1.10）。
|
||||
- 选 1 种标点风格贯穿全文：**全角式 / 半角式 / 开明式 / 居中式**（详见 `reference/punctuation.md`）
|
||||
- 加法模式：标点 = 半宽 + 加空隙；调整对象是空隙，不是字面。InDesign / QuarkXPress / JIS 都按加法。
|
||||
- 避头尾必须做：**basic 级 = 最低标准**（行首禁顿逗句冒分叹问、结束引括书名号；行尾禁开始引括书名号）；正式中文出版用 **GB 级 / strict 级**
|
||||
- 行首禁止：`。，、；：？！…—）》」』`等；行尾禁止：`（《「『"`
|
||||
- 段落缩进首行 2 字（`text-indent: 2em`），段间不空行；引文整段缩进 4 字
|
||||
- 不可分离禁则：破折号 / 省略号 / 数字内 / 数字+单位 / 上下标+被注词 / 西文单词 都不可被换行拆开
|
||||
|
||||
详见 `reference/punctuation.md`。
|
||||
|
||||
## 表现力手法（严谨之上，让中文版面有亮点、有节奏，而不是平铺）
|
||||
|
||||
上面九条保证"**排得严谨、专业、不外行**"。但严谨不等于出彩——一篇规范却平淡的长文，正文+标题+段落一路平铺，没有视觉锤、没有节奏，就是常见的"中文排版很无聊"。对**长文 / 编辑页 / 海报 / 画册 / 公众号 / 任何想要有设计感的中文页**，在守住九条的前提下，主动用下面的手法做出亮点（按内容选 1–3 个，不要全堆）：
|
||||
|
||||
- **标题字号大反差。** 正文与主标题拉开 3–5 倍字号跨度（正文 16px → 主标 clamp 到 48–96px+），让标题成为视觉锤，而不是"大一号的正文"。中文方块字在大字号下张力很强，敢放大。
|
||||
- **字重对比制造焦点。** 同一屏里用"特粗大字 + 常规正文 + 细体辅助信息"三档字重拉开层次；中文避免堆砌多字重，2–3 档即可，但对比要敢拉开。
|
||||
- **首字下沉 / 段首装饰。** 文章开篇或章节起始用首字下沉（2–3 行高）或放大的起首句，给阅读一个明确的"入口仪式"。
|
||||
- **横竖混排做造型。** 横排正文中嵌竖排标题/引文/章节名（参考第 1 条），是中文特有的造型语法——竖排标题贴边、竖排短引文做侧栏，立刻有"中文设计感"而非"翻译腔网页"。
|
||||
- **引文 / 金句造型块。** 把关键句拎出来放大成独立造型块（大字号、留白、或配标点装饰），作为长文的节奏停顿点和记忆点，而不是夹在段落里。
|
||||
- **大字标题 / 数字作版面主体。** 海报、章节页、数据页可以让一行大字或一个大数字占据大半视口，正文退为辅助——文字本身就是画面。
|
||||
- **节奏：快慢交替。** 标题区/引文区/图版区是"慢、重、大"，正文区是"快、轻、密"，靠字号留白的明暗交替制造翻页般的节奏，避免从头到尾一个密度。
|
||||
|
||||
底线：**这些手法服务内容与可读性，不是炫技**。表现力建立在九条严谨规则之上——先排得对，再排得出彩；大字反差、混排造型不能破坏避头尾、行长模数、版心秩序。该克制的场景（公文、正式报告正文）保持安静，该出彩的场景（编辑长文、海报、品牌内容）主动用。
|
||||
|
||||
## 用之前必读的设计哲学
|
||||
|
||||
1. **网格是工具不是枷锁**。瑞士派"具有建设性的、可供分析和理解的设计"——网格能让最普通的排印公司也做出优雅版面，但**优秀作品总在恰当的时候"破格"**
|
||||
2. **直觉是伪装的记忆**——经过训练的直觉才有效；新人先严格守规则，老手再有意识地破规则
|
||||
3. **正形 vs 负形**：版心是正形，页边距是负形，负形甚至优先于正形成为审美判断依据。**留白不是空，是设计**
|
||||
4. **一书一宇宙**：宏伟来自精妙细节。标点占格、行距数值这种"小事"是阅读舒适度的核心
|
||||
5. **理性建筑感与灵性诗意的张力**：中文排版同时需要欧氏几何/费氏数列的理性，与"格律美"的灵性
|
||||
6. **基础概念不可违背，大原则不宜违背，多选项按优先顺序构建自洽逻辑**（"孔雀计划"序）
|
||||
7. **字体设计 ≠ 字体排印**。skill 范围限定后者；不要陷入字体本身好坏的讨论，而要管"怎么用"
|
||||
|
||||
## 标准工作流（任何媒介通用）
|
||||
|
||||
按这个顺序决策，不要跳步：
|
||||
|
||||
1. **确定排版方向**：横排 / 直排 / 混合；地区风格（大陆 / 港台 / 日式）
|
||||
2. **确定开本/画布**：纸面用毫米，屏幕用 px，纵横比常用 2:3 / 3:4 / 16:9 / 5:8
|
||||
3. **确定正文字号**：印刷 9pt / 屏幕 16px / H5 看视距
|
||||
4. **确定模数**：通常 = 正文字号 / 6 或 / 4（如正文 9pt → 模数 1.5pt；正文 16px → 模数 4px）
|
||||
5. **建版心**：开本 = 正文字号 × 整数（如 60 字宽 × 90 字高 = 540×810pt）。**先版心，后余白**
|
||||
6. **设页边距**：按模数的整数倍设 L/R/O/U，遵守"内紧外松、上紧下松"
|
||||
7. **算分栏**：每栏 17–40 字（栏间距也是模数整数倍，常用 2 字宽 = 18pt）
|
||||
8. **设行距**：字号 × 1.5~2，且必须是模数整数倍
|
||||
9. **定字号体系**：标题 / 小标题 / 正文 / 图注 / 注释 / 页码，全部模数倍数；标题必须是正文行高整数倍
|
||||
10. **选字体**：1 个家族多个字重；为衬线/无衬线、宋/黑/楷/仿宋做出与内容气质匹配的选择
|
||||
11. **设标点风格**：全角 / 半角 / 开明 / 居中，全文统一
|
||||
12. **排印 + 检查标点占格 + 检查回行 + 检查标题断句 + 检查文本灰度均匀 + 检查孤行孤字**
|
||||
|
||||
|
||||
## 字体选择分流规则（不在本文件直接选字体）
|
||||
|
||||
本文件负责中文排版 baseline：版心、行长、行距、段落、标点、标题断句、阅读灰度。**不要从本文件选择具体展示字体**。
|
||||
|
||||
字体选择按两层处理：
|
||||
|
||||
```text
|
||||
普通中文 Web / UI / H5 / 原型正文
|
||||
→ 使用安全系统字体栈，不读取 `reference/fonts.md`
|
||||
|
||||
字体会显著影响视觉方向，或需要命名字体 / 上传字体 / OSS 字体 / CDN 字体
|
||||
→ 必须读取 `reference/fonts.md`
|
||||
```
|
||||
|
||||
需要选字体时读 `reference/fonts.md`：§ 一 选字体（气质→字体表）→ § 二 加载执行（含 § 2.5 组装 font-family）。字体的选择和加载都在该文件内完成，不要再拆成额外文件。
|
||||
|
||||
### 安全默认字体栈
|
||||
|
||||
普通中文 Web、UI、H5、表单、Dashboard、工具页正文，默认使用系统中文字体栈。中文字体必须放在西文字体之前，保护中文标点、破折号、省略号和全角符号。
|
||||
|
||||
```css
|
||||
font-family: "PingFang SC", "HarmonyOS Sans SC", "Noto Sans CJK SC",
|
||||
"Microsoft YaHei UI", "Microsoft YaHei",
|
||||
system-ui, -apple-system, BlinkMacSystemFont, sans-serif;
|
||||
```
|
||||
|
||||
正文不要使用展示字体、书法字体、游戏字体、强装饰字体。标题可以更有性格，但必须先进入 `reference/fonts.md` 做场景筛选。
|
||||
|
||||
从 `fonts.md` 选定了具体字体（尤其是给英文单独指定了 Latin 字体）后，写 `font-family` 时务必按 `reference/fonts.md § 2.5` 组装：**含中文的页面，`font-family` 里必须显式出现一个 CJK 字体名，Latin 字体后面绝不能直接接 `system-ui`**（否则中文 fallback 不可控）。
|
||||
|
||||
### 必须读取 `reference/fonts.md` 的情况
|
||||
|
||||
只要命中下列任一条件，就不要在本文件内凭感觉选字体，必须读取 `reference/fonts.md`：
|
||||
|
||||
| 触发条件 | 为什么必须读 fonts.md |
|
||||
|---|---|
|
||||
| 封面、海报、小红书、公众号首图、PPT 封面、活动页、主视觉 | 标题字体会直接决定视觉气质 |
|
||||
| 用户给了字体相关风格词：科技感、工业感、文学感、古籍感、学术感、杂志感、高级感、正式、公文、书卷气、手作感 | 这些不是排版 baseline，属于字体场景选择 |
|
||||
| 用户明确提到字体、字形、字感、宋体、黑体、楷体、仿宋、标题字、展示字 | 已进入字体选择任务 |
|
||||
| 需要命名字体、上传字体、OSS 字体、CDN 字体、`@font-face` 或自托管字体 | 必须确认是否可加载、是否有 fallback |
|
||||
| 长文、报告、公众号、白皮书、出版感页面且字体会影响阅读气质 | 需要在宋/黑/楷/仿宋和字面率之间做选择 |
|
||||
| 品牌页、产品发布页、作品集、内容型页面需要明显字体人格 | 字体是风格来源，不应只用系统栈 |
|
||||
| 当前视觉方向会被字体选择明显改变 | 不允许从本文件的默认字体栈直接跳到展示字体 |
|
||||
|
||||
### 何时不读 `reference/fonts.md`
|
||||
|
||||
以下情况可以只用安全系统字体栈：
|
||||
|
||||
- 普通产品 UI、Dashboard、后台、表单、工具页正文；
|
||||
- 用户没有字体/风格诉求，且字体不会明显改变视觉方向；
|
||||
- 设计系统或模板已经提供了明确字体方案；
|
||||
- 当前任务只是局部间距、行高、断句、标点、版心调整。
|
||||
|
||||
### OSS / 测试字体加载
|
||||
|
||||
不要直接按字体名或 URL 挑字体。先在 `reference/fonts.md § 一` 完成场景筛选；选中的字体若需真实加载，用 `§ 二` 同文件内的 URL 表和 `@font-face` 模板完成，并按 `§ 2.5` 组装 font-family。
|
||||
|
||||
## 常见错误与诊断
|
||||
|
||||
| 症状 | 原因 | 修法 |
|
||||
|---|---|---|
|
||||
| "看着挤、累" | 行长 > 48 字 或 行距 < 1.3 | 缩窄版心 / 加大 `line-height` 到 1.5–1.7 |
|
||||
| "看着空、散" | 行距 > 2.0 或 字号过小 | 收紧行距，或字号 +1 步进 |
|
||||
| "页面里有白块/虫蛀感" | 全角标点连用未挤压 | 启用 InDesign 中文排版设置 / CSS `text-spacing-trim` |
|
||||
| "字号一堆，乱" | 字号不在同一模数 | 重建字号体系，全部 = 模数 × 整数 |
|
||||
| "层级不清" | 字号差 < 1.5×、或字重差不够 | 加大字号比 或 改字重，不要靠颜色撑层级 |
|
||||
| "页边距怪" | 上下左右一样宽 | 改成 内 < 外 < 上 < 下 的递增关系 |
|
||||
| "标题断得莫名其妙" | 按字数硬断，把词撕开 | 手动 `<wbr>` 在词间断；虚词"的"前不断、"和"后不断 |
|
||||
| "末行字距特别大或特别小" | 行长不是字号整数倍 + 两端对齐 | 重算 `width = 字号 × 字数` |
|
||||
| "破折号断成两截" | 用了两个 `—` 但没设禁止分开 | InDesign 加入"不可分割"集 / CSS 加 `⁠` |
|
||||
| "上一行就一个字带个句号" | 孤字成行 | 挤进前行 / 末行均排 / 改写删字 |
|
||||
| "页眉就一行（前段末行）" | 孤行成页 | 调整前页 / 删字 / 加字 |
|
||||
| "直排里数字躺倒了" | 没用 tate-chu-yoko | 2-3 位数字用纵中横排；4 位以上整体旋转 |
|
||||
|
||||
|
||||
## Reference 文件（按条件读，1–3 个最相关的）
|
||||
|
||||
| 触发条件 | 读这个文件 | 文件里讲什么 |
|
||||
|---|---|---|
|
||||
| 标题/封面/海报/PPT/小红书标题需要人工断行 | `reference/title-and-breaking.md` | 标题断句、占行、正文断行、不可分离禁则、孤行孤字 |
|
||||
| 长文/报告/公众号/公文/出版物、标点密集、破折号/省略号/引号/书名号问题 | `reference/punctuation.md` | 避头尾、标点风格、加法/减法模式、破折号、省略号、行内挤压/拉伸 |
|
||||
| 字号/行距/字距/段落/文本灰度/屏幕阅读舒适度诊断 | `reference/text-detail.md` | 字号、字重、字距、行距、段落缩进、Ruby 注音、文本灰度 |
|
||||
| 字体选择、展示字体、品牌字体、标题字体、正式报告字体、可加载字体测试 | `reference/fonts.md` | § 一 选字体(气质→表)→ § 二 加载执行；不要从本文件直接选字体 |
|
||||
| 复杂版面/长文报告/PDF/画册/分栏/版心/模数/栅格 | `reference/grid-system.md` | 模数、版心、网格、栏宽、CLReq 关键数值（Web/H5/deck 只借模数和阅读逻辑） |
|
||||
| 直排/混排/诗词/古籍/邀请函/传统中文/地区排版差异 | `reference/directions.md` | 横排/直排/混排、装订方向、CSS writing-mode、地区风格差异 |
|
||||
|
||||
Executable
+88
@@ -0,0 +1,88 @@
|
||||
# Color craft rules
|
||||
|
||||
Universal color rules applied on top of the active `DESIGN.md`. The
|
||||
design system supplies the palette tokens; this file enforces how to
|
||||
*use* them.
|
||||
|
||||
> Adapted from [refero_skill](https://github.com/referodesign/refero_skill)
|
||||
> (MIT). All examples reference Open Design's standard tokens
|
||||
> (`--bg`, `--surface`, `--fg`, `--muted`, `--border`, `--accent`).
|
||||
|
||||
## Palette structure
|
||||
|
||||
A coherent palette has four layers. Plan all four before writing any CSS.
|
||||
|
||||
| Layer | Share of pixels | Tokens |
|
||||
|---|---|---|
|
||||
| **Neutrals** | 70–90% | `--bg`, `--surface`, `--fg`, `--muted`, `--border` |
|
||||
| **Accent** (one) | 5–10% | `--accent` only — never invent a second accent |
|
||||
| **Semantic** | 0–5% | `--success`, `--warn`, `--danger` |
|
||||
| **Effect** | <1% | gradients, glows; rarely justified |
|
||||
|
||||
## Accent discipline
|
||||
|
||||
The single biggest readability failure in AI-generated UIs is accent
|
||||
overuse. Hard caps:
|
||||
|
||||
- **At most 2 visible uses of `--accent` per screen.** Typical pair:
|
||||
one eyebrow / chip + one primary CTA. Or one accent card + one tab
|
||||
pill. Pick a pair, not a flood.
|
||||
- Links count as accent; demote to `--fg` underline if you also have a
|
||||
CTA on the same screen.
|
||||
- Hover/focus rings count as accent. Ration accordingly.
|
||||
|
||||
## Contrast minimums
|
||||
|
||||
Run these as gates, not goals:
|
||||
|
||||
| Pair | Minimum |
|
||||
|---|---|
|
||||
| Body text (≤16 px) on background | **4.5:1** |
|
||||
| Large text (>18 px or 14 px bold) | **3:1** |
|
||||
| UI components against adjacent surfaces | **3:1** |
|
||||
|
||||
When the brand color clashes (low-contrast indigo on light background is
|
||||
common), darken the accent to a `600`-level shade for text use; reserve
|
||||
the brand-bright variant for fills only.
|
||||
|
||||
## Dark themes
|
||||
|
||||
Avoid pure black and pure white — both cause vibration and eye strain.
|
||||
|
||||
| Token | Dark theme | Light theme |
|
||||
|---|---|---|
|
||||
| Background | `#0f0f0f` (not `#000`) | `#fafafa` (not `#fff`) |
|
||||
| Foreground | `#f0f0f0` (not `#fff`) | `#111111` (not `#000`) |
|
||||
|
||||
On dark surfaces, prefer **semi-transparent white borders** over solid
|
||||
dark borders — a 1px `rgba(255,255,255,0.08)` reads as structure
|
||||
without adding visual noise.
|
||||
|
||||
## Semantic color naming
|
||||
|
||||
Always name tokens by **purpose**, never by hue:
|
||||
|
||||
```css
|
||||
/* good */
|
||||
--accent: #2f6feb;
|
||||
--success: #17a34a;
|
||||
|
||||
/* bad — locks you out of theming */
|
||||
--blue-500: #2f6feb;
|
||||
--green-500: #17a34a;
|
||||
```
|
||||
|
||||
## Anti-defaults
|
||||
|
||||
- **Indigo `#6366f1`** (Tailwind `indigo-500`) is the most reliable
|
||||
AI-slop tell. The active `DESIGN.md` provides `--accent`; use it. If
|
||||
the brief truly needs indigo, make the user say so explicitly. If
|
||||
your `DESIGN.md` encodes indigo as `--accent`, that is intentional —
|
||||
the linter only flags hardcoded hex, so `var(--accent)` uses are
|
||||
unaffected even when the resolved color happens to be `#6366f1`.
|
||||
- **Two-stop "trust" gradient** (purple → blue, blue → cyan, etc.) on a
|
||||
hero is the second most reliable tell. A flat surface + one
|
||||
type-driven hierarchy beats it every time.
|
||||
- **Decorative gradients with no functional purpose**. Gradients should
|
||||
separate hierarchies (header → body, primary CTA → secondary), not
|
||||
decorate empty space.
|
||||
+158
@@ -0,0 +1,158 @@
|
||||
---
|
||||
name: data-integrity
|
||||
description: Data marker, chart, table, metric, and demo-data integrity rules for editable design artifacts.
|
||||
mode: reference
|
||||
platform: web
|
||||
scenario: horizontal-craft
|
||||
preview:
|
||||
type: none
|
||||
default_for:
|
||||
- data markers
|
||||
- charts
|
||||
- metrics
|
||||
- tables
|
||||
- dashboard data
|
||||
- demo data
|
||||
- editable artifact
|
||||
fidelity: system
|
||||
---
|
||||
|
||||
# Data Integrity
|
||||
|
||||
Use this file when an artifact contains data, metrics, charts, tables, proof-like numbers, or needs future editing.
|
||||
|
||||
Core rule:
|
||||
|
||||
```text
|
||||
A design artifact may use demo data, but it must never disguise demo data as real evidence.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data markers
|
||||
|
||||
Data markers preserve editability and later comment targeting.
|
||||
|
||||
Use the artifact scaffold:
|
||||
|
||||
```text
|
||||
portfolio → data-portfolio / data-section / data-project / data-component
|
||||
deck → data-deck / data-slide / data-component
|
||||
prototype → data-prototype / data-screen / data-section / data-component / data-state
|
||||
content-page → data-content-page / data-mode / data-section / data-component
|
||||
landing-page → data-landing-page / data-section / data-component
|
||||
web-tool → data-web-tool / data-tool-type / data-screen / data-component / data-state
|
||||
```
|
||||
|
||||
If a marker would be excessive for a tiny edit, preserve existing markers and add the minimum missing markers around edited regions.
|
||||
|
||||
---
|
||||
|
||||
## Metrics and demo data
|
||||
|
||||
Specific numbers must be one of:
|
||||
|
||||
```text
|
||||
user-provided
|
||||
sourced
|
||||
demo-labeled
|
||||
placeholder
|
||||
```
|
||||
|
||||
Do not invent impressive proof to improve a design.
|
||||
|
||||
Never invent:
|
||||
|
||||
- revenue
|
||||
- market size
|
||||
- user counts
|
||||
- growth rates
|
||||
- conversion rates
|
||||
- retention / churn
|
||||
- satisfaction scores
|
||||
- rankings
|
||||
- uptime
|
||||
- benchmark wins
|
||||
- customer counts
|
||||
|
||||
If the number is illustrative, label it as demo.
|
||||
|
||||
Example:
|
||||
|
||||
```html
|
||||
<span data-proof="demo">92% demo</span>
|
||||
<p class="data-note">Demo data — replace with verified figures before publishing.</p>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Charts
|
||||
|
||||
Charts must communicate a claim, not decorate a card.
|
||||
|
||||
Required:
|
||||
|
||||
- title or conclusion
|
||||
- axes or labels when quantitative
|
||||
- units
|
||||
- source / demo label when data is not user-provided
|
||||
- readable values
|
||||
- contrast that survives small screens
|
||||
|
||||
Avoid:
|
||||
|
||||
- fake trend lines with no data meaning
|
||||
- unlabeled sparkline decoration
|
||||
- impossible precision
|
||||
- random upward growth lines
|
||||
- chart colors with no legend or state meaning
|
||||
|
||||
---
|
||||
|
||||
## Tables
|
||||
|
||||
Tables must optimize scanning.
|
||||
|
||||
Rules:
|
||||
|
||||
- numeric columns align consistently
|
||||
- status labels use consistent vocabulary
|
||||
- filters/search/sort appear when the table implies operations
|
||||
- long text has wrap or truncation strategy
|
||||
- empty and error states exist
|
||||
- row actions are close to rows
|
||||
- units appear in header or values, not randomly
|
||||
|
||||
---
|
||||
|
||||
## Data copy
|
||||
|
||||
Prefer honest labels:
|
||||
|
||||
- Demo data
|
||||
- 示例数据
|
||||
- 待填写
|
||||
- Replace with verified figures
|
||||
- Source pending
|
||||
|
||||
Avoid pretending:
|
||||
|
||||
- trusted by 10,000+ teams
|
||||
- 99.9% uptime
|
||||
- #1 platform
|
||||
- industry-leading
|
||||
- verified by experts
|
||||
|
||||
---
|
||||
|
||||
## Quality checks
|
||||
|
||||
```text
|
||||
[ ] Required data markers are present.
|
||||
[ ] Proof-like numbers have provenance.
|
||||
[ ] Demo data is visibly labeled.
|
||||
[ ] Charts have labels, units, and a conclusion.
|
||||
[ ] Tables are aligned, scannable, and have states.
|
||||
[ ] No invented impressive metric exists.
|
||||
[ ] Fake customer logos, quotes, awards, and press claims are absent.
|
||||
```
|
||||
+221
@@ -0,0 +1,221 @@
|
||||
# Form validation craft rules
|
||||
|
||||
Universal rules for form validation lifecycle, error wiring beyond the
|
||||
accessibility baseline, and the schema-as-contract layer that makes
|
||||
the same validation work on the server and the client. The active
|
||||
`DESIGN.md` decides how the field looks; this file decides *when* the
|
||||
field tells the user it's wrong, *how* the error reaches assistive
|
||||
tech, and *where* the rule lives.
|
||||
|
||||
> Grounded in primary sources: WHATWG HTML Living Standard
|
||||
> (Constraint Validation section under "Form control infrastructure"),
|
||||
> CSS Selectors L4 (`:user-invalid`), WCAG 2.2 SC 3.3.x
|
||||
> Understanding pages, ARIA APG forms patterns, Standard Schema spec
|
||||
> (`@standard-schema/spec`), Baymard 2024 inline-validation research
|
||||
> checkout-UX benchmark, WebAIM Million 2026 forms findings.
|
||||
|
||||
## Prior art and scope
|
||||
|
||||
Existing OSS forms guidance for AI agents pins to one layer at a time
|
||||
— `szilu/ux-designer-skill` is UX-opinion grade with no spec anchors,
|
||||
`Community-Access/accessibility-agents/forms-specialist` is
|
||||
WCAG-anchored but AT-only and doesn't reach the platform validity
|
||||
layer or the schema contract. This file connects the four layers a
|
||||
real form spans: **WHATWG Constraint Validation as the platform
|
||||
floor, validation timing as a state machine on the input, WCAG 3.3.x
|
||||
as the announcement and recovery contract, schema as the cross-stack
|
||||
truth.** A11y wiring lives next door in `accessibility.md`
|
||||
(label + describedby + invalid + `role="alert"` for inline errors);
|
||||
this file picks up where that ends.
|
||||
|
||||
## The input state machine
|
||||
|
||||
Every input passes through these states. The names trace back to RHF /
|
||||
Formik vocabulary on web; the *shape* applies regardless of stack.
|
||||
Drive error chrome off the state, not off raw `:invalid` or
|
||||
focus/blur booleans.
|
||||
|
||||
| State | Meaning | UI |
|
||||
|---|---|---|
|
||||
| `pristine` | User has not interacted | No error chrome, no green check |
|
||||
| `dirty` | User has typed but not committed (still focused) | No error chrome yet |
|
||||
| `touched` | User has blurred at least once after editing | Field-level constraint runs |
|
||||
| `invalid-after-touched` | Constraint failed after blur | Show error, link via `aria-describedby` |
|
||||
| `invalid-after-submit` | Submit attempted, field still invalid | Same plus focus management to summary or first invalid field |
|
||||
| `recovering` | User editing an already-invalid field | Re-validate on `input`, not on next blur |
|
||||
| `submitting` | Action in flight | Disable submit, announce status via a polite live region |
|
||||
| `server-error` | Server returned an error for this field | Use server's message text; treat as `invalid-after-submit` |
|
||||
|
||||
Decision rule that collapses validation-timing debates: errors appear
|
||||
on transition into `invalid-after-touched`, clear on transition out
|
||||
of any invalid state, and never appear from `pristine` or plain
|
||||
`dirty`. CSS `:user-invalid` matches the `invalid-after-touched` /
|
||||
`invalid-after-submit` states for free.
|
||||
|
||||
## Validation timing
|
||||
|
||||
Baymard's checkout-UX benchmark (2024-01-09 inline-validation article):
|
||||
**31% of sites have no inline validation, and most of the rest fire
|
||||
too early.** The participant quote that anchors the research: *"Why
|
||||
are you telling me my email address is wrong, I haven't had a chance
|
||||
to fill it all out yet?"* Premature firing is the loudest UX failure
|
||||
in this space.
|
||||
|
||||
The four rules:
|
||||
|
||||
1. **First blur after edit** runs the field-level constraint. Not on focus, not on first keystroke, not on every keystroke.
|
||||
2. **Once a field is invalid, switch to `input`-event re-validation** so the error clears the moment input becomes valid. Don't make the user blur again to dismiss it.
|
||||
3. **On submit**, run the schema parse. Move focus to the error summary at the top of the form (a heading-led container with `tabindex="-1"`, no `role="alert"` — see the wiring section), or to the first invalid field if no summary exists. Don't move focus on every keystroke.
|
||||
4. **Async checks** split into two paths. *Background preflight* (uniqueness while typing, address lookup) debounces 250-500 ms, announces via a polite live region, and never gates typing or keeps the submit button disabled indefinitely. *Authoritative server validation on submit* is different: the submit path must await the server's response and surface field errors from it, since the server is the truth. Don't conflate the two — the rule is "don't let a slow background check freeze the form," not "don't ever wait for the server."
|
||||
|
||||
CSS gets you most of timing rule 1 for free: style off `:user-invalid`
|
||||
not `:invalid`. The `:user-invalid` selector is Baseline Newly
|
||||
available 2023 (Chrome 119, Firefox 88, Safari 16.5; Firefox shipped
|
||||
the prefixed `:-moz-ui-invalid` years earlier and unprefixed in v88)
|
||||
and matches only after the user has either submitted the form or
|
||||
blurred the field with bad input.
|
||||
|
||||
## Constraint Validation API as the platform floor
|
||||
|
||||
Native HTML constraints are not an alternative to JS validation; they
|
||||
are the substrate the rest of the layers run on. They survive JS
|
||||
failure, they integrate with autofill, and they are what
|
||||
`reportValidity()` and screen-reader native announcements key off.
|
||||
|
||||
```html
|
||||
<input type="email" name="email" required>
|
||||
```
|
||||
|
||||
Use these declaratively for every field that has them: `required`,
|
||||
`type` (email, url, number, tel), `pattern`, `min`/`max`,
|
||||
`minlength`/`maxlength`, `step`. Cross-field rules and dynamic
|
||||
constraints go through `setCustomValidity()` on both `input` and
|
||||
`change` events — autofill flows historically fired one without the
|
||||
other on some browsers, so listening on both is the cheap defense.
|
||||
|
||||
Rules of the API:
|
||||
|
||||
- **Empty string clears `setCustomValidity`.** Not `null`, not no-arg.
|
||||
- **`form.requestSubmit()` honors validation; `form.submit()` skips it.** Never call the second.
|
||||
- `disabled` controls are barred from validation and not submitted. The HTML spec says `readonly` is also barred, but `readonly` only has defined behavior on `<input>` and `<textarea>` — implementations diverge for `<select readonly>` and `<button readonly>` ([whatwg/html#11841](https://github.com/whatwg/html/issues/11841)). For non-input controls where the value must still submit, the safe pattern is `disabled` plus a same-named hidden `<input>` carrying the value, or rendering the non-editable text alongside a hidden `<input>`. `aria-readonly` alone is not enough — a `<select>` or custom widget tagged `aria-readonly="true"` is still interactable, so the visible control can drift while the hidden input ships a stale or different value. If you do use `aria-readonly`, you must also block the interaction or keep both values in sync.
|
||||
- `inputmode` is a virtual-keyboard hint, **not** validation. `<input type="text" inputmode="numeric" pattern="[0-9]*">` is the Baymard-recommended shape for ZIPs / OTPs / card numbers; `pattern="[0-9]*"` is the historical iOS-Safari trigger for the numeric keypad on top of `inputmode`. `type="number"` adds spinners, strips leading zeros, applies locale-decimal handling, and varies field width across browsers — wrong for any of these.
|
||||
|
||||
## Error wiring beyond the baseline
|
||||
|
||||
The default error pattern in `accessibility.md` (`<label>` +
|
||||
`aria-describedby` + `aria-invalid` + `role="alert"`) covers WCAG
|
||||
3.3.1 / 3.3.2. Three additions matter for real forms:
|
||||
|
||||
**Adaptive error messages.** Baymard 2023: 98% of audited sites use
|
||||
generic catch-all errors ("Provide a valid phone number") rather than
|
||||
the specific subrule that fired ("Phone number is too short"). The
|
||||
back end already knows the subrule; surfacing it cuts re-submit
|
||||
attempts. Ship 4-7 distinct messages per high-traffic complex field
|
||||
(email, phone, card, postal code). The scale of the problem matches
|
||||
WebAIM Million 2026: missing form-input labels appear on **51% of
|
||||
the top 1M home pages** (input-level rate **33.1%** of all 6.9M
|
||||
inputs sampled) — labels and error messages are the categories
|
||||
trending sideways or worse year-over-year while overall a11y errors
|
||||
drop.
|
||||
|
||||
**Error summary at the top, on submit only.** Long forms benefit from
|
||||
a summary list of in-page anchor links to invalid fields, focused on
|
||||
submit:
|
||||
|
||||
```html
|
||||
<div id="form-errors" tabindex="-1">
|
||||
<h2>2 problems</h2>
|
||||
<ul>
|
||||
<li><a href="#email">Email is required</a></li>
|
||||
<li><a href="#dob">Date of birth must be in the past</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
```
|
||||
|
||||
The container is heading-led with `tabindex="-1"` so JS can move
|
||||
focus to it on submit (render the summary into the DOM, *then*
|
||||
`.focus()` it; a `hidden` element can't take focus). It does **not**
|
||||
carry `role="alert"` because combining a moved-focus target with an
|
||||
alert role causes double-announcement: alert fires on insertion,
|
||||
focus fires the accessible name + role. Reserve `role="alert"` for
|
||||
inline per-field errors that appear without focus moving — that's
|
||||
the canonical baseline pattern in `accessibility.md`. WCAG
|
||||
technique G139 covers the summary; not required, high-value for long
|
||||
forms.
|
||||
|
||||
**Preserve user input on error.** Baymard 2024: 34% of audited
|
||||
checkouts wipe the credit-card field when an unrelated error reloads
|
||||
the page. Direct cause of abandonment. Either field-level-validate
|
||||
non-sensitive fields first, or split the payment step. PCI-wise,
|
||||
persisting card values across an error reload is fine via tokenized
|
||||
hosted iframes; never store raw PAN in your own session.
|
||||
|
||||
## Schema as the cross-stack contract
|
||||
|
||||
Validation expressed once, consumed everywhere. The 2026 React shape
|
||||
— `useActionState` + Server Actions + Conform (which added Standard
|
||||
Schema support during the v1.x line) + a Zod 4 / Valibot / ArkType
|
||||
schema — is the most-cited concrete instance: one schema,
|
||||
server-authoritative, validator hot-swappable via the `~standard`
|
||||
interface. The same architecture works in TanStack Form, oRPC, Hono
|
||||
validator middleware, Nuxt UForm, and any other consumer that reads
|
||||
`~standard`.
|
||||
|
||||
```ts
|
||||
const Signup = z.object({
|
||||
email: z.email(), // Zod 4 top-level form
|
||||
password: z.string().min(12),
|
||||
});
|
||||
// Same schema parses on the Server Action and on the Conform client.
|
||||
```
|
||||
|
||||
Three rules that survive across stacks:
|
||||
|
||||
- **Server is the truth, client is the optimization.** Same schema runs in both. Returning `{ errors }` from the action (not throwing) is what feeds back into `useActionState`'s state slot — throwing routes to the Error Boundary and loses the form data.
|
||||
- **Standard Schema is the contract, not Zod.** A form library that ships per-validator resolver shims (`zodResolver`, `valibotResolver`, etc.) is yesterday's stack. Accept any `~standard`-compliant validator.
|
||||
- **`novalidate` on `<form>` does not mean "skip validation".** It means "let the form library repaint errors instead of the browser's bubble." But the trade-off is real: a literal server-rendered `<form novalidate>` disables the browser's submit-blocking and native validation UI **even when JS is unavailable**, which loses the no-JS constraint-validation floor. Pick one of two patterns. **A:** render `<form>` without `novalidate` server-side and have the form library set `form.noValidate = true` after hydration — the no-JS user keeps the browser's native validation, the JS user gets the library's chrome. **B:** ship `novalidate` from the start only when the submit path reaches server validation without JS (Server Action, classic POST handler) so the no-JS user is still protected by the server. Either way, keep `required` / `pattern` / `type` attributes — they survive JS failure and integrate with autofill. (HTML attribute is lowercase `novalidate`; the IDL property on the form element is `noValidate`.)
|
||||
|
||||
## WCAG 3.3.x beyond Error Identification
|
||||
|
||||
`accessibility.md` covers 3.3.1 (Error ID), 3.3.2 (Labels),
|
||||
and 3.3.7 (Redundant Entry). The rest of 3.3 binds harder on
|
||||
transactional forms:
|
||||
|
||||
- **3.3.3 Error Suggestion (AA):** when the fix is determinable, suggest it in text. Adaptive errors satisfy this. "Date must be MM/DD/YYYY. You entered 5-3-26. Did you mean 05/03/2026?"
|
||||
- **3.3.4 Error Prevention — Legal, Financial, Data (AA):** for any submission with legal / financial / data-modifying consequence, provide one of: reversibility, server-side check + correction step, or a confirm-summary screen before commit.
|
||||
- **3.3.8 Accessible Authentication (AA, WCAG 2.2):** auth steps must not require a cognitive function test (remember a password, transcribe a code, recognize images) without an alternative. CAPTCHAs are the canonical thing this SC restricts; only object-recognition or personal-content variants escape via the narrow exceptions, and not all CAPTCHAs do. Practical floor: never block paste on password / verification-code fields, support password managers, accept verification-code paste from a clipboard.
|
||||
- **3.3.9 Accessible Authentication, No Exception (AAA):** removes even the object-recognition / personal-content exceptions. Aspirational; flag if a project commits to it.
|
||||
|
||||
## Native mobile parity
|
||||
|
||||
Web validation primitives don't auto-translate. Each platform has its
|
||||
own validity machinery and its own AT path. Skills that emit web-only
|
||||
artifacts can skim this section; it's the entry point for skills
|
||||
that ship to mobile (mobile-onboarding, mobile-app, etc.).
|
||||
|
||||
| Platform | Validity primitive | Error announcement |
|
||||
|---|---|---|
|
||||
| iOS UIKit | Hand-rolled state on the view controller; `UITextField` doesn't carry a built-in invalid flag | `UIAccessibility.post(notification: .announcement, argument: "Email is required")` |
|
||||
| iOS SwiftUI | `TextField` + `@State`-driven validation; no built-in `Form`-level validity API as of iOS 18 | `AccessibilityNotification.Announcement("…").post()` (iOS 17+) |
|
||||
| Android Compose | `OutlinedTextField(isError = true, supportingText = { Text("…") })` — `isError` wires the AT error semantic for you | `Modifier.semantics { liveRegion = LiveRegionMode.Polite }` on the supporting-text node, or `LocalView.current.announceForAccessibility(message)` |
|
||||
| Flutter | `TextFormField(validator: (v) => …)` inside a `Form`, `formKey.currentState!.validate()` | `SemanticsService.announce(message, Directionality.of(context))` — never hardcode `TextDirection.ltr`; pull ambient direction so Arabic / Hebrew / Persian flows announce correctly |
|
||||
| React Native | Hand-rolled per field; no platform validity flag | `accessibilityLiveRegion="polite"` on the error node (Android) + `AccessibilityInfo.announceForAccessibility(...)` (iOS) |
|
||||
|
||||
Two parity rules that catch most AI-generated mobile forms:
|
||||
|
||||
- **Use the platform's native validation flag — and pair it with the platform's error-message semantic where one exists.** On Compose, `isError = true` is the right boolean state for the field visuals and AT error-state cue, but it does *not* carry the localized error message. Pair it with `Modifier.semantics { error(message) }` so accessibility services get the actual text — the same string you render in `supportingText`. The trap is duplication: a hand-rolled `Modifier.semantics { error("Email is required") }` next to a different supporting-text string desyncs. Source `error()` from the same state field as `supportingText` so they stay in sync.
|
||||
- **Don't mirror web ARIA into mobile semantics.** `aria-describedby` on a SwiftUI `TextField` is a no-op. Use the platform announcement primitive (`AccessibilityNotification.Announcement` on SwiftUI, `UIAccessibility.post` on UIKit, `announceForAccessibility` on Android, `SemanticsService.announce` on Flutter) for state-change events that need to reach the screen reader.
|
||||
|
||||
## Common mistakes (lint these)
|
||||
|
||||
- Styling off `input:invalid` instead of `input:user-invalid`. Red borders on page load is the loudest "this validation was added without testing" signal.
|
||||
- Validating on every keystroke. Hostile; fires before the user has finished typing.
|
||||
- Generic catch-all error messages ("Invalid input") when the back end already knows which subrule fired. Baymard 2023 found 98% of audited sites do this — the most-cited preventable validation failure in their corpus.
|
||||
- Throwing from a Server Action on validation failure. Routes to the Error Boundary and loses the form data. Return `{ errors }` instead.
|
||||
- `role="alert"` on the error-summary container that focus moves to. Double-announces. Reserve `role="alert"` for inline per-field errors that appear without focus moving.
|
||||
- `aria-busy="true"` on the submit button while submitting. `aria-busy` is for stale containers; for buttons use `disabled` plus a polite live-region status message.
|
||||
- Email-confirm fields ("retype your email"). 3.3.7 redundant entry — exceptions are essential / security / no-longer-valid, not "we want to catch typos." Allow paste and validate the single field instead.
|
||||
- Per-validator resolver shims (`zodResolver`, `valibotResolver`) on a 2026 stack. Accept Standard Schema's `~standard` interface and the validator becomes swappable.
|
||||
- Wiping the credit-card field when an unrelated field errors. Baymard 2024: 34% of audited e-commerce sites; direct abandonment cause.
|
||||
- `setCustomValidity(null)` to clear an error. Pass empty string; `null` does not clear.
|
||||
- Mirroring web ARIA onto SwiftUI / Compose / Flutter. Each platform has its own validity API; `aria-*` attributes don't reach the mobile AT path.
|
||||
+343
@@ -0,0 +1,343 @@
|
||||
---
|
||||
name: Icon System
|
||||
description: Shared icon sourcing, consistency, accessibility, and quality rules for design artifacts.
|
||||
mode: reference
|
||||
platform: any
|
||||
type: horizontal-craft
|
||||
preview:
|
||||
type: none
|
||||
default_for:
|
||||
- icons
|
||||
- icon system
|
||||
- icon family
|
||||
- icon set
|
||||
- SVG icons
|
||||
- UI icons
|
||||
- 图标
|
||||
- 图标库
|
||||
- 成套图标
|
||||
fidelity: system
|
||||
---
|
||||
|
||||
# Icon System
|
||||
|
||||
Use this shared reference whenever a design artifact uses UI icons, feature icons, navigation icons, status icons, pictograms, or icon-like visual marks.
|
||||
|
||||
The goal is not to add more icons. The goal is to use icons as a coherent functional language.
|
||||
|
||||
Bad icons make the artifact look more AI-generated than no icons.
|
||||
|
||||
---
|
||||
|
||||
## Core Rule
|
||||
|
||||
```text
|
||||
One artifact → one icon family → one visual logic.
|
||||
```
|
||||
|
||||
Do not mix line icons, solid icons, emoji, 3D stickers, random SVGs, and different stroke widths in one artifact.
|
||||
|
||||
If a coherent icon family is not available, draw a small set of custom inline SVG icons in one consistent style.
|
||||
|
||||
---
|
||||
|
||||
## Icon Source Priority
|
||||
|
||||
Choose icons from one coherent source.
|
||||
|
||||
Priority:
|
||||
|
||||
1. User-provided icon set
|
||||
2. Icons included in the selected design system
|
||||
3. Product-bundled icon library
|
||||
4. Approved icon libraries only
|
||||
5. Licensed / free Streamline assets, only when license and attribution requirements are satisfied
|
||||
6. Custom inline SVG fallback
|
||||
|
||||
Do not use unknown icon libraries just because they are open-source.
|
||||
|
||||
Do not claim an icon came from a third-party library unless the asset is actually available and permitted.
|
||||
|
||||
---
|
||||
|
||||
## Approved Icon Libraries
|
||||
|
||||
Use only these approved external libraries unless the user provides another set or the selected design system requires another set.
|
||||
|
||||
Approved by default:
|
||||
|
||||
- Lucide
|
||||
- Heroicons
|
||||
- Material Symbols
|
||||
- Phosphor Icons
|
||||
- Radix Icons
|
||||
- Tabler Icons
|
||||
- Streamline, only when user-provided, free, licensed, or otherwise permitted
|
||||
|
||||
Do not mix multiple approved libraries in one artifact unless there is a specific reason and the visual style is manually normalized.
|
||||
|
||||
---
|
||||
|
||||
## Streamline Rules
|
||||
|
||||
Streamline is a high-quality source because it provides large coherent icon families and sets.
|
||||
|
||||
Use Streamline only when:
|
||||
|
||||
- the user provides Streamline assets
|
||||
- the environment includes licensed Streamline assets
|
||||
- the selected Streamline set is free or open-source for the intended use
|
||||
- attribution requirements can be satisfied
|
||||
|
||||
Do not assume all Streamline assets are free to use.
|
||||
|
||||
Do not scrape, hotlink, or invent Streamline assets.
|
||||
|
||||
If Streamline assets are unavailable, create custom inline SVG icons in a consistent style inspired by the selected icon direction, but do not label them as Streamline icons.
|
||||
|
||||
---
|
||||
|
||||
## Scenario Defaults
|
||||
|
||||
### Prototype / Dashboard
|
||||
|
||||
Recommended default:
|
||||
|
||||
- Lucide or Heroicons
|
||||
- 20–24px grid
|
||||
- 1.5–2px stroke
|
||||
- rounded caps / joins
|
||||
- `currentColor`
|
||||
- restrained usage
|
||||
|
||||
Use icons for:
|
||||
|
||||
- navigation
|
||||
- actions
|
||||
- status
|
||||
- empty states
|
||||
- affordance clarification
|
||||
|
||||
Avoid:
|
||||
|
||||
- icon-heavy cards
|
||||
- random feature icons
|
||||
- decorative icon wallpaper
|
||||
|
||||
---
|
||||
|
||||
### Tool H5
|
||||
|
||||
Recommended default:
|
||||
|
||||
- Phosphor, Tabler, or custom inline SVG
|
||||
- larger optical size
|
||||
- playful but consistent
|
||||
- fewer icons
|
||||
- stronger result-area pictogram when useful
|
||||
|
||||
Use icons for:
|
||||
|
||||
- input affordance
|
||||
- result card
|
||||
- retry/share actions
|
||||
- physical metaphor when the tool needs one
|
||||
|
||||
Avoid:
|
||||
|
||||
- sticker-like 3D icons
|
||||
- emoji substitutes
|
||||
- mixed cute + serious icon styles
|
||||
|
||||
---
|
||||
|
||||
### Landing Page
|
||||
|
||||
Recommended default:
|
||||
|
||||
- minimal functional icons only
|
||||
- avoid icon feature grids by default
|
||||
- prefer product screenshots, diagrams, numerals, or type-led plates over icon rows
|
||||
|
||||
Use icons only when they clarify:
|
||||
|
||||
- feature categories
|
||||
- integrations
|
||||
- navigation
|
||||
- product mechanism
|
||||
|
||||
Avoid:
|
||||
|
||||
- three equal cards each with an icon, title, and description
|
||||
- icon rows used as filler
|
||||
- fake integration logos
|
||||
|
||||
---
|
||||
|
||||
### Deck
|
||||
|
||||
Recommended default:
|
||||
|
||||
- use icons sparingly
|
||||
- prefer diagrams, pictograms, numerals, arrows, and simple SVG marks
|
||||
- keep icon style consistent across slides
|
||||
|
||||
Use icons for:
|
||||
|
||||
- navigation keys
|
||||
- simple concept markers
|
||||
- diagrams
|
||||
- status legends
|
||||
|
||||
Avoid:
|
||||
|
||||
- decorative emoji
|
||||
- slide titles with emoji
|
||||
- random icon bullets
|
||||
- icon-heavy feature slides
|
||||
|
||||
---
|
||||
|
||||
### Content Page
|
||||
|
||||
Recommended default:
|
||||
|
||||
- usually no icons
|
||||
- use typography, pull quotes, dividers, and illustrations instead
|
||||
- icons only for callout type, step labels, or compact metadata
|
||||
|
||||
Avoid random icons in long-form reading content.
|
||||
|
||||
---
|
||||
|
||||
## Visual Consistency Rules
|
||||
|
||||
If icons are used, define the icon style before generating the artifact.
|
||||
|
||||
Specify:
|
||||
|
||||
```text
|
||||
icon family
|
||||
style: line / solid / duo / filled / custom SVG
|
||||
grid size
|
||||
stroke width
|
||||
corner style
|
||||
cap / join style
|
||||
optical size
|
||||
color behavior
|
||||
```
|
||||
|
||||
Default custom line icon style:
|
||||
|
||||
```text
|
||||
viewBox: 0 0 24 24
|
||||
stroke: currentColor
|
||||
stroke-width: 1.75 or 2
|
||||
stroke-linecap: round
|
||||
stroke-linejoin: round
|
||||
fill: none
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- Keep all icons on the same optical grid.
|
||||
- Keep stroke widths consistent.
|
||||
- Do not mix outline and filled icons unless the difference encodes state.
|
||||
- Do not mix flat icons with 3D icons.
|
||||
- Do not mix icon libraries.
|
||||
- Do not use emoji as UI icons.
|
||||
- Do not use logos as icons unless the user provides them or usage is clearly permitted.
|
||||
- Do not use icons where a short text label is clearer.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Rules
|
||||
|
||||
Prefer inline SVG for HTML artifacts.
|
||||
|
||||
Inline SVG requirements:
|
||||
|
||||
```html
|
||||
<svg aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round">
|
||||
<path d="..." />
|
||||
</svg>
|
||||
```
|
||||
|
||||
Decorative icons:
|
||||
|
||||
```html
|
||||
<svg aria-hidden="true" focusable="false">...</svg>
|
||||
```
|
||||
|
||||
Meaningful icons:
|
||||
|
||||
```html
|
||||
<button aria-label="Open settings">
|
||||
<svg aria-hidden="true" focusable="false">...</svg>
|
||||
</button>
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- Use `currentColor` so icons inherit text color.
|
||||
- Do not hardcode random icon colors.
|
||||
- Ensure icon-only buttons have accessible labels.
|
||||
- Do not leave inline SVG paths unlabeled if the icon carries unique meaning outside a labeled control.
|
||||
- Keep icon markup small; do not paste huge unoptimized SVG blobs.
|
||||
|
||||
---
|
||||
|
||||
## Quality Gate Checks
|
||||
|
||||
Before delivery, verify:
|
||||
|
||||
- Are icons necessary?
|
||||
- Is there exactly one coherent icon family or custom SVG style?
|
||||
- Are emoji absent as UI icons?
|
||||
- Are stroke widths / fill styles consistent?
|
||||
- Are icon-only controls labeled?
|
||||
- Are decorative icons `aria-hidden="true"`?
|
||||
- Are third-party license / attribution requirements satisfied?
|
||||
- Are there no unknown low-quality open-source icon packs?
|
||||
- Are icons not being used as filler?
|
||||
|
||||
If the answer is no, remove the icons or replace them with custom inline SVG in one consistent style.
|
||||
|
||||
---
|
||||
|
||||
## Fallback: Custom Inline SVG
|
||||
|
||||
Use this when no approved icon set is available.
|
||||
|
||||
Rules:
|
||||
|
||||
- Draw only the icons needed.
|
||||
- Use simple geometry.
|
||||
- Use a shared 24×24 viewBox.
|
||||
- Use one stroke width.
|
||||
- Use `currentColor`.
|
||||
- Keep forms minimal and readable.
|
||||
- Avoid clever decorative shapes.
|
||||
|
||||
Recommended fallback style:
|
||||
|
||||
```html
|
||||
<svg class="icon" aria-hidden="true" focusable="false" viewBox="0 0 24 24">
|
||||
<path d="M5 12h14" />
|
||||
<path d="M13 6l6 6-6 6" />
|
||||
</svg>
|
||||
```
|
||||
|
||||
```css
|
||||
.icon {
|
||||
width: 1.25em;
|
||||
height: 1.25em;
|
||||
stroke: currentColor;
|
||||
stroke-width: 1.75;
|
||||
stroke-linecap: round;
|
||||
stroke-linejoin: round;
|
||||
fill: none;
|
||||
}
|
||||
```
|
||||
|
||||
Do not call fallback icons Streamline, Lucide, Heroicons, or any other named library.
|
||||
Executable
+296
@@ -0,0 +1,296 @@
|
||||
# Laws of UX craft rules
|
||||
|
||||
Universal cognitive, perceptual, and behavioral heuristics that decide
|
||||
what a UI composes — how many pricing tiers fit on a screen, where a
|
||||
primary action anchors in scanning order, when a progress indicator
|
||||
earns its place, why a settings list needs grouping. The active
|
||||
`DESIGN.md` decides brand visual language; the existing craft files
|
||||
decide rendering rules (color, typography, motion, states, ARIA, RTL,
|
||||
forms); this file decides composition rules grounded in named research.
|
||||
|
||||
> Distilled from primary sources: Hick (1952) + Hyman (1953), Miller
|
||||
> (1956) for chunking / `7±2` channel capacity, Cowan (2001) for the
|
||||
> modern ~4 working-memory bound, Fitts (1954), Wertheimer (1923) for
|
||||
> proximity / similarity / Prägnanz, Palmer (1992) for Common Region,
|
||||
> Palmer & Rock (1994) for Uniform Connectedness, Kahneman /
|
||||
> Fredrickson / Schreiber / Redelmeier (1993) for Peak-End, Zeigarnik
|
||||
> (1927), Csíkszentmihályi (1975), Hull (1932), von Restorff (1933),
|
||||
> Broadbent (1958), Sweller (1988), Postel (RFC 760, 1980), Carroll &
|
||||
> Rosson (1987), Tversky & Kahneman (1974) for Anchoring, Kurosu &
|
||||
> Kashimura (1995), Iyengar & Lepper (2000), Toffler (1970), Pareto
|
||||
> (c.1906) / Juran (*Quality Control Handbook*, 1951), Ebbinghaus
|
||||
> (1885), Ockham (14th c.), Tesler at Apple (1980s), Nielsen (2000),
|
||||
> Norman *POET* (1988), Parkinson (1955).
|
||||
|
||||
## Prior art and scope
|
||||
|
||||
Existing public catalogs of UX heuristics (Yablonski's lawsofux.com,
|
||||
NN/g's 10 usability heuristics, Material 3 motion + interaction
|
||||
guidance, Apple HIG, Baymard Institute checkout research) inventory the
|
||||
laws but rarely tie each one to a concrete code-gen directive. This
|
||||
file does the translation: every entry ends with one actionable move
|
||||
for an HTML / Tailwind / React-emitting agent. Sibling craft files
|
||||
(`accessibility.md`, `state-coverage.md`, `chinese-typography.md`,
|
||||
`anti-ai-slop.md`, `color.md`, `animation-discipline.md`,
|
||||
`form-validation.md`) own the auto-checked rules; this file names the
|
||||
underlying law and surfaces the folklore. Out of scope: Weber-Fechner
|
||||
psychophysics and Signal Detection Theory — both apply to UI but the
|
||||
prompt-emission directives are too narrow to earn a slot here. Add
|
||||
later if a skill needs them.
|
||||
|
||||
The rules below are guidance, not auto-checked. Reviewers and the agent
|
||||
apply them; the linter does not. Where a law has a sibling rule already
|
||||
auto-checked elsewhere — touch-target floor in
|
||||
`accessibility.md`, the 300 ms / 2 s / 10 s / 30 s / 60 s
|
||||
loading thresholds in `state-coverage.md`, ALL CAPS letter-spacing in
|
||||
`chinese-typography.md`, the indigo / gradient / emoji-icon list in
|
||||
`anti-ai-slop.md` — the entry below cross-references rather than
|
||||
duplicates.
|
||||
|
||||
## Perception and visual grouping
|
||||
|
||||
Five Gestalt laws plus three attention-and-recognition laws govern how
|
||||
the eye groups elements before the brain reads them.
|
||||
|
||||
- **Law of Proximity** (Wertheimer, 1923). Objects near each other read
|
||||
as a group. Cheapest grouping signal — cheaper than borders or shared
|
||||
color. Apply variable vertical rhythm: 8–12 px within a group,
|
||||
32–48 px between groups. Uniform spacing reads as nothing being
|
||||
grouped.
|
||||
- **Law of Similarity** (Wertheimer, 1923). Visually similar elements
|
||||
read as a group. Equivalent affordances must share treatment — every
|
||||
list row identical class set, every secondary button identical, every
|
||||
destructive action identical. Visible deviation is reserved for the
|
||||
one item meant to draw attention (the recommended pricing tier, the
|
||||
selected nav item).
|
||||
- **Law of Common Region** (Palmer, 1992). A shared bounded area binds
|
||||
enclosed elements. Use enclosure when proximity is not enough — and
|
||||
reserve it. Concrete numbers: padding ≥16 px inside the region,
|
||||
distinct surface (border + tinted background, or card chrome at
|
||||
≥1 px hairline). A page where every section is bordered destroys the
|
||||
signal.
|
||||
- **Law of Prägnanz / Good Figure** (Wertheimer, 1923). The eye
|
||||
resolves complex layouts into the simplest underlying form. Designs
|
||||
that align with a clear underlying grid (12-column, F-pattern,
|
||||
4-quadrant) feel inevitable; ornate breaks that add nothing semantic
|
||||
feel arbitrary.
|
||||
- **Law of Uniform Connectedness** (Palmer & Rock, 1994). The
|
||||
strongest grouping signal in the Gestalt hierarchy: connected lines,
|
||||
shared toolbars, or bracketing containers tie items together more
|
||||
strongly than proximity or similarity. Use for wizard steps,
|
||||
comparison sets, and explicit navigation flows.
|
||||
- **Selective Attention** (Broadbent, *Perception and Communication*,
|
||||
1958). Cognitive bandwidth is finite. Users filter aggressively and
|
||||
ignore anything that looks irrelevant to their goal — banner blindness
|
||||
comes from this. Reserve the strongest visual contrast for the single
|
||||
goal-relevant action; let supporting content recede in weight.
|
||||
- **Von Restorff Effect** (von Restorff, 1933). The item that differs
|
||||
from a uniform field is the one most likely to be remembered. Make
|
||||
the recommended pricing tier, the active nav item, the warning state
|
||||
visually distinct. Pair contrast with a non-color signal (icon, text
|
||||
label, position) — `accessibility.md` rules out color-alone
|
||||
signaling.
|
||||
- **Aesthetic-Usability Effect** (Kurosu & Kashimura, Hitachi Design
|
||||
Center, 1995). Visual polish biases perceived usability. Refined
|
||||
typography, generous whitespace, and a calm palette earn the benefit
|
||||
of the doubt for minor friction. Never substitutes for measurable
|
||||
usability or for `state-coverage.md`'s required-states rule.
|
||||
|
||||
## Decision-making
|
||||
|
||||
Six laws govern how fast and how well users decide when an interface
|
||||
offers a choice.
|
||||
|
||||
- **Hick's Law** (Hick, 1952; Hyman, 1953 replication). Decision time
|
||||
grows roughly log(n+1) with the number of equivalent options. Cap any
|
||||
single decision-screen to 3–5 visible primary options; collapse the
|
||||
rest behind a "More" / progressive disclosure pattern; visually
|
||||
distinguish the recommended choice. Aggressive truncation that hides
|
||||
the path forward is the opposite failure mode — surface the full
|
||||
option set, just don't render every option at the same visual weight.
|
||||
- **Choice Overload** (Iyengar & Lepper, *Journal of Personality and
|
||||
Social Psychology*, 2000; framing dates to Toffler, *Future Shock*,
|
||||
1970). Too many roughly-equivalent options stall or abandon the
|
||||
decision. Pricing pages: 3–4 tiers, exactly one marked recommended.
|
||||
Product grids: 6–9 hero cards above the fold. Settings panels: ≤5
|
||||
named groups. Never emit a flat wall of equivalents.
|
||||
- **Anchoring** (Tversky & Kahneman, *Science* 185:1124–1131, 1974).
|
||||
The first number a user sees re-weights every subsequent number.
|
||||
Place the recommended pricing tier where it anchors the comparison;
|
||||
render yearly-billing savings as concrete dollar deltas, not just
|
||||
percentage badges; pre-select the safer default in radio groups.
|
||||
Visual weight matches intended decision weight.
|
||||
- **Pareto Principle / 80-20** (Pareto, c.1906; Juran, *Quality Control
|
||||
Handbook*, 1951 — popularized the management-application framing). A
|
||||
small share of features drives most of the value. Identify the 2–3 actions
|
||||
that drive the dominant journey for the target persona; emphasize
|
||||
those visually; demote the long tail to overflow menus, footer
|
||||
surfaces, or settings.
|
||||
- **Tesler's Law / Conservation of Complexity** (Tesler, Apple, 1980s).
|
||||
Every product has an irreducible amount of complexity. The design
|
||||
choice is *where* it lives — engineering team, interface, user — not
|
||||
whether to eliminate it. When complexity reaches the user, surface
|
||||
contextual guidance (tooltips, smart defaults, inline empty-state
|
||||
coaching, progressive disclosure) at the exact step where it
|
||||
surfaces. Hiding it is not the same as removing it.
|
||||
- **Occam's Razor** (Ockham, 14th c.). Among options that explain the
|
||||
data equally well, prefer the one with the fewest assumptions. Specify
|
||||
a minimal element inventory; forbid decorative chrome that doesn't
|
||||
serve a stated user task. The law constrains assumptions, not feature
|
||||
count — a "minimum viable" framing misreads it.
|
||||
|
||||
## Memory and learning
|
||||
|
||||
Five laws cover how working memory handles information density and
|
||||
what the user retains afterward.
|
||||
|
||||
- **Miller's Law and Chunking** (Miller, *The Magical Number Seven,
|
||||
Plus or Minus Two*, *Psychological Review*, 1956 — channel capacity /
|
||||
`7±2` and chunking; Cowan, *Behavioral and Brain Sciences* 24:1, 2001
|
||||
for the modern ~4-item working-memory bound). Working memory holds
|
||||
about four items reliably and up to seven for short-term recall. Each
|
||||
slot can hold a *larger familiar unit*, constrained by the user's
|
||||
domain knowledge — chunking does not let you pack arbitrary content
|
||||
into a single slot. Often misread as a rule about menu length;
|
||||
Miller's paper is about chunks. Group related fields with clear
|
||||
section headings, dividers, or card containers. A settings page with
|
||||
sections "Account / Notifications / Privacy / Billing / Danger zone"
|
||||
beats one flat list of 30 toggles.
|
||||
- **Working Memory** (Baddeley & Hitch, 1974; lineage to Atkinson &
|
||||
Shiffrin, 1968). Items decay in seconds without rehearsal. Recognition
|
||||
beats recall: persisting prior context across screens, marking visited
|
||||
elements, and surfacing comparison views beats forcing the user to
|
||||
memorize. On dashboards specifically: sticky filter chips, last-N
|
||||
selections persisted, breadcrumbs that include applied filters.
|
||||
- **Serial Position Effect** (Ebbinghaus, *Über das Gedächtnis*, 1885).
|
||||
Recall favors the extremes — primacy at the start, recency at the
|
||||
end — while middle items fade. Anchor the most important nav items at
|
||||
the leftmost and rightmost positions of a horizontal menu; cluster
|
||||
utilities in the middle.
|
||||
- **Peak-End Rule** (Kahneman, Fredrickson, Schreiber, Redelmeier,
|
||||
*Psychological Science*, 1993). Memory of an experience is dominated
|
||||
by the emotional peak and the ending, not the average. Stage a
|
||||
high-effort celebratory success state; let intermediate steps stay
|
||||
calm. Mediocre middles matter less than a strong close. The peak
|
||||
belongs at the *end* of a flow, not as arbitrary mid-flow motion —
|
||||
`animation-discipline.md` rejects motion that performs (rather than
|
||||
confirms) a state change.
|
||||
- **Zeigarnik Effect** (Zeigarnik, *Über das Behalten erledigter und
|
||||
unerledigter Handlungen*, 1927). Uncompleted tasks create cognitive
|
||||
tension that pulls the user back. Visible progress ("3 of 5 steps",
|
||||
greyed-out next sections) converts that tension into completion
|
||||
pressure. Reserve for genuinely beneficial flows like onboarding;
|
||||
applying the same lever to streaks, daily-quest counters, or notification-
|
||||
reduction nags is a dark pattern.
|
||||
|
||||
## Interaction and motor
|
||||
|
||||
Five laws cover how fast and how accurately users can act on the UI.
|
||||
|
||||
- **Fitts's Law** (Fitts, *Journal of Experimental Psychology*, 1954).
|
||||
Time to acquire a target depends on its distance and size — bigger
|
||||
and closer is faster. Spacing between adjacent hit zones matters as
|
||||
much as size. Pair with `accessibility.md`'s 24 × 24 CSS px
|
||||
AA touch-target floor; on mobile, place high-frequency controls in
|
||||
the natural thumb arc.
|
||||
- **Doherty Threshold** (Doherty & Thadani, *IBM Systems Journal*,
|
||||
1982). Sub-second feedback keeps users in flow; latency above ~1 s
|
||||
breaks attention. The implementable directive lives in
|
||||
`state-coverage.md`'s loading-threshold table (no indicator under
|
||||
300 ms; skeleton 300 ms – 2 s; labelled spinner 2 – 10 s; determinate
|
||||
bar with cancel 10 – 60 s; stop and offer error/retry past 60 s).
|
||||
This entry exists to name the underlying law and flag its folklore
|
||||
(the 400 ms number doesn't appear in the 1982 paper — see
|
||||
`animation-discipline.md` for the 400 ms folklore trace).
|
||||
- **Flow** (Csíkszentmihályi, *Beyond Boredom and Anxiety*, 1975). Flow
|
||||
sits in the balance between challenge and skill — too hard breeds
|
||||
frustration, too easy breeds boredom. Continuous feedback and a clear
|
||||
sense of control keep the user inside the state. System friction and
|
||||
latency are the fastest ways to break it.
|
||||
- **Goal-Gradient Effect** (Hull, *Psychological Review*, 1932; Kivetz,
|
||||
Urminsky, Zheng, 2006 for the punch-card replication). Motivation to
|
||||
finish rises as the goal gets closer. Multi-step flows render with a
|
||||
prominent progress indicator that reflects *real* endowed progress —
|
||||
show completed prerequisites when they truly exist (saved profile,
|
||||
imported team, prior survey answer). When no real prerequisite
|
||||
exists, render the current step honestly as `1 of N` with the
|
||||
empty/current-step state clearly marked. Hull's hypothesis is
|
||||
descriptive; treating it as license for fabricated progress, streak
|
||||
dark patterns, or loyalty-program quota inflation is a misread.
|
||||
- **Postel's Law / Robustness Principle** (Postel, RFC 760, 1980). "Be
|
||||
liberal in what you accept, conservative in what you send." Take
|
||||
input in whatever shape users naturally give it (phone numbers with
|
||||
or without dashes, dates in mixed formats, percentages with or
|
||||
without `%`); normalize internally to a canonical form; emit one
|
||||
consistent format on output. The error-timing and ARIA-wiring half
|
||||
lives in `form-validation.md`; the input-tolerance half is the
|
||||
directive above. RFC 9413 (Thomson, IAB, 2023; built on the earlier
|
||||
`draft-iab-protocol-maintenance`) retracts the maxim for protocol
|
||||
design citing security surface; the UX-input application stands.
|
||||
|
||||
## Behavior and expectation
|
||||
|
||||
Five laws cover what users predict and how that prediction interacts
|
||||
with the rendered surface.
|
||||
|
||||
- **Jakob's Law** (Nielsen, Nielsen Norman Group, 2000). Users spend
|
||||
most of their time on other sites and expect yours to work the same.
|
||||
Reuse category convention — nav placement, cart icon, settings gear,
|
||||
primary CTA in the upper right of a SaaS landing — so the user spends
|
||||
zero cycles relearning interaction grammar. Novelty must earn its
|
||||
keep against the convention's ROI; "innovate everywhere" is the
|
||||
opposite failure mode.
|
||||
- **Mental Model** (Craik, *The Nature of Explanation*, 1943; Norman,
|
||||
*POET / The Psychology of Everyday Things*, 1988). Every user
|
||||
arrives with a prior built from competitor products and the physical
|
||||
world. When the prediction holds, the product feels intuitive; when
|
||||
it breaks, friction shows up as confusion, not curiosity. When the
|
||||
brief names a reference product, anchor explicitly — capture the
|
||||
reference in the prompt and the agent inherits a transferable
|
||||
interaction grammar.
|
||||
- **Paradox of the Active User** (Carroll & Rosson, in *Interfacing
|
||||
Thought: Cognitive Aspects of Human-Computer Interaction*, MIT Press,
|
||||
1987, pp. 80–111). Users skip the manual and start using the
|
||||
software immediately, even when reading it would speed them up. Bake
|
||||
guidance into the surface itself — empty-state coaching, inline
|
||||
tooltips, contextual hints — at the action point.
|
||||
- **Parkinson's Law** (Parkinson, *The Economist*, 1955). Work expands
|
||||
to fill the time allotted to it. Loose interfaces let users dawdle;
|
||||
cut friction and pre-fill what you can — autofill, smart defaults,
|
||||
saved state — so a checkout finishes faster than the user expected.
|
||||
Beating anticipated duration becomes the felt win.
|
||||
- **Cognitive Load** (Sweller, *Cognitive Science*, 1988). Total
|
||||
mental effort splits into intrinsic (the task's inherent difficulty)
|
||||
and extraneous (poor layout, jargon, inconsistent patterns, visual
|
||||
noise). Designers can't reduce intrinsic load; they own extraneous
|
||||
fully. The visual-restraint directives (single accent in `color.md`,
|
||||
three-weight typography rhythm in `chinese-typography.md`, P0 anti-default
|
||||
list in `anti-ai-slop.md`) already constrain extraneous load; this
|
||||
entry exists to name the cognitive cost the sibling rules reduce.
|
||||
|
||||
## Common mistakes (lint these)
|
||||
|
||||
Folklore corrections that don't survive a primary-source check, in the
|
||||
same vein as the busts already documented in `animation-discipline.md`
|
||||
and `accessibility.md`. The first three are attribution
|
||||
corrections (year / venue / institution) the body entries already
|
||||
applied — restated here so a reviewer reading just this section sees
|
||||
them. The remainder are folklore not addressed in the body.
|
||||
|
||||
- "Anchoring effect = Tversky & Kahneman 1972." Wrong year. The
|
||||
*Science* paper introducing the anchoring framing is 1974; the 1972
|
||||
paper is "Subjective probability: A judgment of representativeness"
|
||||
(different work).
|
||||
- "Tesler's Law was developed at Xerox PARC." Tesler left PARC for
|
||||
Apple in 1980; the Conservation-of-Complexity formulation traces to
|
||||
his Apple years.
|
||||
- "Paradox of the Active User was a CACM article." It's a chapter in
|
||||
Carroll's *Interfacing Thought* (MIT Press, 1987), not CACM.
|
||||
- "Selective Attention = solved by red dots and badges." Repeated
|
||||
attention-grabbers train banner blindness. Reserve the strongest
|
||||
contrast for one goal-relevant action per surface.
|
||||
- "Fitts's Law alone is enough for touch targets." Fitts gives the
|
||||
speed-accuracy tradeoff. WCAG 2.2 SC 2.5.8 sets the AA floor at
|
||||
24 × 24 CSS px (`accessibility.md`); iOS HIG suggests
|
||||
44 × 44 pt; Material 3 suggests 48 × 48 dp. Fitts plus the
|
||||
platform floor — never just Fitts.
|
||||
+164
@@ -0,0 +1,164 @@
|
||||
---
|
||||
name: link-and-proof
|
||||
description: Link, CTA destination, placeholder, proof provenance, source-labeling, and fake-claim prevention rules.
|
||||
mode: reference
|
||||
platform: web
|
||||
scenario: horizontal-craft
|
||||
preview:
|
||||
type: none
|
||||
default_for:
|
||||
- proof provenance
|
||||
- links
|
||||
- dead links
|
||||
- placeholder links
|
||||
- fake proof
|
||||
- CTA destinations
|
||||
fidelity: system
|
||||
---
|
||||
|
||||
# Link and Proof
|
||||
|
||||
Use this file whenever an artifact contains links, CTAs, proof-like claims, metrics, logos, testimonials, awards, press mentions, or case studies.
|
||||
|
||||
---
|
||||
|
||||
## Dead link protocol
|
||||
|
||||
Never use:
|
||||
|
||||
```html
|
||||
<a href="#">...</a>
|
||||
<a href="javascript:void(0)">...</a>
|
||||
<button onclick="">...</button>
|
||||
<button onclick="alert('todo')">...</button>
|
||||
<button onclick="console.log('clicked')">...</button>
|
||||
```
|
||||
|
||||
Use one of:
|
||||
|
||||
```html
|
||||
<a href="#contact">Contact</a>
|
||||
<button type="button" data-action="open-demo">Open demo</button>
|
||||
<a aria-disabled="true" data-placeholder-link>Link pending</a>
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- navigation uses `<a href="...">`
|
||||
- actions use `<button type="button">`
|
||||
- if the CTA destination is unknown, use a real section anchor, disabled placeholder, or ask if it materially matters
|
||||
- no fake external links
|
||||
- no placeholder JavaScript logic
|
||||
|
||||
---
|
||||
|
||||
## Proof-like content
|
||||
|
||||
Proof-like content includes:
|
||||
|
||||
- percentages
|
||||
- money
|
||||
- revenue
|
||||
- market size
|
||||
- user counts
|
||||
- customer counts
|
||||
- testimonials
|
||||
- awards
|
||||
- pricing
|
||||
- logos
|
||||
- case studies
|
||||
- benchmarks
|
||||
- “trusted by” claims
|
||||
- press mentions
|
||||
- rankings
|
||||
- dates that imply launch or traction
|
||||
|
||||
Allowed provenance states:
|
||||
|
||||
```text
|
||||
user-provided
|
||||
sourced
|
||||
demo
|
||||
placeholder
|
||||
```
|
||||
|
||||
Recommended attribute:
|
||||
|
||||
```html
|
||||
<span data-proof="user-provided">¥128/月</span>
|
||||
<span data-proof="sourced">92%</span>
|
||||
<span data-proof="demo">92% demo</span>
|
||||
<span data-proof="placeholder">[填写真实满意度]</span>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- If the user provided the number, keep it and mark it when practical.
|
||||
- If a source is included in the artifact, mark it as sourced and include a source label.
|
||||
- If the number is illustrative, mark it visibly as demo.
|
||||
- If the number is unknown, use a placeholder.
|
||||
- Do not create fake customer logos, fake testimonials, fake press quotes, fake awards, fake market reports, fake rankings, or fake growth charts.
|
||||
- Decks and reports may use demo data only when clearly labeled as demo.
|
||||
|
||||
---
|
||||
|
||||
## Placeholder content
|
||||
|
||||
Forbidden:
|
||||
|
||||
```text
|
||||
TODO
|
||||
FIXME
|
||||
待实现
|
||||
lorem ipsum
|
||||
placeholder text
|
||||
feature one / two / three
|
||||
```
|
||||
|
||||
Allowed when clearly labeled:
|
||||
|
||||
```text
|
||||
[填写真实客户 Logo]
|
||||
[替换为用户提供的案例]
|
||||
示例数据，仅用于版式预览
|
||||
Demo data — replace before publishing
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## CTA destination rules
|
||||
|
||||
Every CTA must answer:
|
||||
|
||||
1. What will happen?
|
||||
2. Is it navigation or an action?
|
||||
3. Is the destination real, in-page, disabled, or pending?
|
||||
|
||||
Bad:
|
||||
|
||||
```html
|
||||
<a href="#" class="button">立即体验</a>
|
||||
```
|
||||
|
||||
Better:
|
||||
|
||||
```html
|
||||
<a href="#demo" class="button">预约演示</a>
|
||||
<button type="button" class="button" data-action="generate-report">生成报告</button>
|
||||
<a aria-disabled="true" data-placeholder-link class="button">等待接入报名链接</a>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality checks
|
||||
|
||||
```text
|
||||
[ ] No href="#" or javascript:void(0) exists.
|
||||
[ ] Every CTA has a real behavior or visible pending state.
|
||||
[ ] Proof-like claims have provenance.
|
||||
[ ] Demo data is visibly labeled.
|
||||
[ ] No fake logos, quotes, awards, press, rankings, or case outcomes exist.
|
||||
[ ] Placeholder content is bracketed or labeled, not disguised as final copy.
|
||||
```
|
||||
+277
@@ -0,0 +1,277 @@
|
||||
# 排版方向 Text Direction：横排 / 直排 / 混排
|
||||
|
||||
中文是世界上少数能**横竖两套排版系统并行**的文字。"用什么方向"是任何中文排版项目的第一个决策，而不是默认横排。本文给出方向决策树、参数对照、CSS 实现、地区风格差异。
|
||||
|
||||
## 一、方向决策树
|
||||
|
||||
```
|
||||
内容主要属性是什么？
|
||||
│
|
||||
├─ 古籍 / 文言 / 诗词 / 书法集 / 题词 / 对联 ────────────→ 直排
|
||||
├─ 邀请函 / 请柬 / 礼仪文书 / 书信复古 ──────────────→ 直排
|
||||
├─ 博物馆图录 / 艺术画册中"诗题画跋"页 ────────────→ 直排
|
||||
├─ 杂志 / 报纸 / 教材 / 学术论文 / 商务文档 ───────→ 横排
|
||||
├─ 现代小说 / 散文 / 网页 / H5 / App ───────────────→ 横排
|
||||
└─ 工具书 / 字典 / 辞海 ───────────────────────→ 横排（直排版多见于民国老版本）
|
||||
|
||||
需不需要混排？
|
||||
│
|
||||
├─ 直排中遇 1 字英文/缩略词 ────→ 正立排（保持横向单字）
|
||||
├─ 直排中遇 2-3 位阿拉伯数字 ───→ 纵中横排 tate-chu-yoko（保持横向小组）
|
||||
├─ 直排中遇整段西文/词组 ───────→ 顺时针 90° 旋转
|
||||
├─ 直排中遇竖排小注 ──────────→ 双行夹注（注文两行平行，字号 1/2）
|
||||
├─ 横排中遇直排标题/匾额 ──────→ 局部 writing-mode: vertical-rl
|
||||
└─ 横排中遇直排小段诗词引文 ───→ 局部直排（"插秧式"）
|
||||
```
|
||||
|
||||
## 二、横排 vs 直排参数对照
|
||||
|
||||
| 维度 | 横排 | 直排 |
|
||||
|---|---|---|
|
||||
| 文字方向 | 左 → 右 | 上 → 下 |
|
||||
| 行方向 | 上 → 下 | **右 → 左** |
|
||||
| 翻页方向 | 从左向右翻（**左侧装订**） | 从右向左翻（**右侧装订**） |
|
||||
| 正面页位置 | 右页（奇数页） | 左页（奇数页） |
|
||||
| 分栏方向 | 垂直切分（左中右栏） | 水平切分（上中下栏） |
|
||||
| 图/表标题位置 | 上方 / 下方 | 左侧 / 右侧 |
|
||||
| 表头行位置 | 上方 | 右侧 |
|
||||
| 表头列位置 | 左侧 | 上方 |
|
||||
| 末页多栏行数 | 各栏尽量对齐，余空在末栏末尾 | 顺其结束，各栏行数可不齐 |
|
||||
| 行长上限 | ≤ 48 字 | ≤ 55 字 |
|
||||
| 行长下限 | ≥ 10 字 | ≥ 10 字 |
|
||||
| CSS writing-mode | `horizontal-tb`（默认） | `vertical-rl` |
|
||||
|
||||
## 三、标点在横/直排中的差异（大陆 GB/T 15834-2011）
|
||||
|
||||
**关键差异点。错配会让版面瞬间显业余。**
|
||||
|
||||
| 标点 | 横排（大陆） | 直排（大陆） | 港台 |
|
||||
|---|---|---|---|
|
||||
| 句号 。 | 字面左下角 | 字面右上角 | 字面正中 |
|
||||
| 逗号 ， | 字面左下角 | 字面右上角 | 字面正中 |
|
||||
| 顿号 、 | 字面左下角 | 字面右上角 | 字面正中 |
|
||||
| 冒号 ： | 字面左下角，直立 | **直立偏右**（不转 90°） | 居中直立 |
|
||||
| 分号 ； | 字面左下角，直立 | **直立偏右**（不转 90°） | 居中直立 |
|
||||
| 问号 ？ | 字面左下角，直立 | **直立**（不转 90°） | 居中直立 |
|
||||
| 叹号 ！ | 字面左下角，直立 | **直立**（不转 90°） | 居中直立 |
|
||||
| 引号（双） | 弯引号 " " | **直角引号 「」**（双） | 直角引号 |
|
||||
| 引号（单） | 弯引号 ' ' | 直角引号 『』 | 直角引号 |
|
||||
| 书名号 | 《》〈〉 | 《》（直立） | 甲式波浪 ﹏（台湾）/ 乙式《》 |
|
||||
| 破折号 | —— 占 2 字水平居中 | **占 2 字垂直居中** | 同 |
|
||||
| 省略号 | …… 占 2 字，6 点水平居中 | 占 2 字，6 点**垂直居中** | 同 |
|
||||
|
||||
**反例（要避免）**：
|
||||
- 把日文规则套用到中文直排：冒号、分号、问号、叹号在日文直排转 90° 躺倒；**中文必须保持直立**。某代 macOS 因 Unicode UAX#50 早期不完善曾把中文比照日文，是错误案例。
|
||||
- 直排正文用弯引号 " "（应改用直角「」）。
|
||||
|
||||
## 四、直排中混排西文的 3 种方法（W3C CLReq §2.1.3）
|
||||
|
||||
直排文本中遇到西文/数字时，根据长度选用：
|
||||
|
||||
### 方法 1：正立排（Upright）
|
||||
- 用于：**单个字母、首字母缩略词**（如 GDP、CPU、A）
|
||||
- 做法：用与汉字等宽的字体或全角字符，与汉字同方向逐字排
|
||||
- CSS：`text-orientation: upright`
|
||||
- 示例：`一个 G D P 增速…` （G、D、P 各占一格，与汉字同方向）
|
||||
|
||||
### 方法 2：顺时针 90° 旋转（Rotated）
|
||||
- 用于：**一般单词 / 句子 / 4 位以上数字**（如 "JavaScript"、"2024"、"the quick brown fox"）
|
||||
- 做法：用比例字体，整词整句旋转
|
||||
- 汉字与西文之间间距 **≤ 1/4 汉字宽**；西文位于行首/行尾时**不加空白**
|
||||
- CSS：`text-orientation: sideways`（即默认行为）
|
||||
|
||||
### 方法 3：纵中横排（Tate-chu-yoko 縦中横）
|
||||
- 用于：**2–3 位阿拉伯数字、短缩写**（如 "3.0"、"A+"、"2B"、"21"、"AM"、"99"）
|
||||
- 做法：比例字体，保持正方向横置；宽度与行幅相当或稍出
|
||||
- 活字时代严格不超过 1 个汉字宽；现今可凸出行间
|
||||
- CSS：`text-combine-upright: all`
|
||||
- 示例：年龄 `21` 岁、`3.0` 升发动机、温度 `25` ℃
|
||||
|
||||
### 混排间距规则（直排同横排）
|
||||
- 直排中**通常不用弯引号**（应改用直角引号）
|
||||
- 若引用西文且用弯引号，需跟随被引文旋转
|
||||
- 直排中阿拉伯数字内部不可分行，破折号/省略号不可分行
|
||||
|
||||
## 五、横排中嵌入直排
|
||||
|
||||
现代横排文档中嵌入小段直排的场景：
|
||||
|
||||
- 标题 / 匾额 / 题字
|
||||
- 古诗引文（一首七绝直排展示，强化古意）
|
||||
- 对联（两幅竖排平行展示）
|
||||
- 印章、闲章、款识
|
||||
- 杂志专题"穿插式"页面
|
||||
|
||||
**CSS 实现**：
|
||||
```css
|
||||
.vertical-quote {
|
||||
writing-mode: vertical-rl; /* 直排：从右向左 */
|
||||
text-orientation: mixed; /* 汉字直立，西文转横 */
|
||||
height: 20em;
|
||||
margin: 0 1em;
|
||||
}
|
||||
```
|
||||
|
||||
**注意事项**：
|
||||
- 直排段在横排里要"做容器"——给定明确高度，不要让它自由撑开
|
||||
- 直排标点要切换到右上角形态；不要直接搬横排标点
|
||||
- 嵌入位置遵守"文意停顿"——句间嵌入而非词间
|
||||
|
||||
## 六、装订与翻页方向
|
||||
|
||||
装订方向直接影响版心位置和阅读体验，不能搞反。
|
||||
|
||||
| 方向 | 装订侧 | 翻页方向 | 第一页（正面）位置 | 用途 |
|
||||
|---|---|---|---|---|
|
||||
| **横排左翻** | 左侧 | 从左向右 | **右页**（奇数页） | 现代中文书、教材、报告、所有英文书 |
|
||||
| **直排右翻** | 右侧 | 从右向左 | **左页**（奇数页） | 古籍、文言、诗集、传统书法集 |
|
||||
| **直排左翻（错的）** | 左侧 | 从左向右 | — | 中日韩三国都不用 |
|
||||
|
||||
**关键检查项**：
|
||||
- 大标题必须出现在**正面页**（横排右页 / 直排左页），不能开在反面页
|
||||
- 章节末页留出余白时，留白方向匹配阅读方向（横排留下方、直排留下方）
|
||||
- 跨页大图：横排左页向右延展、直排右页向左延展
|
||||
|
||||
## 七、CSS writing-mode 完整指南
|
||||
|
||||
```css
|
||||
/* 横排（默认） */
|
||||
.horizontal {
|
||||
writing-mode: horizontal-tb; /* horizontal, top-to-bottom */
|
||||
}
|
||||
|
||||
/* 直排（中文、日文、传统蒙文） */
|
||||
.vertical {
|
||||
writing-mode: vertical-rl; /* vertical, right-to-left lines */
|
||||
text-orientation: mixed; /* 汉字立、半角西文转 90° */
|
||||
}
|
||||
|
||||
/* 直排但行从左向右（少见，部分新蒙文） */
|
||||
.vertical-lr {
|
||||
writing-mode: vertical-lr;
|
||||
}
|
||||
|
||||
/* 直排内单字符强制立起来（缩略词、单字母） */
|
||||
.upright {
|
||||
text-orientation: upright;
|
||||
}
|
||||
|
||||
/* 纵中横排（数字小组保持横置） */
|
||||
.tcy {
|
||||
text-combine-upright: all;
|
||||
}
|
||||
```
|
||||
|
||||
完整 HTML 示例：
|
||||
```html
|
||||
<article style="writing-mode: vertical-rl; height: 30em;">
|
||||
<p>
|
||||
秦时明月汉时关，万里长征人未还。
|
||||
但使<span style="text-combine-upright: all;">21</span>世纪有李广，
|
||||
不教胡马度阴山。
|
||||
</p>
|
||||
</article>
|
||||
```
|
||||
|
||||
## 八、地区风格三大体系
|
||||
|
||||
地区差异的索引表——一个项目锁定一个地区，按下面维度逐项对齐。具体执行细节看对应文件：标点详见 `punctuation.md`、字体详见 `fonts.md`、避头尾详见 `punctuation.md § 四`。
|
||||
|
||||
| 维度 | 大陆简体 | 港台繁体 | 日文 |
|
||||
|---|---|---|---|
|
||||
| 标点位置 | **横排左下、直排右上** | **居中**（横直排都一样） | 横排左下、直排右上（同大陆） |
|
||||
| 避头尾严格度 | GB 级 / strict 级 | 多不严格（标点居中无突兀） | 严格 |
|
||||
| 标点风格 | 开明式（句末全宽、句内半宽）多 | 居中式 + 多不调宽度 | 开明式 + 严格挤压 |
|
||||
| 直排冒号分号 | 直立偏右 | 居中直立 | **转 90° 躺倒** |
|
||||
| 引号 | 弯引号 ""''（横）/ 直角「」（直） | 直角「」『』（先单后双） | 直角「」 |
|
||||
| 书名号 | 《》〈〉 | 甲式波浪 ﹏（书底）+ 乙式《》 | 二重括号 『』 |
|
||||
| 间隔号 · | 占**半字宽** | 占**全字宽** | 占全字宽 |
|
||||
| 公文字体 | **仿宋** | **楷体** | 明朝体 |
|
||||
|
||||
**核心心法**：项目开始就锁定地区风格，不要"中港台日"混用。
|
||||
|
||||
## 九、什么时候直排？什么时候横排？
|
||||
|
||||
### 必须直排
|
||||
- 古籍影印 / 古籍今译保留原貌
|
||||
- 文言文学校教材（部分台湾教材）
|
||||
- 中医典籍、佛经、道经
|
||||
- 书法作品集、字帖
|
||||
- 传统戏曲剧本（旧版）
|
||||
- 朱批奏折、家书复刻
|
||||
|
||||
### 强烈推荐直排
|
||||
- 当代古典诗词集
|
||||
- 茶艺 / 香道 / 国画相关书籍
|
||||
- 高端艺术画册"诗题画跋"页
|
||||
- 邀请函 / 请柬 / 谢卡（小段）
|
||||
- 博物馆图录的部分内页（混合）
|
||||
- 题字 / 题词 / 闲章
|
||||
|
||||
### 可以选直排（增加古意 / 仪式感）
|
||||
- 散文集封面
|
||||
- 招贴海报标题
|
||||
- 茶包装、白酒包装文案
|
||||
- 婚礼喜帖
|
||||
- 复古风咖啡店菜单
|
||||
|
||||
### 不要直排
|
||||
- 现代长文（用户已习惯横向扫视）
|
||||
- 表格密集的文档（直排表格难做）
|
||||
- 大量中英混排的技术 / 学术内容
|
||||
- 网页正文（写读不便、生态差）
|
||||
- App / H5（小屏直排压力大）
|
||||
|
||||
## 十、混排（横直交叉）的进阶玩法
|
||||
|
||||
不要把"混排"理解为"破格"——这是中文排版的基础语法。常见 5 种：
|
||||
|
||||
### 1. 横排正文 + 直排引文
|
||||
正文横排，引用的古诗、对联、题词单段直排，与正文形成节奏对比。
|
||||
|
||||
```html
|
||||
<article class="horizontal-body">
|
||||
<p>李白《静夜思》写道：</p>
|
||||
<blockquote class="vertical-quote">
|
||||
床前明月光，疑是地上霜。<br>
|
||||
举头望明月，低头思故乡。
|
||||
</blockquote>
|
||||
<p>这首诗体现了…</p>
|
||||
</article>
|
||||
```
|
||||
|
||||
### 2. 直排正文 + 横排数据
|
||||
古籍今译类，正文直排，但年表、数据表、地图说明等横排。靠纸张/底色区分。
|
||||
|
||||
### 3. 跨页"半横半直"
|
||||
左页直排（古文原文）、右页横排（今译），翻页对照。常见于古籍今译。
|
||||
|
||||
### 4. 标题直排、正文横排
|
||||
封面 / 章首页用直排大字标题，营造仪式感；内页正文回到横排实用。
|
||||
|
||||
### 5. 双行夹注（小注）
|
||||
直排正文中插入双行夹注：两行小注同高，字号为正文 1/2，平行排列。古籍标配。
|
||||
|
||||
```
|
||||
正┃ 双行夹注：
|
||||
文┃ 上行注┃下行注
|
||||
正┃ 上行注┃下行注
|
||||
文┃
|
||||
```
|
||||
|
||||
## 十一、检查清单（方向相关）
|
||||
|
||||
排印完成前必过：
|
||||
|
||||
- [ ] 排版方向（横 / 直 / 混）是否与内容气质匹配？
|
||||
- [ ] 装订方向是否与排版方向对应？（横左翻 / 直右翻）
|
||||
- [ ] 大标题是否在正面页（横右页 / 直左页）？
|
||||
- [ ] 直排中数字是否用了纵中横排？
|
||||
- [ ] 直排中单字英文是否用了正立排？
|
||||
- [ ] 直排标点是否切换到右上角形态？
|
||||
- [ ] 直排冒号分号是否保持直立（没躺成日式）？
|
||||
- [ ] 直排引号是否改用了直角「」？
|
||||
- [ ] 地区风格是否一致？（没把港台居中标点 + 大陆 GB 避头尾混用）
|
||||
- [ ] 横排嵌直排的段落是否给了明确高度？
|
||||
- [ ] 图表标题方向是否匹配主排版方向？
|
||||
- [ ] CSS `writing-mode` 和 `text-orientation` 是否成对设置？
|
||||
+627
@@ -0,0 +1,627 @@
|
||||
# 字体选择与搭配 Chinese Font Selection
|
||||
|
||||
> 本文件是场景化中文字体选择、搭配与加载参考。不要在每个中文排版任务中默认读取；只有当字体会显著影响视觉方向，或需要命名字体 / 可加载字体测试时读取。
|
||||
|
||||
本文件按"选字体的实际顺序"组织：**一、选字体（决策线，从头读到尾选完）→ 二、加载执行（选完才需要）→ 三、原则自检（最后对照）**。
|
||||
不要跳着读字体表；先在 § 一 按气质定位，再到 § 二 取加载方式。
|
||||
|
||||
## 一、选字体（决策线）
|
||||
|
||||
不要先浏览所有字体表，也不要为了“好看”直接挑一个刺激的字体名。先把用户意图归类，再按媒介、字体角色、加载可用性筛选，最后只进入匹配的字体库表。
|
||||
|
||||
### 1.1 用户意图 → 场景类别
|
||||
|
||||
| 用户意图 / 关键词 | 场景类别 | 进入字体库 |
|
||||
|---|---|---|
|
||||
| SaaS / Dashboard / 产品页 / 科技 / 商务 / 工业 / 硬朗 / 效率 | 现代 / 工业 / 科技 / 商务 | 表 A |
|
||||
| 文学 / 古典 / 文化 / 新中式 / 感性 / 编辑 / 出版 / 杂志 | 文学 / 古典 / 优雅 / 感性 | 表 B |
|
||||
| 古籍 / 文言 / 诗词 / 引文 / 对话 / 传统文化 / 楷书气质 | 古籍 / 文言 / 引文 / 对话文 | 表 C |
|
||||
| 公文 / 党政机关 / 通知 / 制度文件 / 红头文件 | 公文 / 规范（大陆） | 表 D |
|
||||
| 台湾公文 / 台湾教科书 / 繁体正式 / 楷書教育 | 公文 / 教科书（台湾） | 表 E |
|
||||
| 学术 / 论文 / 白皮书 / 研究报告 / 严谨 / 可信 | 学术 / 严谨 / 出版 | 表 F |
|
||||
| 小红书封面 / 海报 / 活动页 / 标语 / 主视觉 / 大字号 | 标题 / 海报 / 大字号 | 表 G |
|
||||
|
||||
如果一个需求同时命中多个类别，先按**产物主目的**选主类别：
|
||||
|
||||
- 产品/UI 可用性优先 → 表 A；
|
||||
- 阅读与出版感优先 → 表 B / F；
|
||||
- 固定图片封面冲击力优先 → 表 G；
|
||||
- 正式规范优先 → 表 D / E。
|
||||
|
||||
### 1.2 字体筛选
|
||||
|
||||
进入字体库表后，不要直接选字体名。按下面 4 个条件筛掉不合适的字体。
|
||||
|
||||
| 筛选维度 | 判断问题 | 选择原则 |
|
||||
|---|---|---|
|
||||
| **交付媒介** | 是 Web/HTML、固定图片、长文、Dashboard，还是公文？ | Web 优先 `A:CDN` / `B:OSS切片`；固定图片可更强；长文和 Dashboard 优先可读；公文按规范。 |
|
||||
| **字体角色** | 这套字体用于正文、标题、展示字、引文、数字，还是 UI 控件？ | 正文重可读；标题重气质；展示字只用于短标题/标语；UI 控件优先稳定屏幕字体。 |
|
||||
| **加载可用性** | 字体是否真的能在 HTML 中加载？ | `A:CDN` 可直接用；`B:OSS切片` 用 `@font-face`；`C:仅参考` 不能直接写进 `font-family`。 |
|
||||
| **内容密度** | 字数多、信息密，还是短标题/海报？ | 密内容用稳字体；短标题才允许强展示字体。 |
|
||||
|
||||
快速筛选规则：
|
||||
|
||||
- **Web / HTML 输出**：优先 `A:CDN` 或 `B:OSS切片`；`C:仅参考` 不要直接写进 `font-family`。
|
||||
- **社媒图 / 海报 / 固定图片输出**：可以使用强展示字体，但仍需要可加载方案、用户提供字体文件，或明确它只是视觉气质参考。
|
||||
- **长文 / 报告 / 公众号**：正文优先高可读字体；强展示字体最多用于标题、栏目名、引文或关键数字。
|
||||
- **Dashboard / 表单 / 后台 / 工具页**：优先系统字体栈、思源黑、MiSans 等屏幕字体；不要用强展示字体做 UI 正文。
|
||||
- **公文 / 正式材料**：优先用户或机构规范；不要用海报字体“增强设计感”。
|
||||
|
||||
### 1.3 字体库表
|
||||
|
||||
字体库表只放字体本身的信息：字体名、字重、用途提示、加载方式。OSS/CDN/OSS切片状态也在这里体现，不要在场景路由表里重复展开。
|
||||
|
||||
“加载”列含义：
|
||||
|
||||
- `A:CDN` = 公共 CDN 可达，`<link>` 直接引（见 § 6）。
|
||||
- `B:OSS切片` = 当前已上传OSS切片，按 § 1.2/§ 1.4 写 `@font-face`。
|
||||
- `C:仅参考` = 无公共加载方案，仅作气质参考；确定方向后改用本类同气质 A/B 字体，或由用户提供字体文件。
|
||||
- `系统` = 系统字体（如 PingFang/macOS），无需加载但不跨平台保证。
|
||||
|
||||
以下字体库表只在场景命中后读取，不要跨场景扫表。
|
||||
|
||||
### 表 A：现代 / 工业 / 科技 / 商务
|
||||
|
||||
**关键词**：现代 · 工业 · 科技 · 商务 · 硬朗 · 效率 · 中性 · 极简 · UI · SaaS · Dashboard · 产品页
|
||||
|
||||
| 字体 | 字重数 | 用途/提示 | 加载 |
|
||||
|---|---|---|---|
|
||||
| 思源黑体 Source Han Sans | 7（ExtraLight–Heavy） | 屏幕通用首选，可正文可标题 | A:CDN |
|
||||
| MiSans 小米兰亭 | 7（Thin–Heavy） | 屏幕、移动 UI、Dashboard；字怀稍开 | A:CDN |
|
||||
| PingFang 苹方 | 6 | macOS/iOS 系统首选 | 系统 |
|
||||
| HarmonyOS Sans | 9 | 鸿蒙生态；字重最丰富之一；有 OSS 切片可加载 | B:OSS |
|
||||
| 阿里巴巴普惠体 | 5 | 商务、阿里系产品；有 OSS 切片可加载 | B:OSS |
|
||||
| OPPO Sans | 5 | 移动端、ColorOS 生态；有 OSS 切片可加载 | B:OSS |
|
||||
| BIZ UD Gothic | 2 | 日系气质；⚠ CJK 以 JIS 为主，简体部分字符 fallback | A:CDN |
|
||||
| 方正兰亭黑（家族） | 6+ | 出版排版经典选择 | C:仅参考 |
|
||||
| 汉仪旗黑 | 12 | 字重最丰富，商业项目 | C:仅参考 |
|
||||
| 创客贴金刚体 | 1 | 强工业感标题；有 OSS 切片可加载 | B:OSS |
|
||||
| 字体传奇特战体 | 1 | 极强工业/锐角，仅标题 | B:OSS切片 |
|
||||
| 站酷酷黑 | 1 | 硬朗标题 | B:OSS切片 |
|
||||
| 标小智无界黑 | 1 | 现代/无界感标题；有 OSS 切片可加载 | B:OSS |
|
||||
|
||||
**提示**：工业/科技不等于一律超黑粗体；信息密度高时强字体只用于主标题或关键数字。故障、特战类强烈改变气质，适合海报/发布页，不适合后台和长文。
|
||||
|
||||
### 表 B：文学 / 古典 / 优雅 / 感性
|
||||
|
||||
**关键词**：文学 · 古典 · 优雅 · 感性 · 文化 · 新中式 · 情绪 · 抒情 · 编辑 · 出版 · 杂志
|
||||
|
||||
| 字体 | 字重数 | 用途/提示 | 加载 |
|
||||
|---|---|---|---|
|
||||
| 思源宋体 Source Han Serif | 6 | 通用稳妥首选，可正文可标题 | A:CDN |
|
||||
| BIZ UD Mincho | 2 | 现代明朝、易读性强；⚠ JIS 为主、简体部分字符 fallback | A:CDN |
|
||||
| 方正书宋 | 多 | 经典书宋，温和 | C:仅参考 |
|
||||
| 方正雅宋 / 准雅宋 | 多 | 现代宋代表 | C:仅参考 |
|
||||
| 汉仪玄宋 | 5 | 偏现代，字面率小、留白多 | C:仅参考 |
|
||||
| 汉仪书宋 | 多 | 经典书宋 | C:仅参考 |
|
||||
| 霞鹜致宋 | 1 | 文化气质标题 | B:OSS切片 |
|
||||
| 飞花宋体 / 一点明体 / 京华老宋体 | 1 | 文学气质标题；飞花宋体、一点明体有 OSS 切片，京华老宋体仅参考 | B:OSS切片 / C:仅参考 |
|
||||
| 瀞之故障明朝 | 1 | 故障感文学标题 | C:仅参考 |
|
||||
| 新愚公沧桑体 | 1 | 沧桑/感性文学标题；有 OSS 切片可加载 | B:OSS |
|
||||
| ORADANO 明朝体 | 1 | 古典明朝感标题；有 OSS 切片可加载 | B:OSS |
|
||||
|
||||
**提示**：这类字体适合建立气韵，不适合密集 UI 和数据系统。文化感不能只靠字体——同时控制字距、行高、段落灰度。
|
||||
|
||||
### 表 C：古籍 / 文言 / 引文 / 对话文
|
||||
|
||||
**关键词**：古籍 · 文言 · 诗词 · 引文 · 对话 · 剧本 · 书卷 · 传统文化 · 楷书气质
|
||||
|
||||
| 字体 | 字重数 | 用途/提示 | 加载 |
|
||||
|---|---|---|---|
|
||||
| 霞鹜文楷 LXGW WenKai | 3 | 现代书卷感（清刻本风），古籍今译/文言/教科书 | A:CDN |
|
||||
| 寒蝉正楷体 | 1 | 楷体引文 | B:OSS切片 |
|
||||
| 演示春风楷 | 1 | 装饰性楷体标题 | B:OSS切片 |
|
||||
| 初夏明朝体 / 源流明体 | 多字重 | 明朝体文学标题/引文 | B:OSS切片 |
|
||||
| 润植家如印奏章楷 | 1 | 古意标题 | C:仅参考 |
|
||||
| 梦源宋体 | 多 | 现代宋体替代 | C:仅参考 |
|
||||
| 江西拙楷 | 1 | 拙朴楷体 | B:OSS切片 |
|
||||
| 仓耳今楷 | 多 | 严谨可读楷体，教育/儿童 | C:仅参考 |
|
||||
| Kaiti SC（macOS） | 1 | 系统楷，标题、引文 | 系统 |
|
||||
| 方正楷体 GBK | 1 | 大陆常见楷，标题/引文 | C:仅参考 |
|
||||
|
||||
**提示**：楷、明、仿宋类适合营造文气，但不要默认用于长篇屏幕正文。对话文优先保证人名、冒号、引号和行距清楚。古籍/文言场景同时检查标点、断句、直排/横排和字距。
|
||||
|
||||
### 表 D：公文 / 规范（大陆）
|
||||
|
||||
**关键词**：公文 · 党政机关 · 通知 · 制度文件 · 正式规范 · 红头文件
|
||||
|
||||
| 字体 | 字重数 | 用途/提示 | 加载 |
|
||||
|---|---|---|---|
|
||||
| 方正小标宋简体 | 1 | 公文一级标题 | C:仅参考 |
|
||||
| 仿宋 GB2312 | 1 | 公文正文（16pt） | C:仅参考 |
|
||||
| 黑体（系统/方正） | 多 | 公文小标题（16pt） | 系统/C |
|
||||
| 楷体 GB2312 | 1 | 公文签发说明（16pt） | C:仅参考 |
|
||||
|
||||
**提示**：公文场景不要自由发挥；优先遵守用户或机构提供的格式规范。公文字体方案不要迁移到普通网页、海报或产品 UI。
|
||||
|
||||
### 表 E：公文 / 教科书（台湾）
|
||||
|
||||
**关键词**：台湾公文 · 台湾教科书 · 繁体正式 · 楷書教育
|
||||
|
||||
| 字体 | 字重数 | 用途/提示 | 加载 |
|
||||
|---|---|---|---|
|
||||
| 中文采楷書 | 1 | 台湾公文/教材标准 | C:仅参考 |
|
||||
| 华康楷体 | 多 | 台湾公文/教科书 | C:仅参考 |
|
||||
| 文鼎楷体 | 多 | 同上 | C:仅参考 |
|
||||
| 文鼎 PMingLiu 明朝体 | 1 | 繁体经典正文 | 系统 |
|
||||
|
||||
**提示**：台湾公文/教科书不要套用大陆公文的仿宋方案。双语材料注意中文楷书与西文（如 Times New Roman）的行高、基线和字号协调。
|
||||
|
||||
### 表 F：学术 / 严谨 / 出版
|
||||
|
||||
**关键词**：学术 · 严谨 · 论文 · 白皮书 · 研究报告 · 出版 · 正式 · 可信
|
||||
|
||||
**通用稳妥搭配**：思源宋体（正文）+ 思源黑体（标题），或 方正书宋 + 方正兰亭黑。
|
||||
|
||||
| 字体 | 字重数 | 用途/提示 | 加载 |
|
||||
|---|---|---|---|
|
||||
| 思源宋体 | 6 | 正文首选 | A:CDN |
|
||||
| 思源黑体 | 7 | 标题首选 | A:CDN |
|
||||
| 狮尾四季春 | 多字重 | 学术、严谨、出版标题；繁中/宋体气质 | B:OSS切片 |
|
||||
| 思源赢宋 | 1 | 学术报告标题；有 OSS 切片可加载 | B:OSS |
|
||||
| 朱雀仿宋 | 1 | 仿宋正文（特定语境） | B:OSS切片 |
|
||||
| 字体圈欣意吉祥宋 | 1 | 严谨宋体 | B:OSS切片 |
|
||||
|
||||
**提示**：严谨场景优先可读性和可信度，不使用过强装饰字。仿宋适合公文/制度/正式文本气质，不要滥用于现代产品页正文。
|
||||
|
||||
### 表 G：标题 / 海报 / 大字号
|
||||
|
||||
**关键词**：标题 · 海报 · 封面 · 主视觉 · 标语 · 小红书封面 · 活动页 · 大字号 · 显眼
|
||||
|
||||
| 字体 | 字重数 | 用途/提示 | 加载 |
|
||||
|---|---|---|---|
|
||||
| 得意黑 Smiley Sans | 1 | 倾斜现代标题 | A:CDN |
|
||||
| 钉钉进步体 | 1 | 现代品牌标题 | A:CDN / B:OSS切片 |
|
||||
| 抖音美好体 DouyinSans | 1 | 抖音生态、活泼现代；有 OSS 切片可加载 | B:OSS |
|
||||
| 阿里妈妈数黑体 | 1 | 营销标题、强冲击 | B:OSS切片 |
|
||||
| 思源黑体 Heavy | 1 | 通用稳妥重标题 | A:CDN |
|
||||
| 庞门正道标题体 | 1 | 标语、口号；有 OSS 切片可加载 | B:OSS |
|
||||
| 文悦古典明朝 | 1 | 古风/复古标题 | C:仅参考 |
|
||||
| 汉仪铸字尚黑 / 悦圆 | 多 | 现代品牌 | C:仅参考 |
|
||||
| 优设标题黑 | 1 | 通用标题 | B:OSS切片 |
|
||||
| 追光斗鱼体 / 一品启航体 / 快看世界体 | 1 | 强气质标题；一品启航体、快看世界体有 OSS 切片，追光斗鱼体仅参考 | B:OSS切片 / C:仅参考 |
|
||||
| 字魂扁桃体 / 仓迹高德国妙黑 / Leefont 蒙黑体 | 1 | 装饰性标题；均有 OSS 切片 | B:OSS切片 |
|
||||
| 淘宝买菜体 / 汤宪滨宋 / 荆南俊俊体 | 1 | 强气质标题；荆南俊俊体有 OSS 切片，淘宝买菜体/汤宪滨宋仅参考 | B:OSS切片 / C:仅参考 |
|
||||
|
||||
**提示**：标题/海报字体可以更强，但必须服务主题，不要只为"显眼"。小红书、海报、活动页可以用；B2B SaaS、后台、研究报告慎用。标题很长时优先处理断行和层级，再决定是否用强展示字体。
|
||||
|
||||
### 1.4 家族搭配范式（选完气质字体后，定正文+标题搭配）
|
||||
|
||||
### 范式 A：单家族，多字重（极简，推荐入门）
|
||||
- 思源黑体 Light（正文）
|
||||
- 思源黑体 Medium（小标题）
|
||||
- 思源黑体 Bold（大标题）
|
||||
|
||||
### 范式 B：宋 + 黑 经典搭配
|
||||
- 思源宋体 Regular（正文）
|
||||
- 思源黑体 Medium（标题、图注、CTA 按钮）
|
||||
|
||||
### 范式 C：标题大字宋，正文黑（出版风）
|
||||
- 方正准雅宋 Bold（大标题）
|
||||
- 方正兰亭黑 Light（正文）
|
||||
|
||||
### 范式 D：同家族多字重 + 共同模数
|
||||
- 方正兰亭准黑 GBK 12pt（小标题）
|
||||
- 方正兰亭纤黑 GBK 9pt（正文）
|
||||
- 方正细黑一 GBK 6pt（图注）
|
||||
- 同模数（1.5pt）下三个字号通过家族字重协同
|
||||
|
||||
### 范式 E：宋 + 楷（古典 / 文学）
|
||||
- 方正书宋 Regular 10.5pt（正文）
|
||||
- 霞鹜文楷 Medium 14pt（标题、引文）
|
||||
- 适合：古诗集、文学随笔、传统文化项目
|
||||
|
||||
### 范式 F：大陆公文专用方案
|
||||
- 方正小标宋简体（标题候选）
|
||||
- 仿宋 GB2312（16pt，正文候选）
|
||||
- 黑体（16pt，层级/小标题候选）
|
||||
- 楷体 GB2312（16pt，特定说明/签发类文本候选）
|
||||
- 只用于大陆公文、通知、制度等正式文书，不迁移到普通网页/海报/UI。
|
||||
|
||||
### 范式 G：台湾公文 / 教科书专用方案
|
||||
- 中文采楷書（中文正文/教材候选）
|
||||
- Times New Roman（西文候选）
|
||||
- 注意中文楷书与西文衬线的基线、行高和字号协调。
|
||||
|
||||
### 1.5 中英文混排
|
||||
|
||||
中英混排时，目标不是“谁排在 font-family 第一”，而是：
|
||||
- 中文标点、破折号、省略号不能被西文字体接管；
|
||||
- 英文单词、数字可以有更好的 Latin 字体表现；
|
||||
- 行高、基线和视觉重量要协调。
|
||||
|
||||
| 中文字体 | 可搭配西文 | 备注 |
|
||||
|---|---|---|
|
||||
| 思源黑体 | Source Sans Pro / Inter | 技术、SaaS、报告 |
|
||||
| PingFang | San Francisco | macOS / iOS 原生匹配 |
|
||||
| MiSans | MiSans Latin | 同家族，行高匹配好 |
|
||||
| HarmonyOS Sans | HarmonyOS Sans Latin | 同家族 |
|
||||
| 思源宋体 | Source Serif Pro | 报告、编辑、出版感 |
|
||||
| 方正书宋 | Times / Georgia | 经典宋 + 经典衬线 |
|
||||
| 微软雅黑 | Segoe UI | Windows 环境 |
|
||||
| 霞鹜文楷 | Crimson Pro | 文楷 + 现代衬线 |
|
||||
| 方正仿宋 | EB Garamond / Crimson | 公文/古典感 |
|
||||
|
||||
#### 安全默认：中文字体在前
|
||||
|
||||
通用中文页面、H5、卡片和报告正文，默认用中文字体在前，保护中文标点：
|
||||
|
||||
```css
|
||||
font-family: "PingFang SC", "HarmonyOS Sans SC", "Noto Sans CJK SC",
|
||||
"Microsoft YaHei UI", "Microsoft YaHei",
|
||||
system-ui, -apple-system, BlinkMacSystemFont, sans-serif;
|
||||
```
|
||||
|
||||
#### 需要 Latin 优先时，不要直接把 Inter 放到 body 第一位
|
||||
|
||||
如果把 `Inter`、`Helvetica` 放到 body 第一位，破折号、引号、省略号等共享码位字符可能被西文字体抢走，导致下沉、断开或视觉不一致。
|
||||
|
||||
更稳的做法：
|
||||
|
||||
```css
|
||||
@font-face {
|
||||
font-family: "Inter Local";
|
||||
src: local("Inter");
|
||||
unicode-range: U+0000-007F;
|
||||
}
|
||||
body {
|
||||
font-family: "PingFang SC", "Noto Sans CJK SC", "Microsoft YaHei", sans-serif;
|
||||
}
|
||||
.latin {
|
||||
font-family: "Inter Local", Inter, system-ui, sans-serif;
|
||||
}
|
||||
```
|
||||
|
||||
也可以只对英文标题、数字、代码、标签使用 Latin class，不要让它接管中文正文标点。
|
||||
|
||||
### 1.6 可变字体（Variable Font）
|
||||
|
||||
新一代字体支持轴向调节，适合屏幕：
|
||||
- 思源黑体 Variable（GitHub）
|
||||
- 鸿蒙 HarmonyOS Sans Variable
|
||||
- **MiSans VF**（小米官网，权重轴）
|
||||
- Inter Variable
|
||||
|
||||
CSS：
|
||||
```css
|
||||
font-family: "Source Han Sans VF";
|
||||
font-variation-settings: "wght" 450;
|
||||
```
|
||||
|
||||
变体字重让设计响应屏幕尺寸（小屏用粗，大屏用细）。
|
||||
|
||||
## 二、加载执行（选定字体后）
|
||||
|
||||
### 2.1 三种加载情境，分清楚再写
|
||||
|
||||
| 字体类型 | 加载方式 | 示例 |
|
||||
|---|---|---|
|
||||
| **A. 公共 CDN 可达** | 直接 `<link>` 引 CDN（Google Fonts / jsDelivr 等自带子集化机制，浏览器自动按需下载） | 思源黑/宋、Noto SC、霞鹜文楷、得意黑、Source Sans 3 等 |
|
||||
| **B. OSS 切片 / 自托管切片** | 用生成 CSS 的 `@font-face` 引 woff2 切片 + `unicode-range`；`ext` 兜底放最后 | 当前已上传 OSS 切片的展示字体、找不到公共 CDN 但有自托管切片的字体 |
|
||||
| **C. 完全无加载方案** | 不要写进 `font-family`——仅用作气质参考 | § 2 候选清单中未标 `✓可加载`、且 § 6 无 CDN/无OSS切片的字体 |
|
||||
|
||||
### 2.2 B 类OSS切片：标准方案
|
||||
|
||||
当前 OSS 切片字体采用 **高频优先 CSS**：先加载高频汉字切片，再加载标点、拉丁，最后用扩展切片兜底。
|
||||
|
||||
参考 CSS 结构：
|
||||
|
||||
```text
|
||||
@font-face common-hi → 高频汉字，使用精确 unicode-range 列表
|
||||
@font-face punct → CJK 符号 + 通用标点 + 全角 ASCII
|
||||
@font-face latin → 基本拉丁 + 拉丁补充 + 常用标点
|
||||
@font-face ext → 兜底剩余字符，放最后
|
||||
```
|
||||
|
||||
切片说明：
|
||||
|
||||
| 切片名 | 推荐写法 | 覆盖 |
|
||||
|---|---|---|
|
||||
| `common-hi` | 使用生成 CSS 里的精确高频汉字 `unicode-range`，不要简化成整段 `U+4E00-9FFF` | 高频/常用中文，优先用于标题、封面和常见正文测试 |
|
||||
| `punct` | `U+3000-303F, U+2000-206F, U+FF00-FFEF` | CJK 符号标点、通用标点、全角 ASCII |
|
||||
| `latin` | `U+0020-007E, U+00A0-00FF, U+2010-2027` | 基本拉丁、拉丁补充、常用标点 |
|
||||
| `ext` | `U+0-10FFFF`，必须放在最后 | 兜底剩余字符，含低频汉字、生僻字和未覆盖字符 |
|
||||
|
||||
为什么 `common-hi` 不直接写 `U+4E00-9FFF`：
|
||||
|
||||
- `U+4E00-9FFF` 会让 common 切片承担整个 CJK 统一汉字区，失去“高频优先”的意义。
|
||||
- 生成 CSS 里的 `common-hi` 已经把常用 2500 汉字压成精确范围，浏览器只在页面出现这些字时下载高频切片。
|
||||
- 低频字交给最后的 `ext` 兜底，避免首屏强行加载过大的完整中文切片。
|
||||
|
||||
**当前OSS 切片链接**：直接使用 § 1.4 的已上传 URL，不再套 `{oss-host}` 占位。
|
||||
|
||||
**Paste-ready `@font-face` 模板**（从 § 1.4 复制某个字体/字重的 4 个 URL；`common-hi` 的 `unicode-range` 从对应生成 CSS 复制）：
|
||||
|
||||
```css
|
||||
/* 高频汉字：不要简化为 U+4E00-9FFF；复制生成 CSS 里的精确范围 */
|
||||
@font-face {
|
||||
font-family: "{字体显示名}";
|
||||
src: url("{common-hi-url}") format("woff2");
|
||||
unicode-range:
|
||||
/* paste generated common-hi unicode-range here */;
|
||||
font-display: swap;
|
||||
}
|
||||
|
||||
/* CJK 符号 + 通用标点 + 全角 ASCII */
|
||||
@font-face {
|
||||
font-family: "{字体显示名}";
|
||||
src: url("{punct-url}") format("woff2");
|
||||
unicode-range: U+3000-303F, U+2000-206F, U+FF00-FFEF;
|
||||
font-display: swap;
|
||||
}
|
||||
|
||||
/* 基本拉丁 + 拉丁补充 + 常用标点 */
|
||||
@font-face {
|
||||
font-family: "{字体显示名}";
|
||||
src: url("{latin-url}") format("woff2");
|
||||
unicode-range: U+0020-007E, U+00A0-00FF, U+2010-2027;
|
||||
font-display: swap;
|
||||
}
|
||||
|
||||
/* 兜底：剩余字符。必须放最后 */
|
||||
@font-face {
|
||||
font-family: "{字体显示名}";
|
||||
src: url("{ext-url}") format("woff2");
|
||||
unicode-range: U+0-10FFFF;
|
||||
font-display: swap;
|
||||
}
|
||||
```
|
||||
|
||||
使用注意：
|
||||
|
||||
- `common-hi`、`punct`、`latin`、`ext` 的顺序不要乱；`ext` 必须最后。
|
||||
- 如果没有对应字体的生成 CSS，临时预览可以用 § 1.4 的 URL + 简化范围，但不能当成正式加载方案。
|
||||
- 若用户只做短标题/社媒卡片，通常只会命中 `common-hi`、`punct`、少量 `latin`；长文和生僻字才会触发 `ext`。
|
||||
- 生产环境仍需确认授权、缓存策略、CORS、文件体积和实际命中字符。
|
||||
|
||||
**机制说明**：浏览器根据页面实际字符与 `unicode-range` 匹配下载字体切片。高频汉字先命中 `common-hi`，标点命中 `punct`，英文/数字命中 `latin`，其余字符由最后的 `ext` 兜底。
|
||||
|
||||
### 2.3 当前已上传 OSS 字体切片 URL 表
|
||||
|
||||
本节是字体加载查表，放在 `fonts.md` 内，避免运行时再跳到第三个文件。
|
||||
|
||||
使用顺序：
|
||||
|
||||
1. 先按 § 2 完成“用户意图 → 场景类别 → 字体筛选”。
|
||||
2. 如果选中 `B:OSS切片` 字体，再回到本节查对应 `font-family`、`font-weight` 和 4 个切片 URL。
|
||||
3. 把 URL 填入 § 1.2 的 `@font-face` 模板。
|
||||
4. 多字重家族必须写 `font-weight`，不要把所有切片都声明成 `normal`。
|
||||
5. `common-hi` 的精确 `unicode-range` 仍应从对应生成 CSS 复制；没有生成 CSS 时只能临时测试。
|
||||
|
||||
不要从本节直接挑字体。本节只负责“已选字体如何加载”。
|
||||
|
||||
#### 字体家族概要
|
||||
|
||||
| font_examples | css_family | font_weights | scene | count |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 寒蝉正楷体 | `"ChillKai"` | 400 | 古籍 / 文言 / 引文 / 对话文 | 1 |
|
||||
| 演示春风楷 | `"Slide Chunfeng Kai"` | 400 | 古籍 / 文言 / 引文 / 对话文，楷体标题 | 1 |
|
||||
| 江西拙楷 | `"Jiangxi ZhuoKai"` | 400 | 古籍 / 文言 / 拙朴楷体 | 1 |
|
||||
| 朱雀仿宋 | `"Zhuque Fangsong"` | 400 | 学术 / 严谨 / 仿宋语境 | 1 |
|
||||
| 思源赢宋 | `"CorpSrcWinSong Slim"` | 400 | 学术 / 严谨 / 出版标题 | 1 |
|
||||
| 阿里巴巴普惠体 | `"Alibaba PuHuiTi 3.0"` | 400 | 现代 / 商务 / 阿里系 | https://fileup.chatglm.cn/chatglm-operation/AlibabaPuHuiTi-3-55-Regular/file/a0/a055f93b5d | https://fileup.chatglm.cn/chatglm-operation/AlibabaPuHuiTi-3-55-Regular/file/89/8988f0ce3a | https://fileup.chatglm.cn/chatglm-operation/AlibabaPuHuiTi-3-55-Regular/file/54/54bcd7c6b7 | https://fileup.chatglm.cn/chatglm-operation/AlibabaPuHuiTi-3-55-Regular/file/98/98f1a2b7c1 | upload batch 3 |
|
||||
| 抖音美好体 DouyinSans | `"Douyin Sans"` | 400 | 标题 / 海报 / 活泼现代 | https://fileup.chatglm.cn/chatglm-operation/DouyinMeiHaoTi/file/30/30da93e844 | https://fileup.chatglm.cn/chatglm-operation/DouyinMeiHaoTi/file/3b/3b171d2f15 | https://fileup.chatglm.cn/chatglm-operation/DouyinMeiHaoTi/file/a3/a380b67b0f | https://fileup.chatglm.cn/chatglm-operation/DouyinMeiHaoTi/file/44/449109fb5c | upload batch 3 |
|
||||
| HarmonyOS Sans SC (Thin) | `"HarmonyOS Sans SC"` | 100 | 现代 / 工业 / 科技 / 鸿蒙生态 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Thin/file/00/00540c8656 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Thin/file/d1/d1f7d77c1e | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Thin/file/df/df02b19609 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Thin/file/37/37c8413537 | upload batch 3 |
|
||||
| HarmonyOS Sans SC (Light) | `"HarmonyOS Sans SC"` | 300 | 现代 / 工业 / 科技 / 鸿蒙生态 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Light/file/29/29bf93d0c0 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Light/file/20/20282efc71 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Light/file/8e/8edf18df66 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Light/file/3c/3c72b5376c | upload batch 3 |
|
||||
| HarmonyOS Sans SC (Regular) | `"HarmonyOS Sans SC"` | 400 | 现代 / 工业 / 科技 / 鸿蒙生态 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Regular/file/01/01c1e63b4b | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Regular/file/60/600b67ec1f | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Regular/file/01/01a87f4cf2 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Regular/file/b8/b864f26ac4 | upload batch 3 |
|
||||
| HarmonyOS Sans SC (Medium) | `"HarmonyOS Sans SC"` | 500 | 现代 / 工业 / 科技 / 鸿蒙生态 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Medium/file/3a/3a02b63f25 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Medium/file/7c/7c75e18d44 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Medium/file/31/3147c5bf0e | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Medium/file/c7/c70bc7fcd3 | upload batch 3 |
|
||||
| HarmonyOS Sans SC (Bold) | `"HarmonyOS Sans SC"` | 700 | 现代 / 工业 / 科技 / 鸿蒙生态 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Bold/file/7c/7cae48675b | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Bold/file/40/40cfd77cc2 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Bold/file/3f/3f31fa480d | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Bold/file/26/26a9ef75a3 | upload batch 3 |
|
||||
| HarmonyOS Sans SC (Black) | `"HarmonyOS Sans SC"` | 900 | 现代 / 工业 / 科技 / 鸿蒙生态 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Black/file/24/246d346cc6 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Black/file/70/70dad93690 | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Black/file/5f/5f6a76369a | https://fileup.chatglm.cn/chatglm-operation/HarmonyOS_Sans_SC_Black/file/2f/2f83a1c310 | upload batch 3 |
|
||||
| OPPO Sans (Regular) | `"OPPO Sans"` | 400 | 现代 / 移动端 / ColorOS | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Regular/file/43/43f018edfb | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Regular/file/2d/2dfba362f9 | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Regular/file/d0/d075041026 | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Regular/file/a2/a2375f3414 | upload batch 3 |
|
||||
| OPPO Sans (Medium) | `"OPPO Sans"` | 500 | 现代 / 移动端 / ColorOS | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Medium/file/a0/a0eba90561 | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Medium/file/7b/7b241f2dad | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Medium/file/b5/b55f3cb429 | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Medium/file/e3/e3bf64883a | upload batch 3 |
|
||||
| OPPO Sans (Bold) | `"OPPO Sans"` | 700 | 现代 / 移动端 / ColorOS | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Bold/file/49/496c8f2d63 | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Bold/file/c3/c332d5e576 | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Bold/file/bf/bfeea08fdc | https://fileup.chatglm.cn/chatglm-operation/OPPOSans-Bold/file/e3/e36dd64024 | upload batch 3 |
|
||||
| 狮尾四季春 Black / 狮尾四季春 Bold / 狮尾四季春 ExtraLight | `"Swei Spring CJK TC"` | 200, 700, 900 | 学术 / 严谨 / 出版，繁中/宋体标题 | 3 |
|
||||
| 字体圈欣意吉祥宋 | `"XinYi JiXiang Song"` | 400 | 学术 / 严谨 / 宋体标题 | 1 |
|
||||
| 初夏明朝体 Bold / 初夏明朝体 ExtraLight / 初夏明朝体 Heavy … | `"Early Summer Serif"` | 200, 300, 400, 500, 600, 700, 900 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | 7 |
|
||||
| 狮尾四季春糖 ExtraLight / 狮尾四季春糖 Light / 狮尾四季春糖 Medium … | `"Swei Spring Sugar CJK TC"` | 200, 300, 400, 500 | 文学 / 古典 / 优雅 / 感性，柔和宋体 | 4 |
|
||||
| 源流明体 Bold / 源流明体 ExtraLight / 源流明体 Heavy … | `"GenRyuMin JP"` | 200, 300, 400, 500, 600, 700, 900 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | 7 |
|
||||
| ORADANO 明朝体 | `"ORADANO Mincho"` | 400 | 文学 / 古典 / 感性标题 | 1 |
|
||||
| 新愚公沧桑体 | `"XinYuGong CangSang Ti"` | 400 | 文学 / 古典 / 感性标题 | 1 |
|
||||
| 霞鹜致宋 | `"LXGW ZhiSong"` | 400 | 文学 / 古典 / 感性标题 | 1 |
|
||||
| 飞花宋体 | `"Feihua Song"` | 400 | 文学 / 古典 / 感性标题 | 1 |
|
||||
| 一点明体 | `"I.Ming"` | 400 | 文学 / 古典 / 明朝体标题 | 1 |
|
||||
| 润植家康熙字典美化体 | `"RunZhiJia KangXi"` | 400 | 文学 / 古籍 / 传统标题 | 1 |
|
||||
| 润植家康熙字典美化体 清瘦款 | `"RunZhiJia KangXi Slim"` | 400 | 文学 / 古籍 / 传统标题 | 1 |
|
||||
| 一品启航体 | `"YiPin QiHang Ti"` | 400 | 标题 / 海报 | 1 |
|
||||
| 快看世界体 | `"Kuaikan Shijie Ti"` | 400 | 标题 / 海报 / 年轻内容 | 1 |
|
||||
| Leefont 蒙黑体 | `"Leefont MengHei"` | 400 | 标题 / 海报 / 强气质标题 | 1 |
|
||||
| 仓迹高德国妙黑 | `"Cangji Gaode Guomiao Hei"` | 400 | 标题 / 海报 / 强气质标题 | 1 |
|
||||
| 荆南俊俊体 | `"JingNan JunJunTi"` | 400 | 标题 / 海报 / 强气质标题 | 1 |
|
||||
| 庞门正道标题体 | `"PangMenZhengDao Title"` | 400 | 标题 / 海报 / 标语口号 | 1 |
|
||||
| 钉钉进步体 | `"DingTalk JinBuTi"` | 400 | 标题 / 海报 / 现代品牌 | 1 |
|
||||
| 阿里妈妈数黑体 | `"Alimama ShuHeiTi"` | 400 | 标题 / 海报 / 营销 / 产品发布 | 1 |
|
||||
| 字魂扁桃体 | `"ZiHun BianTao Ti"` | 400 | 标题 / 海报 / 装饰标题 | 1 |
|
||||
| 优设标题黑 | `"YouShe Title Black"` | 400 | 标题 / 海报 / 通用重标题 | 1 |
|
||||
| 字体传奇特战体 | `"ZiTiChuanQi TeZhan Ti"` | 400 | 现代 / 工业 / 特战锐角标题 | 1 |
|
||||
| Blix Bold / Blix ExtraLight / Blix Light … | `"Blix"` | 100, 200, 300, 400, 500, 600, 700 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | 7 |
|
||||
| Blix Text | `"Blix Text"` | 400 | 现代 / 工业 / 科技 / 商务，多字重正文/标题测试 | 1 |
|
||||
| 乡立方黑体 | `"XiangLiFang HeiTi"` | 400 | 现代 / 工业 / 科技标题 | 1 |
|
||||
| 创客贴金刚体 | `"Chuangkit KingKong"` | 400 | 现代 / 工业 / 科技标题 | 1 |
|
||||
| 德拉黑体 | `"Dela Gothic One"` | 400 | 现代 / 工业 / 科技标题 | 1 |
|
||||
| 标小智无界黑 | `"BiaoXiaoZhi WuJie Hei"` | 400 | 现代 / 工业 / 科技标题 | 1 |
|
||||
| 站酷酷黑体 | `"ZCOOL KuHei"` | 400 | 现代 / 工业 / 科技标题 | 1 |
|
||||
| Plix 普利士 Bold / Plix 普利士 ExtraLight / Plix 普利士 Light … | `"Plix"` | 100, 200, 300, 400, 500, 600, 700 | 现代 / 工业 / 科技，多字重标题/产品发布 | 7 |
|
||||
| Plix 普利士 Text | `"Plix Text"` | 400 | 现代 / 工业 / 科技，多字重正文/标题测试 | 1 |
|
||||
| 联盟起艺卢帅正锐黑体 | `"Lushuai Zhengrui Hei"` | 400 | 现代 / 工业 / 锐利标题 | 1 |
|
||||
|
||||
#### URL 查表
|
||||
|
||||
| font | css_family | font_weight | scene | common_hi | latin | punct | ext | source |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| ORADANO 明朝体 | `"ORADANO Mincho"` | 400 | 文学 / 古典 / 感性标题 | `https://fileup.chatglm.cn/chatglm-operation/OradanoGSRR/file/cf/cfca08647b` | `https://fileup.chatglm.cn/chatglm-operation/OradanoGSRR/file/96/9669e6fafc` | `https://fileup.chatglm.cn/chatglm-operation/OradanoGSRR/file/2e/2e080147a0` | `https://fileup.chatglm.cn/chatglm-operation/OradanoGSRR/file/77/7785a5869e` | previous fonts.md |
|
||||
| 一品启航体 | `"YiPin QiHang Ti"` | 400 | 标题 / 海报 | `https://fileup.chatglm.cn/chatglm-operation/一品启航体/file/76/76e29dad38` | `https://fileup.chatglm.cn/chatglm-operation/一品启航体/file/55/55e3ca4732` | `https://fileup.chatglm.cn/chatglm-operation/一品启航体/file/be/be931f15f9` | `https://fileup.chatglm.cn/chatglm-operation/一品启航体/file/7f/7f1a985296` | previous fonts.md |
|
||||
| 一点明体 | `"I.Ming"` | 400 | 文学 / 古典 / 明朝体标题 | `https://fileup.chatglm.cn/chatglm-operation/I.Ming-7.00/file/07/07ffdc1adc` | `https://fileup.chatglm.cn/chatglm-operation/I.Ming-7.00/file/f1/f1d05f12d2` | `https://fileup.chatglm.cn/chatglm-operation/I.Ming-7.00/file/0a/0a40bb960b` | `https://fileup.chatglm.cn/chatglm-operation/I.Ming-7.00/file/8a/8a0b4c63be` | previous fonts.md |
|
||||
| 乡立方黑体 | `"XiangLiFang HeiTi"` | 400 | 现代 / 工业 / 科技标题 | `https://fileup.chatglm.cn/chatglm-operation/乡立方黑体/file/56/56aba77493` | `https://fileup.chatglm.cn/chatglm-operation/乡立方黑体/file/5a/5ab39ea07b` | `https://fileup.chatglm.cn/chatglm-operation/乡立方黑体/file/0c/0cff80e0d0` | `https://fileup.chatglm.cn/chatglm-operation/乡立方黑体/file/91/91c932c78e` | previous fonts.md |
|
||||
| 字体传奇特战体 | `"ZiTiChuanQi TeZhan Ti"` | 400 | 现代 / 工业 / 特战锐角标题 | `https://fileup.chatglm.cn/chatglm-operation/字体传奇特战体/file/de/de9cb81c4c` | `https://fileup.chatglm.cn/chatglm-operation/字体传奇特战体/file/36/36f5e042e9` | `https://fileup.chatglm.cn/chatglm-operation/字体传奇特战体/file/65/651d795fc4` | `https://fileup.chatglm.cn/chatglm-operation/字体传奇特战体/file/11/11548cd4b7` | previous fonts.md |
|
||||
| 字体圈欣意吉祥宋 | `"XinYi JiXiang Song"` | 400 | 学术 / 严谨 / 宋体标题 | `https://fileup.chatglm.cn/chatglm-operation/字体圈欣意吉祥宋/file/c9/c9dddef6e8` | `https://fileup.chatglm.cn/chatglm-operation/字体圈欣意吉祥宋/file/af/aff9039041` | `https://fileup.chatglm.cn/chatglm-operation/字体圈欣意吉祥宋/file/31/313d305e30` | `https://fileup.chatglm.cn/chatglm-operation/字体圈欣意吉祥宋/file/34/3486a908c2` | previous fonts.md |
|
||||
| 字魂扁桃体 | `"ZiHun BianTao Ti"` | 400 | 标题 / 海报 / 装饰标题 | `https://fileup.chatglm.cn/chatglm-operation/字魂扁桃体/file/19/194181e6cb` | `https://fileup.chatglm.cn/chatglm-operation/字魂扁桃体/file/88/88cd111dd2` | `https://fileup.chatglm.cn/chatglm-operation/字魂扁桃体/file/01/01ccc9e7e1` | `https://fileup.chatglm.cn/chatglm-operation/字魂扁桃体/file/ca/caa5025441` | previous fonts.md |
|
||||
| 寒蝉正楷体 | `"ChillKai"` | 400 | 古籍 / 文言 / 引文 / 对话文 | `https://fileup.chatglm.cn/chatglm-operation/ChillKai/file/eb/ebda4b10a4` | `https://fileup.chatglm.cn/chatglm-operation/ChillKai/file/44/440fb6ae60` | `https://fileup.chatglm.cn/chatglm-operation/ChillKai/file/9d/9dea0f4c28` | `https://fileup.chatglm.cn/chatglm-operation/ChillKai/file/c2/c2ee5f953f` | previous fonts.md |
|
||||
| 庞门正道标题体 | `"PangMenZhengDao Title"` | 400 | 标题 / 海报 / 标语口号 | `https://fileup.chatglm.cn/chatglm-operation/PangMenZhengDaoBiaoTiTiMianFeiBan-2/file/5d/5d64a9bdcb` | `https://fileup.chatglm.cn/chatglm-operation/PangMenZhengDaoBiaoTiTiMianFeiBan-2/file/de/de6cbf790e` | `https://fileup.chatglm.cn/chatglm-operation/PangMenZhengDaoBiaoTiTiMianFeiBan-2/file/c4/c4600cb505` | `https://fileup.chatglm.cn/chatglm-operation/PangMenZhengDaoBiaoTiTiMianFeiBan-2/file/0b/0b92972246` | previous fonts.md |
|
||||
| 德拉黑体 | `"Dela Gothic One"` | 400 | 现代 / 工业 / 科技标题 | `https://fileup.chatglm.cn/chatglm-operation/DelaGothicOne-Regular/file/18/1806c3702f` | `https://fileup.chatglm.cn/chatglm-operation/DelaGothicOne-Regular/file/79/79e72e7dc7` | `https://fileup.chatglm.cn/chatglm-operation/DelaGothicOne-Regular/file/01/011df6fd58` | `https://fileup.chatglm.cn/chatglm-operation/DelaGothicOne-Regular/file/e9/e9bc1db661` | previous fonts.md |
|
||||
| 快看世界体 | `"Kuaikan Shijie Ti"` | 400 | 标题 / 海报 / 年轻内容 | `https://fileup.chatglm.cn/chatglm-operation/kuaikanshijieti/file/34/34f1113cd5` | `https://fileup.chatglm.cn/chatglm-operation/kuaikanshijieti/file/87/87aebfd38a` | `https://fileup.chatglm.cn/chatglm-operation/kuaikanshijieti/file/ed/ed4819ef67` | `https://fileup.chatglm.cn/chatglm-operation/kuaikanshijieti/file/19/190ff5cb5e` | previous fonts.md |
|
||||
| 思源赢宋 | `"CorpSrcWinSong Slim"` | 400 | 学术 / 严谨 / 出版标题 | `https://fileup.chatglm.cn/chatglm-operation/CorpSrcWinSong-slim/file/2e/2e88d410e7` | `https://fileup.chatglm.cn/chatglm-operation/CorpSrcWinSong-slim/file/70/701fb6cf26` | `https://fileup.chatglm.cn/chatglm-operation/CorpSrcWinSong-slim/file/01/01d5854ec6` | `https://fileup.chatglm.cn/chatglm-operation/CorpSrcWinSong-slim/file/06/065e0e26bb` | previous fonts.md |
|
||||
| 新愚公沧桑体 | `"XinYuGong CangSang Ti"` | 400 | 文学 / 古典 / 感性标题 | `https://fileup.chatglm.cn/chatglm-operation/新愚公沧桑体/file/4c/4cbdf91141` | `https://fileup.chatglm.cn/chatglm-operation/新愚公沧桑体/file/1b/1b9de889cf` | `https://fileup.chatglm.cn/chatglm-operation/新愚公沧桑体/file/d6/d67a6cf51b` | `https://fileup.chatglm.cn/chatglm-operation/新愚公沧桑体/file/df/dffb5f4b32` | previous fonts.md |
|
||||
| 朱雀仿宋 | `"Zhuque Fangsong"` | 400 | 学术 / 严谨 / 仿宋语境 | `https://fileup.chatglm.cn/chatglm-operation/朱雀仿宋/file/73/739649f27b` | `https://fileup.chatglm.cn/chatglm-operation/朱雀仿宋/file/8b/8b0607dcf5` | `https://fileup.chatglm.cn/chatglm-operation/朱雀仿宋/file/f9/f9508b25a5` | `https://fileup.chatglm.cn/chatglm-operation/朱雀仿宋/file/34/349ba93dfa` | previous fonts.md |
|
||||
| 江西拙楷 | `"Jiangxi ZhuoKai"` | 400 | 古籍 / 文言 / 拙朴楷体 | `https://fileup.chatglm.cn/chatglm-operation/江西拙楷2.0/file/30/30489bcd64` | `https://fileup.chatglm.cn/chatglm-operation/江西拙楷2.0/file/a5/a5576e755f` | `https://fileup.chatglm.cn/chatglm-operation/江西拙楷2.0/file/42/42ca2970b1` | `https://fileup.chatglm.cn/chatglm-operation/江西拙楷2.0/file/dd/ddbe3161a0` | previous fonts.md |
|
||||
| 润植家康熙字典美化体 | `"RunZhiJia KangXi"` | 400 | 文学 / 古籍 / 传统标题 | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体/file/fe/fe7aa424c4` | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体/file/ee/ee8b8f834b` | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体/file/5b/5bdb2beb2a` | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体/file/60/60b82d3143` | previous fonts.md |
|
||||
| 润植家康熙字典美化体 清瘦款 | `"RunZhiJia KangXi Slim"` | 400 | 文学 / 古籍 / 传统标题 | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体-清瘦款/file/20/2099cd5e83` | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体-清瘦款/file/5c/5cfb8dbdf6` | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体-清瘦款/file/39/3964fcafc8` | `https://fileup.chatglm.cn/chatglm-operation/润植家康熙字典美化体-清瘦款/file/e6/e6c2d94792` | previous fonts.md |
|
||||
| 站酷酷黑体 | `"ZCOOL KuHei"` | 400 | 现代 / 工业 / 科技标题 | `https://fileup.chatglm.cn/chatglm-operation/站酷酷黑体/file/ea/eadd08db72` | `https://fileup.chatglm.cn/chatglm-operation/站酷酷黑体/file/13/13dd379397` | `https://fileup.chatglm.cn/chatglm-operation/站酷酷黑体/file/4b/4bde15434e` | `https://fileup.chatglm.cn/chatglm-operation/站酷酷黑体/file/80/80b5c54b0d` | previous fonts.md |
|
||||
| 联盟起艺卢帅正锐黑体 | `"Lushuai Zhengrui Hei"` | 400 | 现代 / 工业 / 锐利标题 | `https://fileup.chatglm.cn/chatglm-operation/联盟起艺卢帅正锐黑体/file/4f/4f37900ffc` | `https://fileup.chatglm.cn/chatglm-operation/联盟起艺卢帅正锐黑体/file/98/9840da1aeb` | `https://fileup.chatglm.cn/chatglm-operation/联盟起艺卢帅正锐黑体/file/70/70a1db7c91` | `https://fileup.chatglm.cn/chatglm-operation/联盟起艺卢帅正锐黑体/file/c2/c2af99b3fc` | previous fonts.md |
|
||||
| 荆南俊俊体 | `"JingNan JunJunTi"` | 400 | 标题 / 海报 / 强气质标题 | `https://fileup.chatglm.cn/chatglm-operation/JingNanJunJunTi-JinNanJunJunTi-Bold-2/file/cb/cbb8549ae0` | `https://fileup.chatglm.cn/chatglm-operation/JingNanJunJunTi-JinNanJunJunTi-Bold-2/file/ab/abd1273106` | `https://fileup.chatglm.cn/chatglm-operation/JingNanJunJunTi-JinNanJunJunTi-Bold-2/file/f1/f13c84fb94` | `https://fileup.chatglm.cn/chatglm-operation/JingNanJunJunTi-JinNanJunJunTi-Bold-2/file/44/44a4205932` | previous fonts.md |
|
||||
| 钉钉进步体 | `"DingTalk JinBuTi"` | 400 | 标题 / 海报 / 现代品牌 | `https://fileup.chatglm.cn/chatglm-operation/DingTalkJinBuTi-Regular/file/f7/f76dac6937` | `https://fileup.chatglm.cn/chatglm-operation/DingTalkJinBuTi-Regular/file/56/565cc41a96` | `https://fileup.chatglm.cn/chatglm-operation/DingTalkJinBuTi-Regular/file/ef/ef81576a19` | `https://fileup.chatglm.cn/chatglm-operation/DingTalkJinBuTi-Regular/file/84/84e1509a2c` | previous fonts.md |
|
||||
| 阿里妈妈数黑体 | `"Alimama ShuHeiTi"` | 400 | 标题 / 海报 / 营销 / 产品发布 | `https://fileup.chatglm.cn/chatglm-operation/AlimamaShuHeiTi-Bold/file/cb/cbfb7e4458` | `https://fileup.chatglm.cn/chatglm-operation/AlimamaShuHeiTi-Bold/file/61/61711255c2` | `https://fileup.chatglm.cn/chatglm-operation/AlimamaShuHeiTi-Bold/file/9b/9b1d007c76` | `https://fileup.chatglm.cn/chatglm-operation/AlimamaShuHeiTi-Bold/file/c5/c51379dac8` | previous fonts.md |
|
||||
| 飞花宋体 | `"Feihua Song"` | 400 | 文学 / 古典 / 感性标题 | `https://fileup.chatglm.cn/chatglm-operation/飞花宋体/file/f0/f0e72eccf3` | `https://fileup.chatglm.cn/chatglm-operation/飞花宋体/file/5b/5b11746893` | `https://fileup.chatglm.cn/chatglm-operation/飞花宋体/file/d2/d21c0e3479` | `https://fileup.chatglm.cn/chatglm-operation/飞花宋体/file/ea/ea8ab8cd6f` | previous fonts.md |
|
||||
| Blix Bold | `"Blix"` | 700 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-Bold/file/26/262abdf55d` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Bold/file/04/041fe34200` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Bold/file/a2/a249ce7687` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Bold/file/ae/aec610d95c` | fonts_upload_result2.csv |
|
||||
| Blix ExtraLight | `"Blix"` | 200 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-ExtraLight/file/21/2193185438` | `https://fileup.chatglm.cn/chatglm-operation/Blix-ExtraLight/file/45/45edc00a9b` | `https://fileup.chatglm.cn/chatglm-operation/Blix-ExtraLight/file/9c/9cfecb9691` | `https://fileup.chatglm.cn/chatglm-operation/Blix-ExtraLight/file/ff/ffe53dfa43` | fonts_upload_result2.csv |
|
||||
| Blix Light | `"Blix"` | 300 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-Light/file/3f/3f0d54a8cb` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Light/file/f0/f04181a3ef` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Light/file/35/35033b633c` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Light/file/56/563ddfdb03` | fonts_upload_result2.csv |
|
||||
| Blix Medium | `"Blix"` | 500 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-Medium/file/2d/2de1e9a8ba` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Medium/file/b1/b1309f5393` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Medium/file/b7/b73c9a408a` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Medium/file/38/38887b9641` | fonts_upload_result2.csv |
|
||||
| Blix Regular | `"Blix"` | 400 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-Regular/file/5c/5cba7280ac` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Regular/file/26/26225968c9` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Regular/file/07/074ef94072` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Regular/file/29/299afaba9c` | fonts_upload_result2.csv |
|
||||
| Blix SemiBold | `"Blix"` | 600 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-SemiBold/file/5e/5efb6f641f` | `https://fileup.chatglm.cn/chatglm-operation/Blix-SemiBold/file/dc/dc8a790bd9` | `https://fileup.chatglm.cn/chatglm-operation/Blix-SemiBold/file/2c/2c84409bd6` | `https://fileup.chatglm.cn/chatglm-operation/Blix-SemiBold/file/88/8851c60de7` | fonts_upload_result2.csv |
|
||||
| Blix Text | `"Blix Text"` | 400 | 现代 / 工业 / 科技 / 商务，多字重正文/标题测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-Text/file/0e/0e4aa0cd41` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Text/file/4a/4a4b2170ed` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Text/file/cd/cd0c4f3f0e` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Text/file/ed/ed3abc7940` | fonts_upload_result2.csv |
|
||||
| Blix Thin | `"Blix"` | 100 | 现代 / 工业 / 科技 / 商务，多字重标题/界面测试 | `https://fileup.chatglm.cn/chatglm-operation/Blix-Thin/file/c5/c576803cdd` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Thin/file/66/665334cd4c` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Thin/file/ba/bad1b25e87` | `https://fileup.chatglm.cn/chatglm-operation/Blix-Thin/file/83/833afaf19e` | fonts_upload_result2.csv |
|
||||
| 初夏明朝体 Bold | `"Early Summer Serif"` | 700 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Bold/file/9e/9e7a93c0d4` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Bold/file/ad/adfab8bd66` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Bold/file/1d/1d690160e4` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Bold/file/24/241fb12f1b` | fonts_upload_result2.csv |
|
||||
| 初夏明朝体 ExtraLight | `"Early Summer Serif"` | 200 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-ExtraLight/file/cb/cb9f3dbb30` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-ExtraLight/file/11/1126df09ff` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-ExtraLight/file/a1/a15fd9a2be` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-ExtraLight/file/df/dfc81e40b7` | fonts_upload_result2.csv |
|
||||
| 初夏明朝体 Heavy | `"Early Summer Serif"` | 900 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Heavy/file/bc/bcbd45c849` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Heavy/file/5a/5a7f10c952` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Heavy/file/2a/2a4268ce41` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Heavy/file/28/28f748319f` | fonts_upload_result2.csv |
|
||||
| 初夏明朝体 Light | `"Early Summer Serif"` | 300 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Light/file/6d/6d80ac384b` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Light/file/81/81278898c7` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Light/file/19/19c59b5e10` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Light/file/f2/f254f3ee53` | fonts_upload_result2.csv |
|
||||
| 初夏明朝体 Medium | `"Early Summer Serif"` | 500 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Medium/file/2d/2dd6de2b01` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Medium/file/60/60ada71088` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Medium/file/82/822f64e64e` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Medium/file/73/7335b8f693` | fonts_upload_result2.csv |
|
||||
| 初夏明朝体 Regular | `"Early Summer Serif"` | 400 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Regular/file/ff/ff27654498` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Regular/file/36/36d455145e` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Regular/file/cf/cf9bea1ab5` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-Regular/file/90/9088bd3069` | fonts_upload_result2.csv |
|
||||
| 初夏明朝体 SemiBold | `"Early Summer Serif"` | 600 | 文学 / 古典 / 优雅 / 感性，明朝体标题/短文 | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-SemiBold/file/63/6378c94799` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-SemiBold/file/8e/8eb81f0cd1` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-SemiBold/file/20/20aca09499` | `https://fileup.chatglm.cn/chatglm-operation/EarlySummerSerif-SemiBold/file/a1/a12ddfa661` | fonts_upload_result2.csv |
|
||||
| 源流明体 Bold | `"GenRyuMin JP"` | 700 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Bold-2/file/c4/c4fca8acfc` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Bold-2/file/fd/fd97bd3c57` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Bold-2/file/ac/acb00d888a` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Bold-2/file/30/303e02361e` | fonts_upload_result2.csv |
|
||||
| 源流明体 ExtraLight | `"GenRyuMin JP"` | 200 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-ExtraLight-3/file/8d/8d28bc4d1a` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-ExtraLight-3/file/58/586b40f864` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-ExtraLight-3/file/35/357938f213` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-ExtraLight-3/file/9c/9ca7d004e4` | fonts_upload_result2.csv |
|
||||
| 源流明体 Heavy | `"GenRyuMin JP"` | 900 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Heavy-4/file/42/42ee49d982` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Heavy-4/file/5b/5bade94110` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Heavy-4/file/e4/e4a56d24bb` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Heavy-4/file/57/573abe53c5` | fonts_upload_result2.csv |
|
||||
| 源流明体 Light | `"GenRyuMin JP"` | 300 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Light-5/file/7b/7b804e9f2e` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Light-5/file/a3/a3a78821ad` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Light-5/file/32/32bce1ed1e` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Light-5/file/b2/b22d1d9ad0` | fonts_upload_result2.csv |
|
||||
| 源流明体 Medium | `"GenRyuMin JP"` | 500 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Medium-6/file/00/00d40483a8` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Medium-6/file/9e/9e7ed7bb98` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Medium-6/file/de/de1074fa56` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Medium-6/file/32/32863e2ca5` | fonts_upload_result2.csv |
|
||||
| 源流明体 Regular | `"GenRyuMin JP"` | 400 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Regular-7/file/06/0615f8acbd` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Regular-7/file/11/11f8f60de4` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Regular-7/file/ee/ee6452c6e8` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-Regular-7/file/6c/6c84952724` | fonts_upload_result2.csv |
|
||||
| 源流明体 SemiBold | `"GenRyuMin JP"` | 600 | 文学 / 古典 / 引文 / 明朝体；日系/传统气质 | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-SemiBold-8/file/fa/faa4062b63` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-SemiBold-8/file/c8/c8ad6ba144` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-SemiBold-8/file/2a/2a2430a174` | `https://fileup.chatglm.cn/chatglm-operation/GenRyuMinJP-SemiBold-8/file/86/862003923c` | fonts_upload_result2.csv |
|
||||
| Leefont 蒙黑体 | `"Leefont MengHei"` | 400 | 标题 / 海报 / 强气质标题 | `https://fileup.chatglm.cn/chatglm-operation/Leefont蒙黑体/file/44/44fa456e39` | `https://fileup.chatglm.cn/chatglm-operation/Leefont蒙黑体/file/43/43d9dac7ed` | `https://fileup.chatglm.cn/chatglm-operation/Leefont蒙黑体/file/86/86d7fc1b56` | `https://fileup.chatglm.cn/chatglm-operation/Leefont蒙黑体/file/f1/f1bccaa444` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 Bold | `"Plix"` | 700 | 现代 / 工业 / 科技，多字重标题/产品发布 | `https://fileup.chatglm.cn/chatglm-operation/Plix-Bold/file/20/20ab9b228b` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Bold/file/ff/ff5ad6c35c` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Bold/file/7f/7f266e9ab8` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Bold/file/72/72ea6eba65` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 ExtraLight | `"Plix"` | 200 | 现代 / 工业 / 科技，多字重标题/产品发布 | `https://fileup.chatglm.cn/chatglm-operation/Plix-ExtraLight/file/44/44ea3ad18c` | `https://fileup.chatglm.cn/chatglm-operation/Plix-ExtraLight/file/de/de382861e8` | `https://fileup.chatglm.cn/chatglm-operation/Plix-ExtraLight/file/4f/4f33b32eab` | `https://fileup.chatglm.cn/chatglm-operation/Plix-ExtraLight/file/25/253ac4035a` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 Light | `"Plix"` | 300 | 现代 / 工业 / 科技，多字重标题/产品发布 | `https://fileup.chatglm.cn/chatglm-operation/Plix-Light/file/0a/0a41f59145` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Light/file/56/56ca45cd72` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Light/file/9e/9e0d314ed6` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Light/file/32/32fc493bde` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 Medium | `"Plix"` | 500 | 现代 / 工业 / 科技，多字重标题/产品发布 | `https://fileup.chatglm.cn/chatglm-operation/Plix-Medium/file/99/99735c84dd` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Medium/file/f2/f2062f9763` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Medium/file/08/084584f23a` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Medium/file/3e/3e7d5e1613` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 Regular | `"Plix"` | 400 | 现代 / 工业 / 科技，多字重标题/产品发布 | `https://fileup.chatglm.cn/chatglm-operation/Plix-Regular/file/30/30e51f7096` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Regular/file/bd/bd02f2a6aa` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Regular/file/4a/4a12aff53e` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Regular/file/36/36e4af189f` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 SemiBold | `"Plix"` | 600 | 现代 / 工业 / 科技，多字重标题/产品发布 | `https://fileup.chatglm.cn/chatglm-operation/Plix-SemiBold/file/53/534febe072` | `https://fileup.chatglm.cn/chatglm-operation/Plix-SemiBold/file/95/95c63a7834` | `https://fileup.chatglm.cn/chatglm-operation/Plix-SemiBold/file/9c/9c42ed77cb` | `https://fileup.chatglm.cn/chatglm-operation/Plix-SemiBold/file/70/706b68a842` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 Text | `"Plix Text"` | 400 | 现代 / 工业 / 科技，多字重正文/标题测试 | `https://fileup.chatglm.cn/chatglm-operation/Plix-Text/file/f5/f5cae38ed5` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Text/file/be/bebc157f30` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Text/file/bc/bc36d5dc10` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Text/file/f1/f1a08dd5ab` | fonts_upload_result2.csv |
|
||||
| Plix 普利士 Thin | `"Plix"` | 100 | 现代 / 工业 / 科技，多字重标题/产品发布 | `https://fileup.chatglm.cn/chatglm-operation/Plix-Thin/file/f5/f5b452a7e5` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Thin/file/27/27d434dbf5` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Thin/file/88/887ee1fc9c` | `https://fileup.chatglm.cn/chatglm-operation/Plix-Thin/file/b6/b6c12b4ab2` | fonts_upload_result2.csv |
|
||||
| 演示春风楷 | `"Slide Chunfeng Kai"` | 400 | 古籍 / 文言 / 引文 / 对话文，楷体标题 | `https://fileup.chatglm.cn/chatglm-operation/Slidechunfeng-Regular/file/e7/e7a2a98669` | `https://fileup.chatglm.cn/chatglm-operation/Slidechunfeng-Regular/file/7e/7e76141d49` | `https://fileup.chatglm.cn/chatglm-operation/Slidechunfeng-Regular/file/95/95292e23a0` | `https://fileup.chatglm.cn/chatglm-operation/Slidechunfeng-Regular/file/c5/c5aaf20d76` | fonts_upload_result2.csv |
|
||||
| 狮尾四季春 Black | `"Swei Spring CJK TC"` | 900 | 学术 / 严谨 / 出版，繁中/宋体标题 | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Black/file/74/745f6a117b` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Black/file/b5/b59271fb3a` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Black/file/c0/c0798484ce` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Black/file/2e/2ec18b32e7` | fonts_upload_result2.csv |
|
||||
| 狮尾四季春 Bold | `"Swei Spring CJK TC"` | 700 | 学术 / 严谨 / 出版，繁中/宋体标题 | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Bold/file/2c/2c1e22d582` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Bold/file/f8/f81c815d41` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Bold/file/8f/8fbc87b012` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-Bold/file/46/46bdb3bcac` | fonts_upload_result2.csv |
|
||||
| 狮尾四季春 ExtraLight | `"Swei Spring CJK TC"` | 200 | 学术 / 严谨 / 出版，繁中/宋体标题 | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-ExtraLight/file/ea/eae48f5558` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-ExtraLight/file/34/342b7933b1` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-ExtraLight/file/3f/3f04f2cef8` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringCJKtc-ExtraLight/file/c9/c97f798620` | fonts_upload_result2.csv |
|
||||
| 狮尾四季春糖 ExtraLight | `"Swei Spring Sugar CJK TC"` | 200 | 文学 / 古典 / 优雅 / 感性，柔和宋体 | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-ExtraLight/file/9e/9e740cfb8a` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-ExtraLight/file/7f/7ff7baed53` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-ExtraLight/file/e7/e72980f785` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-ExtraLight/file/2e/2e43afce54` | fonts_upload_result2.csv |
|
||||
| 狮尾四季春糖 Light | `"Swei Spring Sugar CJK TC"` | 300 | 文学 / 古典 / 优雅 / 感性，柔和宋体 | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Light/file/fb/fb2ea95fbd` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Light/file/48/480090eeb1` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Light/file/37/37aa2e72a7` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Light/file/4e/4ef78056ed` | fonts_upload_result2.csv |
|
||||
| 狮尾四季春糖 Medium | `"Swei Spring Sugar CJK TC"` | 500 | 文学 / 古典 / 优雅 / 感性，柔和宋体 | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Medium/file/ff/ffc7d6cc4e` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Medium/file/c7/c7e930b33f` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Medium/file/4d/4d33bd4f85` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Medium/file/09/09c3f1e9ac` | fonts_upload_result2.csv |
|
||||
| 狮尾四季春糖 Regular | `"Swei Spring Sugar CJK TC"` | 400 | 文学 / 古典 / 优雅 / 感性，柔和宋体 | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Regular/file/9b/9b45083ab4` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Regular/file/d1/d121306867` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Regular/file/00/002363c227` | `https://fileup.chatglm.cn/chatglm-operation/SweiSpringSugarCJKtc-Regular/file/a6/a6a6836ee9` | fonts_upload_result2.csv |
|
||||
| 霞鹜致宋 | `"LXGW ZhiSong"` | 400 | 文学 / 古典 / 感性标题 | `https://fileup.chatglm.cn/chatglm-operation/xiawuzhisong/file/e3/e3ef8f1238` | `https://fileup.chatglm.cn/chatglm-operation/xiawuzhisong/file/c3/c3ffb778a6` | `https://fileup.chatglm.cn/chatglm-operation/xiawuzhisong/file/a9/a99e73508a` | `https://fileup.chatglm.cn/chatglm-operation/xiawuzhisong/file/94/94ba9251ce` | fonts_upload_result2.csv |
|
||||
| 仓迹高德国妙黑 | `"Cangji Gaode Guomiao Hei"` | 400 | 标题 / 海报 / 强气质标题 | `https://fileup.chatglm.cn/chatglm-operation/仓迹高德国妙黑/file/54/546b95a0d0` | `https://fileup.chatglm.cn/chatglm-operation/仓迹高德国妙黑/file/7f/7f2986f888` | `https://fileup.chatglm.cn/chatglm-operation/仓迹高德国妙黑/file/74/748bbd6371` | `https://fileup.chatglm.cn/chatglm-operation/仓迹高德国妙黑/file/3f/3f52c4766f` | fonts_upload_result2.csv |
|
||||
| 优设标题黑 | `"YouShe Title Black"` | 400 | 标题 / 海报 / 通用重标题 | `https://fileup.chatglm.cn/chatglm-operation/优设标题黑/file/24/24ecaa8f59` | `https://fileup.chatglm.cn/chatglm-operation/优设标题黑/file/93/930ab5a2bf` | `https://fileup.chatglm.cn/chatglm-operation/优设标题黑/file/87/8794e267e0` | `https://fileup.chatglm.cn/chatglm-operation/优设标题黑/file/90/90eab1b431` | fonts_upload_result2.csv |
|
||||
| 创客贴金刚体 | `"Chuangkit KingKong"` | 400 | 现代 / 工业 / 科技标题 | `https://fileup.chatglm.cn/chatglm-operation/创客贴金刚体/file/95/95d2df8fbd` | `https://fileup.chatglm.cn/chatglm-operation/创客贴金刚体/file/fd/fd1829b5f1` | `https://fileup.chatglm.cn/chatglm-operation/创客贴金刚体/file/0f/0f474674d1` | `https://fileup.chatglm.cn/chatglm-operation/创客贴金刚体/file/1e/1ed6b8865c` | fonts_upload_result2.csv |
|
||||
| 标小智无界黑 | `"BiaoXiaoZhi WuJie Hei"` | 400 | 现代 / 工业 / 科技标题 | `https://fileup.chatglm.cn/chatglm-operation/标小智无界黑/file/3c/3c8fed3f61` | `https://fileup.chatglm.cn/chatglm-operation/标小智无界黑/file/17/173c9801ef` | `https://fileup.chatglm.cn/chatglm-operation/标小智无界黑/file/7b/7b7b634392` | `https://fileup.chatglm.cn/chatglm-operation/标小智无界黑/file/14/1419fd9c1b` | fonts_upload_result2.csv |
|
||||
|
||||
### 2.4 备查：CDN / 系统字体加载方式
|
||||
|
||||
> 关键规则：在 `font-family` 里写了命名字体，就必须同时加载它（用 `<link>` 引 CDN，或用 `@font-face` 自托管）。
|
||||
> 只写名字不加载 = 没用，浏览器会 fallback 成默认字体。拿不准就优先 A 类有公共 CDN 的字体。
|
||||
|
||||
#### 中文字体
|
||||
|
||||
| 字体 | 类型 | 加载方式 |
|
||||
|---|---|---|
|
||||
| 思源黑体 Source Han Sans SC | 黑 | A：`https://cdn.jsdelivr.net/npm/cn-fontsource-source-han-sans-sc-vf/font.css`；也可走自托管切片 → 见 § 1 |
|
||||
| 思源宋体 Source Han Serif SC | 宋 | A：`https://cdn.jsdelivr.net/npm/cn-fontsource-source-han-serif-sc-vf/font.css`；也可走自托管切片 → 见 § 1 |
|
||||
| Noto Sans SC | 黑 | A：`https://cdn.jsdelivr.net/npm/cn-fontsource-source-han-sans-sc-vf/font.css`（国内 jsDelivr，思源黑同源；原 Google：`Noto+Sans+SC`） |
|
||||
| Noto Serif SC | 宋 | A：`https://cdn.jsdelivr.net/npm/cn-fontsource-source-han-serif-sc-vf/font.css`（国内 jsDelivr，思源宋同源；原 Google：`Noto+Serif+SC`） |
|
||||
| 霞鹜文楷 LXGW WenKai | 楷 | A：`https://cdn.jsdelivr.net/npm/cn-fontsource-lxgw-wen-kai-screen-r/font.css`（国内 jsDelivr；原 Google：`fonts.googleapis.com/css2?family=LXGW+WenKai`） |
|
||||
| 得意黑 Smiley Sans | 标题/黑 | A：`https://cdn.jsdelivr.net/npm/cn-fontsource-smiley-sans-oblique-regular/font.css` |
|
||||
| 钉钉进步体 | 标题/黑 | A：`https://cdn.jsdelivr.net/npm/cn-fontsource-ding-talk-jin-bu-ti-regular/font.css`；B：OSS 切片 → 见 § 1.4 |
|
||||
| BIZ UDGothic / UDMincho | 黑/宋（日文为主，简体部分字符会 fallback） | A：`https://fonts.googleapis.com/css2?family=BIZ+UDGothic`（或 `BIZ+UDMincho`）（Google CDN，国内加载可能慢；日文为主的边缘字体，按需使用） |
|
||||
| MiSans | 黑 | A：`https://cdn.jsdelivr.net/npm/misans@4.1.0/lib/Normal/MiSans-Regular.min.css`（按字重换 Medium/Bold） |
|
||||
| HarmonyOS Sans | 黑 | B:OSS；切片见 § 2.3（Thin–Black 全字重）|
|
||||
| 阿里巴巴普惠体 | 黑 | B:OSS；切片见 § 2.3 |
|
||||
| OPPO Sans | 黑 | B:OSS；切片见 § 2.3（Regular/Medium/Bold）|
|
||||
| 抖音美好体 DouyinSans | 标题/黑 | B:OSS；切片见 § 2.3 |
|
||||
| 阿里妈妈数黑体 | 标题/黑 | B：OSS 切片 → 见 § 1.4 |
|
||||
| 其他已上传测试字体 | 标题/宋/楷/仿宋 | 见 § 1.4；仅用于标题、封面、海报、社媒卡片或特定测试，不默认用于正文 |
|
||||
|
||||
#### 拉丁/西文字体（中英混排时给 Latin 部分；比系统默认更有性格）
|
||||
|
||||
> 这些都不是系统字体，必须加载。**不要默认用 Inter**（AI 烂大街，见 `anti-ai-slop.md`）——优先下面这些。
|
||||
|
||||
| 字体 | 风格 | Web 加载 |
|
||||
|---|---|---|
|
||||
| Source Sans 3 | 无衬线，中性专业（思源黑的拉丁同源感） | `https://cdn.jsdelivr.net/npm/@fontsource/source-sans-3/index.css`（国内 jsDelivr） |
|
||||
| Source Serif 4 | 衬线，编辑/出版感（配思源宋） | `https://cdn.jsdelivr.net/npm/@fontsource/source-serif-4/index.css`（国内 jsDelivr） |
|
||||
| Crimson Pro | 衬线，文学/优雅 | `https://cdn.jsdelivr.net/npm/@fontsource/crimson-pro/index.css`（国内 jsDelivr） |
|
||||
| EB Garamond | 衬线，古典/书卷 | `https://cdn.jsdelivr.net/npm/@fontsource/eb-garamond/index.css`（国内 jsDelivr） |
|
||||
|
||||
### 2.5 组装 font-family 栈（选字和落 CSS 之间的最后一步，最容易出错）
|
||||
|
||||
选完字体后，写 `font-family` 时最常见的错误是**漏掉 CJK 字体那一环**——比如选了「Inter 英文 + 系统中文」，却写成
|
||||
`font-family: 'Inter', system-ui, sans-serif`，中文直接跳到 system-ui，渲染不可控。
|
||||
|
||||
**硬规则：任何含中文的页面，`font-family` 里必须显式出现一个 CJK 字体名。Latin 字体后面绝不能直接接 `system-ui`。**
|
||||
|
||||
按"中英是否用不同字体"分两种，直接照模板填：
|
||||
|
||||
```css
|
||||
/* 情形 A：中英用同一字体 / 不特别指定英文字体 → CJK 字体在最前 */
|
||||
font-family: '{CJK字体}', system-ui, sans-serif;
|
||||
/* 例： */
|
||||
font-family: 'Noto Sans SC', 'PingFang SC', 'Microsoft YaHei', system-ui, sans-serif;
|
||||
|
||||
/* 情形 B：中英用不同字体（指定了 Latin display 字体）→ Latin 在前，但 CJK 必须紧跟 */
|
||||
font-family: '{Latin字体}', '{CJK字体}', 'PingFang SC', 'Microsoft YaHei', system-ui, sans-serif;
|
||||
/* 例： */
|
||||
font-family: 'Inter', 'Noto Sans SC', 'PingFang SC', 'Microsoft YaHei', system-ui, sans-serif;
|
||||
```
|
||||
|
||||
**反例（不要这样写）**：
|
||||
```css
|
||||
font-family: 'Inter', system-ui, sans-serif; /* ✗ 中文 fallback 到 system-ui，不可控 */
|
||||
font-family: 'Helvetica', 'PingFang SC'; /* ✗ 英文在前会抢走中文标点(破折号/引号下沉) */
|
||||
```
|
||||
|
||||
**和"中文排英文前"铁律的关系**（两种策略，别混）：
|
||||
- **情形 A（同字体）**：CJK 在前——这就是"中文排英文前"，避免英文字体抢走中文标点字形。
|
||||
- **情形 B（分字体）**：Latin 在前但 CJK 必须紧跟——靠浏览器按字符 fallback，Latin 字体只渲染它有的拉丁字符，中文落到紧跟的 CJK 字体。这种情形若担心标点被 Latin 抢走，用 `unicode-range` 把 Latin 限定在拉丁码位：
|
||||
|
||||
```css
|
||||
@font-face {
|
||||
font-family: "Inter Latin";
|
||||
src: local("Inter");
|
||||
unicode-range: U+0000-024F; /* 只渲染拉丁，标点/中文留给 CJK */
|
||||
}
|
||||
body { font-family: "Inter Latin", "Noto Sans SC", "PingFang SC", system-ui, sans-serif; }
|
||||
```
|
||||
|
||||
标点下沉/破折号问题详见 `punctuation.md` 破折号专题。
|
||||
|
||||
## 三、原则自检（选完字体后对照检查）
|
||||
|
||||
### 3.1 字面率（Face Ratio）选择结论
|
||||
|
||||
- **字面率约 95%**（思源黑、Noto Sans CJK、HarmonyOS Sans、MiSans、阿里普惠体等）：屏幕首选——大字面率在小字号下仍清晰。
|
||||
- **字面率约 85%**（思源宋、霞鹜文楷、传统宋/楷）：印刷、长文阅读、文学/古籍气质首选——视觉松弛、易长时间阅读。
|
||||
- **不要混搭悬殊字面率的字体**（如 95% 黑体 + 85% 宋体）做同等级标题/正文，视觉重量会断。
|
||||
|
||||
### 3.2 通用搭配原则
|
||||
|
||||
- 一个项目 ≤ 2 个字体家族；优先一家族多字重，靠粗细和字号拉层级。
|
||||
- 同一设计最多 1 个强展示字体；正文回到高可读字体。
|
||||
- 标题/海报字体强但必须服务主题，不要只为"显眼"。
|
||||
- 候选清单的顺序不是优先级；按内容气质、可读性、媒介选择。
|
||||
|
||||
### 3.3 绝对避免
|
||||
|
||||
正文/严肃内容禁用：
|
||||
- ❌ 华文彩云、华文琥珀、华文行楷
|
||||
- ❌ 任何带阴影/3D/塑料质感的"特效字体"
|
||||
- ❌ 装饰性毛笔字体（如造字工房悦圆系列做正文）
|
||||
- ❌ 游戏字体（暗黑、星际等）做长文
|
||||
- ❌ 楷体做现代长文正文（**儿童读物 / 教育例外**）—— 楷体笔画细易疲劳
|
||||
- ❌ 仿宋体做大段现代正文（**公文例外**）—— 同上
|
||||
- ⚠️ 中易宋体、中易仿宋、旧版微软雅黑：破折号/省略号可能断开或下沉，Web 与长文场景需测试
|
||||
- ⚠️ 华文黑体、部分兰亭黑版本：标点可能不居中；如用于出版/品牌项目需实测
|
||||
|
||||
标题/海报谨慎用：
|
||||
- ⚠️ 卡通字体用于商务
|
||||
- ⚠️ 书法字体用于科技
|
||||
- ⚠️ 衬线字体（宋体）用于运动/动感主题
|
||||
+290
@@ -0,0 +1,290 @@
|
||||
# 汉字网格系统 详解
|
||||
|
||||
中文出版物"模数 → 网格 → 版心"方法论的完整展开。
|
||||
|
||||
## 一、核心概念
|
||||
|
||||
### 模数（Modulus / 倍率 / 系数）
|
||||
一个数值，所有版面元素都是它的整数倍。让页面所有空间要素纳入统一比例。
|
||||
|
||||
- **默认推荐：1.5pt**（正文 9pt 体系）
|
||||
- 正文 9pt = 6 × 1.5pt
|
||||
- 图注 6pt = 4 × 1.5pt
|
||||
- 小标题 12pt = 8 × 1.5pt
|
||||
- 行距 18pt = 12 × 1.5pt
|
||||
- 页边距以 9pt = 1 字 为单位
|
||||
- **学术/严谨：1pt**（步进更细）
|
||||
- **古典精装 / 多体例对齐：0.5pt**（极精细）
|
||||
- **不要用 1.618pt / φ 比例做模数**——汉字定宽方格，小数位会让单元格宽算不齐
|
||||
|
||||
模数选择原则：**正文字号能被模数整除**，且模数能产生足够的字号梯度（不超过 12 级）。
|
||||
|
||||
### 字号体系
|
||||
一个项目里所有字号都从同一个表里选。典型 9pt 模数 1.5pt 体系：
|
||||
|
||||
| 用途 | 字号 (pt) | 是模数的 ? 倍 |
|
||||
|---|---|---|
|
||||
| 主标题 / 章首字 | 18–24 | 12–16× |
|
||||
| 章标题 | 15 | 10× |
|
||||
| 节标题 | 12 | 8× |
|
||||
| 正文 | 9 | 6× |
|
||||
| 引文 / 副文 | 7.5 | 5× |
|
||||
| 注释 / 图注 | 6 | 4× |
|
||||
| 页眉 / 页码 | 6 | 4× |
|
||||
|
||||
字号之间的"跳跃"不应小于 1.5×（小于这个差视觉上分不出来）。
|
||||
|
||||
### 中国传统字号体系（号 / 级 / 点对照）
|
||||
|
||||
| 号 | pt | mm | 用途 |
|
||||
|---|---|---|---|
|
||||
| 初号 | 42 | 14.8 | 章首大字、大标题 |
|
||||
| 一号 | 27.5–28 | 9.7–9.9 | 海报大标题 |
|
||||
| 小一 | 24 | 8.5 | 大标题 |
|
||||
| 二号 | 21–22 | 7.4–7.8 | 标题 |
|
||||
| 小二 | 18 | 6.3 | 中标 |
|
||||
| 三号 | 15.75–16 | 5.6 | **公文正文（GB/T 9704-2012：三号仿宋）** |
|
||||
| 四号 | 13.75–14 | 4.9 | 副标题 |
|
||||
| 小四 | 12 | 4.2 | 副文 |
|
||||
| **五号** | **10.5** | **3.7** | **书籍正文（最常用）** |
|
||||
| 小五 | 9 | 3.2 | 报刊正文 / 新五号 |
|
||||
| 六号 | 7.875 | 2.8 | 图注 / **正文字号下限** |
|
||||
| 七号 | 5.25 | 1.9 | 极小辅助文字 |
|
||||
|
||||
### 页面与版心
|
||||
|
||||
**核心公式：开本 = 正文字号 × 整数**
|
||||
|
||||
- 例：60 字宽 × 90 字高 × 9pt = **540 × 810pt = 190.5 × 285.75mm**
|
||||
- 横纵比 = 2:3（费氏数列里的优美比）
|
||||
- 印装预留：横宽各 +6pt，纵高上下各 +9pt → 成品 552 × 828pt
|
||||
|
||||
其他常用比：1:1 / 2:3 / 3:5 / 5:8 / 8:13（费氏数列）
|
||||
|
||||
## 二、版心标记法
|
||||
|
||||
这套记号让任意排版方案能被一行字精确描述。**学会这套记号能让你像建筑师一样思考版面。**
|
||||
|
||||
### 横排版心
|
||||
|
||||
```
|
||||
L3 + [ W(9pt × 56) ] + R1 / O2 + { H(9pt × 83) } + U5
|
||||
```
|
||||
|
||||
含义：
|
||||
| 符号 | 含义 | 单位 |
|
||||
|---|---|---|
|
||||
| **L** | 订口（内侧）页边距 Left/back margin | 9pt 字数 |
|
||||
| **R** | 切口（外侧）页边距 Right/fore-edge | 9pt 字数 |
|
||||
| **O** | 天头（顶部）页边距 Top margin | 9pt 字数 |
|
||||
| **U** | 地脚（底部）页边距 Bottom margin | 9pt 字数 |
|
||||
| **W( )** | 版心宽 Width of type area，方括号 `[ ]` 包裹 | pt × 字数 |
|
||||
| **H{ }** | 版心高 Height of type area，花括号 `{ }` 包裹 | pt × 字数 |
|
||||
|
||||
读法：订口空 3 个字、切口空 1 个字、天头空 2 个字、地脚空 5 个字；版心是 9pt × 56 字宽、9pt × 83 行高。
|
||||
|
||||
### 直排版心（标记略有不同）
|
||||
|
||||
直排时"宽" = 行数 × 字号、"高" = 每行字数 × 字号；订口在**右侧**（左页则在左侧）。
|
||||
|
||||
```
|
||||
O5 + { H(10.5pt × 40) } + U8 / R3 + [ W(10.5pt × 25) ] + L13
|
||||
↑ ↑
|
||||
订口（右页右侧） 切口（左侧）
|
||||
```
|
||||
|
||||
注意：直排时 L/R 角色调换 —— **L 仍指订口**（左页的左侧、右页的右侧），**R 仍指切口**。
|
||||
|
||||
### 典型版心方案（34 例精选）
|
||||
|
||||
页面均为 540×810pt（60×90 字）。
|
||||
|
||||
| 例 | 标记 | 用途 |
|
||||
|---|---|---|
|
||||
| V_1 | `L3+[W(9×56)]+R1 / O2+{H(9×83)}+U5` | 极致填满，工具书/字典 |
|
||||
| V_12 | `L2+[W(9×53)]+R5 / O3+{H(9×79)}+U8` | 文学小说 |
|
||||
| V_22 | `L5+[W(9×42)]+R13 / O8+{H(9×61)}+U21` | 大切口、可批注（教材/笔记书） |
|
||||
| V_26 | `L5+[W(9×50)]+R5 / O13+{H(9×69)}+U8` | 顶天/对称，画册 |
|
||||
| V_31 | `L3+[W(9×54)]+R3 / O5+{H(9×77)}+U8` | 通用学术，最常用 |
|
||||
| V_32 | `L3+[W(9×54)]+R3 / O5+{H(9×77)}+U8` | 同上，配多体例 |
|
||||
|
||||
**规律**：
|
||||
- 几乎都是 L < R 或 L+R 比 O+U 小（视觉重心略偏上）
|
||||
- 边距数值都是费氏数列邻项（1, 2, 3, 5, 8, 13, 21）
|
||||
|
||||
## 三、分栏（Column）
|
||||
|
||||
版心内可再分栏。栏宽和栏间距都是模数整数倍。
|
||||
|
||||
- 1 栏：文学、散文
|
||||
- 2 栏：杂志、学术论文、教材
|
||||
- 3+ 栏：辞书、目录、新闻、数据手册
|
||||
- 栏间距：**2 字宽**（如 9pt × 2 = 18pt）最常用，也可 1 字宽
|
||||
|
||||
每栏字数：
|
||||
- 1 栏页面：17–40 字（W3C 推荐 17–40，硬上限 48）
|
||||
- 2 栏页面：15–22 字
|
||||
- 3 栏页面：12–18 字
|
||||
|
||||
## 四、为不同媒介换算模数
|
||||
|
||||
### 屏幕 / 网页
|
||||
- 正文 16px → 模数 4px（16/4=4，太粗时取 2px）
|
||||
- 字号梯度：12 / 14 / 16 / 20 / 24 / 32 / 48 / 64 px（都是 4 的倍数 + 偶数和谐）
|
||||
- max-width：`30em` ≈ 480px @ 16px
|
||||
- line-height：1.5–1.7
|
||||
|
||||
### PowerPoint / Keynote
|
||||
- 4:3 画布 1024×768 → 用 64px 模数，16×12 格
|
||||
- 16:9 画布 1920×1080 → 用 60px 模数，32×18 格
|
||||
- 标题 40–60pt，正文 24–32pt，注释 14–18pt
|
||||
|
||||
### H5 / 移动 (375pt 设计稿)
|
||||
- 模数 4pt，正文 14–16pt
|
||||
- 行长建议 ≤ 18 字（375pt 宽减边距后 ~ 311pt / 18pt 字宽 = 17 字）
|
||||
|
||||
### 印刷书籍
|
||||
- 32 开 (140×210mm) → 正文 9–10pt
|
||||
- 16 开 (185×260mm) → 正文 9.5–11pt
|
||||
- 8 开/画册 → 正文可 10–12pt（视距更远）
|
||||
|
||||
## 五、网格七要点
|
||||
|
||||
整套方法论最精炼的归纳：
|
||||
|
||||
1. **从哪里开始？** 从一个字开始，更确切是从组成这个字的模数开始。"汉字一字即一格"，1:1 是费氏数列黄金比第一项。
|
||||
2. **页面尺寸 = 正文字号的整数倍**。如 60 字 × 90 字。
|
||||
3. **页面尺寸 = 模数字号的整数倍**。1.5pt 模数下 540×810pt = 194,400 个单元格。
|
||||
4. **由 1 到 ∞**：5400 个单元格可以选 1 字、2 字、N 字组合出页边距和版心；天头/订口/地脚/切口可按费氏比例（1:2:3:5）任选。
|
||||
5. **感觉是设计的核心**：网格作为工具不能在感觉上提供帮助。"美比严格按网格排列重要"。
|
||||
6. **用相同模数设计不同字号**：不同字号之间的比例关系来自共同模数。
|
||||
7. **用模数设计行间距**：行间距必须是模数整数倍。同模数下，不同字号、不同行距的文本能行对齐（多语种对照、多体例对照）。
|
||||
|
||||
## 六、网格的实操规则（中文特有）
|
||||
|
||||
中文网格不只是"框文本"，必须细到行内字格；用 `em`/`rem` 表达一切尺寸，不用 px/mm。
|
||||
|
||||
### 6.1 工作流：先字号定版心，再余出边距
|
||||
|
||||
中文工作流是"先版心、后边距"，**不是西式"先边距、再版心"**：
|
||||
|
||||
```
|
||||
1. 定字号（如 9pt）
|
||||
2. 定每行字数（如 30 字）
|
||||
3. 行长 = 字号 × 字数（9 × 30 = 270pt）
|
||||
4. 定每页行数（如 28 行）
|
||||
5. 定行距（如 18pt）
|
||||
6. 版心高 = (28-1) × 18 + 9 = 495pt
|
||||
7. 开本尺寸 - 版心 = 余白
|
||||
8. 按 3:5:8:13 分配 L/R/O/U（左/右/外/内）
|
||||
```
|
||||
|
||||
### 6.2 一切以"占字/占行"度量
|
||||
|
||||
| 元素 | 度量方式 |
|
||||
|---|---|
|
||||
| 首行缩进（书籍/公文/古典长文） | `text-indent: 2em` |
|
||||
| 网页/卡片/UI 段落 | 通常不用首行缩进，顶格 |
|
||||
| 栏间距 | 占 2 个字宽 |
|
||||
| 一级标题占行 | 4–5 行（正文行高倍数） |
|
||||
| 二级标题占行 | 2–3 行 |
|
||||
| 三级标题占行 | 1–2 行 |
|
||||
| 双行题目占行 | 3 行 |
|
||||
| 人名/花名册 | 每名占 3 格，2 字名后补 1 格空 |
|
||||
|
||||
所有标题占行**必须是正文行高的整数倍**——这是"对行"的基本要求。
|
||||
|
||||
### 6.3 行内字格也要管
|
||||
|
||||
奇数个对开（半宽）标点产生半格余量时，两种做法（无绝对对错，但要清楚妥协方向）：
|
||||
|
||||
- **活字做法**：把半格余量加给那个标点 → 标点变全宽，行仍对齐网格
|
||||
- **数码常用**：把半格均摊到全行字距 → 标点不变但整行偏离网格
|
||||
|
||||
### 6.4 严格网格之外允许"破格"
|
||||
|
||||
在网格内偶尔破格能让作品有上限突破，但**先有下限再谈上限**：
|
||||
|
||||
- 一张大图越出版心
|
||||
- 一行标题挑出栏
|
||||
- 段落里有意留出局部空白
|
||||
- 用同字号的空行/缩进区分体例（不靠加粗或换字体）
|
||||
|
||||
### 6.5 优先级：先功能，再形式对齐
|
||||
|
||||
"全标点全宽 + 不避头尾 + 数字字母全角"虽能纵横绝对对齐，但牺牲易读性。**先做完下面这些，再考虑形式对齐**：
|
||||
|
||||
- 标点宽度调整（见 `punctuation.md`）
|
||||
- 避头尾（见 `punctuation.md § 四`）
|
||||
- 换行控制（见 `title-and-breaking.md`）
|
||||
- 正字法选择（汉字数字 vs 阿拉伯数字、中西混排策略）
|
||||
|
||||
"为形式牺牲功能"是错。
|
||||
|
||||
## 七、W3C CLReq 关键数值速查表
|
||||
|
||||
把 W3C《中文排版需求》里散落的硬数值集中在一起，方便查。
|
||||
|
||||
### 字号 / 行长 / 行距
|
||||
|
||||
| 项目 | 最小 | 推荐 | 最大 |
|
||||
|---|---|---|---|
|
||||
| 正文字号 | 6 号 (7.875pt ≈ 2.8mm) | 五号 10.5pt / 小五 9pt | — |
|
||||
| 行长（每行字数）| ≥ 10 字 | 17–40 字 | 横排 ≤ 48 字 / 直排 ≤ 55 字 |
|
||||
| 行距（字号比例）| 50% 字号 | 50–100% 字号 | 100% 字号（超出不增易读性）|
|
||||
| 行高（含字本身）| 1.5 × 字号 | 1.5–2 × 字号 | 2 × 字号 |
|
||||
| 段首缩进 | — | 仅在书籍/公文/古典长文等模板指定时使用；常见 2em，短栏可 1em | — |
|
||||
| 直排带注音行距 | ≥ 1.5 × 基字 | — | — |
|
||||
| 行间标点单面装行距 | ≥ 1/2 字号 | — | — |
|
||||
| 行间标点双面装行距 | ≥ 5/8 字号 | — | — |
|
||||
|
||||
### 中西混排间距
|
||||
|
||||
| 间距 | 最小 | 默认 | 最大 |
|
||||
|---|---|---|---|
|
||||
| 中西文之间 | 1/8 em | 1/4 em | 1/2 em |
|
||||
| 西文词距 | 1/4 em | 1/3 em | 1/2 em |
|
||||
| 行末标点 | 半字宽 | 半字宽 | 半字宽（固定） |
|
||||
|
||||
### 注音与拼音字号比例
|
||||
|
||||
| 注法 | 注文字号 | 行距加成 |
|
||||
|---|---|---|
|
||||
| 注音符号（Bopomofo） | 基字的 30% | 行距 ≥ 1.5 × 基字 |
|
||||
| 汉语拼音 | 基字的 50% | 同上 |
|
||||
| 轻声符（注音） | 基字的 1/15 | — |
|
||||
|
||||
### 标题占行
|
||||
|
||||
| 标题层级 | 占行 | 字号（正文 9pt 时） |
|
||||
|---|---|---|
|
||||
| 大标题（章首） | 4–5 行 | 18–24pt |
|
||||
| 中标题（节首） | 2–3 行 | 12–15pt |
|
||||
| 小标题 | 1–2 行 | 10–12pt |
|
||||
| 双行标题 | 3 行 | 主 12pt + 副 9pt |
|
||||
| 同行标题 | 1 行（接续正文）| 9pt 加粗 |
|
||||
|
||||
### 连续标点宽度
|
||||
|
||||
| 状态 | 宽度 |
|
||||
|---|---|
|
||||
| 任意两个相邻标点共 | 2 字（未挤压） |
|
||||
| 应缩到 | **1.5 字宽** |
|
||||
| 可进一步缩到 | 1 字宽 |
|
||||
|
||||
## 八、横排 / 直排版心的方向差异
|
||||
|
||||
不同方向下版心的"行 / 列"含义对调：
|
||||
|
||||
| 概念 | 横排 | 直排 |
|
||||
|---|---|---|
|
||||
| 一行 | 水平一行字 | 垂直一行字 |
|
||||
| 行长 | 水平宽度 | 垂直高度 |
|
||||
| 每页行数 | 垂直堆叠多少行 | 水平排列多少行 |
|
||||
| 行间距 | 上下两行之间 | 左右两行之间 |
|
||||
| 版心宽 W | 横向尺寸 | 横向尺寸（= 行数 × 字号）|
|
||||
| 版心高 H | 纵向尺寸 | 纵向尺寸（= 每行字数 × 字号）|
|
||||
| 订口 L | 左侧（右页）/ 右侧（左页）| 右侧（右页）/ 左侧（左页）|
|
||||
| 切口 R | 右侧（右页）/ 左侧（左页）| 左侧（右页）/ 右侧（左页）|
|
||||
|
||||
详见 `directions.md`。
|
||||
+413
@@ -0,0 +1,413 @@
|
||||
# 标点全规则 Punctuation：风格 / 挤压 / 避头尾 / 破折号
|
||||
|
||||
中文排版的"暗物质"。占文本面积 5%–15%，决定 95% 的"专业感"。本文按 6 个主题展开：4 种标点风格、加法/减法模式、4 级避头尾、行内挤压/拉伸优先级、破折号专题、Unicode 码位速查。
|
||||
|
||||
## 一、4 种标点风格
|
||||
|
||||
不要混用。一个项目锁定一种风格。
|
||||
|
||||
### 1. 全角式（Full-width）
|
||||
- 所有标点占 1 个汉字宽
|
||||
- 出现场景：默认网页排版（引擎不调）、《普列汉诺夫美学论文选》等老派出版
|
||||
- 优点：纵横对齐严格
|
||||
- 缺点：标点连用形成"白窟窿"（` "。（ ` 三符 ≈ 3 格空白）
|
||||
- CSS：默认行为（无需特别处理）
|
||||
|
||||
### 2. 半角式（Half-width）
|
||||
- 所有标点占 0.5 个汉字宽
|
||||
- 出现场景：辞典（《汉语大字典》节约空间）、苹果中国官网 2018 年（用 WebFont SF Pro SC）
|
||||
- 优点：紧凑，西文混排自然
|
||||
- 缺点：句末停顿感弱，影响阅读节奏
|
||||
- CSS：`font-feature-settings: "halt" 1;` 或换用半宽字体
|
||||
|
||||
### 3. 开明式（Kaiming-style，大陆纸媒主流）
|
||||
- **句末标点全宽**：`。 ？ ！`（句号、问号、叹号）
|
||||
- **句内标点半宽**：`， 、 ； ：`（逗号、顿号、分号、冒号）
|
||||
- 出现场景：大陆纸媒、方正飞腾默认、绝大多数大陆图书
|
||||
- **推荐用于大陆现代横排正文**
|
||||
- CSS：手动控制或用 InDesign 标点挤压预设
|
||||
|
||||
### 4. 居中式（Centered，港台主流）
|
||||
- 所有标点全宽 + 字面正中
|
||||
- 同时适应横排和直排（标点位置一致）
|
||||
- 出现场景：港台几乎所有出版物、传统书法集
|
||||
- 优点：方向无关、对纵横对齐友好
|
||||
- 缺点：横排时"。"看着像浮在中间
|
||||
- CSS：港台地区字体（如华康、文鼎）自带这种字面分布
|
||||
|
||||
### 选择决策表
|
||||
|
||||
| 项目类型 | 推荐风格 | 备注 |
|
||||
|---|---|---|
|
||||
| 大陆现代图书 / 杂志 / 报刊 | 开明式 | 主流选择 |
|
||||
| 大陆学术论文 / 招股书 / 公文 | 开明式 | 严肃 |
|
||||
| 港台繁体书籍 | 居中式 | 民国延续 |
|
||||
| 字典 / 辞海 / 工具书 | 半角式 | 节约空间 |
|
||||
| 网页正文（无引擎支持时） | 全角式（被迫） | 加 `text-spacing-trim` 可改善 |
|
||||
| 现代网页 / App（有引擎） | 开明式 + `text-spacing-trim` | 推荐 |
|
||||
| 古籍影印 / 文言 | 居中式或全角式 | 配直排 |
|
||||
|
||||
## 二、加法模式 vs 减法模式
|
||||
|
||||
**这是认知误区的重灾区。**
|
||||
|
||||
### 加法模式（Additive，专业排版的方式）
|
||||
- 标点本身 = **半宽**
|
||||
- 加上一侧或两侧的**空隙**凑成全宽
|
||||
- 调整对象 = 空隙（可拿掉、可缩半、可拉满）
|
||||
- 采用方：InDesign、QuarkXPress、JIS、Adobe 全系
|
||||
- 标点连用时：把相邻一侧的空隙拿掉
|
||||
|
||||
### 减法模式（Subtractive，大众默认认知）
|
||||
- 标点本身 = **全宽**
|
||||
- 通过"挤压"去掉部分宽度
|
||||
- 调整对象 = 标点字面本身
|
||||
- 采用方：方正自家排版软件、Word 中文版部分预设
|
||||
- 问题：在加法模式的字体上做减法会算错
|
||||
|
||||
### 实操判断
|
||||
|
||||
**用 InDesign / Adobe 系统**：默认加法模式。选字体时优先选标点"偏靠式"的字库（思源、华文、蒙纳）；规避方正大量正文字体（方正新书宋、方正悠黑、方正宋一）—— 它们把标点摆在字面正中（"居中式"），与 Adobe 算法错位。
|
||||
|
||||
**用方正飞腾**：默认减法模式，方正字库内部自洽，不会出问题。
|
||||
|
||||
**Web / CSS**：现代 `text-spacing-trim: space-all` 是加法模式实现。
|
||||
|
||||
### 加法模式下标点的 3 类分组
|
||||
|
||||
| 类别 | 标点 | 空隙 |
|
||||
|---|---|---|
|
||||
| **第 1 类**：默认密排不加空 | 着重号、分隔号、连接号短横、日文 `？！` | 0 |
|
||||
| **第 2 类**：一边加二分空（大陆 + 日文绝大多数） | 大陆问号 / 叹号 / 冒号 / 分号 / 逗号 / 顿号 / 句号；蝌蚪引号 ""''；圆括号 ()；书名号《》 | 半宽 + 二分空 = 全宽 |
|
||||
| **第 3 类**：两边各加四分空（港台多数 + 日文中点） | 港台问号 / 叹号 / 冒号；日文 `・` | 半宽 + 左 1/4 + 右 1/4 = 全宽 |
|
||||
|
||||
## 三、行末半角原则（GB/T 15834-2011 §5.1.10）
|
||||
|
||||
**强制规则**：标点排在一行末尾时，若为全宽字符**应占半角字符的宽度**。即"行末标点 → 半宽"。
|
||||
|
||||
- 这是中国大陆和多数中国出版社的硬性规范
|
||||
- 视觉效果：行尾对齐（不会因末标点全宽撑出视觉外凸）
|
||||
- 实现：InDesign "标点挤压" → 行尾减半（自动）；CSS `hanging-punctuation: allow-end` 让标点悬挂到版心外
|
||||
|
||||
## 四、避头尾 4 级严格度（W3C CLReq §6.1.1）
|
||||
|
||||
**同一文档内必须统一一种严格度。**
|
||||
|
||||
### 0 级：none（不处理）
|
||||
- 不做任何避头尾
|
||||
- 见于港台部分报刊（标点居中无突兀）
|
||||
- 大陆不推荐
|
||||
|
||||
### 1 级：basic（基本处理，最低标准）
|
||||
- **不可在行首**：`。， 、 ； ： ！ ？ … 》 」 』 ） 】`、所有"结束"括号和引号、连接号 `–`、间隔号 `·`、分隔号 `/`
|
||||
- **不可在行尾**：`（ 【 《 「 『 " '`、所有"开始"括号和引号
|
||||
|
||||
### 2 级：GB 法（大陆国标，推荐用于正式出版）
|
||||
- basic 全部规则
|
||||
- **加**：分隔号 `/` 也不可在行尾
|
||||
- 这是中国大陆图书业的默认级别
|
||||
|
||||
### 3 级：strict（严格，推荐用于精装/正式出版）
|
||||
- GB 法全部规则
|
||||
- **加**：破折号 `——` 不可在行首
|
||||
- **加**：省略号 `……` 不可在行首
|
||||
- InDesign "简体中文避头尾" 默认即此级
|
||||
|
||||
### 完整字符表
|
||||
|
||||
#### 不可出现在行首
|
||||
```
|
||||
。，、；：？！…—··――
|
||||
）】〗〕〉》」』〙〗｠
|
||||
’"
|
||||
%‰‱℃℉°′″
|
||||
／、‧/
|
||||
```
|
||||
|
||||
#### 不可出现在行尾
|
||||
```
|
||||
（【〖〔〈《「『〘〖｟
|
||||
‘"
|
||||
$¥€£¢₩₫
|
||||
```
|
||||
|
||||
#### 不可分离（不可在中间断开）
|
||||
```
|
||||
—— 破折号（2 字宽视为一体）
|
||||
…… 省略号（2 字宽视为一体）
|
||||
123456 阿拉伯数字内部及小数点
|
||||
50% 数字 + 百分号 / 千分号 / 度数
|
||||
20℃ 数字 + 单位
|
||||
±5 符号 + 数字
|
||||
m² 被标记词 + 上下标
|
||||
①② 注释记号 + 被注词
|
||||
word 西文单词（按 hyphenation）
|
||||
```
|
||||
|
||||
### 处理顺序："先挤进后推出"
|
||||
|
||||
W3C 明文规则。
|
||||
|
||||
1. **第一步**：检查标点能否通过"宽度挤压"塞回前行末
|
||||
- 行末全宽标点 → 半宽
|
||||
- 连续标点 → 拿掉相邻一侧的空隙
|
||||
- 中西间距 1/4 em → 1/8 em
|
||||
2. **第二步**：仍塞不下，从前行末字推入下行
|
||||
3. **第三步**：前行多出的空间按拉伸优先级处理
|
||||
4. **第四步**：最后才平均加大字间距
|
||||
|
||||
**口诀**：**挤进只需腾半字宽，推出至少动一字宽；正文排版应尽量少调**。
|
||||
|
||||
### 推出后救济：均排（justify within）
|
||||
|
||||
行内调整无法整齐时，按拉伸优先级把空间分配出去。详见下一节。
|
||||
|
||||
## 五、行内挤压 / 拉伸优先级（W3C CLReq §6.2.2）
|
||||
|
||||
**这是排版引擎的内部算法表，知道了它你才知道为什么 InDesign 那样调字。**
|
||||
|
||||
### 挤压优先级（从高到低）
|
||||
|
||||
| 优先级 | 对象 | 挤压幅度 |
|
||||
|---|---|---|
|
||||
| a | **行末标点** | 固定半字宽（GB/T 15834-2011 §5.1.10） |
|
||||
| b | 行内西文词距 | 最小 **1/4 em**，多处同等量 |
|
||||
| c | 间隔号 `·` | 从两侧同等量挤，最小到 0（结果半字宽） |
|
||||
| d | 夹注符号（括号）| 开始括号前侧、结束括号后侧，最小到半字宽 |
|
||||
| e | 逗号 / 顿号 / 分号 | 后侧或两侧同等量挤，最小到半字宽 |
|
||||
| f | 中西间距 | 最小 **1/8 em**（部分风格固定 1/4 em 不允许调） |
|
||||
| g | 句号 / 问号 / 叹号 | 有空间则挤到半字宽（部分风格不允许调，因句末停顿大） |
|
||||
|
||||
### 拉伸优先级（从高到低）
|
||||
|
||||
| 优先级 | 对象 | 拉伸幅度 |
|
||||
|---|---|---|
|
||||
| a | 西文词距 | 最大 **1/2 em**，多处同等量 |
|
||||
| b | 中西间距 | 从 1/4 em 默认值起，最大 **1/2 em**（实际多数风格只到 1/3 em）|
|
||||
| c（最后选项） | 字间距 | 同等量拉，但**不可对禁则字间距拉伸**；连接号、分隔号及其前后字符避免拉伸 |
|
||||
|
||||
### 关键数值速查
|
||||
|
||||
| 间距 | 最小 | 默认 | 最大 |
|
||||
|---|---|---|---|
|
||||
| 西文词距 | 1/4 em | 1/3 em | 1/2 em |
|
||||
| 中西间距 | 1/8 em | 1/4 em | 1/2 em |
|
||||
| 间隔号两侧 | 0 | 1/4 em | 1/4 em |
|
||||
| 行末标点 | 半字宽 | 半字宽 | 半字宽（不变） |
|
||||
| 连续标点共 2 字 | 1 字 | 1.5 字 | 2 字 |
|
||||
|
||||
## 六、连续标点处理（W3C CLReq §6.3.2）
|
||||
|
||||
**最常见的灾难现场**：标点连用形成"白窟窿"。
|
||||
|
||||
未处理：
|
||||
```
|
||||
（明）钟惺、谭元春《唐诗归》钟评后二句"二
|
||||
句儿童皆诵之，然其言自足不朽"。（清）弘历
|
||||
↑↑↑
|
||||
"。（ 三个全角占 3 格
|
||||
```
|
||||
|
||||
处理后：
|
||||
```
|
||||
（明）钟惺、谭元春《唐诗归》钟评后二句"二句儿童皆
|
||||
诵之，然其言自足不朽"。（清）弘历《唐宋诗醇》评
|
||||
↑↑
|
||||
"。（ 挤压到约 1.5 字宽
|
||||
```
|
||||
|
||||
### 规则
|
||||
- 任意两个相邻标点共 2 字宽时**应缩到 1.5 字宽**
|
||||
- 可进一步缩到 1 字（但通常不缩到 1 字，避免读者错觉两符号是一个）
|
||||
- 挤压方向让开始/结束括号紧靠被夹内容
|
||||
|
||||
### 实现
|
||||
- InDesign：段落 → 中文排版设置 → "标点挤压" → 选"简体中文默认"或自定义
|
||||
- CSS：`text-spacing-trim: space-all`（自动处理）
|
||||
|
||||
## 七、破折号专题
|
||||
|
||||
**最容易出错的单一符号。**
|
||||
|
||||
### 1. 码位优先级
|
||||
1. **U+2E3A** TWO EM DASH `⸺` —— 正式码位，占 2 字一体，**首选**
|
||||
2. **U+2014** EM DASH `—` × 2 —— 事实标准，思源字体通过 `ccmp` 替换为长横，**主用**
|
||||
3. ❌ U+2015 HORIZONTAL BAR `―` —— 简中字库多数会断开
|
||||
4. ❌ U+2500 BOX DRAWINGS LIGHT HORIZONTAL `─` —— 语义错误（制表符）
|
||||
5. ❌ U+30FC KATAKANA-HIRAGANA PROLONGED SOUND MARK `ー` —— 日文长音符
|
||||
6. ❌ U+FF0D FULLWIDTH HYPHEN-MINUS `－` —— 半宽连接符
|
||||
7. ❌ U+002D HYPHEN-MINUS `-` —— ASCII 连字符
|
||||
|
||||
### 2. 字体推荐（破折号正确实现）
|
||||
|
||||
**推荐**：
|
||||
- 思源黑体 / 思源宋体（通过 OpenType `ccmp` 把连续两个 U+2014 替换为整段长横，再用 `locl` 在 CJK 语言下切换为字框居中字形）
|
||||
- 苹方 PingFang
|
||||
- HarmonyOS Sans / MiSans
|
||||
|
||||
**雷区**（破折号断开 / 顶格 / 下沉）：
|
||||
- 中易宋体、中易仿宋（破折号"无论如何接不上"）
|
||||
- 旧版微软雅黑（破折号下沉且双连超过两字宽）
|
||||
- 华文黑体（破折号顶格不居中）
|
||||
- 兰亭黑（破折号顶格且不居中）
|
||||
|
||||
### 3. 字体优先级陷阱（CSS）
|
||||
|
||||
❌ **错误**：
|
||||
```css
|
||||
font-family: "Helvetica", "PingFang SC"; /* 英文字体在前 */
|
||||
```
|
||||
连续两个 `—` 会优先取 Helvetica 字形，导致下沉、断开、双横之间留白。
|
||||
|
||||
✅ **正确（方案 A）**：删掉英文字体，用系统中文字体
|
||||
```css
|
||||
font-family: "PingFang SC", "Microsoft YaHei", sans-serif;
|
||||
```
|
||||
|
||||
✅ **正确（方案 B）**：用 `unicode-range` 拆 `@font-face`
|
||||
```css
|
||||
@font-face {
|
||||
font-family: "Helvetica Local";
|
||||
src: local("Helvetica");
|
||||
unicode-range: U+0000-007F; /* 只用于 ASCII */
|
||||
}
|
||||
body {
|
||||
font-family: "Helvetica Local", "PingFang SC", sans-serif;
|
||||
}
|
||||
```
|
||||
|
||||
✅ **正确（方案 C）**：声明 `lang` 激活 `locl`
|
||||
```html
|
||||
<html lang="zh-CN">
|
||||
```
|
||||
|
||||
### 4. 防破折号中间断开
|
||||
|
||||
**InDesign**：
|
||||
1. 段落面板 → "禁止断字" 勾选（默认开）
|
||||
2. 避头尾规则集 → "禁止分开的字符" → 加入 `U+2014`、`U+2015`、`U+2500`
|
||||
3. 不要只勾"不换行"（那只是局部手动）
|
||||
|
||||
**Word**：
|
||||
- 中文版"后置标点"里的 `―` 实际是 U+2015，不是 U+2014
|
||||
- 要让 U+2014 也避头尾，须手动加进"自定义后置标点"
|
||||
- 终极保险：选中单个 `—`，格式→字体→字符间距→缩放 200%，硬把单 em dash 变成两字宽（来自《排版与校对规范》）
|
||||
|
||||
**CSS**：
|
||||
```html
|
||||
<!-- 两个 em dash 之间禁止断行 -->
|
||||
他说—⁠—我不去了。
|
||||
```
|
||||
|
||||
### 5. 国标依据
|
||||
- GB/T 15834-2011 §4.10 / §5.1.4：破折号占两个字位置、上下居中、**不能中间断开**
|
||||
|
||||
## 八、Unicode 码位速查（W3C CLReq 推荐）
|
||||
|
||||
| 符号 | Unicode | 推荐 | 不推荐替代 |
|
||||
|---|---|---|---|
|
||||
| 句号 | U+3002 。 | ✅ | U+FF0E ． / U+002E . |
|
||||
| 逗号 | U+FF0C ， | ✅ | U+002C , |
|
||||
| 顿号 | U+3001 、 | ✅ | — |
|
||||
| 分号 | U+FF1B ； | ✅ | U+003B ; |
|
||||
| 冒号 | U+FF1A ： | ✅ | U+003A : |
|
||||
| 问号 | U+FF1F ？ | ✅ | U+003F ? |
|
||||
| 叹号 | U+FF01 ！ | ✅ | U+0021 ! |
|
||||
| 弯双引号开 | U+201C " | ✅（横排）| — |
|
||||
| 弯双引号闭 | U+201D " | ✅（横排）| — |
|
||||
| 直角引号开 | U+300C 「 | ✅（直排）| — |
|
||||
| 直角引号闭 | U+300D 」 | ✅（直排）| — |
|
||||
| 双重直角引号开 | U+300E 『 | ✅（直排）| — |
|
||||
| 双重直角引号闭 | U+300F 』 | ✅（直排）| — |
|
||||
| 圆括号开 | U+FF08 （ | ✅ | U+0028 ( |
|
||||
| 圆括号闭 | U+FF09 ） | ✅ | U+0029 ) |
|
||||
| 书名号开 | U+300A 《 | ✅ | — |
|
||||
| 书名号闭 | U+300B 》 | ✅ | — |
|
||||
| 单书名号开 | U+3008 〈 | ✅ | — |
|
||||
| 单书名号闭 | U+3009 〉 | ✅ | — |
|
||||
| 破折号 | U+2E3A ⸺ / U+2014×2 —— | ✅ | U+2015 / U+2500 / U+30FC |
|
||||
| 省略号 | U+2026×2 …… | ✅ | U+22EF（横直自动居中替代）|
|
||||
| 连接号短横 | U+2013 – | ✅ | — |
|
||||
| 连接号一字线 | U+2014 — | ✅ | — |
|
||||
| 浪纹线 | U+FF5E ～ | ✅ | U+007E ~ |
|
||||
| 间隔号 | U+00B7 · | ✅ | U+30FB / U+2027 / U+2022 |
|
||||
| 分隔号 | U+002F / 或 U+FF0F ／ | ✅ | — |
|
||||
| 着重号 | U+25CF ● 或 U+2022 • | ✅ | — |
|
||||
|
||||
## 九、CSS 完整实现（现代浏览器，2024+）
|
||||
|
||||
```css
|
||||
.body-text {
|
||||
/* 字间距：密排 */
|
||||
letter-spacing: 0;
|
||||
|
||||
/* 标点空间挤压（加法模式实现） */
|
||||
text-spacing-trim: space-all;
|
||||
|
||||
/* 标点悬挂到版心外（行尾标点视觉对齐） */
|
||||
hanging-punctuation: allow-end;
|
||||
|
||||
/* 严格避头尾 */
|
||||
line-break: strict;
|
||||
|
||||
/* 不在词中断 */
|
||||
word-break: keep-all;
|
||||
|
||||
/* 超长 URL 允许换行 */
|
||||
overflow-wrap: break-word;
|
||||
|
||||
/* 两端对齐 */
|
||||
text-align: justify;
|
||||
|
||||
/* 中文字间分布 */
|
||||
text-justify: inter-character;
|
||||
|
||||
/* 标点宽度优化（OpenType） */
|
||||
font-feature-settings:
|
||||
"halt" 1, /* 半宽间距 */
|
||||
"palt" 1; /* 成比例排（标题用） */
|
||||
}
|
||||
|
||||
/* 标题：不要 halt，标题密排 */
|
||||
h1, h2, h3 {
|
||||
font-feature-settings: "palt" 1; /* 仅成比例排 */
|
||||
}
|
||||
|
||||
/* 网页 / H5 / 卡片正文：通常不做首行缩进 */
|
||||
p {
|
||||
text-indent: 0;
|
||||
margin: 0 0 1em 0;
|
||||
}
|
||||
|
||||
/* 书籍 / 公文 / 古典长文如需首行缩进，应由对应 template 明确指定 */
|
||||
.book-copy p,
|
||||
.official-doc p,
|
||||
.classical-copy p {
|
||||
text-indent: 2em;
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
/* 引文段：不要斜体；缩进/边线/底色由版式决定 */
|
||||
blockquote {
|
||||
font-style: normal;
|
||||
}
|
||||
```
|
||||
|
||||
旧浏览器降级：用 `<wbr>` 手工断行；用脚本处理（如 `kerning.js`）。
|
||||
|
||||
## 十、检查清单（标点相关）
|
||||
|
||||
排印完成前必过：
|
||||
|
||||
- [ ] 标点风格（全角 / 半角 / 开明 / 居中）是否全文统一？
|
||||
- [ ] 行末全宽标点是否变为半宽？
|
||||
- [ ] 避头尾级别（basic / GB / strict）是否选定并启用？
|
||||
- [ ] 连续标点是否被挤压到 1.5 字宽内？
|
||||
- [ ] 破折号是否用了 U+2014×2（不是 4 个连字符）？
|
||||
- [ ] 破折号字体是否选了思源 / 苹方而不是中易 / 旧版雅黑？
|
||||
- [ ] 破折号是否被加入"禁止分开"集？
|
||||
- [ ] 引号横排用弯""'',直排用直角「」『』？
|
||||
- [ ] CSS `font-family` 是否把中文字体放在英文字体之前？
|
||||
- [ ] HTML 是否声明了 `lang="zh-CN"` 或 `lang="zh-TW"`？
|
||||
- [ ] 段落组织是否符合媒介：网页/卡片不机械首行缩进，书籍/公文/古典长文才按模板缩进？
|
||||
- [ ] 中英混排是否有 1/4 字宽间距？
|
||||
+344
@@ -0,0 +1,344 @@
|
||||
# 文本排印细节 Text Typesetting Details
|
||||
|
||||
「最基础的美学，易忽略的细节与阅读」——很多看似高级的版面，其实只是把这些"小事"全做对了。
|
||||
|
||||
> **本文专注**：字号 / 字重 / 字距 / 行距 / 段落 / 灰度 / 中英混排 / 孤行孤字 / Ruby 注音。
|
||||
> **标点专题**（避头尾 / 破折号 / 4 种风格 / 加法减法模式 / 挤压拉伸优先级）见 `punctuation.md`。
|
||||
> **断行专题**（标题断句 / 不可分离禁则）见 `title-and-breaking.md`。
|
||||
|
||||
## 一、版心（Type area）：决定阅读心理压力
|
||||
|
||||
版心位置和页边距对比强烈到能"潜移默化影响读者审美"。
|
||||
|
||||
- **太满**（每行 48 字、每页 30 行、四周边距小）→ 文字"扑面而来"，回行困难，疲劳
|
||||
- **舒展**（每行 17–25 字、页边距按比例递增）→ 优美、轻松、愉悦
|
||||
|
||||
每行字数太多的版面，会让读者阅读时心理压力较大，回行时不易找到下一行的起头，增加视觉疲劳。
|
||||
|
||||
### 横排页边距三大法则
|
||||
1. **内紧外松**：订口（书脊）< 切口（外）。视觉重心向外。
|
||||
2. **上紧下松**：天头 < 地脚。视觉重心略往上。
|
||||
3. **比例递增**：常用 **2 : 3 : 5 : 8** 或 **3 : 5 : 8 : 13**（费氏数列）
|
||||
|
||||
最常用配比（横排书籍）：
|
||||
```
|
||||
订口 : 切口 : 天头 : 地脚 = 3 : 5 : 8 : 13
|
||||
即 L3 + R5 + O8 + U13 （字数）
|
||||
```
|
||||
|
||||
### Web/H5 边距换算
|
||||
设计稿 375px 宽 H5：
|
||||
- 屏宽 375，左右各 20–24px，正文版心 327–335px
|
||||
- 上 24–32px，下 32–48px
|
||||
- 模块间距用 16/24/32（4 的倍数）
|
||||
|
||||
## 二、字间距 字距
|
||||
|
||||
**核心法则：正文密排，不动字距。**
|
||||
|
||||
### 字面率（Face ratio）
|
||||
字符在方框内实际占多少。现代字体：
|
||||
- 汉仪玄宋：92%
|
||||
- 方正雅宋：94%
|
||||
- 汉仪书宋：~96%
|
||||
- 方正书宋：96%
|
||||
- 思源黑体：~95%
|
||||
|
||||
字面率 < 100% 意味着**两个字紧贴排版时已经天然有间距**，不需要再额外加字距。
|
||||
|
||||
### 字距规则
|
||||
- **正文**：letter-spacing 0，密排
|
||||
- **标题**（≥ 24pt）：可加 0.05–0.1em 增加从容感
|
||||
- **超大字号**（≥ 40pt 海报）：可加 0.1–0.2em
|
||||
- **Logo / 单字装饰**：字距按设计意图
|
||||
|
||||
### 4 种字距模式（W3C 术语）
|
||||
|
||||
| 模式 | 字距 | 用途 |
|
||||
|---|---|---|
|
||||
| **密排** | 0 | 默认正文 |
|
||||
| **疏排** | 1/4 em / 1/3 em / 1/2 em / 1 em | 标题求平衡、图说短文求平衡、短诗词、儿童读物 |
|
||||
| **均排** | 由算法均摊 | 禁则处理后凑齐行长；列表中并列项目求体例一致 |
|
||||
| **紧排** | 负值 | 杂志标题、广告文案多字时凑一行（**不适用于书籍标题与正文**）|
|
||||
|
||||
CSS 注意：
|
||||
```css
|
||||
/* 正文区，不要碰 */
|
||||
.body { letter-spacing: 0; }
|
||||
|
||||
/* 大标题可以稍加 */
|
||||
.headline { letter-spacing: 0.05em; }
|
||||
|
||||
/* 不要这样 */
|
||||
.body-bad { letter-spacing: 1px; } /* 破坏字号节奏 */
|
||||
```
|
||||
|
||||
## 三、行间距 行距
|
||||
|
||||
### 比例区间
|
||||
| 比例（字号:行距） | 体感 | 用途 |
|
||||
|---|---|---|
|
||||
| 1 : 1.0 | 密排、铅字时代标准 | 字典、报纸（每行字少时） |
|
||||
| 1 : 1.33 | 紧凑 | 杂志、新闻 |
|
||||
| **1 : 1.5** | **现代标准** | **网页正文、商务文档** |
|
||||
| 1 : 1.7 | 舒适 | 长文阅读、技术文档 |
|
||||
| 1 : 2.0 | 疏朗 | 文学、诗歌、画册说明 |
|
||||
| 1 : 2.5+ | 飘散，章节断裂感 | 避免 |
|
||||
|
||||
W3C 规定：**行距（行间空白）= 字号的 50%–100%**；对应行高（含字本身）= 字号的 1.5–2 倍。超出 100% 不增易读性。
|
||||
|
||||
铅活字时代的优美版面（如 1918 年前后的期刊正文），字号 : 行距比约在 **1:1 ~ 4:3** 之间，是经典优美范例。
|
||||
|
||||
### 实操值
|
||||
- 印刷正文 9pt → 行距 12–18pt（默认 18pt = 1:2 雍容）
|
||||
- 印刷正文 10.5pt → 行距 14–18pt
|
||||
- 屏幕 16px → line-height 1.5–1.7（= 24–27px）
|
||||
- 屏幕 14px → line-height 1.6–1.8
|
||||
|
||||
**所有行距必须是模数整数倍。** 否则跨语种/跨字号无法行对齐。
|
||||
|
||||
### 行间标点行距加成（W3C）
|
||||
- 行间有专名号（﹏）、甲式书名号（﹏）、着重号时：
|
||||
- **单面装行距 ≥ 1/2 字号**
|
||||
- **双面装行距 ≥ 5/8 字号**
|
||||
- 直排带注音时：行距 ≥ 1.5 × 基字
|
||||
|
||||
## 四、字重与字号
|
||||
|
||||
### 字重与对比度的关系
|
||||
- 字重塑造文字与载体（纸/屏）的对比度
|
||||
- **小字 + 重字重** > 小字 + 轻字重（小字更需对比度）
|
||||
- **大字 + 轻字重** 可显优雅，大字也禁得起轻字重
|
||||
|
||||
实例：薄而透的纸张上用大字重宋体作正文，文字的黑与纸张的白构成易于阅读的对比关系，大字重还能反向突出纸张的"透"。
|
||||
|
||||
### 字重选用矩阵
|
||||
| 字号 | 屏幕 | 印刷 | 推荐字重 |
|
||||
|---|---|---|---|
|
||||
| 极小 | < 12px | < 6pt | Medium / Bold（55S–65S） |
|
||||
| 小 | 12–14px | 6–7.5pt | Regular / Medium（45S–55S） |
|
||||
| 中 | 14–18px | 8–10pt | Regular（45S–55S） |
|
||||
| 大 | 18–24px | 10–14pt | Regular / Light（35S–45S） |
|
||||
| 极大 | > 24px | > 14pt | Light / Thin 可选（25S–45S） |
|
||||
|
||||
### 层级用字重不用字体
|
||||
不同字号 × 不同字重，常常会形成灰度近似的面，从而拉开与其他元素的空间关系。例如：大字号正文用较细字重，小字号辅文用中等字重，它们灰度接近，但通过字号自然分出层级。
|
||||
|
||||
层级关系优先级：**字号 > 字重 > 颜色 > 字体**。前两个搞不定再考虑后两个。
|
||||
|
||||
## 五、段落与体例
|
||||
|
||||
### 段落组织：不要把 2 字缩进当成通用默认
|
||||
- 书籍、古典文本、公文、长篇正式印刷物：可以采用首行缩进，常见为 2 字；短栏可减弱为 1 字
|
||||
- 网页、H5、小红书、Dashboard、PPT、卡片：通常不使用首行缩进，优先用段间距、分组、标题层级来组织文本
|
||||
- 引文可使用整段缩进或边线/底色/卡片区分；不要机械套 4 字缩进
|
||||
- 列表项无需首行缩进
|
||||
- 同一作品只选择一种段落组织方式，不要“首行缩进 + 大段间距”同时堆叠
|
||||
|
||||
### 段落 4 种缩排模式（W3C CLReq §6.2.1）
|
||||
|
||||
| 模式 | 做法 | 适用 |
|
||||
|---|---|---|
|
||||
| **1. 全部段落首行缩排** | 所有段落首行空 2 字 | 书籍、古典文本、公文、正式印刷物 |
|
||||
| **2. 首段不缩排，其余缩排** | 首段顶格，其余段缩 2 字 | 长篇文章、英译中、跨文化项目 |
|
||||
| **3. 所有段落不缩排 + 段间距** | 段首顶格，段间空一定行距 | 现代网页、技术文档、H5、PPT、卡片、Markdown 渲染 |
|
||||
| **4. 语气未完段断行不缩排** | 段断而语气未完时，下一段顶格 | 散文、诗、剧本 |
|
||||
|
||||
### 凸排（Hanging Indent）
|
||||
|
||||
首行不缩、次行起缩。用于：
|
||||
- 剧本对白
|
||||
- Q&A 问答
|
||||
- 法条
|
||||
- 词典词条
|
||||
- 人名列表（花名册）
|
||||
|
||||
```
|
||||
李白：床前明月光，
|
||||
疑是地上霜。
|
||||
杜甫：好雨知时节，
|
||||
当春乃发生。
|
||||
```
|
||||
|
||||
CSS：
|
||||
```css
|
||||
.hanging {
|
||||
text-indent: -4em; /* 首行向左凸 4 字 */
|
||||
padding-left: 4em; /* 整段左缩 4 字 */
|
||||
}
|
||||
```
|
||||
|
||||
### 段落缩排（Block Indent）
|
||||
|
||||
行首侧统一缩进，用于引文、诗词、副标题。字号同正文，可换字体或加段间距，段间距应为正文行的整数倍。
|
||||
|
||||
```css
|
||||
blockquote {
|
||||
margin: 1em 4em 1em 4em; /* 左右各缩 4 字 */
|
||||
font-style: normal; /* 中文不要斜体 */
|
||||
}
|
||||
```
|
||||
|
||||
### 小标题处理
|
||||
经典示范：用同一字体同一字号，仅用空字格区分体例。
|
||||
- 引文：段首不空格，用整段缩进、边线、底色或卡片区分；具体缩进量由版式决定
|
||||
- 小标题：段首空 6 字（向右推），与正文不空行
|
||||
- 正文：按所选段落组织方式处理；书籍/公文可首行缩进，网页/卡片/UI 通常顶格并用段间距分组
|
||||
|
||||
这种"用空间代替字号"的处理，是高级排版的标志——**信息层级不靠强对比，靠空间秩序**。
|
||||
|
||||
### 单行对齐 4 种（W3C）
|
||||
- **居中**：标题、署名、独立元素
|
||||
- **行首**：列表项（左对齐于行首）
|
||||
- **行尾**：日期、署名、价格（右对齐于行尾）
|
||||
- **均排**：禁则处理后凑齐 / 列表并列项体例一致；**段落末行 / 段落只有一行时不用均排**
|
||||
|
||||
## 六、文本灰度均匀
|
||||
|
||||
排版的至高理想：**文字在版心内形成极致均匀的灰**，使塑造文本的型变得容易。
|
||||
|
||||
灰度均匀的敌人：
|
||||
1. 标点未挤压 → 局部白块
|
||||
2. 中英文混排无字距 → 字宽不均
|
||||
3. 多字重混用 → 黑白对比跳跃
|
||||
4. 行末参差不齐（左对齐）→ 右侧灰度断
|
||||
5. 大量繁体字夹杂简体 → 局部更黑
|
||||
|
||||
灰度均匀的盟友：
|
||||
1. 启用两端对齐（justify）
|
||||
2. 启用中英文混排自动间距
|
||||
3. 同段内字重统一
|
||||
4. 标点挤压 + 避头尾
|
||||
5. 行距足够稳定
|
||||
|
||||
### CSS 实现
|
||||
```css
|
||||
.body {
|
||||
text-align: justify;
|
||||
text-justify: inter-character; /* 中文字间分布 */
|
||||
text-spacing-trim: space-all;
|
||||
line-break: strict;
|
||||
}
|
||||
```
|
||||
|
||||
## 七、中英文混排
|
||||
|
||||
- 中英文之间**自动加 1/4 字宽空隙**（盘古之白）
|
||||
- Web: `<span>中文</span> <span>english</span>` 之间留半个空格；或用 `text-autospace`（IE 老规范）/CSS Text Module Level 4 的 `text-spacing`
|
||||
- Markdown 写作：手工在中英之间空格
|
||||
- 西文标点（半角）和中文字符之间也要加空格
|
||||
- 数字与中文之间同样要加：`第 3 章`，不要 `第3章`
|
||||
- 单位与数字之间不空：`30px` `9pt`，不要 `30 px`
|
||||
|
||||
### 间距 W3C 规则
|
||||
|
||||
- 横排西文字母用比例字体；数字用比例或等宽字体
|
||||
- 汉字与西文字母/数字间空隙 **≤ 1/4 em**（默认 1/4 em，最小 1/8 em，最大 1/2 em）
|
||||
- 西文/数字在行首行尾时**不加空白**
|
||||
- 中文点号前后、中文开始夹注符号之后、结束夹注符号之前的西文/数字**不调整字距、不加空白**
|
||||
|
||||
## 八、孤行孤字（Widow & Orphan）救济
|
||||
|
||||
排版的"末页综合症"。详见 `title-and-breaking.md` §五。
|
||||
|
||||
### 孤字不成行（Orphan）
|
||||
段落最后一行只有 1 字 + 1 标点。
|
||||
|
||||
救济顺序：
|
||||
1. **挤进上行**（首选）：标点宽度调整、中西间距压缩、字距均压
|
||||
2. **删字回前行**：与作者商议删 1–2 字
|
||||
3. **加字补足**：补 1 字让末行≥3 字
|
||||
4. **均排末行**（次选）：仅适用于诗歌对联
|
||||
|
||||
### 孤行不成页（Widow）
|
||||
页首是前段的最后一行。
|
||||
|
||||
救济顺序：
|
||||
1. **孤行回前页**：超出版心 1 行接前段
|
||||
2. **前页末段取 1 行**：修改前段提前结束
|
||||
3. **删字**：删本段开头让孤行不孤
|
||||
4. **加字**：补 1 行字数
|
||||
|
||||
CSS：
|
||||
```css
|
||||
p {
|
||||
orphans: 2; /* 段末至少留 2 行 */
|
||||
widows: 2; /* 段首至少留 2 行 */
|
||||
}
|
||||
```
|
||||
|
||||
## 九、Ruby 注音 / 拼音（W3C CLReq §5.5）
|
||||
|
||||
### 注音符号（Bopomofo，台湾用）
|
||||
- 横排 / 直排原则上都置基字**右侧**
|
||||
- 注文字号 : 基字 = **3 : 10**
|
||||
- 调号同字号；轻声符 = 1 : 15
|
||||
- 声调位置：
|
||||
- 平上去入声：标在末符号**右上方**
|
||||
- 入声：右下方
|
||||
- 轻声：标在前方
|
||||
- 直排向上回返半个符号位、横排向右突出半个符号位
|
||||
|
||||
### 汉语拼音
|
||||
- **仅横排**
|
||||
- 常放在基字**上方**（部分场景下方）
|
||||
- 注文字号 = 基字字号的 **1/2**
|
||||
- 相邻注文间距 ≥ 西文词间空格 ≈ 1/4 字宽
|
||||
- 字形：用 a / g 单层、二声调下粗上细的**无衬线体**（出版/教育界惯例，无国标）
|
||||
|
||||
**两种用法**：
|
||||
1. **单字标音**：注文总在上方、汉字间字距大、全小写
|
||||
2. **分词连写标音**：注文常在下方、词间约 1/2 字宽空、句首/专名大写、标点跟左侧注文
|
||||
|
||||
### HTML5 Ruby
|
||||
|
||||
```html
|
||||
<!-- 单字标音 -->
|
||||
<ruby>
|
||||
汉<rt>hàn</rt>语<rt>yǔ</rt>拼<rt>pīn</rt>音<rt>yīn</rt>
|
||||
</ruby>
|
||||
|
||||
<!-- 整词标音 -->
|
||||
<ruby>
|
||||
汉语拼音<rt>Hànyǔ Pīnyīn</rt>
|
||||
</ruby>
|
||||
|
||||
<!-- 含括号回退 -->
|
||||
<ruby>
|
||||
汉<rp>(</rp><rt>hàn</rt><rp>)</rp>
|
||||
</ruby>
|
||||
```
|
||||
|
||||
CSS：
|
||||
```css
|
||||
ruby {
|
||||
ruby-position: over; /* 注文在上 */
|
||||
/* ruby-position: under; // 注文在下（分词连写法）*/
|
||||
}
|
||||
|
||||
rt {
|
||||
font-size: 0.5em; /* 拼音 = 基字 1/2 */
|
||||
font-family: "Source Sans Pro", "Inter", sans-serif;
|
||||
line-height: 1;
|
||||
}
|
||||
```
|
||||
|
||||
### 注意：CSS Ruby 各浏览器支持不一致；Apple Books 字体选择较全。Web 上稳定方案是手动用 `<sup>` 模拟。
|
||||
|
||||
## 十、检查清单（排印完成前必过）
|
||||
|
||||
- [ ] 正文行长 17–40 字（最多 48 横排 / 55 直排）？
|
||||
- [ ] 行距是字号 1.5–2 倍？
|
||||
- [ ] 行距是模数整数倍？
|
||||
- [ ] 所有字号都在模数体系内？
|
||||
- [ ] 内 < 外 < 上 < 下 的页边距？
|
||||
- [ ] 正文 letter-spacing 是 0？
|
||||
- [ ] 段落组织方式是否符合媒介（网页/卡片不机械使用首行缩进，书籍/公文再按模板设置）？
|
||||
- [ ] 一段内字重统一？
|
||||
- [ ] 中英文之间有 1/4 字宽空格？
|
||||
- [ ] 段末是否有"孤字 + 标点"？
|
||||
- [ ] 页首是否有"孤行"？
|
||||
- [ ] 整页放远看文本灰度均匀？
|
||||
- [ ] 段落是否选定 4 种缩排模式中的一种并贯穿全文？
|
||||
|
||||
任何一项不过关，先修这一项再说"美学"。
|
||||
@@ -0,0 +1,349 @@
|
||||
# 标题断句 与 一般断行 Title Line Breaking & Word Wrapping
|
||||
|
||||
中文排版里最容易被忽略的一组规则。**正文断行和标题断行逻辑完全相反**——正文按字、标题按词。这个差异不知道，就会把"我外交部强烈谴责伊拉克"和"大使馆被炸事件"在标题里硬切两行。
|
||||
|
||||
## 一、核心原则
|
||||
|
||||
| 文本类型 | 断行逻辑 | 原因 |
|
||||
|---|---|---|
|
||||
| **正文** | 按字断，不按词 | 汉语双音节词约占 60%，按词断会形成锯齿状右缘，方块字硕大无法形成西文那样的"波浪状" |
|
||||
| **标题** | 必须按词断 | 字数少、视觉占比大，词被切开会产生歧义和阅读阻塞 |
|
||||
| **诗词** | 按句断（每句独占一行或按对齐排列） | 节奏感优先 |
|
||||
| **目录、列表** | 按条目断（必要时换行用次行缩进） | 凸排（hanging）保持检索性 |
|
||||
|
||||
## 二、标题断行规则
|
||||
|
||||
### 1. 不可在词中间断开
|
||||
|
||||
绝对不可拆的"词单位"：
|
||||
- **专有名词**：人名（毛泽东 / 习近平 / 苏炳添）、地名（北京 / 哈尔滨 / 上海浦东）、机构名（外交部 / 中央电视台）、品牌（华为 / 字节跳动）
|
||||
- **术语**：人工智能、深度学习、量子纠缠、新冠肺炎
|
||||
- **数字 + 单位**：3 公斤、500 万、第 5 章
|
||||
- **数字串**：2024 年、100 元
|
||||
- **书名 / 影片名 / 歌名**：《静夜思》、《流浪地球 2》
|
||||
- **成语 / 熟语**：守株待兔、海纳百川（4 字成语整体不拆）
|
||||
|
||||
### 2. 虚词位禁忌
|
||||
|
||||
| 字 / 词 | 禁忌位置 | 原因 |
|
||||
|---|---|---|
|
||||
| **的、地、得、之、所** | **不入行首** | 修饰关系断了 |
|
||||
| **和、与、及、或、跟、同** | **不入行末** | 并列关系悬空 |
|
||||
| **是、为、乃** | 不入行首 | 系动词需有主语 |
|
||||
| **在、于、对、向、从** | 不入行末 | 介词需带宾语 |
|
||||
| **了、着、过** | 不入行首 | 助词依附前字 |
|
||||
| **吗、呢、吧、啊、哦** | 不入行首（语气词通常）| 同上 |
|
||||
|
||||
### 3. 标题反例与修正
|
||||
|
||||
❌ **反例 1**（歧义）：
|
||||
```
|
||||
我外交部强烈谴责伊拉克
|
||||
大使馆被炸事件
|
||||
```
|
||||
读者可能误解为"伊拉克大使馆被炸"。
|
||||
|
||||
✅ **修正**：
|
||||
```
|
||||
我外交部强烈谴责
|
||||
伊拉克大使馆被炸事件
|
||||
```
|
||||
|
||||
❌ **反例 2**（词中断）：
|
||||
```
|
||||
苹果发布全新人工智
|
||||
能芯片 M5
|
||||
```
|
||||
|
||||
✅ **修正**：
|
||||
```
|
||||
苹果发布全新
|
||||
人工智能芯片 M5
|
||||
```
|
||||
|
||||
❌ **反例 3**（虚词位）：
|
||||
```
|
||||
中国队战胜了美国队和
|
||||
日本队
|
||||
```
|
||||
|
||||
✅ **修正**（"和"不入行末）：
|
||||
```
|
||||
中国队战胜了
|
||||
美国队和日本队
|
||||
```
|
||||
|
||||
### 4. 标题占行规则（铅排经验值）
|
||||
|
||||
标题必须占整数倍正文行高，否则跨栏对不齐。
|
||||
|
||||
| 标题层级 | 占行（含上下空白） | 典型字号（正文 9pt 时） |
|
||||
|---|---|---|
|
||||
| 大标题（章首） | 4–5 行 | 18–24pt |
|
||||
| 中标题（节首） | 2–3 行 | 12–15pt |
|
||||
| 小标题 | 1–2 行 | 10–12pt |
|
||||
| 双行标题（主 + 副）| 3 行 | 主 12pt + 副 9pt |
|
||||
| 同行标题（小节首）| 1 行（接续正文）| 9pt 加粗 |
|
||||
|
||||
**关键原则**：标题字号 + 上下空白 = 正文行高 × N。**否则后面所有正文都对不齐基线**。
|
||||
|
||||
### 5. 标题在页面中的位置
|
||||
|
||||
- **大标题（章首）**：必出现在**正面页**
|
||||
- 横排左翻书 → 右页（奇数页）
|
||||
- 直排右翻书 → 左页（奇数页）
|
||||
- 若大标题前一章末页停在正面页 → 反面页留空白（"双白页"是必要的，不要为省纸打破）
|
||||
- **换页 vs 单页起**：
|
||||
- 换页：从新页开始，不论奇偶（中小标题用）
|
||||
- 单页起：必从正面页开始（大标题用）
|
||||
- **中小标题孤行处理**：若中小标题落到页末且后续正文容不下，**整个标题换到下一页开头**
|
||||
|
||||
### 6. 标题对齐方式
|
||||
|
||||
| 排版方向 | 大标题对齐 | 小标题对齐 |
|
||||
|---|---|---|
|
||||
| 横排 | 多居中 | 多左对齐 / 段首空格 |
|
||||
| 直排 | 对行首（顶天） / 下沉（如下字常用 2 字位）| 同 |
|
||||
|
||||
**直排标题"下字 2 字位置"**：直排时标题从天头空 2 字开始，避免顶天造成压抑。
|
||||
|
||||
### 7. 同行标题
|
||||
|
||||
小节标题不换行，直接接续正文。处理：
|
||||
|
||||
```
|
||||
四、本章小结 本章我们讨论了……
|
||||
↑
|
||||
1 字空白
|
||||
```
|
||||
|
||||
- 标题与正文之间空 1 字位置
|
||||
- 若标题字号非整数倍，调整空白让正文头尾对齐
|
||||
|
||||
## 三、CSS / HTML 实现标题断行
|
||||
|
||||
### 方法 1：手工 `<br>` 控制断点（最稳）
|
||||
```html
|
||||
<h1>
|
||||
我外交部强烈谴责<br>
|
||||
伊拉克大使馆被炸事件
|
||||
</h1>
|
||||
```
|
||||
|
||||
### 方法 2：`<wbr>` 提示断点（允许在此换行）
|
||||
```html
|
||||
<h1>苹果发布全新<wbr>人工智能芯片 M5</h1>
|
||||
```
|
||||
|
||||
### 方法 3：U+2060 WORD JOINER（禁止在此换行）
|
||||
```html
|
||||
<h1>第⁠5⁠章 深度学习</h1>
|
||||
```
|
||||
注意：**不要**用 `‍`（U+200D ZERO WIDTH JOINER）—— 那是给阿拉伯文/天城文连写用的，对中文断行无效。
|
||||
|
||||
### 方法 4：CSS `text-wrap: balance`（现代浏览器）
|
||||
```css
|
||||
h1, h2, h3 {
|
||||
text-wrap: balance; /* 让多行标题各行字数尽量均衡 */
|
||||
}
|
||||
```
|
||||
|
||||
### 方法 5：响应式断点（不同屏宽换不同断点）
|
||||
```html
|
||||
<h1>
|
||||
我外交部强烈谴责<br class="md-only">
|
||||
<wbr>伊拉克大使馆被炸事件
|
||||
</h1>
|
||||
<style>
|
||||
@media (min-width: 768px) {
|
||||
.md-only { display: inline; }
|
||||
}
|
||||
</style>
|
||||
```
|
||||
|
||||
## 四、正文断行规则
|
||||
|
||||
正文按字断，但 6 类位置**不能拆**（不可分离禁则）：
|
||||
|
||||
### 1. 阿拉伯数字内部不拆
|
||||
- ❌ `100`<br>`0 元`
|
||||
- ✅ 整体到下一行
|
||||
|
||||
### 2. 数字 + 单位不拆
|
||||
- 数字 + `%`、`‰`、`°`、`℃`、`℉` 不拆
|
||||
- 数字 + `±`、`+`、`−` 之前的符号不拆
|
||||
- 数字 + 货币 `¥`、`$`、`€`、`£` 不拆
|
||||
|
||||
### 3. 上下标 / 注释记号 + 被标记词不拆
|
||||
- ❌ `m`<br>`²`
|
||||
- ❌ 苹果<sup>1</sup> <br> 公司
|
||||
- ✅ 注释上标紧贴前一个字
|
||||
|
||||
### 4. 破折号 / 省略号不可拆开
|
||||
- 破折号 `——`（2 字宽）不可在中间断开
|
||||
- 省略号 `……`（2 字宽）不可在中间断开
|
||||
- 连续多个破折号 `————` 允许在每一组之间拆
|
||||
|
||||
### 5. 西文单词按 hyphenation 断
|
||||
- 横排中混排的西文单词遇行尾按西文连字符规则断词
|
||||
- 直排中旋转 90° 的西文单词除连字符外不拆
|
||||
|
||||
### 6. URL / 邮件地址特殊处理
|
||||
- 建议在 `@`、`/`、`?` 等符号处断行
|
||||
- **不得加连字符**（连字符会被误解为 URL 的一部分）
|
||||
- **不改大小写**
|
||||
- CSS：`overflow-wrap: anywhere`（针对长 URL）
|
||||
|
||||
### CSS 实现"不可分离禁则"
|
||||
|
||||
```css
|
||||
.body-text {
|
||||
word-break: keep-all; /* 不在词中间断 */
|
||||
overflow-wrap: break-word; /* 但允许长 URL 换行 */
|
||||
line-break: strict; /* 严格避头尾 */
|
||||
text-spacing-trim: space-all; /* 标点空间挤压 */
|
||||
hanging-punctuation: allow-end; /* 末行标点悬挂 */
|
||||
}
|
||||
|
||||
/* 关键：不要这样写 */
|
||||
.bad {
|
||||
word-break: break-all; /* ❌ 会让中文按字硬断，避头尾全失效 */
|
||||
}
|
||||
|
||||
/* 不可断的小组：数字+单位、上下标 */
|
||||
.unit, .superscript-group {
|
||||
white-space: nowrap; /* 整组不换行 */
|
||||
}
|
||||
```
|
||||
|
||||
### 不可断小组的 HTML 标记
|
||||
|
||||
```html
|
||||
<!-- 数字+单位 -->
|
||||
温度 <span class="unit">25 ℃</span>
|
||||
价格 <span class="unit">¥ 999.99</span>
|
||||
|
||||
<!-- 上下标 -->
|
||||
面积 <span class="superscript-group">10 m<sup>2</sup></span>
|
||||
|
||||
<!-- 注释记号 -->
|
||||
苹果公司<sup class="superscript-group">①</sup>
|
||||
|
||||
<!-- 用 U+2060 也可 -->
|
||||
温度 25⁠℃
|
||||
```
|
||||
|
||||
## 五、孤行孤字（Widow & Orphan）
|
||||
|
||||
排版的"末页综合症"：段末单字、页首单行。**不修就是失败。**
|
||||
|
||||
### 1. 孤字不成行（Orphan）
|
||||
|
||||
**症状**：段落最后一行只有 1 个字 + 1 个标点。
|
||||
|
||||
**3 种救济**（按优先级）：
|
||||
|
||||
#### 救济 A：挤进上行（首选）
|
||||
- 通过标点宽度调整：把上一行的标点全部从全宽改为半宽，腾出空间
|
||||
- 通过中西间距调整：把中西混排的 1/4 em 间距压到 1/8 em
|
||||
- 通过字距均压：上一行字距压缩 1/24 em
|
||||
|
||||
#### 救济 B：删字让孤字回前行
|
||||
- 与作者商议删去 1–2 个字
|
||||
- 修改句法（"非常" → "很"）
|
||||
|
||||
#### 救济 C：加字让末行≥3 字
|
||||
- 与作者商议补 1 字让末行不再"孤"
|
||||
- 加补缀词（"了"、"的"、"则"）
|
||||
|
||||
#### 救济 D（次选）：均排末行
|
||||
- 让末行 1 个字均排到整个版心宽度
|
||||
- 适用于诗歌、对联，**不适用于现代文**（看着别扭）
|
||||
|
||||
### 2. 孤行不成页（Widow）
|
||||
|
||||
**症状**：页首是前段的最后一行（1 行 + 段间空白）。
|
||||
|
||||
**4 种救济**（按优先级）：
|
||||
|
||||
#### 救济 A：孤行回前页（突出版心）
|
||||
- 让孤行超出地脚版心 1 行，与前段连在一起
|
||||
- 此页地脚临时缩小 1 行（在不严格场合允许）
|
||||
|
||||
#### 救济 B：前页末段取 1 行
|
||||
- 修改前段，让前段在前页最后一行结束自然停顿
|
||||
- 让新段从本页开始（最自然）
|
||||
|
||||
#### 救济 C：删字
|
||||
- 删本段开头 1 行字数，让孤行不再孤
|
||||
|
||||
#### 救济 D：加字
|
||||
- 在前段补 1 行字数
|
||||
|
||||
### 3. CSS 实现
|
||||
|
||||
```css
|
||||
p {
|
||||
orphans: 2; /* 段末至少留 2 行（避免 1 字孤悬）*/
|
||||
widows: 2; /* 段首至少留 2 行（避免 1 行孤悬）*/
|
||||
}
|
||||
|
||||
/* 段不要被分页符切断 */
|
||||
h1, h2, h3 {
|
||||
page-break-after: avoid; /* 标题后不分页 */
|
||||
break-after: avoid-page; /* 同上，现代写法 */
|
||||
}
|
||||
|
||||
img, figure {
|
||||
page-break-inside: avoid; /* 图片不被切断 */
|
||||
break-inside: avoid;
|
||||
}
|
||||
```
|
||||
|
||||
## 六、断行控制工具汇总
|
||||
|
||||
| 工具 | 控制粒度 | 用法 | 平台 |
|
||||
|---|---|---|---|
|
||||
| `<br>` | 强制换行 | HTML | 所有 |
|
||||
| `<wbr>` | 软断点（允许在此换行） | HTML5 | 现代浏览器 |
|
||||
| `⁠` (U+2060 WJ) | 禁止在此换行 | HTML 字符 | 现代浏览器 |
|
||||
| ` ` | 不可换行空格 | HTML 字符 | 所有 |
|
||||
| `white-space: nowrap` | 整段不换行 | CSS | 所有 |
|
||||
| `word-break: keep-all` | 单词内不断（不要 `break-all`） | CSS | 所有现代 |
|
||||
| `overflow-wrap: break-word` | 超长词允许换行 | CSS | 现代浏览器 |
|
||||
| `line-break: strict` | 严格避头尾 | CSS | 现代浏览器 |
|
||||
| `text-wrap: balance` | 多行均衡 | CSS | 现代浏览器（2024+） |
|
||||
| `hyphens: auto` | 西文自动连字符 | CSS | 现代浏览器 |
|
||||
|
||||
## 七、InDesign / Word 中的断行设置
|
||||
|
||||
### InDesign
|
||||
1. **关闭"连数字"**（默认开启会把"以防万一"中的"万一"误判数字）：
|
||||
- 不打开任何文档 → 段落面板选项 → 关闭"连数字" → 影响所有新文档
|
||||
2. **选用 Adobe CJK 单行书写器**（不是段落书写器）
|
||||
- 段落书写器会把单行字距调整污染相邻行
|
||||
3. **避头尾设置**：选"简体中文避头尾"，避头尾间断类型选"先推入"或"确定调整量优先级"
|
||||
4. **段落面板"禁止断字"**勾选（默认开），破折号才不被拆
|
||||
|
||||
### Word
|
||||
1. 段落对话框 → 中文版式
|
||||
2. 勾选"允许标点溢出边界"
|
||||
3. 勾选"按中文习惯控制首尾字符"
|
||||
4. "首尾字符"选"标准"或"严格"
|
||||
5. **注意**：Word 默认中文"后置标点"不包含 `U+2014`，破折号需要手动加入"自定义后置标点"
|
||||
|
||||
## 八、检查清单（断行相关）
|
||||
|
||||
排印完成前必过：
|
||||
|
||||
- [ ] 所有标题是否按词断、不在词中间硬断？
|
||||
- [ ] 标题中"的"是否在行首？"和/与"是否在行末？
|
||||
- [ ] 标题占行是否为正文行高整数倍？
|
||||
- [ ] 大标题是否在正面页（横右页 / 直左页）？
|
||||
- [ ] 数字 + 单位是否整组不分行？（用 `<span class="unit">` 或 `⁠`）
|
||||
- [ ] 破折号、省略号是否未被中间拆开？
|
||||
- [ ] 注释上标是否与被标记词紧贴？
|
||||
- [ ] 段末是否有"孤字 + 标点"？
|
||||
- [ ] 页首是否有"孤行"？
|
||||
- [ ] URL / 邮箱是否在合理位置断（不加连字符）？
|
||||
- [ ] CSS 是否用 `word-break: keep-all` 而不是 `break-all`？
|
||||
+172
@@ -0,0 +1,172 @@
|
||||
---
|
||||
name: state-coverage
|
||||
description: Required UI states for interactive, data-driven, form, tool, dashboard, and prototype surfaces. Prevents designs that only render the ideal populated state.
|
||||
mode: reference
|
||||
platform: web
|
||||
scenario: horizontal-craft
|
||||
preview:
|
||||
type: none
|
||||
default_for:
|
||||
- state coverage
|
||||
- empty state
|
||||
- loading state
|
||||
- error state
|
||||
- forms
|
||||
- dashboard
|
||||
- interactive prototype
|
||||
fidelity: system
|
||||
sources:
|
||||
- adapted-from-open-design/craft/state-coverage.md
|
||||
---
|
||||
|
||||
# State Coverage
|
||||
|
||||
The single most reliable AI-design failure is shipping only the populated state.
|
||||
|
||||
The active design system decides how states look. This file decides which states must exist and what they must contain.
|
||||
|
||||
---
|
||||
|
||||
## The five required states
|
||||
|
||||
Every surface that fetches, transforms, filters, searches, or accepts data must handle all five.
|
||||
|
||||
| State | Triggered when | Must contain |
|
||||
|---|---|---|
|
||||
| Loading | Data is in flight | skeleton, spinner, shell, or labelled progress |
|
||||
| Empty | no records yet or query returned nothing | headline, explanation, primary next action |
|
||||
| Error | fetch failed, server failure, validation rejection | plain cause, recovery action, preserved input |
|
||||
| Populated | data present | the main designed state |
|
||||
| Edge | extreme volume, long strings, missing fields, partial network | layout does not break |
|
||||
|
||||
Render-and-screenshot test: every list, table, card, form, and panel has these states.
|
||||
|
||||
---
|
||||
|
||||
## Edge matrix
|
||||
|
||||
| Surface | Edge scenario |
|
||||
|---|---|
|
||||
| Dashboard / table | 10,000+ rows, numeric columns, sort + filter active |
|
||||
| Mobile card / list | 200-char title, missing avatar, missing secondary CTA |
|
||||
| Form | optional fields empty, required fields at max length |
|
||||
| Search results | one-character query, special-character query, 1,000+ results |
|
||||
| Detail view | missing optional metadata, mixed Chinese / Latin / long words |
|
||||
| Tool H5 | invalid input, user retries, result cannot be computed |
|
||||
|
||||
---
|
||||
|
||||
## Form-specific states
|
||||
|
||||
Forms add:
|
||||
|
||||
| State | Triggered when | Behavior |
|
||||
|---|---|---|
|
||||
| Untouched | field has not had focus | default styling; no validation message |
|
||||
| Dirty valid | user typed and field passes validation | helper remains; avoid excessive success coloring |
|
||||
| Submitted pending | submit clicked, waiting | button loading state; prevent duplicate submit |
|
||||
|
||||
Validation timing:
|
||||
|
||||
- validate on blur by default;
|
||||
- for password / live fields, validate on keystroke only after first blur;
|
||||
- remove error when input becomes valid;
|
||||
- preserve input on server failure.
|
||||
|
||||
---
|
||||
|
||||
## Empty state composition
|
||||
|
||||
Empty is not absence. It has a job.
|
||||
|
||||
- **First-use empty:** illustration or simple mark + headline + value sentence + primary CTA.
|
||||
- **No-results empty:** echo the query, suggest alternatives.
|
||||
- **Cleared empty:** confirm completion, optional next action.
|
||||
- **Error-as-empty:** forbidden. Error is its own state.
|
||||
|
||||
---
|
||||
|
||||
## Error state composition
|
||||
|
||||
Every error answers:
|
||||
|
||||
1. What happened.
|
||||
2. Why, if knowable.
|
||||
3. What the user can do.
|
||||
|
||||
Bad:
|
||||
|
||||
```text
|
||||
Something went wrong.
|
||||
```
|
||||
|
||||
Better:
|
||||
|
||||
```text
|
||||
未能保存表单。网络连接中断，请检查后重试。
|
||||
```
|
||||
|
||||
Severity tiers:
|
||||
|
||||
- field-level
|
||||
- form-level
|
||||
- section-level
|
||||
- page-level
|
||||
- app-level
|
||||
|
||||
Match severity to scope. A field error does not need a page-level error.
|
||||
|
||||
---
|
||||
|
||||
## Loading thresholds
|
||||
|
||||
| Duration | Indicator |
|
||||
|---|---|
|
||||
| 0–300ms | none |
|
||||
| 300ms–2s | subtle spinner or skeleton |
|
||||
| 2–10s | skeleton or labelled spinner |
|
||||
| 10–30s | progress with cancel option when possible |
|
||||
| 30s+ | explicit longer-than-expected message |
|
||||
| 60s+ | stop indefinite animation; show error / retry / cancel |
|
||||
|
||||
Never leave a spinner running indefinitely.
|
||||
|
||||
---
|
||||
|
||||
## ARIA and focus rules
|
||||
|
||||
| Change | ARIA | Focus action |
|
||||
|---|---|---|
|
||||
| Inline error on submit | `role="alert"` | move focus to first error field |
|
||||
| Toast confirmation | `role="status"` | do not move focus |
|
||||
| Critical modal | `role="alertdialog"` | move focus to dialog |
|
||||
| Loading begins | `role="status"` | do not focus spinner |
|
||||
| User-triggered content appears | usually none | move focus only if it helps continuation |
|
||||
|
||||
---
|
||||
|
||||
## Common mistakes
|
||||
|
||||
- only populated state exists
|
||||
- empty state says only “No data”
|
||||
- error says only “Something went wrong”
|
||||
- spinner has no timeout
|
||||
- submit clears fields on failure
|
||||
- validation fires on first keystroke
|
||||
- full-page loading replaces chrome for a section-level fetch
|
||||
- color alone conveys error state
|
||||
- toast cannot be paused on hover/focus
|
||||
|
||||
---
|
||||
|
||||
## Quality checks
|
||||
|
||||
```text
|
||||
[ ] Loading, empty, error, populated, and edge states exist where relevant.
|
||||
[ ] Empty state has explanation and next action.
|
||||
[ ] Error state has cause and recovery.
|
||||
[ ] Forms preserve input after failure.
|
||||
[ ] Long strings and missing optional fields do not break layout.
|
||||
[ ] Loading does not spin forever.
|
||||
[ ] State changes are announced where appropriate.
|
||||
```
|
||||
+218
@@ -0,0 +1,218 @@
|
||||
---
|
||||
name: technique-library
|
||||
description: Advanced front-end technique selection reference for motion, 3D, shaders, data visualization, and high-cost visual effects. This is a horizontal craft reference, not a routing target.
|
||||
mode: reference
|
||||
type: horizontal-craft
|
||||
applies_to:
|
||||
- landing-page
|
||||
- prototype
|
||||
- portfolio
|
||||
- info-interactive
|
||||
- deck
|
||||
- web-tool
|
||||
avoid_for:
|
||||
- static export cards unless explicitly animated
|
||||
- text-heavy editorial reading experiences
|
||||
---
|
||||
|
||||
# Technique Library
|
||||
|
||||
A reference of advanced techniques that can make a web artifact more effective, and **when**
|
||||
each is worth using. Artifact skills consult this when an effect would genuinely improve the
|
||||
result. It is not a scenario and not a routing target — a user asks for "a landing page with
|
||||
rich scroll storytelling", not "a GSAP". The artifact skill (e.g. `landing-page.md`) decides
|
||||
the form and intent, then reaches here for the implementation technique.
|
||||
|
||||
## How to use this
|
||||
|
||||
- Only reach for a technique when it serves comprehension, emotion, or the product goal.
|
||||
Default to simple CSS; escalate to a library only when the effect earns its weight.
|
||||
- Never add a technique for novelty. Motion/3D that doesn't help the message is noise — and a
|
||||
cost in load, accessibility, and maintenance.
|
||||
- Always pair an advanced technique with `prefers-reduced-motion` handling and a sensible
|
||||
no-JS / fallback state.
|
||||
- Prefer CDN includes consistent with the artifact environment; keep dependencies minimal.
|
||||
|
||||
### Not every scenario should use this — match technique to intent
|
||||
|
||||
| Scenario | What it should pull (if anything) |
|
||||
|----------|-----------------------------------|
|
||||
| landing-page | full range — motion/3D/shader serve conviction and impact |
|
||||
| prototype | motion/transitions for realistic interaction; 3D/device mockups when relevant |
|
||||
| portfolio | optional motion/3D when craft is the message; restrained for résumé/text-led profiles |
|
||||
| info-interactive | **interactive data-visualization is the point** — use diagram/chart interaction that aids comprehension (linked highlighting, filter/recompare, draggable/zoomable graphs, slider-driven models); avoid only *decorative* motion/3D that doesn't explain |
|
||||
| content-page | none — reading wants calm; at most subtle CSS reveals |
|
||||
| social-card | none — static export graphics |
|
||||
| web-tool | none beyond simple CSS — single-task utility, keep it light |
|
||||
| deck | none beyond restrained CSS — decks favor clarity over spectacle |
|
||||
|
||||
The rule of thumb: the more a scenario is about *impact/craft* (landing, creative portfolio),
|
||||
the more these techniques help; the more it is about *reading or understanding* (content-page,
|
||||
info-interactive), the more decorative effects hurt — there, only data viz qualifies.
|
||||
|
||||
---
|
||||
|
||||
## Motion & scroll
|
||||
|
||||
### CSS transitions / animations (default)
|
||||
First choice for hovers, state changes, simple reveals, micro-interactions. No library needed.
|
||||
Reach further only when CSS genuinely can't express the effect.
|
||||
|
||||
### GSAP (GreenSock)
|
||||
For complex, sequenced, or scroll-driven motion that CSS handles poorly.
|
||||
- **GSAP core + Timeline** — choreographed multi-step sequences, precise easing, coordinated
|
||||
animations.
|
||||
- **ScrollTrigger** — scroll-linked storytelling: pin sections, scrub animations to scroll,
|
||||
reveal-on-enter, parallax. The main reason to choose GSAP for landing pages and explainers.
|
||||
- Use when: a landing page needs narrative scroll, a product reveal, or staged emphasis.
|
||||
- Avoid when: a simple fade/slide on scroll (use CSS + IntersectionObserver instead).
|
||||
|
||||
### Lottie
|
||||
For designer-authored vector animations (exported from After Effects) — mascots, rich loaders,
|
||||
illustrative loops. Use when you have/need polished illustrative motion; avoid for simple UI motion.
|
||||
|
||||
---
|
||||
|
||||
## 3D & shaders
|
||||
|
||||
### Three.js
|
||||
For real 3D: product showcases in 3D, spatial scenes, interactive 3D objects.
|
||||
- Use when: a hero needs a rotatable 3D product, a spatial concept, or depth that 2D can't convey.
|
||||
- Avoid when: a flat illustration or a CSS 3D transform would do. 3D is heavy — justify it.
|
||||
- Note: in constrained runtimes some Three.js addons/geometries may be unavailable; prefer core
|
||||
geometries and verify availability.
|
||||
|
||||
### Shaders (GLSL / WebGL)
|
||||
For custom visual effects: generative backgrounds, fluid/gradient fields, particle systems.
|
||||
- Use when: a distinctive atmospheric background or effect is core to the design direction.
|
||||
- Avoid when: a CSS gradient or static image achieves the same impression. High cost, niche payoff.
|
||||
|
||||
---
|
||||
|
||||
## Data visualization
|
||||
|
||||
For quantitative, relational, or temporal information. **This overlaps with
|
||||
`info-interactive.md`** — when the deliverable's *purpose* is expressing information (report,
|
||||
data story, explainer), route to `info-interactive.md` and use these techniques inside it. Use
|
||||
them here when a scenario (e.g. landing page, dashboard) needs a chart as a supporting element.
|
||||
|
||||
### Inline SVG (default for simple charts)
|
||||
Hand-built bar/line/donut charts as inline SVG. First choice for a few simple, static charts —
|
||||
no dependency, full control, crisp export.
|
||||
|
||||
### D3.js
|
||||
For complex, custom, or data-driven visualizations: custom scales, force/network graphs,
|
||||
hierarchical layouts, bespoke interactive charts that off-the-shelf libraries can't express.
|
||||
- **Use when:** the visualization is interactive or custom beyond standard chart types — this is
|
||||
the right tool for the force/relationship graphs, zoomable hierarchies, and bespoke explorable
|
||||
charts in the Interactive diagrams section below. Don't shy away from it when the diagram genuinely
|
||||
needs force layout, hierarchical layout, or custom scales.
|
||||
- **Avoid when:** a standard bar/line/pie suffices (inline SVG or a chart library is lighter), or
|
||||
when hand-written SVG + vanilla JS already covers the interaction (see skeletons below — many
|
||||
linked-highlight / slider-model diagrams don't need D3 at all).
|
||||
|
||||
### Chart libraries (Chart.js / Recharts, when supported)
|
||||
For standard chart types quickly. Use when standard charts are enough and a library is available
|
||||
in the environment; otherwise fall back to inline SVG.
|
||||
|
||||
Visualization integrity (always): correct axes/units/scales; no misleading truncation; readable
|
||||
labels; the title states the insight; never invent data.
|
||||
|
||||
### Interactive diagrams — go past "expand / click-to-show"
|
||||
|
||||
For info-interactive (and any explainer), "click to expand" is the *lowest* tier of interaction.
|
||||
When the information is relational, comparative, sequential, or model-like, reach for a real
|
||||
interactive diagram. The point is comprehension, not spectacle — but a static list with a toggle
|
||||
is usually under-delivering for these shapes. Tiers:
|
||||
|
||||
```text
|
||||
L1 (baseline) expand / collapse / click-to-reveal ← don't stop here for explore-class info
|
||||
L2 linked highlighting, filter-and-recompose, hover-to-trace
|
||||
L3 draggable / zoomable / slider-driven models that recompute live
|
||||
```
|
||||
|
||||
Match shape → interaction (and grab a skeleton below):
|
||||
|
||||
| Information shape | Interactive move |
|
||||
|---|---|
|
||||
| relationship / network | hover a node → highlight its neighbours + dim the rest; click → detail |
|
||||
| architecture / dependency | click a layer/component → trace and highlight its dependency path |
|
||||
| sequence / process | scrub or step through; the active step explains itself |
|
||||
| comparison | toggle a dimension → matrix/chart re-sorts or re-weights live |
|
||||
| model / sensitivity | slider/input → numbers, chart, and the written takeaway update together |
|
||||
| time / evolution | brush/zoom a range → detail and summary update for that window |
|
||||
|
||||
Paste-ready skeletons (vanilla JS + SVG/HTML; reduced-motion safe; escalate to D3 only when the
|
||||
layout maths genuinely needs it):
|
||||
|
||||
**1. Linked-highlight relationship graph** (hover highlights neighbours)
|
||||
```html
|
||||
<svg id="graph" viewBox="0 0 400 300" role="img" aria-label="Relationship graph"></svg>
|
||||
<script>
|
||||
const nodes=[{id:'a',x:80,y:80,label:'Auth'},{id:'b',x:220,y:60,label:'API'},
|
||||
{id:'c',x:300,y:180,label:'DB'},{id:'d',x:120,y:210,label:'Cache'}];
|
||||
const edges=[['a','b'],['b','c'],['b','d']];
|
||||
const svg=document.getElementById('graph'), adj={};
|
||||
edges.forEach(([s,t])=>{(adj[s]=adj[s]||[]).push(t);(adj[t]=adj[t]||[]).push(s);});
|
||||
edges.forEach(([s,t])=>{const a=nodes.find(n=>n.id===s),b=nodes.find(n=>n.id===t);
|
||||
const l=document.createElementNS(svg.namespaceURI,'line');
|
||||
l.setAttribute('x1',a.x);l.setAttribute('y1',a.y);l.setAttribute('x2',b.x);l.setAttribute('y2',b.y);
|
||||
l.setAttribute('stroke','#bbb');l.dataset.edge=s+'-'+t;svg.appendChild(l);});
|
||||
nodes.forEach(n=>{const g=document.createElementNS(svg.namespaceURI,'g');g.tabIndex=0;
|
||||
g.innerHTML=`<circle cx="${n.x}" cy="${n.y}" r="20" fill="#3b82f6"/>
|
||||
<text x="${n.x}" y="${n.y+4}" text-anchor="middle" font-size="10" fill="#fff">${n.label}</text>`;
|
||||
const focus=()=>{const near=new Set([n.id,...(adj[n.id]||[])]);
|
||||
svg.querySelectorAll('circle').forEach((c,i)=>c.style.opacity=near.has(nodes[i].id)?1:.25);
|
||||
svg.querySelectorAll('line').forEach(l=>{const[s,t]=l.dataset.edge.split('-');
|
||||
l.setAttribute('stroke',s===n.id||t===n.id?'#3b82f6':'#eee');});};
|
||||
const reset=()=>{svg.querySelectorAll('circle').forEach(c=>c.style.opacity=1);
|
||||
svg.querySelectorAll('line').forEach(l=>l.setAttribute('stroke','#bbb'));};
|
||||
g.addEventListener('mouseenter',focus);g.addEventListener('focus',focus);
|
||||
g.addEventListener('mouseleave',reset);g.addEventListener('blur',reset);svg.appendChild(g);});
|
||||
</script>
|
||||
```
|
||||
|
||||
**2. Slider-driven explorable model** (input → chart + takeaway recompute)
|
||||
```html
|
||||
<label>Monthly users <input id="u" type="range" min="100" max="10000" value="2000" step="100"></label>
|
||||
<p id="out"></p><svg id="bars" viewBox="0 0 320 120"></svg>
|
||||
<script>
|
||||
const u=document.getElementById('u'),out=document.getElementById('out'),bars=document.getElementById('bars');
|
||||
function render(){const users=+u.value, revenue=users*12, cost=2000+users*3, profit=revenue-cost;
|
||||
out.textContent=`At ${users.toLocaleString()} users: revenue ¥${revenue.toLocaleString()}, `
|
||||
+`profit ¥${profit.toLocaleString()} — ${profit>0?'profitable':'below break-even'}.`;
|
||||
const data=[['Revenue',revenue],['Cost',cost],['Profit',Math.max(profit,0)]],max=Math.max(...data.map(d=>d[1]),1);
|
||||
bars.innerHTML=data.map((d,i)=>{const h=d[1]/max*80;return `
|
||||
<rect x="${20+i*100}" y="${100-h}" width="60" height="${h}" fill="${['#3b82f6','#ef4444','#22c55e'][i]}"/>
|
||||
<text x="${50+i*100}" y="115" text-anchor="middle" font-size="9">${d[0]}</text>`;}).join('');}
|
||||
u.addEventListener('input',render);render();
|
||||
</script>
|
||||
```
|
||||
|
||||
**3. Step-through process** (active step explains itself) and **4. Toggle-recompose comparison**
|
||||
follow the same pattern: state in a variable, one `render()` that redraws SVG/HTML from state, and
|
||||
controls that mutate state then call `render()`. Keep state in the DOM (classes/attributes) so it
|
||||
stays editable and inspectable.
|
||||
|
||||
Rules for all of the above: every control has a visible output change and keyboard access; provide
|
||||
a static-readable fallback (the default render must already make sense); honor `prefers-reduced-motion`;
|
||||
never fake a control. Use D3 only when force layout, hierarchical layout, or custom scales exceed
|
||||
what hand-written SVG can manage.
|
||||
|
||||
---
|
||||
|
||||
## Selection summary
|
||||
|
||||
| Need | Default | Escalate to |
|
||||
|------|---------|-------------|
|
||||
| hover / state / simple reveal | CSS | — |
|
||||
| scroll-driven storytelling | CSS + IntersectionObserver | GSAP ScrollTrigger |
|
||||
| choreographed multi-step motion | CSS | GSAP Timeline |
|
||||
| illustrative vector animation | — | Lottie |
|
||||
| real 3D / spatial | CSS 3D transforms | Three.js |
|
||||
| custom atmospheric effect | CSS gradient/image | Shaders (WebGL) |
|
||||
| a few simple charts | inline SVG | — |
|
||||
| standard charts, fast | inline SVG | Chart.js / Recharts |
|
||||
| custom / interactive data viz | inline SVG | D3.js |
|
||||
|
||||
Every escalation must (1) serve the goal, (2) ship reduced-motion handling, (3) justify its weight.
|
||||
+300
@@ -0,0 +1,300 @@
|
||||
---
|
||||
name: Visual Explanation Craft
|
||||
description: Design rules for diagrams, charts, visual explanations, explorable models, and information graphics. Choose representation from information shape; interaction must improve understanding.
|
||||
mode: reference
|
||||
platform: any
|
||||
scenario: visual-explanation
|
||||
preview:
|
||||
type: none
|
||||
default_for:
|
||||
- diagram
|
||||
- chart
|
||||
- data visualization
|
||||
- visual explanation
|
||||
- explorable model
|
||||
- interactive report
|
||||
- flowchart
|
||||
- architecture diagram
|
||||
- system map
|
||||
- process map
|
||||
- user journey map
|
||||
- data flow diagram
|
||||
- timeline
|
||||
- comparison graphic
|
||||
- information graphic
|
||||
- 可视化解释
|
||||
- 信息图
|
||||
- 交互式解释
|
||||
- 流程图
|
||||
- 架构图
|
||||
- 系统关系图
|
||||
- 业务流程图
|
||||
- 用户旅程图
|
||||
- 数据流图
|
||||
- 时间线
|
||||
fidelity: system
|
||||
---
|
||||
|
||||
# Visual Explanation Craft
|
||||
|
||||
Use this file when an artifact contains a **diagram, chart, visual explanation, interactive explanation, timeline, map, relationship graph, comparison matrix, explorable model, or data/information graphic**.
|
||||
|
||||
This is not a style preset and not a chart-library guide. It decides **what visual form the information deserves**. Use `horizontal-craft/technique-library.md` only after the representation choice requires a specific implementation technique.
|
||||
|
||||
## Core Principle
|
||||
|
||||
Pick the representation from the information shape, not from visual habit.
|
||||
|
||||
Every visual explanation must answer one of these:
|
||||
|
||||
```text
|
||||
What is the structure?
|
||||
What changed over time?
|
||||
What causes what?
|
||||
What is larger / smaller / better / worse?
|
||||
Where is it?
|
||||
How does the process move?
|
||||
What happens if I change this input?
|
||||
What should the reader compare or decide?
|
||||
```
|
||||
|
||||
If a chart, diagram, animation, or interaction does not change what the user can understand, decide, or do, remove it.
|
||||
|
||||
---
|
||||
|
||||
## Information Shape → Representation
|
||||
|
||||
| Information shape | Preferred representation | Avoid |
|
||||
|---|---|---|
|
||||
| Hierarchy / taxonomy | tree, nested cards, layered outline, collapsible hierarchy | force-fitting into a timeline |
|
||||
| Process / workflow | flowchart, stepper, pipeline, state machine | disconnected numbered cards |
|
||||
| Time / evolution | timeline, sequence strip, trend chart | unordered bullet grid |
|
||||
| Comparison / trade-off | matrix, side-by-side, before/after, toggle compare | decorative radar charts with unclear axes |
|
||||
| Quantity / metric | chart, KPI group, ranking, distribution, small multiples | chart without units, labels, or conclusion |
|
||||
| Relationship / network | node-link, adjacency list, map of dependencies | dense spaghetti graph |
|
||||
| System inventory / architecture | layered architecture map, responsibility map, component relationship diagram | pretending architecture is a time sequence |
|
||||
| Geography / spatial relation | map, route, region block, schematic geography | fake map when real geography matters |
|
||||
| Argument / evidence chain | claim → evidence → implication layout | pile of quotes or stats without logic |
|
||||
| Explorable model | input controls that update output or explanation | sliders that only animate decoration |
|
||||
| Collection / resource set | filterable grid/list, facets, search, detail drawer | endless undifferentiated cards |
|
||||
|
||||
Use the simplest representation that makes the information clearer.
|
||||
|
||||
---
|
||||
|
||||
## Interaction Must Earn Its Place
|
||||
|
||||
Use interaction only when it creates one of these values:
|
||||
|
||||
```text
|
||||
reveal detail on demand
|
||||
filter to a relevant subset
|
||||
compare alternatives
|
||||
advance through a sequence
|
||||
change an input and see the result
|
||||
highlight a relationship
|
||||
reduce cognitive load by progressive disclosure
|
||||
```
|
||||
|
||||
Interaction fails if:
|
||||
|
||||
```text
|
||||
it only creates motion;
|
||||
it hides essential information;
|
||||
it makes the user click just to read basics;
|
||||
it has no visible output change;
|
||||
it has fake controls or placeholder handlers;
|
||||
it is worse than a static chart or table.
|
||||
```
|
||||
|
||||
Every interactive control must have visible state, keyboard access, and a clear result.
|
||||
|
||||
---
|
||||
|
||||
## Chart and Data Explanation Rules
|
||||
|
||||
For charts, use `horizontal-craft/data-integrity.md` together with this file.
|
||||
|
||||
A chart must have:
|
||||
|
||||
```text
|
||||
clear title that states the insight or question;
|
||||
visible units and labels;
|
||||
honest scale and axis treatment;
|
||||
legend only when needed;
|
||||
source/provenance or visible demo-data label;
|
||||
one main reading path.
|
||||
```
|
||||
|
||||
Do not use:
|
||||
|
||||
```text
|
||||
3D charts for normal data;
|
||||
decorative charts with unreadable labels;
|
||||
truncated axes that exaggerate difference without disclosure;
|
||||
precise-looking fake data;
|
||||
multiple chart types when one table would be clearer.
|
||||
```
|
||||
|
||||
For small charts in cards, decks, or mobile surfaces, prefer fewer data points and larger labels over visual completeness.
|
||||
|
||||
---
|
||||
|
||||
## Standalone Diagram Mode
|
||||
|
||||
Use this mode when the user's final request is a flowchart, architecture diagram, system map, business process diagram, user journey map, dependency diagram, or data-flow diagram.
|
||||
|
||||
A standalone diagram may be static. Do not add filters, hover states, or animations just to make it feel interactive. Interaction is only useful when it reveals detail, switches layers, compares variants, or reduces clutter.
|
||||
|
||||
Before drawing, choose one diagram story:
|
||||
|
||||
```text
|
||||
execution flow → what happens first, next, last
|
||||
system inventory → what parts exist and how they relate
|
||||
responsibility map → who/what owns each step or component
|
||||
data flow → where data enters, transforms, and exits
|
||||
dependency map → what depends on what
|
||||
journey map → what the user/actor experiences over time
|
||||
```
|
||||
|
||||
Do not mix incompatible stories in one diagram. If the request combines system inventory and execution sequence, split into two diagrams or separate layers.
|
||||
|
||||
Default complexity:
|
||||
|
||||
```text
|
||||
4–8 primary nodes
|
||||
one dominant reading path
|
||||
at most two secondary branches
|
||||
one clear reading direction: left-to-right, top-to-bottom, radial, or loop
|
||||
no unlabeled spaghetti connectors
|
||||
```
|
||||
|
||||
Node types should have meaning:
|
||||
|
||||
```text
|
||||
step · decision · data · external system · actor · component · annotation
|
||||
```
|
||||
|
||||
Relationship types should have meaning:
|
||||
|
||||
```text
|
||||
main pipeline · optional branch · feedback loop · async signal · dependency · ownership · data movement
|
||||
```
|
||||
|
||||
Connector rules:
|
||||
|
||||
- edge labels sit near the relationship, not on top of the line;
|
||||
- arrows should not cross through nodes;
|
||||
- line style encodes meaning, not decoration;
|
||||
- avoid unnecessary connector colors;
|
||||
- if labels or arrows need long explanation, simplify the diagram.
|
||||
|
||||
Fail a standalone diagram if it requires long prose to understand, if nodes are too small to read, if every connector looks equally important, or if system structure and execution timing are confused.
|
||||
|
||||
---
|
||||
|
||||
## Diagram Rules
|
||||
|
||||
### Flowcharts and Process Diagrams
|
||||
|
||||
- One node = one step, state, decision, actor, component, or data object — but do not mix these meanings without visual distinction.
|
||||
- Keep primary flow visually dominant.
|
||||
- Branches must be labeled by trigger or condition.
|
||||
- Do not let arrows cross casually; if arrows cross, simplify the graph.
|
||||
- For user journeys, label the user action between states.
|
||||
- For system diagrams, label data/object movement between nodes.
|
||||
- For architecture diagrams, separate layers or groups before drawing arrows; boxes alone are not architecture.
|
||||
|
||||
### Timelines
|
||||
|
||||
- Use time only when order or duration matters.
|
||||
- Make scale explicit: chronological, phase-based, or milestone-based.
|
||||
- Do not mix exact dates and vague phases without visual distinction.
|
||||
- Long timelines need grouping or zoom/filter.
|
||||
|
||||
### Hierarchies
|
||||
|
||||
- Use indentation, nesting, or containment consistently.
|
||||
- Parent/child relations must be obvious without reading all text.
|
||||
- Avoid more than 3 visible hierarchy levels on a small canvas unless expandable.
|
||||
|
||||
### Comparisons
|
||||
|
||||
- Compare like with like.
|
||||
- Keep dimensions aligned across columns or rows.
|
||||
- If one side has extra criteria, explain why.
|
||||
- Difference must be visible before decorative styling.
|
||||
|
||||
### Maps and Spatial Views
|
||||
|
||||
- Use a real map when geography matters.
|
||||
- Use a schematic map when only relationship, route, or grouping matters.
|
||||
- Do not use live map widgets for exported images unless the final export captures a stable state.
|
||||
|
||||
---
|
||||
|
||||
## Carrier-Native Behavior
|
||||
|
||||
The visual explanation must feel native to its final carrier.
|
||||
|
||||
```text
|
||||
info-interactive → explorable page or standalone visual explanation, not a product demo
|
||||
web-tool → controls update the result, not just decoration
|
||||
prototype → diagram explains product flow, not a marketing infographic
|
||||
social-card → readable image, not a shrunk webpage
|
||||
standalone diagram → clear SVG/HTML diagram, not a full report page
|
||||
landing-page → visual proof supports conversion, not a full report
|
||||
slide/deck → one idea per slide, not a dense dashboard screenshot
|
||||
```
|
||||
|
||||
If the carrier is fixed image, prioritize readability at export scale. If the carrier is interactive HTML, prioritize progressive exploration and accessible state changes.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Guidance
|
||||
|
||||
Choose implementation after choosing representation.
|
||||
|
||||
```text
|
||||
simple static chart / diagram → inline SVG or semantic HTML/CSS
|
||||
simple interaction → vanilla JS + SVG/HTML state updates
|
||||
complex custom data viz → D3 or canvas only when needed
|
||||
standard charts → chart library only when supported and appropriate
|
||||
3D / shader / WebGL → almost never for explanation; use only when spatial/physical meaning matters
|
||||
```
|
||||
|
||||
Default to stable HTML/SVG. Do not escalate to advanced libraries for novelty.
|
||||
|
||||
---
|
||||
|
||||
## Accessibility and Resilience
|
||||
|
||||
- Provide text alternatives or visible summaries for charts/diagrams.
|
||||
- Do not rely on color alone; use labels, shapes, patterns, or position.
|
||||
- Ensure controls are keyboard reachable.
|
||||
- Preserve focus-visible styling.
|
||||
- Support reduced motion when animation exists.
|
||||
- Keep labels readable at the target viewport/export size.
|
||||
- If data is missing, say so; do not invent a complete visualization.
|
||||
|
||||
---
|
||||
|
||||
## Failure Cases
|
||||
|
||||
Fail the visual explanation if:
|
||||
|
||||
```text
|
||||
[ ] representation does not match the information shape
|
||||
[ ] interaction does not change understanding, decision, or task outcome
|
||||
[ ] chart lacks labels, units, scale, or conclusion
|
||||
[ ] diagram arrows/nodes are visually confusing
|
||||
[ ] standalone diagram mixes incompatible stories such as architecture inventory and execution sequence
|
||||
[ ] connectors lack semantic meaning or labels
|
||||
[ ] visual form looks impressive but explains less than text would
|
||||
[ ] controls are fake, hidden, or inaccessible
|
||||
[ ] data/proof is invented or not marked as demo/sample
|
||||
[ ] labels are too small for the final carrier
|
||||
[ ] carrier mismatch: image behaves like a webpage, deck behaves like a report, tool behaves like an infographic
|
||||
```
|
||||
|
||||
Fix by simplifying the representation before adding more decoration.
|
||||
Reference in new issue
Block a user