17 ms·

I always thought this was funny. This was the embodiment of the original CSS philosophy, which was to "label your html elements semantically with what they ARE,

I always thought this was funny. This was the embodiment of the original CSS philosophy, which was to "label your html elements semantically with what they ARE, and then worry about styling those in the CSS." The whole point was to get anything style related out of the HTML altogether, the HTML would just be semantic/content related. But then Bootstrap and other CSS libraries came out, and completely inverted the philosophy back to what HTML originally looked like pre-CSS, which is that you had all of these rules you could place directly in the HTML that would directly control how the element was styled. In CSS Zen era you could look at my HTML and have no idea how I intended it to LOOK, whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually. Now people just make components and will maybe use style variables/tokens. Just funny how things change.

arkh 7y ago
And now we're back to table-based design and flash-like but less powerful javascript based application.
jakearmitage 7y ago
http://smacss.com http://smacss.com tried to push this, but failed
- hinkley 7y ago
  Can’t remember which, but there was someone who made a CSS library that patterned like a fluent interface. They had lots of selectors that were adjectives, and most of them composed. So you could have a class=“tiny button” or whatnot.
  - mpranjic 7y ago
    Perhaps Semantic UI?
    - hinkley 7y ago
      YES. That's the one. Thanks.
rimliu 7y ago
I think this reversal is sad, actually. Even sadder, that one of the driving reasons was people just giving up on CSS ("too complex/weird") and going for spaghetti and a wall approach. Then trying to use tools to plug the knowledge hole.
- sbergot 7y ago
  It is only sad when you have not worked on a medium sized website/webapp. For a small document like css zen garden where the goal is to produce a diversity of design without changing the html? css selectors are perfect. But how often is that the goal of the UI team? The goal of a ui team is to have a consistent ui that is easy to change. Components helps with consistency. It also helps in separation of concerns: you can have someone writing the component library and someone else using it. The goal of a ui team is also to minimise the amount of ui bugs, and the amount of ui code. If you let people go wild with css selectors, you end up with badly scoped class names and very painful integration phases where selectors breaks the ui across the whole application. When fixing bugs people are too afraid to remove anything because it means that they have to test a huge scope. The trend I see is not spaguetti (except in places that don't care). It is the use of a very restricted type of selector: .class_name. Some people use css BEM or functional css and write those names themselves. Some people use a css in js library that generates them. We have started adopting css BEM two years ago and now we are considering using a css in js library. I had to manage a css library update recently and 90% of the issues were in place where people didn't have this kind of methodologies.
  - z3t4 7y ago
    Just like with programming you have to limit scope. And avoid using global scope. Its fine to have a "private" base style for components. The power of CSS however is that users can overrule those styles. Its however important to organize the css in a cascade and not have rules for the same element spread out all over the place with !important everywhere.
- klodolph 7y ago
  Honestly I say the reason it’s sad is because of the idea that CSS promised something it couldn’t deliver. The sad part isn’t that people gave up on CSS, the sad part is that people believed it could work this way in the first place. Writing CSS stylesheets by hand is like writing HTML pages by hand. It just doesn’t scale, and you run into a million tiny problems every time you change something in a medium size project. So for HTML we use templates and components. For CSS, we want the CSS for a component right next to the component itself in our VS Code window, so that actual humans have good insight into what styles will affect a particular component. The alternative—keeping the CSS separate—requires its own set of tooling to plug the holes, like all those fancy web developer tools built into browsers these days.
dsego 7y ago
If you look at some talks on ideas behind oocss you can understand that a lot of elements share similar styles. It's all boxes in the end. There is this one talk about refactoring a huge pile of css into a small number of reusable visual styles, I think it was for facebook. The semantics of an element might be a comment box, but visually it's a box with a shadow and a chat box or sidebar might share the same look, thereby it would make sense to assign them the same class (classes are intended for extracting common visual styles). Doing styles the zen garden way was usually done via long selectors to target the elements and you would end up with css code that is tightly coupled to your markup. Moving html sections would cause the styles to break. Using strictly visual styles (ie functional classes) makes it easier to distinguish the style aspect from the content and HTML is already a presentational medium.
- saagarjha 7y ago
  > classes are intended for extracting common visual styles No, they’re intended to group together semantically similar elements. There’s no reason that a blue button and a blue link should be related–what if I want to make the button red later?
  - sbergot 7y ago
    What about a classes like primary-color, secondary-color, danger-color & success-color? Having two elements share the same color creates a relation between the two elements. If you have decided to use the same color for both elements it is probably because this color has a specific meaning. If the color of one of the elements changes it is probably a good idea to also change the other element.
    - saagarjha 7y ago
      That sounds like an excellent use case for CSS variables.
      - dsego 7y ago
        Those were not supported across all browsers for a long time (recently IE11). Also, a variable only covers one property and is not adequate to extract many shared properties. Less/sass mixins and inheritance are a good way to extract reusable parts shared between components.
thomascgalvin 7y ago
I've seen people seriously recommend marking up your document like this: <div style="display: table;"> <div style="display: table-row;"> <div style="display: table-cell;"> </div> </div> </div> How in the nine fires of hell is that better than just using a table?
- castis 7y ago
  I am convinced that people who recommend things like that have no idea where we are or how we got here.
- HideousKojima 7y ago
  Probably to avoid the dumb limitations on having forms within a table? Still an awful and ugly way to do it
- mgr86 7y ago
  This makes me cringe. I may have been 12 but I was making websites in 1998. And they were decent--I mean, it was a lot of right click > view source copying. But I fell in love with the Web Standards movement. I was probably the only 13 year old whose book shelf included books on perl, css, xml, and the like.
  - carldaddy 7y ago
    I feel the same way. It's probably because I'm 90s kid and nostalgia, but I wish web standards were taken seriously.
- hinkley 7y ago
  CSS Zen Garden seemed to have a message that you don’t need tables for everything, but it was astonishing how few of the featured designs ever handled responsive layout properly. Getting text to fit into a rectangle by cheating was very common and you’d see bleed everywhere at a different resolution. Until flexbox, there was no way to fix this without resorting to table cell behavior. It ultimately soured me on the Garden. And thankfully I got to use CSS3 shortly after.
deleted 7y ago
[deleted]
gridlockd 7y ago
Semantic HTML has never been something that businesses asked for. HTML has never been a good format for structured data. Things have simply moved towards what's actually manageable in a production environment, not what some ivory tower designer thought was good practice.
williamdclt 7y ago
Because it was "the whole point" doesn't mean that it was a "good idea", especially when the web changed so much since then. It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes? I find the approach by Bootstrap (or better, Tailwind) much easier to work with: compose utility classes to make up higher-level components. It still require some encapsulation of these higher-order components (with a Web Component, React Component or even just a class with @apply), but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around. Ultimately I code faster with less bugs and easier maintainance: I take it as a subjectively better approach.
- uk_programmer 7y ago
  > It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes? If the markup is done properly in the first place. It is incredibly easy to restyle and you typically don't to rework much markup. It just ends up working. > but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around. I have seen no evidence of this in practice. This is only true if you design is basically a skin of these frameworks. If you have anything remotely custom you end up overriding so much you might have well just started with a normalise/reset style-sheet. So for some internal application that never seen on the outside, you can use bootstrap and slap something together quick sure. However if you are actually building something with a unique it just doesn't really work. If you think about what you are doing instead of just jumping in and coding. You can break stuff down properly without the need for hundreds of classes that typically come with these CSS frameworks. You do end up with clean CSS and the markup is clean and you do have less code. By doing things properly i.e. you markup and css is correct. You have less cross browser bugs. I end up in my current being asked by a coworker to pick up IE bugs (yes we still support IE9 upwards). Only 10% of the fixes are actually problems with IE. 90% of the problems are correcting the markup (making it valid) and cleaning up the CSS and it just works cross browser. Sure you will have to work around things like you don't have flexbox and other niceties and you have to use an alternative style-sheet. But fixing the markup normally gets it from "not rendering properly at all" to "rendering only slightly wrong".
hinkley 7y ago
Bootstrap still gives me an eye twitch. It didn’t handle color customization properly until at least 3.0 (oh you could color many things, but you want light text on a dark background and you’ll have to override a ton of stuff). I was ordered to use a version that didn’t even handle responsive design properly. Right after we had agreed to make the app responsive.
- kevin_thibedeau 7y ago
  It's a shame that Foundation never caught on fire because they were/are way ahead of Bootstrap in these and other areas.
  - bmn__ 7y ago
    To "become popular" is just "caught on", not "caught on fire". https://www.lexico.com/definition/catch_on https://www.lexico.com/definition/catch_on
leeoniya 7y ago
> whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually. say what you will about utility classes, but the grid classes are absolutely necessary, especially when many elements might need specific behavior for different screen sizes and must interact gracefully. without the grid classes your css would be an absolute nightmare of a thousand often-nonsensical "semantic" classnames littered with a crapload of fragile media queries.
- nickelcitymario 7y ago
  This is no longer true with CSS Grids. The grids are all defined in the CSS itself, allowing us to once again separate style and content, as well as allowing us to define custom templates for different screen sizes (rather than simply force them into a single-column, left-to-right order). I know this is still barely being used, but it's clearly the better way to go.
- nitely 7y ago
  Sass removes most of the cruft. I made a semantic flex grid many years ago, and the result was a lot more clean than using utilities, even in the css side [0]. This was before CSS Grid Layout was widely supported, nowadays you can use plain CSS grids and get similar results. [0] https://github.com/nitely/semantic-flex-grid/ https://github.com/nitely/semantic-flex-grid/
  - leeoniya 7y ago
    > I made a semantic flex grid many years ago, and the result was a lot more clean than using utilities your grid has zero media queries in it, which means whatever grid classes you were using before were not responsive - which is where 90% of the complexity lives. complex/nested responsive grids are not simple, unfortunately. i've made one, too: https://github.com/leeoniya/flecks https://github.com/leeoniya/flecks
    - nitely 7y ago
      > complex/nested responsive grids are not simple, unfortunately. How does utilities make complex/nested responsive grid simple, again? I'm arguing semantic css is simpler than using utilities all over the HTML, not that it magically makes responsive design easy. > your grid has zero media queries in it, which means whatever grid classes you were using before were not responsive - which is where 90% of the complexity lives. There are some in the examples [0][1]. Both for responsive design and nested grid, sadly not for both at the same time. It's not much more complex, though, well I guess it depends on how complex are we talking about. Anyway, CSS Grid makes semantic layout a lot simpler now. [0] https://github.com/nitely/semantic-flex-grid/blob/gh-pages/sass/styles.scss#L59 https://github.com/nitely/semantic-flex-grid/blob/gh-pages/s... [1] https://nitely.github.io/semantic-flex-grid/ https://nitely.github.io/semantic-flex-grid/
tylerjwilk00 7y ago
So long as structure and design overlap there will always be some inescapable coupling. The choice is deciding which one should master over the other.
jacurtis 7y ago
The ultimate anti-pattern of this philosophy is Tailwind.css (the newest, "coolest" css framework). Not trying to hate on it, but I find it ironic that the whole point of Tailwind is that you can basically style your entire website within the HTML, without needing to customize it with CSS. For someone who learned CSS during the CSS Zen Garden era where we were told to only use the HTML document for structure and never style, it makes Tailwind cringe-worthy. Yes, I know lots of people customize it and stuff, but the idea still stands that 95% of styles are done within the HTML document through tens of thousands of ultra-specific css classes which basically just tweak a single css property.
- adamlett 7y ago
  The gospel of separating styling from content comes from an era when most web sites were comprised of collections of hand crafted HTML documents, when it was a pain to make site wide changes to styling because it meant updating each of these documents by hand. These days web sites are mostly comprised of HTML pages rendered on the fly by some type of web app which composes pages from nested templates injected with content from a database. In this scenario separating the styling from the markup gains us little, because to change the styling site wide you only have to update a few templates, not every single page that uses these templates.
- Ayesh 7y ago
  Totally agree with this. It's faster to prototype with Tailwind though, if you remember the class names well.
  - jfengel 7y ago
    Unfortunately, prototypes are rarely thrown away. Prototypes become production code, because code that works is usually more important than code that's clean. Cleanliness comes with refactoring. And that's actually OK, most of the time. In some situations you have to be certain you get it right the first time, but the web encourages you to try, deploy, and fix later. It's messy and has long-term debt, but a lot of that debt rarely comes due. You might just be the one holding it when the bill comes in, and that's no fun, but people do this because on the whole the amortized cost is less. Just don't fool yourself into thinking that this is just the prototype. Unless you have specifically allocated resources to throwing it out and starting over, acknowledge from the beginning that this is going to be production code. That way you make fewer of those "Oh, well, it's a prototype" decisions. Not zero, just fewer.
jguffey 7y ago
I've long thought about this too. Eventually I've come to the conclusion that CSS Zen Garden was more about "Hey you can do all of this with pure CSS" than it was "You should do it this way". At the time that I discovered Zen Garden, CSS was in it's more early, primitive days. As a front-end developer, it was easy to say "I can't achieve this design without changing the HTML Structure". Zen Garden showed us that this was just an excuse, (just about) any design could be achieved without a requirement to fundamentally change the HTML of the page. It was eye-opening to see some of the ways theme authors rearranged content, broke down those box boundaries, and used design tricks that stretched the limits of CSS and HTML in that era. It was awfully inspiring, and I think the point was never - "this is the way you should encode pages" it was more about taking excuses away.
- regularfry 7y ago
  The point absolutely was "this is the way you should encode pages", or rather "this is what is possible if you encode pages this way". The purpose of Zen Garden was to highlight the separation between style and content; that separation is why we've got CSS as a separate language to HTML in the first place.
- jtms 7y ago
  No, it was absolutely about the way you should "encode" your pages. I would choose the word "markup" here instead as that's what it is, but it was 100% a recommendation on the benefits of separation between markup and presentation.
- bluetwo 7y ago
  Or, was it to prove that yes, you can live without Flash.
bromuro 7y ago
Well I think it went that way because CSS is lot of frustration and not much zen.
crispyambulance 7y ago
> ...in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually. Part of the blame for this has to fall onto the lap of CSS itself. Up until CSS-grid it has been too damn hard to get layout to "just freaking work" with CSS. To be fair, it was even more of a dumpster fire back in the early naughts when almost everyone just used HTML tables to do their layouts. The folks behind CSS should have caught on at that time and focused on making layout better and eliminate thousands of person-years of frontend people grinding their gears... BUT NO, not until 2018-ish did we get CSS-grid.
- pjmlp 7y ago
  And ironically CSS-grid was born as part of WPF's Grid component.
  - crispyambulance 7y ago
    Not surprising at all. The desktop application world has long enjoyed relatively fuss-free layouts. Java swing had nice layout mechanisms too. MIG-layout comes to mind.
lazyjones 7y ago
People are far too concerned with these things anyway, IMO. All ways work well enough and perhaps I'm just ignorant, but in the past 25 years I haven't seen a single good example of a situation where someone won against the competition because of better presentation or better choice of frontend framework. That excludes those who shot themselves in the foot with Flash though. IOW, put the effort into backends / core functionality and not elegant styling or elaborate frameworks.
wdb 7y ago
Personally, I find the mixes of class names like with Tailwind really confusing and need to keep looking it up when using it. Doesn't really make things easier imho
hcarvalhoalves 7y ago
Because every 10 years you have people who haven't been around for the past 20 years (re-?) inventing things.
mightybyte 7y ago
For awhile now I've felt that the CSS libraries like Bootstrap, Semantic UI, etc are never the "right" way to organize your markup and CSS for a large project. They're great for getting out something quick and dirty that looks decent. But once your project passes a certain scale (in size or time spent maintaining it), the balance shifts in favor of semantic markup and style in CSS using BEM or something similar as an organizational paradigm. The latter just doesn't seem conducive to off-the-shelf styles because semantic organization is different for every project. Another way of thinking about it is that CSS libraries build infrastructure for universal reusable widgets. In the beginning of a project it makes sense to build your app by putting together these building blocks. But as time goes by and the app grows, you start to develop a layer of higher level UI abstractions that are specific to the domain of your app. And when that happens it is often in conjunction with some kind of a re-styling and the old universal building blocks are no longer what you want. I've seen multiple large frontend projects go through these phases, and am starting to see them as a natural evolution of frontend projects.
lmm 7y ago
It's a failed experiment. We've had over a decade of people trying to use CSS to style websites and ending up with worse results than if they'd just changed the HTML. Let it die.
arvinsim 7y ago
Funnily enough, styled-components in React does allow me to focus on the semantics meaning without worrying about the style.

arkh 7y ago

And now we're back to table-based design and flash-like but less powerful javascript based application.

jakearmitage 7y ago

http://smacss.com http://smacss.com tried to push this, but failed

hinkley 7y ago
Can’t remember which, but there was someone who made a CSS library that patterned like a fluent interface. They had lots of selectors that were adjectives, and most of them composed. So you could have a class=“tiny button” or whatnot.
- mpranjic 7y ago
  Perhaps Semantic UI?
  - hinkley 7y ago
    YES. That's the one. Thanks.

rimliu 7y ago

I think this reversal is sad, actually. Even sadder, that one of the driving reasons was people just giving up on CSS ("too complex/weird") and going for spaghetti and a wall approach. Then trying to use tools to plug the knowledge hole.

sbergot 7y ago
It is only sad when you have not worked on a medium sized website/webapp. For a small document like css zen garden where the goal is to produce a diversity of design without changing the html? css selectors are perfect. But how often is that the goal of the UI team? The goal of a ui team is to have a consistent ui that is easy to change. Components helps with consistency. It also helps in separation of concerns: you can have someone writing the component library and someone else using it. The goal of a ui team is also to minimise the amount of ui bugs, and the amount of ui code. If you let people go wild with css selectors, you end up with badly scoped class names and very painful integration phases where selectors breaks the ui across the whole application. When fixing bugs people are too afraid to remove anything because it means that they have to test a huge scope. The trend I see is not spaguetti (except in places that don't care). It is the use of a very restricted type of selector: .class_name. Some people use css BEM or functional css and write those names themselves. Some people use a css in js library that generates them. We have started adopting css BEM two years ago and now we are considering using a css in js library. I had to manage a css library update recently and 90% of the issues were in place where people didn't have this kind of methodologies.
- z3t4 7y ago
  Just like with programming you have to limit scope. And avoid using global scope. Its fine to have a "private" base style for components. The power of CSS however is that users can overrule those styles. Its however important to organize the css in a cascade and not have rules for the same element spread out all over the place with !important everywhere.
klodolph 7y ago
Honestly I say the reason it’s sad is because of the idea that CSS promised something it couldn’t deliver. The sad part isn’t that people gave up on CSS, the sad part is that people believed it could work this way in the first place. Writing CSS stylesheets by hand is like writing HTML pages by hand. It just doesn’t scale, and you run into a million tiny problems every time you change something in a medium size project. So for HTML we use templates and components. For CSS, we want the CSS for a component right next to the component itself in our VS Code window, so that actual humans have good insight into what styles will affect a particular component. The alternative—keeping the CSS separate—requires its own set of tooling to plug the holes, like all those fancy web developer tools built into browsers these days.

dsego 7y ago

If you look at some talks on ideas behind oocss you can understand that a lot of elements share similar styles. It's all boxes in the end. There is this one talk about refactoring a huge pile of css into a small number of reusable visual styles, I think it was for facebook. The semantics of an element might be a comment box, but visually it's a box with a shadow and a chat box or sidebar might share the same look, thereby it would make sense to assign them the same class (classes are intended for extracting common visual styles). Doing styles the zen garden way was usually done via long selectors to target the elements and you would end up with css code that is tightly coupled to your markup. Moving html sections would cause the styles to break. Using strictly visual styles (ie functional classes) makes it easier to distinguish the style aspect from the content and HTML is already a presentational medium.

saagarjha 7y ago
> classes are intended for extracting common visual styles No, they’re intended to group together semantically similar elements. There’s no reason that a blue button and a blue link should be related–what if I want to make the button red later?
- sbergot 7y ago
  What about a classes like primary-color, secondary-color, danger-color & success-color? Having two elements share the same color creates a relation between the two elements. If you have decided to use the same color for both elements it is probably because this color has a specific meaning. If the color of one of the elements changes it is probably a good idea to also change the other element.
  - saagarjha 7y ago
    That sounds like an excellent use case for CSS variables.
    - dsego 7y ago
      Those were not supported across all browsers for a long time (recently IE11). Also, a variable only covers one property and is not adequate to extract many shared properties. Less/sass mixins and inheritance are a good way to extract reusable parts shared between components.

thomascgalvin 7y ago

I've seen people seriously recommend marking up your document like this: <div style="display: table;"> <div style="display: table-row;"> <div style="display: table-cell;"> </div> </div> </div> How in the nine fires of hell is that better than just using a table?

castis 7y ago
I am convinced that people who recommend things like that have no idea where we are or how we got here.
HideousKojima 7y ago
Probably to avoid the dumb limitations on having forms within a table? Still an awful and ugly way to do it
mgr86 7y ago
This makes me cringe. I may have been 12 but I was making websites in 1998. And they were decent--I mean, it was a lot of right click > view source copying. But I fell in love with the Web Standards movement. I was probably the only 13 year old whose book shelf included books on perl, css, xml, and the like.
- carldaddy 7y ago
  I feel the same way. It's probably because I'm 90s kid and nostalgia, but I wish web standards were taken seriously.
hinkley 7y ago
CSS Zen Garden seemed to have a message that you don’t need tables for everything, but it was astonishing how few of the featured designs ever handled responsive layout properly. Getting text to fit into a rectangle by cheating was very common and you’d see bleed everywhere at a different resolution. Until flexbox, there was no way to fix this without resorting to table cell behavior. It ultimately soured me on the Garden. And thankfully I got to use CSS3 shortly after.

deleted 7y ago

[deleted]

gridlockd 7y ago

Semantic HTML has never been something that businesses asked for. HTML has never been a good format for structured data. Things have simply moved towards what's actually manageable in a production environment, not what some ivory tower designer thought was good practice.

williamdclt 7y ago

Because it was "the whole point" doesn't mean that it was a "good idea", especially when the web changed so much since then. It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes? I find the approach by Bootstrap (or better, Tailwind) much easier to work with: compose utility classes to make up higher-level components. It still require some encapsulation of these higher-order components (with a Web Component, React Component or even just a class with @apply), but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around. Ultimately I code faster with less bugs and easier maintainance: I take it as a subjectively better approach.

uk_programmer 7y ago
> It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes? If the markup is done properly in the first place. It is incredibly easy to restyle and you typically don't to rework much markup. It just ends up working. > but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around. I have seen no evidence of this in practice. This is only true if you design is basically a skin of these frameworks. If you have anything remotely custom you end up overriding so much you might have well just started with a normalise/reset style-sheet. So for some internal application that never seen on the outside, you can use bootstrap and slap something together quick sure. However if you are actually building something with a unique it just doesn't really work. If you think about what you are doing instead of just jumping in and coding. You can break stuff down properly without the need for hundreds of classes that typically come with these CSS frameworks. You do end up with clean CSS and the markup is clean and you do have less code. By doing things properly i.e. you markup and css is correct. You have less cross browser bugs. I end up in my current being asked by a coworker to pick up IE bugs (yes we still support IE9 upwards). Only 10% of the fixes are actually problems with IE. 90% of the problems are correcting the markup (making it valid) and cleaning up the CSS and it just works cross browser. Sure you will have to work around things like you don't have flexbox and other niceties and you have to use an alternative style-sheet. But fixing the markup normally gets it from "not rendering properly at all" to "rendering only slightly wrong".

hinkley 7y ago

Bootstrap still gives me an eye twitch. It didn’t handle color customization properly until at least 3.0 (oh you could color many things, but you want light text on a dark background and you’ll have to override a ton of stuff). I was ordered to use a version that didn’t even handle responsive design properly. Right after we had agreed to make the app responsive.

kevin_thibedeau 7y ago
It's a shame that Foundation never caught on fire because they were/are way ahead of Bootstrap in these and other areas.
- bmn__ 7y ago
  To "become popular" is just "caught on", not "caught on fire". https://www.lexico.com/definition/catch_on https://www.lexico.com/definition/catch_on

leeoniya 7y ago

> whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually. say what you will about utility classes, but the grid classes are absolutely necessary, especially when many elements might need specific behavior for different screen sizes and must interact gracefully. without the grid classes your css would be an absolute nightmare of a thousand often-nonsensical "semantic" classnames littered with a crapload of fragile media queries.

nickelcitymario 7y ago
This is no longer true with CSS Grids. The grids are all defined in the CSS itself, allowing us to once again separate style and content, as well as allowing us to define custom templates for different screen sizes (rather than simply force them into a single-column, left-to-right order). I know this is still barely being used, but it's clearly the better way to go.
nitely 7y ago
Sass removes most of the cruft. I made a semantic flex grid many years ago, and the result was a lot more clean than using utilities, even in the css side [0]. This was before CSS Grid Layout was widely supported, nowadays you can use plain CSS grids and get similar results. [0] https://github.com/nitely/semantic-flex-grid/ https://github.com/nitely/semantic-flex-grid/
- leeoniya 7y ago
  > I made a semantic flex grid many years ago, and the result was a lot more clean than using utilities your grid has zero media queries in it, which means whatever grid classes you were using before were not responsive - which is where 90% of the complexity lives. complex/nested responsive grids are not simple, unfortunately. i've made one, too: https://github.com/leeoniya/flecks https://github.com/leeoniya/flecks
  - nitely 7y ago
    > complex/nested responsive grids are not simple, unfortunately. How does utilities make complex/nested responsive grid simple, again? I'm arguing semantic css is simpler than using utilities all over the HTML, not that it magically makes responsive design easy. > your grid has zero media queries in it, which means whatever grid classes you were using before were not responsive - which is where 90% of the complexity lives. There are some in the examples [0][1]. Both for responsive design and nested grid, sadly not for both at the same time. It's not much more complex, though, well I guess it depends on how complex are we talking about. Anyway, CSS Grid makes semantic layout a lot simpler now. [0] https://github.com/nitely/semantic-flex-grid/blob/gh-pages/sass/styles.scss#L59 https://github.com/nitely/semantic-flex-grid/blob/gh-pages/s... [1] https://nitely.github.io/semantic-flex-grid/ https://nitely.github.io/semantic-flex-grid/

tylerjwilk00 7y ago

So long as structure and design overlap there will always be some inescapable coupling. The choice is deciding which one should master over the other.

jacurtis 7y ago

The ultimate anti-pattern of this philosophy is Tailwind.css (the newest, "coolest" css framework). Not trying to hate on it, but I find it ironic that the whole point of Tailwind is that you can basically style your entire website within the HTML, without needing to customize it with CSS. For someone who learned CSS during the CSS Zen Garden era where we were told to only use the HTML document for structure and never style, it makes Tailwind cringe-worthy. Yes, I know lots of people customize it and stuff, but the idea still stands that 95% of styles are done within the HTML document through tens of thousands of ultra-specific css classes which basically just tweak a single css property.

adamlett 7y ago
The gospel of separating styling from content comes from an era when most web sites were comprised of collections of hand crafted HTML documents, when it was a pain to make site wide changes to styling because it meant updating each of these documents by hand. These days web sites are mostly comprised of HTML pages rendered on the fly by some type of web app which composes pages from nested templates injected with content from a database. In this scenario separating the styling from the markup gains us little, because to change the styling site wide you only have to update a few templates, not every single page that uses these templates.
Ayesh 7y ago
Totally agree with this. It's faster to prototype with Tailwind though, if you remember the class names well.
- jfengel 7y ago
  Unfortunately, prototypes are rarely thrown away. Prototypes become production code, because code that works is usually more important than code that's clean. Cleanliness comes with refactoring. And that's actually OK, most of the time. In some situations you have to be certain you get it right the first time, but the web encourages you to try, deploy, and fix later. It's messy and has long-term debt, but a lot of that debt rarely comes due. You might just be the one holding it when the bill comes in, and that's no fun, but people do this because on the whole the amortized cost is less. Just don't fool yourself into thinking that this is just the prototype. Unless you have specifically allocated resources to throwing it out and starting over, acknowledge from the beginning that this is going to be production code. That way you make fewer of those "Oh, well, it's a prototype" decisions. Not zero, just fewer.

jguffey 7y ago

I've long thought about this too. Eventually I've come to the conclusion that CSS Zen Garden was more about "Hey you can do all of this with pure CSS" than it was "You should do it this way". At the time that I discovered Zen Garden, CSS was in it's more early, primitive days. As a front-end developer, it was easy to say "I can't achieve this design without changing the HTML Structure". Zen Garden showed us that this was just an excuse, (just about) any design could be achieved without a requirement to fundamentally change the HTML of the page. It was eye-opening to see some of the ways theme authors rearranged content, broke down those box boundaries, and used design tricks that stretched the limits of CSS and HTML in that era. It was awfully inspiring, and I think the point was never - "this is the way you should encode pages" it was more about taking excuses away.

regularfry 7y ago
The point absolutely was "this is the way you should encode pages", or rather "this is what is possible if you encode pages this way". The purpose of Zen Garden was to highlight the separation between style and content; that separation is why we've got CSS as a separate language to HTML in the first place.
jtms 7y ago
No, it was absolutely about the way you should "encode" your pages. I would choose the word "markup" here instead as that's what it is, but it was 100% a recommendation on the benefits of separation between markup and presentation.
bluetwo 7y ago
Or, was it to prove that yes, you can live without Flash.

bromuro 7y ago

Well I think it went that way because CSS is lot of frustration and not much zen.

crispyambulance 7y ago

> ...in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually. Part of the blame for this has to fall onto the lap of CSS itself. Up until CSS-grid it has been too damn hard to get layout to "just freaking work" with CSS. To be fair, it was even more of a dumpster fire back in the early naughts when almost everyone just used HTML tables to do their layouts. The folks behind CSS should have caught on at that time and focused on making layout better and eliminate thousands of person-years of frontend people grinding their gears... BUT NO, not until 2018-ish did we get CSS-grid.

pjmlp 7y ago
And ironically CSS-grid was born as part of WPF's Grid component.
- crispyambulance 7y ago
  Not surprising at all. The desktop application world has long enjoyed relatively fuss-free layouts. Java swing had nice layout mechanisms too. MIG-layout comes to mind.

lazyjones 7y ago

People are far too concerned with these things anyway, IMO. All ways work well enough and perhaps I'm just ignorant, but in the past 25 years I haven't seen a single good example of a situation where someone won against the competition because of better presentation or better choice of frontend framework. That excludes those who shot themselves in the foot with Flash though. IOW, put the effort into backends / core functionality and not elegant styling or elaborate frameworks.

wdb 7y ago

Personally, I find the mixes of class names like with Tailwind really confusing and need to keep looking it up when using it. Doesn't really make things easier imho

hcarvalhoalves 7y ago

Because every 10 years you have people who haven't been around for the past 20 years (re-?) inventing things.

mightybyte 7y ago

For awhile now I've felt that the CSS libraries like Bootstrap, Semantic UI, etc are never the "right" way to organize your markup and CSS for a large project. They're great for getting out something quick and dirty that looks decent. But once your project passes a certain scale (in size or time spent maintaining it), the balance shifts in favor of semantic markup and style in CSS using BEM or something similar as an organizational paradigm. The latter just doesn't seem conducive to off-the-shelf styles because semantic organization is different for every project. Another way of thinking about it is that CSS libraries build infrastructure for universal reusable widgets. In the beginning of a project it makes sense to build your app by putting together these building blocks. But as time goes by and the app grows, you start to develop a layer of higher level UI abstractions that are specific to the domain of your app. And when that happens it is often in conjunction with some kind of a re-styling and the old universal building blocks are no longer what you want. I've seen multiple large frontend projects go through these phases, and am starting to see them as a natural evolution of frontend projects.

lmm 7y ago

It's a failed experiment. We've had over a decade of people trying to use CSS to style websites and ending up with worse results than if they'd just changed the HTML. Let it die.

arvinsim 7y ago

Funnily enough, styled-components in React does allow me to focus on the semantics meaning without worrying about the style.