heybokeh / pollen Goto Github PK

Since everything in pollen is now configurable, and whole modules can be disabled just by setting them to false in config, there doesn’t seem to be much sense in separating core/addon modules. It would be simpler to just enable everything by default, and document how to remove or overwrite stuff (which is already done)

Only downside is a larger default bundle, though it would still be well under 2kb. I think for the savings in cognitive overhead that’s worth it.

Not sure if I’d consider this a breaking change since all that’s changing is more stuff included by default?

Hey folks, I'm playing around with pollen and really like it so far ❤️

I'm using greys as a base for my pages and want to give them a slight touch of color - most often a cold (blue'ish) or a warm (yellow'ish) touch, to make the overall page design feel either colder or warmer.

What I'm doing so far is taking the pollen greys to a color picker and then adding a touch of blue/yellow eye-balling the results.

Do you think this is a use case pollen should support in its color palette?

I have been looking at the competition 👀 🙈 how they do it, and it seems like they have Slate and Stone for cold/warm greys, respectively.

Currently variables are generated in this fashion:

:root {
  --scale-0: 1rem;
  --scale-1: 1.125rem;
  --scale-2: 1.25rem;
  --scale-3: 1.5rem;
  --scale-4: 1.875rem;
  --scale-5: 2.25rem;
  --scale-6: 3rem;
  --scale-7: 3.75rem;
  --scale-8: 4.5rem;

Would it be possible to omit :root { to support scoped usage? Eg. in shadow DOM.

I am really liking what you're doing here,
and I also read your Dev.to article, that sadly got a lot of hate from TailwindCSS fans.

But back to the feature request 😉

I also created a CSS framework using both CSS Utilities, CSS Components and Native Components,
powered also through CSS variables.
And I offer import options for both Sass and CSS (PostCSS).

I was wondering If you are also planing to offer the CSS variables in a SCSS file.
This would give your framework even more flexibility to be used in different CSS environments.

Not a must, just curious if you open to this option.

While Pollen isn't exactly a heavy library, I don't like the idea of deadweight in a codebase. The colour palette is both the heaviest part of the library (0.4kb gzip) and the least likely to be used as a project matures and leaves prototyping, since most projects end up with their own custom colour palette.

We could split the library into a core with addons, as separate CSS files. Pollen core (typography, layout, and UI) would then be 0.9kb (and can tout being "under 1kb"), and you could easily eject colours once you're done prototyping and have a custom palette.

Could even split every module into its own file, but that seems excessive. Colours stand out to me as something that may not belong in a long-lived design system foundation, the rest feels quite foundational.

This is a pattern that would allow new, less-core variables to be added as addons later too. Something like some tailwind-style grid template defaults comes to mind.

If I click Tweet it or the satchel link I get links without www which 404s.

PS. LOVE this project! It's everything I wanted a certain other CSS framework to be.

Peppercorn (this organisation) is winding down now that I'm focussing all my spare time on Bokeh. Give that org ownership of pollen + pollen-docs repos as it will be the primary at-scale user and maintainer of Pollen going forward.

https://github.com/heybokeh

I think it would be better to use rem like tailwind does for layout size definitions as well. If all sizes are based on rem then the user can change the default font size and the layout of the page will not break.

If you're open to the idea I can create a PR.

Thanks for this excellent library!

Pollen is now a whole new kind of tool — document how to customise it, extend it, and generate your own design systems.

Basics in here #46

• Update intro
• Update addons in getting started
• Add config instructions to addons
• Remove section: Theming
• New section: Configuration
• New section: Extending
• New section: Reactivity (from theming)
• Move "motivations" to bottom of the list, or remove
• Add config section to each submodule
• Flatten modules in docs? Typography → Font scale, Line height, etc?
• “Property group” → “Prefix” to match config api
• Add link / text to readme about generating own custom bundle

Thank you. This project is great. Simple, easy, and high value. I really appreciate this. And while I'm happy to just build, build, build with the defaults, we have some design standards that fall outside of those defaults.

Our current solution is overrides, but I can already see value in being able to generate values instead for the variables already defined in pollen. Both the colors addon and #42 are features that could leverage this.

Is there interest in supporting something like this as part of this project?

Example: Pseudo-TypeScript method of defining gray as #1e1e20 could yield this overly verbose result.

type Colors = {
  gray?: string;
  // other colors
}

let brandColors: Colors = {
  gray: "#1e1e20",
  // other colors
};

Pollen.build(brandColors);

    --color-gray-rbg: 30, 30, 30;
    --color-gray-100: #1e1e1e;
    --color-gray-80:  #4a4a4a;
    --color-gray-60:  #777777;
    --color-gray-40:  #a3a3a3;
    --color-gray-24:  #c7c7c7;
    --color-gray-16:  #d8d8d8;
    --color-gray-08:  #eaeaea;
    --color-gray-80a: rgba(var(--color-gray-rbg), .8);
    --color-gray-60a: rgba(var(--color-gray-rbg), .6);
    --color-gray-40a: rgba(var(--color-gray-rbg), .4);
    --color-gray-24a: rgba(var(--color-gray-rbg), .24);
    --color-gray-16a: rgba(var(--color-gray-rbg), .16);
    --color-gray-08a: rgba(var(--color-gray-rbg), .08);

Husky or just manually? Will see

Safari supports eye-popping colors using the the color() function. I wonder if it'd be neat to maybe add support for this with graceful fallback to regular old hex/hsl.

I have successfully used this on the Svelte Summit website and I think the result is pretty nice. You can see the difference by visiting on Chrome vs Safari.

It would be as simple as figuring out what colors that would be nice to have and then just adding support via something like this (example taken from the WebKit explainer page):

:root {
    --bright-green: rgb(0, 255, 0);
}

/* Display-P3 color, when supported. */
@supports (color: color(display-p3 1 1 1)) {
    :root {
        --bright-green: color(display-p3 0 1 0);
    }
}

Another idea is to support the lch() and lab() functions.

Here's a site where you can compare between the two - you need to use Safar on a Mac or iPhone to see differences.

The default colour palette is a bit cobbled together. Seeing it all in one place in the new graphic in the docs made me realise it could be tightened up a bit — the greyscale goes from neutral to blueish and back, and there are a few color families that are awfully similar.

Tracking issue for what Pollen v3 might look like

Addon architecture

• #31
• #35

Renaming properties and units

• #32
• #33
• #36

Misc

• #38
• #39
• #6

Doing a stream on pollen today made me realise elevation isn’t a very intuitive name for box shadows. It’s a hangover from when Pollen used more design based rather than semantic token names.

Aliasing this to shadow for now will make it a non-breaking change, and elevation can be removed in the next major version.

The width scale was lifted straight from Tailwind as an extension of the size scale. However now that Pollen has an extended prose width scale, based on character size, is there really a need for a dedicated scale for max-widths? It's needed in tailwind since they are classes, but as raw values it seems like an antipattern compared to encouraging people to use typgraphic-based widths.

Open for comment on this one since I'm not sure.

JSON output of the variable schema is implemented (thanks @shannonrothe!) now just gotta document it.

Also might change schema to json alongside css.

Once/if builder ships, config for enabling addons should be the only way to do it. Keeping the prebuilt files is only there for v3 compat.

See #46 for context

Pollen needs a way to support outputting queries to its final CSS. This would open up support of responsive variables (via @media) and progressive enhancement (via @supports) in a design system straight from config. The former has obvious strong use-cases, and #62 shows a good use case of the latter.

I haven’t yet thought of an elegant config API to support it, so this is a request for comment to get some ideas and feedback.

This project looks (concept-wise) really cool! I think it'd be an easy sell if there were something demoable to look at, to see what's possible with all the design tokens out of the box. I personally dislike Tailwind in terms of the utility classes mindset, but there's no denying it became popular quickly because it just presents extremely well and seems easy to pick up and run with.

Pollen inherited Tailwind's naming conventions for leading (line-height) and tracking (letter-spacing). These are the correct typographic names for these measurements, but developers are much more familiar with line-height and letter-spacing than leading and tracking.

With a probable v3 breaking change coming for #31, it might be a good opportunity to rename these and correct a possible misstep by Tailwind. But the full property names are too verbose, leading- and tracking- are at least nice and concise.

So I'm thinking:

• line- for line-height, eg: line-sm
• letter- for letter-spacing, eg: letter-tight

Not sure how much more memorable they are than leading- and tracking- though, since we already have measure- (which has no concise replacement I can think of) anyway

Even with a docs site what’s there now is pretty cryptic. Give a summary of the docs site home page and a very brief getting started guide, then link to site for API docs.

Or check Tailwind et al for best practices

Would there perhaps be a need for adding some basic CSS reset or normalization to Pollen? It could help with cross-browser inconsistencies.

The current size, width, and radius scales were borrowed pretty much directly from Tailwind, and as such are in rem units. However, outside of font sizes there is very little benefit to using rem units, and several downsides for a library like Pollen.

Downsides:

• More opaque autocomplete and docs (everyone roughly knows what a 4px border radius or 20px margin feels like, not so much 0.25rem or 1.25rem)
• Size, width, and radius scales aren't fully reliable, but vary depending on the root font size of the document. Especially problematic if the author doesn't have control over the environment (UI widgets, libraries, extensions, etc)

Uses:

• Scaling a whole interface by changing the root font size. I'd argue that having fine grain control over variables, which can already be globally responsive, is a better way to achieve this, and doesn't assume all 3rd party UI or styles are also in rem, but it is a valid use-case.

The typography scale will stay in rem, because users can still set browser font scaling (which only works with rem) independently of page zoom (which works with px).

Open to comment. It could technically be a breaking change, but considering all of these values have only been live in Pollen v2 for a week or so, and in 99% of cases rem === px, I think a minor verion bump would be fine.

From #55.

Potentially move Pollen's defaults from an argument provided to a config function, to a seperate import provided in pollen-css/defaults or something, and have pollen.config.js export a plain object instead.

Current implementation

module.exports = (pollen) => ({
  output: './styles/pollen.css',
  modules: {
    radius: { ...pollen.radius, xs: '2px', sm: '4px ' },
  }
});

Proposal

const pollen = require('pollen-css/defaults');

module.exports = {
  output: './styles/pollen.css',
  modules: {
    radius: { ...pollen.radius, xs: '2px', sm: '4px ' },
  }
};

This would be a breaking change and therefore needs to to resolved before shipping a final v4. I'm currently leading towards the former (current impl) as more of a standard pattern, especially since untouched keys (or keys with a value of true) inherit pollen defaults, which I think the current pattern communicates better. But open to arguments on the contrary.

It would be cool to be able to write tests against PRs for this project and I noticed jest isn't setup yet! Happy to take some time to look into this one if somebody doesn't get to it before me 👍🏼

And just roll up entire library into single default export / css file. The whole lib is <2kb, is it worth having individual modules, ensuring none cross reference each other, documenting it (and making Pollen seem heavier as a result), etc.

Probably not. Double check how much it weighs, check in with Tailwind et al, and then decide.

it seems

color addon not working.

Failed to find 'pollen-css/addons/colors.css'

I tried with cdn and also with npm install.

When exporting a JSON file, the custom colors seem not to be represented in the pollen.json file.

module.exports = (pollen) => ({
  output: {
    css: './.pollen/pollen.css',
    json: './.pollen/pollen.json'
  },
  modules: {
    color: { ...pollen.color, custom: '#AAAAAA' },
  }
})

I am assuming this is intentional. It would be nice to have them represented in that file, or having an option for that.

And link to existing gitbook docs. Very quick/rough mockup:

Opinionated pairings of line heights with the modular font scale for sans and serif font families.

• Applies to: font
• Property group: sans- and serif-

Values eg:

:root {
	--sans-0: var(--scale-0)/1.5, var(--font-sans);
}

Usage:

.paragraph {
  font: var(--sans-0);
}

I’m not a fan of pollen-css as a package name, but pollen is taken. The project using it seems abandoned, so perhaps try emailing the owner and see if he’d be willing to transfer?

I follow CSS projects on Twitter. I think creating your own Pollen Twitter account, for at the very least releases, would help expose this great project.

In the docs it says: --radius-round, but this variable does not exists and should be --radius-full

blur(4px) → blur(40px) becomes var(--blur-xs) → var(--blur-xl) and applies to backdrop-filter

Should probably go in core UI alongside elevation, since it serves the same purpose (add 3D depth to a surface), and 5 properties aren't really worth making an addon out of.

I've been using Pollen for the last 2 weeks and it's amazing.

I think that one addition that would be nice is a fluid sizing system. I've seen the same in Open Props although I think that their implementation is not great.

I know that I can configure fluid sizes myself, but it would be really great to have them out of the box since I think this is a good pattern that should be encouraged.

The Open Props implementation is very simple:

  --font-size-fluid-0: clamp(.75rem, 2vw, 1rem);
  --font-size-fluid-1: clamp(1rem, 4vw, 1.5rem);
  --font-size-fluid-2: clamp(1.5rem, 6vw, 2.5rem);
  --font-size-fluid-3: clamp(2rem, 9vw, 3.5rem);

but I think that this is too simple, since this means that fonts will shrink at different speeds and reach their min and max at different viewport widths.

What I have been using is based on this css-tricks article and it works perfectly. The downside with this method is, that it's not possible to use the --scale-X custom properties in CSS because it involves doing some math that can't be done with <dimension> types.

I'm not 100% sure how to solve this best, but one suggestion would be to add a linearClamp function that takes a viewport min and max width in px and a size min and max in rem and spits out the clamp([...]) property. This can then be used to generate the default values in pollen.css but also by users of the library to generate their own fluid sizes.

What do you think? If you like this idea I can create a PR to discuss this further.

Thin wrapper around css-vars-ponyfill that dynamically imports if needed, sanely configures, and inits it for plug n play usage of Pollen. Pass opts object straight to css-vars-ponyfill.

Maybe call it shimmie because that’s cute.

Need to figure out how to best distro it. Separate file in root of package? Named export in utils file in root of package? Probably the latter, gives room for more tools in future if needed.

import ‘pollen-css’;
import { shimmie } from ‘pollen-css/utils’;

shimmie();

Currently the official docs site is the only place you could see a list of all available tokens and their values and if you customize any of them, this would no longer stay in sync with the officially supported tokens.

By adding the ability to export a JSON (or yaml?) file with all customizations applied, you would be able to use this JSON output to generate your own dictionary reference/docs site so that your entire team can now stay in sync. It would also make it easier to build out utility classes out of the tokens as you could convert JSON to SCSS easily with existing packages.

Perhaps something like this in the config file?

module.exports = {
  outputjson: 'some/path/pollen.json',
  modules: {
    // Module config
  }
}

Example output could be something like:

{
  "size": {
    "0": "2px",
    "1": "4px",
    "2": "8px",
    "3": "12px"
  },

  "blur": {
    "sm": "blur(4px)",
    "md": "blur(8px)",
    "lg": "blur(16px)",
    "xl": "blur(24px)",
    "2xl": "blur(40px)"
  }
}

Need to rewrite the documentation for the Pollen rewrite, then put together a docs site and launch it. Already have the domain pollen.style, and maybe I should get whatever standard TLD I can too and alias it just in case (pollencss.{whatever}). Even I had never heard of the .style TLD before.

Keep it nice and simple — home page with an overview of features and motivations, docs one pager with sticky nav.

Carrying on from #32, with a probable v3 breaking change coming it could be a good opportunity to rethink some fundamentals that Pollen blindly inherited from Tailwind. Namely, inconsistent unit scales.

We currently use:

• Numerical (eg: --size-2)
• Sizes (eg: width-xs)
• Descriptive (eg: tracking-tight).

If Pollen was to standardise on a scale I feel like it should be numeric, since that's the most obvious, extensible, and easiest to understand.

Great discussion on Tailwind that was abandoned due to breaking change friction on a large project: tailwindlabs/tailwindcss#1277

So it doesn't muddy up the existing --font- families. Offshoot of #46

Measure might be the correct typographic name for the width of a block of text, but it's pretty unintuitive for developers, where measure has so many other meanings (like, measuring something).

Tailwind has a single value for this, called max-w-prose, which isn't exactly elegant. Maybe --prose- or --text-width-

Per this issue comment (#46 (comment)) and this one (#47 (comment)), I'm glad that there will be a pollen.config.js to extend pollen. I'm just wondering that it might be a good idea to add a little sugar to the config file without forcing the non-typescript users (at this point of writing, I don't know whether pollen's config file supports the .ts extension or not) to use JSdoc annotation for /** @type import("pollen.Config") */.

I'm suggesting something like Vite's (link) and WindiCSS' (link) config file.

So, it would be something like:

/** pollen.config.js */
import pollen, { defineConfig } from "pollen";

export default defineConfig({
  output: 'styles/pollen.css',
  modules: {
    font: { sans: `"Inter", sans-serif` },
    letter: { ...pollen.letter, sm: '-0.02em' },
    radius: { ...pollen.radius, xs: '4px ' },
    grid: { ...pollen.grid, pageGutter: 'var(--grid-gap)' },
    color: {
      grey100: '#f2f4f7',
	  ...
    }
  }
})

Or, if import pollen from "pollen" sounds like a no for you, because you might need to export some other things on the pollen.js file, we could make the exported configs on a separate file (this wouldn't cause any breaking change tho).

import { defineConfig } from "pollen/helpers";
import { letter } from "pollen/typography";
import { radius } from "pollen/ui";
import { grid } from "pollen/grid";

export default defineConfig({
  output: 'styles/pollen.css',
  modules: {
    font: { sans: `"Inter", sans-serif` },
    letter: { ...letter, sm: '-0.02em' },
    radius: { ...radius, xs: '4px ' },
    grid: { ...grid, pageGutter: 'var(--grid-gap)' },
    color: {
      grey100: '#f2f4f7',
	  ...
    }
  }
})

or if you want to make it a bit neat and put everything on the entry point which you'll only need to do export * from "./typography"...

import { defineConfig, defaults } from "pollen";

export default defineConfig({
  output: 'styles/pollen.css',
  modules: {
    font: { sans: `"Inter", sans-serif` },
    letter: { ...defaults.letter, sm: '-0.02em' },
    radius: { ...defaults.radius, xs: '4px ' },
    grid: { ...defaults.grid, pageGutter: 'var(--grid-gap)' },
    color: {
      grey100: '#f2f4f7',
	  ...
    }
  }
})

If there's another feedback, I'd love to hear it. I might get to work on the PR as soon as I can :)

Follow on from #48, left the weights duplicated in --font- family to avoid a breaking change before v4 is ready. Remove them for v4.

Currently each module in the config from #46 is nested under an umbrella module (following the docs), might be better to flatten it out and treat every group of variables as a top-level module.

Taking a real world config example from Bokeh

Before

module.exports = (pollen, merge) => ({
  output: 'styles/pollen.css',
  modules: {
    typography: merge(pollen.typography, {
      font: { sans: `"Inter", sans-serif` },
      letter: { sm: '-0.02em' }
    }),
    ui: merge(pollen.ui, {
      radius: { xs: '4px ' }
    }),
    grids: merge(pollen.grid, {
      grid: {
        pageGutter: 'var(--grid-gap)'
      }
    }),
    colors: {
      color: {
        grey100: '#f2f4f7',
        ...
      }
    }
  }
});

After

module.exports = (pollen) => ({
  output: 'styles/pollen.css',
  modules: {
    font: { sans: `"Inter", sans-serif` },
    letter: { ...pollen.letter, sm: '-0.02em' },
    radius:  { ...pollen.radius, xs: '4px ' },
    grid: { ...pollen.grid, pageGutter: 'var(--grid-gap)' },
    color: {
      grey100: '#f2f4f7',
      ...
    }
  }
});

Pros

• Cleans up config a lot
• Makes parsing logic simpler
• Removes need for deepmerge utility
• More fine grained control over output, esp selective merge vs. replace

Cons

• Makes enabling addons a bit more cumbersome if there's more than one group in them
• Makes overall config file more verbose if just toggling modules on/off
• Interdependency issues? Have to double check nothing in core relies on other parts of core

I think it's probably worth doing.

In the case of Widths and Radius, the example snippet shows a numeric value but the default/standard properties don’t match. For instance, there isn’t an 11, but rather xs, md, and so on. Those are the only two places in docs where I saw that discrepancy.

Thanks for publishing this nice-looking library.

This issue is to suggest a new docs feature for the gitdocs page and for the README. Putting some screenshots on the docs pages and in the README would help new users get to know the library, get a sense for what it can do visually.