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

Principles we use to write CSS for modern browsers

gist.github.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Principles we use to write CSS for modern browsers

#111

Post by talmand »

zephraph wrote: post #85

I think an important thing to note here is that this individual's team is very small. If you have a small team that closely collaborates then scaling things which take discipline (like CSS) becomes vastly simpler. CSS is difficult because it takes so much effort to do things the "right" way. It requires a good set of linting and testing tools or constant vigilance to maintain a correct, robust system. As the codebase…

I believe you could say the same for a large number of coding languages out there.

Re: Principles we use to write CSS for modern browsers

#112

Post by talmand »

pluma wrote: post #56
surganov wrote: post #27

Recently I got into functional CSS: https://github.com/chibicode/react-functional-css-protips

At that point you might just go full css-in-js and embrace inline styles. I'm not sure which is worse: A) having twenty classes on each element, each doing only one or two things B) having twenty classes overlapping on the same one or two things

I would say both A and B are incorrect.

Re: Principles we use to write CSS for modern browsers

#113

Post by PaulHoule »

rfrey wrote: post #58
sjclemmy wrote: post #52

Earlier quoted context omitted.

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?

They're quite rationally looking for assignments that increase their own market value.

I haven't done anything in Perl since 2005 or so. I think it got eaten pretty much by Python, PHP and Ruby.

Re: Principles we use to write CSS for modern browsers

#114

Post by extrapickles »

spdustin wrote: post #31
freshyill wrote: post #10

Earlier quoted context omitted.

Why not both? Global flexbox support is >96% and in the US it's >97%. Unless you're aiming for a 1:1 pixel-perfect experience in crappy old versions of IE, it's negligibly simple to detect IE (or lack of flexbox support), and just use something else. You can usually get pretty close to a lot of flexbox layouts with display: table and related properties, and also falling back to floats for others. In a worst case scen…

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?

We use nw.js (customizable webkit browser) to provide an "application" for those customers that only have IE9 so we don't have to support IE9 in the web application. Sales pages still need to support IE9 though as they use IE9 to find the product.

Re: Principles we use to write CSS for modern browsers

#115

Post by threesixandnine »

sanderjd wrote: post #46
skrebbel wrote: post #3

A bit meta, but I need this off my chest: I love how this document starts off saying "this is for react apps". IMO every discussion about CSS coding standards needs to start with context. A lot of old CSS lore came from people who build websites. I mean those fairly uninteractive things, focus on content. Blogs, restaurants, newspapers. Building an application that happens to use the DOM as their UI toolkit is totall…

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

Re: Principles we use to write CSS for modern browsers

#116

Post by bobbytherobot »

talmand wrote: post #92
skrebbel wrote: post #3

A bit meta, but I need this off my chest: I love how this document starts off saying "this is for react apps". IMO every discussion about CSS coding standards needs to start with context. A lot of old CSS lore came from people who build websites. I mean those fairly uninteractive things, focus on content. Blogs, restaurants, newspapers. Building an application that happens to use the DOM as their UI toolkit is totall…

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

Re: Principles we use to write CSS for modern browsers

#117

Post by freshyill »

netghost wrote: post #110
freshyill wrote: post #10

Earlier quoted context omitted.

Why not both? Global flexbox support is >96% and in the US it's >97%. Unless you're aiming for a 1:1 pixel-perfect experience in crappy old versions of IE, it's negligibly simple to detect IE (or lack of flexbox support), and just use something else. You can usually get pretty close to a lot of flexbox layouts with display: table and related properties, and also falling back to floats for others. In a worst case scen…

At the point when you write fallbacks for IE, you might as well just use an approach that works for all your supported browsers, otherwise you've got twice as much to verify and maintain. Check this out for an alternative to flexbox if you can't ignore that last n% of your users: https://kyusuf.com/post/almost-complete-guide-to-flexbox-wit...

With flexbox and a fallback, you're future-proofing. If you go with floats or something worse, you're working around yesterday's constraints.

Re: Principles we use to write CSS for modern browsers

#118

Post by lisper »

Klathmon wrote: post #80
lisper wrote: post #75

Earlier quoted context omitted.

> CSS Modules is still a "naming convention," just one that is auto-generated for you. Yes, that's true, but your use of the word "just" implies that auto-generation is a detail. It's not. It's the the big win. At root, everything is machine code, which also has a flat namespace. Having that flat-namespace code auto-generated is a huge lever.

And it fixes a few other unexpected problems as well. We use SHA1 hashes of the CSS classes' contents as it's name when using CSS modules. This has the cool side effect of making any 2 classes that do the same thing to have the same name, and get de-duped in the final output, regardless of where they originated in the application. When I saw it happen the first time, it really kind of cemented in the idea that this c…

Neat trick, but SHA1 is serious overkill for this. Even MD5 would be overkill. You don't need a cryptographically secure hash if you aren't dealing with inputs controlled by an adversary.

Re: Principles we use to write CSS for modern browsers

#119

Post by bobbytherobot »

davedx wrote: post #4

> Flexbox is awesome. No need for grid framework; Yes, great, if you can ignore all the IE users. Is that what "modern" means? I'd love to use flexbox where I work, but it's just not feasible to give up all the customers we would lose.

I've been using flexbox for the past 1.5 years. I'll add fallbacks, but it really is minimal if you are willing not to have it pixel perfect.

Sometimes though I will use the fallback because it actually does it better than flexbox.

Re: Principles we use to write CSS for modern browsers

#120

Post by Klathmon »

lisper wrote: post #118
Klathmon wrote: post #80

Earlier quoted context omitted.

And it fixes a few other unexpected problems as well. We use SHA1 hashes of the CSS classes' contents as it's name when using CSS modules. This has the cool side effect of making any 2 classes that do the same thing to have the same name, and get de-duped in the final output, regardless of where they originated in the application. When I saw it happen the first time, it really kind of cemented in the idea that this c…

Neat trick, but SHA1 is serious overkill for this. Even MD5 would be overkill. You don't need a cryptographically secure hash if you aren't dealing with inputs controlled by an adversary.

Yeah it's overkill, but it ads basically no extra time to our build, so there's no need to optimize it.
Post reply on HN