CSS refactoring of the backend

Creating Neos & Flow Code
1

[Split Topic – Original Post]

The original post has been by @aertmann – which you can find at JS refactoring of the backend. After our meeting, we decided we should split apart the topics instead, so I (@sebastian) split up the discussions.

Answer by Tyll

The first post was related to JS, now I’ll wrap up my proposals for the Sass/CSS part.

Build Tools:
As stated in the last section, we should definitely move from Compass to Autoprefixer, this is more future proof and reliable to say the least.

I saw you’ve noted the grunt-combine-media-queries plugin @aertmann. Isn’t this dangerous? Since it will re-order your final CSS, thus opens doors for side-effects. We should also take into aspect that media-queries are perfectly gzipp’able, so we don’t have a big performance issue here.

Methodologies:
BEM is super usefull, and reduces the complexity of CSS to a bare minimum. Other than that, I would vote for OOCSS and the Atomic-Design Categorization-Model, since it is abstract and works like a charm with OOCSS and BEM.

We can take a peak at the Sass-Framework we at sitegeist use and develop
Brics

This could be a prime example on how we could structure/and build up our styles. I also do have a separate feature-branch which solves the ugly namespace & BEM repetition.
Example Code

This would solve your ‘Automated neos- prefixing?’ point in the GoogleDoc.

General full reset CSS?
This would lead to applying global CSS to all user created site packages. Thus creating side effects and unwanted stylings in the backend.

Instead I would only bind styles to classes. This should be the highest priority since only with this approach we can reduce mismatched/unwanted stylings/resets.

In short: Maybe use a CSS Reset/Normalize, but make sure to apply it only to your classes, and not on plain HTML elements like

form, input ...

Use framework?
I would suggest using the above linked Brics framework. Using Brics we don’t need to follow the methodologies of others, f.e. Boostrap doesn’t use BEM or OOCSS at all. Foundation neither.

Brics is encapsulated and extensible. You can remove one Molecule/Atom without affecting other styles,. They are abstracted and formed into BEM and OOCSS.

We at sitegeist have build multiple sites with this approach. For example hl-kreuzfahrten.de which only has a 20kb stylesheet, and still has encapsulated styles with BEM & OOCSS.

my opinion on this: Use a smaller “Framework” / Boilerplate, and extend it if needed.

2

General question: should we make a separation between the “theme” and components / model / logic? That way we can easily allow custom themes in the future. For now we could include a default theme in Neos or move it to a separate package like the nodetypes (separate package is more work, but probable leads to better separation).

At least I think we should (now we’re on it) already think from the beginning about things like localization, theming & accessibility from the beginning. For the latter: I’ve a possibility to have cooperation with a dutch foundation focussing on only accessibility stuff and I’d love to actively work with them so we can finally make that accessible content editing a reality too.

And just to be clear: I’m not saying we should make this a shitload of work to do the refactoring :wink: Just want to make sure we refactor the extensible way.

1 Like
3

I’ve really good experiences with libsass, so if we would vote around sass build tooling: my vote you got :wink:

3 Likes
4

I agree with you in many points
Thank you for the post.

I would go further and say “use no framework”.

I’m a big fan of frameworks and we made the whole experience in the last
years from less to sass from bootstrap to foundation, to our own
framework …
But there is no fitting css-framework for Neos.
Most of the Frameworks are designed for websites not for applications.
Those framework who are designed for applications are often too big or old.

In my opinion the Neos CSS should focus on three things.

First it has to coexist with the website-css.
Because we could not rely on modern techniques like shadow-dom for the
next three(?) years , we have to prefix every class and only use the
opt-in techniqe for styling. The biggest feature of CSS, the “cascading”
turns in one of the biggests problems of advanced websites and web
applications. funny, isn’t it?
Most of the Frameworks don’t reflect this need.

Second, Neos doesn’t have a lot of elements. For what do you need a
framework? The two forms and headlines are easy styled with your custom
mixins.
The biggest problem is to style 3rd-Party components like jQuery UI.
On that topic no framework can help you.

Furthermore, almost no framework addresses accessibility issues.

We colud use for example Brics (a framework I didn’t know until one
hour) as a starting point, but move quickly to a neos framework with a
good own documentation.

3 Likes
5

Generating a styleguide out of our CSS UI components is another aspect we should consider. It is very hard to find the respective neos- prefixed selectors at the moment. You have to dig into existing component templates and search for the ones you need. Documenting those is a pretty hard job. Therefore it would be superb to integrate an automatic styleguide generation into the (gulp, yip yip yip) build pipeline. Personally, I have pretty good experience with styledown. Would be really cool to see this styleguide on the documentation platform (http://neos.readthedocs.org/en/stable/) then.

@inkdpixels What do you use for this in Brics?

What do you think?

/André

1 Like
6

We have really good experience with Bourbon.io, it not really framework more a light collection of mixin with modern browser in mind, use with BEM it fit perfectly.

-1 for any “big” framework (foundation, bootstrap, …). When you try to follow BEM coding style, you always end up with fighting against the framework.

1 Like
7

@akoenig Definitely - A styleguide is a must have for the upcoming rewrite. I haven’t used a generator Brics, but am familiar with KSS and styledown as well.

@dfeyer Yeah Bourbon definitely has some great mixins, but most of them are useless if you use autoprefixer or the like. I think we should ultimately aim for just picking the best and of course only what we we need.

Afterall I think everyone agrees on the point of not using a big framework/library since Neos has special needs and pretty much every big framework out there doesn’t have the level of abstraction we should aim for.

I also had a long discussion about this with @dimaip - He also wrote a great “tool” for creating a CSS styleguide based in Neos, so maybe he wants to join in on this topic as well! :smile:

8

I document things via Neos nodetypes, but that won’t work for us of course. I guess it’s OK to generate styleguide from CSS comments. I used to use Hologram before in personal projects as it’s really easy to use, but not sure that’s the right choice for Neos.

@CSS frameworks, I think we need to choose a solid methodology rather than a framework. But it’s better if this methodology would not be described by ourselves (writing one is hard!) and have some outside authority in the industry.
Also the methodology must have the tools to enforce it (validators etc).
Personally I’m a strong advocate of SuitCSS by Nicolas Galagher.