Methodology
Reference data sources and editorial policy
Reference pages are not calculation tools in the same way as contrast or conversion utilities, but they still need source clarity, terminology boundaries, and editorial review.
Short answer
Hue Codex treats reference data as curated educational material: CSS named colors are tied to CSS color definitions, glossary entries explain practical usage, and editorial notes distinguish standards from Hue Codex guidance.
- CSS named color values are audited through /assets/js/css-color-keywords.js, whose source metadata points to CSS Color Module Level 4 color-keyword definitions.
- Glossary entries use source tiers: standards-defined terms, color-science terms, print-production terms, Hue Codex workflow terms, and subjective/design terms.
- Technical glossary categories carry category-level citations at minimum; per-term citations should be added when a definition makes a specific conformance, formula, draft-feature, browser, print, or production claim.
- Editorial workflow defines who reviews reference changes, when review happens, what triggers updates, and how corrections are recorded.
- Glossary entries expose term last-reviewed metadata. The current rollout applies a shared default date to every term, with support for per-term overrides when individual entries are reviewed separately.
- Standardized CSS color names are not editorial endorsements; culturally sensitive or historically problematic names are preserved for CSS compatibility but not recommended for new naming systems.
- Editorial content avoids presenting subjective color meaning as universal truth.
- Reference pages include review dates and source links where external standards are central.
Standards status
These badges identify which parts of this methodology are standards-backed, draft-track, source-origin references, Hue Codex-specific, approximate, or dependent on browser behavior.
Formulas, choices, heuristics, and limits
This separates standards-based formulas from Hue Codex implementation decisions, product heuristics, and known limitations for this methodology.
Standards-based formulas
Formula, threshold, syntax, or data behavior taken from a cited standard. Primary and model sources can inform implementation, but they are not automatically standards.
- CSS named color values and special CSS color concepts are tied to CSS color definitions.
- Standards links are used when an external standard defines the term or behavior.
Implementation choices
How Hue Codex chooses to parse, normalize, round, export, or sequence calculations.
- Hue Codex glossary entries are concise editorial explanations for practical color work.
- Reference pages carry version and review dates so source or behavior changes can be audited.
Hue Codex heuristics
Product rankings, bands, labels, suggestions, or role hints that are useful guidance but not external standards.
- Editorial caveat wording, examples, and workflow framing are Hue Codex guidance.
- Color psychology, cultural notes, and practical usage explanations are treated as contextual guidance, not universal rules.
Known limitations
Caveats, edge cases, browser dependencies, approximations, or contexts the method does not prove.
- Reference data is educational and does not replace the underlying standard, specification, or production requirement.
- Subjective color meaning should not be presented as universal across cultures, industries, products, or users.
- Draft or approximate topics must be called out when they appear in reference copy.
Representative automated fixture coverage
Hue Codex imports versioned JSON fixtures and tests the corresponding pure production functions directly. The groups below are the representative regression evidence most relevant to this methodology.
- Parsing fixtures: Accepted CSS color syntax, alpha behavior, clamping, invalid input, and out-of-gamut fallback cases. View the JSON fixtures.
- Export fixtures: Displayed-versus-exported values, parseable CSS and JSON, and safe allowlisted SVG output. View the JSON fixtures.
What a pass means. A passing group confirms the named vectors and tested properties still match the documented implementation. It does not prove every possible input, final browser rendering, full accessibility conformance, profile-aware print output, or every downstream export consumer.
Data sources
Opaque CSS named colors are generated from the CSS Color 4 named-color table. Special keywords are not treated as fixed opaque swatches.
CSS named colors are listed in the generated Hue Codex keyword module at /assets/js/css-color-keywords.js. That module declares CSS Color Module Level 4, 2026-06-18, and the CSS color-keywords section as its source metadata. Current generated-file SHA-256: c7f97a5af5a776273a0ebb039f41d840371c6e3e594f8f6d0873869b166734ba.
The named-color reference presents the 148 fixed opaque CSS named colors as standard CSS keywords for web use. Special keywords such as transparent and currentcolor are treated as CSS concepts rather than ordinary opaque swatches.
Glossary entries are curated for practical color work across CSS, brand, print, accessibility, image processing, and design systems.
- transparent => transparent black.
- currentcolor => resolves from the element's color property.
- system colors => user-agent, operating-system, and forced-colors dependent.
| Dataset | Generated source | Audit note |
|---|---|---|
| CSS named colors and CSS color keywords | /assets/js/css-color-keywords.js | Derived from CSS Color Module Level 4 color-keyword definitions; SHA-256 c7f97a5af5a776273a0ebb039f41d840371c6e3e594f8f6d0873869b166734ba. |
Source badge taxonomy
A source can be authoritative for provenance without being a formal standard. Hue Codex uses source badges to separate stable specifications from drafts, original model sources, generated implementation records, browser behavior, and Hue Codex editorial guidance.
| Badge | Use for | Examples |
|---|---|---|
| Standard | Formal stable standards and specifications used as authority for syntax, thresholds, formulas, or terminology. | WCAG 2.2, CSS Color 4, ISO/CIE 11664-4, ICC.1. |
| DTCG stable community specification — not a W3C Recommendation | Stable Design Tokens Community Group Final Reports intended for implementation. This label does not imply W3C Standard, Standards Track, or Recommendation status. | Design Tokens Format Module 2025.10. |
| Draft standard | Draft, candidate, or preview specifications used only as work-in-progress context. | CSS Color 5 and W3C Working Drafts. |
| Primary source / Model source | Original model articles, algorithm author pages, generated local datasets, package documentation, checksums, or directly maintained implementation records cited for provenance. | Bjorn Ottosson's Oklab article, Brettel/Vienot/Mollon and Machado model sources, generated Hue Codex CSS keyword module. |
| Hue Codex heuristic | Role hints, ranking bands, editorial conventions, generated naming rules, and workflow guidance created for Hue Codex. | Palette role hints, contrast recommendation labels, source-tier editorial rules. |
| Browser-dependent | Behavior that depends on user agent, operating system, rendering, canvas pixels, system colors, forced-colors mode, clipboard, download, or CSS support. | Canvas sampling, system colors, forced-colors behavior, browser-rendered CSS effects. |
CSS keyword treatment
Hue Codex separates CSS keywords by whether the keyword has a fixed color value, an alpha-only value, inherited context, or user-agent/system context. This prevents a fixed HEX swatch from being implied for values that CSS resolves only after cascade, inheritance, system color mode, or forced-colors behavior is known.
Context required. currentcolor and system colors need cascade, element, browser, OS, and sometimes forced-colors context before a concrete used color can be known.
Contrast scope. Hue Codex contrast reports for the named-color reference apply to fixed opaque named colors against the selected test background, not to unresolved currentcolor or system colors.
| Keyword class | CSS behavior | Hue Codex treatment |
|---|---|---|
| Opaque named colors | CSS named colors such as red, tomato, and rebeccapurple resolve to fixed sRGB colors. | Stored in OPAQUE_NAMED_COLORS with fixed uppercase HEX values; included in the 148 opaque named-color count; eligible for HEX/RGB/HSL display, sorting, copy output, and contrast checks against a chosen background. |
| transparent | transparent is transparent black: rgb(0 0 0 / 0%). | Stored as a special keyword with #00000000 and rgb(0 0 0 / 0); excluded from opaque swatch counts and fixed contrast rankings until a background/compositing context is supplied. |
| currentcolor | currentcolor represents the used value of the element color property; in the color property itself it resolves through inheritance, and in other properties it resolves to that same element color. | Stored as a special dynamic keyword with no fixed HEX. Hue Codex lists and copies the keyword, but does not convert it to HEX or run standalone contrast checks without a resolved element color. |
| System colors | System color keywords such as Canvas, CanvasText, Highlight, and AccentColor can depend on user-agent defaults, operating system theme, accent-color, privacy mitigations, and forced-colors mode. | Stored as system keywords with descriptions only. Hue Codex treats them as browser-dependent reference values, does not assign canonical HEX/RGB values, and does not include them in fixed palette or contrast rankings. |
Sensitive and legacy color names
CSS Color 4 standardizes opaque named colors for legacy interoperability, not as a recommendation that every name is good product language. The specification notes that named colors can be hard to predict, internally inconsistent, and in some cases offensive, and says their use is not encouraged.
Hue Codex therefore treats CSS named colors as reference data, not as a preferred naming model for design systems, brands, palettes, tokens, or generated examples.
Compatibility is not endorsement. A keyword can be valid CSS and still be a poor choice for new product, brand, or design-system naming.
Cultural context changes. If a name becomes newly understood as harmful or unsuitable, Hue Codex should update guidance and examples without removing standards-defined lookup data needed for web compatibility.
| Context | Hue Codex policy |
|---|---|
| CSS lookup and copy behavior | Preserve standardized CSS keyword spelling and fixed sRGB values so users can audit real web behavior, but label the dataset as legacy CSS reference data rather than recommended naming vocabulary. |
| Examples and recommendations | Avoid using culturally sensitive, offensive, or historically problematic names as featured examples, suggested token names, palette roles, generated labels, marketing copy, or educational shorthand. Prefer HEX values, color-space notation, or semantic role names. |
| Design-system naming | Do not recommend raw CSS named colors as durable token names. Use purpose-based names such as color.text.default, color.surface.warning, or color.brand.primary, and store the color value separately. |
| Glossary and editorial copy | When a sensitive standardized keyword must be mentioned for source clarity, keep the mention factual, concise, and tied to CSS compatibility. Do not expand it into cultural interpretation or visual personality language. |
| Correction handling | If a reader flags a name as harmful or historically loaded, review whether Hue Codex created the wording or merely lists a standardized CSS keyword. Hue Codex-created language should be renamed or removed; standardized CSS keywords remain in lookup data with clearer caveats. |
| Exports | Do not convert sensitive CSS keyword strings into generated design-token identifiers unless the user explicitly chose that keyword. Prefer normalized HEX, RGB, OKLCH, or user-supplied semantic names in handoff formats. |
Glossary source tiers
Hue Codex glossary entries are concise explanations for practical color work, but each term should still be assigned an editorial source tier. The tier determines whether the entry should cite a standard, cite a primary record or model source, cite color-science or production context, label a Hue Codex workflow convention, or clearly present subjective design language as contextual guidance.
Tier priority. When a term fits multiple tiers, Hue Codex uses the most authoritative applicable tier first: standards-defined, then primary or model-source provenance, then color-science or print-production context, then Hue Codex workflow language, then subjective/design guidance.
Editorial boundary. A glossary entry may include practical examples, but the page should not make heuristic or subjective language sound like a stable standard.
| Tier | Typical source | Hue Codex treatment |
|---|---|---|
| Standards-defined terms | W3C, WCAG, CSS specifications, HTML/canvas references, and other formal standards that define syntax, thresholds, or behavior. | Use standards terminology, link the defining source where practical, and avoid changing normative meanings into Hue Codex language. |
| Primary-source records | Generated Hue Codex datasets, package references, changelogs, source metadata, checksums, and original records that document the exact data or behavior Hue Codex relies on. | Use the source for provenance and auditability, but do not present it as a stable external standard unless it is also a standards document. |
| Model-source records | Original or model-origin papers and articles for Oklab, color-vision simulation models, color appearance methods, and named color-science approaches. | Use the source to identify model lineage and assumptions; keep model origin separate from standards conformance or clinical authority. |
| Color-science terms | CIE, ICC, colorimetry, color appearance, perceptual color spaces, Delta E literature, and named conversion models. | Explain the concept in practical terms while preserving formula/model caveats, white-point assumptions, approximation limits, and when Hue Codex uses a simplified output. |
| Print-production terms | ICC profile workflows, CMYK process context, proofing, press conditions, vendor specs, paper/ink behavior, and production handoff practice. | Frame Hue Codex values as communication aids unless a profile-aware production workflow is actually performed; do not imply press-proof accuracy. |
| Hue Codex workflow terms | Tool labels, palette role hints, ranking bands, suggestions, generated names, export groupings, and review language created for Hue Codex workflows. | Label as Hue Codex guidance or heuristic language, not as an external standard or universal color-science rule. |
| Subjective/design terms | Mood words, color psychology, cultural associations, industry conventions, brand-fit language, and visual-style descriptors. | Present as contextual design guidance; avoid universal claims across cultures, audiences, products, or accessibility outcomes. |
Glossary citation policy
A single methodology source link is not enough for the Color Glossary because the glossary covers CSS, accessibility, image processing, color science, print production, color management, and design-system vocabulary. Hue Codex therefore uses category-level citations as the minimum source floor for technical glossary areas.
Per-term citations are required when a glossary entry states an exact formula, threshold, conformance requirement, draft CSS feature, browser API behavior, color-science model, ICC/profile behavior, print-production constraint, or Hue Codex-specific heuristic. General subjective or design-context terms may use category-level citations plus caveat wording instead of a citation on every line.
Per-term trigger. If a term includes an exact number, formula, threshold, normative requirement, draft status, browser behavior, press condition, or model name, add a term-level citation or explicitly point to the relevant category citation.
Specification-status handling. Draft sources such as CSS Color 5 stay labeled as work-in-progress context. Design Tokens Format Module 2025.10 is instead labeled as a stable DTCG Community Group specification intended for implementation and explicitly not a W3C Recommendation; that source status does not turn Hue Codex token-style exports into a conformance claim.
| Glossary category | Example terms | Minimum citation set |
|---|---|---|
| CSS and web | HEX, rgb(), hsl(), hwb(), lab(), lch(), oklab(), oklch(), color(), color-mix(), currentcolor, transparent, system colors, CSS custom property, device-cmyk() | CSS Color Module Level 4 for stable syntax and named colors; CSS Color Module Level 5 for draft functions such as color-mix() and device-cmyk(); CSS Color Adjustment Module Level 1 for forced-colors and system color context; CSS Custom Properties Level 1 for CSS variables. |
| Accessibility | WCAG contrast, relative luminance, non-text contrast, focus indicator, use of color, color vision deficiency | WCAG 2.2 plus W3C Understanding documents for Contrast Minimum, Non-text Contrast, Focus Appearance, and Use of Color. Simulation-risk labels remain Hue Codex heuristics unless a separate clinical source is cited. |
| Color science and color models | XYZ, Lab, LCH, OKLab, OKLCH, Delta E, white point, chromatic adaptation, gamut, linear-light, transfer curve | CSS Color Module Level 4 for web color-space definitions and sample color-difference context; ISO/CIE 11664-4 for CIE Lab; the Oklab model source for OKLab/OKLCH; CIE or ICC references when a definition moves beyond Hue Codex summaries. |
| Color management and print production | ICC profile, rendering intent, proofing, CMYK, spot color, overprint, GCR, UCR, dot gain, total ink coverage, rich black | ICC.1 profile specification for profile and rendering-intent vocabulary; CSS Color Module Level 5 only as draft CSS context for device-cmyk() and @color-profile; printer/vendor specs for job-specific ink limits, dot gain, overprint, and proofing constraints. |
| Image processing and browser behavior | canvas pixels, image sampling, File, Blob, ImageData, duotone CSS, filters, blend mode, premultiplied alpha | HTML canvas for canvas/ImageData behavior; File API for local file and Blob handling; Filter Effects and Compositing and Blending for CSS filter and blend-mode context. Browser-dependent badge remains required where output depends on decoding, canvas color space, or rendering behavior. |
| Design systems and tokens | design token, semantic color, CSS variable, color role, state color, surface color, text color, palette role | CSS Custom Properties for CSS variable behavior; Design Tokens Format Module 2025.10 as a stable DTCG Community Group specification intended for implementation but not a W3C Recommendation; Hue Codex methodology pages for role hints, naming heuristics, export choices, and any product-specific non-conformance caveats. |
| Palette, data visualization, and subjective design language | analogous, complementary, triadic, sequential palette, diverging palette, brand color, mood, warm/cool, muted | Hue Codex methodology and design guidance are acceptable category-level sources, but entries must avoid universal claims and should not present palette rankings, mood associations, or cultural meanings as standards. |
Term review metadata
Every glossary entry carries a term last-reviewed value so exported definitions can be audited independently from the page-level methodology date. The current glossary data uses a shared default of 2026-07-06 for all entries, and the data shape supports a per-term lastReviewed override when a term is individually rechecked later.
Term last reviewed means the Hue Codex wording, category, aliases, source tier, citation expectation, caveats, and tool-facing export text were reviewed on that date. It does not mean the external standard, draft, browser behavior, print process, or cultural context last changed on that date.
Metadata is an audit signal. A review date supports traceability, but it is not a guarantee that all upstream sources are unchanged or that a term is complete for legal, clinical, accessibility, or press-production use.
Correction alignment. When a term-level correction affects a tool, export, methodology claim, or source list, update the related page and changelog as well as the term last-reviewed value.
| Metadata field | Current treatment | When to update |
|---|---|---|
| lastReviewed | Displayed in glossary cards and included in reference-line, Markdown, JSON, and docs-note exports. Existing entries currently inherit the shared 2026-07-06 default. | Update when the specific term definition, source tier, category, aliases, caveats, or citation basis is rechecked or materially changed. |
| Per-term override | Optional metadata can override the shared default for individual terms without changing the compact glossary data structure for every entry. | Use when one term is corrected, sourced, renamed, or reviewed separately from the rest of the glossary. |
| Page-level review date | The methodology page still has its own last-reviewed and version metadata. | Update when the reference policy itself changes, not merely because one glossary term receives a newer review date. |
Editorial standards
- Define the term first, then explain practical use.
- Call out caveats when a term is often over-trusted, such as color psychology, CMYK approximation, or simulation.
- Prefer standards language for standards-defined features and Hue Codex language for workflow advice.
- Avoid implying that a color, culture, industry, or accessibility outcome is universal.
Editorial workflow
Hue Codex reference edits are reviewed against the affected source tier, the related methodology page, and the public tool behavior before they are treated as current guidance. The workflow is intentionally small and auditable: every material reference change should have a reviewer, a reason, and a visible version or changelog note.
No silent material rewrites. Substantive corrections should leave a visible changelog/version trace even when the visible prose becomes concise.
Source-before-confidence. If a technical claim cannot be tied to a category-level or per-term source, Hue Codex should downgrade it to contextual guidance or remove the claim until a source is available.
| Workflow step | Policy |
|---|---|
| Who reviews | The Hue Codex maintainer or editor responsible for the affected reference page, tool, or methodology page reviews the change. Technical terms are checked against the relevant category citation set; tool-specific terms are checked against the current tool behavior. |
| When review happens | Review happens before publishing new reference terms or source-policy text, when a related tool or methodology changes, when a source standard or draft changes, when a correction is received, and during broader methodology review passes. The last-reviewed date is updated only after the affected content has actually been rechecked. |
| Update triggers | Updates are triggered by standards or draft revisions, browser behavior changes, color-engine or dataset changes, generated-file checksum changes, source-link failures, user-reported corrections, newly documented limitations, changed tool output, or wording that blurs standards, draft material, Hue Codex heuristics, browser dependence, or approximation limits. |
| Correction handling | Corrections are triaged by impact. Typos and broken links can be fixed directly. Material corrections that change source meaning, technical behavior, caveats, trust boundaries, or tool output require a methodology version/changelog entry and any related tool-page or source-list update. |
| Tool-impact corrections | If a correction affects calculated output, exported data, glossary search behavior, named-color values, or methodology claims, the tool behavior and methodology page should be updated together or the page should explicitly say the implementation is pending. |
| Audit record | Material edits update the visible methodology version, changelog, date modified, source links, and validation checks where relevant. The correction text should identify what changed without implying retroactive certainty for the older wording. |
Review and versioning
Reference methodology pages carry a last-reviewed date and version. When source datasets, standards references, or implementation behavior changes, the related methodology page should be updated with the tool.
Validation checks
| Check | Expected behavior |
|---|---|
| CSS named color lookup | Keyword maps to the expected HEX value from /assets/js/css-color-keywords.js |
| transparent entry | Presented as transparent black (#00000000 / rgb(0 0 0 / 0)) and excluded from opaque named-color contrast ranking until composited |
| currentcolor entry | Presented as an inherited/dynamic CSS keyword with no standalone HEX or contrast result |
| System color entry | Presented as browser/system-dependent reference data with no canonical HEX value |
| Glossary source tier | Entry is classified as standards-defined, color-science, print-production, Hue Codex workflow, or subjective/design before source and caveat language is finalized |
| Glossary category citation | Technical glossary entries are covered by a category-level citation set, with per-term citations added for exact formulas, thresholds, conformance claims, draft features, browser behavior, or print-production constraints |
| Editorial workflow | Material reference corrections identify reviewer scope, update trigger, affected sources, related tool impact, and version/changelog handling before publication |
| Sensitive name policy | Standardized CSS keyword names are kept for compatibility lookup, while sensitive or historically problematic names are avoided in generated examples, token recommendations, and subjective design language |
| Term last reviewed | Glossary entries expose a lastReviewed value in the UI and exports; entries inherit the shared 2026-07-06 default unless an individual term override is set |
| Glossary definition | Includes practical context and avoids overclaiming |
| Source link | Uses standards links where a standard defines the term |
Sources and standards
These references anchor the public standards, model origins, source records, and formats used by Hue Codex. Status badges distinguish stable standards, drafts, primary sources, model sources, Hue Codex heuristics, approximations, and browser-dependent behavior.
Tools using this methodology
These Hue Codex tools link to this methodology because they depend on the formulas, assumptions, limits, or data policy described here.
Report a calculation issue
If a result does not match the documented formula or fixture, send the exact input, tool settings, displayed result, expected result, precision mode, and browser details. Please do not include private images, personal information, or secrets.