There are two CSS files referenced on the same page: A generic.css file and a custom.css file. The generic file has default styles in it that are overridden by the custom.css file for the same elements. This allows users of the site to customize or "skin" their pages without needing to recreate the entire generic.css file. Only a few styles would be overridden.
My question is the following: If the generic.css file has a style for an element with a background image and that same style is overridden in the custom.css with a different background image, is the first image ever downloaded by the browser?
Also, I want to find out if this is bad practice - customizing or "skinning" a generic CSS file with another custom CSS file to override a few styles, including specifying different background images.
While not totally definitive, this site ran some tests regarding this. The significant statement from that site that is related to your question is:
CSS images are kicked off not in the order in which they appear in the
CSS but in the order in which they’re called in the HTML. I’m not sure
of the precise moment when the download is initiated, but my guess is
that it happens just after the CSS rules have been matched, when the
property values are assigned to the DOM elements.
This at least tentatively confirms what I thought I remembered in the back of my mind reading on this a few years back, namely, that background images which are not ever displayed (as in the generic.css images being overridden by the custom.css images) are not ever downloaded.
Further confirmation of this would be the typical image preloader script that used to be so common prior to sprite images (and is still found in certain uses). It was designed to download images that would be used on :hover in css, because without it, the image would not load until the first hover was initiated, and this caused an unsightly delay. So that, also, argues for the fact that unless actually displayed (or preloaded), the background images themselves are never loaded.
I don't think there are generally any issues with "skinning," unless you are essentially overwriting most or all of the generic.css with custom.css, then one could argue, why load the generic at all. But as you said, normally there are just a few styles overwritten.
I think i answered NO and NO BAD PRACTICE. Because when the css file readable / executable by the browser, the browser will make comparisons to find the same value or the difference between css file and then combine them.
Easy example:
css1.css on file there is a line:
.test {display: block; width: 100%; height: 600px; background: #991100 url("image1.jpg") center top; border: 1px solid red;}
then the css2.css there is also the line:
.test {background: #991100 url("image2.jpg") no-repeat center center;}
the result of a combination that will be executed and run by the browser are:
.test {display: block; width: 100%; height: 600px; background: url("image2.jpg") no-repeat center center # 991100; border: 1px solid red}
where the "background: # 991100 url("image1.jpg") center top;" read but not called / executed by the browser.
Far as I know the value of the file css1.css be stacked by the value of the css2.css. What if there a css3.css file? then the file css3.css will also stacking on the combination of css1.css and css2.css.
Hope it helps.
Related
I'm creating a Spree store, and trying to make a button use an image instead of the default button that is included with the extension (and bootstrap). I can target the proper button in CSS, and deactivate the background color, border, etc. The background url doesn't work for the image (path: "app/assets/images/heart-icon.png"), but it works fine for any external image url.
I assume my problem lies within the asset pipeline, but I can't figure out the proper path to set as the url.
From my .css file:
form.new_wished_product button.btn.btn-info {
background: url(assets/heart-icon.png);
background-color: transparent;
background-position: center center;
background-repeat: no-repeat;
color: transparent;
border: none;
}
The button doesn't need to change when hovered or clicked -- it's just a simple image.
Thanks!
EDIT:
I saw the related question but thought mine was different because I had tried those solutions. I was trying to do this with plain CSS and changing the file extension to .css.scss worked for me.
Have you tried the image-url() helper instead of url()?
image-url('heart-icon.png');
This will find the asset within your site's file structure.
When using the asset pipeline, paths to assets must be re-written and sass-rails provides -url and -path helpers (hyphenated in Sass, underscored in Ruby) for the following asset classes: image, font, video, audio, JavaScript and stylesheet.
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.
Can anyone tell me why in the world Initializr's bootstrap html template has a single style for body in a element in the head of the page? It's right after the bootstrap.css file.
body {
padding-top: 50px;
padding-bottom: 20px;
}
My question is: isn't it a little odd to throw a one-off style directly in the markup and not just include it in the bootstrap.css file? Is there some specific reason anyone knows of as to why it was done this way? CSS belongs in CSS files, no?
Taking a quick look I would assume because it relates to that page specifically.
What if on another page you didn't want the navigation bar? You then have to override the style implemented in the .css file manually to correct the padding. Seeing as it's only one statement, I'd say it's fair to include it at the top of the page rather than putting it in it's own .css file.
Would you really want to obscure a framework .CSS file by including potentially page-specific code (that would muddy the framework)?
Edit: To elaborate - if you have a rigorous structure across dozens of pages, each with consistent style, it would only make sense to centralise this content into a .css file, however from an industry perspective I would more-than-likely still not put it into a framework .css file (think about future implementations, upgrading the framework, versioning etc etc).
I saw this and just about eliminated my Initializr foundation because:
A) The Initializr index.html rendered differently from the same page on getbootstrap.com and I could not figure out why
B) It was not at all obvious why this style was inline inside the <head> section since there was no comment.
Thankfully I did not delete the Initializr files. It turns out getbootstrap.com includes these same styles (but via a very small stylesheet named theme.css). The values are a bit different than the ones you mentioned, but same idea.
The theme I was referencing included this theme.css:
body {
padding-top: 70px;
padding-bottom: 30px;
}
.theme-dropdown .dropdown-menu {
position: static;
display: block;
margin-bottom: 20px;
}
.theme-showcase > p > .btn {
margin: 5px 0;
}
.theme-showcase .navbar .container {
width: auto;
}
So, long story short- Initializr did the right thing here by removing the extra include in my opinion... HOWEVER, a <!-- Comment --> explaining what those styles are should be there. There are comments on most sections, yet none for this snippet.
Anyways, I am keeping my beautiful Initializr Bootstrap code base, and figuring out what pages need what values of what snippets lol.
I've tried numerous methods to load my CSS background images over SSL without resulting in the mixed content warning.
On this page for example:
https://www.statcentric.com/login/default.aspx
You can see that the message is coming up.
For the logo (logo.png), I've tried using the protocol-less method like so:
span#logo
{
background: url(//www.statcentric.com/images/logo.png) no-repeat scroll 0 0 transparent;
}
For the background (bg.jpg), I've tried using a relative path like so:
body
{
color: #191919;
background: #f2f2f2 url(../../images/bg.jpg) repeat-x top;
}
However, as you'll see, both of these images are still being flagged as mixed content.
Any help is appreciated!
Have you tried pathing your images from the root? ex. url('/images/bg.jpg')
Depending on your tolerance for older browsers, you might look into making your images inline with base64 encoding; data URIs in other words.
https://en.wikipedia.org/wiki/Data_URI_scheme#CSS
http://www.websiteoptimization.com/speed/tweak/inline-images/
It does make your css files bigger and maintenance harder, so you'll have to weigh the size of css file versus the cost of the SSL request. For small images, I usually find the size of the css file is the better way to go.
The other option I know if two different css files; one for ssl and one for not.
I've been stuck on this for 3 days now.
I have two pages that basically share some code for a search feature on my website, here's my code
The CSS
#btnSearch {
display: block;
color: #ffffff;
width: 100px;
height: 27px;
border: 0;
padding: 0;
background: transparent url("Images/btnSearch2.png");
}
When I'd gotten the one page working, I copied that code to the page where it doesn't work, but it hasn't made any difference, here's the HTML (don't worry about the inline css, that's just for convenience while I'm working on it...)
EDIT1:
All other classes work correctly as they (along with the css above) come from a stylesheet at <webroot>/App_Themes/Default... The images go in a subdirectory of this location.
I don't see why this code works on 1 page and not the other when all the other CSS classes work on both pages...
Have you tried the absolute image path and see if it works that way?
Maybe it´s a Browser problem: Try to open the file that doesn´t work in another browser.
Maybe you have a tag named the same way #btnSearch in the pages where the styles don´t apply.
Is the path to the background image correct for the page where the code doesn't work? Or even the path to the CSS file?