Style Padding Not Working

Has anyone noticed that the label style padding in a web project looks ok in the IDE but when it renders to the browser e.g. IE / Firefox on PC it appears to ignore the padding. Having checked the label with Firebug the padding is not being included in the CSS style so it is not a rendering issue it is that Xojo is not outputting the style correctly. Is this a bug?

Which version of Xojo? In Xojo 2014r1 for Mac the padding is included in the CSS and I can clearly see the effect in FireFox.

This is a bug that was reported for 3 ½ years.

please vote:

feedback://showreport?report_id=14863

I am running Xojo 2014r1 for Windows. It was working when I first started the project and then just stopped. The odd thing is that now that I have gone back to Xojo to have a look it appears that the properties window for all the pages with the label is not displaying correctly.

You will see that the Super is missing, the style is missing, they just seem to have vanished.

Sorry meant scope is missing not super. The section is missing and is under the behavior, its all a mess.

I have managed to fix the issue of the missing bits by deleting the plug-in cache so that it gets recreated and the screen now displays correctly but the padding is still not working as per the bug report.

I’m not seeing it. The style is included in the CSS, but it’s not affecting the control (Firefox on Mac also). Are you sure you’re not seeing the effect of your custom controls?

It appears that the problem is that padding attributes don’t cascade down to enclosed div elements. As you know, the Xojo framework creates multiple elements for each control. The class attribute, which links to the CSS, is assigned to the parent or outermost div. For most other attributes, this will affect the inner divs as well. But not for padding. For padding to work, the class has to specified on the closest div element, or on the final element itself (in this case, a p element).

It’s not a custom control (new, empty project), it’s me not paying attention to what I’m doing :slight_smile:

I dragged a tall WebLabel and applied a style with 72px of top padding plus borders. I’m seeing the centering when Multiline is off. Turn it on…yeah, no padding was ever there. Because the IDE and web page are a little different to begin with I thought I was seeing padding.

My first thought was to recommend the styling tools in Web Custom Controls, BUT as you point out the issue boils down to how the WebLabel control uses nested HTML. WebStyleTD and WebStyleExt will apply to the same div that WebStyle does.

WebStyleTD in the next release of Web Custom Controls will be able to solve this easily. I should caution though that I don’t know why Xojo hasn’t fixed this. I don’t know if padding on the inner div affects coordinates reported to events or something. Or if the bug just hasn’t gotten any attention with everything else on their plate. WebStyleTD and WebStyleExt let you set and manipulate any CSS. They work well…two of the best and most useful parts of my kit…but I can’t guarantee that changing a particular CSS property won’t affect something else. Example: if you use WebStyleTD to hide a control then WebControl.Visible isn’t going to work so well.

I’ll use this as a test case this weekend and see if I can blow up my web browser.

Below is an example of what I am seeing in Firebug:

[code]

Mossop Natural Remedies - Prescription Tools

[/code]

The styPageHeader has padding left=20, top=4, right=10, and no bottom padding. The CSS below is copied from the styPageHeader style within Firebug and you can see that their is no padding at all.

color: #004200; font-family: "Arial",sans-serif; font-size: 20px; font-style: normal; font-weight: bold; text-align: left;

I did a quick test by manually adding the padding-left to the inner element and tested the mouse up X position and it reports the same with and without the the padding being tweaked.

Their may be a possible workaround to this that could work but my CSS is not great but here goes.

.styPageHeader P { padding-left: 20px; padding-top: 4px; padding-right: 10px; }

If you add this to your HTMLheader then it will apply the padding to the inner part and does work.

[quote=76974:@Nathan Wright]

.styPageHeader P { padding-left: 20px; padding-top: 4px; padding-right: 10px; }

If you add this to your HTMLheader then it will apply the padding to the inner part and does work.[/quote]
That’s a good idea. I hadn’t thought of overriding the style of the inner element. This restricts the “overriding” to just that class.

Thanks Jay for pointing this out in Feedback Case #14863. Has been a problem for some time now, because I only do Web projects, and being new to Xojo thought it was something I was doing wrong.

Thanks Nathan for finding a work around. It works !!!

I have another feedback report #34849 that is “sortof” related to this but cannot be fixed like this because the inner element is not linked to a class. Any ideas?

Should have mentioned that it was a button not showing the cursor that was selected with the IDE.

@Greg O’Lone - is there any possibility for getting feedback://showreport?report_id=14863 fixed? It’s now Jan 2015 and this still isn’t working right.

Here’s the generated Style:

#tag WebStyle WebStyle stLabelrightJust Inherits WebStyle #tag WebStyleStateGroup text-align=right misc-background=solid 555555BE padding-right=12px text-color=FFFFFFFF corner-topleft=12px corner-bottomleft=12px #tag EndWebStyleStateGroup #tag WebStyleStateGroup #tag EndWebStyleStateGroup #tag WebStyleStateGroup #tag EndWebStyleStateGroup #tag WebStyleStateGroup #tag EndWebStyleStateGroup End WebStyle stLabelrightJust #tag EndWebStyle

In the IDE it looks correct, but the background is clipped at the end of the label text in all browsers.

As an aside, why are there 3 additional WebStyleStateGroup entries in the code?

The current style system has no way to represent which properties cascade and which ones don’t. Once we fix that, each control needs to have more say over where the webstyles properties are applied. As an example… WebLabel consists of two nested elements, so we can have the control positioning mimic the desktop. Padding doesn’t cascade in css, but it needs to be applied to the inner element. Other properties (like background color) really need to be applied to the outer element.

Unfortunately this wasn’t considered in the original design and fixing it isn’t easy without breaking existing user projects. I think we have a good handle on what needs to be done, but need to find the right way to implement it. :slight_smile:

Understood.

I tried to add @Nathan Wrights patch to my project, but it doesn’t appear to work properly in 14r3.1 - or (and this is where I’d place my bet) I’m not following the logic of implementing the change. Ideas or pointers?

It’s more likely because of the changes made to WebLabel recently. We fixed a number of html rendering bugs which likely breaks his code.

Interesting, I just came here with a demo project thinking I would report a bug that I’ve just noticed and it’s been there for a long time now :wink: In the example I just put together changing the padding definitely changes the label, but it seems to actually increase the size of the label by the padding amount rather than apply any padding which should be inside the border, not extend the border. Sigh…

As a hacky temporary work around you can do this in the shown event of the label. In my case the label isn’t visible when it’s first shown so I can adjust this and when the label is used it already shows the proper padding. If your label is shown when the page is opened then it will first show with the incorrect padding and then pop to the correct position with this, there is no way to do this before the control is visible. You could always make a custom web control with whatever you wanted and not use labels, I’ve done that in some places too but this is easier and may suffice for many people.

dim js() as string
js.Append( “try{Xojo.get( '” + me.ControlID + “’).children[0].style.paddingLeft=‘14px’;”)
js.Append( “Xojo.get( '” + me.ControlID + “’).children[0].style.paddingRight=‘14px’;}catch(err){}”)
self.ExecuteJavaScript( join( js, "”))

you can add any more lines for other paddings or add the global padding and not do them separately depending on your needs. Wrapping it in the try{} block keeps any errors from displaying the “help us to improve this” dialog that pops up if this stops working because it wasn’t actually displayed and such. I know we’re not technically supposed to do that sort of thing, and it may also break in future versions but it will do it for now.

I tried to set the padding via css, and everything works except left.

I had to resort to change the left property :

[code]Sub Shown()
dim js as string

js = “var lbl = document.getElementById(’”+me.controlID+"’).getElementsByTagName(‘div’)[0];"
js = js + “lbl.style.left = ‘20px’;”

self.ExecuteJavaScript(js)
End Sub
[/code]

[quote=273598:@James Sentman]As a hacky temporary work around you can do this in the shown event of the label. In my case the label isn’t visible when it’s first shown so I can adjust this and when the label is used it already shows the proper padding. If your label is shown when the page is opened then it will first show with the incorrect padding and then pop to the correct position with this, there is no way to do this before the control is visible. You could always make a custom web control with whatever you wanted and not use labels, I’ve done that in some places too but this is easier and may suffice for many people.

dim js() as string
js.Append( “try{Xojo.get( '” + me.ControlID + “’).children[0].style.paddingLeft=‘14px’;”)
js.Append( “Xojo.get( '” + me.ControlID + “’).children[0].style.paddingRight=‘14px’;}catch(err){}”)
self.ExecuteJavaScript( join( js, "”))

you can add any more lines for other paddings or add the global padding and not do them separately depending on your needs. Wrapping it in the try{} block keeps any errors from displaying the “help us to improve this” dialog that pops up if this stops working because it wasn’t actually displayed and such. I know we’re not technically supposed to do that sort of thing, and it may also break in future versions but it will do it for now.[/quote]
As you say, don’t do this. Changes like the one in 2016r1.1 have a high probability of breaking this code.

Could you make two images showing what you expected and what you got, and post them so I can take a look?