Any CSS work eventually devolves to adjusting numbers until everything falls in line, adjusting for the 2 pixels of padding there or the borders of some other thing. Maybe nowadays there is calc where you don't need to do that, but it didn't exist back when I did CSS.
I feel the same way, and I first wrote CSS in 1998 when it was so new that Netscape misinterpreted even the font size property.
There are now thousands of properties and their values, and browser engines have gone to heroic lengths to produce mostly consistent results from these often conflicting directives. But I still keep looking up basic things because the API is simultaneously sprawling and inexpressive and context-sensitive.
IMO, the core sin of CSS is mixing up three separate concerns: element styling, layout, and compositing. It’s mostly ok for the first. It’s insanely confusing for the second. And it mostly tries to pretend it’s not about the third at all, which leads to weird situations around implicit compositing groups.
We ended up here because CSS started as basically a copy of a handful of Microsoft Word dialog boxes (hence “float” etc.) And as soon as we had got the word processing use case barely working, everybody decided they wanted to build dynamic applications with this same engine instead.
The core sin 0 of CSS is introducing another item-value syntax to the stack when there are regular markup attributes for that exact purpose already. Then it gets worse by taking this simplistic syntactic device ad absurdum, only to then finally also start introducing expressions (calc(), custom properties, media queries). Really, CSS should've been sealed a long time ago, with a low-level API a la Houdini available for programmatic layout from JS rather than bloating the language to become accidental Turing, when these highly dynamic styling features are useful for JS apps anyway. Anyway, considering its complete lack of mental discipline and basic CompSci, the CSS WG at W3C has no business designing languages IMNSHO.
I completely disagree. If CSS were "sealed" it would be absolutely terrible and we'd still be dealing with floats and absolutely positioned elements. The problem with CSS is the weird implicit behavior and edge cases that remain due to compatibility.
Computed properties, custom properties and media queries are well designed.
What CSS needs is a refactor. Make a much smaller Strict-CSS that uses the same code paths in browsers, but provides far less options to the user, sticking to modern tools (grid, flex) with simplified naming schemes, while deprecating old ways of doing (float). That would finally allow a manageable mental model.
I was like you until about a year or two ago, and then set out to learn it enough to implement a site layout without having to resort to copy and pasting things I don't understand.
It wasn't that hard, once you accept that it'll require it's own study and practice. I put in maybe 20 hours dedicated study and got a lot better out of it.
I did a few video courses on LinkedIn Learning (formerly Lynda.com) through my public library. I did a general CSS course and a flexbox CSS course. Then I set out to design pages I needed without pulling some random blog theme and calling it a day.
I've gotten a bit better at design as well, although it is a much intrinsic field than CSS and requires a lot more study. The biggest difference was once I treated the design stage with respect as its own discipline and started designing in a design tool (figma) instead of "doing it live" by trying to tweak the design in code as I went. It made me 100% focused in that stage at the design problems and the feedback loop got a lot tighter compared to editing and running code to see how it looked.
Because most css without context are useless. A div with width 100% may not stretch depending on it's content and parent css. It's even worse on positioning, margin and responsiveness.
Which is why if you don't interact with it day to day basis, you'll need some trial and error, as well as references and examples.
Opposite to backend or usual programming where `foo = foo + 1` is most of the time do an increment by one (exception apply)
There's a lot of unpredictable stuff too. I was trying to change the border color of a checkbox to match a framework being used elsewhere and for the life of me couldn't figure out why neither setting outline or border changed it. But on the framework's website demo it was doing it just fine.
Combing through the CSS and the computed styles panel in dev tools gave me nothing.
It turned out there is an option to disable the standard OS form theming which isn't communicated at all in dev tools for that element (and I hadn't seen --webkit-apperance used before as the guide says you really shouldn't mess with it): https://developer.mozilla.org/en-US/docs/Web/CSS/appearance
You have made some bad decisions if you find yourself 15 divs deep.
There is a surprisingly small amount of content out there on how to competently engineer your CSS (and a lot of it is bad). Most people don't even think it's something you do.
But basic things like making your general rules generic and pushing context descriptively into the HTML go a long way into making your code understandable.
Sure, if you have some general rules that apply to all your widgets. If you are talking about something more specific, you are better with a more specific name.
I've got a feeling some people might consider this to be a rather snarky response, but honestly a lot of trouble comes from assuming you can muddle through CSS, and you can. Unfortunately that means it's easy to always be an expert beginner, and never quite grasp the underlying logic, as obtuse as it may be.
Fair, but actually that just means that the border and margin etc are pushed outside the container. In either case the div is operating by taking up the full width of the container.
Any chance you could show an example? In theory a block level element can only sit inside another block level element. And those expand to the width of their parent unless you constrain the width.
I really benefit from reading comments like this, so I appreciate your honesty. I didn't start learning JavaScript until very recently, even though I was making my own personal websites back when Angelfire, Geocities, and Tripod were still a thing. Instead, I focused on the frontend HTML/CSS combo, constantly learning and implementing new CSS technologies whenever I had an excuse to try them out. Because of that specialization, CSS feels understandable to me. My insecurities about my own abilities often present themselves as a belief that investing time in CSS was the growth of a cheap and relatively useless skill for a web development team. Whenever I see that someone who likely knows incredibly more about JavaScript and other programming languages — things that I feel are far harder to understand than CSS — share about how either HTML or CSS is difficult to use, I feel a little more confident that I do bring some value to the team with whom I work at the office.
Hogwash. Where in the box model are the precedence rules for selectors defined? How does the box model help with page layout and positioning? Animation? Transformations? Pagination?
Sure, the box model is a prerequisite to understand CSS properly. But if you think the box model covers all aspects, you really don't know very much about CSS.
I only do UI for business-facing apps and my own projects. CSS Grid massively improved my frustration with CSS. It makes it much easier to reason about how your page layout works.
I will never ever do another layout without it, stuck together by glue, snot, and magical trial-and-error.
It's one of those things that frameworks had been doing since (before?) 960gs. A Grid really needed to be incorporated into CSS and I'm happy to use it or flexbox for layout purposes depending on my use case.
I’ve still not gotten to grips with CSS grid, mostly because flexbox does what I want so I end up falling back on it at the first hurdle. But the rest of it is very clear to me these days.
This is the kind of HN comment I come for in these kinds of threads.
One person saying one thing (CSS Grid is the one thing keeping me sane!)
Another person coming in to say the exact opposite.
I'll be a little more helpful since I wrote a one liner without really explaining anything...
One explanation people like to give is:
CSS Grid is for layouts in 2 dimensions, Flexbox is for layouts along one dimension.
Which can be confusing because you absolutely can use Grid for layouts along one dimension too.
Here is my stupid sounding rule of thumb that I think is more useful: If you want a grid layout use grid, if you want a flexible layout use flexbox.
Grid quite literally splits the area into a grid but what if you want to just say "I want these two elements to be as far apart as possible within the container they are in" (ie a navbar, you want the logo on the left about 20 pixels away from the left of the viewpoert and you want the actual navigation to be on the right with the rightmost element 20px away from the right of the viewport). Flexbox is better for that.
I do often end up using Flexbox for 1-dimensional layouts, but IMO Grid's fr units are a lot more intuitive than Flexbox's combination of flex-basis/flex-grow/flex-shrink. If CSS added a 1-dimensional layout mode based on these principles then I'd switch to it in a heartbeat.
What bugs me the most is Flex centering absolutely sucks at handling overflow. Have a flex box with content that is supposed to be centered? Great, looks perfect for the first few items. But then try it on a smaller window or with more items and the content overflowing to the left of the border will be entirely inaccessible.
Allowing scrolling both ways would have been perfect. Switching to left-aligned when content overflows would be acceptable. But completely prohibiting access to half the content when an overflow occurs? Absolutely asinine.
I believe there may be ways to get around this with layers of inner divs and weird `overflow: ` incantations, but that's exactly the kind of bullshit flex was supposed to solve.
Most, even 2D layouts map easily into nested 1D flexbox in my head. I feel like a single dimensional approach to layouts is way easier to wrap my head around and design with.
I think they mean it’s a complicated solution for an uncomplicated problem.
Grid systems existed long before CSS grid and were dead-easy to understand and use (960, Bootstrap etc). CSS grid, by comparison, is completely unintuitive. Sure, it’s definitely more powerful, but the barrier to entry is way higher.
Exactly. "Align things to a grid" seems like a simple concept, but CSS grid seemingly has at least 3 ways to place the top-left corner of an element, and it just gets worse from there. I tried it for a simple layout with 3 elements and quickly decided I prefer flexbox, tables, or even floats.
What options exist today for making CSS easier? (It's been a long time since I've done front-end work)
Seems like there would be some sort of layer on top of it that someone built that makes things more consistent and then will compile down to the inconsistencies and odd behaviours for how CSS is supposed to be implemented.
There's supersets and siblings like scss, sass, less, there's different modes entirely like utility classes (Tailwind) and css-in-js.
I don't think any of those make CSS much easier, though. Quicker to use, easier to write certain things, sure. But you still need to know your way around CSS atleast somewhat before you jump in to some augmentation or replacement.
Same here. I think it's because you typically conquer a language by developing a fairly complete mental model of that language's behavior, but with CSS there are just too many nooks and crannies to get your had around. While it's uncomfortable for me, I find that I do best with CSS when I take a more practical approach and just try to use best practices to accomplish what I want without having the deep understanding that I crave.
I've found that Kevin Powell [1] is a great resource for this approach, and he also helps with the model model aspect as a bonus.
I found that Tailwind helped me get more comfortable with CSS. If you put the mechanics of using classes aside, it’s essentially just a well-curated subset of CSS with great documentation. Way more approachable than the sprawl of CSS itself.
The "fun" part of being a frontend dev who naturally gets pushed into fullstack as part of the realities of the job is I have to keep on top of developments in CSS, UI frameworks, Typescript, Vue, testing frameworks, Ruby, Rails, etc. Not to mention the build tooling (Vite/webpack) and deployment / operating system stuff. Fortunately the database stuff rarely changes with Postgres.
I wish I could specialize on any one of these sometimes...but such is life at a startup. It's more interesting being able to do them all anyway and be able to build entire apps yourself. Just occasionally frustrating.
CSS seems like it was “designed” by several teams in an “agile” environment with no plan and simply didn’t consult the people that would actually be using it.
I've developed apps using XAML for a considerable amount of hours. XAML is significantly more restrictive than CSS. Windows UI toolkits will give you a bunch of pretty high level components, but the primitives for build anything else are extremely poor. It lacks something like flexbox or grid.
Last time I investigated having a uniform grid of items is impossible without falling back to custom C# layout code.
Colleagues have suggested the same. My strategy has been to try to avoid frontend and when I must do it I make sure everyone involved understands my limitations.
I found XSLT kind of mind-bending, but also extremely satisfying and quite productive. Like SQL, it’s declarative, so you have to get into the mindset of telling the computer what you want, not what to do.
You may be a smarter person than me, but I couldn't handle it and quite possibly that was partly related to its truly appalling XML-based syntax. I'd like to point out that no other language I'm aware of is so syntacticallyvile that they have to add a new mechanism just to pass parameters around – parameter tunnelling.
Oh Lord. You’ve just triggered a horrific memory of how in my first job we used XSLT to convert xml files of job applications into sql that was then executed to import them into the db. That truly was mind bending.
From start to finish, never. When I had a problem I googled what to do and read the specs of the suggestions that I saw to try to make sense of them. Usually they were not helpful.
It's interesting to see how a big company with a lot of talented engineers would build a brand-new web app, since there's so many ways to achieve similar results.
CSS is a big part of the web and lots of people use it every day. I find this post interesting because it inspects a world-class app used by millions of people, and it showcases some of CSS’s latest capabilities, plus it has nice graphics illustrating the findings!
But did you actually read the blog post about "BS blogs"? Because it's not actually about blogs being BS and how one cares. It's about how you should care about what you are writing and tell everyone else to f-off.
> This post likely was written by a newbie who is trying to enter programming world and by writing a blog about CSS paddings thus keeping his ego inflated
What a weird statement to make. Like mindboggling weird.
There's nothing wrong with newbies documenting things and writing up details on how things work. Because other newbies need it. And besides, haven't we all here figured out by now that the best way to learn something is teach others?
I'm seriously at a loss for why you are arrogantly bashing and trying to shame for someone putting effort into understanding more about the world around them and trying to help others at their level understand. Your time is better off spending time understanding that the world doesn't revolve around you.
I wasn’t there so I can’t judge, but if you got dinged about naming then maybe they interpreted that as you caring about “it works” but not about “team member reading the code understands why it works”.
Personally I’d be hard-pressed to move an applicant with a less-than-obsessive attitude to naming forward to the next round.
Come on, naming is table stakes. It’s nothing like the usual “please sort this red-black tree” that comes up during stupid interviews but never on the job. Naming comes up on the job all the time and if you routinely get it wrong then over time you’re likely to create more problems for your colleagues than you solve yourself, because they can’t easily understand or refactor what you built. Ie you’ll have negative productivity.
When you’re an interviewer you have to make a decision based on way too little signal. This means you zoom in on the things you do see, and you accept the chance that you might reject a great candidate. I can completely imagine a company rejecting a candidate because they didn’t care about naming.
Now if you think “worried that candidate might have negative productivity due to careless attitude, soft reject” is obnoxious then fine but I think that makes you spoiled. You’re not entitled to a job, even a junior position, simply because you can write a loop or center a div. Real world engineering has more going on. Interviewers look for those signals, so better work on getting them right.
Naming is also something that the team needs to decide on. As an interviewee applying for a position in an existing team, I would not expect to get dinged on my naming of variables for a piece of demo code. I would expect to conform to the team's existing naming standards, so bringing and displaying my own preconceptions would be completely useless.
I’m not talking about capitalization, I’m talking descriptiveness, meaning, precision etc. You know, naming.
The idea that naming is about someMethod vs Some_Method is nuts to me. Just choose a thing and do it. Naming is about words and meaning. It’s hard, and it’s important.
So was I. Maybe next time respond to my actual words, not your slimmed-down interpretation of them? Some teams are perfectly ok with single-letter local variables, some are not. Some teams are perfectly ok with single-letter parameter names, some are not. Some APIs I've worked on even specified the units in quantity parameters (e.g. HeightInMeter, WeightInMilligram), others would only specify that in the documentation (if you're lucky).
Naming is about words and meaning. It’s hard, and it’s important.
When working on a piece of throwaway pseudo-code, no it's not important.
Every interviewer seems to have their own idiosyncratic version of what they consider "table stakes". So table stakes ends up being everything and nothing.
> I can completely imagine a company rejecting a candidate because they didn’t care about naming.
Didn't "care" about naming, or didn't focus on naming in some little throwaway sample code for a job interview?
It's of course not the same. But technical interviews aren't always just about "does this solution you wrote actually work." A good interviewer will be paying attention to how you solve the problem and how you communicate the choices you make along the way. Good naming is part of good communication.
Except every interviewer has their own idiosyncratic criteria in their own mind, and they rarely practice good communication themselves by telling the job application ahead of time what those idiosyncratic criteria are exactly.
If you're not putting forward an honest effort for writing code that resembles code you'd be comfortable putting into production during an interview, then I'd pass on hiring you too.
And yet so many interviewers say, "We don't care whether the code is perfect, we just want to see how you think."
The insanity for job applicants is that you never know which kind of interviewer you're going to get until it's too late. Every interviewer has their own nitpicks, yet they somehow believe that their specific nitpicks should be assumed to be universal requirements.
And then hiring managers complain that good programmers are difficult to find, lacking the self-awareness to see how many candidates they arbitrarily exclude for dumb reasons. I've seen people say "I'd pass on a candidate for X" for more or less all X.
I would have failed too, however, the reason would be because of my insistence that there is always a better element to use. It even says so in the specification.
When I've witnessed Flexbox and Grid (esp. templates) for the first time I liked Grid more, but as I've seen Flexbox more commonly used in the industry
I built a web framework in 2005 based on table layouts. Years later I switched to Flex (when it was available, and when Grid was still poorly supported.) Some years ago I switched to Grid because it was more generally supported.
So I expect that what you are mostly seeing is the evolution of CSS, from table to flexbox to grid. Table has no real responsiveness (to screen size), Flex does it _really_ well (especially for cases where the target is both PC and Phone etc.) But it has some limitations (mostly for me around column widths and the concept of "relative" column widths.)
Grid is really nice, it's a lot more like tables in concept, but at the same time has responsive abilities. These days I'm grid-first, although there are still a few places (depending on context) where flex is more appropriate.
Of course flex is also more "well known" (because it's older.) I feel a lot more comfortable there still, and until we have sub-grids I'm also a fan of using Grid layout for the "outside" and using Flex inside specific cells.
I love grid because it allow me to position elements anywhere in the grid without needing wrapper elements like with flex/float. That allow nearly full freedom in layouting the same HTML for different complex layouts targeting different screen width.
Though while grid borrowed a lot of ideas from flex, the creative usage of the grid template is so vast that you probably need to also learn by examples.
Depends on the content and amount of content. I would say you can do the same layout with both. The main advantage of grid and named layouts is that you can move them anywhere you want. You are not bound by the order of html elements.
When I learnt css for the first time, floats was the standard
10 years later, kind of, I got back into web dev and css and learnt about flexbox, what an incredible difference. I was so thankful I wouldn't have to deal with floats ever again
I remember my first web dev job was right before flexbox usable in all major browsers - I can't remember which one was last but the day that it was released was glorious because it meant no more float based layouts at that job.
I find the bifurcation between HTML elements and CSS statements maddening. Structural things like flexbox and grid would be far clearer as HTML element types.
HTML is for marking up the semantics of content - lists, headings, emphasis, etc… CSS is for presentation - how is appears in the target medium. The layout is 100% visual presentation and 100% belongs where it is, in CSS.
Dealing with multiple screen/windows/paper sizes, as well as dynamic resizing & scaling is incredibly hard or impossible when you've baked a fixed idea of presentation into your content, see: Latex, PDFs & old school HTML with complex tables for layout, for examples.
Ah so everything kinda inline? But how do you deal with change of layouts then? Like, sometimes I code sites where the inner structure changes a lot and that's trivial when paired with media queries but it would be a pain to handle if everything is inlined or tied to the markup.
I use relative units (ems/rems) for font sizes and absolute units (px etc) for everything else such as margins/paddings/borders. I also set the html font size to 62.5% which makes the math easy (1rem = 10px).
This ensures that if a user adjusts their browsers font size for accessibility purposes or uses dynamic type, only the text will scale. You don’t want margins/paddings to scale with font size (at least not linearly) otherwise the layout gets cramped/unusable very quickly.
As others have mentioned CSS pixels have nothing to do with hardware pixels. So there are no issues with the differences in screen densities between devices.
px in CSS/web is just shorthand for 1/96th of an inch, regardless how many actual pixels that ends up being. This means it's functionally the same as any other absolute value of measurement on the web, since they are all based in some mapping to physical size as well.
If you change system UI zoom setting then the 1 pixel size in the browser change with zoom. At 200% web 1px is actual 2px. I am not sure how it could be "1/96th of an inch" when it can change size depend on the system setting.
1/96th an inch based on what the browser/system report the pixel density to be. There is no man coming out of your computer with a ruler to verify the reported value, so you're free to use a scaling value that isn't true. Zooming the browser or changing the system scaling will change the reported size of the pixels to the renderer.
¯\_(ツ)_/¯, to the browser - it is. It is a good note to point out the browser may not have an accurate sizing of the display and would produce incorrectly sized outputs in those cases, but it doesn't change how px sizing works.
I stick to percent personally. Easier to adjust if I am working on someone else's messed up css. rem/em depends on global values but many sites override these with different classes and manually entered pixel values. I find % to be safer than em/rem.
Any CSS work eventually devolves to adjusting numbers until everything falls in line, adjusting for the 2 pixels of padding there or the borders of some other thing. Maybe nowadays there is calc where you don't need to do that, but it didn't exist back when I did CSS.