If the plan is to retire these components from skeleton long-term, it might be good to state that and encourage folks who (like me) prefer the components to migrate to headless libraries (and link them to those guides

To be clear, this is and has been stated since day of the v3 launch. I've tried to mention the purpose and expected window these components will be offered. We recently updated the text for this alert, but it's been there since v3 launched:

https://www.skeleton.dev/docs/integrations/popover/svelte

Note that since my last post above, I've put a lot of thought into the Floating UI attachment idea - and while I think it will be useful for power users, I don't think it can or will replace our current Zag-based components. Instead, it will likely live in the Cookbook section and an optional alternative. If that puts any concerns to rest.

On that note, a guide for Ark UI could be good addition, esp since I imagine that would be the easiest migration for these components since they're both built on top of zag

I've spoked at length to the Chakra/Ark/Zag teams (which are essentially one group) and while I can vouch for the quality of their work, I cannot recommend Ark any more than other headless component offerings. The reason being is unlike something like Shadcn, where you have access to the raw template source, your only entry point for styles in Ark/Bits/etc is the class attribute. While this can get you pretty far, it's not really equivalent to the Skeleton experience. You get no default styles out the box, and you have no set mechanisms for sharing style overrides between multiple instances of the same component without having to abstract and "wrap" each component. Again, I think they're great solutions - just not for use with Tailwind specifically. If that makes sense.

To your point thought, if a great a11y-friendly Popover library appears that is either platform agnostic -or- with direct support for Svelte 5, I would generate a guide against these in a heartbeat. But as of present I'm not aware of any such offerings. This doesn't exist - which is why we wanted to build Floating UI Svelte.

That said, think the more reasonable solution will come with time - in that the native Popover API and CSS Anchoring APIs will not only become standard cross-vendor, but mature as well. Those are the endgame, we're just caught in the awkward period before that happens unfortunately.

Fair, that warning has been there since that start. 2 concerns though:

• Will these components continue to be maintained in v4 (if there's still no suitable replacement, native or otherwise)? That's not quite clear to me
• It's not clear how long the current major version will be supported. When released, I expected a lifecycle similar to skeleton v2 or longer. But since then, it seems the emphasis has shifted to working on the v4 component API. (I guess this isn't really a concern if the answer to the above is "yes")
  • I think this is the core of my concern. It feels like the support window for v3 (and these components?) has shortened, so it would feel appropriate to more strongly discourage their use and point people towards admittedly imperfect alternatives
  • For what it's worth, I like the direction the library is headed and am looking forward to v4 <3

I cannot recommend Ark any more than other headless component offerings

I just meant it could be nice to have ark integration guide, equivalent to / alongside the existing bits/melt/radix guides. And those guides collectively could be recommended over these semi-deprecated components (perhaps in that warning, along with the floating-ui attachment guide when that's available). Would an ark guide be a welcomed contribution?

In short, the components will be maintained - not only an alternative is found - but the next major release is dropped AFTER that. So imagine:

• Tomorrow we find a perfect alternative
• We implement the guide for this
• The components will be maintained until v4 - as that's the next major release

If an alternative is not provided until after v4, then they'll remain to v5, etc. Basically we will never strand folks without a direct alternative to move to. And personally I have a feeling that alternative will be the native browser APIs, but not until they're widely available.

Would an ark guide be a welcomed contribution?

100%. It would be almost identical in format to the Bits or Melt guides in most regards. The only difference is it would need to be catered to multiple frameworks (which our code blocks now support). I'd welcome either a contribution for this (if you're volunteering) or a feature request if you're not in a hurry.

Thanks, that helps to clarify! As an alternative to the final sentence of the warning, I'd perhaps suggest "After an alternative is available, these components will be marked as deprecated, and support will end with the next major version of Skeleton." That's clearer to me (but maybe that's just me)

And personally I have a feeling that alternative will be the native browser APIs, but not until they're widely available.

Unfortunately, one of the main projects I use Skeleton for is a Tauri app, and the Linux webview (WebkitGTK) can lag behind the browsers :( I definitely don't expect Skeleton to include that in its definition of "widely available". Worst case, I migrate to one of the headless options

I'd welcome either a contribution for this (if you're volunteering) or a feature request if you're not in a hurry.

Yep, I'm volunteering :)

Nice, well if you do submit a PR feel free to tweak the message too. Whatever helps folks I'm down for.

And yeah that's a bummer about the Linux webview. Remember even when we stop maintaining the components, there's nothing preventing you from copying the source and running them local to your own projects. Likewise if you really want to stick with Zag, you can use it directly and roll your own components.