Initial discussion #1
Comments
|
@lnr0626, @paulstatezny and @harmon25 in case any of you knows anyone else that could be also interested in Tailwind components for Surface, please ping them so they can join us on this discussion. @miguel-s and @Malian I'm not sure what CSS solutions you're using but since you're both very active contributors, in case you're using (or have plans to use) Tailwind, feel free to join us as well. BTW, in case you use Slack, it would be great to have you on the Cheers. |
|
I do use Tailwind CSS and UI, and also AlpineJS in my own projects :D Don't now how I missed the #surface slack channel, will join you there soon! |
|
Ping @capitalist |
|
So I think it's established that we cannot use any markup from Tailwind UI. That said, is the purpose of this project to cook up custom generic components from scratch? The Bulma version uses official Bulma markup instead of doing it from scratch, right? |
If we can't find any free set of components that we can use, then yes.
Yes. Both Just for the record, I think TailwindUI is great and it's more than fair that it has a commercial licence. What I think it's unfair is that Vue.js users get ready-to-use components while a Surface/LV user will have to roll its own suite of components, which cannot be shared to make the life of others easier, not even with those that also bought the licence. It seems like such a waste of resources. An effort to provide an opensource alternative for Surface/LV would be fantastic for the ecosystem. |
|
100% agreed, and supportive of that. I was asking to make sure I understood the strategy/approach for this project. |
I don't think there are any official TailwindCSS/UI Vue or React component suites. Most component suites I.E semantic-ui, antd, materialize have a consistent style, or 'look' to them - the point of tailwind is that it could look however you want. (just tweak the classes) I think this project is interesting - the alpine version would work nicely with LV, appears that is a WIP... |
TailwindLabs are working on something along these lines with HeadlessUI. It's still very early and only React and Vue (Alpine coming soon). This project is under the MIT License, so maybe we could follow what they're doing? |
|
I do use Tailwind CSS, Tailwind UI, and also AlpineJS in my projects. I will join the Surface community on slack! |
Are you sure Adam wouldn't let us share our derived components with others who have already bought the license... maybe from their password protected site? It seems like most of us here have already bought the license and are all reinventing the wheel leveraging the same stack anyway. |
@tmepple I'm not sure, either way, I believe the goal of this project shoud be to have an opensource suite of components that doesn't depend on TailwindUI and by the feedback so far, it looks like everyone using TailwindCSS is already using TailwindUI so I'm not sure I'll be able to bring enough people/companies to invest time and resources on this effort. Maybe the best thing to do is to wait for a free alternative to come up so we can build components on top of it.
@harmon25 there will be soon https://twitter.com/adamwathan/status/1362877785480564738?s=20 |
|
The reason I found this was because I thought I'd just take the Bulma components and redo them with Tailwind. Might be worth having a project here so that people can start adding components. Just don't copy TailwindUI. |
|
Hi @BryanJBryce! @olivermt is working on a more complete suite of components based on bootstrap (https://github.com/surface-ui/surface_bootstrap/). It should be released in the next few days. After its release, maybe we could try to mimic the same API for Tailwind. I'm sure we'll not be able to have the exact same API but we might be able to keep it as similar as possible. |
|
There is https://tailwindcomponents.com/ where are free tailwindcss components. Doesn't help for the ui license problem but there is already a community making custom components that we can freely use. |
|
Totally in the same boat - we also have the license and are in need to write own surface components. From the license it is quite clear that you can only open source end products not component based libs. I however can imagine to get around this limitation without violation of the license. The library would need to use its own set of CSS classes which are intermediate classes (probably bulma like) and just inherit from other classes (bulma by default). They could however also inherit (or map) from(/to) CSS classes of tailwind without providing tailwind CSS classes, whole tailwind UI themes or a complete mapping. This could possibly be done in some So in general more like plugging in CSS later by the user of the lib. edit: which slack? |
|
Hey gang. I've been using TailwindCSS for a couple years now, and I wanted to start contributing to this Tailwind library for Surface. I see a lot of concern about creating Tailwind components because of TailwindUI's license. From the FAQs:
So far, the approach has been to implement components based on documented examples (Bulma, Bootstrap). What if Surface component libraries were more standardized and CSS framework-agnostic? Components and their props would have implementations for each supported CSS framework, but the API for each component would be consistent. Kinda like Ecto has adapters for a few drivers. This way, the Surface components would have distinct appearance (and functionality?) from TailwindUI. Could Surface pull off a unique design aesthetic this way? Is that what users want? |
|
For context, this is the episode where licensing is discussed (85:43) |
@msaraiva How do you feel this release came out as an example for a starting point for tailwind? |
|
As for my POV, I'd say my stuff might not be so relevant, as I'm simply implementing my way through the sandwhich list of components and features in the bootstrap 5 library. |
|
https://dev.to/jameswallis/5-places-to-get-pre-crafted-tailwind-css-components-for-free-3jlg lists 5 open source/mit license tailwind component libs as well. |
|
Is the idea for the tailwind_surface library to have API parity with the surface_bootstrap library, or do things a little differently? The reason I ask is I was looking at the differences as to how tailwind and boostrap approach things. For example taking the button component in the surface_bootstrap library, the colors prop accepts one of these values ~w(primary secondary success danger warning info light dark). But tailwind's approach to colours isn't as semantic as this, and could be any one of the many colours which come with tailwind or custom ones. Same with a prop like size. The surface_boostrap button takes ~w(small large), but there aren't really preset sizes like this in tailwind, although they could be made to work that way. The same for the rounded prop. It's a boolean in surface_boostrap, but in tailwind it could be rounded-( sm | md | lg | xl | 2xl | 3xl| full ) or any combination the top, right, left, bottom, top-left, top-right, bottom-right, bottom-left variants, etc. I guess for both of the above, a 'sensible default' could be included in a component, maybe drawing inspiration from Tailwind UI? But I'm also thinking of (1) how could there be a sensible starting point, and (2) not end up with lots of verboseness like adding the following to the class prop each time for a button because thats what suits the needs in a particular project: "inline-flex items-center justify-center px-4 py-2 border border-transparent text-base font-medium rounded-md text-white bg-indigo-600 hover:bg-indigo-700" ! I'm wondering if others were thinking of this too - how to find a balance with some nice defaults using tailwind in a flexible surface component library, maintaining the expressiveness of tailwind when needed, but not resulting in having everything to be on a components class prop? |
|
I wonder about the idea of a theming component / aspect that could be used?
So buttons would have class defaults, but inherit theme options.
Then you would define things like borders, spacing, colors as part of the
theme. https://material-ui.com/customization/default-theme/ has a pretty
good theme object definition.
…On Thu, May 27, 2021 at 6:18 AM David ***@***.***> wrote:
Is the idea for the tailwind_surface library to have API parity with the
surface_bootstrap library, or do things a little differently?
The reason I ask is looking at the differences as to how tailwind and
boostrap approach things.
For example taking the button component in the surface_bootstrap library,
the colors prop accepts one of these values ~w(primary secondary success
danger warning info light dark). But tailwind's approach to colours isn't
as semantic as this, and could be any one of the many colours
<https://tailwindcss.com/docs/customizing-colors#color-palette-reference>
which come with tailwind or custom ones.
Same with a prop like size. The surface_boostrap button takes ~w(small
large), but there aren't really preset sizes like this in tailwind,
although they could be made to work that way. The same for rounded prop.
It's boolean on surface_boostrap, but in tailwind it could be rounded-( sm
| md | lg | xl | 2xl | 3xl| full ) or any combination the top, right, left,
bottom, top-left, top-right, bottom-right, bottom-left variants, etc.
I guess for both of the above, a 'sensible default' could be included in
each component, maybe drawing inspiration from the TailwindUI?
But I'm also thinking of how there could be a sensible starting point, but
not end up with lots of verboseness like adding the following to the class
prop each time for a button because thats what suits the needs in a
particular project: "inline-flex items-center justify-center px-4 py-2
border border-transparent text-base font-medium rounded-md text-white
bg-indigo-600 hover:bg-indigo-700" !
I'm wondering if others were thinking of this too - how to find a balance
with some nice defaults using tailwind in a flexible surface component
library, maintains the expressiveness of tailwind when needed, but not
resulting in having everything to be on a components class prop?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM7F3AYCMZZIWH6TS65RZDTPYL6DANCNFSM4XY7BHDA>
.
|
I like that approach @gdub01. |
@gdub01 thanks for the link. Cool stuff 👍 This will certainly be helpful.
@haubie there's no requirement for keeping any parity. It can be completely different. Most of the time I'm sure it will be better to keep each one them following their own already established vocabulary and semantics.
Hard to tell now but the chances a project like this have to get bloated is pretty high. TailwindUI did a pretty good job on that regard. The components look good and are flexible enough, however, I didn't have a chance to take a look at the recently released set of official React components provided by TailwindUI. So I'm not sure how intuitive and flexible the API ended up. One thing is creating pseudo-components that looks cool but have no behaviour, no state and no public API. Creating "real" components with all that is a totally different beast.
That's certainly the big question here. Has anyone already seen how TailwindUI's official React component suites handles that? Are there any other lib that do this nicely? What kind of abstractions they came up with? |
|
Thanks for the clarification @msaraiva and those thoughts as well. I hadn't looked at the React or Vue components in Tailwind UI, but I've now had a peak into some that are in the free tier. Lower-level componentsAs you suspected, there can be a lot of bloat on the public API of the lower-level components:
In this current version of Tailwind UI, it doesn't looked like they have a global theming layer as colours, typography, etc, are hardcoded as above in each component. Higher-level componentsHigher level components look clean, and seem to have an API which focuses more on the content/data. e.g. the Features component below, takes an array of values on a features prop:
I also get the impression that some of the Tailwind UI components aren't meant to be a simple drop in where most of the style and behaviour is configured through an API on the component. They seem more of a starting point that will require the dev to edit. Example below is a header component with menu items:
It all looks hard coded to the specific example, rather than exposing a generic 'menu' prop taking an array. I'm thinking there is probably a nicer way which strikes the balance of a sensible starting point without too much verboseness. The material example @gdub01 looks like a nice way of defining customisable global styles, but also allowing overriding through props on an individual component when necessary? I guess this could still be done in Tailwind as per: It might be nicer done in an Elixir module which could hold the theme config, but how will people who use tailwind on a regular basis feel about this? e.g. setting the palette something like the material example shared by @gdub01 : Setting the default global styles for the lower-level components like buttons something like this: With an equivalent prop on the button component that could be pulled in by the component author as defaults, but overridden, e.g.: And used like this: Output:
|
|
Little bit of a revision to the above idea, if supporting say primary, secondary and other named palettes defined in a theme, the above may need a tweak to remove the defaults defined in the props, e.g.: .... or something like that. I guess with a little refactoring, that classes/1 function could be moved to SurfaceTailwind.Theme and aliased instead. And that would allow:
|
|
I like the above a lot! I do wonder if we can get away without having a specific button theme. If we want the button border to look like this:
the button component could look like this:
Just with the idea that the button component itself sets defaults that incorporates the global theme without the need for a separate button theme. Then to switch between a primary and secondary button, it would go from:
to: `background: "#{color(@button_variant, :main, :background)} hover:#{color(@button_variant, :dark, :background)}", where @button_variant is :primary or :secondary or something like that? |
I really like that idea @gdub01 and can see the advantages of that approach. I had a bit of a play around with the idea and got a prototype working for a couple of components as below. I think it feels pretty usable, flexible and tailwind-ish. Probably worth trying with a more complex component as at the moment the classes are just being applied to the top most HTML element, rather than reaching in any deeper. Added to the component is a function which holds the theme information. That callout to Button exampleExamples of it being used:
Sample output for the above:
Alert component exampleIn this component, the theme is set by the alert type, e.g. if it is a :info, :warning or :error alert. Alert component code: Example uses:
Output for the above:
Global theme configFor the above, just a nested keyword list: I think this could be moving in the right direction, what do you think? |
|
Wow nice David! I think it looks great!
…On Sun, May 30, 2021 at 10:16 AM David ***@***.***> wrote:
Just with the idea that the button component itself sets defaults that
incorporates the global theme without the need for a separate button theme.
I really like that idea @gdub01 <https://github.com/gdub01> and can see
the advantages of that approach.
I had a bit of a play around with the idea and got a prototype working for
a couple of components as below. I think it feels pretty usable, flexible
and tailwind-ish. Probably worth trying with a more complex component as at
the moment the classes are just being applied to the top most HTML element,
rather than reaching in any deeper.
Added to the component is a function which holds the theme information.
That callout to SurfaceTailwind.Theme.build_class_list(assigns,
&component_theme/1) is what applies the styles defined in the component
and any values pulled from the global theme config, or overridden by a prop
or in the class prop.
Button example
defmodule SurfaceTailwind.Button do
use Surface.Component
alias SurfaceTailwind.Theme, as: T
# ... other props removed for brevity ... #
prop theme, :atom, default: :primary
prop alignment, :css_class
prop padding, :css_class
prop margin, :css_class
prop border, :css_class
prop text, :css_class
prop text_size, :css_class
prop background, :css_class
prop ring, :css_class
slot default
def render(assigns) do
~H"""
<button
***@***.***}}
***@***.***_label}}
***@***.***}}
***@***.***}}
***@***.***}}
class={{classes(assigns)}}>
<slot>{{ @Label }}</slot>
</button>
"""
end
def classes(assigns), do: T.build_class_list(assigns, &component_theme/1)
# Theme definition for the component, embedded with the component.
def component_theme(theme \\ :primary) do
[
alignment: "inline-flex items-center justify-center",
padding: "px-4 py-2",
margin: "",
border: "border rounded-md #{T.value(theme, :main, :border)}",
border_radius: T.value(:general, :style, :border_radius),
text: "font-medium #{T.value(theme, :main, :contrast_text)} hover:#{T.value(theme, :dark, :contrast_text)}",
text_size: "text-base",
background: "#{T.value(theme, :main, :background)} hover:#{T.value(theme, :dark, :background)}",
ring: "focus:outline-none focus:ring-4 focus:#{T.value(theme, :main, :ring)}"
]
end
end
Examples of it being used:
- Default (primary) theme: <Button>Default</Button>
- Default with background and text overridden in prop: <Button
background="bg-green-200 hover:bg-green-900" text="text-green-900
hover:text-white" class="my-4">Default + props</Button>
- Secondary theme: <Button theme={{:secondary}} class="my-4">Secondary
theme</Button>
- Secondary theme with background and text overridden in prop: <Button
theme={{:secondary}} background="bg-green-200 hover:bg-green-900"
text="text-green-900 hover:text-white" class="my-4">Secondary theme +
props</Button>
- Secondary theme, overriding alignment and text size, adding an SVG:
<Button theme={{:secondary}} alignment="inline-flex flex-col items-center justify-center" text_size="text-xs">
<svg xmlns="http://www.w3.org/2000/svg" class="h-10 w-10" viewBox="0 0 20 20" fill="currentColor">
<path d="M2 11a1 1 0 011-1h2a1 1 0 011 1v5a1 1 0 01-1 1H3a1 1 0 01-1-1v-5zM8 7a1 1 0 011-1h2a1 1 0 011 1v9a1 1 0 01-1 1H9a1 1 0 01-1-1V7zM14 4a1 1 0 011-1h2a1 1 0 011 1v12a1 1 0 01-1 1h-2a1 1 0 01-1-1V4z" />
</svg>
<div>Secondary theme</div>
</Button>
- Disabled button - if disabled = true, it will set the theme to
:disabled <Button class="my-4" disabled={{true}}>Disabled
theme</Button>
- Applying a the :neutral theme: <Button theme={{:neutral}}
class="my-4">Neutral theme</Button>
Sample output for the above:
[image: image]
<https://user-images.githubusercontent.com/1615855/120107115-0c973c00-c1a3-11eb-9f1b-88f5a778eeb0.png>
Alert component example
In this component, the theme is set by the alert type, e.g. if it is a
:info, :warning or :error alert.
Alert component code:
defmodule SurfaceTailwind.Alert do
use Surface.Component
alias SurfaceTailwind.Theme, as: T
prop type, :string, default: :info, values: [:info, :error, :warning]
# ...other props an icon fetching code edited out for brevity...
prop size, :css_class
prop alignment, :css_class
prop padding, :css_class
prop margin, :css_class
prop border, :css_class
prop text, :css_class
prop text_size, :css_class
prop background, :css_class
prop ring, :css_class
prop shadow, :css_class
slot default
def render(assigns) do
~H"""
<div
***@***.***_label}}
***@***.***}}
***@***.***}}
class={{classes(assigns)}}>
<div class="w-12 h-12
rounded-full
bg-white bg-opacity-20
flex flex-col
justify-center items-center
***@***.***)}}</div>
<div class="flex-1">
<slot>{{ @Label }}</slot>
</div>
<div class="w-6 opacity-60">{{icon(:cross)}}</div>
</div>
"""
end
def classes(assigns) do
# Alert theme is selected based on the alert type parameter, rather than using the theme parameter
# E.g. <Alert type={{:error}}>Error message text here.</Alert>
assigns = Map.put(assigns, :theme, assigns.type)
T.build_class_list(assigns, &component_theme/1)
end
def component_theme(theme ) do
[
size: "w-full",
alignment: "inline-flex items-center justify-left",
padding: "px-3 py-3",
margin: "",
border: "border #{T.value(theme, :main, :border)}",
border_radius: T.value(:general, :style, :border_radius),
text: "font-semibold #{T.value(theme, :main, :contrast_text)}",
text_size: "text-base",
background: "#{T.value(theme, :main, :background)} hover:#{T.value(theme, :dark, :background)}",
ring: "focus:outline-none focus:ring-4 focus:#{T.value(theme, :main, :ring)}",
icon: T.value(theme, :main, :icon),
shadow: "shadow-lg"
]
end
end
Example uses:
- Default (info): <Alert class="my-4">Default alert with the info
styling.</Alert>
- Warning: <Alert type={{:warning}} class="my-4">Warning alert
styling.</Alert>
- Error: <Alert type={{:error}} class="my-4">Error alert
styling.</Alert>
- Overriding the border prop: <Alert type={{:error}} class="my-4"
border="border-8 border-blue-900">Error alert styling with overriding of
Tailwind CSS border classes.</Alert>
Output for the above:
[image: image]
<https://user-images.githubusercontent.com/1615855/120106874-18363300-c1a2-11eb-97ce-1cd54b785251.png>
Global theme config
For the above, just a nested keyword list:
[
general: [
style: [
border_radius: "rounded-md",
]
],
primary: [
main: [
background: "bg-blue-700",
text: "text-blue-700",
contrast_text: "text-white",
border: "border-transparent",
ring: "ring-pink-600"
],
dark: [
background: "bg-blue-900",
text: "text-blue-900",
contrast_text: "text-white",
border: "border-blue-800",
ring: "ring-pink-600"
],
light: [
background: "bg-blue-50",
text: "text-blue-400",
contrast_text: "text-white",
border: "border-blue-400",
ring: "ring-pink-600"
]
],
secondary: [
main: [
background: "bg-blue-50 seco",
text: "text-blue-700",
contrast_text: "text-blue-700",
border: "border-blue-700",
ring: "ring-pink-600"
],
dark: [
background: "bg-blue-500",
text: "text-blue-800",
contrast_text: "text-white",
border: "border-blue-800",
ring: "ring-pink-600"
],
light: [
background: "bg-blue-100",
text: "text-blue-400",
contrast_text: "text-blue-700",
border: "border-blue-100",
ring: "ring-pink-600"
]
],
disabled: [
main: [
background: "bg-gray-50",
text: "text-gray-700",
contrast_text: "text-gray-400",
border: "border-gray-200",
ring: "ring-pink-600"
]
],
neutral: [
main: [
background: "bg-gray-100",
text: "text-gray-700",
contrast_text: "text-gray-700",
border: "border-gray-500",
ring: "ring-pink-600"
],
dark: [
background: "bg-gray-500",
text: "text-gray-800",
contrast_text: "text-white",
border: "border-gray-800",
ring: "ring-pink-600"
],
light: [
background: "bg-gray-100",
text: "text-gray-400",
contrast_text: "text-gray-700",
border: "border-gray-100",
ring: "ring-pink-600"
]
],
error: [
main: [
background: "bg-red-700",
text: "bg-red-700",
contrast_text: "text-white",
border: "",
ring: "ring-blue-500",
]
],
info: [
main: [
background: "bg-blue-700",
text: "bg-blue-700",
contrast_text: "text-white",
border: "",
ring: "ring-pink-500",
]
],
warning: [
main: [
background: "bg-yellow-600",
text: "bg-yellow-700",
contrast_text: "text-white",
border: "border-transparent",
ring: "ring-pink-500",
]
],
success: [
main: [
background: "bg-green-600",
text: "bg-green-700",
contrast_text: "text-white",
border: "border-transparent",
ring: "ring-pink-500",
]
]
]
I think this could be moving in the right direction, what do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM7F3BCMNGQK3UE3QN53M3TQJCFVANCNFSM4XY7BHDA>
.
|
|
Looks really cool @haubie , The Click Plugin injects For example I have the TailwindUi Alert: defmodule Ui6Web.Components.Feedback.Alert do
@moduledoc """
Tailwind Feedback Alert
Based on the following source: https://tailwindui.com/components/application-ui/feedback/alerts
"""
use Surface.Component
alias Ui6Web.Components.{Plugins, Custom}
use Plugins.Click
alias Custom.Typo.{SubHeadline, Text}
@icons %{
"default" => "",
"info" => "fas fa-exclamation-circle",
"success" => "fas fa-check-circle",
"warning" => "fas fa-exclamation-triangle",
"error" => "fas fa-times",
}
slot default
@doc """
Type of the Alert
"""
prop type, :string, default: "default", values: ~w(default info warning error success)
@doc """
Title of the Alert
"""
prop title, :string
@doc """
Set accent border to the left side of the Alert
"""
prop accent, :boolean, default: false
def render(assigns) do
~H"""
<!-- This example requires Tailwind CSS v2.0+ -->
<div class={{ "alert", accent: @accent}}
data-type={{ @type }}
:attrs={{ phx_values(@values) }}
:on-click={{ @click }}>
<div class="flex">
<div class="flex-shrink-0">
<span class="alert-icon" data-type={{ @type }}>
<i class={{ get_icon(@type) }}></i>
</span>
</div>
<div class="ml-3">
<SubHeadline type={{ @type }}>
{{ @title }}
</SubHeadline>
<div class="mt-2">
<Text type={{ @type }}>
<slot/>
</Text>
</div>
</div>
</div>
</div>
"""
end
defp get_icon(type), do: Map.get(@icons, type)
The corresponding css looks like this: .alert{
@apply p-4 rounded-md;
}
.alert.accent{
@apply border-l-4 rounded-none;
}
.alert[data-type="default"]{
@apply bg-theme-soft border-theme;
}
.alert[data-type="warning"]{
@apply border-yellow-400 bg-yellow-50;
}
.alert[data-type="success"]{
@apply border-green-400 bg-green-50;
}
.alert[data-type="error"]{
@apply border-red-400 bg-red-50;
}
.alert[data-type="info"]{
@apply border-blue-400 bg-blue-50;
}
.alert-icon{
@apply w-5 h-5 icon;
}
.alert-icon[data-type="default"] {
@apply text-theme.softer;
}
.alert-icon[data-type="success"] {
@apply text-green-400;
}
.alert-icon[data-type="error"] {
@apply text-red-400;
}
.alert-icon[data-type="warning"] {
@apply text-yellow-400;
}
.alert-icon[data-type="info"] {
@apply text-blue-400;
}The following example shows the usage: <Alert title="Default">
...
</Alert>
<Alert title="Info" type="info">
...
</Alert>
<Alert title="Success" type="success">
...
</Alert>
<Alert title="Warning" type="warning">
...
</Alert>
<Alert title="Error" type="error">
...
</Alert>
The main reason to separate style and form was to have readable, smaller html. My approach is much less flexbile, but that was also intentional. A TailwindUI-Component-Library. |
That looks like a good approach too @Menkir. I wondered about that as well, using the @apply and creating styles in a css file instead. This maybe the best way to go to keep it as tailwind-ish as possible? I haven't tried a more complex component as yet, but I will keep these ideas in mind. As component authors such as yourself explore this, I'm interested to learn about the benefits and trade-offs on the different approaches too! I think I'm rubbing against Tailwind CSS utility-first approach at times, when trying to maintain flexibility to override Tailwind's classes based on props. Yesterday I started to author what I thought would be a trivial e.g. something like this: That looks really simple and neat, with a concise and understandable API. But then when I accomodate different breakpoints, going by that approach I'd be creating a cols prop for each breakpoint: And potentially a similar number of breakpoint variations for the gap prop too. I'm not sure if there is any advantage over just applying Tailwind's classes directly to a div: The other thing which is a little annoying is that if I wanted to use interpolation like I really love using Tailwind, but when it comes to using it for completely flexible components in Surface, maybe I "can't have my cake and eat it" as the proverb goes! I'll keep trying though! |
|
I saw daisyUI - Tailwind CSS Components in a changelog.com newsletter a little while back. It's still a WIP as all it's components haven't been implemented yet, but it's off to a good start. I'm also interested in a Surface Tailwind library and it's great to see so much interest in creating one. |
|
I dont understand how daisyUI can exist, it is literally one of the first thing they describe in what you can or cannot do with a Tailwind license. |
|
I don't think daisyUI is using or based on Tailwind UI code. It's just using the Tailwind CSS framework directly to create a component library, which is basically the same thing Tailwind UI is doing. The Tailwind CSS framework is using the MIT license. |
|
Hi everyone! I think the time has come to try out some of the ideas discussed here. Since I want to get back to work on the Surface Catalogue and make it an official supported tool (not only a prototype), it might be a good chance to redesign the UI using TailwindCSS. In the process, I'll try to create some reusable components that could serve as the initial suite of components we want to provide in the context of this project. In case anyone is interested in helping me on this journey, please let me know. Although I'll wait for Phoenix In case you haven't seen the catalogue in action, here's a short video demonstrating some of its features: https://twitter.com/MarlusSaraiva/status/1360254701808324615. It requires some of the most common components, including Thank you all for the many useful ideas and the valuable information you brought to this discussion. They will be extremely important for us to decide the direction we should take. ❤️ ❤️ ❤️ |
|
Hello @msaraiva, Have you considered https://uniformcss.com ? It is a scss based utility framework. That way, possibly we can avoid the postcss overhead also in the project. We can just move on with esbuild and esbuild-scss |
|
👋 I was just yesterday looking into DaisyUI as way to make using Tailwind a bit easier in our project (which uses Surface), so I'm quite excited discovering this repo!... |
|
@msaraiva what would be really cool is a totally agnostic Surface Catalogue - where all components are working with little to no css at all - When we/community design components, we use whatever lib (like TailwindUI, Bulma, etc) is dearest to us, and we document that in the Surface Component Repo in some sort of way - but before we push, we .gitignore the lib 😄 In that way we get only the markup and then each develop can use the components that fits their use-case - by setting dependencies for surface_components and say tailwindcss, tailwindcss/forms. I doubt it that a string of HTML markup is part of Tailwind Labs IP - and in fact I believe that Adam Wathan will sell more libs if more devs can easily utilize his work 😃 |
|
Tailwind released something along the lines of that which they called headless ui - that might be something to use as inspiration |
|
Hi, I am a beginner with Phoenix and Surface UI, coming from React and Vue. Here is an idea: Why not use UnoCSS for styling? It can handle easily all Tailwind CSS classes easily. Features: UnoCSS It has many fantastic features, example pure css icons with more than 100K icons https://icones.js.org/ Benchmark: none 5.87 ms / delta. 0.00 ms It can be easily used instead of Tailwind and still configurable with presets to act like Tailwind or Boostrap etc. see UnoCSS presets and configurations. |
From the slack channel:
harmon:
lnr0626:
harmon:
lnr0626:
harmon:
lnr0626:
harmon:
paulstatezny:
msaraiva:
harmon:
The text was updated successfully, but these errors were encountered: