To me an evident thing in UI development is that separating stylesheet from layout isn't really a thing anymore and the benefits of this separation aren't really that clear.
Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work.
So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?
I work as a web developer for an enterprise-level software company.
Experimented a bit with CSS-in-JS, which is designed to get rid of this separation, and I found it to ultimately be harder to maintain than SCSS. This process was also what got me hooked on BEM after being initially pretty skeptical about whether it had any real value.
I now believe that BEM would meet the needs of most teams, with the exception of a few massive software houses like Facebook. And most companies don't fall into the Facebook category, even if they think they do.
I've also taken some time to reflect on older companies I've worked for, particularly some work I did at Oracle, which was for a reasonably large team spread across several continents. I think BEM would have been good enough for us there as well.
I would propose the following test: Is your front end in a monorepo? If so, BEM is probably good enough to solve any problems with scope and style conflicts. If your code can fit in a monorepo, I think its unlikely you will ever have a legitimate reason to duplicate a component name in multiple places.
Take it or leave it, just my experience, I'm sure other people would advocate different things. But it's by no means a settled debate, different people/orgs have come to different conclusions. It's just that one side writes a lot more blog posts.
I've written a series of very similar articles, and seeing as some of the ones in this site don't seem to be available yet, and otherwise as another point of view, they may be of interest to anyone looking at this: https://ctidd.com/2017/css-ui-patterns/content
Saw this awesome project on Lobsters. I went ahead and ported these components to generalized, composable Styled Components. There's also an npm package at `every-layout`.
Margins of flex child elements won't collapse automatically like regular elements. It can be solved but it would be unnecessarily complex for the simplicity of the layout.
Because it's a just a simple stack. The intent is concistent margins between siblings within the wrapper. What came to mind were paragraphs. Or perhaps images. Or both?
If other browsers besides Firefox add support for the gap property, Flexbox will be perfect for this. The owl approach has some subtle issues, like not taking into account elements which show/hide based on breakpoint.
started reading some of the ideas and got put-off almost immediately. 'margin-top'? the owl-selector? Really? Why do we keep making our life more difficult than it should be? CSS is such a beautiful and interesting tool, yet we still decide to misuse it in trying to be too smart.
(
margin-top: you start dealing with parents inheriting the margin - which is an old quirk of CSS - it's a side-effect you need to control, so the usage of margin-top should always be avoided and margin-bottom should be the preferred solution
owl selector: performance implications - it's fairly bad from a performance POV to use it. Also, we live in a world where we have control over how the layout is generated, we should avoid using generic selectors
Source: I've been doing frontend and focused on CSS for over 10 years
)
The owl-selector can actually be quite elegant, but becomes a burden if you have lots of side-by-side blocks (which would always need to set their margin-top to 0).
It never scaled terribly well in its original state, and with every iteration became more bloated, so we came up with methods of controlling the sprawl; but imo glut of Modern CSS Implementations and their many and varied permutations not only feel like they are not only fighting against the original concepts, but also against each other.
Which isn't to say they're bad or anything, but simply that CSS is old, everything else has changed dramatically, its probably time we went back to the drawing board.
Having been doing full-stack for over 15 years now, I have never seen the owl selector before. It's almost a perfect solution to a problem I regularly have.
A quick google didn't reveal any browser support for it though. Anyone got a resource for that? I can see that the adjacent selector is supported on 98% of global browsers, but I would not be surprised if there were some issues combining it with * +
It's worth noting that * is incredibly inefficient, especially near the front of your selector, because of how the browsers generally handle element styling. It may be better now than in the past, but it's best to avoid it for the most part.
The knowledge contained in the articles is very good but I got the feeling that it was written for an audience that already undertands the problems being solved. The Stack for instance is written in a language that only really makes sense if you've spent a lot of time with CSS and contains some extraneous paragraphs. I only mention this as the problems and solutions being explored are very valuable to learn but I think it could be written simpler and more succinctly so that meaning isn't lost for new-comers.
I'd be happy to contribute if it was open to suggestions.
This website is one of the accessiblest things (for screen readers) out there. I have never seen alt text for layout images. This is well beyond amazing.
I have heard lots of good about "CSS in depth" by Keith J. Grant. It explains why and how CSS does things, rather than just telling you to do one thing for that use case, and another thing for that use case. It is meant for people who already know a bit of CSS, but it wouldn't be too hard to learn the basics of CSS first then read this book. Also, it is free online on the publishers page, which is extremely generous of him and the publisher.
It's probably not for everyone but I just read the specification [1] last week. It is probably also worth noting that I did this to get a better understanding of some details and not for initially learning CSS. But those are mostly easy to read specifications and I think one could use them to initially learn CSS.
CSS level 1 is pretty short but will still teach you a big chunk of the fundamentals of current CSS even though it is more than 20 years old. After that you can focus on the changes and additions in later versions - those newer specifications are a lot more technical and precise and cover a lot more features, so they are also longer and less fun to read from cover to cover.
CSS is completely dependent on HTML. If you write poor HTML - then you've already shot yourself in the foot. If you can't learn them together - then it's really hard. People don't learn the different display types / or positioning, and then they freak out when they can't figure out why a margin-top isn't working on their inline element. I've never met anyone I consider to write decent markup or styles in any of my jobs. This is pretty good: https://maintainablecss.com/chapters/introduction/ - but it doesn't teach you CSS. It teaches you how to write maintainable CSS. MDN is the best we've got (so far)
There is more than way to do all of these layouts. I don't have time to learn all of them, I just want my content to look great on all devices. I also want to stick to the specifications of HTML as it applies to all the browsers that do HTML5 - so no Internet Explorer. Sticking to the specs means no hacks and the likelihood that someone can make sense of my code in ten years time and not think 'why did they do this?'.
For this reason I will be sticking with CSS Grid. CSS Grid is supported in all HTML5 browsers, so that means everything except the depreciated Internet Explorer.
To get my CSS Grid versions to work I will also be using CSS Variables defined in media queries to make things responsive. I don't need to have lots of fixed breakpoints as I use fonts that scale in such a way that lines don't get too long to read on really big screens.
For the CSS variables I have fallbacks which are the desktop defaults. So although 'mobile first' I can get a deluxe mobile experience but code for desktop in the first instance.
With pseudo classes I can add icons, usually Unicode symbols or SVG, SVG defined in CSS variables.
Since I can do this with CSS Grid and only have Internet Explorer be 'of concern', I can write HTML5 with no superfluous markup. That means no div, span or even class attributes. I have got out of the mindset of using container wrappers for content and just putting neat content where it needs to go using CSS Grid.
You could look at my HTML and think I had just swapped the div for article, aside and section. Or for figure. Or for main, header and footer. But that is not the case, I find that if I am using the right elements and pay attention to the structure of my content it just naturally styles itself with CSS Grid, no additional markup needed.
Also not needed are clever things with calc. If I find myself doing that then it is a sign that I have got it wrong and that there is a simpler solution I have overlooked. I also rarely use pixels. It is ems or viewer units all the way, again no need to think of what a pixel actually is.
I find that writing HTML and styling it without the hacks makes my code pretty alien compared to how the rest of the world is doing it. Anyone can make stuff complicated for reasons of backward compatibility, keeping it concise and simple is a different craft.
For the above reasons I am disappointed by these layout modules, a lot of work has gone into it but at times we need to question what we take for granted. Everything is a div. I look at the examples and see that if, e.g., the image is put in a figure and given a figcaption then the structure is there for it to effortlessly be given layout with CSS Grid, no container elements needed.
At some stage we need to stop looking at content as placeholder examples and stop using generic containers.
> if I am using the right elements and pay attention to the structure of my content it just naturally styles itself with CSS Grid
Why is that? Does Grid treat 'article'and 'section' differently than it treats plain 'div'?
I thought that the purpose of 'article' etc. was purely semantic, saying something about the meaning and purpose of content inside them, not how they should be laid out on the page.
"Web browsers helpfully apply default CSS styles..." Totally disagree with the idea that this is 'helpful.' Pretty site though. I think there's some good stuff here - but it's not how I'd teach it. Side-note: I love how wappalyzer says 'zero technologies detected.' That's rad. "Each layout in Every Layout is intrinsically responsive." Everything is intrinsically responsive before you force it not to be. Big respect for tackling this though. Lots of good stuff and just a bit of maybe not great stuff.
>The Cluster layout is available in the full version of Every Layout, which is still in production. All of the currently available layouts are marked "read now" in the index page.
Poor quality articles. They use flexbox and provide no fallback for older browsers. They could use at least non-responsive layout for desktop resolution for older browsers. Probably the reason why they didn't do it is lack of knowledge of CSS.
IE11 is meant for supporting legacy sites and Microsoft doesn’t recommend consumers to use it. It make sense to work on Grid and Flexbox for new sites.
Maybe their target audience doesn't primarily consist of entry-level devs relegated to maintaining legacy eCommerce web properties and back-office portal/intranet systems?
The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this.
Rem units can cause issues in long term. For example, imagine if a sidebar widget is coded using rems. When later the main font size is changed, margins within widget will change its size, although the font size in it is fixed and didn't change. There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. He just uses his authority to push his personal preferences to frontend developers who tend to copy the code from tutorials without much thinking.
I recommend using pixels for projects that are going to be maintained and developed in the long term.
[+] [-] sktrdie|6 years ago|reply
Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work.
So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?
[+] [-] danShumway|6 years ago|reply
Experimented a bit with CSS-in-JS, which is designed to get rid of this separation, and I found it to ultimately be harder to maintain than SCSS. This process was also what got me hooked on BEM after being initially pretty skeptical about whether it had any real value.
I now believe that BEM would meet the needs of most teams, with the exception of a few massive software houses like Facebook. And most companies don't fall into the Facebook category, even if they think they do.
I've also taken some time to reflect on older companies I've worked for, particularly some work I did at Oracle, which was for a reasonably large team spread across several continents. I think BEM would have been good enough for us there as well.
I would propose the following test: Is your front end in a monorepo? If so, BEM is probably good enough to solve any problems with scope and style conflicts. If your code can fit in a monorepo, I think its unlikely you will ever have a legitimate reason to duplicate a component name in multiple places.
Take it or leave it, just my experience, I'm sure other people would advocate different things. But it's by no means a settled debate, different people/orgs have come to different conclusions. It's just that one side writes a lot more blog posts.
[+] [-] ctidd|6 years ago|reply
[+] [-] aarohmankad|6 years ago|reply
https://github.com/aarohmankad/every-layout
[+] [-] vedantroy|6 years ago|reply
[+] [-] have_faith|6 years ago|reply
[+] [-] chiefalchemist|6 years ago|reply
[+] [-] threehams|6 years ago|reply
[+] [-] btbuildem|6 years ago|reply
[+] [-] codedokode|6 years ago|reply
[+] [-] sureaboutthis|6 years ago|reply
[+] [-] razvandh|6 years ago|reply
( margin-top: you start dealing with parents inheriting the margin - which is an old quirk of CSS - it's a side-effect you need to control, so the usage of margin-top should always be avoided and margin-bottom should be the preferred solution owl selector: performance implications - it's fairly bad from a performance POV to use it. Also, we live in a world where we have control over how the layout is generated, we should avoid using generic selectors Source: I've been doing frontend and focused on CSS for over 10 years )
[+] [-] Atomskun|6 years ago|reply
Not really if you consider sibling layouts, e.g.: https://matthewjamestaylor.com/css-margin-top-vs-bottom
> owl selector: performance implications - it's fairly bad from a performance POV to use it.
Arguing about "CSS performance" is futile when the real cause of bloatedness is mostly JavaScript these days (also: http://alistapart.com/article/axiomatic-css-and-lobotomized-...).
The owl-selector can actually be quite elegant, but becomes a burden if you have lots of side-by-side blocks (which would always need to set their margin-top to 0).
[+] [-] gary__|6 years ago|reply
I would prefer that browser compatability is mentioned, for my own purposes that would be IE11.
Perhaps set a baseline of what browsers are considered in the intro and then highlight deviance as it occurs.
[+] [-] andrei_says_|6 years ago|reply
Yes, it is float based but my code is at the correct level of abstraction.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] meerita|6 years ago|reply
[+] [-] emmanueloga_|6 years ago|reply
* https://tailwindcss.com/
* http://tachyons.io/
[+] [-] gitgud|6 years ago|reply
Initially they're frustrating, but after awhile you recognise the ease and predictability of styling reusable components.
[+] [-] GoToRO|6 years ago|reply
[+] [-] vast|6 years ago|reply
[+] [-] ry_ry|6 years ago|reply
It never scaled terribly well in its original state, and with every iteration became more bloated, so we came up with methods of controlling the sprawl; but imo glut of Modern CSS Implementations and their many and varied permutations not only feel like they are not only fighting against the original concepts, but also against each other.
Which isn't to say they're bad or anything, but simply that CSS is old, everything else has changed dramatically, its probably time we went back to the drawing board.
[+] [-] deanclatworthy|6 years ago|reply
A quick google didn't reveal any browser support for it though. Anyone got a resource for that? I can see that the adjacent selector is supported on 98% of global browsers, but I would not be surprised if there were some issues combining it with * +
[+] [-] tracker1|6 years ago|reply
[+] [-] have_faith|6 years ago|reply
I'd be happy to contribute if it was open to suggestions.
[+] [-] miki123211|6 years ago|reply
[+] [-] sam0x17|6 years ago|reply
[+] [-] victor106|6 years ago|reply
[+] [-] macando|6 years ago|reply
https://flexboxfroggy.com/ https://codepip.com/games/grid-garden/
I wish all learning was this fun.
[+] [-] wallmountedtv|6 years ago|reply
https://www.manning.com/books/css-in-depth
[+] [-] danbruc|6 years ago|reply
CSS level 1 is pretty short but will still teach you a big chunk of the fundamentals of current CSS even though it is more than 20 years old. After that you can focus on the changes and additions in later versions - those newer specifications are a lot more technical and precise and cover a lot more features, so they are also longer and less fun to read from cover to cover.
[1] https://www.w3.org/Style/CSS/current-work
[+] [-] runarberg|6 years ago|reply
[+] [-] sheriffderek|6 years ago|reply
[+] [-] azangru|6 years ago|reply
(https://www.amazon.co.uk/gp/product/B076HZSWTM/)
[+] [-] scns|6 years ago|reply
[+] [-] sureaboutthis|6 years ago|reply
is all anyone needs except the standard itself.
[+] [-] Theodores|6 years ago|reply
For this reason I will be sticking with CSS Grid. CSS Grid is supported in all HTML5 browsers, so that means everything except the depreciated Internet Explorer.
To get my CSS Grid versions to work I will also be using CSS Variables defined in media queries to make things responsive. I don't need to have lots of fixed breakpoints as I use fonts that scale in such a way that lines don't get too long to read on really big screens.
For the CSS variables I have fallbacks which are the desktop defaults. So although 'mobile first' I can get a deluxe mobile experience but code for desktop in the first instance.
With pseudo classes I can add icons, usually Unicode symbols or SVG, SVG defined in CSS variables.
Since I can do this with CSS Grid and only have Internet Explorer be 'of concern', I can write HTML5 with no superfluous markup. That means no div, span or even class attributes. I have got out of the mindset of using container wrappers for content and just putting neat content where it needs to go using CSS Grid.
You could look at my HTML and think I had just swapped the div for article, aside and section. Or for figure. Or for main, header and footer. But that is not the case, I find that if I am using the right elements and pay attention to the structure of my content it just naturally styles itself with CSS Grid, no additional markup needed.
Also not needed are clever things with calc. If I find myself doing that then it is a sign that I have got it wrong and that there is a simpler solution I have overlooked. I also rarely use pixels. It is ems or viewer units all the way, again no need to think of what a pixel actually is.
I find that writing HTML and styling it without the hacks makes my code pretty alien compared to how the rest of the world is doing it. Anyone can make stuff complicated for reasons of backward compatibility, keeping it concise and simple is a different craft.
For the above reasons I am disappointed by these layout modules, a lot of work has gone into it but at times we need to question what we take for granted. Everything is a div. I look at the examples and see that if, e.g., the image is put in a figure and given a figcaption then the structure is there for it to effortlessly be given layout with CSS Grid, no container elements needed.
At some stage we need to stop looking at content as placeholder examples and stop using generic containers.
[+] [-] galaxyLogic|6 years ago|reply
Why is that? Does Grid treat 'article'and 'section' differently than it treats plain 'div'?
I thought that the purpose of 'article' etc. was purely semantic, saying something about the meaning and purpose of content inside them, not how they should be laid out on the page.
[+] [-] taivare|6 years ago|reply
[+] [-] sheriffderek|6 years ago|reply
[+] [-] PyroLagus|6 years ago|reply
> At the time of conceiving the axiom, you make not have pictured this specific visual effect.
I'm pretty sure it should be "may" instead of "make".
[+] [-] sergiotapia|6 years ago|reply
>The Cluster layout is available in the full version of Every Layout, which is still in production. All of the currently available layouts are marked "read now" in the index page.
where is production? I can't find it
[+] [-] dmitriid|6 years ago|reply
[+] [-] codedokode|6 years ago|reply
[+] [-] majewsky|6 years ago|reply
[+] [-] proyb2|6 years ago|reply
https://inclusive-components.design/
IE11 is meant for supporting legacy sites and Microsoft doesn’t recommend consumers to use it. It make sense to work on Grid and Flexbox for new sites.
[+] [-] chiefalchemist|6 years ago|reply
[+] [-] plausibilities|6 years ago|reply
[+] [-] robdachshund|6 years ago|reply
[deleted]
[+] [-] codedokode|6 years ago|reply
Rem units can cause issues in long term. For example, imagine if a sidebar widget is coded using rems. When later the main font size is changed, margins within widget will change its size, although the font size in it is fixed and didn't change. There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. He just uses his authority to push his personal preferences to frontend developers who tend to copy the code from tutorials without much thinking.
I recommend using pixels for projects that are going to be maintained and developed in the long term.