Style Padding Not Working

Targets Web
21

[quote=273601:@Greg O’Lone]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?[/quote]

Well it isn’t broken with 1.1 so far… but we can’t talk about that here, these examples were not prepared with the .1 release if you know what I mean nudge nudge wink wink say no more…

This is a screen shot from a dynamically generated web interface to the home automation software that we write in Xojo :wink: The instantaneous power measurement there is actually coming from an arduino compatible kit that I also sell to read the calibration pulses from your electric meter and send them into the program via an xBee radio or a Wifi interface. I love my job :slight_smile:

The label you’re interested in is the one that says “bandwidth throttled” This is a text label locked left and right across the whole page just under the menu bar that only displays if there is a message for the user on the web page. The message is right justified for no good reason other than I liked that. This is what it looks like without any padding which I don’t like at all but thats not Xojo’s fault:

If I add right padding to it via the webStyle then I get this. Which makes sense knowing that the text is a child of the overall control and the style is applied to the parent container. The problem is that the width of the internal element are not relative so they don’t adjust and take into account the padding of the parent. Another potential fix would be to adjust the size of the internal child element by moving it right the right padding and reducing it’s size by the left plus the right padding… I’m not sure if there is a way to force the padding from the parent container to fall through to the child without something like that?

I feel that the background should not be affected by the padding, but perhaps I”m wrong about that? Maybe that is how CSS works I don’t know…

This is how I feel applying padding should make it look and this is the output from my hack above:

when the hack breaks I’ll probably switch to using a rect to hold the background and putting the label on top of it with the proper offset… I know that would be a work around that would not break later, but thats not always a simple option. These controls are created with the colored background as a text label with styles applied that change the color and the text orientation. With padding the way it works now it breaks their layout, without any padding the text showing the level or the state is against the border which looks horrid, but with the hack applied they look like this which seems appropriate to me:

I COULD rebuild those with extra text elements in the middle with the proper offsets, but the strangeness with how embedded container controls handle locking and initial size drawing it would mean even more commands at loading to conform the location of everything, not impossible, but adding complexity that I don’t feel should be that necessary.

22

Ah right. You’re running into the same issue that most WebStyle bug reports are about and that is the fact that we designed each webcontrol with two levels of structure… one outer div used to determines where a control is and what it’s bounds are and then an inner div which determines the appearance of the control… and then we gave you one style control which can either be applied to the outer div or the inner div. This is a problem that we intend to fix when the web framework overhaul is done.

23

Can I volunteer to be on some kind of committee for when you do this?

24

Ditto

I use the Web framework almost exclusively now and have added tons of libraries to do JQuery, JQueryUI, Material Design, Responsive Web Design, etc…

The style revamp alone is very important to me:

  1. Build Styles on the fly and edit them.
  2. Assign multiple styles to controls (should be array of classes assigned to the element not just a single class)
  3. Support Responsive Design (Almost all mobile friendly sites use a column based grid system)
  4. Stop Xojo from using !important on the styles, this is a bad practice and is hard to overwrite.
25

You are - you’re a beta tester

26

By time it reaches Beta many of the design decisions have already been made.
For example drag and drop for instance - could have been a lot better with a Jquery approach - setting drag axis, drag units, etc…

27

Yeah, I meant more of a “let’s ask people who know web technologies before we do anything” committee.
It might have prevented the !important headache…

28

Yeah that how the process works with pretty much every product

when the original web framework was designed Jquery wasn’t anywhere near where it is today
it wasn’t viable as the basis for a framework in late 2009/early 2010
retrofitting it at that time to work how we needed it to work wasn’t practical
so we wrote our own
now that Jquery etc HAVE evolved a lot it MAY be possible to use one of them as we need it to work
But it’s not a “hey lets switch” and tomorrow its done

And its still not design by committee

!important came along because it was the ONLY way to solve a specific issue with the way things work TODAY
But that doesn’t mean it will be that way forever

29

Well this is actually a really good example. Consider WebToolbar for a moment:

  • To build and style a control like WebToolbar you need to be rather specific in your CSS. e.g. “.webtoolbar tr td”
  • To make WebStyles work the way our users expect (object inheritance, applying them to any WebControl), they must be class styles. e.g. “userstyle”

The user web style would never be specific enough to override the built-in style without !important applied. That is why we did it this way, because otherwise we would need to push down a version of a webstyle as ID styles for each control it was applied to or apply the styles directly to each of the tags in the DOM. To top it all off, we target more browsers than the average developer even considers and they’re not all as forgiving as the others. And Norman hits it right on the head… the many frameworks that we might have used, either didn’t exist or were in their infancy back then.

30

Having written quite a bit of javascript and having begun back in the days around when you were working on this framework I can only say YUCK, they were horrible. CSS was horrible. It all still carries a lot of baggage that makes certain dark corners of it still horrible.

The reason I use this is because you have made it work so much better and easier than what I can do myself in raw javascript and CSS :wink:

Just because I want you guys to do the impossible doesn’t mean I don’t appreciate what you’ve accomplished! I know exactly what you’ve accomplished because I’ve worked in the dirty details myself. But that won’t stop me from asking you for the impossible :slight_smile: sometimes you pull it off and I love it!

31

wait… I got distracted :slight_smile: I can apply a style to the inner div?! Because thats all I’m doing with my hack… how do I do that and why don’t I already know how to do that!? :wink:

32

No, you cannot. In the framework, it’s an either/or situation because we have no engine for separating cascading vs non-cascading elements from one another. Consider the following:

CSS elements like text font (Font Family for instance) cascade downward through contained elements. So if you apply Helvetica to a WebPage, the whole page and its contents change to Helvetica. On the other hand, things like padding and margins do not cascade down to children. It would be chaos if you applied 10px of padding around a page and every contained control and control piece also got 10px around them. Let’s say that we solve that (we haven’t yet, but it’s a thought experiment), some browsers apply styles differently than others, to the tune of whether padding and margins are inside or outside of a control’s boundary. Our framework applies almost everything to the outer div with a bit of math to even out the discrepancies between the browsers. I only wish we had used a CSS reset to make sure all of the browsers had a common starting point way back in the beginning.

To be fair, it has always been up to the browsers to determine how things are displayed, so different isn’t exactly incorrect, just a different interpretation of the rules. Things have gotten much better over the last few years, as long as you only support the latest-greatest browsers. Including support for Internet Explorer 9 certainly makes things “interesting.”

33

Ah, you meant “you” as in an entity wishing to write CSS code, not necessary “you” as in a xojo developer :slight_smile: Yes, believe me, I know the pain of trying to work in raw javascript/CSS without one of the major frameworks and not have the browsers just laugh at you, especially any of the internet explorer family.

34

I started to build my Jquery and Jquery UI libraries off of a base webframework.
Something like:

myControl.jquery.css("width","50 vh").runScript

I would love to see something similar with Xojo, people could build their own javascript libraries off of Xojo’s base javascript library.

You should be able to simply append Javascript objects together to make complex scripts and either store them browser side or call “runScript” which calls the execute javascript event.

dim script1 as javascript = myControl.jqeury.css("width","50 vh").css("height","20 vw") dim script2 as javascript = myOtherControl.jquery.css("background-color","red") dim script3 as javascript = script1 + script2 script3.runScript

I also started a rough CSS library but having base Xojo classes with the essentials pieces and a standard for everyone to build off of would be more helpful. And in the nature of Xojo it should auto add the browser prefix (i.e. -moz -webkit) to styles and simply work cross-bowser types.

[code]myControl.styling.backgroundColor = &cff0000

dim myStyle as new webStyle
myStyle.backgroundColor = &cff0000
myControl.addStyle(myStyle)
[/code]

35

Maybe a temporary solution is 2 kinds of access to the css level of things. If we had an “official” method of accessing the CSS of a control and it’s children DOM objects then we wouldn’t need to hack it. The regular styles could still apply the way they are, but we could have an officially sanctioned method of overriding some at the control or container level.

It would be nice to be able to setup specific ones during the open event so that they would go to the browser with the control and not have to be updated later which you can’t do with the hack. I know thats not a particularly elegant solution but it would allow tweaking at the control level which is all most of us want to do. Get things like dynamic colors and font sizes that don’t have to be done through dozens of unchangeable style objects…

myControl.css( “value name”) = “value”

which would be a keyed list of everything in the controls style=“” param. Add or change things would result in them getting sent via the execute javascript type thing. It would apply only to that control and not change the style object at all. You could still do some fudging to know which child object of the control you would send them to if it’s things like the labels where background and padding and borders would obviously go to the parent while font settings would go to the child object.

While it would be nice to have a fully dynamic style interface where I could create one in code and send it to a specific control, thats obviously not going to be possible in the short term. I can do everything I need to do just manipulating the individual controls style via the execute javascript hack, but that will break periodically as things change in the child layout inside the controls. So give us an official way to send specific CSS to a control and I’d be a very happy man :slight_smile:

I’ve already replaced some of the controls in the interface with custom controls so that I control the children and will do the rest if I have to, but just being able to send the CSS to a control in an official way would save ME a lot of work while creating a lot of work for you :wink: It still seems like a more reasonable solution than reworking the style objects completely from scratch though.

36

The best thing I can suggest is to put these ideas into feature requests.

37

<https://xojo.com/issue/41736> was submitted on Dec. 2015 and it’s now ranked as 163rd.
Please vote this feature request.
Thank you all.

38

I created a webcontainer ctPaddedText and placed a weblabel lblText into it with the same width and height as the webcontainer and lblText.LockLeft = True, lblText.LockRight=True, lblText.LockTop = False, lbl.LockBottom = False.

Then I createded the following method in ctPaddedText:

Sub Init(mText As string, mStyle As Webstyle, mTextHeight As integer, PaddingLeft As integer)

		  Var mWidth, mTop as integer
		  
		  mWidth = Self.Width - PaddingLeft
		  if mWidth < 0 then
		    mWidth = 100
		  end if
		  
		  mTop = Round((Self.Height - mTextHeight)/2)
		  if mTop < 0 then
		    mTop = 0
		  end if
		  
		  lblText.Left = PaddingLeft
		  lblText.Top = mTop
		  lblText.Width = mWidth
		  
		  lblText.Text = mText
		  lblText.Style = mStyle

End Sub

On my webpage I drag the webcontainer on it, assign a webstyle and place the following code into the open-event of the created instance of the webcontainer:

me.Init("Your Text here", yourWebStyle, 22, 10)

The “10” says: Place lblText 10 Pixels from the left border, see lblText.Left = PaddingLeft in method “init”

Works for me, hope that helps.