• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Default Skin/StyleVars Suggestions

Mike Creuzer

Well-known member
#1
I've now had the opportunity to create over 20 skins and can say that I am extremely comfortable with the styling and template system. And let me also start by saying this the best damn system ever made for skinning a software. A web developers paradise. And trust me I've pretty much tried them all (mainstream at least). That said, I had a few suggestions that I felt would make theme development much much easier.

1. Font-family variables: If we stored all the font-families in variables, we could easily change the fonts everywhere in seconds:
  • @fontFamily_primary = 'Trebuchet MS',Helvetica,Arial,sans-serif
  • @fontFamily_secondary = Arial,Helvetica,Clean,Sans-serif
  • @fontFamily_tertiary = Georgia,"Times New Roman",Times,serif
  • @fontFamily_quarternary = Consolas,'Courier New',Courier,monospace
2. Element-specific variables:Instead of @primaryDark, @secondaryLightest, I feel that if we assigned these to specific elements, this would be more beneficial in customizing. For example, if I wanted to create a dark skin, I have to be very very careful and make a lot of changes to other stylevars to ensure that light text shows up on the dark background. Also, I think there are too many primary and secondary colors. So I propose a structure similar to this:

Hex or RGBa values:
  • @primaryBg (body)
  • @secondaryBg (#content)
  • @ctrlText (control form elements text color)
  • @ctrlBg (control form elements background color)
  • @bttnTxt (button text color)
  • @bttnBg (button background color)
  • @primaryRow (main color used for node backgrounds, sidebar widgets, posts, almost everything)
  • @secondaryRow (secondary color used for discussion list elements, bb code, avatar/stats columns, etc.)
  • @primaryBorder
  • @secondaryBorder
  • @primaryText (primary text color)
  • @secondaryText (secondary text color)
  • @dimmedText
    @faintedText
    @mutedText
Other elements:
  • @primaryTextShadow (ex, 1px 1px 0 rgba(255,255,255,.4)
  • @secondaryTextShadow (ex, 0 1px 0 rgba(0,0,0,.2)
  • @primaryBoxShadow (ex, 1px 2px 2px rgba(255,255,255,.4)
  • @secondaryBoxShadow (ex, 0 1px 0 rgba(0,0,0,.2)
  • @primaryBorderRadius (6px)
  • @secondaryBorderRadius (3px)
3. Make sure ALL default values conform:If some elements are left alone, given their own font families, allowed their own box shadow, etc. then we still have to go find where they are and fix them each time we wanted to develop a skin. Even in the current system, such things like the quote author link, calendar popout, and more use background shadows that conflict with skins that are anything but extremely light in color. I would be happy to help find some of these inconsistencies, regardless of which system is in place.

We could even add @tooltipBackground and @inlineMod and such, but I felt that these should just have a regular style property and not be included in the color pallet as rarely would you need to call on such values outside of the inlineMod and tooltip elements.

I know this looks like a somewhat limiting and simple list. But I feel that the default should be extremely simple and I am confident that I would be able to convert the current default skin using these variables with ease and would not be limiting myself in any way.

Another point: vBulletin, in 3.X, used the classes alt1 and alt2 as well as an extremely basic and simple skinning interface. There were only a handful of elements that could be customized built-in and while this seems limiting to some, it actually gave the designer free reign. This allowed for an extremely consistent design and led to an unbelievable amount of designers able to make a lot of consistent advanced skins in next to no time at all.
And really the sheer awesomeness of the entire system easily overshadows these issues that I've outlined, so feel free to disregard. I am just sharing my personal experience with skinning for XenForo.

Thanks for considering,
Mike
 

Forsaken

Well-known member
#3
I'd also like to see a global font-weight property added so that you can set the value of the default bold option in the style properties, rather than use the default which can be problematic with certain fonts.
 

Mike Creuzer

Well-known member
#4
I'd also like to see a global font-weight property added so that you can set the value of the default bold option in the style properties, rather than use the default which can be problematic with certain fonts.
True. Font-weight: normal (maps to 400) and font-weight: bold (which maps to weight of 700), is no longer the standard. We have 300 weights and 500 and 600 that are more readily available and conform to the Google material design standard.
 

Forsaken

Well-known member
#5
True. Font-weight: normal (maps to 400) and font-weight: bold (which maps to weight of 700), is no longer the standard. We have 300 weights and 500 and 600 that are more readily available and conform to the Google material design standard.
That's because they're using Roboto (which is what I'm using for a current design and why I brought it up); other fonts use other weights as well which can become even more of a headache.
 
#7
Incorporating functionality from CSS Preprocessing frameworks such as SASS or LESS would be nice too. Being able to use functions such as lighten($var,x%), darken(), adjust-color(hue,sat,opacity) on say a @primaryColor variable would instantly solve the need of having a ton of different colour variables and also ensure XenForo is ahead of ALL competition in terms of using the latest industry techniques.

I also noticed that XenForo has automatic vendor prefixing on certain CSS3 properties but not all. I'd like to suggest incorporating an industry standard tool to do this job instead. Autoprefixer uses the latest vendor prefixes from caniuse.com and is by far the best way to write CSS3.

(Apologies if this should be a new topic - it was supposed to be an extension to Mike's suggestion)
 
Last edited:

idFox

Well-known member
#8
Incorporating functionality from CSS Preprocessing frameworks such as SASS or LESS would be nice too.
Wonderful idea!
For SASS needs RUBY.
And on most hared-hosting Ruby is not installed.
For the development will have to take the server or VDS.

Incidentally, the basic Drupal theme (zen / omega) using SASS.
 
#10
Wonderful idea!
For SASS needs RUBY.
And on most hared-hosting Ruby is not installed.
For the development will have to take the server or VDS.
I don't mean actually incorporating the SASS framework into XenForo as that would require a massive re-write of their entire front-end (XF3.0, maybe?). Xenforo already incorporates many CSS preprocessing techniques such as variables, includes, calculations etc in the template system. My idea was to simply extend those further and include other techniques like color manipulation. Another awesome feature of Sass/Less is mixins. For example, in my full-time work - I regularly use the below mixin:

Code:
+stretch(10px,0,auto,0)
This would output:

Code:
position: absolute;
top: 10px;
right: 0px;
bottom: auto;
left: 0;

Another good example is with tedious media queries. I have a mixin like so:

Code:
@mixin respond-to($media) {
  @if $media == handhelds {
    @media only screen and (max-width: 479px) { @content; }
  }
  @else if $media == wide-handhelds {
    @media only screen and (min-width: 320px) and (max-width: 767px) { @content; }
  }
  @else if $media == wide-handhelds-ls {
    @media only screen and (min-width: 320px) and (max-width: 767px) and (orientation:landscape) { @content; }
  }
}
In my SASS code, all I need to write to target the handheld media query is:

Code:
.myElement
    width: 100px
    +respond-to(handhelds)
        width: 100%
Massively helpful :)
 
Last edited:

idFox

Well-known member
#12
Guys, I've been thinking (yes, sometimes I do it).

I worked with Drupal.
And what if Xenforo do "basic" theme, which can be easily alter by yourself?
Something like "zen" or "omega" for Drupal.

The basic theme must contain the minimum number of elements, easily editable and contain basic number CSS-classes.

What would be on the basis of the topic, users make their own themes.

Wordpress is also available for: http://codex.wordpress.org/Theme_Frameworks#Base.2FStarter_Theme
 

Forsaken

Well-known member
#13
Guys, I've been thinking (yes, sometimes I do it).

I worked with Drupal.
And what if Xenforo do "basic" theme, which can be easily alter by yourself?
Something like "zen" or "omega" for Drupal.

The basic theme must contain the minimum number of elements, easily editable and contain basic number CSS-classes.

What would be on the basis of the topic, users make their own themes.

Wordpress is also available for: http://codex.wordpress.org/Theme_Frameworks#Base.2FStarter_Theme
Because forums do not work the same as blogs/CMS do.

The majority of elements of a blog or CMS can be removed so having a minimum number of elements is easy enough to do. In comparison, most of the elements of a forum are essential either to the user or the moderation staff.

Users can already create their own themes based off of the default style, which is easy to modify due to the style properties, they just need to take the time to learn what they need to do. With the exception of advanced editing to the navigation, node list and message list you can do almost everything with just the style properties.

There are also several style framework available like PixelExit's, Audentio's and mine (which is being re-written currently).

XenForo really needs to release a GDK and some basic documentation for beginners. There are a few guides, but I don't know how well they help people.