Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Relearn CSS layout

every-layout.dev

Post reply on HN
Print view View original

161–170 of 187 posts

Re: Relearn CSS layout

#161

Post by contravariant »

otabdeveloper4 wrote: post #157
majewsky wrote: post #139

Earlier quoted context omitted.

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.

Well like it or not but the rise of REST APIs suggests that HTTP is extraordinarily well suited to use as a general interface so it's not too surprising that the related markup language HTML has found similar use as a user interface.

Re: Relearn CSS layout

#162

Post by wwweston »

dmitriid wrote: post #130
wwweston wrote: post #119

Earlier quoted context omitted.

I'll bite: what's different about styling a UI? UIs are presumably more consistent/less varying than documents, so special cases and cascade overlaps should be less of a thing?

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.

Those are certainly everyday concerns for people doing UI work, but I'm not sure I see how they're specific criticisms of CSS.

Global is going to mean global, regardless of whatever's managing the appearance, and the only UI systems I can imagine that wouldn't have a problem like this would be those with an entirely uncustomizable global UI presentation.

And for differing stylings inside a specific visual component -- generally, specificity is on your side here, most of the time the selectors involved in component-specific rules will naturally override global styles and you'd only fighting specificity if there's another component specific rule. If that's the case, though, what system would save you from conflicting rules applied to a specific component?

Re: Relearn CSS layout

#163

Post by tracker1 »

steve_taylor wrote: post #111
danShumway wrote: post #89

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…

I have the opposite experience. I’m in a React team that was doing BEM via Sass for a few years. Almost two years ago, we moved to Styled Components. The only real difference is that Styled Components automates * naming of classes * creating components whose sole purpose is styling * eliminating unused stylesheets It’s not like we became any less strict about specificity or used inline styles any more or less than we…

I'm with you... Also, with theme context(s) it's easy enough to re-use theme values while keeping actual component styling with the component and in isolation... you remove a component, and the styling goes with it.

I've found it much easier to not have left over or unused cruft with component styling JSS/StyledComponents etc.

Re: Relearn CSS layout

#164

Post by tracker1 »

rukuu001 wrote: post #98
sktrdie wrote: post #73

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…

CSS that affects a components internal layout should be with the component. CSS that affects the components appearance (colours, type etc should be with the document). Of course, communication across teams will affect how successful this is. I’ve seen it go both ways. PS - read ‘should’ as ‘makes my life easier’

If using JSS, you can use a theme for common appearance settings, and use a context that carries that to all components. For example, material-ui uses this approach and I've found it works incredibly well in practice. I've added additional values as needed to my theme and this carries all the way down.

This includes additional/adjusted fonts, colors, etc.

Re: Relearn CSS layout

#165

Post by tracker1 »

deanclatworthy wrote: post #127

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.

Re: Relearn CSS layout

#166

Post by geezerjay »

majewsky wrote: post #138
geezerjay wrote: post #136

Earlier quoted context omitted.

> 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

> UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs This statement makes it sound like every Qt application uses CSS. That's not true. CSS is offered as a way to apply corporate branding to an application. I'm not aware of any FOSS Qt applications using CSS.

> This statement makes it sound like every Qt application uses CSS. That's not true.

The applications that are ok with the default style don't need to specify style. Nevertheless Qt is an UI toolkit that supports CSS styling.

> I'm not aware of any FOSS Qt applications using CSS.

And that's ok. Nevertheless I've already worked on a couple of Qt projects that used Qt Style Sheets extensively. In fact, that's pretty much the norm in any non-desktop project.

Re: Relearn CSS layout

#167

Post by geezerjay »

dmitriid wrote: post #153
geezerjay wrote: post #136

Earlier quoted context omitted.

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

> This will affect all of your styles.

Your example affects all div elements which are not styled. If you also include class and/or ID specific definitions then your padding setting doesn't cascade and those are not affected. That's the point of CSS.

> where you fight to style your local components

That's not true. Style changes do cascade but they only cascade where the designer intends them to cascade. If a designer specifies that all div components shall use the same padding then you can't complain that all div components are using the same padding.

Re: Relearn CSS layout

#168

Post by jxub »

Bahamut wrote: post #108
sktrdie wrote: post #75

Earlier quoted context omitted.

Is your company actually building a platform for developers to build apps? Because that's what Apple is doing and they shifted away from using paradigms like CSS.

I work for Apple.

One of HN's wonderful moments :)

Re: Relearn CSS layout

#169

Post by saidajigumi »

BurningFrog wrote: post #159
meerita wrote: post #148

Earlier quoted context omitted.

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.

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

Re: Relearn CSS layout

#170

Post by chrshawkes »

lmm wrote: post #149
sktrdie wrote: post #73

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…

I've been saying this for over ten years. Glad the world is kind of coming around to it. Almost all HTML is generated these days, and the information that's useful for styling is available in the same place as the information that's defining HTML. So generate the styling inline in the same place. If your address display component use a 14 point font, put that inline in the code that generates HTML for an address disp…

Already addressed earlier but inline styles ignore media queries so you may have missed the entire Web 3.0/4.0/responsive web design etc which occurred in 2012.
Post reply on HN