6 ms·

1) CSS is for implementing designs; being able to use it doesn't require design sense for things like colors 2) I'm fascinated by the fact that so many of my f

by _bxg1 8y ago

1) CSS is for implementing designs; being able to use it doesn't require design sense for things like colors 2) 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, though I did write an article hoping to address it in some capacity: https://css-tricks.com/css-is-awesome/ https://css-tricks.com/css-is-awesome/ I think part of the problem is that many programmers, who like things to be orderly, see CSS as arbitrary and chaotic. Here's the biggest point that I think has to click: CSS isn't a programming language, it's a constraint language. The browser has lots of default, complex behaviors that drive layout, and whereas in a traditional programming language you tend to "build up" from nothing, CSS is more about paring down and guiding that automatic engine with as few statements as necessary. You tell the browser exactly what your layout requires, and the browser figures out how to flesh that out into various contexts and situations. Personally I think CSS is beautiful: it's stateless and declarative, and it allows you to talk about huge swaths of entities in very general terms, gently paring down their avenues of expansion until the possibility space aligns with what your application requires. It's incredibly elegant once you get the hang of it; I sometimes find myself wishing I could use a similar paradigm for talking about objects in other contexts.

Animats 8y ago
CSS is not a real constraint language. If it really were a constraint language, it would be better. There's no constraint solver. Just a bunch of rules applied sequentially. I'd like to have a real constraint system, like the one in Autodesk Inventor sketch mode. You select two things and apply a constraint - parallel, tangent, horizontal, collinear, etc - and the constraint system enforces those constraints. The layout GUI tells you if you've created a conflict. CSS solves an easier problem, and not very well. It's such a mess that no one can attach a decent GUI to it. Amusingly, tables came back. But they're called "layout tables" now, to avoid embarrassment. Trying to do 2D layout with 1D constructs (the "float" and "clear" era) was just silly.
- _bxg1 8y ago
  > Amusingly, tables came back. But they're called "layout tables" now, to avoid embarrassment. I'm not really sure what you're talking about. Tables were bad because they were too rigid and weren't designed for layout purposes; they do still get used when you want to display an actual table. Maybe you meant CSS Grid? > Trying to do 2D layout with 1D constructs (the "float" and "clear" era) was just silly. The float era was certainly a dark time, and I'm glad I came into the field on the tail end of it. It was a hold-over from CSS' document-focused origins. Today we have flex-box, which quite elegantly serves 90% of people's layout needs, and CSS Grid which fills in the rest. For the record, flex-box is a 1D construct for doing 2D layouts, and it does the job fantastically. Your Autodesk comparison belies a fundamental misunderstanding about the nature of the DOM - it is, to its great advantage, a 1D space which flows into a 2D shape. In fact, this was the great flaw with using tables for layout in the first place. By making the content fundamentally 2D, all it could do to respond to different screen sizes and different browser window resizes is stretch. But you don't actually want your layout to be totally percentage-based. You want your content to wrap and flow to make the best use of the available space that it can, with no assumptions about screen size or ratio. The web is 1D because text is 1D. As text flows in lines, within containers which may be different shapes and sizes, so does the entire document model. This is profoundly powerful. Modern CSS gives you the tools to make select aspects of your layout work differently - yes, even in 2D ways - but they're best used to shape and guide that fundamental flow instead of replacing it.
  - rmetzler 8y ago
    > Tables were bad because they were too rigid and weren't designed for layout purposes; they do still get used when you want to display an actual table. And when you have to implement a email design someone gave you who think it’s more important to have it look a certain way then to implement it reliable.
    - mattkevan 8y ago
      That’s because the rendering engines in email software are crap, not due to a deficiency in CSS - I think Outlook still uses Word’s HTML renderer and even Gmail doesn’t support everything.
mnutt 8y ago
Beyond the immediate issues of "what rules do I use to make this thing look this way", the cascade can also make large-scale management and code reuse challenging. It's sort of like object-oriented inheritance, except the definitions and instantiations live in totally different places, and the top-level object properties are defined by browser manufacturers, or possibly end-users. Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not to know whether changing it will break something somewhere else. People have developed some techniques to mitigate these issues, but many are unintuitive and don't follow naturally from "make this thing look this way".
- _bxg1 8y ago
  > It's sort of like object-oriented inheritance With the key difference being that there's no rigid structure to it at all, much less a strict-subset hierarchy. It's really more like structural object types, which can be easily composed, than OOP classes. It's set theory, rather than taxonomy. > Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not This can be easily solved with good project organization. At my day job I maintain a codebase with a couple hundred SCSS files, which are on average a couple hundred lines each. We've organized things well enough that the cascade is a non-issue, and "leftover" styles from an element that's been removed are a rare occurrence. All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles. > don't follow naturally from "make this thing look this way" This is precisely the problem; programmers come from a background where they think in terms of "make it do this thing", and they try to translate that to "make this thing look this way". That's how you create supremely fragile CSS which is impossible to safely make changes to. Instead you should be thinking in terms of, "make it behave this way in the general case, relative to what's around it".
  - jacobush 8y ago
    "This can be easily solved with good project organization" "All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles." Super simple. It is what it is and powerful etc, but simple? I have given up. I just use the minimum web tech to get by.
mattkevan 8y ago
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 designed to complicate CSS a bit so developers feel at home. Pixel perfect design is totally possible, as long as the designer is aware of the constraints and opportunities of the medium they’re working in.
- pasta 8y ago
  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.
  - mattkevan 8y ago
    The key part of my point was "as long as the designer is aware of the constraints and opportunities of the medium they’re working in." Designers coming from print often get caught out when designing for the web as they tend to think of a webpage as a fixed layout, rather than a flexible system of components. It's also important to understand where the design and development budget should be effectively spent. For example, unless there's a real business or usability reason for doing so, there's little point in trying to custom-style form elements like selects as doing so is difficult and time consuming and system defaults look better and provide a more consistent experience. We demand pixel-perfect accuracy at work between design and code – but the developers must approve the designs first to confirm that it's achievable. I guess it comes down to what we define as 'pixel perfect'.
    - DanBC 8y ago
      > I guess it comes down to what we define as 'pixel perfect'. When the customer hears "pixel perfect" they don't think "different on different browsers and on different OSs and on different devices", they think "the same everywhere".
twntee 8y ago
`I think CSS is beautiful` first thing which comes to my mind.
VvR-Ox 8y ago
CSS itself isn't a bad idea but less, scss etc. showed that it was lacking some features you desperately want and in the meantime just styling the web with "a little CSS" is not enough anymore. You have a shitload of display sizes to support on the other hand and strange behaving browsers which aren't truly standardized on the other. That makes adjusting your CSS to all of these a pain in the ass even if you like fiddling around with styling (as I basically do). I don't want to adjust my margins, paddings and fonts and then restart from scratch because f Apple decided they will do everything in Safari completely different from the rest of the browsers just to show how special they are. I'm also sick of building selenium grids with a mac mini in them just to also test this piece of ... "ingenuity" ;-) So nowadays I just go with a framework with sane defaults and no-hassle usability and when I need something special I ask people who don't do anything but CSS the whole day. Without more standardization it's not a domain you'll be great at when you don't specialize in it - which means you got to invest a lot of time to master it.
- _bxg1 8y ago
  Imo as long as you're not targeting internet explorer, things are pretty consistent these days. All modern browsers are now "evergreen", which means they update automatically and silently, which is the best thing in the world for web devs. The only inconsistencies you get are some having implemented new features before others, not really outright contradictions, and even that isn't a very big gap these days.
mekoka 8y ago
> 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 configuration script language (systemd, nginx), etc. In all these the text based interface is the language used to speak with the underlying engine. Now, these languages must be designed and there are good designs and there are bad ones. If the language sucks, people can generally just choose to go with a competing alternative that has a somewhat more accommodating syntax. But CSS is a monopoly. We're stuck with it. For many of us it's a really shitty language that is guaranteed to live on, no matter what, just because, well browser technology. Ok, enough ranting, on with my demonstration. For this I'll take CSS positioning as a case. Let's say we decided to design a domain language to express how items on a web document must be placed. We could start from the perspective that when repositioning an element it should always be relative to some point of reference. That starting point could be the element's default position, or it could be the viewport, or it could be an ancestor element. From there we could devise some simple rules to express this. To move an element you must first declare where you're starting from. For example moving with respect to its "default" position in the normal flow of the page would be declared as such (could be made optional too): position-reference: default To move with respect to the viewport, you would start with: position-reference: viewport To move with respect to an ancestor (and possibly even a distant cousin element): position-reference: parent /* immediate parent */ position-reference: div /* first div ancestor */ position-reference: root /* the document */ position-reference: <some-syntax-to-navigate-ancestry> From there you could add a number of extra properties to fine-tune some specific behavior. For instance if you need to maintain the space that the element was occupying previously: position-maintain-gap: true Or to prevent scrolling when the item is relative to the viewport: position-scrolling: off The above patterns might seem vaguely familiar to some. That's because I've just described "relative", "sticky", "absolute" and "fixed" positioning (albeit with some added possibilities). As someone used to interact often with text-based interfaces, if I didn't know CSS, the above would be an approximation of my expectation of its rules for these concepts. This is how I understand them and how I anticipate a good domain-specific language would allow me to express them. It's precise and descriptive, but more importantly it's not too idiosyncratic, meaning that I'm not making up terminology that is so foreign that occasional users will have to be given a refresher every time they need to use them. Now, contrast that with how these concepts are actually expressed in CSS. Instead of the different patterns being simply given as combinations of the above simple options, as I've demonstrated, they're rather given as ready-to-eat dish with labels such as "relative", "absolute", "fixed", "sticky". The whole thing is then sprinkled with ifs and buts. This "simplification" doesn't always have the intended effect though, and many many people are just confused when first trying to understand positioning.
sureaboutthis 8y ago
I've always found people who struggle with CSS don't really know how CSS works and never studied as well as any other language or tool they use. They do a quick read of an article somewhere, ask a question on reddit, get an answer from some 15-year old kid, it doesn't work, and they give up. Yet they own whole book shelves on the latest trendy framework or language they are using.
svat 8y ago
You make a good observation that: > The browser has lots of default, complex behaviors that drive layout, and […] CSS is more about […] guiding that automatic engine I think for most people who struggle with layout, what they really need to learn is what process the browser uses to lay out content, so that they can then turn their mind to how to guide it. Instead, I've seen hardly any CSS tutorials / documentation that start with a description of the layout algorithm and what hooks it provides via CSS; they all start from the meaning of individual CSS declarations, which are never the full picture. I think there's really room for teaching layout from the other end (the following is the browser's algorithm, and here's what can influence it), for people who think procedurally.
- madeofpalk 8y ago
  Understand the browser and learning how to 'think in CSS' is the biggest trick I've found to being able to work in CSS efficiently. That, and experience. Very rarely do you actually encounter genuinely new layouts in CSS, so with experience you just end up building in your head your own little 'component library' and pattern match designs to that.
naikrovek 8y ago
> many programmers, who like things to be orderly, see CSS as arbitrary and chaotic. It is arbitrary and chaotic. It breaks the principle of least astonishment.

by _bxg1 8y ago

Animats 8y ago

CSS is not a real constraint language. If it really were a constraint language, it would be better. There's no constraint solver. Just a bunch of rules applied sequentially. I'd like to have a real constraint system, like the one in Autodesk Inventor sketch mode. You select two things and apply a constraint - parallel, tangent, horizontal, collinear, etc - and the constraint system enforces those constraints. The layout GUI tells you if you've created a conflict. CSS solves an easier problem, and not very well. It's such a mess that no one can attach a decent GUI to it. Amusingly, tables came back. But they're called "layout tables" now, to avoid embarrassment. Trying to do 2D layout with 1D constructs (the "float" and "clear" era) was just silly.

_bxg1 8y ago
> Amusingly, tables came back. But they're called "layout tables" now, to avoid embarrassment. I'm not really sure what you're talking about. Tables were bad because they were too rigid and weren't designed for layout purposes; they do still get used when you want to display an actual table. Maybe you meant CSS Grid? > Trying to do 2D layout with 1D constructs (the "float" and "clear" era) was just silly. The float era was certainly a dark time, and I'm glad I came into the field on the tail end of it. It was a hold-over from CSS' document-focused origins. Today we have flex-box, which quite elegantly serves 90% of people's layout needs, and CSS Grid which fills in the rest. For the record, flex-box is a 1D construct for doing 2D layouts, and it does the job fantastically. Your Autodesk comparison belies a fundamental misunderstanding about the nature of the DOM - it is, to its great advantage, a 1D space which flows into a 2D shape. In fact, this was the great flaw with using tables for layout in the first place. By making the content fundamentally 2D, all it could do to respond to different screen sizes and different browser window resizes is stretch. But you don't actually want your layout to be totally percentage-based. You want your content to wrap and flow to make the best use of the available space that it can, with no assumptions about screen size or ratio. The web is 1D because text is 1D. As text flows in lines, within containers which may be different shapes and sizes, so does the entire document model. This is profoundly powerful. Modern CSS gives you the tools to make select aspects of your layout work differently - yes, even in 2D ways - but they're best used to shape and guide that fundamental flow instead of replacing it.
- rmetzler 8y ago
  > Tables were bad because they were too rigid and weren't designed for layout purposes; they do still get used when you want to display an actual table. And when you have to implement a email design someone gave you who think it’s more important to have it look a certain way then to implement it reliable.
  - mattkevan 8y ago
    That’s because the rendering engines in email software are crap, not due to a deficiency in CSS - I think Outlook still uses Word’s HTML renderer and even Gmail doesn’t support everything.

mnutt 8y ago

Beyond the immediate issues of "what rules do I use to make this thing look this way", the cascade can also make large-scale management and code reuse challenging. It's sort of like object-oriented inheritance, except the definitions and instantiations live in totally different places, and the top-level object properties are defined by browser manufacturers, or possibly end-users. Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not to know whether changing it will break something somewhere else. People have developed some techniques to mitigate these issues, but many are unintuitive and don't follow naturally from "make this thing look this way".

_bxg1 8y ago
> It's sort of like object-oriented inheritance With the key difference being that there's no rigid structure to it at all, much less a strict-subset hierarchy. It's really more like structural object types, which can be easily composed, than OOP classes. It's set theory, rather than taxonomy. > Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not This can be easily solved with good project organization. At my day job I maintain a codebase with a couple hundred SCSS files, which are on average a couple hundred lines each. We've organized things well enough that the cascade is a non-issue, and "leftover" styles from an element that's been removed are a rare occurrence. All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles. > don't follow naturally from "make this thing look this way" This is precisely the problem; programmers come from a background where they think in terms of "make it do this thing", and they try to translate that to "make this thing look this way". That's how you create supremely fragile CSS which is impossible to safely make changes to. Instead you should be thinking in terms of, "make it behave this way in the general case, relative to what's around it".
- jacobush 8y ago
  "This can be easily solved with good project organization" "All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles." Super simple. It is what it is and powerful etc, but simple? I have given up. I just use the minimum web tech to get by.

mattkevan 8y ago

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 designed to complicate CSS a bit so developers feel at home. Pixel perfect design is totally possible, as long as the designer is aware of the constraints and opportunities of the medium they’re working in.

pasta 8y ago
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.
- mattkevan 8y ago
  The key part of my point was "as long as the designer is aware of the constraints and opportunities of the medium they’re working in." Designers coming from print often get caught out when designing for the web as they tend to think of a webpage as a fixed layout, rather than a flexible system of components. It's also important to understand where the design and development budget should be effectively spent. For example, unless there's a real business or usability reason for doing so, there's little point in trying to custom-style form elements like selects as doing so is difficult and time consuming and system defaults look better and provide a more consistent experience. We demand pixel-perfect accuracy at work between design and code – but the developers must approve the designs first to confirm that it's achievable. I guess it comes down to what we define as 'pixel perfect'.
  - DanBC 8y ago
    > I guess it comes down to what we define as 'pixel perfect'. When the customer hears "pixel perfect" they don't think "different on different browsers and on different OSs and on different devices", they think "the same everywhere".

twntee 8y ago

`I think CSS is beautiful` first thing which comes to my mind.

VvR-Ox 8y ago

CSS itself isn't a bad idea but less, scss etc. showed that it was lacking some features you desperately want and in the meantime just styling the web with "a little CSS" is not enough anymore. You have a shitload of display sizes to support on the other hand and strange behaving browsers which aren't truly standardized on the other. That makes adjusting your CSS to all of these a pain in the ass even if you like fiddling around with styling (as I basically do). I don't want to adjust my margins, paddings and fonts and then restart from scratch because f Apple decided they will do everything in Safari completely different from the rest of the browsers just to show how special they are. I'm also sick of building selenium grids with a mac mini in them just to also test this piece of ... "ingenuity" ;-) So nowadays I just go with a framework with sane defaults and no-hassle usability and when I need something special I ask people who don't do anything but CSS the whole day. Without more standardization it's not a domain you'll be great at when you don't specialize in it - which means you got to invest a lot of time to master it.

_bxg1 8y ago
Imo as long as you're not targeting internet explorer, things are pretty consistent these days. All modern browsers are now "evergreen", which means they update automatically and silently, which is the best thing in the world for web devs. The only inconsistencies you get are some having implemented new features before others, not really outright contradictions, and even that isn't a very big gap these days.

mekoka 8y ago

> 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 configuration script language (systemd, nginx), etc. In all these the text based interface is the language used to speak with the underlying engine. Now, these languages must be designed and there are good designs and there are bad ones. If the language sucks, people can generally just choose to go with a competing alternative that has a somewhat more accommodating syntax. But CSS is a monopoly. We're stuck with it. For many of us it's a really shitty language that is guaranteed to live on, no matter what, just because, well browser technology. Ok, enough ranting, on with my demonstration. For this I'll take CSS positioning as a case. Let's say we decided to design a domain language to express how items on a web document must be placed. We could start from the perspective that when repositioning an element it should always be relative to some point of reference. That starting point could be the element's default position, or it could be the viewport, or it could be an ancestor element. From there we could devise some simple rules to express this. To move an element you must first declare where you're starting from. For example moving with respect to its "default" position in the normal flow of the page would be declared as such (could be made optional too): position-reference: default To move with respect to the viewport, you would start with: position-reference: viewport To move with respect to an ancestor (and possibly even a distant cousin element): position-reference: parent /* immediate parent */ position-reference: div /* first div ancestor */ position-reference: root /* the document */ position-reference: <some-syntax-to-navigate-ancestry> From there you could add a number of extra properties to fine-tune some specific behavior. For instance if you need to maintain the space that the element was occupying previously: position-maintain-gap: true Or to prevent scrolling when the item is relative to the viewport: position-scrolling: off The above patterns might seem vaguely familiar to some. That's because I've just described "relative", "sticky", "absolute" and "fixed" positioning (albeit with some added possibilities). As someone used to interact often with text-based interfaces, if I didn't know CSS, the above would be an approximation of my expectation of its rules for these concepts. This is how I understand them and how I anticipate a good domain-specific language would allow me to express them. It's precise and descriptive, but more importantly it's not too idiosyncratic, meaning that I'm not making up terminology that is so foreign that occasional users will have to be given a refresher every time they need to use them. Now, contrast that with how these concepts are actually expressed in CSS. Instead of the different patterns being simply given as combinations of the above simple options, as I've demonstrated, they're rather given as ready-to-eat dish with labels such as "relative", "absolute", "fixed", "sticky". The whole thing is then sprinkled with ifs and buts. This "simplification" doesn't always have the intended effect though, and many many people are just confused when first trying to understand positioning.

sureaboutthis 8y ago

I've always found people who struggle with CSS don't really know how CSS works and never studied as well as any other language or tool they use. They do a quick read of an article somewhere, ask a question on reddit, get an answer from some 15-year old kid, it doesn't work, and they give up. Yet they own whole book shelves on the latest trendy framework or language they are using.

svat 8y ago

You make a good observation that: > The browser has lots of default, complex behaviors that drive layout, and […] CSS is more about […] guiding that automatic engine I think for most people who struggle with layout, what they really need to learn is what process the browser uses to lay out content, so that they can then turn their mind to how to guide it. Instead, I've seen hardly any CSS tutorials / documentation that start with a description of the layout algorithm and what hooks it provides via CSS; they all start from the meaning of individual CSS declarations, which are never the full picture. I think there's really room for teaching layout from the other end (the following is the browser's algorithm, and here's what can influence it), for people who think procedurally.

madeofpalk 8y ago
Understand the browser and learning how to 'think in CSS' is the biggest trick I've found to being able to work in CSS efficiently. That, and experience. Very rarely do you actually encounter genuinely new layouts in CSS, so with experience you just end up building in your head your own little 'component library' and pattern match designs to that.

naikrovek 8y ago

> many programmers, who like things to be orderly, see CSS as arbitrary and chaotic. It is arbitrary and chaotic. It breaks the principle of least astonishment.