# ThinkRank Admin Styles

This directory contains the organized SCSS files for the ThinkRank WordPress plugin admin interface.

## File Structure

```
src/admin/styles/
├── README.md                 # This documentation
├── _variables.scss          # Design tokens and SCSS variables
├── admin.scss              # Main stylesheet (imports all others)
├── components.scss         # Reusable UI components
├── dashboard.scss          # Dashboard-specific styles
├── settings.scss           # Settings page styles
└── content-brief.scss      # Content brief generator styles
```

## Import Order

The main `admin.scss` file imports styles in this order:

1. `_variables.scss` - Design tokens and SCSS variables
2. `components.scss` - Base UI components
3. `dashboard.scss` - Dashboard page styles
4. `settings.scss` - Settings page styles
5. `content-brief.scss` - Content brief generator styles

## File Descriptions

### `_variables.scss`
Contains all design tokens including:
- Color palette (primary, secondary, neutral colors)
- Provider-specific colors (OpenAI green, Claude orange)
- Typography scale (font sizes, weights, line heights)
- Spacing scale (consistent spacing units)
- Border radius values
- Shadow definitions
- Breakpoints for responsive design
- Utility mixins

### `components.scss`
Reusable UI components including:
- Base ThinkRank UI wrapper styles
- Button variants (primary, secondary)
- Form elements (inputs, selects, textareas)
- Loading states and error notices
- Badges and tooltips
- Responsive utilities

### `dashboard.scss`
Dashboard-specific styles including:
- Enhanced dashboard cards with gradients
- Provider-specific card themes (OpenAI, Claude, Briefs)
- Stat card layouts and animations
- Icon containers and status badges
- Responsive dashboard grid

### `settings.scss`
Settings page styles including:
- AI provider visual selector
- Provider button states and hover effects
- API key section styling
- Settings actions and form layouts
- Data management section
- Responsive settings layout

### `content-brief.scss`
Content brief generator styles including:
- Form layouts and card designs
- Button styling and spacing
- Model badge components
- Saved briefs section
- Content structure display
- Competitor analysis styling
- Responsive content brief layout

## Design System

### Colors
- **Primary**: Blue (#2563eb) for main actions and branding
- **Success**: Green (#22c55e) for positive states
- **Warning**: Orange (#f59e0b) for caution states
- **Error**: Red (#ef4444) for error states
- **OpenAI**: Green (#10a37f) for OpenAI provider
- **Claude**: Orange (#d97757) for Claude provider

### Typography
- **Font Family**: System font stack for optimal performance
- **Scale**: 12px to 36px with consistent ratios
- **Weights**: 400 (normal), 500 (medium), 600 (semibold), 700 (bold)

### Spacing
- **Scale**: 4px base unit (0.25rem) with consistent multipliers
- **Common**: 8px, 12px, 16px, 24px, 32px, 48px

### Shadows
- **Light**: Subtle shadows for cards and buttons
- **Medium**: Standard component shadows
- **Heavy**: Modal and dropdown shadows

## Best Practices

### SCSS Organization
1. Use variables for all design tokens
2. Group related styles in logical files
3. Use mixins for repeated patterns
4. Follow BEM-like naming conventions
5. Keep specificity low and avoid !important

### Responsive Design
1. Mobile-first approach
2. Use consistent breakpoints
3. Test on multiple screen sizes
4. Ensure touch-friendly interfaces

### Performance
1. Minimize CSS output
2. Use efficient selectors
3. Avoid deep nesting (max 3 levels)
4. Leverage CSS custom properties for theming

## Migration from Legacy CSS

The large `thinkrank-custom.css` file has been broken down into organized SCSS files:

- **Dashboard styles** → `dashboard.scss`
- **Settings styles** → `settings.scss`
- **Component styles** → `components.scss`
- **Variables** → `_variables.scss`

### Migration Status
1. ✅ Extract styles into organized SCSS files
2. ✅ Update build process to compile SCSS
3. ✅ Remove legacy `thinkrank-custom.css`
4. ✅ Add missing layout and component styles
5. ✅ Test build process and compilation

## Development Workflow

### Adding New Styles
1. Determine the appropriate file (component, page-specific, etc.)
2. Use existing variables when possible
3. Follow the established naming conventions
4. Test responsive behavior
5. Document any new patterns

### Modifying Existing Styles
1. Locate the style in the appropriate SCSS file
2. Make changes using variables when possible
3. Test across all affected pages
4. Update documentation if needed

### Creating New Components
1. Add base styles to `components.scss`
2. Use variables for colors, spacing, etc.
3. Include responsive behavior
4. Document the component usage

## Browser Support

Styles are designed to work with:
- Modern browsers (Chrome, Firefox, Safari, Edge)
- WordPress admin requirements
- Mobile and tablet devices
- High DPI displays

## Compilation

The SCSS files need to be compiled to CSS for production use. The build process should:
1. Compile SCSS to CSS
2. Add vendor prefixes
3. Minify for production
4. Generate source maps for development