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

171–180 of 187 posts

Re: Relearn CSS layout

#171

Post by meerita »

btbuildem wrote: post #154
meerita wrote: post #94

Earlier quoted context omitted.

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.

Specially if you work with reactive HTMl, like VUE or React. It's a win. Even with old MVC frameworks you can work confortably and have inmeasurable performance and development speed. The CSS becomes so easy to read, mantain. Changing things is way faster. Back then I needed to watch so many things to do the job. That's why I lost my OO CSS bias.

Re: Relearn CSS layout

#172

Post by [deleted] »

wolco wrote: post #62
gary__ wrote: post #53

Earlier quoted context omitted.

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

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.

[deleted]

Re: Relearn CSS layout

#173

Post by crucialfelix »

wolco wrote: post #62
gary__ wrote: post #53

Earlier quoted context omitted.

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

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.

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.

Re: Relearn CSS layout

#174

Post by HelloNurse »

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.

Given the abundance of div elements in modern HTML, a CSS rule to set padding in all of them can only make sense in an unlikely minority of abnormally simple and constrained pages. Setting a huge, fixed 15em padding is also highly suspect.

You need to "fight" only in poorly designed systems; UI elements can pretend to have a hierarchical namespace and avoid all interference with other components, and pages can be designed systematically (e.g. box-sizing border-box vs. content-box, padding vs. margin, flex...) to simplify CSS rules.

div.arbitrary-ui-library-prefix-radio-button-group { padding:0.5em; border: 0.1em dotted rgba(0,0,0,0.3); }

div.arbitrary-ui-library-prefix-huge-padded-box-container { padding:15em; }

Re: Relearn CSS layout

#176

Post by lmm »

chrshawkes wrote: post #170
lmm wrote: post #149

Earlier quoted context omitted.

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.

You mean changing the layout to be less useful on mobile (or occasionally making the layout less useful on desktop and changing to a better one on mobile)? Yeah, I'm pretty happy to have avoided that one.

Re: Relearn CSS layout

#177

Post by galaxyLogic »

Theodores wrote: post #63
galaxyLogic wrote: post #51

Earlier quoted context omitted.

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

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

Good points, seems using semantic tags makes a lot of sense.

Just a question, is article part of a section, or section part of an article ?

Re: Relearn CSS layout

#178

Post by 8lall0 »

bryanrasmussen wrote: post #129
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 two problems with BEM - 1. naming rules almost always lead to verbose inelegant names that humans would not really use at some point. (I said almost to ward off a war) 2. The part of CSS that I am generally better at than most developers is specifically in understanding the cascade. BEM, in order to help the people who are not good at the part that I am good at, pretty much makes it impossible to use what I am…

I agree on the "inelegant" and "verbose", but the tradeoff is that every block became "obvious", so manteinance is much much easier than ever before.

Re: Relearn CSS layout

#179

Post by d0100 »

HelloNurse wrote: post #174
dmitriid wrote: post #153

Earlier quoted context omitted.

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

Given the abundance of div elements in modern HTML, a CSS rule to set padding in all of them can only make sense in an unlikely minority of abnormally simple and constrained pages. Setting a huge, fixed 15em padding is also highly suspect. You need to "fight" only in poorly designed systems; UI elements can pretend to have a hierarchical namespace and avoid all interference with other components, and pages can be des…

> You need to "fight" only in poorly designed systems;

So pretty much most systems, especially general web Dev and frameworks

Re: Relearn CSS layout

#180

Post by Ambele »

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.

That's a design decision by the ReactJS. Some consider this a flaw of ReactJS. Usually all CSS stylesheets are not included globally in all pages.

Also, if you need to apply a different style, you can just include your custom stylesheet after the global or base stylesheet. As long as you use either the same selectors or more specific selectors, you will be able to override the previous styles. This is assuming the previous developer didn't make the bad design decision of using !important which usually can't be overwritten.

Post reply on HN