npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@wwnds/core

v1.8.0

Published

Vanilla CSS, HTML, and JavaScript implementations of the Norton Design System.

Downloads

2,101

Readme

@wwnds/core

Core version

A Sass implementation of the design system's foundations and styling for all components.

Usage

All usage guidance is provided in the developer guide.

Developing

The core library makes considerable use of Sass modules to structure its stylesheets and enable theming through the @forward...with syntax.

Conventions

We follow a handful of conventions to make our stylesheets more manageable and readable. All contributors should strive to follow these conventions.

  1. Declarations must be wrapped in a mixin. This ensures that declarations never leak on @forward or @use.
  2. Design token defaults should be expressed as abstract Sass variables. These aren't compiled and won't result in any CSS output.
    • For example: $duration-simple: 100ms;
  3. Sass variable tokens should be used to set the token as a CSS custom property prefixed with --nds-.
    • For example: --nds-duration-simple: #{$duration-simple};.
  4. System tokens (static properties associated with a foundation):
    • should be declared on the :root element. System tokens are foundational, and should be used globally.
    • should not be customizable. In other words, they should not include the !default flag.
  5. Role tokens (themeable properties associated with a foundation):
    • must be customizable with the !default flag. This makes it possible to override the value on @forward or @use.
    • should be named for their property or their role. If a token sets a single property, name it for its property. If it's used in a more abstract way, name it for what it is trying to accomplish (its role).
      • Property example: $background-color if it's used to set the background-color property.
      • Role example: $padding-y if it's used for both padding-top and padding-bottom.
  6. Component tokens (properties associated with a component):
    • should be set in a standalone tokens.scss file adjacent to the component's styles.
    • should be customizable with the !default flag.
    • should default to existing role tokens whenever possible.
      • Good 👍: $background-color: var(--nds-background-color) !default; (role token)
      • Okay 👍: $border-color: var(--nds-base-color-40) !default; (system token when no role token exists)
      • Bad 👎: $background-color: var(--nds-white) !default; (system token when a role token exists)
      • Worse 👎: $background-color: #fff !default; (raw value)
    • should be named for their property or their role. If a token sets a single property, name it for its property. If it's used in a more abstract way, name it for what it is trying to accomplish (its role).
      • Property example: $background-color if it's used to set the background-color property.
      • Role example: $padding-y if it's used for both padding-top and padding-bottom.
    • should not be prefixed. Component tokens are prefixed with the component's name when forwarded by the main entry point so including the prefix would result in a doubly-prefixed name (e.g., $tooltip-tooltip-border-radius).