Knowing CSS is mastery to front end development
175 comments
·March 2, 2025bryanhogan
exceptione
From daisyui.com:
Tailwind CSS provides low-level utility classes, wich usually inlcude only one CSS rule.
daisyUI classes are a combination of multiple CSS rule that are named semantically for each part of the UI.
It seems like the whole dance is to avoid
class="btn" style="font-color: #3e3"
class="btn font-color-3e3"
wwweston
> and BEM because it was difficult to scope css.
I suspect this reflects the cultural problem that in many organizations no one really wants to create or stick to a systematic design.
Scoping CSS isn't trivial as a site grows large, but it's far from intractable.
Tailwind's orientation on concrete details everywhere is the "just give up" solution -- stop trying to get the organization and culture to do work they don't want to do.
EDIT: I'd also guess there's an element of poor feedback loops for most development tools. When people people talk about things like "I don't want to have to look up what every class means", they're speaking to one reality of code componentization across the multiple dimensions of styling/semantics/markup/logic in development environments that often can't support interactive, legible, and interconnective feedback as development is done. There are probably solutions to this but they're more involved and less well known or fungible than just collapsing styling/semantics/markup into a single dimension around a consistent constrained UI domain language you can add to your resume in a week tops. This is friendlier to the predominant "culture" for building front ends right now.
exceptione
> Tailwind's orientation on concrete details everywhere is the "just give up" solution
Yes, and that is why I am genuinely curious whether going the nuclear approach is still needed, or that css variables, @scope and what-not of today solves the problems of the past.
Because it seems that Tailwind introduces problems that CSS sought to resolve, and now DaisyUI seeks to resolve the problems of Tailwind.
Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved?
crooked-v
For me, it's always been much less of a technical thing, and much more that the material coming out of the product design part of the business is never actually consistent enough that you can have a single consistent CSS file drive the whole site.
jmull
Something at the level of bootstrap or daisyui makes a lot of sense to me, a developer.
But designers I've worked with -- and I've really got to defer to their expertise here -- often seem to be too constrained by the fixed design structure on what I'll call "signature" sites or pages. For things that aren't that important/visible, sure, these general systems work well enough. But for other things, there's a specific vision they are trying to achieve, and forcing that through something like daisyui and bootstrap is a hell of a lot more work (for me) than building from css directly, or from utility classes like tailwind provides.
I think the reality is, the developer is building *app-level* components from html, css, and js. Naturally, you reach for something to take drudgery out of it, thus you work in terms of a middle-level abstraction. daisyui and tailwind are both such abstractions, so from a high-level there's isn't really much distinction or argument to be had. tailwind is somewhat lower level and more flexible while daisyui does more for you at the cost of reduced flexibility. Obviously, you pick something like daisyui when you're pretty sure you don't want/need the extra flexibility of tailwind, or tailwind when you're in doubt. Since you're going to have an app-level library of components, it's just not a big deal either way, just a matter of how pleasant it will be to develop and maintain those components.
grandempire
Lately I’ve been using bootstrap grid only and been happy with that.
osigurdson
I think for getting in the 70th percentile of UI design, tailwind + daisyui are fine. If you need to have the absolute best UI, it is necessary to understand CSS from the ground up.
PantaloonFlames
Thanks for all this.
> And if you do understand some CSS, getting to the next level and learning how to write scalable CSS is not much harder.
I want to believe.
I know some CSS and can write SCSS. But reaching the next level seems difficult.
madeofpalk
I think CSS gets all the flack it gets unfairly because people often run into it as a byproduct of other work they do. Whereas these developers probably aren’t running into windows/macos/ios/android app development.
wruza
I’ve ran into almost all of this, and css is still the worst thing in the list. It’s literally the highest wtf/gfy per minute among all. Barely debuggable, inconsistent, comefrom by design, inarticulate crap.
dsego
Especially since all the things that one would expect should be easy were just really difficult to do for a long time, things like vertically centering, layouts before grid/flex, changing a style in one place and not accidentally breaking some other part of html. There was a lot of tribal knowledge about browser quirks, how to clear floating divs for example, selector precedence, how margins collapse, etc, it's all just non-essential complexity that bites you in the ass when you have the least time to deal with it.
christophilus
Agreed. No static typing. Everything is global. Super easy to accidentally break a thing on some other page that you aren’t aware of. It’s just a brittle stack. Tailwind is by far my favorite bandaid for dealing with all of that. Perfect? No. But it’s the best thing I’ve used in almost 25 years doing this professionally.
bluSCALE4
The sad reality is that younger folks are too busy learning JS and backend devs just don't understand it. I've yet to learn new CSS patterns from anyone I've worked with in front end in the last 6 years. On the same note, I've worked on a few teams that have made backwards decisions and have chosen dead tools instead of embracing new CSS patterns. I think I have to take Ana Tudo, Lea Verou and Rachel Andrew for doing enough advocacy to keep my skillset relevant.
kevinsync
I haven't had a chance to read the all the comments so this may have already been mentioned further down the line, but -- IMO mastering CSS (vanilla) is essential to understanding how browsers render content, which itself is vital to understanding how to structure content (and by extension, write browser JavaScript)
Just learn it! It's worth it. It also makes Tailwind and all those abstractions way easier to grasp.
P.S. Sass (SCSS) is incredibly powerful. Learn that too!
tabony
CSS has way more features today than 15 years ago but is easier to master in my opinion.
Back then, CSS implementations had a lot more quirks and you had to keep all of this in your head. Just because one combination of CSS properties in Firefox worked one way did not mean it worked even similarly in Internet Explorer.
karaterobot
It's astonishing to me how many front end developers refuse to learn how to use vanilla CSS and Javascript, and the lengths they go to avoid touching them. I think of a lot of modern web tooling as a giant mech suit developers climb into to do battle with the underlying technologies of the web. There's so many layers of abstraction between you and the medium you work in, you can go your whole career without learning how to build a website yourself.
The original justification was 'scaling' (a word that stands behind a lot of bad behavior, actually), because you cannot just write bare CSS for a large production website, obviously. But then it creeps down the ladder until pretty soon your hobby website is a 20 megabyte SPA with 500 NPM packages backing it.
bob1029
It has never been easier to build web applications with a vanilla stack.
In 2010 there existed incredibly solid arguments for abstraction over the DOM. You had browsers with insane quirks and you had no choice but to support them. Over a decade and a half later, I'd argue we are in a completely different world. The only browser that bites my hand these days is Safari, and it's barely a nibble compared to what we used to deal with.
Those who adapt to the new reality will likely outpace those who continue to hobble themselves with rusty old training wheels.
evantbyrne
As with any profession, most workers are just proficient in whatever they need to do. The people littering these things with comments about how Tailwind is "enough" are probably telling the truth for their personal experiences. A lot of web developers don't have professional experience working with designers and implementing software to visual specifications.
gjsman-1000
I think you miss the point.
Having 25 developers trying to manage a CSS stylesheet together while naming classes does not scale.
Having 25 developers not worry so much about stepping on other people’s toes with Tailwind scales better.
Or in a nutshell: What is one of the hardest problems in CS? Naming things. What is Tailwind’s biggest feature? Build a frontend with minimal need to name things.
exceptione
25 developers working in the same module? Without a common style?
Afaik we came from plain CSS -> BEM, because scoping styles was hard, so people found a discipline in naming things to isolate styling. Scoping did not exist in CSS.
Then we got a movement from BEM -> Tailwind, because doing the scoping by hand was a bit difficult(?)
Then we get Tailwind -> Tailwind + DaisyUI because Tailwind results in messy concretion.
--------
The question I have: are the modularity/scoping primitives in modern css good enough now, rendering Tailwind e.a obsolete?
Are we still using Tailwind because people do not understand the original problem?
Maybe someone can enlighten me.
isodev
> Having 25 developers trying to manage a CSS stylesheet together
As opposed to 25 developers trying to manage a React component together? I don't think that's feasible either.
dsego
Hence why companies adopt UI toolkits, otherwise it gets messy. Without discipline it's hard to develop a set of core components and often times devs will duplicate work and fail to extract common parts due to the nature of working on features across the stack and failing to recognize common patterns.
azangru
> does not scale
CSS already has @layer; and @scope is coming (waiting for firefox).
There are naming conventions like bem. There are also tools to guarantee unique class names (css modules, 'single-file components' in various js frameworks).
There are design systems to standardize and reduce the amount of CSS.
There are web components, with their styles encapsulated in the shadow DOM.
alt227
Why on earth would you ever have 25 front end developers editing the same classes in the same stylesheet?
gjsman-1000
12 year old project, 2 developers per year, turnover every year. That’s all it takes.
jakelazaroff
CSS modules solved the classname collision problem years prior, though.
recursive
When people say "CSS modules", I never know which one they mean. There's a feature on the spec track for CSS "imports". There's also a family of webpack plugins with various behavior. CSS modules, collectively solved it a number of times with various trade-offs. You can even end up with multiple kinds of CSS modules in the same code base.
sfsefwafawfa
Hard agree, written Tailwind since the very inception. I love it for exactly this, the purging, JIT, arbitrary values, plus you can just write plain CSS any time you want. I have used Tailwind on big FAANG sites and boutique shops. Worked great for both, scales, and is very customizable.
iammrpayments
I’m forking Shopify’s polaris-react library for my personal use and some of the components are clearly made to people who don’t know how to use CSS.
For example, there’s a component called “InlineStack” which is just a javascript wrapper for a div with flex. This stuff drives me nuts.
prezjordan
You're leaving out the most important bit of a component like InlineStack: the props [0]. Yes you can just apply `display: flex` to the div you're working on, but like any proper abstraction these guardrails make using flexbox correctly the easiest path forward (the "pit of a success").
[0]: https://github.com/Shopify/polaris/blob/eb6161f6b4e02679b5e8...
dsego
Because sometimes you just need a flex wrapper. And it's easier to see InlineStack everywhere in your JSX than deciphering the layout from mixed CSS. Whereas plain CSS separates some concerns away from HTML, it also intermingles different concerns together, like layout, positioning, spacing, look & feel, etc. At least with structural or utility components like Stack, Group, Flex, or whatever it makes it more obvious what the intent is.
Zardoz84
Then you are doing something wrong about the layout & components in the page.
korm
It's a bit like the <center> tag. A codebase that's littered with stuff like "InlineStack" is harder to work with and parse because the resulting div soup still requires extra styling, which is now both markup and CSS.
dsego
Why is it harder to work with? It makes it immediately obvious what the visual layout is and what the purpose of the component is and a lot of time all you want to do is have a flex on a component and you don't need other CSS to warrant yet another CSS class. It's the same reason why utility CSS was created (eg <div class="flex">). It also saves you from having to come up with a semantic name in your CSS for every wrapper.
Compare the following:
<Stack gap={2} direction="row">
<Box>
<Avatar />
</Box>
<Box>
<Button />
</Box>
</Stack>
-----
<MyCustomWrapper>
<InnerChild>
<Avatar>
</InnerChild>
<InnerChild>
<Button />
</InnerChild>
</MyCustomWrapper>nfw2
The benefit of components like InlineStack is that the components then have names that semantically describe their purpose in the layout.
yolo3000
The fragmentation this creates is not worth it, we're building the tower of Babel of web technologies. If you look at 'modern' web applications every html component is rephrased into something like this 'inlinestack' crap.
yurishimo
The tower of Web Babel was built 5 years ago during peak React. It’s gotten better tbh as more competition has creeped into the web space due to React dropping the ball and resting on their laurels.
While I understand the gut reaction to seeing something like InlineStack, it’s not any different than a utility class except the abstraction has been made on the component level instead of the CSS level within a bunch of different components. The other thing is that these types of components provide a layer for abstraction that extends beyond the web. If I’m writing a app that targets web and native mobile, I can let the compiler decide which version to place in the build to take advantage of native features of the platform.
At a certain scale, programming becomes about maintaining consistency at said scale and less about the craftsmanship of an individual component. As a developer who also enjoys writing CSS and building layouts myself by hand, I understand your frustration but it’s misguided towards a group of developers who are trying to solve different problems.
We don’t need to implement everything that FAANG comes up with in their “innovation labs” and I 100% believe that there is a place for handcrafted code in applications for decades to come. But let’s not lose site of the fact that table saws haven’t replaced hand saws. They serve different purposes for different audiences and that’s okay!
Towaway69
I’d personally prefer to write markdown instead of html, especially when writing comments on sites like these.
But I have to know that stars represent html italic tags (and bunches of other stuff).
Thankfully this has been standardised and every markdown parser knows what stars mean. So I only have to learn this once.
Most frameworks haven’t been standardised and that’s where the frustration lies.
Abstraction is good when it becomes a commonality, bad when it remains niche.
bryanrasmussen
Why is InlineStack any more semantic than say FlexDiv?
Semantics is at some point arbitrarily agreed upon and memorized.
dsego
It's not, FlexDiv is just another name for Stack, they are describing the same aspect. Eg. you can imagine one CSS library using Flex, one Group and the third one Stack for the same concept, eg. some other UI frameworks use VBox and HBox. But it is still different from TopSectionHeader, SectionHeaderInner, SectionBodyWrapper, or whatever other names you have to come up with to give your component "semantic" meaning according to their content.
nfw2
Because flex just references the layout engine, and div intentionally has no semantic meaning. Fwiw I don't think InlineStack is a particularly good name either, but the criticism of this needs more justification than just "it's not how we did things in the past".
Semantics evolve over time. This is true of natural language and coding practice.
iammrpayments
I instead use <div class=“flex”><\div> now.
If the class name is not enough for me to guess, I just hover the class name and the LSP will show me the applied styles.
Another issue is that Shopify changes the name of these components for no reason, for example InlineStack was once called Inline, then HorizontalStack, then InlineStack, while the flex box model hasn’t change since 2012
alberth
CSS for styling is straight forward (which makes sense since ‘CSS’ is cascading ‘styling’ sheets)
CSS for layout takes sometime getting use too.
For me, the benefit of any css framework is not in prepackaged styles - it’s in simplifying layout for desktop/tablet/phone.
RealCodingOtaku
The mastery to front end development is understanding the semantics of HTML.
At every single company I worked for, I had to teach people to stop using div tag for everything. You can style things however you want, or even create components that the browser does not allow you to style (as long as you have fallbacks).
dsego
I've seen juniors style divs as buttons, it's disheartening.
azemetre
I’ve seen seniors do the same thing.
The root cause always seem to be the same.
Pressure to get things done now. No time in the future to correct things. Possibility of getting fired for falling behind your peers that make the same shortcuts while you attempt to do things better.
It’s always an issue with management that doesn’t care about doing things correct. So the incentive to keep your job is always perverse.
alt227
> I had to teach people to stop using div tag for everything
Can you elaborate a bit on what you mean please?
null
jfengel
Does HTML even have semantics? You practically can use div for everything, and then use CSS to make it act like whatever component you wanted.
You should let the defaults do their job, but they don't do very much. HTML's main semantic is to give things a hierarchical structure. Visually it's a free for all after that
theandrewbailey
Yes, html has lots of semantic elements.
https://developer.mozilla.org/en-US/docs/Glossary/Semantics#...
neontomo
> but they don't do very much
no no no, different elements have different behaviours. for example, a button automatically has accessibility features like being able to tab to it and select with Enter key, which is essential for a screenreader. do that with a div and you end up building the functionality from scratch.
if all you care about is the visuals, sure, there's little difference, but once you scratch the surface you will have a poor product by not using the correct elements (where there is a clear "correct" ofc, sometimes it's subjective).
phartenfeller
For me TailwindCSS actually was helpful in learning CSS. You still apply the same core CSS fundamentals. If you created a complex layout in Tailwind, you can also do it in normal CSS. I look up the exact rules behind their classes frequently in their docs.
If you just copy classes and don't care to understand them, it's a different story of course.
robin_reala
You don’t apply the same core fundamentals because Tailwind works to specifically remove the core fundamental of CSS: the cascade.
kristiandupont
I guess, but that has certainly been a huge relief in my personal experience.
nfw2
yes, specificity wars make it really hard to reuse components across multiple product domains and teams within a large org.
by css fundamentals, they just mean what the various style properties do.
bpev
Frankly, I feel like it goes even further than CSS. People don't really talk about HTML that much, probably just because it doesn't change as much as JS frameworks, etc. But that doesn't mean you should ignore it completely and just use a bunch of divs!
When you start digging into all the different HTML elements and aria guidelines (for example, the differences between `<nav />` and `<menu role="menubar" />`), I think development starts to be a bit more clear, because you start to see how your tools are intended to be used. I think it also makes decisions around CSS styling more clear. And as a bonus, your code just starts becoming more accessible, which is nice.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
ulrischa
"Knowing" CSS in these days is nearly impossible. There are so many language features. Don't get me wrong: CSS today is cool and nearly anything is possible (can Doom run wirh CSS by the way?), but I work as frontend dev for years and I have not the feeling I really know CSS in depth
mattlondon
There is knowing and there is knowing.
I don't pretend to know every dark corner of typescript, neither for CSS. But knowing enough detail to be efficient and write maintainable and easily extendable code is important.
Don't let perfect be the enemy of good.
soulofmischief
It just sounds like you need to spend more time solving problems with CSS. "Knowing" CSS means being able to style most things without needing to check any resources or otherwise look for help.
Occasionally there might be a particular issue that requires contemplation or reading the manual, but that is true of any sufficiently complex design system, especially a living specification such as CSS.
I recommend familiarizing yourself with new features as they are adopted. For example, front end devs are going to need to learn Houdini.
wruza
I spent some honest time solving the problems in css. You know what was the industry/search approved solution 90% of the times? Some greasy hack that assumes sizes and doesn’t translate elsewhere or generalize into experience. You just start to know how to make a single x of X, but X is still as big.
Css is a pile of low-effort crap targeted specifically at ad-hoc problems web designers had. It can make front pages, and sucks at everything else.
soulofmischief
That was way back, things are a lot better now than they were 15 years ago. Anyway, I got by quite far never assuming sizes with hacks like `height: 0; padding: 100%;` etc. But that kind of stuff is almost never needed today to get good results.
> It can make front pages, and sucks at everything else
I've made some very slick apps and widgets over the years using CSS. CSS isn't the problem, a lack of imagination is. CSS actually covers quite a lot of cases today, and with Houdini etc being exposed, the sky will soon be the limit.
bob1029
I think knowing what to ask and where to look represents mastery of CSS.
Understanding the approximate power of things like flexbox and having some aesthetic taste is much of the battle. You have to be willing to get your hands dirty. CSS is almost entirely about art. Figure out which paint brushes and techniques work best for you. There are a lot of viable paths.
econ
That was then, now it is a 3d engine.
mablopoule
No, it has a 3d engine, one that you can happily ignore 99.9999% of the time. CSS has a few gotcha, a few things to got to understand about it (selectors, selector priority and the way content flow depending on absolute / relative positionning), but it is not an impossible language to pick up, far from it.
As the grandparent comment said, don't let the perfect be the enemy of the good.
postepowanieadm
After reading mixu/cssbook I felt I knew and understood CSS quite well. But it was 10 years ago! Every new feature brings new edge cases that combine with all existing edge cases. Add some features like WebComponents and you have far too much undefined behaviour.
soulofmischief
What undefined behavior have you encountered with CSS?
postepowanieadm
Tables and Web Components combined with grid or flex is where magic happens.
arvinsim
In this age of LLMs and AI, the incentive to master CSS is even lower.
econ
I knew css at a time, then it ran away from me and mocked me from afar.
bryanrasmussen
how many features does CSS - the language - have now in comparison to JavaScript?
How many features do the various APIs altogether have.
How many features do the various object models have, CSSOM, SVG DOM, HTML DOM, Shadow DOM...
What is your knowledge of all these features in comparison to CSS features?
Jumping off of that and go look at any mature language and CS subject, there is probably too much for you "know" completely, but there is of course possibility to "know" a general argument for how to use it properly, once that is known individual things is just looking up syntax.
bryanrasmussen
ok evidently someone thought that all of these things are easier to know than CSS, which is just ludicrous, and gave me a downvote to let me know their disapproval of my opinion.
Very Classy. But not CSS Classy.
JansjoFromIkea
I wouldn't get too hung up on downvoting online, ignoring deliberately malicious actors the range of reasons for downvoting can go from "this person posted a hate crime" to "other people already posted something close enough to this" or even "this person gave a perfectly valid answer but it does not feel like it's taking the discussion in the direction I feel it's meant to go"
sublinear
These jokes, as lightheartded as they are, need to stop. Especially true on here.
ripped_britches
This is why I fully moved to flutter. Everything, including styling, is just a widget. It’s surprisingly liberating to write boring C# looking code that accurately describes a UI component without inheritance, overrides, style compiling, etc
notpushkin
It also throws away HTML and throws everything on a canvas instead, which means three things:
1. Accessibility is now an afterthought
2. Giant runtime you have to download for every website
3. Bewildering non-native behaviour on mobile
llama_drama
> Everything, including styling, is just a widget.
And that's the downside. What would be just two or three nested <div>s in HTML+CSS turns into several screens of widgets, making navigation and debugging much harder. I once had an issue with extra margin in one of Flutter's built-in widgets and spent hours trying to figure out why - without success.
amonith
Same, as C# dev I love Flutter. However I just know in my bones that Google will ditch it some day. It's been too many years without significant adoption and it will stop making sense in the corporate spreadsheet one day.
frou_dh
At least according to this post which was on HN recently, Flutter lacking significant adoption is a myth: https://shorebird.dev/blog/dart-macros/#:~:text=Flutter%20ha...
b0m
Hi. C# dev here. Would you please elaborate a bit how do you use flutter and C#?
baueric
I think he means Dart code resembles C# pretty closely.
pjmlp
Basically why Flash ruled back in the day.
Gualdrapo
I agree. But I feel like nowadays knowing CSS is not necessary to land a job in FED - while knowing frameworks as React/Next/Vue/whatever is.
bryanhogan
The idea is that by knowing HTML and CSS you know how to use any framework. Since they are the base technologies that every front-end developer should know, a frameworks should build upon the principles of these.
This doesn't hold true for React, since they just decided to do their own thing, but for frameworks such as Svelte this is a core principle they try to stick to.
alt227
When I am hiring, I will always prioritise devs who have a strong knowledge of HTML/CSS/JS over any frameworks.
If you know the language you can use any framework in that language with minimal effort, and the bonuses of being able to troubleshoot underlying issues is invaluable.
nickpsecurity
HTML/CSS was on most job descriptions I saw. Entry level wanted those and Javascript at a minimum. Your odds are better if you know all three.
albedoa
> HTML/CSS was on most job descriptions I saw.
Those are going to be on nearly every FE job description you see. I think OP's point is that they are not necessary to land a job despite their automatic inclusion in the job description.
(Speaking anecdotally, the companies I have worked for either don't have any CSS masters to sufficiently test for mastery or don't include those experts in the interviewing process. Or, more commonly, we are so desperate for framework devs that any amount of CSS knowledge is considered good enough.)
noelwelsh
Between Tailwind and LLM generation I doubt I'll ever write more than a handful of CSS lines by hand in any future project I work on. CSS has, for me, become like the ASM output of the compilers I use. The result is good enough 99.999% of the time for me and I want to work at a higher level of abstraction.
Boltgolt
Interesting, I can type CSS much much quicker than describing to an LLM what kind of layout I want and with what look
noelwelsh
I find LLMs are best for creating the template, or filling in gaps of my knowledge. Examples:
1. Using a prompt like "Using Tailwind, create a three column layout with main content in the center column and smaller side columns for ancillary information" will generate HTML + CSS faster than I can type.
2. I use the LLM to generate some CSS styling for setting a background blur, which was something I hadn't done before using Tailwind. It created code faster than I could find things in the documentation, though I had to go and patch it up later. In essence it pointed me in the right direction.
If I'm looking at a preview and want to change the styling of a particular element it is usually faster to directly edit it myself than get an LLM to do that. Tailwind makes this faster as the CSS is right there on HTML; I don't have to switch between stylesheet and HTML.
skydhash
1. I’ve mostly gone to the grid section of the docs of whatever framework I’m using (bulma these days) and copy paste the example, then copy paste my own code when I have enough pages done.
> Tailwind makes this faster as the CSS is right there on HTML; I don't have to switch between stylesheet and HTML.
I mostly use the web inspector for live edits to get a feel then I copy over the final result to the sheet. For more complex components, I use Codepen.
OsrsNeedsf2P
The downvoted comment is correct. The only CSS I've used in the last couple years has been to debug issues Claude couldn't resolve - and to delete excess styling that wasn't being applied anywhere.
It has given me the flexibility, accuracy, scalability, and proved the test of time (going strong on 3 years)
spoonfeeder006
> Custom icons for an input field? Welp, it’s not that easy for privacy reasons to add a pseudo-class here in certain cases.
What exactly are those privacy reasons? And by custom icon for input field is meant replacing the cursor with e.g. an svg?
AlienRobot
The only thing I can imagine is if they are third-party icons? I don't understand it either.
alex-e-leon
The issue is that css doesnt allow adding pseudo elements (:before/after) to input fields, making adding icons to an input a little trickier than with other elements.
I disagree with many of the comments here. CSS is not too complicated. It's a good way to style HTML elements.
There are some popular abstractions to writing CSS such as Tailwind. Although I do see it misguiding a lot of people. When you don't know CSS but want a webpage, use a template instead. If you want deep custom styling you will need to understand CSS. Tailwind is just a collection of predefined utility classes which you then over use, breaking a few clean code principles along the way, but you get a decent looking website without writing all the utility classes yourself, which can be helpful especially in larger team projects.
There are improvements to this problem such as DaisyUI.
But regardless, they do require some understanding of CSS. And if you do understand some CSS, getting to the next level and learning how to write scalable CSS is not much harder. The simple requirement of having global and scoped styling is a given in every modern framework.
This is partly what led me to create a guide on writing modern scalable HTML and CSS: https://webdev.bryanhogan.com/
- Tailwind (wow, the website is laggy): https://tailwindcss.com/
- DaisyUI: https://daisyui.com/
- Some modern framework, e.g. Astro: https://astro.build/