I created and coded my own css navigation bar (inspired by apple, if that helps you visualize), that means i have dynamic buttons with 4 states that i manage with a css stylesheet. I only have two graphics, one with the button states, and another with the stylized "text".
However, i'de like to make it so that the nab bar's graphics are preloaded in my webpages.
1) is this possible ?
2) is it useful ?
3) if yes to both questions what would be the code ?
I don't really see the point in preloading those images. If the images are static and always refer to the same file without parameters, they will be cached anyway by the browser and only loaded the first time a visitor comes to your site (unless you prevent caching with some fancy http header settings), and served out of the clients browser cache on further requests. Do you have an example of your navigation to look at?
if you are concerned about loading times your could quite easy have a navigation similar to apple.com by using css3-gradients for the background, border radius for the outer container and only declare a background-image in you IE stylesheet as fallback option, so modern browsers wont requests the IE background pattern.
Add some 1px offset text-shadow to give your navigation some 3d look.
You can preload images either by using JavaScript, or by inserting img tags early on in the page with styling to hide them.
JavaScript example:
<script>
image = new Image();
image.src = '/path/to/image.png';
</script>
You'll need to do the "image = ...", "image.src = ..." for each image you want to preload. This code will load the image into the browser's cache.
HTML/CSS example:
<img src="/path/to/image.png" style="display: none;" />
The above will load the image, but won't display it on the page.
Related
I have created the layout of the website (template). I used Photoshop to design the picture and sliced it to create the divs. It gave me an HTML file including the HTML and CSS code. I separated these in two files HTML and CSS. The background images were being called inside the <div id="idName"> tags as <img src=... tags. I changed this. I loaded the images in the CSS file as
idName { background-image: url(URL); }
All the images in the site are loaded like this creating the background as a whole.
Now my question is: Is this a bad practice? because if I leave the images inside the <div> tags I wont be able to put my content on top of the image. With the background-image attribute in the css file I can put my content anywhere, not having to worry about the background.
No, this is perfectly fine, and actually may be a best practice for background images. Moving the image declarations into the style sheet means the images may be downloaded a little bit later, but most browsers should have enough other resources to load in the meantime, and you'll want prioritize HTML and stylesheets before background images anyways.
Just don't use CSS backgrounds for actual images: If the fallback background color would significantly change the meaning (i.e. the image is content), you should use <img> elements with an alt= attribute. If you're not sure whether this is a good idea, consider this question.
To increase performance (by reducing the number of HTTP requests), you may want to consider using CSS sprites.
Ok, So I designed a responsive layout that doesn't show images for very small screen sizes, using media queries and display: none;.
So far so good. But these images still download on these devices, causing an increase in bandwidth.
What is the proper way to make these images not download on the specified devices?
Any response would be much appreciated!
Two options I can think of:
Detect small devices on the server using browser-sniffing, and send them different HTML that doesn’t reference the images.
Display the images via CSS instead of HTML (in style attributes if you like), using either background-image or :before/:after and content (not supported by IE 6 or 7), and wrap that CSS code in media queries so that it’s only displayed by devices with larger screens.
The only accessible solution right now is to wrap the image with <noscript> tags, then pull the image out later with javascript. Cookies don't work on first page load (HTMLPreloadScanner), nor with CDNs. Browser-sniffing is useless if your images aren't always 100% of the viewport.
Slimmage.js implements context-friendly responsive images in 3KB of vanilla JS.
The markup is pretty simple as well:
<noscript data-slimmage>
<img src="http://z.zr.io/ri/1s.jpg?width=150" />
</noscript>
Of course, you can make a server-side helper to even abstract this away.
If you don't mind a javascript dependency you could check window.innerWidth and insert image tags for sufficiently large screens.
Images would only be requested if javascript is enabled and the window big enough.
If you don't have any issues using additional JavaScript, then you may try THIS. I've stumbled upon it while searching and learning about media queries.
I'm developping a card game.
I have an ASP.NET page with some 52 small images (the cards), say 300 Kbytes in total.
When the page loads for the 1st time the effect is ugly: User can see each card being loaded in turn.
Moreover, only some images are to be displayed after page loads.
Hence the big issue:
I can't make the images hidden from ASP.NET since if hidden they are simply NOT rendered within the "dynamically generated" aspx page!
And of course when I use a js function fired from windows.onload event, then the user will see all the images before I can hide them in javascript!
The dirty way would be to create a Div that would be displayed in front of all other objects since I use absolute positioning.
I'm quite sure you all gurus, you have better ideas!...
If all of the images are enclosed in a single element (say, a div) then you can set its CSS to display: none by default so that even during page rendering it won't show to the user. Then, when all of the content is loaded, display it to the user. Something like this:
<style type="text/css">
#imageContent { display: none; }
</style>
<div id="imageContent">
<!-- your images are here -->
</div>
<script type="text/javascript">
// assuming jQuery because, well, come on
$(document).load(function() {
$('#imageContent').show();
});
</script>
Now, this makes no guarantees that it won't take a long time for the images to load, resulting in the user not seeing any of them for a while. And if some of them fail to load then I'm not sure what would happen. I imagine the event will still fire once the DOM gives up on trying to load the failed resources.
Naturally, you'll want to style around all of this so that the transition from no images to all images is a smooth user experience. If it takes a few moments then the user may already be interacting with the page when the images suddenly load and move stuff around (I haven't seen your page, so maybe that's not an issue.)
So you'll want to test something like this one a known slow connection or with known broken images to see how it all behaves.
I have a small idea of how such things oftenly done in different jQuery libraries.
The idea is to pack all the cards in ONE image and show different patrs of the image by setting this image as a background of the div and change offsets.
Google does so, for instance. Take a look:
http://www.google.ru/images/nav_logo83.png
This is the elements used at SERP
like
img { background-color:color: color matched to the theme}
or
img { background-image:url (a very very tiny gif image with the text "image loading") }
I'm thinking in the benefit of this when user access site on slow connection then background color will give clue about something is there which is diffrent than text content..
It's certainly a good approach. I would however try to assign as much as possible the same background color to the background as the strongest color of the actual background image. This way the website will still be representative whenever the client has disabled all images (as some bandwidth-limited users do or some handhelds by default do) or when its browser doesn't support images. The Web Developer Toolbar is helpful in this, in the Images menu you can choose to hide images so that you can see how it would look like without (background) images. I however wouldn't put a loading gif in. You can however consider to save the image interlaced (supported on GIF and PNG).
Sure, if you want to. In most browsers a space in which an image will load is already indicated, but there's nothing stopping you from doing a background color too if you like. I typically see this on body tags or other block-level tags that have background images, but I suppose you could do it on an image itself too.
In all honesty, I don't think this will actually make a site more usable than one that lacks this "feature."
An image-heavy site will probably look awful with a 'loading' background image, but if your site is not full of pictures, go ahead.
A small loading image is a nice touch, such as those from http://www.ajaxload.info/
I am working on a Joomla 1.5 website and a little self-contained php application, which I want to show within an IFRAME inserted in an article. The template I am using for the website has a dark grey background and the IFRAME shows grey background when loaded in Firefox (I don't quite know why this is so, but I like it like this). However, when the page is loaded in IE, the IFRAME has white background (understandably).
How can I make the IFRAME copy the background color of its parent document also in IE?
Also, I have another unanswered question related to IFRAME usage and Joomla 1.5, which I would like to point your attention to.
If the self-contained application is on the same domain as the article page, you could access the top frame (with the article) through javascript - like this:
document.body.style.backgroundColor = getComputedStyle(window.top.document.body);
Computed style can be get as described in this article.
Your other option is to add a query string parameter for the iframe, like bgcolor= - this is a more widget-like approach, and will make the stand-alone application more configurable. I personally recommend this approach - it will not rely on javascript and it will not flicker if the execution gets slow.