Random thought on structuring html and css

HTML and CSS in and of themselves are very simple syntactically. The problem comes with keeping things organized and creating a jumbled mess. In my opinion, you should avoid selecting and applying styles directly to elements as much as possible because these elements will be used all throughout your pages and it will be very difficult down the line to point out where styles are coming from. I happen to like the approach taken by bootstrap, and I'm sure several other css frameworks, where the vast majority of your styles come from classes that you attach to elements.

I also like the approach of several components on a page as opposed to one jumbled whole. Angular 2 does a great job of allowing you to create fairly isolated components.

The approach I'm pondering on for css organization is the creation of a 'global style sheet that doesn't touch any elements directly, but are a set of predefined classes that you can bring in to give elements their base styles such as how bootstrap does, but for minor tweaks, you have a css file that is localized to that component and ONLY applies to that component.

Something I really wish HTML had was an ability to prefix the class attribute so that you can distinguish between what all of the classes are for. In a lot of cases, classes are used for styling, but they could also be used as an element to grab during testing, etc. Just looking at the document, it becomes impossible to tell what the classes are for, and nobody really wants to remove any of them because they are unsure of the effects it will have on the app. Being able to do something like style-class="btn btn-primary btn-outline" test-class="reference" would be nice to be able to distinguish between categories of classes and what they intend to do. In the meantime, maybe a workaround is in order, such as: <button class="for_style btn btn-primary end for_test reference end">. Sure, you'd be creating a couple of dummy classes, but the ability of knowing what exactly a class is doing just by looking at the html template and knowing that it doesn't have any effects outside of it's category will go a long way in keeping things maintainable. This also ties into the single-responsibility principle. Classes shouldn't be used for numerous things. Their purpose should be generally known just by looking at them. The problem with sharing classes for testing and styling is that if you need to change a style up, then tests that reference elements by those classes that were used for styling will all break. A test should refer to elements by a separate class or an id if possible.

Global styles should never 'dictate' anything except in a few rare cases. They should almost always be 'pulled in'. What I mean by this is aside from doing something along the lines of * { box-sizing: border-box } where you absolutely want to affect every element on the page, the global style sheet should consist of classes that components can pull in by attaching that class to the element.

The concept of modularity is key. Unless data is needed from an outside source, the component should be able to completely stand alone. Having a site built of components that can stand alone and everything it needs is self-contained unless it needs to get data or style from an outside source, is crucial to being able to understand what is going on with the site. When pulling data in from an outside source, there should always be some kind of interface or notification that this is coming from an outside source. Outside components should never just be able to reach inside a subcomponent because things become intertwined. With modularity, if you remove one component, the other components should still work. Everything shouldn't come crashing down.