Live data from Hacker News

Principles we use to write CSS for modern browsers

gist.github.com

121–129 of 129 posts

Re: Principles we use to write CSS for modern browsers

#121
post #94

Earlier quoted context omitted.

My approach is to slap myself in the face each time I need to use !important. That's enough to prevent me from slipping into bad habits but leaves me with an option if rewriting my CSS to work around somebody else's (or my own) hacks would be more painful than a slap in the face. I do occasionally get strange looks from my colleagues.

Just wear a rubber band on your wrist and snap that instead. Your colleagues will just think you're trying to stop smoking.

Or get a pavlok (I have one, it's rather neat, though the bluetooth is predictably terrible).

Re: Principles we use to write CSS for modern browsers

#122

Earlier quoted context omitted.

What amazes me is how violently the run-of-the-mill programmer hates namespaces. Despite the fact that managing namespace collision is important for composability (either deliberate or accidental) and code generation. This problem has, for instance, dogged RDF. All the time I hear about programmers who "don't want to learn SPARQL" and I think the heavy use of namespaces is one of the impediments. For most other progr…

That reminds me of a colleague complaining about a recent cohort of about 60 webdev graduates. Not a single one wanted to learn perl, but were quite happy to get stuck into anything Javascript preferably react! EDIT: why the downvotes?

If I was studying web development in 2016 with the hops of getting a good job, I'd also stay away form Perl and learn JavaScript.

Re: Principles we use to write CSS for modern browsers

#123
post #92

Earlier quoted context omitted.

"reuse the same classes but with different content" What difference does the content make if the styling is meant to be the same? "reuse pieces of behavior" Now, that made me curious. Can you expand on that because I'm not sure I quite understand what you mean. edit: I've read through the naming convention they describe and I don't see much anything that different than how I would create CSS for a website. It's just…

I think "content" should be "context". It is when you create a class based on appearance instead of context. To make it worse, is when the class has a semantic name like Hero but it is being used in clearly non-Hero usages. It makes refactoring hard.

Ok, sure, I see what you mean. But I put that under "not using tool correctly so blame tool" category.

Re: Principles we use to write CSS for modern browsers

#124

Earlier quoted context omitted.

CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.

Auto-generation is a good solution because names are the brain's interface to the code. If the names are auto-generated, and the brain doesn't have to look at the auto-generated names, and the abstraction doesn't leak, then you can consider the problem solved.

My devtools still doesn't show me the unmangled name. The abstraction leaks.

As a practicality, I prefer the naming conventions to the CSS processing pipeline, because it gives me a much better ability to debug and iterate.

Re: Principles we use to write CSS for modern browsers

#125

Earlier quoted context omitted.

Well said. This goes (probably double) for the similar conversations about javascript, where lots of people question whether it should be used at all, which is a reasonable question for sites but not for applications .

Those people probably have static content sites with lots of js on their mind when they say that, no? Ads, tracking code, etc....

I think they probably do, which is why I really liked the parent comment about how people should be clear about what they're talking about so that we stop talking around each other all the time.

Re: Principles we use to write CSS for modern browsers

#126

Earlier quoted context omitted.

Enterprise in the US. IE9 still rules, in many cases. I actually work all over this space, do not tell me otherwise. And now I have to maintain two codebases?

Been there, done that. But you might mention to bosses/clients that MS no longer supports/patches anything older than IE-11 on desktop versions of Windows. They are most likely using an un-patch-able version of Explorer. Virii, Trojans and Hacks, oh my! https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE...

My work "upgraded" to IE 11 late last year. The problem is so much of our internal infrastructure was built to target IE 8 (or earlier) that when our information services guys deployed IE 11 they forced it to run in compatibility mode.

Now you have to go through this endless dance of Enable/Disable compatibility mode depending on what site you are trying to visit. We have a lot of non technical users so as soon as you ask them to delve into menu options to use some added functionality on a site you lose them.

Even technical users hate this so most people sideload chrome. However a large number of workstation are locked down and those people have no option but to continue with IE.

Re: Principles we use to write CSS for modern browsers

#127
post #7

Some thoughts: - Good CSS design needs zero !important statements. Fix your specificity or your component architecture if you have a need to use !important. - DRY is a good thing, not a bad thing. Maybe straight CSS isn't quite there yet but... - Why not use the tools at your disposal to aid in development (and DRY) such as SASS/LESS? - Flexbox will be great once IE dies the well-earned death it deserves. I'm very ha…

Using !important is often encouraged for state changes (e.g. ".is-showing" etc)

Re: Principles we use to write CSS for modern browsers

#128

Earlier quoted context omitted.

Last week I was in an interview with Amazon for a position in their web development team. One of the questions was related to this, they asked me to describe how to create the layout for a web page with two columns, I immediately thought about Flexbox but decided to describe the code using "float: (left|right)" and box-sizing , I felt that the two interviewers didn't like my answer because it is outdated .

I can't find the source right now, but I've read that flexbox for page layout can still be problematic because a lot of times when you use flexbox it'll rely on the content inside of it to determine its flex width. So you'll get a bunch of page reflows while content is being loaded, which is less than ideal.

Sounds like this one: https://jakearchibald.com/2014/dont-use-flexbox-for-page-lay...

Re: Principles we use to write CSS for modern browsers

#129

Earlier quoted context omitted.

Auto-generation is a good solution because names are the brain's interface to the code. If the names are auto-generated, and the brain doesn't have to look at the auto-generated names, and the abstraction doesn't leak, then you can consider the problem solved.

My devtools still doesn't show me the unmangled name. The abstraction leaks. As a practicality, I prefer the naming conventions to the CSS processing pipeline, because it gives me a much better ability to debug and iterate.

With sourcemaps you can get close, but it still shows the "mangled" class name in the HTML.

But with a dev/prod environment, you can have your cake and eat it too (for the most part). In dev we have our classnames be in the format of `[classname]---[file-path]---[filename]---[partial-hash]` So one of my classnames from a current project is `.container` in the file, but shows up as `.container---src-components-scanner----styles---1446d`. And in production shows up as `._1533JgnvGu096C2bCAkrxT`.

Post reply on HN