In an effort to be consistent, many consider the use of inline styles taboo and prefer to use CSS classes only. I’m not going to say inline styles don’t have their place. But if one was going to use CSS classes “exclusively”, then the inline styles would need to be removed from all tags so that the CSS class would become the style of the tags. Is this an easy task in AS? I’ve already noticed if you add a CSS class to a control that the inline styles do effect the result in the browser.
AppStudio constructs style attributes for elements from the properties which are set when the control is defined at Design Time. These are put into the actual HTML definition and appear in index.html.
There’s no option to force these style definitions to be put into the Project CSS file. The thinking is that local definitions are best kept close to the element they apply to, so they can easily be found and checked. If they all went into Project CSS, it would be a huge monolithic file, difficult to navigate.
Instead, we view Project CSS as a good place to put overriding styles and class definitions which are shared between controls.
I realize that the styles wont get put into the CSS by AS. If I do put them in the CSS myself and set the classes on all the controls manually in the IDE. Then in that case, how do I remove all the inline styles that the IDE put into the generated HTML?
There’s no option to suppress them. However, anything you put into Project CSS will supersede what’s in index.html, so you will be fine.
After looking closer in the inspector, it’s not just the inline styles, it’s the # classes AS generates that take precedence over the . classes I’m adding in via the class properties. In other words, I’m not getting the class property to override either the # classes nor the inline element styles. I’ve looked up the precedence order and verified this in a sample program. What am I missing?
I struggled with this for a long time in my early .css career. Just to check that what I remember to be the lesson is still the rule I ran this test on two browsers:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title></title>
<style>
#foo {color: blue; font-size: 8em; }
.bar {color: red; font-size: 6em; }
</style>
</head>
<body>
<p id="foo" class="bar" style="color: green; font-size: 4em;">blah blah blah</p>
</body>
</html>
Inline style was the highest precedence (when present, the text was always green) and the size and color from the style sheet (header or separate .css file) was ignored.
Next in order of precedence was the #id. Remove the inline style and no matter which came first in the style sheet, the element id (#foo) was assigned next and the class=bar all but ignored.
Next, with no inline style and no id style (#foo) then the class=bar was assigned.
Removing the font-size from the inline style and the size from the id (#foo) was assigned. If you removed the font-size from the inline style and #foo then the size in the class=bar was assigned.
If you added a font-weight to the class=bar then that font-weight (i.e. bold) would be assigned in all of the above cases… think of it like a dog pile and the font-weight having no other preceding orders gets pulled from the class=bar.
It may become tedious after-the-fact but one could obliterate all inline styles in the document and target them afterwards with a fresh batch of homemade css.
We can use something like this:
$(’*’).removeAttr(‘style’)
It’s in jquery because I’m just about that life right now. If anyone has a pure js version that would be great. But I can’t imagine it would be difficult to do.