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.
To me what is cringe-worthy is hanging on to ideas about what this medium is that just no longer apply. For better or worse, the web stack has been appropriated into an application framework. I am not making documents that have styles applied to them. It's just not a metaphor that works anymore.
The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way. Maybe for some parts of your app, you can maintain this separation of you try, but it's not something that adds any value at all. Even if it could work, there would be absolutely no reason to try. The type of redesigns I do on this type of code affects HTML, Javascript and CSS equally, always.
Tailwind, to me, solves a bunch of very real ergonomic issues when working with large web applications, and results in far clearer code.
This is orthogonal to the issue. It's still possible to separate the functional layers of a website or application, even if the entire stack is JS or whatever.
I don't see how single page apps invalidate the base concept of separating data, structure, and styling into separate layers, regardless of the format or code language of those layers.
In the old days, website were primarily documents, and as browser formatting grew more sophisticated the ratio of content to styling markup grew lower and lower, and when you're formatting simple documents the amount of redundant styling is very very high. Because HTML was designed with a small number of elements that provide pretty good coverage over basic documents, and because most documents were created by hand, the original CSS design and philosophy behind CSS Zen Garden was an absolute slam dunk for content creators of the era. The assumption is a small amount of CSS covers styling for a huge library of markup documents, minimizing overall code size.
As web apps evolved to be more dynamic, first with bits of AJAX and then graduating into full SPA with more and more functionality ported to client-side APIs, we found the semantics of HTML which were tied to more universal concepts of written documents (heading, paragraph, list, quote, etc) did not cover the semantic needs of describing UI widgets. At this point CSS is still useful but the optimal structure is not as obvious. Essentially there are two extreme approaches: 1) create very specific markup for each UI element, which optimizes markup size and clarity, but leads to a huge amount of duplication of CSS; or 2) create UI-oriented classes that are then tacked onto a dense tree of nested divs, which optimizes CSS size and clarity, but leads to markup bloat and "class-itis".
This fundamental problem was attacked from many different angles, lots of code generation, web components, OOCSS, BEM, Sass, etc. I consider Nicole Sullivan's work in this area to be seminal, leading to the optimal approaches large web products use at scale, and directly informing the design of React and modern SPA approaches. The reason Webpack processes markup, css and javascript all together is because things are so tightly coupled in practice, that you need tooling to optimize overall code structure and legibility. Purist approaches don't work very well for large projects because HTML & CSS were not designed to build GUIs.
Really, only two approaches are viable? There's no middle ground here? What would be the point of highlighting the extremes?
It's as if the entire tech industry has lost the ability to tell a designer to sit down and come up with a basic typography set and color palette even. Obviously you can't just create the entire style sheet set in one pass, but can't there be an iterative approach rather than throwing the entire thing out and building giant systems just to let picky designers pointlessly tweak small pieces of the application, in isolation?
What does a complex, "dynamic" widget have to do with not using standardized typography and colors in your application? Once you start there, can't you just evolve the styles to meet product needs? It just seems to me that 99% of the time, the point where it's decided that this whole thing should be thrown out, is almost always the point where someone wants to put "built a component system" on their resume...
Another grey area:
>create very specific markup for each UI element
vs.
>create UI-oriented classes
There's another middle ground here where you just have really big CSS selectors, and many things share styles, while still pointing to structure-oriented html classes. Can you achieve a middle ground better than individual styling, without resorting to UI-classes?
div's should be avoided. Use semantic elements instead! If you absolutely need them you should consider making a custom element instead. (with it's own base CSS).
It does not. But using utility-first frameworks like Tailwind doesn't mean you're not separating things. It just means you're not separating things in CSS files. You have the Tailwind setup (which allows you to customize colours, spacings, etc.) and the functionality of whatever component framework you're using. The point is that in the context of SPAs, "styling" (visual presentation) is not limited to CSS.
I've heard different forms of this argument for decades in dozens of systems. Same old "why pay for abstraction" argument. I'm not going to answer. Either you figure out the answer or you don't.
And xml-based markup was just never a good format for that. The concept lives on in markdown, and in CMSs like WordPress, where an author creates content in a common format that is styled based on site- and page-specific rules
No one wants to write in html. If you’re working in html directly, it’s probably because you’re building something more complicated.
(If any of those assumptions are wrong, tell me! I’d love to hear a counterargument on why pure html is a great format for producing content!)
Using a framework like tailwind does _not_ affect whether your actual HTML elements are semantic, which is what would affect accessibility.
The separation of concern that actually makes sense, and on which we ended up, is structured data (JSON) piped into a presentation layer (SPA lib like React). That's what XML tried to do before it became gimped as HTML.
If you look at other document writing system such as LaTeX. You will see that there are Sections, SubSections etc.
The link to the CSS simply told the browser how these should be presented. LaTeX has something similar as you can create a document class and Word has different styles you can import.
Having a concept of a document structure with a set of styles attached which you can change easily is a good idea.
The HTML document should make sense without a style sheet and if you write/generate semantic markup it does work properly.
I disagree. Unlike JSON which is truly presentation agnostic, the position of the HTML elements always did affect the layout and some designs were pretty much impossible to achieve without having to move HTML elements around. Despite the popular claim to the contrary, HTML was always part of the presentation layer.
The results you see on CSS Zen Garden show that this is not true at all. It was hard, but not impossible then and nowadays grid layout and CSS3 fixed a lot of the issues.
Oh great let me get right on that. Wait, no, I have far more important things to do with my time.
Have you deliberately ignored the rest of the sentence? CSS3 and display grid solved a lot of the issues. It is supported by any modern browser.
Leveraging grid layout makes for a complete separation of concerns and still keep semantic markup without any hacks that only add to the amount of work. Take just a couple of hours of your very important time to learn it, and you might see the payoff.
Also, just anecdotal: I am working on a Vue.js component which I want people to customize the styling however they want. This is forcing me to drop the CSS part of the components. I am not adding any cruft HTML and yet I did manage to get a "basic" theme and a good chunk of the "materialize" look already. Two themes, two separate SASS projects. It can be done.
You are complaining about the wrong thing.
> Despite the popular claim to the contrary, HTML was always part of the presentation layer.
Not at all. It is document format. Designs that do not respect that doesn't change it's intrinsic nature.
This is like complaining that a shoe isn't a very good mallet.
That's not entirely true. Even ignoring the elements that were explicitly about formatting and have since been deprecated, the order and nesting of elements could have a profound effect.
For example, the entire model for how to do layout using CSS floats fundamentally depended on the order of elements in the source HTML document. It wasn't until much later that CSS finally added tools like flexbox and grid where you could explicitly reorder the content from multiple source elements in the rendered output using CSS alone.
Even today, certain effects such as column-based formatting for a table are much easier to specify in CSS if your HTML has additional elements such as <colgroup> included, yet there is little reason to include such elements in the markup except to support that kind of formatting.
Yes a table will need to have the correct elements in the right order. This isn’t presentational it is semantic.
HTML5 does this better than HTML 4 as it has more semantic elements as a response to the more complicated layouts of modern web pages.
Abstracting out CSS into utility classes can make it much quicker to get a consistent looking site up while still giving you a little more control over the look and feel. Of course you can misuse this but I think people who don’t understand standard CSS make a much bigger mess of it than if they have something like Tailwind.
https://adamwathan.me/css-utility-classes-and-separation-of-...
CSS was explicitly designed not to be Turing complete. Had DSSSL been the choice twenty years ago, we might not be constantly twisting in the wind for a better paradigm.
1: https://adamwathan.me/css-utility-classes-and-separation-of-...
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.
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.
Tailwind allows you to "feel" like you're just quickly prototyping, without afaict compromising maintainability at all.
If you're concerned about the ability to reuse an HTML fragment and associated styles (or just a bunch of styles), they have decent docs on that: https://tailwindcss.com/docs/extracting-components/
Fred Brooks' admonition to plan to throw one away almost never happens. Instead more and more features are force fit onto the prototype.
For CSS/HTML, speaking of Fred Brooks, this is an essential complexity, the tension between style and content.
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.
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".
I had the opposite experience. I've build a few projects with Tachyons and Tailwind, and I rarely have to create custom CSS. In one of the largest ones (that actually had a 100% custom UI toolkit with over 40 widgets) we only had about 120 lines of custom CSS, pretty much just overriding colors and adding some utility classes for animations, custom drop shadows and some weird hover states.
The reason we need so little extra CSS that is that those frameworks use the same defaults that designers use: everything is a multiplier of 4px/8px, font sizes are proportional, and it follows design principles. Actually, if you work with a designer chances are most of your CSS is already very repetitive, because designers love patterns.
It goes against what CSS was supposed to do and generally the results are IMO hard to work with because you have the overhead of having to learn how the framework works rather than just using the fundamental principles of what you are working with. Also the markup is horrendous to read.
With modern CSS you are given so much control. Your style-sheets aren't complicated anyway.
But that's for my own projects I work on as a single dev, in a team I might not mind as much. For something corporate, unless it's a corporation I can really get behind, I will not care at all, because I know it'll be thrown away soon. Let's make it bland then, I don't mind. But for my own things, it's not even a consideration.. I don't even start with a reset stylesheet, I start with a blank file, and I enjoy thinking up the overall structure just as much as I enjoy tweaking values here and there, and I still like things I made over 10 years ago. Care for the little things always ends up showing, somehow.
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?
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.
I really should write something on forgotten simpler CSS / JavaScript techniques.
Bootstrap does this on some components but it has loads of positional bits and pieces mixed. Also the components are fairly generic.
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.
<div style="display: table;">
<div style="display: table-row;">
<div style="display: table-cell;">
</div>
</div>
</div>
We are in similar egregious territory now days with how we’re doing styled components directly in the javascript and totally forgoing some of the principles of CSS (we are effectively in-lining styles , for everything). That’s alright, we go through this upending in frontend every 3 years anyway.
If that weren't bad enough, let's discuss the fundamental core of the web: links.
Links are dead. They are buried under a mountain of SPA walled garden jank, teased at (but never granted) on Pinterest or Quora or LinkedIn or Facebook, or out there scamming users with shortened URL services. Corporate users are subjected to annual security training lessons where they are taught never to trust links (email, text message, or otherwise) because the alternative, training users to understand domain names, is just so impractical that we have all given up. Google gave up, with Chrome. They don't even want to show a domain. It's that bad and awful.
To give you an example of how shit it all really is, I recently had to look up an issue related to a Microsoft product. A quick Google search lead me to a number of Stackoverflow and blog posts on the issue. I found a number of links, pointing to Microsoft's bug tracker (links from just a year or two ago). And here's the kicker: all the links 404. The bug tracker is simply not there anymore. This is Microsoft we're talking about. They have given up on links. They have so given up on links that they can't even be bothered to let the user know what happened to those links.
Things are significantly worse on the mobile web. I would estimate that a good 90% of the web doesn't work on mobile in any sort of way that would delight a user. It's more that users just deal with this massive pile of shit. Watch someone use a mobile web browser sometime. Watch the nonsense they have to deal with. The janky-ass scroll popup sluggish ad-infested dumpster fire. All of it.
Hence each website tries to create their own app. Users are drawing in apps that track every move they make and batteries do not keep their charge even to make an emergency call.
And for what it's worth, NetObjects still exists - http://netobjects.com/
<table type=for-display-only ...>In any case, you might just as well decide the table was a list item or headline then, right? So you would need
<table what-i-actually-mean="ol">...First, one of the reasons HTML has been as successful and widespread as it has been is that mere mortals are able to use it, not just trained software engineers and designers. Mere mortals may not make such decisions on a lark, but they might make the decision incorrectly and have to go back and change it for that reason. Why make more work for yourself than necessary?
Second, making changes is not the only reason to make code DRY. Re-using TR and TD tags is analogous to operator overloading. If you want to add two numbers you want to be able to write x+y and have the compiler figure out whether that means an integer add, a floating point add, etc. You don't want to have to write (say) x II+ y if you want to add two integers, x FF+ y to add two floats, x LL+ y to add two longs, etc. It's the same for table rows and cells. The mental distance between tables-for-layout and tables-for-structure is smaller than the mental distance between integers and floats. It's just annoying to have to keep telling the computer over and over and over again "this is for layout" or "this is for structure" particularly in a case where the number of repetitions can be very, very large. There is no value add in forcing someone to do substantially more typing when the thing being typed contains no additional information that the system does not already have.
I have a hard time understanding this scenario. What kind of content are you working with?
The hypothetical <table-for-layout> element is just not needed in any scenario. It would have been useful back in the day before IE supported display:table, but that is at least a decade ago.
I could just as easily say that the "problem of overloaded operators" only becomes a problem if you try to use + to add anything other than two ints. So don't do that.
But OK, assuming I accept the premise, what should I do instead? The CSS community has been dithering about the answer for years. Only very recently has there been anything even remotely approaching an acceptable solution i.e. a solution that actually reproduces table layouts without having to pile on a ton of hacks. In the intervening years, a lot of legacy code was produced that used <table> for layout because it was the only thing that actually worked.
There also the fact that <display-table><tr><td> or something like that just looks a lot cleaner and is easier to read than <div class=table-for-display><div class=table-row-for-display><div class=table-cell-for-display>. When you make complex table layout you end up with a lot of TR and TD tags, so it makes sense to keep those short to avoid cluttering things up.
You don't really need repeated class=table-row-for-display etc, this can be achieved by CSS contextual selectors.
But in reality html tables was not designed as an all-round layout tool in the first place and the layout algorithm was never specified in detail. Flexbox and flexgrid are typically more appropriate and powerful as layout tools.
I tried that once many years ago. It didn't work. It might work today but I no longer care.
> this can be achieved by CSS contextual selectors
That would be true if display:table worked, but it doesn't (or at least it didn't) and so it doesn't.
And you still need some markup for the contextual selectors to work on. The obvious choice is <table><tr><td>, or, if it existed, <display-table><tr><td>. Maybe <grid><gr><gd> but that's not going to happen.
Can you describe the problem you are having?
But my point stands even if display:table works nowadays. The problem is not what you have to type in order to specify that some piece of markup should be displayed as a table even though it is not semantically a table. What matters is how much you have to type, and whether you have to redundantly specify that a table is for display only on every row and cell. To use display:table you also have to specify display:table-row and display:table-cell, and you have to do it again and again and again and again even though all this information is redundant and only needs to be specified once at the top level. There is absolutely no rational justification for this. It would be as if you had to specify the type of a variable in C not just when it was declared, but again every single time you referenced it.
<table role="presentation" ...>
[edit] See https://www.w3.org/TR/wai-aria-practices-1.1/#presentation_r... for details
Abled people benefit from a system where their browser considers that div as "table-like" in the way content flows through it. Likewise, disabled people benefit from the fact that their screen-readers consider the div as a simple container without imparting any sort of tabular semantics ie expecting some data organized in rows and columns.
It will not surprise you to learn that this concept was not exactly well understood (to be fair, most things were not well understood, including js) and people started building all sorts of actual data tables out of divs with "display: table" applied, because apparently that's how you were supposed to do it.
Nowadays this is obsolete, of course, mostly thanks to flexbox but also grid.
The irony is it was completely against the original intention which is to use html to give semantic meaning to elements. Tabular data doesn't just have a visual layout, it is rows and columns. Most people still don't understand this today although with things like markdown people are doing it even if they don't realise (unless they start embedding html/css, of course).
Really CSS Grid does the same thing; there's just more in CSS now and it's a whole lot cleaner.
Here[1] is a revised edition of a book I read in 2006 about this topic how people often just replace all table elements with div elements and call it a day instead of using all the options CSS provides. Another topic was using all the tools the browsers with the best standard support gave you while still providing a more limited, but at least usable, version for browsers which hadn't implemented some features (yet). Even back then you could make pages which read well if CSS wasn't available and were visually appealing with CSS applied and today almost any browser has all these tools available.
[1] https://stuffandnonsense.co.uk/transcending-css-revisited - there's a free online version available
Sure it might be more elegant to do it with a stylesheet, but for a one-off situation it is not that bad.
There is a persistent attitude that presentational information in the markup is Bad and Evil. This is only partially true.
Misusing semantic html elements (like using <table> for purely layout purposes) is bad because it hurts accessibility for other people. But putting CSS directly in the HTML does not hurt anybody but yourself. If you do it all over the place it becomes a mess to maintain, but in particular cases it might be the simplest solution.
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.
And the thing is, even if you had a 16XX monitor, who wants to maximize a tool that you might be transcribing data in or out of? I might actually need two windows side by side to facilitate that work.
Wikipedia has this timeline:
> Cameron Adams created a demonstration in 2004 that is still online.[46] By 2008, a number of related terms such as "flexible", "liquid",[47] "fluid", and "elastic" were being used to describe layouts. CSS3 media queries were almost ready for prime time in late 2008/early 2009.[48] Ethan Marcotte coined the term responsive web design[49] (RWD)—and defined it to mean fluid grid/ flexible images/ media queries—in a May 2010 article in A List Apart.[2] He described the theory and practice of responsive web design in his brief 2011 book titled Responsive Web Design. Responsive design was listed as #2 in Top Web Design Trends for 2012 by .net magazine after progressive enhancement at #1.
And while the Garden was indeed around long before that, IMO it didn’t get properly cool until maybe ‘07. And once fluid and responsive came in it wasn’t keeping up.
The point, I thought, was to be able to send people there to learn, and I was afraid of having to fix that kind of smoke and mirrors in our production code so I stopped telling people about it, other than other seasoned UI people fora particular design, and half the time it was to laugh at one, not learn from it.
Wikipedia says the book came out in 2005, which if I remember correctly had plenty of colour pics inside. You don't get that kind of tech book unless you're already properly cool.
When I was first learning CSS I was trying to replicate a very easy 3 column layout where the middle column would grow and shrink with the screen and consist of multiple variable sized elements arranged neatly in a column. What should have been one of the most basic layout styles turned out to be quite a challenge to achieve with CSS. I wasn't even trying to have anything fancy like columns that disappear on super narrow screens. Just the most basic three column layout that didn't leave wasted space on the page. In my struggle to get it to work I went to sites like CSS Zengarden to figure out how they did it and was extremely disappointed to discover that they hadn't found the solution either. My thought was it couldn't be difficult because it was so easy to do with tables and literally everybody online was telling me that tables for layout were completely surpassed by CSS. Plus I was working with CSS 2, so any glaring deficiencies like this from CSS 1 would have definitely been fixed by then. I mean this was the point of CSS right? To do layout?
The first time I got to use flexbox in production (different project) I was happy as a pig in shit.
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.
IOW, put the effort into backends / core functionality and not elegant styling or elaborate frameworks.
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.
You can even swap out the web browser front-end, to an extent. I know that some mobile apps are done this way.
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.
Now these same people are mostly doing it for the paycheck. And there are a lot of new people doing it as well. In fact, dozens or hundreds of authors may be maintaining the same stylesheets. You just have to get your changes in.
People get older, begin to care less. The web has surrendered to commercial platforms. It's not as exciting.
It's better to give up on this ideal right from the beginning than to build something that ends up getting complicated with work-arounds and edge-cases.
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.
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.
I know this is still barely being used, but it's clearly the better way to go.
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
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/s...
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.
They had lots of selectors that were adjectives, and most of them composed. So you could have a class=“tiny button” or whatnot.
Let it die.
Things have simply moved towards what's actually manageable in a production environment, not what some ivory tower designer thought was good practice.
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.