Current thoughts on preprocessors and M2 directions

[GravityDept]

Does anyone have strong feelings of replacing smaller CSS files vs adding to existing CSS files (via overriding)?

I'd never do overriding in a client project, but in theme-sales world I know that many DIY store owners are at their technical limits putting all their customizations in a final override.css file.

In client work, I wouldn't do it primarily because of specificity issues (not size bloat). It gets back to the heart of whether the markup and HTML class system are extensible enough, then whether the original CSS is written with too much specificity. That can make writing CSS overrides a major PITA, and more favorable to scrap everything for a clean slate.

Are there CSS minification tools that can merge/minimize such overriding and eliminate it?

I don't think that's possible for overriding CSS because all the base rules are material to inheritance. It'd be impossible for a tool to parse what is or isn't used with classes that are combined or extended.

You'd only have standard minification happening, which would lead to code you probably never wanted to send + changes to revert it. Not ideal for performance or maintainability.

[akent99]

My summary of thread so far - best approach is to create smaller CSS files (generated from Less/Sass by developers) that can be replaced rather than using CSS overrides (tack extra file on the end).

Assuming we go with that, that would seem to suggest:

• Define BEM (or similar) list of "BEM blocks" that align with sensible visual UI components of buttons, menu bars, panels, etc (I am not talking about the Magento UI Components here, more GUI toolkit widgets) 
• Maybe go as far as formally documenting such BEM blocks (note: Magento Less library is such a collection, but is not clearly broken into BEM blocks at present)
• Put the CSS for each BEM block name in a separate file, making it easier to replace the CSS (this is not done today with the Magento Less library - its merged into one CSS file)

Question: Are BEM blocks a good resolution of CSS files? If not, what rules make sense to define how to create a "small CSS file"?

A negative is it puts more pressure on the CSS merging capability of Magento - leaving it off in default/production could be bad because of so many separate CSS file includes. It may also mean need to add to Magento better ways to group CSS files (at moment choice is all or nothing for merging - might need to allow devs to define which files should be merged so they can optimize CSS downloads for different pages, when needed).

(Note: I regurgitate what others tell me that resonates - lots of people contributed to the above thinking - plagiarism is the highest form of complements right?)

Is this on the right track?

[ripen_sbuchanan]

Having an ability for Magento 2 to merge files is good, but I would suggest making that optimization a secondary concern. With HTTP/2 on the horizon, this is a short-termed need, so it's not a good idea to bend major architectural decisions to fit it. As HTTP/2 moves into the mainstream through adoption by browsers and webhosts, the benefits will be fairly automatic for those less-technical DIY merchants.

[bassplayer7]

I'm really excited about what I'm reading / seeing here. There's so much potential. 

@Bartek Igielski, yes, and perhaps that is all that is necessary. Maybe it would be helpful to put some of that in writing at some point to lower the bar-to-entry for developers that may not be familiar with Gulp, etc. I suppose the other thing is that the need may disappear if the new base theme of Magento uses SVGs instead of font icons. 

@akent99 I agree with the points you outlined there. I think one thing that will be key is defining rules as clearly as possible that are in place for the development of the base theme and then 3rd party theme developers as well. 

I agree that, as much as possible, the SCSS partials should be broken down by the "Block" (in BEM). In my experience, a partial that is 10 lines long feels too short and one that is 400 lines seems too long. However, the focus should be more on clear object encapsulation, separation of concerns, and one file per block. If the blocks are broken down correctly, this should put the partials at a comfortable size. In a recent M1.9 build I did where I started from scratch, and with BEM, the partials were often coming in around 100 lines.

While it might be good to formally document the BEM blocks, if it was done correctly, it probably wouldn't be very necessary as developers (especially those already familiar with BEM or OOCSS in general) would be able to find the blocks.

So I think that one Block per file is good for components. I have found the need for other partials as well - like utility classes (http://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/#utility-namespaces-u-) and upper-level styles (like straight HTML tags). There are few of these files that are needed, though, and they should then be broken down based on function and size.