Define context-aware style system

Problem

Define the downstream context-aware style system for Dataface charts: when style decisions should vary by chart family, reading task, semantic context, dashboard context, or mark structure. Consolidate existing graph-library notes on axis side, legend versus direct labeling, title/subtitle blocks, reference-mark emphasis, categorical palette behavior, single-series versus multi-series color posture, and other context-sensitive defaults. Recommend which parts belong in structure presets, theme defaults, chart-level overrides, or later decision architecture.

Context

• The M1 chart-batch work has surfaced a growing set of style decisions that are clearly important, but do not all belong in immediate M1 implementation work. They are context-sensitive: the right answer can vary by chart family, reading task, dashboard role, or semantic framing.
• Recent planning threads already separated some of these into downstream items:
• define-asymmetric-independent-and-dependent-axis-treatments.md
• add-chart-subtitle-support.md
• m1-consistent-category-color-mapping-across-charts.md
• The chart design notes already contain multiple observations and recommendations that belong under a broader context-aware style system rather than as isolated one-off decisions. Important references include:
• left-side categorical label alignment for horizontal bars: docs/docs/guides/chart-design-notes.md around lines 333-339
• two-layer title / subtitle / title-block framing: docs/docs/guides/chart-design-notes.md around lines 353-363
• legend versus direct labeling / legend integration: docs/docs/guides/chart-design-notes.md around lines 374-383
• right-side versus left-side y-axis placement: docs/docs/guides/chart-design-notes.md around lines 415-423
• baseline emphasis versus ordinary lookup axis rules: docs/docs/guides/chart-design-notes.md around lines 434-440
• stacked/overlapping area direct-label behavior: docs/docs/guides/chart-design-notes.md around lines 529-536
• pie/donut palette conservatism and separators: docs/docs/guides/chart-design-notes.md around lines 791-796
• The current M1 palette work already established additional context-sensitive topics that likely belong here:
• single-series accent versus multi-series palette color 1
• dashboard-wide category assignment consistency
• default palette versus hero palette
• when chart surfaces should use stronger versus quieter neutrals
• The new categorical-palette research synthesis also points to several topics that do not belong only to palette-token definition:
• when direct labels should replace or supplement legends as category count rises
• when chart families with stronger adjacency pressure, such as pies and donuts, need more conservative palette behavior
• when non-color differentiation such as dashes, symbols, patterns, or selective gray should share the burden
• how palette evaluation should account for background contrast, small-mark use, grayscale separation, and common color-vision deficiencies
• where cultural or editorial color associations should constrain otherwise valid categorical choices
• Preserve the durable research summary in docs/docs/guides/chart-design-notes.md Note 55, and use this task to decide which of those ideas become fixed defaults, chart-family rules, or later decision architecture.
• Existing implementation seams suggest this system will need to decide where each rule belongs:
• structure presets: dataface/core/compile/chart_structures/*.yml
• theme / paint defaults: dataface/core/compile/chart_themes/*.yml, dataface/core/compile/chart_defaults.yml
• mechanical renderer defaults: dataface/core/render/chart/presentation.py, dataface/core/render/chart/standard_renderer.py
• custom renderers: dataface/core/render/chart/table.py, dataface/core/render/chart/kpi.py
• The key constraint for this task is restraint: the goal is not to create a giant magic styling engine too early, but to identify which style choices truly merit context-aware logic and which should remain fixed defaults or explicit author choices.

Possible Solutions

• Keep all styling mostly context-free and rely on one global default plus manual overrides. Trade-offs: simplest implementation, but misses real opportunities where chart-reading quality depends on context-sensitive defaults.
• Recommended: define a bounded context-aware style system that identifies a small set of recurring situations where the style choice should vary, and map each one to the lightest-possible mechanism: structure preset, theme token, chart-family rule, or later decision architecture. Trade-offs: preserves design intelligence without overbuilding; requires discipline about what counts as worth systematizing.
• Build a broad smart-style engine now that auto-selects palette, axis posture, legends, titling, and annotation behavior from many inputs. Trade-offs: ambitious, but too large and brittle for the current stage.

Plan

1. Consolidate all already-documented context-sensitive style topics into one inventory.
2. Group them by decision family, for example: axis treatment, legends/direct labeling, title blocks, palette/series logic, reference-mark emphasis, chart-family-specific exceptions.
3. For each topic, decide whether the right home is: fixed default, structure preset, theme token, chart-family rule, chart-level explicit override, or later decision architecture.
4. Identify the highest-value downstream tasks and remove duplication between overlapping task files.
5. Recommend what should remain outside the context-aware style system entirely.

Implementation Progress

• 2026-03-24: Task created to hold downstream style-system work that is broader than any one M1 chart-batch decision.
• 2026-03-24: Initial inventory seeded from existing graph-library notes and tasks, including: axis-side decisions, title/subtitle framing, legend-versus-direct-labeling guidance, reference-mark emphasis, palette assignment logic, and other style choices that vary by context.
• 2026-03-25: Moved from m1-ft-analytics-analyst-pilot to m2-internal-adoption-design-partners. Current judgment: this is important, but it is broader than the remaining M1 pilot-critical work and should follow the initial scaffold, palette, and default-structure lock.

QA Exploration

• [ ] QA exploration completed (or N/A for non-UI tasks)

Review Feedback

• [ ] Review cleared