Perfect — I’ll begin crafting a complete design system for **PrecisionCore** tailored for web applications that work well on both desktop and mobile. It’ll default to **light mode**, include **dark mode support**, and cover all essential components found in modern web apps. The system will include: - In-depth design philosophy and visual principles - Guidelines for layout, spacing, grids, and UI behaviors - Component breakdowns with usage rules - Code examples in **vanilla HTML/CSS** (primary) and **TailwindCSS** (secondary) - **Mockups and image examples** of components in the PrecisionCore style I’ll let you know as soon as it’s ready for review. # PrecisionCore Design System ## Introduction & Design Philosophy PrecisionCore is a comprehensive design system that blends four key influences into a unified visual style for web applications: **Material Design** (functional, systemized architecture), **Minimalism** (clarity and focus), **Apple’s Design Elegance** (refinement and attention to detail), and **Windows 98’s Nostalgic Rigidity** (clear structure and familiar patterns). The goal is a modern yet timeless UI that is **highly usable and aesthetically pleasing**. By combining these philosophies, PrecisionCore emphasizes intuitive interaction, minimal distraction, and a touch of retro familiarity: - **Functional Clarity (Material):** Heavily inspired by Material Design, PrecisionCore promotes consistent layouts and predictable components. Every element has a clear purpose and aligns to a rational grid system, ensuring the interface feels organized and easy to navigate. Accessibility and cross-platform consistency are priorities, echoing Material Design’s mission to make UIs that work for everyone in any context ([What is iOS Human Interface Guidelines?](https://pangea.app/glossary/ios-human-interface-guidelines#:~:text=At%20the%20core%20of%20the,to%20convey%20hierarchy%20and%20meaning)). Components are designed with an **8px baseline grid** for balance and rhythm ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=All%20components%20align%20to%20an,a%204dp%20square%20baseline%20grid)), and interactive controls meet recommended touch target sizes (at least 48×48px with adequate spacing) ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=To%20ensure%20balanced%20information%20density,or%20more%20space%20between%20them)) for usability. - **Content over Chrome (Minimalism):** In line with minimalist principles, PrecisionCore interfaces present content and core features in a simple, direct way with as little distraction as possible ([The Roots of Minimalism in Web Design](https://www.nngroup.com/articles/roots-minimalism-web-design/#:~:text=When%20employed%20correctly%2C%20the%20goal,the%20interface%20or%20its%20users)). Unnecessary ornamentation, gradients, or clutter are removed so that users can focus on tasks without extraneous visual noise. Every UI element must justify its existence; if it doesn’t support a primary user goal, PrecisionCore suggests eliminating or simplifying it. This “less is more” approach results in clean screens, ample whitespace, and an overall interface that feels **open and approachable**. - **Refined Elegance (Apple):** Borrowing from Apple’s Human Interface Guidelines, PrecisionCore values **clarity** (legible text, precise controls) and **deference** (the UI should defer to content) ([What is iOS Human Interface Guidelines?](https://pangea.app/glossary/ios-human-interface-guidelines#:~:text=At%20the%20core%20of%20the,to%20convey%20hierarchy%20and%20meaning)). Visuals are crisp and polished – from high-contrast text to smooth micro-interactions – giving the system a modern, premium feel. Subtle effects (like soft shadows or gentle highlights) are used sparingly to create depth and affordances without overwhelming the user. The result is an interface that feels *delightful* and **intuitive**, exhibiting “simplicity carried to an extreme” which becomes elegance (as famously espoused by Apple’s design ethos). - **Nostalgic Structure (Windows 98):** Finally, PrecisionCore infuses a hint of nostalgia by channeling the pragmatic rigidity of classic late-90s interfaces. In those UIs, everything had clear boundaries and states – things were “so frickin obvious” to the user ([98.css – design system for building faithful recreations of Windows 98 UIs | Hacker News](https://news.ycombinator.com/item?id=22940564#:~:text=I%20can%27t%20believe%20how%20intensely,but%20credit%20where%20it%27s%20due)). PrecisionCore revives that sense of obviousness through clearly delineated panels, buttons with distinct states, and straightforward iconography. For example, buttons have clear outlines or shadows to indicate pressability, and modal dialogs resemble classic window frames (complete with a title bar), instantly signaling their function. This throwback to “classic UI” is done with subtlety – providing familiarity and **predictability** (users never have to guess if something is clickable) without looking dated or heavy. As one observer noted, older UIs minimized cognitive load by avoiding ambiguity ([98.css – design system for building faithful recreations of Windows 98 UIs | Hacker News](https://news.ycombinator.com/item?id=22940564#:~:text=I%20can%27t%20believe%20how%20intensely,but%20credit%20where%20it%27s%20due)); PrecisionCore embraces that lesson, ensuring every interactive element is visually distinctive and every state change (hover, active, disabled) is unambiguous. **Light-first, Dark-ready:** By default, PrecisionCore is designed in a **light mode** aesthetic (bright backgrounds, dark text, vibrant accent colors), as light mode tends to be the most common environment for general-purpose apps. However, from its inception the system is built to support an equally robust **dark mode**. This means color palettes, component designs, and shadows have been chosen to invert gracefully. The design philosophy encourages using a *dark gray* (not pure black) for dark backgrounds to reduce eye strain and preserve depth (e.g., shadows on pure black are hard to see) ([docs/theming/Dark.md · mevermore/material-components-android - Gitee](https://gitee.com/mevermore/material-components-android/blob/master/docs/theming/Dark.md?skip_mobile=true#:~:text=use%20of%20the%20,themes%20also%20provide)). All guidelines – from color contrast to elevation – have been considered in both light and dark contexts, and developers are given clear instructions on how to implement theme switching. (See **Color & Theming** for details.) Overall, the PrecisionCore philosophy is about **precision in execution and core essentials in experience**. Users should find interfaces built with PrecisionCore **familiar** yet fresh – as if the best ideas of past and present UI design have been distilled into one system. By following this design system, designers and developers can create apps that are visually consistent, easily extensible, and appealing to a broad range of users. The following sections detail the specifics of this system – from grids and spacing to components and code examples – providing a foundation as polished and complete as official design guidelines from Google, Apple, and Microsoft. ## Color & Theming PrecisionCore uses a carefully chosen color palette that works in both light and dark themes. The system defines a set of **core colors** (with recommended defaults) and guidelines for their usage: - **Primary Color:** A vivid but not overwhelming hue used for main interactive elements, highlights, and emphasis. By default, PrecisionCore’s primary color is a medium **blue** (#3388FF) – evoking the classic Windows 98 selection blue, but with a modern vibrancy. This blue serves as the accent for buttons, links, selection states, and active indicators. It contrasts well against light backgrounds and is adjusted for dark mode (slightly desaturated or brightened as needed) to maintain clarity. - **Secondary Color:** An optional accent or complementary color (for example, a green or orange) used sparingly for secondary actions, highlights or to distinguish different types of messages (like success or warning states). The secondary palette is meant to complement the primary blue and adhere to the minimalist approach (e.g., used in icons or subtle backgrounds rather than large areas). - **Neutrals (Backgrounds & Surfaces):** In light mode, the background is generally a clean **white** or very light gray (#FFFFFF or #F8F8F8) for a fresh, minimal canvas. Surface elements (cards, navbars, modals) use neutral grays (ranging from #FAFAFA to #E0E0E0) to differentiate layers. In dark mode, instead of pure black, a **dark gray** (e.g., #121212 or #1E1E1E) is used for backgrounds ([docs/theming/Dark.md · mevermore/material-components-android - Gitee](https://gitee.com/mevermore/material-components-android/blob/master/docs/theming/Dark.md?skip_mobile=true#:~:text=use%20of%20the%20,themes%20also%20provide)). This dark gray improves shadow visibility and reduces the stark contrast of pure black on modern displays, thereby easing eye strain ([docs/theming/Dark.md · mevermore/material-components-android - Gitee](https://gitee.com/mevermore/material-components-android/blob/master/docs/theming/Dark.md?skip_mobile=true#:~:text=use%20of%20the%20,themes%20also%20provide)). Surfaces in dark mode are slightly lighter dark grays (#2A2A2A, #333) to stand out from the background. Text in dark mode is a near-white (#EAEAEA) rather than pure white, to avoid glare. - **Text Colors:** High contrast is a must. Standard body text in light mode is **charcoal/black** (#212121) on white, meeting at least WCAG AA contrast. In dark mode, body text is a light gray-white (#E0E0E0) on dark backgrounds. Muted or secondary text can use mid-grays (#666 in light mode, #AAA in dark) but always ensure readability (never falling below a 4.5:1 contrast ratio against the background) ([Dark Mode | Apple Developer Documentation](https://developer.apple.com/design/human-interface-guidelines/dark-mode#:~:text=Dark%20Mode%20,contrast%20ratio%20of%207%3A)). PrecisionCore follows accessibility guidance that even non-text elements (like icons or borders) should have sufficient contrast – e.g. an outline or icon should be at least 3:1 against its background ([Color contrast - Accessibility designing – Material Design 3](https://m3.material.io/foundations/designing/color-contrast#:~:text=Color%20contrast%20,Consider)). - **States and Feedback Colors:** Standard semantic colors are included for states like success (e.g., a green #28A745), warning (amber/orange), error (red #DC3545), and info (blue or cyan). These are used for icons or text messages (e.g., error text for form validation). They are designed to be legible on both light and dark backgrounds by slightly adjusting their brightness/saturation between themes (for instance, error red might be slightly lighter in dark mode to appear vibrant on a dark surface). **Dark Mode Guidelines:** Designers should design in light mode first, then invert to dark mode and adjust. When creating a dark theme, **avoid pure black** backgrounds; use dark gray as mentioned (e.g., Material’s baseline is #121212) ([docs/theming/Dark.md · mevermore/material-components-android - Gitee](https://gitee.com/mevermore/material-components-android/blob/master/docs/theming/Dark.md?skip_mobile=true#:~:text=use%20of%20the%20,themes%20also%20provide)). Ensure that text and UI elements in dark mode meet contrast standards (ideally ≥ 4.5:1 for body text) ([Dark Mode | Apple Developer Documentation](https://developer.apple.com/design/human-interface-guidelines/dark-mode#:~:text=Dark%20Mode%20,contrast%20ratio%20of%207%3A)). Additionally, consider using “on-dark” variants for shadows or dividers – e.g., a semi-transparent white at 15% opacity for dividers on dark backgrounds (instead of a gray) to achieve a subtle separation without harsh lines. Primary and secondary colors can generally remain the same hue, but check their vibrancy on dark backgrounds; sometimes increasing the brightness or adding a slight outer glow can maintain their visibility. For example, PrecisionCore’s primary blue (#3388FF) in dark mode might be tweaked to a slightly lighter blue (#5B9DFF) for links or buttons, ensuring it stands out on near-black. The design system provides tokenized color definitions for both modes. **CSS Custom Properties Example:** PrecisionCore provides CSS variables to manage theming easily. In the light mode stylesheet (or `:root`), variables define the palette. For dark mode, a `.dark` class or `[data-theme="dark"]` attribute on a parent element can override those variables: ```css :root { --pcore-bg: #FFFFFF; --pcore-surface: #F8F8F8; --pcore-text: #212121; --pcore-text-muted: #666666; --pcore-primary: #3388FF; --pcore-primary-text: #FFFFFF; --pcore-border: #CCCCCC; /* ...other vars */ } .dark { --pcore-bg: #121212; --pcore-surface: #1E1E1E; --pcore-text: #EAEAEA; --pcore-text-muted: #AAAAAA; --pcore-primary: #5B9DFF; /* slightly brighter blue for dark mode */ --pcore-primary-text: #FFFFFF; --pcore-border: #444444; } ``` In your HTML, you could then toggle dark mode by adding the `dark` class to `` or ``, and all components will adapt automatically by using these variables for colors. **TailwindCSS Theming:** If using Tailwind, PrecisionCore’s color palette can be integrated via Tailwind’s configuration (`tailwind.config.js`). Define a custom theme with the above colors (e.g., as `primary`, `surface`, etc.) and enable Tailwind’s built-in dark mode class strategy (`dark` class). For example: ```js // tailwind.config.js (excerpt) module.exports = { theme: { colors: { primary: '#3388FF', 'primary-dark': '#5B9DFF', surface: '#F8F8F8', 'surface-dark': '#1E1E1E', text: '#212121', 'text-dark': '#EAEAEA', /* ... */ } }, darkMode: 'class' } ``` Then in HTML you can use classes like `bg-surface text-text dark:bg-surface-dark dark:text-text-dark`. Tailwind also provides `dark:` variants for utility classes, so you might write: `
...
` to manually implement dark mode styles. **Theming Summary:** PrecisionCore supplies light and dark design tokens, encouraging developers to implement theme toggling either via CSS classes or media queries (`prefers-color-scheme`). All components and examples in this document are provided in light mode by default, but include notes or examples for dark mode adjustments. By adhering to these color and theming guidelines, your app will be comfortable to use in a variety of environments (bright office, dark room, OLED mobile screen, etc.), all while preserving a consistent brand identity. ## Typography Typography in PrecisionCore is chosen for **legibility, scalability, and a hint of nostalgia**. The default typeface is a clean sans-serif, aligning with the system fonts of each platform for familiarity and optimal rendering. For example, the recommended font stack might be: ```css font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; ``` This stack uses the user’s system UI font (San Francisco on Apple devices, Segoe UI on Windows, Roboto on Android, etc.), ensuring text feels *native* on every device. It also pays homage to classic GUI fonts (Segoe UI was a cornerstone of Windows design). **Font Sizes & Scale:** PrecisionCore uses a **modular scale** derived from an 8px baseline grid for vertical rhythm ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=All%20components%20align%20to%20an,a%204dp%20square%20baseline%20grid)). Base body text is typically **14px** (roughly 0.875rem) for desktop for a dense but readable display, and can scale up to 16px (1rem) for mobile devices for readability. Heading styles increment by roughly 1.25× to 1.333× ratios: - Body/Text: 14px (0.875rem) – primary content, forms, labels. - Small Text/Caption: 12px (0.75rem) – secondary info, hints. - H3/Subsection Title: ~16px (1rem) – section headings. - H2/Modal Title: ~20px (1.25rem). - H1/Page Title: ~24px (1.5rem) – used sparingly for page headers. These sizes are guidelines; the system is flexible as long as the baseline grid is maintained (e.g., line-heights in multiples of 4px). **Line-height** is set around 1.4 for body text for comfortable reading (e.g., 14px text -> ~20px line-height). Headings have tighter line-heights (~1.2) to keep them tied to their content block. **Weight & Style:** Use a minimal set of font weights to avoid confusion and maintain performance. Regular (400) for body, Medium/Semi-bold (500–600) for headings or emphasis, and perhaps Bold (700) for very important numbers or labels. Italics are rarely used except for occasional emphasis or terminology. Underlines are reserved for actual links (as per web convention), and even then, a subtle colored underline or dotted underline can be used to reduce visual noise unless needed for clarity. **Tone & Aesthetic:** The overall typographic tone is **utilitarian meets elegant**. It should remind users of productivity software (clear and focused) but with the polish of a modern app. Apple’s influence means text is given ample margin and is never too cramped; minimalism means we don’t use excessive font variants or decorative type. If a custom font is desired for branding, it should be high-legibility and tested in various sizes. (Think of Google’s use of Roboto or Apple’s use of San Francisco – functional yet distinct.) **Responsive Typography:** PrecisionCore recommends slightly adjusting font sizes at extreme breakpoints. For instance, on very large screens (desktop HD), bump base font to 15px or 16px for readability. On very small screens, ensure captions/labels don’t go below 12px, and consider using relative units (rem/em) so that user browser settings for font size can gracefully scale the UI. The design system’s typography is designed to work with user preferences – if a user has increased their base font size for accessibility, the UI should scale accordingly (thanks to using rem units). **Vertical Rhythm:** All text sits on a 4px baseline grid ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=All%20components%20align%20to%20an,a%204dp%20square%20baseline%20grid)). This means margin/padding around text elements come in increments of 4px or 8px to ensure consistent spacing. For example, a heading might have 8px margin-top and 4px margin-bottom, aligning neatly with the spacing system. Consistent line heights (e.g., 20px for 14px text, 24px for 16px text) also snap to the grid to avoid misalignment between text lines and other UI elements. **Examples:** - A form label might be 14px, semi-bold, with 4px letter-spacing in uppercase for a subtle nod to old-school form labels (which were often all-caps), but this is optional. - Button text is typically **14px Medium**, using uppercase for primary buttons to resemble Material Design and classic buttons (again, optional based on preference). In code, a simple example for a heading and body text: ```html

Analytics Dashboard

Welcome back, user! Here are your stats for this week.

``` ```css .page-title { font-size: 1.5rem; /* 24px */ font-weight: 600; margin: 0 0 0.5rem 0; } .body-text { font-size: 0.875rem; /* 14px */ line-height: 1.4; margin: 0; } ``` **TailwindCSS Equivalent:** Using Tailwind’s utilities and perhaps custom font sizing: ```html

Analytics Dashboard

Welcome back, user! Here are your stats for this week.

``` (Tailwind’s default `text-base` is 1rem/16px, so one might configure `text-base` to 0.875rem in Tailwind config to match our 14px base.) By following these typography rules, PrecisionCore ensures text is always readable and harmonious with the overall design, whether on a small mobile screen or a 4K monitor. ## Layout, Grid & Spacing A solid layout foundation is critical. PrecisionCore uses a **responsive 12-column grid** (like many modern systems) with an **8px base unit** for spacing and sizing ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=All%20components%20align%20to%20an,a%204dp%20square%20baseline%20grid)): - **8px Grid System:** All measurements – margins, paddings, component dimensions, and placements – align to an 8px increment. This doesn’t mean every gap is 8px, but rather that all spacing values are multiples of 8 (or 4, for finer adjustments). For instance, a card might have 16px padding (2 × 8), a gutter between columns might be 24px (3 × 8) on desktop, or 8px on mobile. Using an 8px grid simplifies layout decisions and keeps visual harmony ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=All%20components%20align%20to%20an,a%204dp%20square%20baseline%20grid)). (Material Design also uses 8dp extensively for this reason.) - **12-Column Responsive Grid:** The page layout is divided into 12 columns with adjustable gutters. This allows flexibility – e.g., a form might use 6 of 12 columns (50% width) on desktop, but 12 of 12 (full width) on mobile. We provide breakpoint guidelines: - **Mobile (≤ 600px):** Simplified, mostly single-column or two-column layouts. Use full-bleed content with 16px padding margins on the sides by default. The grid can collapse to 4 columns for finer control if needed (each ~25% width) on mobile, but generally a single column flow is preferred. - **Tablet (601px–1024px):** 12-column grid with gutters ~16px. You might use 2–3 columns for content. E.g., a sidebar might take 3 cols and content 9 cols. - **Desktop (≥ 1025px):** 12-column grid with wider gutters (24px). Content often centers with a max width (e.g., 1200px container) for readability on large screens. Side navigation (if present) can be a fixed 240px width column, and the remaining content uses the rest of the grid. PrecisionCore’s grid is **flexible**: you can nest grids for card layouts or split layouts into halves, thirds, etc., as long as you stick to the base spacing. Use CSS Flexbox or CSS Grid for actual implementation (the system is agnostic to method; you could use floats in older setups, though Flex/Grid is recommended). - **Spacing Scale:** We define spacers like 4px (minor), 8px (small), 16px (medium), 24px (large), 32px (x-large), etc. This scale is used for margin/padding of components: - Small elements (buttons, icons) often have 4px or 8px gaps. - Medium components (input fields, cards) might have 16px internal padding. - Large sections (between form sections or large grid gaps) use 24px or more. This consistent scale keeps the design cohesive. For example, a form label might have 4px bottom margin (to the input), fields 16px bottom margin to the next field, and form sections separated by 32px. - **Alignment & Keylines:** Align content to the grid and keylines. For instance, text baselines line up horizontally across columns when possible. Icons and text within a toolbar align on a 4px baseline grid for a neat appearance ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=All%20components%20align%20to%20an,a%204dp%20square%20baseline%20grid)). PrecisionCore encourages using **soft keylines** – subtle vertical rhythm lines at consistent intervals to guide placement (these aren’t visible, but you can imagine a vertical grid every 8px). This helps ensure consistent padding inside containers and alignment of elements in complex layouts. - **Example Layout Usage:** A typical page might have a header (taking full width), a content area using a 12-col centered grid, and a footer. Within the content, you could have a 2-column layout for desktop (8 cols for main content, 4 cols for a sidebar). On mobile, those would stack. PrecisionCore’s spacing guidelines ensure that the gutter between these columns is at least 24px on desktop (for clear separation) and maybe 16px on tablet, 8px on mobile. All of these follow the 8px rule. - **Visual Rhythm:** To avoid a dead, overly rigid look, not everything must be an exact multiple of 8px (e.g., 12px is allowed for line-height or subtle adjustments). But such exceptions are used intentionally. Most of the time, sticking to 8px increments (and sometimes 4px for fine tuning) will create a natural rhythm that users subconsciously appreciate. **Navigation & Structure** will be discussed next, but note that layout-wise, navigation elements (like sidebars or top bars) integrate with this grid system. For example, a sidebar might span 2 columns of the grid in a desktop layout, and the remaining 10 columns are the main content area. **Code Example – Responsive Grid:** Here’s how you might structure a basic responsive grid in HTML/CSS: ```html
Sidebar content
Main content
``` ```css .container { max-width: 1200px; margin: 0 auto; padding: 0 16px; /* gutter padding */ } .row { display: flex; flex-wrap: wrap; margin: -8px; /* negate child padding/gutter */ } .col { padding: 8px; } .col-4 { width: 33.333%; } .col-8 { width: 66.667%; } @media (max-width: 600px) { .col-sm-12 { width: 100%; } } ``` In this example, `.col-4` and `.col-8` are using a 12-col grid (4/12 and 8/12 respectively). On small screens, we override to full width (`col-sm-12`). We use 8px gutters. In real use, you might use CSS Grid with `grid-template-columns: repeat(12, 1fr)` and span columns as needed, or a framework’s grid. **TailwindCSS Equivalent:** Tailwind makes grids easy with its utility classes: ```html
Main content
``` Here we used `w-1/3` and `w-2/3` for 33%/66% columns (Tailwind also has a 12-column fraction utilities like `w-4/12`, etc.), and `sm:w-full` to stack them on small screens. We simulate gutters with padding (`px-2` which is 0.5rem, i.e. 8px, in Tailwind’s default config, aligning to our 8px grid). The container uses `px-4` (16px padding) and is centered. ## Navigation Structure Navigation components in PrecisionCore are designed to be straightforward, responsive, and consistent across desktop and mobile. The system supports common navigation patterns: - **Top App Bar / Header**, - **Sidebar / Drawer**, - **Tabs**, - **Breadcrumbs** (for secondary navigation), - **Footer** (for supplemental links). The **Top App Bar** is usually a full-width horizontal bar at the top of the app (or page). It typically contains the application’s logo or title on the left, and important actions or menu toggles on the right. PrecisionCore’s top bar draws from Apple’s simplicity and Material’s functionality: - It’s usually a solid color (often white or a light neutral in light mode, or a dark neutral in dark mode) or can optionally use the primary color for emphasis (like Material’s colored app bars). - It has a subtle shadow or a 1px bottom border to separate it from content (to echo Windows 98’s delineation of toolbars, we often use a simple border line). - The height is around 56px on mobile and 64px on desktop (to accommodate status bars and comfortably fit icons and touch targets ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=To%20ensure%20balanced%20information%20density,or%20more%20space%20between%20them))). For example, a header might look like this: ([image]()) *Example of a PrecisionCore header (top navigation bar with a title on the left and icons on the right), and a set of tabs below it for secondary navigation.* *(The header uses a white background with a bottom border, while the active tab is underlined in blue.)* The image above illustrates a **top navbar** with the app title “PrecisionApp” on the left, and two icon placeholders on the right. Below it is a **tab bar** with three tabs (“Home”, “Profile”, “Settings”), where “Home” is active (underlined in the primary blue). This structure is typical: a persistent top bar for global nav, and optional tabs for different views or sub-sections. **Sidebar / Drawer:** On larger screens, an app may use a left sidebar for navigation (e.g., a list of sections or a menu). PrecisionCore sidebars are plain and functional: - Typically a fixed width (say 240px) with a neutral background distinct from main content (light gray in light mode). - Menu items are arranged vertically, each item with an icon and label (if needed). Active item can be highlighted with the primary color background or an indicator bar on the side. - The style can subtly mimic classic menus (e.g., slight 3D pressed effect for active item, or just a solid highlight). However, by default it stays flat/minimal. - On mobile, this sidebar turns into a **drawer** that slides in from the left or appears as a hamburger menu. A hamburger icon in the top bar triggers it. The drawer covers the content with a semi-transparent overlay background when open. **Tabs:** As shown, tabs in PrecisionCore appear as a horizontal strip of text labels (or icons+text) that allow switching between views. The active tab is indicated by: - A bold text and a colored underline (Material influence), - Or alternatively, a pill-shaped highlight behind the active tab (for a more prominent look, though that’s less minimal). - In a nod to older interfaces, if appropriate, the active tab could also have a slight raised look (like Windows 98 tabs). This is optional and generally the flat style is preferred for modernity. - Tabs overflow smoothly to a dropdown or scroll if there are too many to fit, ensuring responsiveness. **Breadcrumbs:** If the app has deep navigation, breadcrumbs can be used (e.g., “Projects / Project Alpha / Settings”). PrecisionCore breadcrumbs are simple text links separated by “/” or chevron icons. They use the primary color for links and a muted color for the current page. Spacing around them aligns to the grid (maybe 8px between items). **Footer:** For web apps that need a footer (less common in app-like interfaces), PrecisionCore footers are minimal – typically a thin bar with secondary links or copyright info, using a very light background. **Responsive Behavior:** Navigation adapts to screen size: - On **mobile**, the top bar often contains a menu button (to open the sidebar as a drawer) and maybe a single context action (like a search or profile icon). Tabs can scroll horizontally if too many, or collapse into a dropdown. - On **desktop**, the sidebar can be persistent (always shown) and tabs display fully since there’s space. The top bar might show more actions with text labels (since hover is available for tooltips). - PrecisionCore encourages using the appropriate component per platform conventions: e.g., on mobile, a bottom navigation bar (like iOS’s tab bar with icons) could be used instead of top tabs if it makes more sense for the app. The design system supports that pattern too, with similar styling (icons, labels, primary color highlight for active). **Code Example – Top Bar and Tabs:** HTML: ```html

MyApp

``` CSS: ```css .app-header { display: flex; justify-content: space-between; align-items: center; background: #fff; border-bottom: 1px solid #ccc; padding: 0 16px; height: 56px; } .app-title { font-size: 1rem; font-weight: bold; margin: 0; } .app-actions .icon-button { background: none; border: none; font-size: 20px; margin-left: 16px; cursor: pointer; } .tab-bar { display: flex; background: #f8f8f8; padding: 0 8px; } .tab { flex: 1; padding: 12px 0; border: none; background: transparent; font: 1rem sans-serif; cursor: pointer; color: #555; border-bottom: 3px solid transparent; } .tab.active { color: #000; font-weight: 600; border-bottom: 3px solid #3388FF; } ``` This snippet creates a responsive header with a menu and notification icon, and a tab bar. On mobile, you might hide the words “MyApp” in favor of just an icon due to space, or vice versa show more icons on desktop. **TailwindCSS Equivalent:** ```html

MyApp

``` You would then add a class (e.g., `border-blue-600 text-black`) to the active tab via a script or a server-side render for the active page. Tailwind’s utility classes allow quick styling; here we used `border-b-4` to mimic the underline. (Note: 4 corresponds to 4px in default Tailwind, not 3px, but that’s fine, or Tailwind can be configured.) Using these navigation patterns, your app will have a clear and familiar structure. Users will find the menu locations and behaviors unsurprising, which is exactly the intention – **predictable navigation = better UX**. ## Components PrecisionCore provides a rich library of UI components, each designed with detailed styles, states, and behaviors. Below we cover the major components, including design guidelines and code examples in both standard HTML/CSS and TailwindCSS. Each component in PrecisionCore is designed to be **accessible**, **responsive**, and easily themeable. ### Buttons & Actions Buttons are fundamental interactive elements. In PrecisionCore, buttons combine the flat, modern look of Material Design with subtle retro cues (like clear borders or inset shadows on click) from classic GUIs. The design system defines several types of buttons: - **Primary Button:** Used for the main call-to-action. Visually distinguished with a solid fill (usually the primary color) and white or light text. - **Secondary Button:** Used for secondary actions. Typically has a softer style – often a light background (gray or neutral) with a border, or an outline style. - **Outline (Ghost) Button:** Transparent background, colored border (usually primary color) and primary-colored text. Used for less emphasis or tertiary actions. - **Text Button:** No border, no background, just text (often primary-colored text). Used for the least emphasis (like a “Cancel” action or inline link-style button). - **Disabled state:** Any button type can be disabled, which in PrecisionCore means it is visibly faded (lower opacity) and non-interactive (no hover effects). The style often includes a dashed or gray-out text to communicate disuse. These buttons all share consistent **shape and spacing**: a small border-radius (e.g., 4px) for slightly rounded corners (to soften the look, avoiding harsh 90° corners of pure Win98, but still squarer than overly-round modern buttons), and padding that provides a comfortable touch target (8px tall padding typically, resulting in ~36px tall buttons, meeting the ~48px including text height and paddi ([Metrics & keylines - Layout - Material Design](https://m1.material.io/layout/metrics-keylines.html#:~:text=Avatar%3A%2040dp%20Icon%3A%2024dp%20Touch,target%20on%20both%3A%2048dp))0】). Buttons have clear focus indicators for keyboard users – e.g., an outline or glow when focused. **States:** PrecisionCore buttons have distinct states: - *Default:* As described (filled or outlined). - *Hover:* In light mode, the primary button might darken slightly on hover (e.g., #3388FF to #2A76D2) or gain a subtle shadow. Secondary/outline buttons might get a light gray background on hover to indicate interactiveness. - *Active/Pressed:* When clicked or tapped, buttons might use an **inset shadow** to mimic a pressed look (a nod to Windows 98) or simply become a slightly darker shade. For example, a filled button might momentarily show an inset 2px shadow (giving a “pushed in” fee ([98.css – design system for building faithful recreations of Windows 98 UIs | Hacker News](https://news.ycombinator.com/item?id=22940564#:~:text=I%20can%27t%20believe%20how%20intensely,but%20credit%20where%20it%27s%20due))2】. This reinforces the action feedback. - *Disabled:* Reduced opacity (e.g., 50%) and no shadow or hover change. The cursor also becomes default (not pointer) to indicate it’s not interactive. ([image]())e】 *Examples of various button styles in PrecisionCore’s light theme: a blue primary button, a gray secondary button, an outline button, and a disabled button.* The image above shows (from left to right) a **Primary Button** (filled blue), a **Secondary Button** (gray background, for a less prominent action), an **Outline Button** (white background with blue border and text), and a **Disabled** primary button (faded). These demonstrate the default appearance of each type. Notice the Primary button has a slight shadow and solid fill, Secondary has a bordered rectangle style (almost like a classic UI button but flat), the Outline is very minimal until hover (not shown), and Disabled is semi-transparent. All have 4px rounded corners and consistent padding. **HTML/CSS Example (Button):** ```html ``` ```css .btn { font: 14px "Segoe UI", sans-serif; padding: 8px 16px; border: 1px solid transparent; border-radius: 4px; cursor: pointer; } .btn.primary { background-color: #3388FF; border-color: #2A76D2; color: #fff; } .btn.primary:hover { background-color: #2A76D2; } .btn.primary:active { /* simulate pressed with inset shadow */ box-shadow: inset 2px 2px 4px rgba(0,0,0,0.2); } .btn.secondary { background-color: #F5F5F5; border-color: #CCCCCC; color: #222; } .btn.secondary:hover { background-color: #E0E0E0; } .btn.outline { background: #fff; border-color: #3388FF; color: #3388FF; } .btn.outline:hover { background: #E6F0FF; } .btn:disabled, .btn.disabled { background: #DDD; border-color: #CCC; color: #888; cursor: not-allowed; } ``` In this CSS: - `.btn` sets base style (padding, font). - `.btn.primary` etc. set variants. We use a slightly darker border on primary for contrast (blue on blue). - The `:active` state of primary uses an inset shadow to give that pressed effect. - Disabled style grays everything out. **TailwindCSS Example:** Using Tailwind utility classes, the equivalent of a primary and secondary button: ```html ``` Here: - Primary: `bg-blue-600` (blue), `hover:bg-blue-700` for hover darken, `focus:ring-2 focus:ring-blue-300` for focus outline. Tailwind doesn’t have an inset shadow utility by default, but one could add a custom style or use `active:shadow-inner` if configured. - Secondary: gray background and border via `bg-gray-100 border border-gray-400`, etc. In summary, Buttons in PrecisionCore are accessible (use `

This is a modal dialog. It appears on top of the main content, requiring user interaction.

``` CSS: ```css .backdrop { position: fixed; top: 0; left: 0; right: 0; bottom: 0; background: rgba(0, 0, 0, 0.4); /* a semi-transparent black overlay */ } .modal { position: fixed; top: 50%; left: 50%; transform: translate(-50%, -50%); width: 320px; background: #F0F0F0; border: 1px solid #888; box-shadow: 2px 2px 8px rgba(0,0,0,0.5); } .modal-header { background: #3388FF; color: #FFF; padding: 8px; display: flex; justify-content: space-between; align-items: center; } .modal-header .title { font-size: 14px; font-weight: bold; } .close-btn { background: #FFF; color: #3388FF; border: none; width: 20px; height: 20px; text-align: center; line-height: 18px; font-size: 18px; border-radius: 4px; cursor: pointer; } .modal-body { background: #FFF; color: #222; padding: 16px; font-size: 14px; } .modal-footer { background: #F0F0F0; text-align: right; padding: 8px; } .modal-footer .btn { margin-left: 8px; } ``` Notes on this CSS: - The modal is fixed positioned (so it stays centered even on scroll) and uses a CSS transform to center it. - We gave it a slight border and a shadow to lift it off the backdrop. - The header is blue with white text – we also styled the close “X” as a white square button to fit the retro style a bit (white button on blue bar, akin to old Windows title bars which had a gray “X” button). This `close-btn` changes color on hover perhaps (could add `.close-btn:hover { background: #e0e0e0; }` for effect). - The body and footer are separated just by background colors here: body white, footer light gray. You could also keep them unified and just have the buttons at bottom. - The buttons reuse the earlier `.btn` styles (with classes `primary` and `secondary`). **Behavior & JavaScript:** Not shown here, but the close button `×` would be wired to close the modal (removing it and the backdrop from DOM). Clicking the backdrop could also close the modal (if allowed), except for critical confirmations where you might require an explicit choice. Ensure focus is trapped inside the modal when open (using JS to loop tab focus or using `inert` attribute on background content in modern browsers). Also, pressing `Esc` should close the modal for accessibility. **TailwindCSS Example:** Tailwind utilities can style a modal quickly: ```html
Modal Title

This is a modal dialog. It appears on top of the main content, requiring user interaction.

``` This uses Tailwind’s utilities for layout and spacing. We used `rounded-t` and `rounded-b` to give the modal a slightly rounded top and bottom corners (though in our CSS above we didn’t round the corners explicitly). One could also remove rounding for a more rectangular look. The close button is styled inline (white circle with blue X, here we did blue background text on white just to illustrate). PrecisionCore modals are designed to ensure the user’s focus is not lost: the backdrop prevents interaction with background, the active elements are clearly in the modal. By following these patterns, modals will feel **native and user-friendly**. They combine the best of old-school dialogs (title bars, clear separation) with modern simplicity (flat design, smooth animations). **Other Overlays:** For completeness, tooltips might be implemented simply as: ```css .tooltip { position: absolute; background: #333; color: #FFF; padding: 4px 8px; font-size: 12px; border-radius: 4px; pointer-events: none; opacity: 0; transition: opacity 0.2s; } .tooltip.show { opacity: 1; } ``` And dropdown menus (context menus) as: ```css .menu { position: absolute; background: #FFF; border: 1px solid #CCC; box-shadow: 0 2px 4px rgba(0,0,0,0.2); list-style: none; margin: 0; padding: 4px 0; } .menu-item { padding: 4px 12px; font-size: 14px; color: #222; cursor: pointer; } .menu-item:hover { background: #F0F0F0; } ``` These follow similar styling philosophies – flat, lightly bordered, subtle shadows, and clear highlight on hover. They can be theme-adjusted (dark menus on dark mode, etc.). With modals and overlays, **accessibility** is key: always provide `aria-labels`, `role="dialog"` for modals, focus management, etc. PrecisionCore’s provided code ensures these attributes are considered (though not all are shown in the snippet, developers should include them). ### Additional Components *(Beyond the major components above, PrecisionCore includes patterns for other common UI components, ensuring they match the overall design language. A brief overview is given below.)* - **Cards & Containers:** A “card” is a container for content (like a user info card or a dashboard stat box). PrecisionCore cards have a white (or surface color) background, a 1px light border or subtle shadow for separation, and a border-radius of 4px. They have consistent padding inside (e.g., 16px). Cards can contain a header (maybe with an icon or small title text), body content, and possibly actions (like buttons or links) at the bottom. They should align to the grid when in a series (e.g. in a dashboard, multiple cards of equal width per row). Our **Dashboard example** below will illustrate cards in context. - **Tables:** Table styles are minimal – we use clear separators for rows. Header row can have a slightly different background (light gray) and bold text. Borders between rows can be 1px solid #E0E0E0 (light gray), or zebra striping can be used as an alternative for readability. Table cells have padding (8px or 16px) for spacing. The design ensures tables look clean and not overly cramped, while also not as heavy as old-school spreadsheets. In dark mode, table header might be a darker gray, and stripes would be subtle dark variations. - **Alerts/Notifications:** An alert banner (e.g., success or error message) typically spans the top of a container or form. PrecisionCore alerts use the semantic colors with a light tint. For example, a success alert might be a green tint background (#E6F4EA) with a green icon and text, error alert a pink/red tint (#FDECEA with #D32F2F text). They have an icon (like ✓ or ⚠️) on the left, message text, and maybe a close icon on the right. They are padded (12px) and have a border-radius (4px) to differentiate from straight-edged layout sections. They should be full-width of their parent container typically. - **Icons:** The system doesn’t mandate a specific icon set, but recommends a **line-style or minimal solid style** icon that matches the font’s stroke weight. (Think Material Icons or Feather icons). Icons are used sparingly next to labels or in buttons. All icons should have alt text or aria-hidden as appropriate. - **Loading Indicators:** A simple spinner (perhaps the classic 3-quarter circle loop) or a progress bar is included. The spinner in light mode could be an animated SVG with the primary color. The progress bar is flat: a track (light gray) and a fill (blue or other color). It might have squared or slightly rounded ends. Indeterminate progress can use an animated stripe or a looping motion. Each of these components is documented with their states and variants in the full PrecisionCore spec (for brevity, not all code is shown here). The goal is that any piece of UI you need – from a data table to a nav drawer – has a defined style in PrecisionCore that meshes with everything else. ## Accessibility & Best Practices PrecisionCore is built with accessibility as a first-class concern, following WAI-ARIA guidelines and inclusive design principles. Adhering to these practices is essential for engineering teams: - **Color Contrast:** As noted, all text meets WCAG AA contrast (at least 4.5:1 contrast rati ([Dark Mode | Apple Developer Documentation](https://developer.apple.com/design/human-interface-guidelines/dark-mode#:~:text=Dark%20Mode%20,contrast%20ratio%20of%207%3A))7】 against its background. This includes text on buttons, labels on colored backgrounds, etc. We also ensure interactive graphics (like icons or focus outlines) have sufficient contrast. For example, the focus ring (blue) on a text field is designed to be visible even if the surrounding UI is blue-ish. In dark mode, using dark grey instead of pure black for background helps keep contrast of white text from being too high (which can cause visual vibratio ([docs/theming/Dark.md · mevermore/material-components-android - Gitee](https://gitee.com/mevermore/material-components-android/blob/master/docs/theming/Dark.md?skip_mobile=true#:~:text=use%20of%20the%20,themes%20also%20provide))5】, balancing comfort and readability. - **Keyboard Navigation:** All interactive elements (links, buttons, form inputs, etc.) are reachable via keyboard (tab order follows logical order). We include visible focus indicators. For instance, buttons might get a faint outline or a darker outline on focus, links might underline. No component should be focusable without a visible indicator. The design provides a default focus style (often a 2px outline in the primary color, or the browser default dotted outline if acceptable). Ensure that custom components (like our custom switch toggle or a custom dropdown menu) also handle `:focus` and `:focus-visible` states properly. - **ARIA Roles and Labels:** Use semantic HTML whenever possible (e.g., `