Skeleton design system feedback #1842
Replies: 2 comments
-
|
Valuable feedback and thanks for that, just a minor note about Links: https://www.skeleton.dev/elements/typography#anchor (which just means that it's not easy to find there and could use some improvement as well) |
Beta Was this translation helpful? Give feedback.
-
|
Hey @bohdank1995, thanks for the feedback. There's a lot to cover here and my time is limited today, but let me at least do a quick pass through the issues raised and answer best I can... Link colors
Breacrumbs have no inherit color for the links. They use There's a "source" button near the top of every documentation page if you would like to view the source or styles used to generate what's being documented on each page. For example, you can see where we define anchor style colors here: https://www.skeleton.dev/elements/typography#anchor We use design tokens when relevant, but for anchors specifically we found that in practice the existing tokens didn't provide links that were legible in most themes. So we've opted for a slightly askew custom pairing of 700/500. This provide results that were much more legible in most circumstances. Note the keyword I used above - our typography system is "opt-in", meaning user can choose to use our
Correct, and there will never be a link "component" (as in Svelte component) in Skeleton. We introduce our own set of utility classes (which we call "Tailwind Elements") that provide CSS styling for common HTML elements, such as anchor links in an opt-in manner. The source for this is linked above. Again, this can be found here: Border-radius logic
I think you may be failing to take into account multi-selection, which we cover here: Sure, single line select boxes should likely match standard inputs for border radius, so there's room for improvement here. Feel free to file an "enhancement" labeled issue on GitHub Issues or submit a pull request to resolve this. Ideally after v2, since a lot is about to change in our upcoming v2 release candidate due out next week.
We originally applied theme-provided border radius styles to checkbox/radio inputs by default, but we received some great feedback from users explaining that the shape of Checkbox and Radios should differ to help denote which is which. Making them uniform was harmful to UX. Given this, we've opted allow these retain the defaults set by the Tailwind Forms plugin, which normalizes and resets the basic styles. If users which to modify these, they can through standard CSS customization - ideally through their global stylesheet. Basic components
Sorry, I don't quite follow what you mean here. Skeleton takes the stance of not providing "components" for native input elements. We detail this here:
Source: https://www.skeleton.dev/elements/forms Lists use a variety of markup for the variety of native HTML elements we're styling, including order lists, unordered lists, description lists, and natigation lists. https://www.skeleton.dev/elements/lists Our List styles follow the ARIA APG for accessability: Likewise our Listboxes follow the ARIA APG guidelines defined here: But again, maybe I've missed your point here? Feel free to clarify. Some elements don’t follow Theme color logic.
This is incorrect, we use design tokens for these defined here:
These are native inputs provided by the browser, and browses do not currently provide full control over every portion of these elements. This is an issue for browser vendors to solve. If they provide us the tools to customize this, we will in a heartbeat! You might also note that some components (such as range sliders) display differently in different browsers. This is a long standing issue with web browsers, and not a problem we see being fixed anytime soon. But it's gotten a lot better as time has gone on.
This is correct. We define the ring style here, using a design token: The design token is declared here (for both light and dark mode versions): In this case we utilize a semi-transparent neutral tone based on light or dark mode. This is inset and slightly overlaps the card background. This was an intention design decision. The reason for this is the design token cannot know every combination of colors it may be overlapped on when the background color is modified for the card. If we hardcode the ring style, say to surface tone, and then someone implements a variant that makes the card background red - then that surface tone is going to stick out like a sore thumb. The user then has to modify TWO styles instead of one (background and ring). The overlapping ring was the most clever solution we could come up with for this scenario. I've made the ring much thicker to help visualize how this looks and works in execution. This might make it more clear what's going on here:
Just FYI, in my 20+ year career I started as a designer before I became a frontend developer. This is one of those ideas that sounds great on paper, but doesn't always pan out in execution. Just helpful advice from one designer to another ;) Documentation from a Design perspective
I explained this to your partner, but part of your challenge may be the fact you guys have opted to silo yourself away and work on this in isolation rather than bridge a gap to communicate with the contributors building this every single day for the last year and half. Our door has always been open and we always welcome open communication with the members of the community. In fact, we highly encourage it every chance we get. That's what open source is all about after all. It also sounds like you missed some critical portions of our documentation, which to Sarenor's point might mean there's room for improvement on the structure of our documentation. But, a lot of this information is there if you look for it. We also include a search feature, and of course our community is always around to help point folks in the right directly.
Given the dynamic nature of themes, the closest you're going to get to this is our background variant styles: If you mean the default app background color, we discuss that here: And note this whole section is getting a nice update in the next release:
Not sure what you mean by this. Perhaps you mean the techniques we use to define the the text/fill color when overlapping certain background colors? If so I agree, there's room for improvement here. But FYI this is part of the "on" colors, which are specific design tokens for Fill and Text colors: https://www.skeleton.dev/docs/tokens#svg-fill-color You can see this in practice on our live theme generator. Note the options on the right side:
https://www.skeleton.dev/elements/typography Please share what you would like covered beyond what's currently present.
Skeleton tries not to replicate features provided by Tailwind. Please refer to either: All Skeleton theme colors work with the shadow syntax provided by Tailwind.
Again, this is outside the scope of Skeleton. We just utilize the tools provided by Tailwind: We use the standardized breakpoints they provide. If you understand Tailwind, then you understand how these can be configured.
We're actually inspired by many different sources, including UI libraries and system, such as Material Design, Mantine, Radix, and a slew of others. But we're also not trying to BE those libraries either. The goal with Skeleton is to be Skeleton. |
Beta Was this translation helpful? Give feedback.
-
Hi there, Bohdan here. I’ve created with @mmailaender the Unofficial Skeleton for the Figma library. While making the library, we noticed some points that I would like to share with you. I expect some of these points are probably already known and covered in the upcoming v2. But eventually, we identified some new points that help to improve Skeleton further.
I’m a designer and not so into Programming, so my feedback is mostly related to the design system of Skeleton.
1. Link colors
Problem
Expectation
2. Border-radius logic
Problem
Skeleton objects in the border-radius context are distinguished by ‘base’ and ‘container’.
Expectation
3. Basic components
Problem
Checkboxes, radio buttons, options, and links do not appear as separate components in Skeleton.
Certain remarkably similar components require the application of different sub-components, even if the striking similarity between these sub-components is high. For example, Lists use
<li>and<span>, while Listboxes use ListBoxItem to display a list of elements.Expectation
In my perspective, utilizing the same subcomponent across components like Lists, Listboxes, Autocomplete, and others would increase consistency and therefore simplicity. This approach could involve distinct variations, and states, and offer the flexibility for complete customization.
4. Some elements don’t follow Theme color logic.
Problem
Certain elements within specific components use colors that are not part of the Theme. (See items below.)
Expectation
To achieve a consistent design system, I would expect that all used colors are provided from the Theme.
5. Documentation from a Design perspective
To create interfaces quickly and efficiently, designers and developers must have a common understanding of how the design system works.
Problem
From a design perspective, understanding how Skeleton works has been a bit of a challenge for me. I recognize the existence of basic sections like Colors or Variants, but I want more clarity. I had to discover a considerable amount on my own, using the Inspect feature in my Browser.
Expectation
It would be great if the Skeleton documentation had the following sections:
You might be inspired by Material 3 or Reshaped
Beta Was this translation helpful? Give feedback.
All reactions