
Relearn CSS layout - aarohmankad
https://every-layout.dev/
======
sktrdie
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?

~~~
danShumway
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.

~~~
meerita
Show us a pastebin of your compiled CSS. I can tell you from now your CSS is
bloated with the uncountable properties and classes that repeat the same fixes
and structures. You can program functional CSS and get better in way.

~~~
BurningFrog
But does bloated CSS matter?

If a human isn't going to read the CSS and the computer handles it without
performance problem, I say no.

Those are of course two quite important ifs!

~~~
meerita
It matters.

First, not all users need your huge CSS file, in terms of downloading.
Specially when they're on mobile phones and cache is crap.

A ~9000 rules CSS file will load and become COSSM slower than one that has
1000 or 10. It is linear increment. Make a test to see it for yourself.

A bloated CSS is more network time. Therefore, slower loading.

A bloated CSS will contain slower selectors, therefore slower rendering time
and painting speed.

When you count all these things, you will see radical speed performance.

~~~
BurningFrog
Maybe. You need to _measure_ these things and get a feel for the _actual_
performance impact to make informed decisions.

Rule 1 of performance: Your intuitions are _not_ reliable.

~~~
saidajigumi
Upthread, this commenter did post specific measurements from production
projects.

------
ctidd
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](https://ctidd.com/2017/css-
ui-patterns/content)

------
aarohmankad
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`.

[https://github.com/aarohmankad/every-
layout](https://github.com/aarohmankad/every-layout)

~~~
WA
You mean "React Components" right? Nice effort, but please mention that these
components are supposed to work with React. If we now use the word "Component"
as a synonym for React, you make it look like there are no other frameworks
than React.

~~~
osdiab
No, he meant Styled Components, a popular library for styling React
components.

~~~
WA
I see, didn’t know about this. Thanks for pointing it out!

------
vedantroy
Out of curiosity, why doesn't the stack layout use flexbox? It seems like
flexbox is the perfect fit for such a layout.

~~~
sureaboutthis
Flex is great for one directional layout within a box. It is not great for two
dimensions which most layout is concerned with.

~~~
nhooyr
The stack is not two dimensional.

~~~
sureaboutthis
Has nothing to do with what we're talking about.

------
razvandh
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 )

~~~
Atomskun
> so the usage of margin-top should always be avoided

Not really if you consider sibling layouts, e.g.:
[https://matthewjamestaylor.com/css-margin-top-vs-
bottom](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-...](http://alistapart.com/article/axiomatic-css-and-lobotomized-
owls)).

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).

~~~
ry_ry
I was suprised the degree to which selector performance is a negligible
overhead in normal use these days.

Was browsing through the docs for some Vue+CSS library or another recently,
and the author had done quite a lot of research into this, was interesting.

They were heavily using the square bracket html-attribute selector notation,
although I'm not sure if it performs better now, or if modern processors are
just that much faster.

------
gary__
This is great.

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_
Suzy grids 2 is an amazing tool for ie11 and everything above it. So I can use
one codebase for everything.

Yes, it is float based but my code is at the correct level of abstraction.

------
meerita
To me this way to CSS development is outdated. I will never program like this
anymore. I only do functional/utilitarian CSS.

~~~
emmanueloga_
NOTE: I think this refers to the approach implemented by libraries like:

* [https://tailwindcss.com/](https://tailwindcss.com/)

* [http://tachyons.io/](http://tachyons.io/)

~~~
meerita
Also: * [http://minid.net/2019/04/07/the-css-utilitarian-
methodology/](http://minid.net/2019/04/07/the-css-utilitarian-methodology/) *
[https://github.com/meerita/utilcss](https://github.com/meerita/utilcss)

------
deanclatworthy
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 * + _

~~~
tracker1
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.

------
have_faith
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.

~~~
gary__
Bear in mind the tutorial is prefixed "Relearn..."

Though I'd class myself as a "full stack developer" css for a long time was
the 2nd class citizen, with most of my time spent on learning to use front end
frameworks in their idiomatic way, the "it depends" peculiarities of SQL and
RDBMSs and making inroads on the vast tomb that represents architectuliary
sound back ends.

So an article focussed on improving my "it's only css but it works" knowledge
is one of the best things I've seen on HN in quite some time :)

~~~
wolco
A good full stack developer should have double the salary of a
frontend/backend developer. Do you find this is the case? You need to be an
expert at both roles plus have a third skill connecting them together.

~~~
gary__
I think there's often a leeway given to the full stack dev that they have
strengths and limitations. I haven't got to the point where I could compete
with the true / good front end dev with my skills.

Even at the backend you have the application backend (c# or whatever) and then
sql/rdbms. If you are that good perhaps you deserve thrice the pay by this
logic ;).

Jokes aside, at the last good company I worked for where I knew other people's
pay, I was compensated for the entirety of my skills compared to the good
front end dev. We earned the same, and I was quite happy with that.

Jack of all trades...

~~~
wolco
I've been a backend developer for years and at times a frontend developer.

I've applied to a few full stack positions and the amount of specific
knowledge in various topics they require seems much greater than either role
separately.

~~~
crucialfelix
When hiring or interviewing we tend to build up a big list of skills so the
job looks impressive and attracts talent. Don't take the requirements too
seriously.

Ideally the person doing the hiring is just measuring your knowledge. But I
know many interviewers just try to eliminate candidates.

------
miki123211
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.

------
sam0x17
Uh huh, what about "the vertically centered div" and the ever important "span
vertically centered within the parent"

------
Theodores
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.

~~~
galaxyLogic
> 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.

~~~
Theodores
What I have learned just from having a go is that document outlines matter
too, so I just think of whatever I am writing in terms of sections, articles
and asides. I don't actually ever think of adding a 'div', there is just no
actual use case for them.

Typically with a 'section' the first line inside it for me is a heading. So on
the outline there are no 'unnamed sections'. Save with 'nav' and other content
blocks, I usually find that there does need to be a heading in there anyway.

So Grid does not care what the elements are, however, that form fieldset won't
work in CSS Grid and there may be a couple of other edge cases. Now here is
the important thing to know - have too many nested divs and it makes CSS Grid
very difficult, almost pointless.

So, imagine a form. You can have just label followed by input, label followed
by input with some submit button at the end. This can be put into CSS grid and
styled beautifully with no effort. It goes responsive effortlessly as well.
There is nothing to it.

But then, in real life you are working with some legacy code where there are
divs around each form element and divs grouping the labels and the inputs and
an outer wrapper with spans around the required field asterisks, everything
with class attributes on it.

It is hard to imagine if you are used to that type of markup that you don't
need any of it!

But that is the case. You can write ultra lean HTML.

Then when it comes to actual content, e.g. a blog article, you realise that
the WYSIWYG paradigm is doing us no favours. It has no structure even if it
looks okay.

So I use the article and section elements to just get my writing neatly
organised, with headings at the top of each. This is more about just writing
content neatly than presentation.

The div makes sense if you are copying stuff from old tutorials, but it never
makes sense with content, but it sneaks in there. It is so baked in with
things like the Wordpress Gutenberg blocks thing where some people have staked
the whole company on new ways of writing out of spec bad HTML. If you check
the manual you will see it is the element of last resort and just isn't needed
with CSS Grid layout.

Before CSS Grid layout you did need the div to make wrappers for centering
stuff. But now you don't. But people have got so used to using it that it has
got stuck in the mindset, a groupthink that will look silly in a decade or so.

I also style the elements, never needing classes. But with no div wrappers
these are all sensible looking to me but would horrify someone doing BEM
notation. Here is an example that gives you an idea...

    
    
        body > footer > nav > ul {
          display: grid;
          grid-auto-flow: var(--footer-nav-ul-auto-flow, column);
          grid-gap: .25em;
          justify-items: var(--footer-nav-ul-justify-items, left);
          padding: 0;
        }
    

So that is for some responsive footer links, they go across the page on
desktop and the other way on a small screen. Best practice would say that I
add 'footer-links' as a class to the footer links. Best practice says the
'body > footer > nav > ul' selector is 'too complicated' as it uses four
rather than three (max) selectors. But that is how I like to read my CSS these
days, with no preprocessor, no compiling, just spelt out.

Now this example is not a portable component but that is the point, the
document structure is relatively flat and quite predictable.

~~~
ctidd
If seems like you discount portability as a concern, and if that's appropriate
for your use case, that's a fair decision of course. But there are many use
cases for which that's a priority.

The concern the BEM and component-based CSS approaches aim to address is the
composition of arbitrary chunks of DOM without implicit side effects. By
having chunks of DOM explicitly opt in via classes to being styled in a given
way, they never accidentally receive styles they weren't meant to, and they're
fully portable to arbitrary contexts.

In something like an web application as opposed to a document-oriented
website, the ability to compose components and avoid quirks of things that
randomly break or look different inside other things is beneficial. Using a
component in a new place shouldn't (in the application development context)
require adding new selectors for it because it's not "where" your selectors
expected it to be.

~~~
Theodores
When it comes to portability I find that a class for the component is all that
is needed. So that is at the root element of the component and with everything
inside classless. So '.component > nav > ul' might be how I would style
navigation inside the component, knowing it would not inherit styles from the
body defined classes for header/footer navigation.

The BEM type of examples you will normally see will have everything as a div,
I just avoid div elements not out of some prejudice against them but because I
am out of the mindset to think to use them.

A lot of what I am saying here does fall apart on over complicated commercial
projects though where the CSS is 'add to' and you can't just strip everything
out to do it stupidly simplified.

I am also not a fan of monolith stylesheets with resets and frameworks adding
thousands of lines of CSS. The idea that you should need 30000 lines of CSS
for a product page is just silly, but even some of the best websites are doing
that sort of thing.

In one of my pet projects that I am not quite happy with yet (wording could be
better), I create a lot of content from JSON data using templates done as
'template' the element. The approach of using simple selectors works well when
it comes to taking a template, changing elements within it such as the title
and adding rows of data to it. I have struggled with over complex toolkits
that create stuff, e.g. the Wordpress Gutenberg editor, but I find vanilla
javascript (no compiling) with full feature HTML5 (all the elements) and the
compound selectors work great. At one level the rest of the world is way ahead
of me on these mega complex build tools but then I wonder if they are really
needed.

Anyway back to it!

------
sheriffderek
"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.

------
victor106
What’s the best resource (book, videos etc.,) to learn css these days?

~~~
macando
Hey once you're past the fundamentals check these two cool games out. They
teach how to quickly grasp the most difficult parts of CSS - the layout.

[https://flexboxfroggy.com/](https://flexboxfroggy.com/)
[https://codepip.com/games/grid-garden/](https://codepip.com/games/grid-
garden/)

I wish all learning was this fun.

~~~
sambroner
Wow, that grid-garden game is great.

------
PyroLagus
I'm not sure if the creators will read this, but on [https://every-
layout.dev/rudiments/axioms/](https://every-layout.dev/rudiments/axioms/)

> 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
>[https://every-layout.dev/layouts/cluster/](https://every-
layout.dev/layouts/cluster/)

>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
It's _still in production_ meaning: they are not available yet, they are being
written.

~~~
galaxyLogic
Another way of saying that would be that they are still in "development"

------
codedokode
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.

~~~
majewsky
Flexbox has been supported by all browsers for years now, even by IE11. What
on earth do you need to support if you cannot use flexbox?

~~~
codedokode
Caniuse says that IE11 has a lot of bugs regarding flexbox. Firefox supports
flexbox only since 2013-2014. So it would make sense to add a simple non-
responsive fallback for older browsers.

Also, if I remember correctly, the default browser in Windows 7 is IE9. It
makes sense to support default browser in the most popular desktop OS.

Some of older browsers, released in 2012-2014 support flexbox only with vendor
prefixes, but the article doesn't has rules with prefix. As frontend devs tend
to copy the code without much thinking, we cannot expect that they will add
the prefixes or fallback code themselves. So it will be author's
responsibility for web sites being less accessible in different browsers.

~~~
RussianCow
caniuse.com also has the combined global market share of IE 6-10 as being only
0.46%, which is completely insignificant for most websites. And I've
personally been using flexbox on IE 11 for years with very few issues.

> Some of older browsers, released in 2012-2014 support flexbox only with
> vendor prefixes

Again, these browsers represent a tiny fraction of the total market. Firefox
and Chrome auto-update by default, so there is no reason that someone should
be on a version from 2012.

These days it simply doesn't make sense to have a fallback for flexbox unless
you're specifically targeting older versions of IE. (And even then, I've had
some luck getting flexbox layouts to work on IE 10, even though it's more
effort.)

~~~
zamber
Global market share stats are applicable for global target websites. Consider
any medical equipment company for example - their clients will browse the
catalog from archaic, unmaintained PCs they have laying around.

Always get data about browser market share from your client if they have it,
otherwise you're simply in for an uncomfortable surprise one stats start
coming in.

------
codedokode
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.

~~~
ww520
Rem is great. It allows uniform scaling of all UI elements under a parent
along with them font size.

~~~
codedokode
Where is this used? If a user wants to make everything larger then they can
use zoom in a browser that works with any units (except for vx, vh, vmin, vmax
that break zoom).

~~~
ww520
Designers or developers.

