Fixed Removing text color in Style Properties breaks entire page layout

[DeltaHF]

Affected version

2.1

With the default theme, if you remove an explicit color definition of a property, it will break the entire layout of the page.

To replicate, delete the "Color" field of the "Navigation row" in the "Header and navigation" style properties. It is set to @xf-chromeTextColor by default:



This breaks the theme significantly. Here is a screenshot of the Account Preferences page below.

(Ignore the black box — I edited the screenshot to hide my public navigation tabs which are displayed there as a raw unordered list.)



I'm still new to LESS, but I'm assuming the lack of a color value definition in this location breaks the syntax and causes a cascade (pardon the pun) of invalid rules.

Note the "Navigation row" is not the only field which can cause this error.

 

[Max Taxable]

I'm assuming the lack of a color value definition in this location breaks the syntax and causes a cascade (pardon the pun) of invalid rules.

Probably exactly right. Had this happen a time or two as well. Just revert your change.

You shouldn't be editing the default style anyway, always make new style with no parent and style that.

 

[Lukas W.]

You shouldn't be editing the default style anyway, always make new style with no parent and style that.

A new style with no parent is exactly the same as the default style. The default style inherits from the master style, which is not editable unless you turn on development mode, so there's not really anything to worry about when editing the default style.

 

[Max Taxable]

A new style with no parent is exactly the same as the default style. The default style inherits from the master style, which is not editable unless you turn on development mode, so there's not really anything to worry about when editing the default style.

Thank you for that information. Assumed the default style WAS the master style. However when you do edit the default style, what do you have to fall back on when something breaks, and you need to look and see if it's also broken in the default?

 

[Mr Lucky]

Thank you for that information. Assumed the default style WAS the master style. However when you do edit the default style, what do you have to fall back on when something breaks, and you need to look and see if it's also broken in the default?

Just create a new style (add style with no parent) , it will be a "default" style

 

[Max Taxable]

Just create a new style (add style with no parent) , it will be a "default" style

That's what I do when I want to experiment. Didn't think of still being able to do that as a default tester. I just leave the default be.

 

[Mr Lucky]

Back to the OP I’m not surprised this breaks the CSS as the property would have no value, ie nothing after the colon and there must be s value there.

To achieve text with no colour, you would just assign any colour with full transparency

 

[XF Bug Bot]

Thank you for reporting this issue. It has now been resolved and we are aiming to include it in a future XF release (2.1.1).

Change log:

Prevent LESS compilation errors if removing certain style property elements (namely ones passed into H-scroller variations).

Any changes made as a result of this issue being resolved may not be rolled out here until later.