Styles as reduced shared modular blocks

[hnla]

Toying with the idea of running smaller scss modules for components e.g _activity_entry or more generic _bp_lists

These are run this way so as to be re-used as 'lib' elements for all or any future packs.

Our directory /bp-templates/ has a directory /bp-templates/shared/styles/ in here we keep out partials.

Our .scsss sheet in a template location /bp-templates/bp-nouveau/scss/buddypress.scss includes these partials and gains modular shared styles that suit a basic layout.

If that template set doesn't want it simply removes the @import '../../shared/styles/_bp_lists';

I'm sure there are many issues in this kind of idea and a plugin like BP, this is to establish the idea for discussion and see what issues there would be... it works on my local but that isn't seeing issues such as style ruleset structuring yet.

[imath]

First i'm not against using scss processor to build css files. I'm also in favor of using modular blocks as you're suggesting. I just think we need to provide a modular approach that is more user friendly, meaning splitting the buddypress.css file into smaller ones.

It could be buddypress-colors.css, buddypress-activity.css etc... that your scss modules would build.

Then we could have a more granular approach when enqueueing styles by registering overridable path and enqueueing the needed styles when required.

eg:

wp_register_style( 'bp-nouveau-main', 'path/to/buddypress.css', array(), $version );
wp_register_style( 'bp-nouveau-colors', 'path/to/buddypress-colors.css', array( 'bp-nouveau-main' ), $version );
wp_register_style( 'bp-nouveau-activity', 'path/to/buddypress-activity.css', array( 'bp-nouveau-colors' ), $version );

// Then a bit later in the loading process, when we need to style activities
wp_enqueue_style( 'bp-nouveau-activity' );

[hnla]

It could be buddypress-colors.css, buddypress-activity.css etc... that your scss modules would build.

Traditionally splitting styles up in this manner has been somewhat frowned upon, fracturing styles can lead to maintenance nightmares, even if on the face of it seems acceptable even sensible.

I'm concerned that in reality there would need to be many files and you then lose track quite easily of what's happening and where.

What is in buddypress.css? Where do all the rules required for user account screens go etc etc.

I'm not dead set against the idea and in some respects it's simply extending what I'm doing with the scss partials but actually compiling them to actual .css ones to enqueue but we do need to think carefully before heading down this road.

Why does this approach make things easier for users and what level of user are we talking about, people can still create child themes they can still overload files are we saying that up breaking the styles in this manner is easier for users than simply copying over the main stylefile and editing

[imath]

So this: https://bpdevel.wordpress.com/2016/05/11/buddypress-style-modules/

is about scss modules ?

Why does this approach make things easier for users and what level of user are we talking about, people can still create child themes they can still overload files are we saying that up breaking the styles in this manner is easier for users than simply copying over the main stylefile and editing

If they need to override only 'buddypress-colors', they can do it without overriding the full buddypress.css :)

[imath]

Also, having multiple css files won't matter soon > https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/#concatenating-css-and-javascript

And till then we can always do something similar than /wp-admin/load-styles.php to cancatenate all css files :)

[hnla]

imath it's not so much about loading of multiple files, although that's always a concern, but about maintainability of rules once you fracture them across files. what is suggested here is not necessarily easy to do in the first instance, also I have a sectional structure in buddypress main styles that would be hard to use if we follow this multiple file approach.

So this: https://bpdevel.wordpress.com/2016/05/11/buddypress-style-modules/ is about scss modules ?

No not really, it's about CSS styles/rulesets we do not force people into working in any particular way although I have attempted to provide them with the options.

I'll have to think more on this. As I don't want to lose momentum I'm going to carry on with what I am doing with the styles as this phase is a tedious transposition clearing out the old and re-building, whether those files get imported or get compiled for enqueueing, or new files added such as color/typography ones will be a matter for later - if rules are in a semi modular form it will help anyway.

Question then: In your paradigm do we still have these files that are not now scss partials but proper .css ones regarded and use as shared ones, i.e do we keep them where I suggest under /bp-templates/ so any template pack automatically inherits them (unless of course they fundamentally do something contrary- and obviously child themes being still able to overload in accepted locations).

[imath]

i see, if it's really a mountain too high to climb then do it as you wish.

My point is if we have a real end user modular approach, splitting buddypress.css files into smaller parts, then it's easier for a user to only change the colors.css file if he wants red buttons :)

Also, i think it would be nicer to only load the css we really need for the displayed screen.

I'd like some other members opinion, maybe i'm just losing my mind here! What are you thinking of my suggested approach @dcavins & @mercime ?

[hnla]

then it's easier for a user to only change the colors.css file if he wants red buttons Yes although we don't just write stuff cos it's easier for an end user, if that means following a less that ideal approach, we have to balance things up.

Loading only for a particular screen is a bit of a misleading saving really yes it feels nice but means thinking exactly what parts of activity lists are strictly activity & what parts are lists general the latter would need to load initially, then we visit activity load the those parts, the lots now cached on client side, our saving? it was never really that beneficial - writing well formed markup and styles as lean as possible probably saves as much if not more.

Like I say I'm moving on with this as it's a lot of work and there is a start here that moves in this general direction but lets have input from the others on this too.