XF 2.0 Style Properties changes for XF2

[DragonByte Tech]

Hey all,

In one of our mods, we use a sprite for the images being used, as they are small, "editor button"-like images.

In XF1, I could set up the following Style Property:

To refer to the image in the first 18 by 18 pixels from the top left corner.

However, I cannot figure out how to achieve this in XF2. When I select the "Background" and "Extra" CSS components, I no longer receive the "position" box, nor do I receive the "Width" and "Height" input boxes.

The result is this screen:


I'm assuming I have to put background-position:0 0; width:18px; height:18px; into the Extra box, but I decided to post this thread as I'm wondering if I'm doing something wrong that is hiding these options from me.

Not only are the above options missing in XF2, but the "Layout" option from XF1 has also been changed to only "Padding", so you now have to manually add margins to the freeform box.

At first glance this looks like the Style Properties function has taken a downgrade since XF1, but I could be doing something wrong. Please let me know if you need screenshots of the property definitions.

Thanks!


Fillip

 

[Chris D]

Your assumption is correct.

I wouldn't necessarily like to call it a downgrade, as such, but we've toned it down a little. Part of it is rationalising stuff which users are actually likely to want to change. If you're using a sprite, is the user likely to change that sprite? Is the user likely going to want to change the sprite coordinates? That level of verbosity seems a little OTT for the general case.

So, if it's absolutely necessary, indeed, using the Extra box is recommended. If it's not essential (which it doesn't immediately seem to me like it is) then you could just forego the style property route and define it directly in the less template. In some ways that might be clearer as people will search for the selectors on that element, find the template, and then just edit it there rather than then having to find the style property to control it.

Another point to consider, perhaps, is that when it comes to XF 1.1 and below, we generally advised people to avoid editing templates directly. At that point there was no reasonable way to resolve templates being outdated. At least now if a user edits a template, and then you subsequently edit the master template, those changes can be merged in. That wasn't available until XF 1.2 and by that point we were fairly invested in our somewhat OTT "everything goes in style properties" approach.

 

[DragonByte Tech]

I wouldn't necessarily like to call it a downgrade, as such, but we've toned it down a little. Part of it is rationalising stuff which users are actually likely to want to change. If you're using a sprite, is the user likely to change that sprite? Is the user likely going to want to change the sprite coordinates? That level of verbosity seems a little OTT for the general case.

Fair enough, in this case though the images may not look correct on darker skins (this was a huge problem we suffered, and still suffer, on the vBulletin version).

So for that reason, I set it up so that if the admin only wanted to change the sprite (but the coordinates were the same), they only have to change 1 property, rather than having to hunt it down in the LESS template. If they need to change coordinates for one or more properties, that's available right there on the same page.

So, if it's absolutely necessary, indeed, using the Extra box is recommended. If it's not essential (which it doesn't immediately seem to me like it is) then you could just forego the style property route and define it directly in the less template. In some ways that might be clearer as people will search for the selectors on that element, find the template, and then just edit it there rather than then having to find the style property to control it.

Back on XF1, I did receive feedback saying it would have been better to keep this (and everything else related to colours) in the style properties, so I guess I've gone a bit OTT on it as well

Speaking of style properties, is there a rough "equivalence map" for the XF1 properties to the XF2 variants anywhere? Things like @primaryLighter and @primaryLighterStill etc.

I'm stylastically challenged so I'm a bit worried about picking the wrong properties because I don't fully understand where they're all used and in what way they're used


Fillip

 

[Mike]

It's probably worth noting that the purpose of style properties has always specifically been to allow simple and common changes without going into the templates. It's not supposed to replace template/CSS changes if you want to get into more specific or advanced changes.

Beyond that, it's targetting basic visual changes and not structural changes. This is why you don't see things like margins and width/height being expected here. In many cases, changing one or both of these will lead to layouts that break unexpectedly. Of course, you can still expose these in custom properties if needed.

In terms of the reduction of background properties, it's mostly because after a basic image/gradient and a color, the possible properties get quite advanced. Background positioning is quite advanced and varied to the point that if you knew how to change it, you almost certainly understand CSS anyway. Background repeat actually has more options than we even supported in XF1, for example.

Though to follow up on your latest comments...

So for that reason, I set it up so that if the admin only wanted to change the sprite (but the coordinates were the same), they only have to change 1 property, rather than having to hunt it down in the LESS template. If they need to change coordinates for one or more properties, that's available right there on the same page.

It sounds like you really want a property that represents the path to the image then. You should have this anyway, since there is not generic image path property any longer.

Speaking of style properties, is there a rough "equivalence map" for the XF1 properties to the XF2 variants anywhere? Things like @primaryLighter and @primaryLighterStill etc.

The colors are just numbered now. 1 is the lightest and 5 is the darkest for primary, 1 to 3 for accent (secondary). You can mix colors if needed to generate new ones, though that's not ideal.

Generally speaking, templates shouldn't use palette colors directly if avoidable. Use a more semantic color (via basic colors) when possible or consider creating a property for your specific usage if that's not appropriate.

 

[DragonByte Tech]

It's probably worth noting that the purpose of style properties has always specifically been to allow simple and common changes without going into the templates. It's not supposed to replace template/CSS changes if you want to get into more specific or advanced changes.

[...]

Makes sense, if I understand you correctly I should consider moving everything that doesn't have a dedicated style property field directly into the LESS template, as it should only be edited by advanced users.

It sounds like you really want a property that represents the path to the image then. You should have this anyway, since there is not generic image path property any longer.

Do you mean my style property should only be the image path, and all the background co-ordinates should be defined in the LESS template directly?

The colors are just numbered now. 1 is the lightest and 5 is the darkest for primary, 1 to 3 for accent (secondary). You can mix colors if needed to generate new ones, though that's not ideal.

Generally speaking, templates shouldn't use palette colors directly if avoidable. Use a more semantic color (via basic colors) when possible or consider creating a property for your specific usage if that's not appropriate.

Gotcha, I will definitely keep an eye out to avoid using the palette colours if I can avoid it.

My last question is about gradients, I found this example: background: linear-gradient(0deg, @xf-contentHighlightBg, mix(@xf-contentHighlightBg, @xf-contentBg, 50%));

I'm familiar with about 0% of this, where can I go to read up on what each of those parameters do? I had a quick Google for linear-gradient but that doesn't appear to be the same as what's happening here.

Thanks for taking the time to hold my hand here, I really appreciate it


Fillip

 

[Mike]

Do you mean my style property should only be the image path, and all the background co-ordinates should be defined in the LESS template directly?

In this case, just the path to the image, if you want people to be able to replace it easily (with one that matches the sprite).

My last question is about gradients, I found this example

This is half CSS itself and half LESS.

linear-gradient() is CSS: https://developer.mozilla.org/en-US/docs/Web/CSS/linear-gradient
mix() is from LESS: http://lesscss.org/functions/#color-operations-mix

(And the @ properties are from XF, though written in a LESS-style way.)

 

[DragonByte Tech]

In this case, just the path to the image, if you want people to be able to replace it easily (with one that matches the sprite).

Gotcha, I'll make the change now.

This is half CSS itself and half LESS.

linear-gradient() is CSS: https://developer.mozilla.org/en-US/docs/Web/CSS/linear-gradient
mix() is from LESS: http://lesscss.org/functions/#color-operations-mix

(And the @ properties are from XF, though written in a LESS-style way.)

I've got some reading to do

Much appreciated, if I get this wrong I'm sure customers will let me know once the mod is released


Fillip