WE and Styles / CSS

Targets Web
1

First, I should say up front that I’ve been developing for the web longer than with Xojo, and I’ve been developing with Xojo / RealBasic since v3…

I also think I understand the strategy behind Xojo to maintain x-platform development consistency and keep WE development firmly in the Xojo realm (as opposed to requiring web/html/css/javascript knowledge. Overall I applaud this idea and think WE is an amazing tool.

That said (you knew it was coming), there seems to be some disconnect when it comes to styles.

A few points:

  • I don’t have “normal” styling control over WE controls like I do with Desktop controls. I’m just referring to some of the basics like bold, font size, etc. I realize this needs to be implemented using a style… but see below.

  • webStyles are a fairly clean way of implementing styling of controls & page elements without requiring the developer to know CSS. The problem is that I can apply only one style to a control. This is decidedly un web-like (and for a Xojo element that is already un Desktop like). CSS is Cascading after all, and we lose that ability. While you do support pseudo styles like hover, active, etc it still doesn’t cover enough cases. When developing in WE I end up with multiple styles that are super-sets of each other: bold, bold-with-background-color, bold-with-background-color-and-border… you get the drift.

  • Also, WebStyles should allow developer additions. There are many cool CSS things that can be done by developers and keep graphical processing in the browser.

So, I propose that styles be applied in a dictionary form, allowing for applyStyle() and removeStyle() methods… and perhaps simpler styling available in the controls themselves? Finally, a “custom…” choice at the bottom of webStyles into which we can work our magic if we choose.

Anyone agree? I thought I’d pose it to the group before I submitted feedback items…

2

The Style controls in Daniel Taylor’s Web Custom Controls address a lot of this.

3

Agreed, and I like his stuff.

But I’m hoping to have it addressed at the “native” level (IDE, framework, etc)

4

Therein lies the problem. WE is supposed to be Desktop like, not web-like.

5

I agree… or at least I understand.

But if it were truly being desktop-like then we’d have the normal styling controls available in the IDE’s inspector and it would be implemented using styles behind the scenes.

My reasoning is that if they are going to depart from the desktop control attributes and require WebStyles for styling, then they could be expanded somewhat without running off the rails entirely.

I appreciate that it’s a delicate balance between the very complicated web dev environment and the Xojo environment. I also believe that with a few careful adjustments, those of us who want to develop in a more advanced manner could do so without negatively affecting the overall Xojo dev experience.

6

You can already do cool CSS stuff without using the WCC controls specifically. You can either do it by adding your own CSS link file to the HTML Header for the WE APP and then add all your tweaks within that file (my normal approach) or you can do it at a page level by adding a PageSource control to each page you want to tweak. You have to be a little careful with this approach as sometimes for styles hang around and overwrite styles with the same name on another page. As I say the first approach at the app level is the easiest. As a web developer you should have no problem doing this and getting all the benefits without Xojo having to be altered.

7

@Nathan yeah, I get it. really. And I appreciate the reply.

I’m just trying to get the tool at hand to improve for all, and some things are much better at the Xojo level.

For instance, I can add my own styles to my WE project outside the Xojo methods - I get this.

But I can only have one class associated with each control via the Xojo methods. So even if I want to work around Xojo and do cool things using CSS or perhaps using class selectors in a javascript library like jQuery, I still have to apply additional class names to my controls using some javascript hack that could easily break in the next version of Xojo, or even on the next update of the control from the server.

make sense? I’m not asking for the world here, just a little bit more in the IDE that could make life outside the IDE easier and less brittle.

8

Yeah I get what you mean about the the single class bit. I can just see if Xojo Inc are not careful they could start to make the styles stuff complex for general users. Maybe a simple approach would be the ability to be able to add your “extras” onto the class that is added. So for example lets say you select a style called “styListbox”. If their was a button next to the style where a popup appeared where you could add your own extra (external) classes and the same the styles then you could add whatever you wanted at the individual control level.