I find it fascinating (saddening, but fascinating) that so many programmers are so turned-off by CSS and find it so unintuitive. I almost want to set out on a research project to figure out why that is. My experience with it couldn't be more different.
Here's one way of looking at CSS (which I didn't think of until just now): CSS is not a language you build something up out of. It's more like you're carefully taming a wild horse, or pruning a plant. You have to embrace the natural movement of the thing, and strategically redirect it only where necessary. If you come in with the mindset of constructing the world from scratch (which works in most programming languages), you're just going to be fighting the beast the whole way, and you're going to lose.
This isn't fully formed in my mind yet so go easy:
Intuition is linked to elegance, an elegantly designed language is intuitive. An elegant language is one that starts with a few core principles and from that derives the rest of the language. Lisp is an example of a programming language that does this beautifully well.
Usually (always?) such core principles themselves are taken from mathematics. After all, maths is heavily engaged in the business of elegance.
CSS doesn't feel like it's built in this way. When you read a tutorial it doesn't begin with: "these are the fundamental concepts of CSS", rather it feels more like a hodgepodge of lots of different ideas and when they intersect you end up with confusion.
Part of that is for sure the nature of the evolution of CSS. But I don't see any "core" of CSS that you could extract that would be elegant and intuitive now.
I think programmers develop this strong instinct for when things "make sense" in that they're intuitive and elegant. It's like taste. CSS leaves a bad taste.
The best comparison I have for how it could be are the UI layouts of Java, Android, iOS. Java and Android aren't great tbh (don't have much experience with iOS) but at least you can see the design behind them.
It feels like something should begin "there are these elements. each have a bounding box. to see how bounding boxes are calculating for text etc you can deep dive into docs. Anyway, these bounding boxes may also be enlarged (through padding etc.). Now, each box has three properties that define its interaction with other elements..." like a maths class and not "if X is inside Y then you can set Y to make X appear on the left if X has its margin set to Z" uggggg.
This is more a failure of the tutorials than of CSS itself though. CSS has a pretty simple and elegant core. You just have to understand the problems it was designed to solve.
- Readable documents at any screen dimensions or resolution (i.e. you should not need to scroll horizontally back and forth to read each line just because you have a smaller screen.)
- Incremental rendering - the document could be rendered as the data arrives over the network.
- The user should be able to increase the text size.
The "normal flow" layout model is designed in such a way that these constraints are fulfilled by default. You can make a layout which only works on a screen of a particular size, or where the user have to scroll horizontally for every line, but you have to do it deliberately.
I'd say the fundamentals of CSS is to understand the "normal flow" and the box model.
I'm not convinced. Literally none of these 3 bullet points are problems with plain HTML since at least 1993 or so - it's responsive by default, incremental by default and user agents are free to zoom in or out at will by default.
Exactly! The default CSS browser stylesheet is a reverse engineering of how Netscape 2.0 rendered HTML. It had to be, since otherwise CSS wouldn't be backwards compatible, which would have killed it. But it was also a good starting point because browsers had to solve this exact problem: Layout text so it it readable regardless of screen dimensions.
Except that HTML rending was never specified (and varied significantly between browsers), so CSS basically codified the defacto HTML rendering in mainstream browsers, and then described this as the "browser style sheet".
CSS then allowed the author to override anything they wanted to change. But the default for anything not overriden was the browser style sheet, which was a sane default which adapted to all screen sizes.
But HTML doesn't say anything about how things need to be rendered / presented. It was never intended to do that.
All it does is mark the structure in a document. "This is a header", "this is a paragraph", "this is a quote". That's basically it. The "hypertext" part of HTML refers to the notion that it uses URI's that can be used to identify resources, and dereference them.
It's entirely up to the consumer of a HTML document to decide how it gets rendered. A browser engine comes with a layout component that determines how the constituent parts of a document need to be painted before they are actually painted on the canvas.
Browsers in a GUI come with a default CSS definition that will be used if the document doesn't reference a companion CSS stylesheet.
Moreover, a browser doesn't have to be a GUI browser. What about text browsers on the command line?
I'll give you an example:
This is the hard coded default style definition of the Lynx browser when running through curses:
CSS was exactly designed to solve those 3 problems and much more.
The separation of structure and presentation is by design. Why? Because HTML and CSS never were intended to be used as tools for building "Rich Web Applications". They were originally intended to render hypertext and static web pages.
As it happened, the world wanted rich, interactive, animated web applications. And it needed technology to build such complex applications. Web technologies have evolved over 30 years to get to that point. Remember Flash? Java applets? Silverlight? Those were all attempts to do what HTML and CSS didn't do. Until the big vendors who came to dominate the browser market expanded on what HTML, CSS offers, and build new API's into their browsers that allow for exactly that.
There's nothing wrong with wanting to build rich web applications, and trying to leverage these affordances. But if you get hit by the limits of what web technologies have to offer in terms of maintainability, performance and what not, that's because you're still building on top of a historical foundation of basic principles that was never intended to be used in ways that it is used today, 30 years into the future.
HTML absolutely used to “say how things needed to be rendered”: with tags like B, I, FONT and so on. It was developed when documents were expected to be WYSIWYG-style markup (Word/WordPerfect, Latex, etc).
CSS was designed to strip that away only after people decided the future of hypertext should look more like XML. In doing so, they added the constraint that you should be able to get completely different outputs depending on which media you use to access the content - which at the time largely meant printing vs browsing.
But I agree that the whole thing was fundamentally document-based and has been bent out of shape in the subsequent decades. Once the content/presentation separation was abandoned, all bets were off. Now we are in a situation where content is driven by CSS properties via JS manipulation. We have the worst of both worlds. Ironically, this was enabled by something called XMLHttpRequest...
Actually, the original HTML was not designed to have the end user agent determine how a page looks, and was designed to specify presentation. <FONT> was not part of the original HTML specification. <TABLE> was never meant to lay out a page.
The WYSIWYG-like tags were added in the late 1990s during the dot-com era because companies wanted to be able to make web pages “glossy brochures” and were doing things like making web pages huge imagemaps until Netscape added HTML tags specifying presentation.
> HTML absolutely used to “say how things needed to be rendered”: with tags like B, I, FONT and so on. It was developed when documents were expected to be WYSIWYG-style markup (Word/WordPerfect, Latex, etc).
Yes, those tags do exist. However, their story is more complex, and intertwined with the rocky road towards standardization. And their importance gets easily overstated, even though they were a boon for budding website builders dabbling with HTML in the late 1990's. [0]
These didn't exist in the original HTML document as drafted by TBL. They were tacked on in what we know as HTML 2, which wasn't an W3 recommendation but an IETF RFC. [1] They were kept in HTML 3.2 which is the first formal W3 recommendation recognized as a standard in january 1997. [2]
HTML 4.01 deprecated FONT, CENTER, U and STRIKE in december 1999, barely 2 years later. [3] At the same time, HTML 4.01 introduced and promotes the use of stylesheets for presentational purposes to overcome the limitations of HTML. [4]
> Style sheets represent a major breakthrough for Web page designers, expanding their ability to improve the appearance of their pages. In the scientific environments in which the Web was conceived, people are more concerned with the content of their documents than the presentation. As people from wider walks of life discovered the Web, the limitations of HTML became a source of continuing frustration and authors were forced to sidestep HTML's stylistic limitations.
> ... Style sheets solve these problems at the same time they supersede the limited range of presentation mechanisms in HTML.
Moreover, the use of the elements that weren't deprecated - I, B, BIG,... - was discouraged by the HTML 4.01 specification itself in favour of stylesheets. That's since December 1999. [5]
> The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets.
Also, I would have to disagree with this:
> CSS was designed to strip that away only after people decided the future of hypertext should look more like XML.
The development on XML happened at the same time as HTML and CSS. XML was first published in February of 1998, well after HTML 3.2 and before HTML 4.01.
However, XHTML 1.0 was based of HTML 4.01 and was basically a transposition of HTML 4.01 using XML. XHTML 1.0 only became a W3 recommendation in January 2000, well after HTML 4.01 and XML were first published. [6]
Moreover, CSS 1 was first published in 1996, CSS 2 in May 1998. The first draft of XHTML only was published in December of 1998, well after CSS was established. [7]
My point is that all of these technologies were developed by committee. In separate Working Groups, which didn't necessarily align their efforts. That's basically why the road towards convergence was - and to a degree still is - this rocky.
And all of that is discounting the browser wars with vendors such as Microsoft applying their own interpretation of the specifications in their engine.
The CSS 2 spec was actually a good introduction to the fundamentals, but it is 20 years out of data now, and the new modular specs does not works well as a tutorial.
>This is more a failure of the tutorials than of CSS itself though.
But therein lies the rub. Where do you go for authoritative information on CSS that doesn't involve digging through winding, terse technical specifications? That may be fine for developers making web browsers but becoming an 'expert' in CSS shouldn't be a requirement just to make a web page. Hell, even the experts struggle with it otherwise all web browsers would have consistent CSS rendering. A good example is centering an element in CSS. What's the right way to do it? There's a multitude of techniques with varying advantages and trade-offs. I first cut my teeth in web development in 2001 and we still don't have a simple, straight forward, codified way to accomplish this seemingly simple task. Instead we have an ever changing standard coupled with a dizzying amount of opinions on the matter and inconsistent browser support on mobile devices. We can't really blame the failure of tutorials when there's no clear authoritative reference point to work from.
What happened was this: Once upon a time, there was only HTML. It could only make simple text pages.
Then the internet revolution of the 1990s happened, and everyone wanted to put make their webpage look like a glossy pamphlet. So along came extra HTML tags, and the widespread abuse of <TABLE> and other tags added to HTML to make web pages look like glossy pamphlets.
At the same time, CSS was developed so the HTML could stay clean and maintainble, and the layout of the “glossy pamphlet” look was in a separate file. HTML + CSS wasn’t designed to make an interactive app. It was designed to make a magazine article or an online resume. One would use Java (1990s) or Flash (first 2000s decade) for anything interactive.
It was in the 2010s, long after Java applets stopped being widely supported, and when Flash was too proprietary and too insecure, that the ability to make a fully interactive app was tacked on to Javascript; this was not the original intent of Javascript nor of CSS.
So, there is no real underlying design. It was something hacked on to a standard designed to share text documents.
If Steve Jobs were alive today, I think Apple or someone else would create a new interactive standard without all of the baggage of HTML + CSS + Javascript. It’s like the problem we have had for years, where a modern x86_64 chip is a 64-bit extension of a 32-bit extension of an originally 16-bit chip; it’s only now with the M1 that we are finally using a more elegant and well-designed chip architecture for desktop computers.
I hear you and think you make great points. Thankfully, there IS a resource and approach to using CSS properly, embracing the nature of the browser environment and building up from profoundly well-researched and -articulated first principles. The approach is called "Axiomatic CSS", and the website is https://every-layout.dev.
Disclaimers:
1. No affiliation, just a grateful follower.
2. The site includes a mix of free and paid content. The free content includes the axioms you're seeking, and compelling examples of their use. The paid content includes a book and access to the full suite of composable layout primitives, and a component generator. Best $100 business expense of my 22+ year career in web development.
I'm not a fan of CSS. I learned it well enough to build a decent UI toolkit (draggable modals, collapsible, etc.)
I hate how CSS tries to mix layout and style. A million articles about not using tables for layout, and it took 20+ years to get a grid. I tried to do some fancy text and element alignment with CSS, and it was not having it (and, yes, I know about display: table). In the end I reverted to a table. It worked, and I moved on with life.
It is ridiculously hard to draw things in absolute positions. In many cases, it is easier to do a tiny bit of math and compute the positions of objects, rather than have to define parent/child relationships. But for true absolute positioning, you have to throw divs into a "portal" of some sort, and move that object into the root element. This makes doing things like pretty drag and drop extremely painful.
Browsers are buggy as hell, and often something works on everything but [insert your most hated browser]. That's a hint that the spec is too complicated.
I agree with your assessment, in that if you try to construct the world from scratch, you'll be "fighting the beast the whole way." I disagree that this is positive quality of the thing.
>A million articles about not using tables for layout, and it took 20+ years to get a grid<
To be fair, CSS 2.0 (from 1998) has “display: table” which allows table layout in pure CSS. [1] The problem was not CSS. The problem was Internet Explorer 6; “display: table” was not viable to use until the early 2010s when IE6 usage finally plunged.
[1] Edit: CSS was designed for styled documents, such as online resumes or blogs. It was not designed to make interactive apps, which is why it doesn’t fit that paradigm well. Everyone thought Java applets would run the interactive web, and we would be making web applications in Java today if Microsoft had not killed Java on the web in the late 1990s with IE.
In my experience, "display: table" is not really identical to the behavior of <table>. I gave up on it for my project, though unfortunately I don't remember the specifics.
I think it's just a fundamental issue where CSS is trying to be both layout and style. Works great for basic document formatting, but once you try to do something complex, it all falls apart. Or, rather, it should fall apart, but we've spent the last couple decades duct taping it together.
Every JavaScript framework ultimately hits a wall where it has to interact with CSS. It can't be abstracted away.
I really do believe more money and effort should be spent looking for an alternative.
The biggest thing missing in “display: table” is “colspan”, allowing a table cell to take up multiple columns of the table. That can be a big deal with some layouts. One workaround is to use “position: absolute” inside a CSS table cell to have an element which can span more than one table column.
The real reason we don’t use tables for layout (and only for the occasional tabular data) is because a table layout doesn’t work really well on the screen of an iPhone or Android phone, especially when they are vertically aligned. So, the workaround is to use media selectors: Desktops, laptops, and tablets get a table layout; phones get a simpler one-column layout.
I believe grid and flex layouts allow one to use a single design which will appropriately scale from a phone screen to an ultrawide monitor, but I use a two-layout or three-layout design for my web pages.
[1] In the days when the CSS Zen Garden was new, all of the web design blogs and comments felt using <table> for anything at all was heresy, since abusing <table> resulted in really ugly and hard to maintain webpages during the dot-com days of the late 1990s. It would be an extended discussion whether it was OK to even use <table> for clearly tabular data.
I think the don't-use-tables argument is from way before mobile devices were something web developers cared about. I recall it as being mostly about semantics, i.e. tables should only be used for tabular data, not setting up the layout of your entire page.
Those kinds of discussions have dropped off of the Internet over the last decade and a half, being hosted at places like the now defunct original Digg website. It was an era when one could said something really stupid online and it would become mercifully forgotten.
What I have found is a 2014 blog posting where another web designer from that era says “the early anti-HTML table movement was strong. It managed to brainwash many generation of developers into thinking that any usage of table is evil.
[...] I am one of those developers who avoided table layout, even for displaying tabular data.”
These days you actually can use <table> without compromising accessibility, by adding aria-annotations. So if you prefer this to CSS, go ahead.
Most of the angst around <table> was before aria support, so using <table> purely for layout impacted accessibility, which meant it was not viable for most real-world scenarios.
That said, if you need stuff like colspans for a layout, you are probably better of using grid.
td supported vertical-align:middle since css1. But you're not suppose to use tables because... hmm. The user sees no difference. Google doesn't care. The browser has no problem with it. It's easier to code. Oh, but it's bad practice... how? I feel like we just listed what qualifies as good practice.
What is it called when following rules only leads to breaking rules? Hint: Sometimes it even leads to javascript.
That is not why you're not supposed to use tables for layout. It is for accessibility reasons. This is routinely ignored because approximately 0% of rich web apps are accessibility-friendly and people with screen readers have pretty much just learned to make do.
This is such an oversimplification. Since when did a table contribute to the richness of an application? Most modern sites are built with divs and remain inaccessible.
Tables simplify the code for simple content placement. That's it. It's only one of a long list of requirements to satisfy all sorts of requirements including screen reader compatibility. And if one were to use tables, it's only one of a long list of hacks and non-hacks that would break screen readers.
The root of the problem is with web designers not prioritizing accessibility-friendliness in their sites to begin with, for the basic reason that it prevents them from building the site that they need to build. And "what breaks or doesn't break accessibility" is not part of the spec description and is not enforced technically. We get recommendations, but it's up to us to test everything against everything else and compromise. Not just with accessibility but with everything else as well including backwards compatibility.
If you're a developer and someone decides to have a layout for the emails sent to customers, you probably still have to use tables.
I find that designers who create their own CSS are pretty rare. Most times I've seen frontend developers slice up designs. I think you need to have a workflow to do this properly. I needed someone to show me how to do it and I often preferred to just use an open source CSS lib like Bootstrap.
The problem is that most CSS properties are contextual. They'll work one way in a certain hierarchy, and a different way in another. I've had issues where items would suddenly appear in REVERSED order if I changed the width of the container object (which would be fine if there were a CSS property "component-alignment: reversed", but there isn't). There are no enforced types. You can assign any value to any property name, even though invalid names will do nothing (and so typos cause hours of lost time). Some properties won't do anything unless they're done in conjunction with other properties, but you have no way of knowing that because there's no debug feedback mechanism. Even worse: some properties do nothing unless the SURROUNDING object has certain properties set to certain values. That's INSANE.
There's very little logic, but much lore and arcane incantations to CSS, which is what makes it a bad system (much like the crotchety systems in the bad old UNIX engineer days of "if it was hard to write, it should be hard to understand").
I've worked with a number of UI systems, and the best ones are ALWAYS component based, where component properties ALWAYS behave the same way internally, and where you can COMBINE them into more powerful components. This is not what happens with CSS. Basic things like alignment, size, borders, padding, margins all behave in weird ways depending on the context, or the presence or absence of text, or rely on similar sounding but subtly different properties that only work in certain contexts and not others, with no debug information to tell you why it's not affecting anything. That's not cool. If someone were to invent a programming language that behaved this way today, they'd be laughed out of the room.
CSS has a fundamentally different cognitive kalkül. You can do things fast, but if you do not have a deeper understanding, it can get pretty frustrating. At least historically.
It is like asking a Python programmer to write Prolog. Anyone can write Prolog, but only if you are willing to learn. The difference is: Prolog is an optional choice for most, CSS is a must for certain applications..
Okay, to balance out the analogies let's say regular programming is like building a skyscraper brick by brick ;)
The idea is that to some people, having total control and building something up piece by piece comes totally naturally, while understanding and then selectively guiding a thing that has a will of its own does not, even if in some since it's more "elegant"
Having worked with a variety of GUI frameworks on small projects for work (WPF, Windows Forms, Xamrin, Android, iOS), I think HTML and CSS are the best out there for easy of use. It definitely helps that it has so much history and documentation behind it, but if I could build my GUIs in standard HTML and CSS without being forced into Electron or something else and still have my choice for a backend language, I'd find building GUIs way more fun.
I have a feeling people like to hate on CSS because making GUIs is hard and tedious work in general and introducing bugs is way easier than fixing them.
And since many applications nowadays run in your browser, people end up having to use CSS, thus getting blamed for the general pain it is to make a good GUI. I have used native GUI kits like Tk and Qt and found myself fiddling just about as much as I would with CSS.
YMMV but, almost every single GUI framework outside the web has:
- virtual lists
- customizable controls (including selects)
- easy solutions for layouts of any complexity (CSS got flexbox in 2015, Qt had it in early 2000s)
- a plethora of complex components out of the box (and most complex controls are rather trivial to implement yourself): date pickers, modals and dialog boxes, tree views, splitters, you name it.
Yes, building GUIs is hard. But building GUIs on the web is approaching impossible. There's a reason why most GUI frameworks on the web only manage to implement the same paltry set of components: buttons, badges, inputs. Very rarely there's a date picker and a table. And... that's about it.
Agreed. CSS is a more of an artistic design task than a programming one. You have to have the mindset of a sculptor, meticulously chipping away, fiddling with tiny bits as the figure gradually takes shape.
Now that I think about it, I feel like this is what CSS Zen Garden was all about. You have to embrace the fact that you’re gonna sit there tweaking margins and experimenting with various incantations.
hey, author here. I always find it weird to see HN posts where you have to pay to read what it says (what's the point?) so here are 6 sample pages from the zine if you're interested in seeing more of what's in it:
PS Separately, if you ever felt like it, it would be lovely to have a poster (or similar short thing in your style) about CSS Selectors specifically, to give to our customers. (To use our stuff, it's good to know about selectors but don't need to know about styling/positioning and such.)
I have a love-hate relationship with CSS. It's now been 18 years since I learned it and I still regularly get bitten by
- browser incompatibilities (Last bug I fought: top/left/right/bottom behave differently in Chrome vs. Firefox when `position: sticky`. Fantastic.)
- messy refactorings: Sure, CSS3 variables are nice but you can still tell that they were bolted onto the language. Moreover, elements and their rules can interact in lots of ways and CSS code (especially code by other people haha) often doesn't make these interactions immediately clear. Besides, everything is global state and IDs and classes are the only way modularize CSS code.
- the fact that it's impossible to use HTML only for semantics and do all the layouting in CSS. (Wrapper divs, I'm looking at you!)
- missing type separation and missing type checks. All CSS properties live in the same namespace and may or may not interact with one another. For instance, top/left/bottom/right, margin etc. behave completely differently depending on what you set `position` and `display` to.
Things are getting better with web components now but I'm still not sure I'll ever be entirely happy with CSS.
I’d like to fix that, and learn CSS well. I’m not looking for a quick zine like this, more of an in-depth course, say roughly 5-10 hrs. Ideally free, but I’d pay if it’s good. Anyone have any favourites?
I know you asked for a course, but I cannot recommend MDN's Learn CSS section enough [0]. It's long, but it was the only resource that got me over my CSS imposter syndrome. They go over so many great principles and have wonderful examples. I'm a huge advocate of tutorial videos, so I was surprised at how helpful I found their documentation.
I'm actually working on this, releasing it in about a week or so (doing the final edits).
It's called "How To Debug CSS"[1], if you go through my post history, you'll get a good idea of the backstory behind it.
Essentially, what I'm trying to do is help developers like you (who are like me, or at least how I was), in that I knew CSS for a long time, but never really felt like I 'got it', in the same way that I 'got' many of the other aspects of web development.
I've now gotten to a point where this is almost the complete opposite. I now feel like I have gained a certain level of mastery over CSS. And most of it had to do with a simple change of perspective.
Here's an article I wrote as sort of a subset of the book, that covers a lot more about how you can truly start to get better at CSS, as a developer: https://planflow.dev/blog/how-to-get-better-at-css.
Do you know anything about design? Learn some of that first. In the same way that programming makes loads more sense if you can do a little algebra and set theory, CSS makes more sense if you have some idea about how "the eye" moves across a visual space, what colour does and how typography developed (and thus defines the words designers use for type).
I do not recommend this (despite of how cool it looks). It is using algorithmic aspects of CSS which is not what it was designed for. These aspects were added later on in CSS3+.
Learn the basics of CSS first. Even after then, it is hard to recommend this Every-Layout approach.
Learning CSS well is a great goal to have. This zine will probably bring you faster to 80% or 90% of that goal than any other content, because it shows the most important aspects about CSS.
I guess the trickiest thing still is some layout stuff that isn't covered by ^ and usually when I'm dealing with that kind of stuff I use https://learnlayout.com/ as a reference
CSS sucks and I don't think I'll ever be convinced otherwise.. it's just a mess of tricks you have to remember. The people that do spend time memorizing the tricks turn around and say "hey! look! it's awesome" but that doesn't convince me.
Modern CSS (e.g. flexbox and grid) is much less painful for layout, although the number and naming of properties makes it unpleasantly complex. Additionally, I'm still baffled why CSS gained transitions and animations as features. Now it's a jumbled mix of layout, styling, transitions and animation.
Despite the recent improvements to CSS, I agree that it is quite horrible to work with.
I’m just glad we’re no longer in the IE6 days where getting something as simple as a stable three-column pure CSS layout was a nay-to-impossible challenge.
IE9 was probably the first version of IE with decent CSS (read ”display: table” which wasn’t broken); all of the other browsers (which didn’t have IE9’s market share at the time) had already added “display: table” support.
Before “display: table” was widely supported, people would either mix CSS with a <table> layout, or have a fixed width (usually) single column design.
Anyone who learned CSS in the first 2000s decade was living in a world where designing a webpage was 5% getting the design down and working in Firefox, and 95% getting something to kinda sorta work in IE6. Just be glad we’re not trying to use “float” to make multi-column layouts anymore.
The trick was to know beforehand what would work and what wouldn't. That way you only had to spend a couple of hours in the end fixing small things that were broken in IE. A couple of well-placed "zoom: 1" could fix a lot.
CSS is an utter timesink. If I could only recover the time I've wasted fiddling with CSS layouts over the years. If Dart for web makes it we'll finally have an alternative. Thankfully there's now SwiftUI and Jetpack Compose for mobile.
I think someone learning CSS today with an eye to targeting modern browsers with have an easier time. They won't have to learn those old hacks like floating elements, correcting box-sizng across browsers, centering elements etc.
CSS has endless ways of writing and representing the same thing which actually makes things harder, not easier in my opinion.
So many years into CSS and it's still damn near impossible to (a) vertically center multi-line text in a div (b) set the width of a div or video in units other than pixels and let the height be set based on an aspect ratio. Both result in nested div hell.
Even I'll admit that Grid is complicated. It serves a valid use-case, but it's honestly a very rare one in my experience and the learning curve is steep
Grid is nice but overused in my opinion. However, at the end of the day whatever gets the job done and is sane is a valid solution in my eyes but I prefer to think of grid as anything requiring centering on two-axis and/or macroscopic to the task at hand.
So for instance I would do the responsive page layout in grid, probably. Then I would do positioning the elements within a article or section with flexbox.
I paid $60 to a guy on Fiverr to do css for me just a few days ago. I should have been able to do it myself but after fooling with it for awhile I gave up.
I'm sure someone will come and say they disagree, but I find CSS extremely unintuitive as well. The primitives it has compose very poorly. There are too many ways to do the same thing, each with their own weird quirks. Sometimes it's really hard to get it to render something simple. I mean... Just centering something on the screen is needlessly complicated. I wish CSS was more like a programming language, with a minimal set of primitives that are nicely composable, instead of 1000 bells and whistles that go in every direction.
Well, CSS is pretty old, and as such old, backwards-compatible specs do, it's utterly bloated. I tend to use CSS Grid and Flex almost exclusively, since they are a lot more intuitive than the block and inline combo.
But then again if you look at the origin of CSS, it all makes sense. CSS was never developed to be used for app-like interfaces. At it's inception, it was intended as a style sheet for documents (specifically scientific documents). The original idea was that everybody would have their own CSS which they could then apply to HTML locally. Interestingly, 30 years later, HTML and CSS are used for almost anything but scientific documents and nobody uses a personal style sheet.
The technology is really not well suited for the cases it is most often used for today and there is a superb blog post on the topic that has featured several times on HN:
Nice blog about the early styling proposals which predate my webdev experience.
For the newbies, back in the CSS 1 days, the intention was to create separate styling rules to make maintaining or changing styles easier. If you ever had to style HTML before CSS by wrapping each and every any colour or font change in HTML elements or embedding background colour attributes inside each table cell, you'll understand the pain it was addressing. The CSS 1 spec was relatively small and easy to understand - although pretty limited.
I first seriously tried to make that work in the IE4 days. IE4 was almost kinda OK at CSS1, but NN4.x was just awful. Opera was (not surprisingly) the best at CSS, but nobody used it.
The complex layout stuff came not log after in the much bigger CSS 2, but the nature of IE only badly implementing a fraction of it for a decade or more meant that most people just cargo culted IE work arounds and never really sat down to learn any of the principles. Not claiming they were great principles, just that there were some :)
Indeed there are two (at least) more ways to both horizontally and vertically center something (using CSS Grid and the good old translate(-50%, -50%)) and with flex I always have a hard time remembering if it is justify-items or justify-content..
I’m chuckling because (a) parent is right that it’s easier than before, and (b) grandparent is right that it’s still infuriatingly obscure to anyone not fluent in CSS.
There are ways to vertically center content, but since that wasn’t something CSS was designed to do (for the kinds of things where something vertically centered makes sense, we were supposed to be making web apps in Java), they are all clunky.
Programming, I'm guessing. Page layout was its own weird world even before HTML came along, and the explosion of devices and use cases has made the domain much weirder. Put 25 years of CSS evolution on top of that and it's very much its own beast. As somebody who's done mostly back-end work lately, whenever I approach CSS it's one WTF after another.
I keep hearing that it has settled down, though, so I am looking forward to learning it properly next I need to do something interface-y.
My biggest tip of advice for anyone dipping into CSS is to focus on _why_ CSS is behaving the way it is instead of memorizing the different properties and selectors. Some principles in CSS won't ever go away, and they will even explain how the newer features that "settled down" CSS work and make then even easier to use.
While I haven’t read this one just yet, I’ve found all of the author’s previous zines incredibly useful. They’re densely packed with information, presented in a way that makes them great quick reference material. My only wish is that someone could print and bind them into a book.
For folks who bought this or consider buying it, help me please understand why?
I know I am not the target audience since I know CSS enough but I think that this is just a very short reference to some aspects of CSS that can't help you much?
I bought it. I'm not very good with CSS, as I haven't spent much time trying to learn it, and like the author, spent lots of time trying to puzzle over snippets I've been able to Google search. So, it's a nice ground level for me. I think it helped me understand CSS a little bit better.
I also quite enjoy her other writings, so it was also purchased to support her as well!
For the bottom two columns on the page, shouldn't the second column break below the first column in a mobile/responsive view? I normally don't get picky about css stuff except for when it is in css tutorials lol.
I think you’re saying that you think the “I want this!” and “Commonly asked questions” should appear after the “Table of contents” and “take a peek inside” on small screens, because on larger screens they appear to the right of it (rather than to the left).
Why? Having it this way round is definitely less common than the other, but by no means is it rare, and there’s nothing at all wrong with it.
Wow! A perfect example of thinking outside the box and a fresh new perspective on technical documentation. This is just one reason why we need more talented women in tech.
Some of these are self-inflicted wounds, though. For instance, why do you have to declare inline boxes to be inline-block before you can add padding to them? Perhaps just because of backwards compatibility, which could perhaps have been solved a bit more elegant.
You’re right; inline-block is a later addition. It doesn’t change the mental model, though.
For example, it makes perfect sense for an empty inline-block to get aligned to the text baseline, while an inline-block with text also gets aligned to the text baseline. That is precisely what ”vertical-align: baseline” means: align this element’s line of text to the surrounding baseline. If the element doesn’t contain a text node, the inline-block does align correctly, but by default does not have a size unless explicitly specified.
And if there’s something in CSS that is to be avoided unless necessary, it’s specifying things explicitly.
Your elementary school teacher would give you dirty looks if you said it, but your teenaged and adult friends would give you high fives and "hell yeahs" right back.
Here in Australia, hell / damn aren't considered bad words. I think americans have a perception that australians swear a lot. We do - but also, a lot of what my american coworkers considered swearing doesn't register as swearing in my head.
Here in australia (at least how I was raised), "hell" is just a word.
America is culturally all over the map (and literally too I suppose?), maybe more so than Australia. While the child-in-school thing might be universal across each state, there are many places were the word hell isn’t profane.
Hell, sometimes it would be weird and just plain confusing not to say the word!
When people complain about CSS they seem to forget that HTML and CSS started as basically an Word-alternative, or actually more like an RTF-format for the web. Doing anything other than that is simply misuse, and all features we slap on to CSS3 and HTML5 does not change this. That's the reason you can not center a div without "hacks".
It's like those creative kids building super Mario-clones in Excel, It's certainly possible but it's still madness. But I guess those kids don't complain about Excel being a lousy game engine...
I agree with the general gist of what you’re saying: The web was originally designed to share text documents with some light formatting.
As it turns out, HTML wasn’t even originally a Word alternative. The original web, as envisioned by Tim Berners-Lee used something called “semantic” markup. For example, a HTML page would have <STRONG>, and it was up to the browser and end user whether <STRONG> was bold, italic, or in another color.
It was only in the late 1990s, during the Netscape-IE wars, that CSS was tacked on to HTML; that’s why CSS syntax looks nothing like HTML syntax. CSS changed the web from a world where <STRONG> could look any of a number of different ways in to a world where <STRONG> would be, say, Lora Serif 600 weight italic at 24point.
Javascript dynamically altering webpages to make applications was never the plan. It only ended up that way because Java applets on the web were effectively killed by Microsoft when Internet Explorer won the IE-Netscape wars, and no other plugin was widely available to fill the gap Java left. Flash was too proprietary and closed-source to take over the web, but it was huge for a while until Javascript finally caught up in the post-IE web of the 2010s.
I find it fascinating (saddening, but fascinating) that so many programmers are so turned-off by CSS and find it so unintuitive. I almost want to set out on a research project to figure out why that is. My experience with it couldn't be more different.
Here's one way of looking at CSS (which I didn't think of until just now): CSS is not a language you build something up out of. It's more like you're carefully taming a wild horse, or pruning a plant. You have to embrace the natural movement of the thing, and strategically redirect it only where necessary. If you come in with the mindset of constructing the world from scratch (which works in most programming languages), you're just going to be fighting the beast the whole way, and you're going to lose.