2016r1 added the “!important” rule to “background-image:none” (and also to other properties) in styles.
This rule was not defined in 2015r4.1.
There is a reason why this rule was added?
Regards.
Oh this I would love to know.
This change was made because the expectation of user styles is that they always override the framework styles. The vast majority of bug reports we have received over the years regarding WebStyles were because of this.
Hi Greg,
I’m not a css guru so my following comments are, possibly, wrong.
I don’t understand what exactly users are reporting as a bug.
For my knowledge the “!important” rule prevents any override on the affected property or, better, an “!important” must be overridden with another “!important”.
So this rule was added to avoid user changes on styles of the Xojo framework?
I’m confused.
Regards.
The other way around
It was added to make sure that styles users created in the IDE did override the default styles on controls in the framework
They didn’t always do that
If you are seeing something specific in one of your projects which is rendering incorrectly, please file a bug report.
Thank you for the explanation, now it’s clear to me what’s the root cause of the problem was.
I don’t see anything strange in my projects.
Simply last week I’ve made some changes using ExecuteJavascript on 2015r4.1 to add a background image to some labels.
These changes aren’t working on 2016r1 but adding an “!important” rule has restored the expected behaviour.
Best regards.
This new feature seems to have broken for certain controls the old method of adding to a webstyle CSS features not supported by Xojo in complementary style in HTMLHeader.
It still works for WebButtons, but not for WebRectangles anymore. The same program pre 2015R4.1 works just fine, and is broken afterward.
I know it was hack, but that was the only game in town.
It would be nice to have an “advanced” field as part of a WebStyle that enables entering CSS code to support features not available.
Some controls behave not very well with styles, WebSegmentControl to name one.
Properties that can’t be defined using the IDE style editor can be added without much trouble.
When unusual or complex styles must be used I think the best solution is to add the style to the page header using the same name of an empty style defined in the IDE.
[quote=260822:@Maurizio Rossi]Some controls behave not very well with styles, WebSegmentControl to name one.
Properties that can’t be defined using the IDE style editor can be added without much trouble.
When unusual or complex styles must be used I think the best solution is to add the style to the page header using the same name of an empty style defined in the IDE.[/quote]
WebSegmentedControl was a special case. It had styles that could never be overridden by a user style in versions prior to 2016r1 and they’d just ignore them. 2016r1 fixed that issue, but revealed a design flaw which caused other issues. The control has been refactored for a future version of Xojo.
Just FYI - this change was pointed out in the beta’s of 2016r1 at least from beta 4 onward
Except precisely the new webstyles seem to prevent that now for certain controls. WebRectangle is a simple div, it should be very simple, and yet, adding in header simply does not work.
Hence my proposal in <https://xojo.com/issue/43531>.
This project works in pre-2015R4.1, not after : customWebstyles.xojo_binary_project
yup, this change broke a lot of the custom things I was doing via execute javascript. I spent an awful lot of time learning how to work around that. I was working around some of the deficiencies with the style objects being immutable at runtime by changing the values myself at runtime. But you cant change it if someone in the chain of objects has set what you want to set as !important (which is horrible code, to me that reads as NOT important) I had to work around it by making yet MORE styles in my app that had different parents which didnt set the things I later needed to change. I had to add yet more custom javascript that will break later to work around this fix for styles not working 
So my fix that for a while reduced the number of styles I needed to load in my app and sped up loading times now has caused me to have to create yet more styles and slow things back down again.
Styles REALLY REALLY and truly need some woodshedding. I know this will cause pain throughout and probably all of us to do a little refactoring, but jeeze, fix it now and absorb the pain or have it kill us through the death of a thousand cuts over the next decade.
Not sure styles can be reasonably factored out of web edition & fixed on their own without touching the rest of web edition
Just the way it all hangs together
WebStyles are in fact CSS styles that take place in the header, The addition of a CSS code area in the webstyle that will become part of it in the DOM would alleviate all the hackish workarounds we have been forced to use.
A simple textArea in Miscellaneous called “CSS code (Advanced)” would do very nicely.
Yeah that’s the phrase I’d use for the WE CSS…
[quote=260945:@Michel Bujardet]WebStyles are in fact CSS styles that take place in the header, The addition of a CSS code area in the webstyle that will become part of it in the DOM would alleviate all the hackish workarounds we have been forced to use.
A simple textArea in Miscellaneous called “CSS code (Advanced)” would do very nicely.[/quote]
We should just let you write everything in a text editor 
The point of a rad tool is that it’s WYSIWYG - and putting a CSS field would pretty much guarantee that doesn’t happen any more
We all know Xojo Web is vastly underpowered, that WebStyles are extremely limited to be charitable, and that to get to a decent result, adding more powerful CSS is a requisite.
I do not see how having a CSS code field in WebStyles would terribly differ from what is currently done in App.HTMLHeader. Users do not expect what is placed there to be wysiwyg more than they would with that new feature. You could even have “Non Wysiwyg” indicated above the code editor.
As it stands, Xojo Web is indeed a RAD, but in order to get on par with current web design, it requires tons of JavaScript, CSS and convoluted methods to get there.
Don’t get me started on the Fisher Price philosophy.
A RAD tool like Xojo can’t be compared to more specific tools and javascript frameworks.
Up to now Xojo has not closed me in a cage where I can’t add javascript code or styles more tailored for my needs.
It’s not a perfect tool but has the advantage to let users to start prototyping fast, to build the application and to add any other requirement refinement.
This can’t be true for all Xojo’s users but I don’t know of some tool perfect for everyone.
[quote=260873:@Michel Bujardet]Except precisely the new webstyles seem to prevent that now for certain controls. WebRectangle is a simple div, it should be very simple, and yet, adding in header simply does not work.
Hence my proposal in <https://xojo.com/issue/43531>.
This project works in pre-2015R4.1, not after : customWebstyles.xojo_binary_project[/quote]
Substitute the WebRectangle with a Weblabel to get the expected result.
I am aware of all possible workarounds. Thank you.