As for layout, spend half a day learning about flexbox (https://css-tricks.com/snippets/css/a-guide-to-flexbox/). It's much simpler than CSS grid and it'll do 90% of what you need as far as layouts go. If you have a particular section of your page that needs to be laid out in a grid, then you could try out CSS grid in that limited section. I think it is a nightmare for overall page layout.
Ask HN: Is it just me, or is CSS too damn hard?
291–300 of 358 posts
Re: Ask HN: Is it just me, or is CSS too damn hard?
#292Earlier quoted context omitted.
> I'm fascinated by the fact that so many of my fellow programmers - often the smartest ones - have so much trouble with CSS. I'm not sure exactly what the reason for that is I will demonstrate why. First, think of all the tools that you use that require a text interface. That may include a programming language (python, ruby, javascript, etc), a command line shell (bash, fish), a database client (mysql, psql), a conf…
Some of the names are unintuitive, sure. Though I don't think the ones you provided are in particular; I think your distaste for those is subjective. But it's really not hard to learn the names for concepts which themselves make sense (at the beginning, perhaps, but not for someone willing to put in a modicum of effort). Many of the worst parts of CSS, and even JavaScript for that matter, come from the need for backw…
Relative and absolute... Is there a CSS book or tutorial that doesn't take a jab at these names when explaining positioning?
Re: Ask HN: Is it just me, or is CSS too damn hard?
#293CSS is great, but its poorly taught. I've known so many developers of all skill levels who get stuck somewhere between "I can make it red but I have no idea how to apply all these random properties into the layout I want." They'd ask me for resources, and I couldn't find one I thought was very good at that. So I tried to write one. https://whatisjasongoldstein.github.io/buildcss/ What's nice about this is I wrote it…
Re: Ask HN: Is it just me, or is CSS too damn hard?
#294I have met many very competent developers who have struggled with "getting" CSS. They didn't get the fundamental logic because they lacked an understanding of the problem it was designed to solve. If someone says CSS is "a series of hacks" or "does not make sense" it is probably because they don't understand the premises for its design.
The design goals of CSS:
* A layout can adjust to any screen/viewport/canvas dimension across any platform - including the printed page.
* Text can be scaled independently of the viewport dimensions. Scaling font size up should not force the use to scroll sideways back and forth - the text should reflow to adjust to the new size.
* Anything can be overridden by the user: E.g the user can scale the font size up regardless of what the designer have specified.
* It should be rendered progressively: the layout of a box may depend on previous content, but not on things not loaded yet - although loading new content might force a "reflow" of previous rendered content.
* CSS applies styling and layout properties to elements in the HTML. So you can paint a border around a HTML element, but you cannot paint a box in pure CSS.
Whether or not you agree with these design goals, CSS makes a lot more sense when you understand them.
Developers sometimes compare CSS unfavorable to GUI toolkits like Windows Forms or to fixed-dimension layout formats like PDF. Those are indeed much simpler to use: You place a control or a line of text somewhere on a canvas, and it generally stays where you put it. But neither format gracefully handle scaling of text, non-standard screen sizes or resizing of the canvas. CSS solves a much more difficult problem than either Windows Forms or PDF attemps to.
So CSS is not about placing object with specific dimensions at specific coordinates. That does not work when all the assumptions behind the dimensions and coordinate may change dynamically. Instead CSS layout is typically defined in relative terms - relative to page width or font size or dimensions of the parent element.
After understanding the design constraints, it is a lot easier to understand the algorithm the browser uses to lay out elements. The is a handful of different algorithms depending on the display property of the current element. This property is the most important CSS property.
inline: Elements flows horizontally left to right as space allows. Line breaks happen when the edge of the container is reached, and the flow continues on the next line.
block: Elements flow top down, one after another. The width of the block is what is available in the container, the height is defined by the content.
table: Child elements are aligned both vertically and horizontally.
flex: Child elements are placed on a single axis either vertically or horizontally, which specified alignment, adjustments and spacing.
(there are more, these are just the most important.)
You will often combine these. Document-oriented layouts typically use inline and block flow. A classical GUI with some panels of fixed size and some panels expanding to the available width will probably use flex.
Re: Ask HN: Is it just me, or is CSS too damn hard?
#295Earlier quoted context omitted.
> What's the advantage? The same content reflows to different 2D spaces
Flow-like layout is just a sub-problem of 2D Layouting. Having it as the only way to do layouting (besides tables) has proven a nightmare to work with. That's why you got Flexbox (and now Grid).
Re: Ask HN: Is it just me, or is CSS too damn hard?
#296Earlier quoted context omitted.
Good comment. CSS is actually pretty simple, as long as you start with the smallest elements and work up. It becomes a nightmare if you try and address everything individually. It’s not really a programming language, but a series of guidelines. I’ve seen this simplicity actually throw developers as they’re used to something much more complex and systematic. Preprocessors like SASS are great, but I wonder if they’re d…
Pixel perfect is not possible in HTML/CSS. Stop spreading this. But it is very possible to make websites look very good and inline with what was designed. But good luck making an input, button and select the same height. It's just not going to be pixel perfect. What is pixel perfect in your browser isn't in others. But what designers should now is it doesn't matter as long as it looks good for everyone.
It's... actually incredibly easy to do that. You just disable the browser's default styles for those elements and then set their height explicitly.
There is a certain interpretation of "pixel perfect" which, I agree, isn't really feasible or worth trying to achieve, and that's when it comes to layout. You can hardcode the dimensions of "atomic" elements like buttons and inputs all you want, but if you start giving hard pixel widths to containers that should be adjusting their size according to their content and surroundings, you're going to get yourself into trouble real fast. I think designers these days have mostly started to grasp this, though.
Re: Ask HN: Is it just me, or is CSS too damn hard?
#297You can also extend selectors and at-rules in ways that allow you to define new, custom features, supported by JavaScript, and utilized from valid CSS stylesheets.
Given all this power and flexibility, you can go a long way toward turning CSS into the "styling language of your dreams". When you're extending CSS you also get to pick all the naming you work with as well.
Rather than trying to replace CSS, or abstract CSS away, it turns out the friendliest solution is to start with valid CSS and continue building on top it from there.
Check this out for more information about how to extend valid CSS with JavaScript: https://github.com/tomhodgins/caffeinated-style-sheets
Re: Ask HN: Is it just me, or is CSS too damn hard?
#298Re: Ask HN: Is it just me, or is CSS too damn hard?
#299That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of Tim Berners-Lee, a drunk standards committee, or whoever.
And it would mean we (developers & testers) are dealing with one engine instead of the myriad engines one is facing with a combinatorial explosion of browser brands and versions and OS settings. I've seen web UI "testing labs" with 20 PC's and Macs, and that wasn't enough.
The only people who like the current state of affairs are UI/UX specialists; it keeps their wallets fat. Bicycle science was turned into rocket science, and the rockets often crash and burn.
Re: Ask HN: Is it just me, or is CSS too damn hard?
#300Earlier quoted context omitted.
> Some (unlucky) programmers entire job was turning PSDs into HTML and CSS. That was my entry into programming many years ago. But I wouldn't call it unlucky - early web devs like me (we didn't really call ourselves programmers back then) had front-row seats at the beginning of a revolution, and it certainly was entertaining to watch and be part of. > CSS has nothing to do with design CSS works the way it does becaus…
> CSS works the way it does because it was created to make the kind of designs that designers wanted possible Well, not originally. Later that became a thing, yes - but all the design that was already there at that point (circa CSS 2) remained, as did the overall approach with cascading styles. A styling language designed for HTML5 today from scratch, accommodating modern use cases, would likely look a lot different.
I think the best illustration of this "fight" between CSS as a tool for styling "traditional" hypertekst documents, vs CSS as a tool for styling "web pages" is the fate of Adobe's CSS regions proposal - and Håkon Lie's opinion piece arguing against it:
https://alistapart.com/blog/post/css-regions-considered-harm...
That was when "design" lost. But now with grid and transitions, there's a "new" CSS - one that is oriented around UX for "web apps". But apps evolved from documents, mind - not from windowing toolkits like smalltalk morphs or Java swing etc.
Fwiw I really liked the idea of regions for laying out rich documents - like what you might want for epub.
I must admit I'm not that concerned about "web apps" - everyone seems to end up doing their o we n abstraction anyway, and the CSS that "falls out" isn't really sane anyway.