emmacharp

14 ms·

91.
by emmacharp 4y ago
It can be, yes. But I was talking more about "right" for the end user which should be less subjective (I think).
92.
by emmacharp 4y ago
A simple find and replace would do the same then for a CSS change. Again, that's not something that should happen often. As for support in text editors, you can still autocomplete any class you have in your CSS. And the CSS linting wil
93.
by emmacharp 4y ago
What is the convention? Beginning selectors in a file by the filename only? If I understand correctly, then I'd fallback on the linting. If the file is renamed, then yes, you change the selectors. That's a simple operation. But I
94.
by emmacharp 4y ago
With simple linting, I think, you could make sure to disable the vast majority of these guns. But I care to hear your take about it.
95.
by emmacharp 4y ago
You can make it mirror Tailwind's nomenclature if you want it.
96.
by emmacharp 4y ago
I should have said: "it's more than a philosophical debate".
97.
by emmacharp 4y ago
You can use the same standardized nomenclature in CSS if you want it to be "compatible" with Tailwind. Nothing wrong here.
98.
by emmacharp 4y ago
Again, I agree the base stylings etc. I do the same in each of my project using pure CSS specifically because I don't want to remember them all. So I have all the same kind of files, and change the design tokens accordingly. The only d
99.
by emmacharp 4y ago
Yes! And that's the whole point I guess. What's the best, cheapest, simplest way of preventing these mistakes? I think simple linting could be part of the solution.
100.
by emmacharp 4y ago
My thoughts exactly!
101.
by emmacharp 4y ago
It depends on the project. More HTML and CSS than JS. But, as I said, the team has been generally using the Tailwind paradigm for 5 years now. The team has also been divided for while about it. Heheh.
102.
by emmacharp 4y ago
It is, as of now, the only argument I've read that sticks. Lots of devs do not like CSS. And this is a way for them, as you said, to skip understanding the language. But, is it a "good" argument though?
103.
by emmacharp 4y ago
Well, I wouldn't say it's about CSS being a "beautiful thing". It's about delivering great experiences to our users, experiences that use our native tools in an optimized way. Because, you can ship the same experien
104.
by emmacharp 4y ago
Do you mean conflicts or spillovers? Because, as I said elsewhere in the thread, I think (maybe wrongly) that simple linting could rid you of the vast majority of these problems. But, please, if you mean something else, do comment! I very m
105.
by emmacharp 4y ago
Great question. Simple linting rules can get you lots of mileage here. First and foremost, you ensure that in any component CSS file, ALL selectors begin with a class that mirrors the filename. It seems to me that this can prevent the vast
106.
by emmacharp 4y ago
Yes I have. For a couple of years and my team still uses it. But Tailwind is sensitive to DOM changes too, since every style is on tag. You wouldn't remove any tag without understanding its usage in a component using Tailwind. Why woul
107.
by emmacharp 4y ago
But you could have the exact same design system in native CSS. I don't get why this should be considered a Tailwind benefit given that it comes with a lot more baggage. Am I missing something? edit: syntax
108.
by emmacharp 4y ago
But we can have a native, standard library for CSS. No need for Tailwind if this is the problem to solve.
109.
by emmacharp 4y ago
What do you mean by responsiveness?
110.
by emmacharp 4y ago
I agree wholeheartedly about design tokens. I use this in every project, always. But I only need custom properties, nothing else. And I get all the advantages you're describing. And I'd say that striping the cascade, removing sele
111.
by emmacharp 4y ago
Sorry about the "careless" bit. Maybe I could have chosen a better word. I get what you're saying. But again, linting should be enough to guide you in writing good CSS. It's really not that hard if we are interested. No
112.
by emmacharp 4y ago
Yes. But it creates the problem of naming everything. Which is clearly a problem in itself.
113.
by emmacharp 4y ago
Again, it's not only philosophical nor spiritual. It has numerous practical implications for any dev engaged in Web work.
114.
by emmacharp 4y ago
The « > » part should not be necessary 90% of the time. And while using Tailwind, I still have to know where I include my components. I still need to test different instances in different places. With that in mind, I don't see the a
115.
by emmacharp 4y ago
The naming of every little thing in CSS is what I call a "pseudo-problem" in the original post. You don't have to name classes for everything inside a component. You only have to name the component, as in Tailwind. Afterwards
116.
by emmacharp 4y ago
CSS is really not that hard to understand and use adequately. And as I said here, linting should be more than enough to nudge you in the right direction, CSS-wise. Or maybe you don't like CSS at all?
117.
by emmacharp 4y ago
That's great! I'd love to have a proper response as you say. As for your analogy, I'm not convinced it's adequate. The Phillips screwdriver does not reinvent the way to turn screws as Tailwind does here with styles. The
118.
by emmacharp 4y ago
I see, yes. But could we not care and try to use this native language as it was designed instead of short-circuiting it by slapping costly dependencies on top of it? Wouldn't it be a better approach considering, among other things, the
119.
by emmacharp 4y ago
You can do the exact same thing with CSS. It does not matter if the code is added to HTML or CSS. And for me, at least, this is not a spiritual debate. On the contrary, this is a very practical debate. The popularity of the tool and the sig
120.
by emmacharp 4y ago
Yes, I see. It's a way of limiting the damage done by careless CSS developers. But couldn't these mistakes be flagged easily through linting only?

More ›