|Updates to the documentation pages or text copy.
|New features, components, or far-reaching updates.
|Simple and localized updates.
|Commits that address or fix issues.
Each wildcard (*) should be replaced with short and semantic descriptions using kebab-case.
- Feature directories should be singular and title case:
- Components should be singular and title case:
- Svelte Actions should be singular, lowercase, and use Typescript:
- Tailwind Element stylesheets should be plural and lowercase:
- Documentation should be lowercase and use dashes:
- Tests should be suffixed with
*.test.ts, matching feature conventions:
Ensure relevant events bubble via event forwarding.
Slot names should be short, semantic, and agnostic. Avoid names that are too specific, such as
Use adaptive theme colors for component styling.
If you need to include miscellaneous attributes that were not defined as properties, use Svelte's
$$restProps. Be careful
though, this can overwrite the element's
$$props.class attribute. To avoid this, delete the
class key from
$$restProps. We recommend introducing a
prunedRestProps function as shown below.
- Each prop should be a single word, all lowercase, and semantic. Match Tailwind class names if possible.
- If you need multiple words, use camel-casing (ex:
- Typescript will automatically handle primitive types that can be trivially inferred, such as string, number, or boolean.
- Make sure to set relevant default values when possible.
- When an existing prop is modified, consider documenting an example if relevant.
Tailwind Class Props
For props that pass one or more CSS utility classes, make sure to import and append the
This resolves to a type of
string and allows our build process to identify props that support Tailwind Intellisense.
- Color props should follow standard CSS style conventions (ex:
colorfor text color).
- Never pass class props as arrays or objects, strings are always preferred (ex:
- Always pass the entire Tailwind class name. Tailwind does not support dynamic class names.
CSS Styling Conventions
Skeleton utilizes an opinionated set of conventions for defining structural and component props for CSS utility classes within components. Please review existing components for examples of this in practice.
The default classses for a component template element. Note the "c" is short for classes.
To dynamically modify classes based on a variable or prop, use a reactive statement as follows.
We use the following pattern to combine base and dynamic classes. Note the parent element classes includes
to enable arbitrary classes passed by the user via
- The first class should be an "id" class, which semantically describes the element for global overrides (ex:
- Then followed immediately by the reactive class set (ex:
Skeleton has a convention for implementing dynamic transitions within components. Please follow the guidelines below to ensure you are following our standard for this process.
TIP: You may reference existing components to view this in practice: Accordion
Define transition types in a
context="module" script tag so you can use it as generic for the standard script
Supply the generics in the standard
script tag attributes.
Define the following properties:
transition- default to
!$prefersReducedMotionStoreto adhere to the Reduced motion rules.
transitionIn- the transition on entry.
transitionInParams- the parameters for the entry transition.
transitionOut- the transition on exit.
transitionOutParams- the parameters for the entry transition.
See the dedicated Transitions page for examples of how to implement custom transitions for a component.
TIP: Review existing component pages to view how this is presented in practice: Accordions
transitionX props to
DocsShellSettings to indicate that dynamic transitions
Below are a few pitfalls we've encountered when creating Skeleton. Do your best to avoid these whenever possible.
- Never construct utility class names, Tailwind does not support this feature.
@applyin component files. This will bloat the stylesheet bundle size.
- Do not mix script-defined and inline Tailwind classes. Doing so can have a negative impact on the readability of the code.
- Avoid switch-case statements to create shorthand property values (ex: sm, md, lg). This restricts customization.
- Keep Skeleton icon library agnostic. Embed SVGs or unicode instead, which can be passed via a slot.