Comment by Jason Knight on "Fonts become bigger after building with webpack"

Impossible to say without seeing the code, but given you're talking about the train wreck of how NOT to build a website that is SCSS... First thing I'd do is open up the document inspector in each copy to see what's different. ASSUMING your target environment has a document inspector.

Seriously, SCSS is doing NOTHING for you a bit of common sense, learning to group selectors, learning to leverage your semantics (if any), etc, etc cannot already accomplish. It's a giant card-stacked lie and an "extra step for NOTHING" -- that much like HTML/CSS framework idiocy I cannot grasp how or why anyone would use them by choice.

But I guess in this age of using 100k of markup to do 10k's job and half a megabyte of CSS to do 48k or less' job, it's hardly a surprise people get suckered in by any of this nonsense.

That's all wild guesses though since we have no idea what your code is, how you chose your font-sizes, what metric those sizes are declared in, if webpack is screwing with your load order (which happens!), if your testing environment has a different system metric (default font-size) than your production, etc, etc.

Yuh, my first guess was webpack messing with my load order, but I'm not sure. I feel there're some syntactical advantages to writing Scss instead of CSS though, especially with nesting and mixins.

Emmanuel Any "advantages" are massviely outweighed by the disadvantages -- the biggest of which being that your deployed code bears zero resemblance to your development code! That hobbles your ability to fix when things go wrong.

Take "nesting" where if you look at just a selector in the SCSS version you have no idea what it's relative to unless you scroll up. That's stupid. It's made all the more stupid by the 'compiled' selector being entirely different meaning good luck even finding what the document inspector is telling you in your working source! Any alleged clarity it provides is destroyed by the imprecise selectors. MORE of a problem when a wrapping parent is an ID or class and you land in specificity hell.

... or mixins, which are pointless garbage if you bother just grouping your like selectors. Complete waste of time, effort, and code for ZERO legitimate benefit!

Though to be fair, I say the same thing about CSS "variables".

Again though the big questions remain -- is your deployment environment the same as your testing? What is your DE is it something like nw.js/electron/uwp or are you deploying for browsers? If deploying for browsers are you testing in the same browser? What do other browsers do?

There's a lot that can go bits-up face-down along the way between dev and deploy.

I don't know about that though, I love nesting, maybe because I'm lazy when typing, and I avoid specificity hell by not going too deep with nesting. I think for the most part you can use inspect element to debug the scss whether in production or development. Most times I know what an Scss selector is relative to because every component has its own file, so it doesn't feel that difficult, but I guess its mostly just preference. Mixins are awesome, imagine you have to write a particular style, every time, for links to style them as buttons? Or write a bunch of lines of CSS that do the same things for multiple divs that need the same CSS. Personally, I prefer making parts of the webpage components than grouping my like selectors, it just helps with reusability.

Search Hashnode