4 ms·
>A lot of web development seems to be about splitting things up into manageable chunks or “components”. [...] This doesn’t work so well for CSS. I'm not a web
by forgotmypassw 11y ago
>A lot of web development seems to be about splitting things up into manageable chunks or “components”. [...] This doesn’t work so well for CSS.
I'm not a web developer by any means but I'm pretty sure there's a way to manage CSS "components" that then are compiled into a single, minified stylesheet, no?
- igvadaimon 11y agoI think what author meant here is order of those compiled files. For example, when 'media_queries.css' comes before 'main.css', those media queries will be most likely overwritten.
- lojack 11y agoTypically, you'd have a css file that serves as an entrypoint that you'd then use to specify the order of the files to include. Additionally, while it sometimes makes sense to rely on order of your CSS selectors (e.g. media queries), this can easily be an anti-pattern. Keeping a single file well organized helps as long as you maintain the organization. Splitting things into separate files can enforce this organization.
- forgotmypassw 11y agoI understand that but there surely must be a way to account for that, I'd imagine something like telling the tool to "don't override this section", or "this one overrides that one, but not the other way around" should be an option.
- micheleb 11y agoyeah, but the point is that it's very easy to forget about adding these rules because of the very complexity that motivated splitting CSS into several files in the first place
- gotchange 11y agoThis where the «!important» flag shines through but it gets a lot of hate in the community but I am seriously not convinced with their reasoning and arguments put forth as they seem not fully aware of the standard order of conflict resolution in dealing with cascading and inheritance in the language.
- d4n3 11y ago> as they seem not fully aware of the standard order of conflict resolution I'd say it's the other way around - a lot of usages of !important are due to lack of understanding of CSS specificity, usually as a symptom of something else like using IDs in selectors.. If you avoid using IDs in selectors and avoid deep nesting of classes, then overriding styles works as you expect - apply a more specific selector to override the style. Selector order only comes in to play rarely, and you can structure your files to start with less specific (base) styles first. I see !important as more of a workaround than a solution, and I don't think it is used as it was originally intended.
- gotchange 11y agoI was talking more specifically from a debugging perspective as most of the frustration and anti-!important sentiment in the community stems from the effort and time taken in the process to fix a layout issue only to find after a half an hour of mental exercise and acrobatics an !important flag was raised somewhere and hence was this unexpected layout behavior. I'd say that people who debug this way are at fault here not the language itself or this specific methodology followed because the order of cascading and inheritance in CSS is as follows: importance, origin, specificity and finally source order. So, people who debug layout issue shouldn't jump first to diagnose specificity problems but importance and to lesser extent the origin albeit it's less common now to encounter a prob in this domain, and when everything is clear, you go and inspect specificity and source order. That's why I am not sold on the complete avoidance of !important when writing CSS but I am of the opinion that you should only use them when necessary when you need to override a certain style in a very specific context and not more.
- 11y ago
- mariusmg 11y agoYeap, i'm using LessCSS for this. 1 less file for each "component" (classes are prefixed with component name to prevent collision). At build all less files are compiles into 1 big css file
- gotchange 11y agoWe have Sass partials for that but not as a part or official extension of the language itself.