XF 1.4 Creating Style Properties

[Amaury]

We're working on a framework that will be used for KH-Flare 2016 and future styles. We plan on creating style properties so we can significantly reduce the amount of custom CSS we use.

As an example, we have to use custom CSS for the local avatar and Gravatar blocks within the Avatar Editor overlay because there are no style properties for those:



My question is if we create custom style properties, will they be overwritten when updating XenForo? I know that if you customize the core properties, such as changing the color of @contentText on the color palette, they will be reverted when you update, but I'm not sure if that extends to custom style properties as well.

 

[Amaury]

I would definitely suggest starting with an unedited style to start your framework.

That's precisely what I did.

I then made all of the necessary edits to all the style properties and non-CSS templates for things that will be the same across every style. For example, in some areas where they are, such as the news feed, prefixes will never be part of the links and colors will always be controlled by the same color palette items, such as:



Anything extra, such as making the sub-navigation bar's text uppercase using text-transform will be done on the individual style(s) since that may not be something that'll be the same across every style.

The actual styling, however, is done on the individual styles using only the color palette since the style properties have already been set up accordingly on the framework.

Also something I found useful for things such as this example. You make a property to control an area that doesn't already have a property you have problems of not all of the CSS being applied as it gets overwritten with the original CSS. What we have done to remedy this is to add a new selector to the html so we can target that and be more specific.

It just makes it easier to remember and always something you can reference in your CSS instead of searching through for specifics.

And that can be done on literally anything, thereby removing !important everywhere? There are indeed some areas where you need to overwrite with !important because it's not possible to be more specific.

Here are some lines from our EXTRA.css template for KH-Flare 2015:

/* Attachment Editor */

.AttachmentEditor .AttachedFile .ProgressMeter {
    background-color: @contentBackground !important;
}

.AttachmentEditor .AttachedFile .ProgressMeter .ProgressGraphic {
    background: @secondaryLighter !important;
}

.AttachmentEditor .AttachedFile .ProgressMeter .ProgressGraphic .ProgressCounter {
    color: @secondaryDarker !important;
}

/* Attachment Editor */

/* Attached Files */

.messageContent .attachedFiles .attachmentList {
    background-color: @contentBackground;
    background-image: none;
    border-radius: 0;
}

.messageContent .attachment .boxModelFixer {
    background-color: @primaryLightest;
}

/* Attached Files */

/* Editor UI */

.redactor_box .draftNotice span {
    color: @secondaryDarker !important;
    background: @tooltipBackground !important;
    box-shadow: none !important;
    opacity: 1 !important;
}

.redactor_dropdown {
    border: 1px solid @primaryLight !important;
    box-shadow: none !important;
}

.redactor_dropdown a {
    color: @contentText !important;
}

.redactor_dropdown a:hover {
    background-color: @primaryLight !important;
}

/* Editor UI */

/* Error */

.errorPanel {
    color: @secondaryDarker;
    background-color: @secondaryLighter;
    border-color: @secondaryLighter;
}

.formValidationInlineError {
    color: @secondaryDarker;
    background-color: @secondaryLighter;
    border-color: @secondaryLighter;
    box-shadow: none;
}

/* Error */

/* Form Date Picker */

#calcurrent {
    color: @secondaryDarker;
    background-color: @secondaryLighter;
}

#caldays {
    border-color: @secondaryLight;
}

#caldays span {
    color: @contentText;
}

#caltitle {
    color: @contentText;
}

.calweek a:hover {
    color: @secondaryDarker;
    background-color: @inlineMod;
}

/* Form Date Picker */

By creating an HTML class, I could just do this, and bam! No more !important, right?

.KHFlare .AttachmentEditor .AttachedFile .ProgressMeter .ProgressGraphic .ProgressCounter {
    color: @secondaryDarker;
}

That leads to a question: How do you create a custom class?

If you're still having trouble, I have a very basic tutorial on style properties:

Create Simple Style Properties

Thank you, Russ!

 

[Amaury]

That leads to a question: How do you create a custom class?

When you have some time, @Steve F.

 

[Russ]

When you have some time, @Steve F.

Just open page_container and put in a new class in the HTML tag at the top.

 

[Amaury]

Like this?



Sorry, I'm new to this.

 

[Steve F]

No, add it to the current HTML.

Where you see class="Public NoJs ect..

Add it somewhere in there if you want.

 

[Amaury]

I think I got it:



If correct, now I don't need to waste time looking for specificity or using !importants like in my example above on post #21 if I use that for everything, just to clarify what you said earlier?

 

[Steve F]

No again

class="KHFlare Public NoJs ect.."

You have an extra " in there

 

[Amaury]

On a personal opinion, do you think it's better to have custom classes at the beginning or end?

class="KHFlare Public NoJs

Or:

Responsive, NoResponsive} KHFlare" xmlns:fb="http://www.facebook.com/2008/fbml">

Please let it be right this time.

 

[Amaury]

@Steve F, I decided to just leave it at the beginning.

One last thing: As you know, while there's nothing inherently wrong with it, it's considered bad practice to use !important everywhere as you should look for other classes to use in order to be more specific. In this particular case, we're bypassing that by always using the custom KHFlare class.



Without the custom class and without !important, I can still get this to work:

.formPopup .controlsWrapper {
    background-color: @primaryLightest;
    background-image: none;
}

This particular case is likely because that's already specific enough. However, is there anything wrong with using a custom class everywhere, even if the CSS works without it and an !important declaration? Is it also considered bad practice or is it different than using !important everywhere?