Live data from Hacker News

Relearn CSS layout

every-layout.dev

151–160 of 187 posts

Re: Relearn CSS layout

#151
post #116

Earlier quoted context omitted.

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

The stack is not two dimensional.

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

Re: Relearn CSS layout

#152

Earlier quoted context omitted.

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…

Despite trying using it a few times I've never seen the appeal in BEM, it's just bringing excessive and redundant verbosity to CSS class names as well as introducing unnecessary complexity in maintenance (e.g. if you change a class's name you need to also need to apply the change to any derivative class names)

The appeal of BEM is that it offers module scoping through naming convention (because we had no other way to do it). And it stops you accidentally styling something you didn't intent to. If you have a .box with a .title inside and you write some css like .box .title { color: red; } You're telling the browser to find any title in box and make it red. But that's not what you wanted to do, you wanted to style box titles, not anything that happens to be in box with a .title, there could be sub-components with titles that you don't want to target. So instead you could write .box > .container > .left-panel > .title and maybe you've been explicit enough to get your intentions across, or you could write .box__title, which only titles scoped to box will contain if conventions are followed. This will also target the title no matter how you refactor the markup inside of box, if the title moves from the left panel to the right etc.

In the hundreds of projects I've used it on it has only make maintenance easier and intentions much more clear. Having a flatter css structure is much easier to work with too. The classes do look ugly though, and was a point of contention when I first looked at it. It was the same when I first saw JSX in React too. I hope a native scoped css solution becomes commonplace so we can avoid having to use a naming convention to achieve the same thing.

Re: Relearn CSS layout

#153

Earlier quoted context omitted.

You accidentally apply a global style, and your entire UI is broken. You need a different styling inside a specific visual component? You need to fight specificity and override a parent ir a grandparent or a global style. In most UI systems this is not a concern.

> You accidentally apply a global style, and your entire UI is broken. That's only a concern if your UI elements depend on global styles, right? Meanwhile, UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs

> That's only a concern if your UI elements depend on global styles, right?

No.

   div {
      padding: 15em;
   }
This will affect all of your styles. CSS is a flat global namespace where you fight to style your local components by overriding rules with increasing specificity.

Re: Relearn CSS layout

#154
post #94

Earlier quoted context omitted.

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…

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.

I've discovered functional CSS some months ago, and I don't think I'll ever look back. Building everything with simple classes makes it easy to keep things consistent, appearance concerns live firmly in the style layer, and once patterns of classes used together start to appear, I can break the rules a little with SCSS and make classes like "button" ("ps ts cap rc2 box1") for the shorthand convenience.

Re: Relearn CSS layout

#156
post #131

Earlier quoted context omitted.

Is a single purpose class still a class? Not in the conventional sense - In CSS' lexicon it's a group of things, right? I've got nothing against the approach - it solves a problem - but it's not how CSS was intended to be used. CSS modules, CSS components, BEM, heck even Sass and Less fall into the same area of trying to wrangle huge unsorted lists of loosely composed attributes into something meaningful. So if there…

Please, elaborate on the first statement. In CSS a class is a class, we're not tied to group things. Original CSS wasn't group purpose, mainly due the lack of properties, you could see more single or a couple of properties per class.

I'm taking about classes with an enforced 1:1 relationship with a DOM node, via a unique computed className.

Since there is no requirement for a cascade for this, you've effectively made an ID out of a class.

All the reasons styling off IDs isn't ideal in the traditional CSS metaphor still apply, specificity, verbose stylesheets, etc. But now it's defined as a class too.

Re: Relearn CSS layout

#157

Earlier quoted context omitted.

HTML isn't about UI. Never has been and never will. The pain will continue until people understand.

HTML/CSS/JS is arguably the most successful UI platform in the world, so this is obviously wrong. You just want HTML to not be about UI.

Something can be "not about UI" and "the most successful UI platform in the world" at the same time.

Many such cases. :)

Point is, HTML is a document format, not a UI toolkit. That's how it was designed and that's how it continues to evolve.

This is probably not a ideal situation, but trying to change it now probably won't do any good.

Re: Relearn CSS layout

#158

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 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-lob…

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.

Re: Relearn CSS layout

#159

Earlier quoted context omitted.

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!

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 render…

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.

Post reply on HN