[DOCS]: Timeline of the project

[anandbhaskaran]

Do you have any planned timeline for this project? Would be awesome to see when would the basic components (such as buttons, inputs, tables, etc..) will arrive in this project.

[matthewpull]

I don't think things like buttons or inputs are in-scope for a project like this: that's what Tailwind UI is for.

Headless UI isn't here to offer styled components (again, that's Tailwind UI), but rather to provide component logic (dropdown open/close, keyboard shortcuts, ARIA, etc). As simple buttons and inputs don't really need that, there isn't a lot of point including them here (the <button> or <input> tags already exist).

[anandbhaskaran]

Thanks for your reply, I would slightly challenge the decision here.

As an end-user, I see Headless UI as a styled component library and the Tailwind Ui as an unstyled component library.

Said that, for a widely-used styled component library, we would need many more out-of-the-box components (with logic) that are quicker to implement.

[matthewpull]

Correct me if I'm wrong, but I think you might have got Headless UI and Tailwind UI the wrong way around.

The Headless UI authors have publicly stated on multiple occasions that Headless is an unstyled library. The first line of this repo's README (and the website) calls them "completely unstyled, fully accessible UI components". Hell, even the name "headless" conveys this message - the library is designed purely to facilitate interactivity and accessibility, not offer CSS styling.

By comparison, Tailwind UI (of which, full disclosure, I am a paying customer) contains nothing but styled components. That's literally all it is - HTML and CSS, no JavaScript. When there are components that require more interaction than can be done with just pre-defined HTML elements along, Tailwind UI actually uses the corresponding Headless UI elements - literally operating as the styled versions of Headless' unstyled components!

Now I do agree that I would like to see additional elements in the future - autocomplete would be a key feature for me - I am pretty sure that the "basic components (such as buttons, inputs, tables, etc..)" will never be a part of this project.

Perhaps the purpose of Headless UI wasn't clear (and I hope that my message has cleared up any possible confusion), but the browser already handles buttons and inputs fine - there is no interactivity for Headless to offer. Even for tables, the styled examples in Tailwind UI show that the basic browser tags are more than capable of handling most use-cases, as even then there isn't really an interactivity or significant accessibility issue (as tables are static).

[QaahirStewart]

I think he wants Headless UI to go in the direction of Radix Primitives https://www.radix-ui.com/docs/primitives/overview/getting-started