WP.org: Better sass structure

[atimmer]

Currently all styles are in one file, it would be better to bring some structure to this.

I prefer to structure it like the php files, single-post.scss, single-parsable.scss, single-archive.scss, etc. With some mixins to get the responsiveness.

[Otto42]

I believe that you're posting these in the wrong place. This is the meta.trac, we talk about various bits and components of the WordPress.org website itself here. If you have any core enhancements, you should use the core.trac instead.

[atimmer]

Because I cannot change the ticket, more clarification here about the ticket:

This ticket is about the developer.wordpress.org theme that is located here: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-developer

[kevinwhoffman]

My recommendation for the Sass structure is ITCSS (Inverted Triangle CSS). ITCSS is a sane, scalable, managed architecture for CSS that was put forward by Harry Roberts (a.k.a. ​csswizardry). Below I have summarized Harry's presentation regarding structure, goals, theory, and outcomes of ITCSS. I also included additional resources if you'd like to learn more. Looking forward to hearing your feedback.

Structure

1. Settings: Global variables, config switches.
2. Tools: Default mixins and functions.
3. Generic: Ground-zero styles (Normalize.css, resets, box-sizing).
4. Base: Unclassed HTML elements (type selectors).
5. Objects: Cosmetic-free design patterns.
6. Components: Designed components, chunks of UI.
7. Trumps: Helpers and overrides.

Each level gets its own directory. Files within each directory are imported to main.scss. The end result is a main.scss file that is entirely composed of neatly organized partials.

Goals

• A sane environment that is accessible to lots of people.
• To tame and manage source order and the cascade.
• To create a place for everything to live (new and old).
• To reduce waste and redundancy.
• To end the Specificity Wars.

Theory

• Specificity slowly increases layer-by-layer.
• We affect smaller and smaller bits of the DOM at a time.
• Progressively adding styles; never undoing.

Outcomes

• Everything has a place to live.
• People know where to look to find types of rule.
• A sane source oder.
• Reduced waste/redundancy.
• Increased scalability.
• The Specificity Wars are over!

Additional Info

• ​ITCSS Presentation
• ​ITCSS Slides
• ​ITCSS in Practice

[kevinwhoffman]

ITCSS Structure

[mapk]

I am totally on board with this! I imagine that each level gets its own directory b/c it will be broken into separate files based on purpose or pattern.

Can we get some steps around this? Or a process for implementation?

@obenland created a structure for the new Plugin Directory here: (maybe we can utilize some of this in a more global way?) https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-plugins/client/styles

I'm getting ready to start styling the Support Forums and b/c these are separate themes, until this new structure gets implemented, I'm going to be duplicating a lot of sass/css and the grunt file stuff into the bbPress theme - which is just crazy BTW.

[obenland]

I'm happy to take a stab at a parent theme with grunt tasks to compile styles from child themes next week

[obenland]

In 3879:

WP.org Theme: Introduce a parent theme for future wp.org themes.

Allows us to bundle components in a central place for all themes to use.
CSS us built on Inverted Triangle CSS logic.

See #1015.

[kevinwhoffman]

@obenland Great work. What is the protocol for adding objects or components to the parent theme? Should we instruct developers to mimic this CSS architecture in the child themes, and then we can shift objects or components to the parent theme if they offer value to the other sites? As an example, a table-of-contents component that is currently in the DevHub theme could be leveraged in other sites.

[obenland]

I'd like to avoid setting up a protocol or guidelines for now and rather have it evolve organically.

The existing Gruntfile encourages a similar setup as in the parent theme, so I think that'll come automatically. Components probably shouldn't move up to the parent until they're used by at least one other site. The downside of being to liberal with globalized components is not only bloat but, more importantly, unforeseen style changes. See the wp4.css dilemma.
Once a component gets globalized, other child themes might have to be updated to exclude that component from their build tree.

With the parent theme in place now, would you be interested in rewriting the devhub theme to use it?

[obenland]

In 4879:

WPorg Theme: Add ES6 Promise polyfill for Postcss.

See #1015.

[obenland]

In 4880:

Learn: Update theme to be a child theme of wporg.

See #1015.

[obenland]

After trying to porting wporg-developer for a few hours on a flight today, I decided that it's just not worth our time to rewrite all of its CSS for the purpose or rewriting CSS. wporg, wporg-main, wporg-plugins, wporg-learn, wporg-themes are using ITCSS now. Working on these themes has given us a solid base to extend from, and the next time DevHub gets a design refresh it will join the gang.