Geometry

Structure first, softness with purpose

JR Dream’s working geometry supports Architectural Minimalism with Technical Precision through aligned rectangular regions, subtle controls and restrained content grouping. Consistent edges help distinguish structure, interaction and related information without adding ornamental shapes.

Use the existing grid, spacing, colour and typography foundations together. Ordinary surfaces stay flat; rounding identifies a role, and elevation is reserved for actual overlap. These are internally accepted working specifications, pending implementation testing and final company approval.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 1–2 and 14.

Geometry principles

• Align structural panel edges to the grid. Separate content with spacing first, then fill or a restrained border when needed.
• Square regions organise space. Controls use a small corner transition; cards group related content without turning every section into a rounded object.
• Use flat fills and purposeful status tints. Avoid organic blobs, purposeless circles, ornamental geometry, decorative gradients, glassmorphism, bevels and dimensional card stacks.
• Preserve complete content frames when critical details matter. Interface geometry does not authorise cropping or masking the supplied logo, copying its symbol or deriving new motifs.

Structural panels, interactive objects and supplementary media have distinct roles. A corner radius or shadow is never a substitute for a usable target, an accessible name or a meaningful boundary.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 2–3, 5 and 12.

Corner radius system

Use only the three established role values. The following frames render the actual central tokens, with content-driven height and no decorative elevation.

Keep these values on narrow screens; do not enlarge rounding as a percentage of the frame. Do not assign a radius to the logo itself. A rounded surrounding card is allowed only while its complete square canvas and exclusion zone remain intact.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, page 3; token names on page 13.

Square structural geometry

Page sections, major divisions, table shells and navigation rails remain rectangular and flat. Smaller control or card geometry belongs inside that structure rather than redefining it.

The documentation shell remains unchanged. Its mobile navigation rail is implemented using a native dialog, but keeps its existing square structural treatment. That application detail is distinct from the source’s 8px content-dialog role; geometry follows purpose, not the HTML tag alone.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 2–3 and 7–8; existing documentation-shell implementation retained.

Borders and functional boundaries

Functional meaning determines colour. Increasing the width of a low-contrast decorative line does not make it an appropriate control boundary.

When error state changes a 1px border to 2px, use border-box sizing and reserve the space or compensate padding. The live input below subtracts the 1px difference from its padding: 12/16px becomes 11/15px without adding spacing tokens.

Boundary contrast: source and calculated evidence

The source’s 15 sRGB pair calculations use a 3:1 meaningful-cue threshold. Source ratios below are transcribed from page 5; calculated ratios independently use current token values and the existing colour documentation’s luminance function. Verdicts use unrounded calculations, with ratios displayed to two decimals.

Failed decorative pairs remain decorative. Error red is 2.26:1 against charcoal and cannot be the sole meaningful boundary there: use the light error surface with explicit wording. Shadows are never the required identification cue. These numerical checks are not a WCAG conformance verdict.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 4–5, 9 and 13.

Dividers and content grouping

Use restrained lines when sections, table rows or card content need additional separation; start with spacing and clear labels. A card perimeter or table row separator can use the decorative token when its outline is not required to identify an interactive object. Keyboard/click selection needs a separate meaningful cue.

For physical materials, the source specifies square A4 blocks/callouts with 0.5pt decorative separators, 0.75pt meaningful form outlines and a 1.5pt selected rule. Slides use square panels and 1pt separators where helpful. Default physical radius is 0pt; do not reinterpret digital 4px as 4mm. Print and projection require proofs.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 2, 4–5, 8 and 11.

Flat surfaces and restrained elevation

Sticky navigation starts flat with a bottom separator. The source allows the floating recipe only when actual overlap needs extra separation; this stage does not change the documentation header. Prefer a light floating surface over charcoal rather than depending on a subtle shadow between dark layers.

The source defers modal backdrop design. The documentation’s existing mobile-menu backdrop remains an unchanged application detail, pending design validation; no opacity or backdrop token is introduced. Neither shadow recipe establishes z-index or keyboard behaviour.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 6, 9 and 13; accepted existing-backdrop handling from Stage 02.1.

Geometry in common UI patterns

Source selection and the documentation exception

The accepted documentation navigation uses solid accessible action orange, white selected text, 4px corners, existing focus and at least 48px targets. It retains aria-current="page" with no selected marker, selected outline or visible Current label. This application choice is not an automatic corporate-site rule. Focus remains independent of selection.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 3–5 and 7–10; documentation-sidebar exception recorded in Stage 02.1.

Correct and incorrect applications

The source permits a stronger 2px control outline when useful; it does not recommend making every card heavier. Recommendations to prefer spacing and restrained lines are layout guidance, not an additional numeric geometry scale.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 2–6, 9–10 and 12.

Responsive geometry and accessibility

• Keep role radii at 0/4/8px across viewport bands. Let content, labels and messages wrap; use minimum rather than fixed control heights.
• Retain at least 48px interactive targets and 8px between neighbours. A status badge’s 4px/8px padding alone is not a usable interactive target.
• A 2px focus ring plus 2px gap needs 4px of clear space outside the control on each side. Avoid clipping the group, and check sticky/scrolling obstructions.
• Keep focus, selection and error independent. Associate explicit errors, expose invalid state and preserve native/system focus in forced colours.
• Scope focus to the local surface: warm-white fields use the warm-white gap; white popups on dark parents reset to the light ring and white gap. Preserve elevation when combining box-shadow layers.
• Use logical start/end properties for RTL flow. Move the source selected marker to inline-start without mirroring the logo, identifiers or non-directional content.

The technical marker example verifies direction only. It does not introduce Arabic copy or a numeral convention. Real Arabic content, diacritics, mixed punctuation and native-reader review remain pending.

The source reports 20 static bilingual form specimens, not native browser interaction. Its zero outside-page text cases do not certify input caret scrolling, 200%/400% zoom, screen-reader error announcements or full accessibility. A proposed 2px ring is not a claim of the separate AAA Focus Appearance criterion.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 3, 8–9 and 12–13.

Developer implementation

Reuse the exact existing geometry and semantic colour variables. Values displayed on this page resolve from styles/tokens.css at build time. Examples are implementation guidance, not a separate component package.

.structural-panel {
  border-radius: var(--radius-none);
  background: var(--surface-secondary);
  box-shadow: var(--shadow-none);
}
.card {
  border: var(--border-thin) solid var(--border-default);
  border-radius: var(--radius-container);
  background: var(--surface-primary);
  padding: var(--padding-card-comfortable);
  box-shadow: var(--shadow-none);
}
.control {
  box-sizing: border-box;
  min-block-size: var(--target-min);
  block-size: auto;
  min-inline-size: 0;
  max-inline-size: 100%;
  border: var(--border-thin) solid var(--border-control);
  border-radius: var(--radius-control);
  padding: var(--space-12) var(--space-16);
  font: inherit;
  line-height: var(--type-input-leading);
}
.control[aria-invalid="true"] {
  border-width: var(--border-strong);
  border-color: var(--status-error);
  padding-block: calc(var(--space-12) - (var(--border-strong) - var(--border-thin)));
  padding-inline: calc(var(--space-16) - (var(--border-strong) - var(--border-thin)));
}
/* Pair invalid state with an explicit associated error message.
   Compensation preserves the content position; 11/15px are not new tokens. */

.light-surface {
  --focus-ring: var(--focus-light);
  --focus-gap: var(--surface-primary);
}
.warm-surface { --focus-gap: var(--surface-secondary); }
.inverse-surface {
  --focus-ring: var(--focus-inverse);
  --focus-gap: var(--surface-inverse);
}
/* A white popup on a dark parent must reset BOTH variables locally. */
.floating-surface {
  --focus-ring: var(--focus-light);
  --focus-gap: var(--surface-primary);
  border: var(--border-thin) solid var(--border-default);
  border-radius: var(--radius-control);
  background: var(--surface-primary);
  box-shadow: var(--shadow-floating);
}
.control:focus-visible {
  outline: var(--focus-width) solid var(--focus-ring);
  outline-offset: var(--focus-offset);
  box-shadow: 0 0 0 var(--focus-offset) var(--focus-gap);
}
.floating-surface:focus-visible {
  outline: var(--focus-width) solid var(--focus-ring);
  outline-offset: var(--focus-offset);
  box-shadow: 0 0 0 var(--focus-offset) var(--focus-gap), var(--shadow-floating);
}
@media (forced-colors: active) {
  .control:focus-visible, .floating-surface:focus-visible {
    outline: var(--focus-width) solid Highlight;
    box-shadow: none;
  }
  .control[aria-invalid="true"] { border-style: dashed; }
}

.source-selected-row {
  border: var(--border-thin) solid var(--action-primary-background);
  border-inline-start-width: var(--marker-selected);
  border-radius: var(--radius-none);
  background: var(--brand-accent-subtle);
  color: var(--text-primary);
  padding: var(--space-12) var(--space-16);
  text-align: start;
}
/* Add written state and aria-current/aria-selected to the actual
   interactive pattern. This is not the documentation-sidebar exception. */
.control-group { display: flex; flex-wrap: wrap; gap: var(--space-08); }
.control-group > * { min-inline-size: 0; overflow-wrap: anywhere; }
/* Keep at least 4px clear around focusable items for the 2px ring + gap.
   Do not clip the group or change role radii by viewport percentage. */

Supply accessible labels and real behaviour when these roles become production controls. For dialogs and menus, separately implement and test keyboard behaviour, focus order/return and modality as appropriate. The static surface specimens above do not provide those behaviours.

Keep spacing/layout rules, language-aware typography and colour pairing restrictions alongside these geometry rules. Preserve the original logo artwork and complete canvas.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 4, 9 and 12–13.

Validation and approval status

No comprehensive WCAG conformance, real-device certification, Arabic approval or final company approval is claimed. Documentation specimens do not establish production component readiness.

Source: Shapes, Borders & Corner Radii Exploration & Validation v1.0, pages 12–14; existing implementation records and current Stage 02.2E report.