Greetings Everyone!!!
A little bit of my background so it could be easier to understand where my comments are coming from, and to take them with a grain of saltâŠor lots of.
I started coding back in 1989. A few years later I was writing code with VIM in Unix: FoxBase+ and C. So, I am very used to code on a simple and fun programming language, and in a not so fun but powerful language, hence, I am used to allocate memory when needed and freeing it when no longer needed, and yes, I still use Short integers when available: The very first computer I used had 128Kb of RAM, the Tandy Color Computer 3. Some habits are hard to break, and I really want my programs to be thin and light. I am barely starting with Elixir, Phoenix, LiveView, HTML and CSS, thus⊠I really see no point on using Tailwind. I started using Linux in the mid '90s because I love the freedom it provides, so I totally agree that everybody is free to choose if they want to use Tailwind or not. Everybody is free to chose their poison. No questions asked (my VERY PERSONAL point of view).
I agree with @knoebber, @eiji and @D4no0: If the user entered the --no-tailwind parameter, there should be no Tailwind code in the project.
I disagree with both âŠ
⊠and âŠ
This is because I think a âstyle sheetâ already exists, even though it doesnât. If you create a project without Tailwind, the LiveView page you create after that wonât show any CSS formatting (so, no style sheet actually exists), but there are lots of Tailwind classes already mentioned (so, some sort of style sheet exists, it just happen to have empty references).
I kind of agree with @knoebber but with a slightly different approach.
Here is what I think (my very personal point of view):
As the documentation says The generated markup will still include Tailwind CSS classes, those are left-in as reference for the subsequent styling of your layout and components. This kind of defeats the purpose of the âno-tailwind parameter, because, even though it is not configuring the project to use Tailwind (as requested), it is leaving Tailwind classes as empty references, i.e., misinterpreting the âI donât want to use this CSS Frameworkâ with some sort of âI donât want to use CSSâ.
I just created an app with the âno-tailwind parameter, checked the core_components.ex file and the first class statement there says:
def modal(assigns) do
~H"""
<div
[...]
class="relative z-50 hidden"
I havenât checked where this class value comes from. My first guess is it is hard-coded somewhere, but lets just say it comes from the source. At this point I want to think the source already knows what that divisionâs attributes should be, since it has a class value in it, so we already have a style definition. As far as I understand, Tailwind would have created three classes in the priv/static/assets/app.css file:
.relative{
position: relative;
}
.z-50{
z-index: 50;
}
.hidden{
display: none;
}
Since the purpose is to get rid of Tailwind, but to keep some sort of references for the subsequent styling (thatâs why they are leaving references behind, right? Empty references, but references whatsoever), letâs get rid of the Tailwind classes, but leave references to actual CSS styles: the parameter is named --no-tailwind not --no-css.
Instead of the source defining empty Tailwind references in core_components.ex, lets have the source to name classes pointing to actual CSS Classes in the priv/static/assets/app.css file, since it already knows the attributes. Something like:
# === core_components.ex ===
def modal(assigns) do
~H"""
<div
[...]
class="relative_late_hidden"
# or "drlh", "nice_hidden_item" or a much better name than this
# I am sure the Phoenix Core group will find a better name
[...]
"""
end
# === priv/static/assets/app.css ===
.relative_late_hidden {
position: relative;
z-index: 50;
display: none;
}
This way we accomplish what the --no-tailwind parameter should do: Get rid of Tailwind, and at the same time, we still have references to the style, as the documentation says. Plus, if we need to change how a component looks, it already has a reference where to modify the component looks.
This is what my limited knowledge of Web Development+LiveView reaches. I hope it makes sense.
Best regards,
Greg.
