Xojo Web 2 Tips For Customization

Xojo Web 2 Tips For Customization

Perhaps my last articles on Customization for Xojo Web 2 helped you a little bit. Now you are eagerly developing fancy GUIs and you’re happy with the results.

But does your Web App look the same, everywhere, on each platform? Let’s not start yet with mobile devices, tablets and all kinds of iThings. Let’s first concentrate on macOS only and “Desktop”. I’m currently running Big Sur and have Chrome, Firefox and Safari in my hands for testing (all in their latest Release. Let’s take again the example of the “ Closing X button “, which we developed in:

The sad news

I am running the code in the debugger and opened the URL in all 3 browsers in parallel: but funny enough we get slightly different results.

What is happening here? Well, welcome to the world of web developers, all browsers had in the past big differences in how they were rendering HTML code. In the old days, Internet Explorer was a complete nightmare for every web developer. Things are now improving as the new Microsoft Edge Browser is built on Chromium, so it usually looks exactly the same as on Chrome. But as we can see even today there is a slight difference in all browsers. And only a very few people are working with calibrated displays. Did I mention Retina, HiDPI, True Tone, and Night Shift?

Conclusion: forget your dream of creating Web Apps (or even Web Pages) looking the same on all browsers. If you think that you achieved that your result will be presented the same, it only means that you have not tested enough! It is far better to design something which looks pleasant enough on all major browsers, on all major platforms and the most common resolutions.

You don’t believe me? Okay, fair enough. But then please explain to me why companies like the following are successful businesses. ;-)

It is just a fact, better cope with it!

How to find out what I can change and where?

You could use Brackets[], but are there other tools out in the wild? Yes, your browser can help you with these tasks!

Google Chrome

Let’s open our example in Google Chrome. With a right-click you can launch the inspector:

Now you will see the involved code of the element you are hovering over and clicking into:

Now switch the tab from Styles to Computed:

Try again playing around with the existing values and adding your settings.

Safari

In Safari you will find the Web Inspector in the Develop Menu. Please note that you have to activate this function in Safari’s preferences first:

As within Google Chrome, the Safari Browser will show you now the respective code depending on the object you are marking in the browser:

Click on the following symbol:

in the following menu area in the middle of the screen:

Now you can mark the object you are interested in and you will get the following view on the right-hand side you will see the respective CSS code:

As within Chrome you can see as well a box model:

Why can’t I change all CSS elements from within Xojo Code?

Firstly, Bootstrap is a framework, which means that it is a CSS construct which you have to change before your app is running, but those changes will then apply to your whole bootstrap template, which means for all pages and dialogues.

Secondly, Xojo is using its own Framework. Let’s try to compare it to vehicles. Xojo is rendering at the run time all sorts of controls. Let’s say a WebButton is a car, a WebLabel is a truck, etc.

You can with the style.value attribute injects your own CSS to colour your car or your truck, but it would be insane (from a Xojo perspective) that you can change with your code that your truck would become a car and vice-versa. Otherwise, we would break their framework. Remember that Xojo has to react to different events, etc. means the Xojo Framework needs to keep control over a whole range of aspects.

This is solved partially through “CSS inheritance”. So when the “opening” or “shown” events are firing, we are just too late to the party for many changes*.* You can change colours, font sizes, margins, paddings, etc. But you won’t be able to change everything. Unfortunately, you have to use trial and error to analyse what is working and what is not. But please don’t forget: you might run into a situation where changes in CSS in your browser might very well work, but they won’t change anything when put into your code. The reason is simple: in your browser, you have so say a “static status” in your browser (though the app is still running). You are manipulating this static version, not the real beast.

What should I change and what not?

Global Changes

If you are working for a customer whose corporate design is somehow “green-ish” then it will be best to adapt your bootstrap theme such that it will reflect this customer’s design rules. Those changes will be needed “everywhere”. A special font is a good example as well to illustrate this approach. You don’t want to apply this change on every control but centrally.

Individual Changes

If you are facing a situation where a certain element doesn’t fit exactly to the scenario you want to build, then it is fair enough to customize this control individually. If you are doing these through the standard style options Xojo is offering you are most likely safe that these adaptions will survive in future Xojo releases. This said, I still urge you to comment on such changes in your code with something you can later search for, e.g. “// DC!” (for Design Change).

For the time being, I suggest reducing your own CSS injections to an absolute minimum. What will work now, might no longer work in future releases. Hence, you should comment on such changes very, very precisely. But they are an excellent approach to fine-tuning some difficult design patterns, for instance, padding of images, etc.

Did you find this article valuable?

Support Jeannot Muller by becoming a sponsor. Any amount is appreciated!