As designed Add-on style properties aren't kept

I would say contact the developer to remedy that and if it is an official add-on make a suggestion for a change.
This is not always possible. Many devs are responsive, some aren't or it's not always convenient. Lots of little changes to support the add-ons here.
Isn't there an expectation that if you uninstall a add-on there will be data loss including any custom styling that may have been done?
No, there isn't.
Wouldn't it be best to have a development board just for UIX and official XF add-ons? So everyone is on the same page then handle on a separate board all testing and compatibility issues.
I don't see how this helps. The issue is even when people install products (your products as well) depending on what they do style property values won't be retained. This means that if you edited something to work better with your theme when having that addon installed it gets lost. Developing is just half the issue.
 
So, just so Im clear. We should not edit style properties for add-ons in third-party resources?

So third-party authors should not be editing other style properties, they should say use CSS exclusively? I just want to make sure thats the official position on XenForo, this is becoming near impossible to manage on our end and it'd be good to move on I guess.

Say I want to edit XenPorta or Featured Threads, I would make those edits in CSS and NOT in that add-ons designated style property for my theme. As thats the crux of the issue.
 
@Chris D sorry to bug you on this, we just want to make sure since we'll have to rewrite somethings. We'll likely remove style properties from our add-ons, and just use CSS.
 
Yeah given that we're not planning to make any changes here, and you're unable to manage the process by keeping the add-ons installed, you'd have to make the changes using CSS.
 
Yeah given that we're not planning to make any changes here, and you're unable to manage the process by keeping the add-ons installed, you'd have to make the changes using CSS.
Its not us, its customers uninstalling then reinstalling add-ons, those customizations wouldn't be kept depending on install order.
 
Well, I just meant that having and keeping all of those add-ons installed during development may not be practical for a large team anyway, but yes, that too :)
 
Well, I just meant that having and keeping all of those add-ons installed during development may not be practical for a large team anyway

That was the main issue I had brought up, I guess the other issue is that if we do need to make a change (say someone uses #FFF as a color somewhere) we'd have to overwrite it with css, and any style property changes someone makes won't get applied
 
But OK if thats the official standpoint, this will be sorely missed (its the little things you miss :P) We'll change that methodology.
 
We'd generally expect the issues found in many XF1 add-ons to not be as prevalent in XF2 add-ons if people are following a similar approach to us in terms of core and add-on style properties. You may well have noticed that we hardly use any style properties for RM and MG and certainly the core ones cover fewer areas. With the BEM approach to our core CSS and a better thought out colour pallet and some of the new features such as lightening/darkening core colours in Less requiring fewer "new" colours it should be much more common for developers to inherit from our core styling and properties rather than rolling their own as was often the case in XF1.
 
We'd generally expect the issues found in many XF1 add-ons to not be as prevalent in XF2 add-ons if people are following a similar approach to us in terms of core and add-on style properties. You may well have noticed that we hardly use any style properties for RM and MG and certainly the core ones cover fewer areas. With the BEM approach to our core CSS and a better thought out colour pallet and some of the new features such as lightening/darkening core colours in Less requiring fewer "new" colours it should be much more common for developers to inherit from our core styling and properties rather than rolling their own as was often the case in XF1.
This sums it up well, though to get everyone on board won't be possible.

Example: https://xenforo.com/community/threads/chat-2-by-siropu-paid.136023/post-1216342 and https://xenforo.com/community/threads/chat-2-by-siropu-paid.136023/post-1216689
 
The fact that you had to do that though is the fundamental flaw, you'd have to go through everyone's code and have their developer fix it, and some devs go missing unfortunately. It's indeed quite nice of you to do this, but I'm not sure if we can rely on this as THE method for making sure themes can work with add-ons in the majority of cases.

The solution here is "build add-ons correctly" but I mean XenPorta used Papyrus in their latest add-on as one of their title fonts, this is just not going to happen. Just saying.

Thanks @Chris D we'll figure it out appreciate the response.
 
Well if a developer doesn't want to put effort in to avoid potential style issues then that's a pretty poor show, IMO. There's various tools that would mean that it isn't necessary to use any hard coded colour, and would instead allow them to use xf-diminish and xf-intensify if they can't find a default colour that quite works for their usage. Also bear in mind that those two functions either darken or lighten a colour depending on whether the style is set as "Dark" or "Light".

Hard coding the colours in that way is not necessary.
 
Sorry for the double post and for hijacking, but how would I go about constructing a green ribbon, e.g. this:

1516991679975.webp
At the moment, I create a new style property, but I would like to support all skins out of the box without customisations needed, so any advice would be greatly appreciated :)


Fillip
 
For something as unique as that ( likely would look fine on dark and light styles ) just simply hard code the color, basically how the online marker is done by default in XF2.
 
Top Bottom