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

81–90 of 129 posts

Re: Principles we use to write CSS for modern browsers

#81

Post by Roboprog »

FWIW, I'm using Angular (1.x) on a project at work, rather than React. One of the things I did recently was take the CSS file used in the project ("Few Pages App", rather than SPA, which had a common .css file), and turn it into an Angular (javascript) "directive".

I wish I had done this earlier. I have no "compile" step, it's just straight js plus the framework. However, I now have a mechanism to use variables for any (new) stuff with repeated settings, inserted into the rest of the text in the " ... " template.

Re: Principles we use to write CSS for modern browsers

#82

Post by Roboprog »

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?

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

Re: Principles we use to write CSS for modern browsers

#83

Post by Roboprog »

epmatsw wrote: post #76
spdustin wrote: post #48

Earlier quoted context omitted.

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.

Even Epic has dropped IE9 support AFAIK. That's a pretty good indicator to me that healthcare has moved off it.

Seconded. I am working on a project at UCD Med Center for California Dept of Public Health, which includes a pilot tie-in with Epic (even if it's just Epic shaking hands with our system and putting a short task's page in a frame).

We started out in late spring / early summer back in 2015 saying we needed to support IE9, but that has since changed to 11. The notice from MS that nothing before 11 would be supported after January of this year (2016) forced the issue, I think.

Back when I worked at a financial company two years ago we sure had mandatory crusty old versions of IE, though. Except for the groups that got special permission to use a browser that actually worked for things they had to have.

Re: Principles we use to write CSS for modern browsers

#84

Post by Roboprog »

spdustin wrote: post #78
moron4hire wrote: post #53

Earlier quoted context omitted.

I've done those verticals, too. We always had Firefox. I don't know what it's like now. That was 10 years ago. (AKA sit down and shut up with your bullshit "sit down and shut up"s)

I literally deal with students in every class, a not-small percentage of students, that are disallowed by domain policy from installing another browser.

I know :-(

Give it a year. Without MS support, they will be forced to give up these older versions. Of course by then, IE 11 will seem quite "vintage", but that's life.

Re: Principles we use to write CSS for modern browsers

#85

Post by zephraph »

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 or team grows the difficulty of that task increases. That, to me, is why CSS often viewed in a negative light.

Re: Principles we use to write CSS for modern browsers

#86

Post by Nadya »

kowdermeister wrote: post #19

I've developed my last 5 projects (corporate websites with many different layouts) with SASS + Foundation 6 an no naming convention. Instead I relied on nesting selectors. I can behave and usually not go deeper than 4-5 levels. It's a really neat way unambiguously tell a CSS rule where it should belong to. For example I can create a section.hero-block{ /* things inside are scoped */ } CSS selectors who live outside a…

This is how I've developed projects for the past two years. Every module is scoped. If it needs variations but contains the same HTML structure - it gets a modifying class (.full, .half, .side, .footer, whatever)

If it has a different HTML structure - it is a different module entirely: `.module.v1` VS `.module.v2`

Doesn't matter if 85% of the CSS is shared between v1 and v2. If the HTML structure is different, it is a different version of that module. If you can run a diff checker and return 100% the same HTML structure but you need a different coat of paint, you add a variation class. All modules begin as a "v1". This prevents it from needing to be added to the scope selector if a "v2" is ever added. I've yet to work at such a scale where the loss in CSS performance was a problem.

Utility and State classes live in global space. Global being defined as anything unscoped, not "everything in CSS is global space". Since everything is scoped - I can safely reduce selectors. Very rarely does it go more than 3 levels.

I use some level of OOCSS but don't use it for things like `.floatLeft`. If it is a style I will want to remove later, typically for responsiveness, then I don't want a class `.floatLeft` that is really `.floatNone` at a certain size. I would rather take `.item` and change `float: left` to `float: none` with a media query.

Re: Principles we use to write CSS for modern browsers

#87

Post by atomwaffel »

ulkesh wrote: post #59
MatekCopatek wrote: post #57

Earlier quoted context omitted.

Avoiding !important is generally very good advice, although the ZOMG NEVAH! approach is a bit overzealous IMHO. One good example would be overriding random external styling (e.g. an included CSS file some plugin you use). If their stylesheet has very long and specific selectors, you can either repeat them entirely ( #plugin .container .subcontainer .input-wrapper.input-wrapper-blue input[type=text]:first-child ) or s…

I agree with respect to 3rd party libraries. One of the things I hate most about Bootstrap is its amazing overuse of !important. However, my context was mainly around architecting your own CSS, not as it relates to using someone else's.

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.

Re: Principles we use to write CSS for modern browsers

#88

Post by cel1ne »

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

My preferred solution is http://tachyons.io because it has a font relative scale for spaces. No more guessing of pixel values.

Re: Principles we use to write CSS for modern browsers

#89

Post by gr3yh47 »

awesomebob wrote: post #55
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"

CRY: Continuously Repeating Yourself WET: Write Everything Twice Credit: https://roots.io/sage/docs/theme-wrapper/#fn2 :)

WET is standardly 'Write Every Time'

Re: Principles we use to write CSS for modern browsers

#90

Post by Wintamute »

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 build large static websites, and sometimes apps, and can confirm that the CSS techniques listed in the article work very well for both use cases.

UI components don't need to map to richly interactive parts of an app, they can just as appropriately map to repeated design elements in a well planned static site.

To me its the same problem.

Post reply on HN