3 ms·

Too much CSS, possibly. Too much cognitive load, definitely, I do think so. As a whole, modern CSS features feel unintuitive and often require a historical kn

Too much CSS, possibly. Too much cognitive load, definitely, I do think so. As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve, which means to me, it's laden with baggage. Some new CSS feature pages on MDN are absolutely gigantic in their explanations, and that means that there is a lot of 'talking' required to overcome its unintuitive nature. Of course, once you start using it, it becomes just another tool.

sbf501 4y ago
> Too much CSS, possibly. > Too much cognitive load, definitely, I do think so. That's a good way to put it. AFter reading those two statements, it started to occur to me that a well-organized concept can have breadth, but not tax one's cognitive facilities. I think of programming languages. They ALL started simple, but then accrete. Look at K&R's original C, then look at C2x. The cognitive load increases. Like you said, "require a historical knowledge"[1]. Do you think this is inevitable? I tend to think languages need major overhauls and backwards-compatibility breaking in order to become "cleaner". Intel & the PC maintained massive backwards compatibility, but parts of the architecture are a nightmare (like the intel instruction decoder); whereas early Apple tossed backwards compatibility routinely for better tech (now they do it for profit, I'm afraid). Same with Windows v. (early) MacOS. When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there? [1] (there was a post the other day on HN where a programmer was talking about a text editor and how he used nonprintable unicode to indicate new pages: this young cub had apparently never heard of the first 31 characters of ASCII!!)
- Sohcahtoa82 4y ago
  > When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there? The W3Schools page for <frame> says it is not supported in HTML 5 [0]. The MDN page for it warns that it may be removed from browsers at any time, though the compatibility table says it's still supported in every browser. [0] https://www.w3schools.com/tags/tag_frame.asp https://www.w3schools.com/tags/tag_frame.asp [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...
- thfuran 4y ago
  >Do you think this is inevitable? I tend to think languages need major overhauls and backwards-compatibility breaking in order to become "cleaner". I think it's pretty much inevitable when use case and/or feature set significantly changes but there's not a comprehensive overhaul of existing work. I think programming languages, code bases, and even cities all have basically the same issue: if the goal or the environment has significantly changed after a lot of work has been done, you're likely to end up with a final product that isn't what you'd choose if you were starting today.
- alwillis 4y ago
  When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there? Yes; in the early 2000’s, the W3C created XHTML 2.0 [1], a strict XML-based re-implementation of HTML. Because it dropped backwards compatibility to HTML4, it created a lot of backlash that (eventually) resulted in the browser vendors forming their own standards organization (WHATWG) which lead to the creation of HTML5. [1]: https://en.wikipedia.org/wiki/XHTML#XHTML_2.0 https://en.wikipedia.org/wiki/XHTML#XHTML_2.0
tikhonj 4y ago
I've just started playing around with CSS after a seven year break from web programming and have the opposite impression. The two biggest additions I've seen are flexbox and grid both of which massively decrease the cognitive load—compared to past options, it almost feels like cheating. Moreover, they do this by consciously not building on top of past layout features but instead doing their own thing. CSS is still a mess of random features that can't be cleanly composed or extended—it's the complete opposite of a language that can grow[1]—but it's a more usable mess than it used to be. [1]: Wonderful talk on language design by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0
- naasking 4y ago
  > CSS is still a mess of random features that can't be cleanly composed or extended The lack of orthogonality and composability has always been the core issue. It's definitely better now, and atomic CSS makes this pretty close to simple.
- alwillis 4y ago
  CSS is still a mess of random features that can't be cleanly composed or extended If you separate old CSS from new CSS, it’s not so bad. Yes, CSS has some technical debt from the olden times (like any programming language does) but these days, you need less and less of the old stuff. For example, all of the alignment stuff created originally for Flexbox (justify-content, align-items, justify-self, etc.) were broken out in their own specification [1] and now CSS Grid and any future specification uses the same terminology to describe how to align something in a box. Instead of every color model having it's own syntax, which is how CSS started, there's now color functions that can specify any color in any color space [2]. [1]: https://drafts.csswg.org/css-align/ https://drafts.csswg.org/css-align/ [2]: https://drafts.csswg.org/css-color-5/#color-function https://drafts.csswg.org/css-color-5/#color-function
alwillis 4y ago
As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve… Disagree. The beauty of CSS Grid and Flexbox is that you don’t need to know anything about the hacks and work-arounds which were the industry standard to approximate what these specifications give us today. The reason why you see seasoned web developers go on and on about how it used to be is due to how unintuitive and fragile those methods were compared to today. It’s similar to young people today: they don’t need to know anything about using a modem to dial-up to an ISP to access the internet in the age of broadband and Wi-Fi.
Frotag 4y ago
> As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve There's no real way to debug unexpected behavior short of digging through the W3 spec. For example you can't set height / width on inline elements, but you'll never see any error messages or warnings in devtools / IDEs when you try. It doesn't help that tutorials rarely discuss how "layout algorithms" [0] (block, inline, flex, grid) affect certain rules. [0] - https://www.joshwcomeau.com/css/understanding-layout-algorithms/ https://www.joshwcomeau.com/css/understanding-layout-algorit...
- alwillis 4y ago
  you'll never see any error messages or warnings in devtools / IDEs when you try. I’ve seem dev tools highlight code that either doesn’t make sense or doesn’t have any affect. I wonder if something like Stylelint [1] would catch this. [1]: https://stylelint.io https://stylelint.io

sbf501 4y ago

> Too much CSS, possibly. > Too much cognitive load, definitely, I do think so. That's a good way to put it. AFter reading those two statements, it started to occur to me that a well-organized concept can have breadth, but not tax one's cognitive facilities. I think of programming languages. They ALL started simple, but then accrete. Look at K&R's original C, then look at C2x. The cognitive load increases. Like you said, "require a historical knowledge"[1]. Do you think this is inevitable? I tend to think languages need major overhauls and backwards-compatibility breaking in order to become "cleaner". Intel & the PC maintained massive backwards compatibility, but parts of the architecture are a nightmare (like the intel instruction decoder); whereas early Apple tossed backwards compatibility routinely for better tech (now they do it for profit, I'm afraid). Same with Windows v. (early) MacOS. When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there? [1] (there was a post the other day on HN where a programmer was talking about a text editor and how he used nonprintable unicode to indicate new pages: this young cub had apparently never heard of the first 31 characters of ASCII!!)

Sohcahtoa82 4y ago
> When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there? The W3Schools page for <frame> says it is not supported in HTML 5 [0]. The MDN page for it warns that it may be removed from browsers at any time, though the compatibility table says it's still supported in every browser. [0] https://www.w3schools.com/tags/tag_frame.asp https://www.w3schools.com/tags/tag_frame.asp [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...
thfuran 4y ago
>Do you think this is inevitable? I tend to think languages need major overhauls and backwards-compatibility breaking in order to become "cleaner". I think it's pretty much inevitable when use case and/or feature set significantly changes but there's not a comprehensive overhaul of existing work. I think programming languages, code bases, and even cities all have basically the same issue: if the goal or the environment has significantly changed after a lot of work has been done, you're likely to end up with a final product that isn't what you'd choose if you were starting today.
alwillis 4y ago
When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there? Yes; in the early 2000’s, the W3C created XHTML 2.0 [1], a strict XML-based re-implementation of HTML. Because it dropped backwards compatibility to HTML4, it created a lot of backlash that (eventually) resulted in the browser vendors forming their own standards organization (WHATWG) which lead to the creation of HTML5. [1]: https://en.wikipedia.org/wiki/XHTML#XHTML_2.0 https://en.wikipedia.org/wiki/XHTML#XHTML_2.0

tikhonj 4y ago

I've just started playing around with CSS after a seven year break from web programming and have the opposite impression. The two biggest additions I've seen are flexbox and grid both of which massively decrease the cognitive load—compared to past options, it almost feels like cheating. Moreover, they do this by consciously not building on top of past layout features but instead doing their own thing. CSS is still a mess of random features that can't be cleanly composed or extended—it's the complete opposite of a language that can grow[1]—but it's a more usable mess than it used to be. [1]: Wonderful talk on language design by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0

naasking 4y ago
> CSS is still a mess of random features that can't be cleanly composed or extended The lack of orthogonality and composability has always been the core issue. It's definitely better now, and atomic CSS makes this pretty close to simple.
alwillis 4y ago
CSS is still a mess of random features that can't be cleanly composed or extended If you separate old CSS from new CSS, it’s not so bad. Yes, CSS has some technical debt from the olden times (like any programming language does) but these days, you need less and less of the old stuff. For example, all of the alignment stuff created originally for Flexbox (justify-content, align-items, justify-self, etc.) were broken out in their own specification [1] and now CSS Grid and any future specification uses the same terminology to describe how to align something in a box. Instead of every color model having it's own syntax, which is how CSS started, there's now color functions that can specify any color in any color space [2]. [1]: https://drafts.csswg.org/css-align/ https://drafts.csswg.org/css-align/ [2]: https://drafts.csswg.org/css-color-5/#color-function https://drafts.csswg.org/css-color-5/#color-function

alwillis 4y ago

As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve… Disagree. The beauty of CSS Grid and Flexbox is that you don’t need to know anything about the hacks and work-arounds which were the industry standard to approximate what these specifications give us today. The reason why you see seasoned web developers go on and on about how it used to be is due to how unintuitive and fragile those methods were compared to today. It’s similar to young people today: they don’t need to know anything about using a modem to dial-up to an ISP to access the internet in the age of broadband and Wi-Fi.

Frotag 4y ago

> As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve There's no real way to debug unexpected behavior short of digging through the W3 spec. For example you can't set height / width on inline elements, but you'll never see any error messages or warnings in devtools / IDEs when you try. It doesn't help that tutorials rarely discuss how "layout algorithms" [0] (block, inline, flex, grid) affect certain rules. [0] - https://www.joshwcomeau.com/css/understanding-layout-algorithms/ https://www.joshwcomeau.com/css/understanding-layout-algorit...

alwillis 4y ago
you'll never see any error messages or warnings in devtools / IDEs when you try. I’ve seem dev tools highlight code that either doesn’t make sense or doesn’t have any affect. I wonder if something like Stylelint [1] would catch this. [1]: https://stylelint.io https://stylelint.io