Skeleton Roadmap #1367
Replies: 6 comments 8 replies
-
|
Awesome Roadmap! Some brief thoughts after reading it.
With the radix-svelte port being worked on, and gainings some traction, this is definitely an interesting one. I think separating the styles from the components themselves could be a great idea. You don't want to have to wrestle with a framework, like the good ole' days of Bootstrap 2. But at the same time, it can good to stay a a somewhat opinionated framework. Having element styles be separate would likely make the boilerplate a bit more verbose, causing simple items to look more complicated than they are (we all know how nasty/lengthy Tailwind classes can get). Honestly I am stuck on this one - because on one hand, having to override a padding that a button has by default when next to another element can be frustrating, and on the other hand, those little CSS adjustments can be real time savers. Bootstrap (not that Skeleton is Bootstrap at all) was popular for a reason; it was hated for that same reason. I wonder if having some sort of wizard on the site to adjust common things like padding and margins throughout forms, or gap sizes throughout the theme, would be a better plan. What are your thoughts? What complaints do you hear most from the Skeleton community regarding styles?
Personally I think this is a mistake. Of course I am a little biased since I use Svelte but I think trying to support multiple frameworks would slow down development on all fronts. There are already so many good frameworks, both style opinionated (Chakra UI), and headless (Radix)...and even ones built on headless (shadn-ui). React is such a rich eco-system, and has had time to develop, that I think even splitting any resources away from the Svelte community would be an unfortunate step. Sure, I think opening Skeleton to other frameworks would probably bring more interest, and could in turn even help out the Svelte side inadvertently, but I would rather not bet on it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @saturnonearth, you brought up a couple great points. I was trying to keep the explanations above slim and simple so not to overwhelm, but I have a lot more in mind for all these proposals. Too much to fit here.
The way I'd imagine this working is we would build on our system for feeding utility classes as props for components. Instead of feeding primative utility classes (ex: bg-green-500) to a
It's a lot like the current prop system, just on crack! Another cool benefit of this is the classes provided by the user don't have to be Tailwind. So traditional CSS styling is available for those that shy away from Tailwind. Though I'm not sure if we can drop the Tailwind dependency altogether, all our "in-house" styles will still utilize Tailwind.
I actually have always intended to implement margins/padding into theme settings, then build design tokens around them. Then you get the nice standardization approach that tokens provide. Meaning you may no longer be required to set a padding for every card instance. Though margin/padding is more nuanced than, say, border radius. We might need canned presets like
It very well could be. You're not the first to express this concern. There's a time and maintenance cost for every framework we support. Without additional full time staff this falls apart, as I can't be the expert leading the charge for every framework. It's too much effort. But I know library ports are common (ex: Svelte-Radix within the last couple weeks). So in some ways this in inevitable. Heck, I already know of one guy porting Skeleton to Vue in his free time, for example. I think we can lay a lot of the foundation for this with other changes we know we want to implement though, then only worry about expanding if/when it makes sense. Funny enough I'm not really interested in expanding to React. I'd rather look at the "new kids on the block" like Solid and Quik and whatever comes next. |
Beta Was this translation helpful? Give feedback.
-
I wonder what maniac spends his time doing such a thing. |
Beta Was this translation helpful? Give feedback.
-
Ah I understand now. This sounds great!
Cool! |
Beta Was this translation helpful? Give feedback.
-
|
Maybe this: Core developers focus on Svelte (there's still too much to do), let others port Skeleton to other frameworks. |
Beta Was this translation helpful? Give feedback.
-
Yep. Like how radix is being ported to svelte by another dev |
Beta Was this translation helpful? Give feedback.
-
|
I really celebrate the headless plans! |
Beta Was this translation helpful? Give feedback.
-
|
Headless Skeleton is what I have suggested since the earliest days of Skeleton! In fact, I have argued about it on multiple occasions with Chris on Discord (as Shoob). |
Beta Was this translation helpful? Give feedback.
-
|
I'm a React developer and I was really drawn by the design tokens aspect of Skeleton. I actually started looking just today to see if it would be possible to port that aspect over to a Next.js app I'm working on. So I would for sure love if the design tokens were framework agnostic. As for developing actual components in all of the other frameworks, I don't think it's really worth it. I know, at least with React, there are already other headless component libraries, so you would be reinventing the wheel. Just being able to style them with Skeleton's design tokens would be amazing. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah @multiwebinc would be glad to share how some of that works. It's definitely not Svelte specific. And I don't see us supporting all frameworks, but I think a lot of the changes we have planned will just make it possible. So we'll see if if there's anything we can do with that. But I definitely see that a year or two away. Nothing in the immediate future. |
Beta Was this translation helpful? Give feedback.
-
|
@endigo9740 I actually followed the manual instructions on https://www.skeleton.dev/docs/get-started and I was able to get it working with Next.js, Radix and shadcn-ui components (although I am likely going to have to overwrite all of the styles from them or maybe just use straight Radix):
module.exports = {
plugins: {
"postcss-import": {},
tailwindcss: {},
autoprefixer: {},
},
}
import "@skeletonlabs/skeleton/themes/theme-skeleton.css"
import "@skeletonlabs/skeleton/styles/all.css"
You should now be able to use Skeleton classes: <button type="button" className="btn-icon variant-soft-primary">
(icon)
</button>
<button type="button" className="btn variant-soft-primary">
Button
</button>
<button type="button" className="btn variant-soft-primary">
<span>(icon)</span>
<span>Button</span>
</button>
|
Beta Was this translation helpful? Give feedback.
-
|
Awesome work @multiwebinc! I meant to mention that everything but our components and utility features will work cross-framework. Tailwind is really the only requirement there. Not a bad way to dip your toes in for sure! |
Beta Was this translation helpful? Give feedback.
-
|
I really am glad this library might go headless in the future. This would allow other styling frameworks/libraries to be paired with Skeleton and not limit to only tailwind, this would also allow for existing projects to use Skeleton purely for logic (which is usually the hard part of any UI pattern) because some projects might already use something else. |
Beta Was this translation helpful? Give feedback.
-
|
Just FYI everyone, we'll be making some changes for Skeleton v3. See the RFC and proposal to learn what's incoming: And you can track progress via a dedicated milestone here: |
Beta Was this translation helpful? Give feedback.
-
View past Roadmaps:
Hey everyone, Chris here from the Skeleton crew. We've had a lot of questions about the future plans for Skeleton so I wanted to pull back the curtain and share what we've been cooking up.
Please note that the Skeleton core team is comprised of four contributor role members (Nik, Rhys, Adrian, and myself) and four moderators (Dom, Luke, Brent, and Sebas). After the v1.0 launch the full team and I met to discuss the future of the project and define our long term goals. While the team is responsible for organizing these ideas, most suggestions has come either directly or indirectly from feedback and suggestions provided by you (our community).
The information below represents a high level overview and future plans. Nothing here is set in stone, so expect revisions. However, this is meant to provide our general direction for the project. We do very much welcome your feedback in the comment section below!
Skeleton v3+
focus-trapto include a new dedicatedstrictargument (reference)regionversusslotnaming for properties.Long-Term Concepts and Proposals
Please note the following represents some "big picture" ideas we have for the far flung future of Skeleton. We reserve the right to change the direction and/or discard any of the following concepts at any time. In short, temper your expectations. However, we do wish to share our big ideas early to help garner support and contributors and help guide the overall direction the project is heading. If these features move forward, expect to see them as major breaking change releases, such as v2, v3, etc.
Rethinking Dark Mode Strategy
I've written a detailed post on this subject, which can be found in the link below. In short, we have some flaws in how light and dark mode is handled in relation to features such as design tokens. Given the scale and scope of this proposal, we do highly encourage feedback from you on this. Additionally, upcoming changes in next major version of Tailwind may influence how we approach this as well.
Headless Components
This is a hard concept to explain with words alone, so I've created diagram below to help visualize this proposal:
Currently Skeleton components are a tightly coupled set of HTML templates, TS/JS logic, and Tailwind CSS utility classes. This provides a fully featured component that comes pre-styled, while still adapting to your current theme. However, there are benefits to splitting the components between what are commonly referred to as "headless components" and our unique approach to Tailwind Element styling. Here's a few potential use cases with the split pattern:
Going Framework Agnostic
We're often asked why we didn't name the library "Sveleton" or something more Svelte-specific, and the reason for that is simple: we've always anticipated the library might one day go framework agnostic. We love Svelte and SvelteKit and imagine it will continue to be the tip of the spear for us, leading all feature development for the foreseeable future. However, we often hear it said that Skeleton has brought a lot of new ideas and innovations to the UI library space (such as our adapting themes and use of design tokens). We think there's potential to bring these benefits to ALL frameworks, including those not yet created. The headless component + element styling approach is one of the primary features that may make this possible.
Again, here's another diagram to visualize how this might work:
By separating the visual presentation (Tailwind Element styles) from the core component itself, it makes it much easier to port each component to a new Javascript Framework, such as React, Vue, Angular, etc. Tailwind and styling would then be the shared commonality between each. While not a trivial task by any stretch of the imagination, especially given how each framework operates differently (ex: Stores vs Signals vs rxJS Observables). We do think this may be technically possible
That said, this would be a tremendous amount of effort, likely taking multiple years to fully implement. We would also need the assistance of one or more experts in each framework we wished to support. If you think you might be capable of helping with something like this, and understand the long term commitment required to make this happen, then please reach out to me (@endigo9740) on the Skeleton Discord or email me at [email protected]. I'd love to meet and review this in more detail!
Sharing Feedback
If you have questions or feedback about anything above, please consider leaving a comment in the section below. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions