Theming

Franz

Hey Toby, what are your thoughts on the power of themes? Should they be able to swap out entire templates, or only provide new stylesheets?

In any case, here are some interesting slides by Harry Roberts (amazing CSS guru) on theming: https://speakerdeck.com/csswizardry/4half-methods-for-theming-in-s-css
(He talks about SASS, but I'm sure most of that applies to LESS, too.)

Toby

Good stuff! I've thought about theming a fair bit — here's the current plan.

For the default theme:*

There are a few config options in the admin section: a primary color, a secondary color, "dark mode", and whether to use a colored header background.
[attachment:5513e262a310e]
When these are changed, PHP recompiles all of the LESS (core + extensions), inputting these config options as LESS variables.
Based on these config options, all colors are defined as variables, then used extensively throughout the rest of the styles.

This is all functional right now: https://twitter.com/Flarum/status/567144713782714368

In general:*

• During the LESS compilation process, a block of user-defined custom LESS/CSS is included. This is an opportunity to override any LESS variables, mixins, or just put new CSS rules. Because this will be included after the other LESS, all of the definitions within it take precedence. It can easily be inputted in the admin section:

[attachment:5513e2e9392c2]

• I'm not sure whether other themes should be built on top of the default theme CSS, or as a complete replacement of it. I'm leaning towards the former, because I imagine there will be a lot of breakage/upgrade pain if every custom theme has to try and replicate changes to the core CSS. I kind of envision themes as a large block of "user-defined custom LESS/CSS" as described above, but in a nice package.

• Templates (HTML) will not be able to be customised easily, except in some certain cases. We will have certain "hooks" within the templates, in positions that people commonly want to modify, that allow custom HTML to be outputted (e.g. in the header). Beyond this, any core template technically can be overridden by a extension (themes === extensions), but this won't be recommended, again because of breakage/upgrade pain.

• In general, I don't want to encourage themes which re-layout the UI too crazily, because it'd be good to keep some consistency across the UIs of different Flarum forums.

MattDiMu

@Toby what are the reasons for using less instead of sass?

By this time sass has AFAIK every feature that less offers plus
- some more features (like maps, looping through string lists, etc.)
- epic libsass
- a larger community with more projects/frameworks
- it has arguable the more intuitive syntax (functions...)

@Theming - the screenshot looks very appealing, even though some more options and flexibility (no need to limit the color-selection to 10 options) would be nice.

Toby

I originally went with LESS over SASS because:

It's the native language of Twitter Bootstrap, which I wanted to use. (I know there is a SASS port, but I thought that usually a port is never quite as supported as the original.)
LESS's native compiler is written in JS (which is also used for ember compilation) rather than Ruby => fewer dependencies. (Again, though, I know there is a JS port of the SASS compiler.) Regardless, this argument is entirely irrelevant now because ultimately we will need to use a PHP LESS/SASS compiler so that variables can be changed in the admin interface.
In general, as someone who'd only ever written plain CSS before, I think I found LESS's syntax to be a bit more "familiar". I think it's important for us to keep it as close as possible to vanilla CSS to prevent it from being a barrier to extension/theme creators.

I did look thoroughly into both a while ago, trying to find any convincing reasons to use one over the other, but couldn't find anything so I just stuck with my "default". I'm open to switching over if people have strong opinions and convincing arguments. But right now I would argue that LESS has everything we need and switching over is not worth the trouble. Thoughts?

As for the color selection, I've limited it to a predefined set in the GUI because it's actually really easy to pick a color that looks bad in the theme (especially on "dark mode"). Picking a custom color will be as simple as adding @fl-primary-color: #123456; to the custom LESS input though.

MattDiMu

Thx for your reply. The argument, that the color-variables may be overriden in the variabels-file anyway, is an argument 🙂

Actually I do have some arguments for switching to SASS. Things have changed in the past month and some of your initial decision reasons are not valid anymore:

@Syntax
The (newer ) SCSS-Syntax is very similar to CSS/LESS and meanwhile the default one (for the simple reason to make switching from CSS to SASS easier.

@Bootstrap-Port
Yes, in case of doubt a port should be avoided and yes there were problems in the past. Meanwhile, however, there are converters from LESS to SCSS:> Keeping bootstrap-sass in sync with upstream changes from Bootstrap used to be an error prone and time consuming manual process. With Bootstrap 3 we have introduced a converter that automates this.

Source:

@Portability
This is probably the most important point. The already mentioned libsass is a SASS-Implementation in C/C++, created for maximum performance and portability. So instead of creating xxx implementation of the Preprocessor in each backend language (lessphp, lessjava, lessruby, etc.), which are (let's be realistic) never bug-free, libsass is one very actively lib, which is then binded by the preferred language. e.g. for php: https://github.com/sensational/sassphp
I have no idea, however, whether such a solution works on classic webspace hosting packages, where user have restricted rights.

Another, IMO, huge advantage of libsass is the performance. In my (quite large) projects, the compilation time went down from 1,5-2 sec to 80-120 milliseconds. So when developing with some sort of livereload/browserSync tool, you have this live-experience of changing a variable/selector/anything on the left side of your screen in your editor and you "instantly" see the outcome on the right side of the screen.

Watch this 2-min-video for maximum "wow"-factor:
https://youtu.be/iyTXdRqP-qg?t=25s

And of course there are the other advantages of SASS, which i mentioned in my previous post 🙂

Regards

edit: What about autoprefixr? for better readability/maintainability it should probably be included as well.

Toby

MattDiMu The package you've linked to is a PHP extension, so it would require installation as a server-side dependency which is not supported on shared hosts. Unfortunately, we simply can't use libsass.

At this stage it's looking like the decision may be made by the available standalone PHP compilers for each preprocessor. LESS has a good one which is kept up-to-date with the official compiler. On the other hand, I haven't been able to find a SCSS one which is actively maintained.

MattDiMu Doesn't look like there's a standalone PHP version of autoprefixer either 🙁 Bootstrap provides some mixins for version prefixing though.

Ophie I did look into Stylus as well, but I felt the syntax would be too unfamiliar. Popularity is in fact an important factor here, we want something that lots of people know.

Ophie

@Toby any thoughts on stylus? I feel that it is less popular then the other two yet a lot easier to work with.

MattDiMu

Toby Well, that's convincing, even though I don't like the idea of compiling on the server instead of using local task-runners, where any desired operation (linting, preprocessor compiling, autoprefixr, css optimizing/compression, image base64-inlining, etc.) could be easily added...

Toby

Yeah, in an ideal world, but the goal is for Flarum to be able to run on any shared host without any dependencies 🙂

deriherdianto

[deleted]

@Toby

[attachment:5513e262a310e]
[attachment:5513e2e9392c2]

just wanted to let you know for some strange reason in regards to these attachments (i am using a Opera browser /PC) cant see the images?

Toby

Attachments were lost when we upgraded from esoTalk. Sorry!

[deleted]

no problem

[deleted]

Toby ill be messaging you private on esotalk cause i cant seem to do it here ok?