Implementing custom framework; how to reduce Bootstrap dependency

Help / Discuss
, , , ,
#1

Salutations, XWiki Forum.

Short Version: How can I reduce (or remove) my dependency on the Bootstrap framework? Specifically, I am developing a custom framework and have a great need to normalize and simplify CSS/LESS classes and rules.

Long Version: I’ve been spending the last few months developing a heavily modified custom skin, which has actually been going pretty well. I was wondering, though, if it was possible to move away from the Bootstrap framework, as it’s quite overkill for our use and is difficult to adhere to our brand and style guidelines.

My mission is to revamp the CSS/LESS to be as minimal as possible, with emphasis on normalizing a lot of the duplicate and redundant classes and rules.

For example, Bootstrap uses the classes btn and btn-group, but the buttonGroup.css resource uses the classes button and button-group.

This makes it particularly messy when trying to keep style consistent, as I find that I’m often having to write extra rules to account for such special cases.

I’m able to modify any of the resources easily, so that leaves the Bootstrap framework to be the problem child. I’ve already begun consolidating the source .less files as well as I can, but so many components (.js files, .vm files, default and application pages, etc.) already have code for Bootstrap classes. I was hoping there would be a way to modify them without having to search for each class through Solr and go manually modify each individual page.

If I could even have access to the page content from the file system, that would make this task monumentally easier.

I understand this is an odd request and probably advised against (I’m prepared to handle future pitfalls as they come, e.g. upgrades, extensions, etc.), but I would greatly appreciate any assistance that can be provided.

Thank you, XWiki developers, for creating and making available this fantastic platform. I have so many ideas for using it in my organization, I fear I may not live long enough to implement them all!

#2

You need to create a custom Skin. More about Skins at:

For example, the old (pre 2014) Colibri Skin (https://extensions.xwiki.org/xwiki/bin/view/Extension/Colibri%20Skin ) was not using at all Bootstrap. Sources at https://github.com/xwiki-attic/skin-colibri/tree/master/xwiki-platform-colibri

The templates are on the file system and you will be able to customize them from the .vm files. Now, there are a lot of applications that have their own custom sheets, and these need to be modified from the page level.

So the Skin will be able to affect the default views, but some applications might still use Boostrap classes (since we recommended Boostrap as ok to use). Now, you can have some mappings and extends to cover such cases. It all depends on how ‘minimal’ you need to be. If you control the application and extensions that will be on the wiki, maybe you can cover all the cases.

We are providing Boostrap and try to be as ‘inclusive’ as we can, trying to cover as many use cases as possible. Flamingo’s intention was not to be ‘minimal’.

So, as conclusion: just create a new Skin.

Off topic: I would be curious where do you go with this direction and also maybe you will make the skin open source. There is an investigation about a new skin in XWiki (https://design.xwiki.org/xwiki/bin/view/Proposal/Skin10x/ ), but the focus was more about migrating to Boostrap 4 or 5, not really getting read of Boostrap.

1 Like
#3

I appreciate your detailed response!

I suppose I should have been more clear in my original post. I have already been working on a new skin, manually modifying/creating the .vm template files and .less XWiki/Bootstrap styles. (Which, I might add, has been the most colossal learning experience. There’s no better way to learn the platform, in my opinion.)

Now, there are a lot of applications that have their own custom sheets, and these need to be modified from the page level.

This is really where my concern lies. I was hoping there would be a way to access these sheets from the file system similar to how I am able to access and modify the files for a custom skin. The overlapping styles across different sheets are driving me bonkers!

I’ve looked at that proposal and probably would have foregone this endeavor if Bootstrap 4+ was in place, but sadly, I don’t have that luxury of time. I would absolutely be open to making this publicly available once complete, though I fear it may be too stripped down for others to find useful, as we’re developing it for a knowledge base for our software platform with very specific styles and components in mind.

Once I get it stable, however, I am up for the challenge of making it more universally customizable. I can’t promise an ETA, but I would love to develop it so that it can be shared with the community.

1 Like
#4

I don’t have an answer for this. Each extension can create its own velocity macros or provide custom styling. Ideally they should use as much styling as possible from the Skin, or use the Color/Icon themes variables, but in terms of structure we don’t really enforce anything. Some might use Bootstrap classes, so might need a fallback, mapping for those classes. Again, the work load depends on how many / which extensions you need to support / need.

1 Like
#5

Ah, I figured that would be the case. I’ve been using XWiki for only a few months so I know that there are still many things I need to learn about the platform, but the pieces are starting to fall into place.

Thank you very much for taking time to answer my questions. Once I break ground on open-sourcing my skin I’ll definitely be sure to let the community know.

1 Like