To keep our library high-quality and consistent, every submitted template must meet these core standards in design, structure, and usability. Templates that pass review are easier to customize, perform better, and give users a seamless Oxygen experience.

Style Guide required. Instructions optional.

Include a Style Guide page demonstrating all core elements: headings (H1–H6), body text, Text Links, buttons, lists, blockquote, and code blocks via the Rich Text Element. Use realistic copy — no lorem ipsum.

All interactive controls must have hover states defined using class States (:hover, :focus, :active).

Add an Instructions page (optional) for editors covering: Templating Conditions, Dynamic Data connections, ACF or Meta Box field mappings, Loop configurations, forms (if using Breakdance Forms for Oxygen), custom post types, custom code elements, or Interactions

Test like a user, not a designer. Templates must work end-to-end on all devices and match your demo exactly.

• Verify all links, forms, Interactions, and Dynamic Data connections.
• Preview across multiple devices and browsers.
• Confirm accessibility and PageSpeed pass baseline thresholds (see sections below).

Names should sound like brands, not SEO keywords. Thumbnails should sell the design.

• Name: Short, unique name (1–3 words). No trademarked or keyword-stuffed titles. Do not include "Oxygen" or "template."
• Thumbnail: 1200×1600px, no overlays, under 500kB (WebP).
• Description: 1–3 sentences explaining purpose, tone, and ideal audience. Mention key features briefly (e.g., "Ideal for small SaaS startups with pricing tables and testimonials ready."). Skip filler words like best, ultimate, or professional — focus on what makes it genuinely useful.

Consistency starts here. Oxygen's Variables system is how buyers restyle a site in minutes without touching individual elements. Every approved template must use it fully.

Before building, go to Oxygen > Variables and define your complete design system using Variable Collections. Use descriptive collection names like "Brand Colors," "Typography Scale," or "Spacing."

• Color variables: Define your full brand palette as Color variables. These must be used for every color control in the template — no raw hex codes on individual elements.
• Unit variables: Define your spacing and typography scale as Unit variables (e.g., 16px, 1.5rem). Use these for font sizes, padding, margin, and gap controls.
• Font Family variables: Register your fonts and assign them as Font Family variables. Apply these to all typography controls.
• Number variables: Use Number variables for layout values like grid column counts, border-radius tokens, and z-index layers.
• Image URL variables: Use Image URL variables wherever a default or overridable background image is needed (e.g., dynamic featured image backgrounds via Variable Override).

Variable Overrides may be used intentionally to create layout variants — such as alternate grid column counts — without duplicating classes.

All styling must live on classes. Oxygen's design system is class-based. After adding a class to an element, all styling is applied to that class and reused wherever it's needed.

• Every styled element must have a named class. No styling should exist only on a single element without a class.
• Manage all classes via the Selectors Panel for a clear, organized design system.
• Define States (:hover, :active, :focus, :focus-visible) directly on classes — not as inline overrides.
• Use Nested Selectors within classes to target sub-elements or pseudo-elements where needed.
• Typography: set a full scale (H1–H6, body, captions, buttons) as named classes with consistent line heights across breakpoints.
• Buttons: define base, hover, focus, and active states on classes. Do not override locally per element.
• Lock finalized utility classes (via Lock in Class Actions) to prevent accidental edits.

Structure defines quality. Good layout determines how easily buyers can restyle and maintain a template.

• Use Containers as the primary structural element. Each container should represent a clear content band (hero, features, testimonials, footer).
• Use Oxygen's Layout controls — gap, align, justify — for spacing. Avoid arbitrary padding or margin applied only to deeply nested child elements.
• Keep nesting shallow. Unnecessary depth hurts performance and makes editing harder.
• Apply semantic HTML tags (e.g., <section>, <article>, <nav>, <header>, <footer>, <aside>) via the element's tag settings in the Properties panel wherever appropriate.
• Use Container Link for fully clickable card or block patterns.
• Use Loop Elements (Post Loop Builder, Term Loop Builder, Repeater Field) only when genuinely needed for dynamic content — not as a substitute for static layout patterns.
• Custom Breakpoints may be added via Oxygen > Preferences when the default breakpoints are insufficient for the design.

Build once, reuse everywhere. Components are Oxygen's system for reusable, synchronized design blocks. When you edit a Component, the change propagates to every instance on the site.

• Use Components for any pattern that repeats across pages: navigation, footers, card designs, testimonial blocks, CTAs, pricing rows.
• Use Component Properties to expose editable content (titles, images, links) per instance while keeping layout and styles locked. Label properties clearly so buyers understand what's customizable.
• Name Components descriptively: e.g., Card / Blog Post, Section / Testimonials, Footer / Standard.
• Do not duplicate the same design as separate one-off elements — convert it to a Component.

Templates submitted to the library are distributed as Design Sets. Before submitting, go to Oxygen > Settings > Design Library and verify your Design Set configuration:

• Enable Turn This Website Into a Design Set.
• If your template relies on Variable Collections or class-based Global Settings, enable the appropriate prompts (This Design Set Relies on Global Settings, This Design Set Relies on Design Presets) so buyers are guided to import them correctly.
• Enable Copy From Frontend if buyers should be able to copy individual sections from the live demo.
• Test the Shareable URL to confirm it works from a clean Oxygen installation.

Use realistic, inclusive demo content. No lorem ipsum, no real brands.

• Match copy to the chosen vertical.
• Use placeholder logos.
• License all imagery (Unsplash, Pexels, Pixabay). Add descriptive alt text to every image.
• Write clear, inclusive copy. Avoid cultural or political references.

If your template includes dynamic pages (blog, archive, single post, custom post type), the following apply:

• Use Templating Conditions (via Oxygen > Templates) to assign templates to the correct content types. Document any non-obvious conditions on the Instructions page.
• Use Data Points to bind dynamic content (post title, featured image, custom fields) to elements cleanly — not hardcoded text with manual per-page overrides.
• If using ACF or Meta Box, list the required field groups and keys on the Instructions page so buyers know what to create.
• Paginated loops must use Oxygen's built-in Pagination controls — no custom JS pagination unless necessary and documented.
• Use Element Display Conditions to show or hide elements based on data state (e.g., hide a field if it's empty).

If your template includes Interactions:

• Interactions must work reliably on both desktop and mobile. Test entry and exit triggers.
• Do not use Interactions to replicate layout that should be handled by CSS.
• Document any Interaction-driven UI patterns (animated menus, scroll effects, modal triggers) on the Instructions page.
• Avoid Interactions that trigger on page load and cause layout shift — this will fail CLS requirements.

If your template includes forms, use Breakdance Forms for Oxygen (the official extension):

• Use the correct form element for the context: Form Builder for contact and lead forms, Login Form, Registration Form, and Comment Form where relevant.
• Configure and test at least one Form Action (email notification, stored submission, or integration). A form with no action will be declined.
• Style all form field states: default, focus, error, and success. Use Global Settings to define form styles consistently across the template.
• Document any required Form Actions setup on the Instructions page.
• Because the Form Builder is a Breakdance Element, use the Design tab controls to style it — not classes. See Breakdance Elements for Oxygen for guidance.

Native Oxygen elements should be your default. Breakdance Elements are acceptable where native elements fall short — most commonly forms and WooCommerce pages.

If your template uses Breakdance Elements, style them via the Design tab controls, not classes. Because Breakdance Elements are composite, adding an Oxygen class only affects the root element — internal parts have their own more-specific CSS selectors that will override it. For shared styling across multiple elements, use Nested Selectors or the Selectors Panel.

Templates with unstyled or mismatched Breakdance Elements will be declined. See Styling Breakdance Elements in Oxygen

Design for clarity and action. Visitors should instantly see what to do.

• Single goal: One main CTA per page. Secondary actions stay subtle.
• Above the fold: Headline, value proposition, and main CTA visible without scrolling.
• CTA placement: Repeat after key sections and in the footer. Add a sticky CTA container on mobile.
• Hierarchy: Use color, size, and spacing to guide attention to the main action.
• Trust: Place testimonials, ratings, or logos near CTAs.
• Objections: Add a short FAQ or guarantee element near decision points.

Fast, smooth, and optimized for real users. Performance is part of design quality.

Google PageSpeed targets:

• Mobile: ≥ 90 overall
• Desktop: ≥ 95 overall
• LCP ≤ 2.5s
• TBT ≤ 200ms
• CLS ≤ 0.1

GTmetrix targets:

• Performance ≥ 90
• Structure ≥ 90

Other requirements:

• Optimize all images (WebP, ≤ 300kB per image).
• Lazy-load large media. Use HTML5 Video element with lazy loading for background videos.
• Avoid heavy third-party JS. Use Oxygen's built-in Interactions for animations and transitions — do not reach for external libraries unless absolutely necessary and documented.
• Use SVG Icon elements for icons rather than icon font libraries.
• Test both the homepage and at least two inner pages.

Accessible design is part of quality. Every template should be usable, readable, and navigable by everyone.

• Color contrast: Minimum 4.5:1 for body text; 3:1 for large or bold text. Define compliant values inside your Variable Collections.
• Alt text: Every Image element must include accurate, descriptive alt text.
• Headings: One H1 per page, with logical H2–H6 hierarchy. Set the correct HTML tag on Text elements via Properties.
• No autoplay audio or video. HTML5 Video elements may autoplay only if muted.
• Keyboard navigation: All interactive elements — links, buttons, form fields, interactive Components — must be reachable and operable via keyboard. Verify :focus and :focus-visible states are defined on classes.
• Semantic landmarks: Use the correct HTML tags on Containers (<header>, <nav>, <main>, <section>, <footer>, etc.) so screen readers understand the page structure.

We value craft, not volume. Templates that succeed are polished, intentional, and built to last.

• Submitting large numbers of low-effort designs will not improve visibility or ranking.
• Review prioritizes quality, usability, and originality — not upload frequency.
• Each submission must feel complete: tested, documented, and visually refined.
• Designers who consistently meet or exceed standards will see their work featured more prominently.
• Excessive low-quality or repetitive submissions may result in temporary limits or removal from the program.