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

Default Skin/StyleVars Suggestions

Discussion in 'XenForo Suggestions' started by Mike Creuzer, Feb 7, 2012.

  1. Mike Creuzer

    Mike Creuzer Well-Known Member

    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
     
    Azofan, RoldanLT, semprot and 12 others like this.
  2. Allan

    Allan Well-Known Member

    Good suggestion :)
     
  3. Forsaken

    Forsaken Well-Known Member

    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.
     
  4. Mike Creuzer

    Mike Creuzer Well-Known Member

    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.
     
  5. Forsaken

    Forsaken Well-Known Member

    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.
     
    Mike Creuzer likes this.
  6. Mike Creuzer

    Mike Creuzer Well-Known Member

    @XenForo @Brogan can we perhaps reconsider moving this to open? As with 2.0 discussion beginning, there may no longer be a lack of interest.
     
    Last edited: Nov 4, 2014
  7. Tom Christian

    Tom Christian Active Member

    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: Nov 4, 2014
    idFox and Mike Creuzer like this.
  8. idFox

    idFox Well-Known Member

    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.
     
  9. Mike Creuzer

    Mike Creuzer Well-Known Member

    There are PHP versions that are similar, such as http://leafo.net/scssphp/

    Agree with Tom on vendor prefixes and really all other points.
     
    idFox likes this.
  10. Tom Christian

    Tom Christian Active Member

    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: Nov 4, 2014
  11. idFox

    idFox Well-Known Member

    Thanks! Did not know about it. Thank you very much. Used to develop themes for Drupal.

    @Tom Christian I get it. :)

    Using variables in CSS is a very welcome opportunity.
    Only, not whether it will make a big mess?
    By the way, introduced native support for CSS variables? It seems to be a CSS version 4. Оо
     
  12. idFox

    idFox Well-Known Member

    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
     
  13. Forsaken

    Forsaken Well-Known Member

    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.
     
    semprot likes this.

Share This Page