Principles we use to write CSS for modern browsers • Hacker News Board

Re: Principles we use to write CSS for modern browsers

#41

Post by adrianratnapala » Thu, Sep 22, 2016, 1:30 PM UTC

andybak wrote: post #2

A random brain dump prompted by this statement: "No DRY. It does not scale with CSS, just focus on better components" All programming involves resolving a conflict between two different principles and a lot of the fiercest disagreements are between people that weight the importance of these two things differently: 1. Reducing repetition 2. Reducing dependencies and side effects The language and it's tooling/ecosystem…

You are essentially right. But I would say anything that helps one of these harms the other.

Part of the art of good language/library/thingy design is to understand, and then defy those trade-offs. Try and have you cake and eat it too. It's not always possible, but sometimes it is.

Re: Principles we use to write CSS for modern browsers

#42

Post by MatekCopatek » Thu, Sep 22, 2016, 1:37 PM UTC

andybak wrote: post #2

A random brain dump prompted by this statement: "No DRY. It does not scale with CSS, just focus on better components" All programming involves resolving a conflict between two different principles and a lot of the fiercest disagreements are between people that weight the importance of these two things differently: 1. Reducing repetition 2. Reducing dependencies and side effects The language and it's tooling/ecosystem…

I wouldn't say that they are always mutually exclusive. I think there is a variable ratio between advantages gained by 1. and disadvantages caused by 2.

In other words, at first, reducing repetition will net nearly no negative results - you just recognise different areas that do very similar things and write a common functionality. The most basic example would be programming languages providing standard libraries, even though everything could be done with regular operations. At this point, abstractions are even simpler to use than implementing things yourself.

Problems start to arise once you hit a certain point beyond which your abstractions become harder to use and maintain than simply writing things multiple times. This is where you should stop abstracting/modularising things away (assuming that the reason is purely overengineering, not bad engineering).

Re: Principles we use to write CSS for modern browsers

#43

Post by javajosh » Thu, Sep 22, 2016, 1:44 PM UTC

NKCSS wrote: post #24

kilian wrote: post #8

Earlier quoted context omitted.

Flexbox is supported in all versions of IE that Microsoft themselves still support (IE 11 and up). You can still support it in IE10 too, albeit with a different syntax. That means even windows installations that haven't been updated since 2012 will support flexbox.

It's still common to find Citrix environments with IE 8/9 here in .nl healthhcare sector

Someone should write an exploit for IE 8/9 that upgrades them to Firefox.

Re: Principles we use to write CSS for modern browsers

#44

Post by intrasight » Thu, Sep 22, 2016, 1:45 PM UTC

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?

My experience is that that ceased to be the case about a year ago. Now everyone also has Chrome.

Re: Principles we use to write CSS for modern browsers

#45

Post by paulddraper » Thu, Sep 22, 2016, 1:51 PM UTC

vog wrote: post #35

al2o3cr wrote: post #28

".ComponentName-descendentName" nested inside ".ComponentName"? Remember kids, the cascade is TEH B4DZORS - so always include everything you would have gotten from it in every class name. headdesk Solidly delivered on the "no DRY" premise. Maybe they should coin a new acronym like "WET": "Write Everything Thrice"

I propose to name it the "wet-wet-wet" principle.

WETTT Write Everything Ten Thousand Times

Re: Principles we use to write CSS for modern browsers

#46

Post by sanderjd » Thu, Sep 22, 2016, 1:51 PM UTC

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.

Re: Principles we use to write CSS for modern browsers

#47

Post by PaulHoule » Thu, Sep 22, 2016, 1:52 PM UTC

MatekCopatek wrote: post #14

IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global namespace. My preferred solution are CSS Modules[1], Vue's scoped styling[2] or something similar. [1] https://github.com/css-modules/css-modules [2] https://github.com/vuejs/vue-loader/blob/master/docs/en/feat...

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 programming languages it seems the opposite:

(i) half of the software managers in the world are driven nuts because their team is screwing around with Vagrant instead of working (ii) it seems no programming task is too boring if you do it in rust or go.

Re: Principles we use to write CSS for modern browsers

#48

Post by spdustin » Thu, Sep 22, 2016, 1:54 PM UTC

intrasight wrote: post #44

spdustin wrote: post #31

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?

My experience is that that ceased to be the case about a year ago. Now everyone also has Chrome.

Your experience isn't in healthcare, finance, military, manufacturing or oil and gas (to pop a few verticals off the top of my stack), it would seem. Literally 80% of my (adult, American-enterprise-employed) students in 2015-2016 so far have IE9 as their desktop standard, and have to beg for a special exemption to be allowed to install Chrome or Firefox.

Re: Principles we use to write CSS for modern browsers

#49

Post by ooqr » Thu, Sep 22, 2016, 2:04 PM UTC

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…

I would love to read a long-form article about this if you're ever inclined.

Re: Principles we use to write CSS for modern browsers

#50

Post by exceptione » Thu, Sep 22, 2016, 2:05 PM UTC

daurnimator wrote: post #21

ulkesh wrote: 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…

> - Why not use the tools at your disposal to aid in development (and DRY) such as SASS/LESS? Because there is so much tooling churn + barrier to entry. The point is that sometimes it's better to repeat yourself than to use the tool of the month.

Both are proven tools and should be used by any serious frontender. Pick SCSS, it's your most advanced option; you won't hit a limit in what you ultimately want to achieve.