I'm chopping up a new design into valid HTML/CSS. This particular design has several images that are very detailed and I'm debating on how to approach dividing them up.
Here is a link to a folder containing the different options I see. There are four aptly named images - bg.brickLeft, bg.brickMiddle, bg.brickMiddle, bg.combined.
I'd just like some input in how other web-developers would break up this design. bg.combined is obviously what the final product needs to look like.
I'm leaning towards bg.combined because 1) less css 2) one http request - but the CSS purist in me is screaming and even wants to separate the gradient into a 3px wide repeatable image.
I'm concerned with the bg.combined approach because it won't look so pretty when loading on slower connections.
How would you approach chopping up this design?
What are the technical pro's/con's you see for these two approaches?
Would you approach it entirely different?
EDIT - Also, the height of the site is static
I'm a fanatic for giving people with wide screens something to look at (you mention static height, but there really is no such thing as static width), so for me, I would make the brick left/right into an image that can be repeated nicely and have a repeat-x applied to it so that wide screen visitors saw more wall.
Other than that, I would leave the center one as my content background in a div centered on the page. So the short of it is, I would do 2 images, the brick as the body background and the patterned 'middleBrick' as my page wrapper div background.
I ended up combining these images, in addition to adding a wider background.
Here is the final result
Related
I have an image I want to set as a background, with background-attachment: fixed element, but I'd like to set it on two divs, which scroll at different speeds. So as you scroll it 'appears' that both divs are giving little peeks at the same image hiding behind it all. However, it would actually need to be two separate divs with the same image set as the background.
I'm curious, will using the same image twice be less clunky than two separate images? I know the render will be relatively the same, but in terms of the page loading, will It save some performance?
Yes it will, if the URL is exactly the same.
Browsers will cache media resources if the URL is the same, so using the same image in two places is better than using two separate images.
I have searched for this question, but I can't find a good solution, so maybe you guys can help me.
Link
If you look at this site, you can see that in each side (left/right), there is a banner. The width for these two are 160px each. the website is using the WHOLE screen at any givin time, but the ads are still 160px no matter what, and the game in the middle is the one shrinking to fit the screen, both vertically and horisontally.
How can I achieve this, and is it even possible to do in css alone? I've looked their code, but I can't really figure it out.
Banner provided by thirt pars (like AdSense) can't generally be resized for an obvoius reason: the advertiser provides, one or more images for the banner, possibly of different sizes; but that sizes are generally not intended to be "scalable" 'cause in that case the result might suck...
You can scale the container, of course, but you are asking about ADS...
I have been trying to code a responsive thumbnail group that I'd like it to respect to a few rules.
I came very close but the implementation always end up not satisfying at least one of the rules. In other words when I try to do one thing it always cancels the other.
In summary, what I am trying to achieve is something like this -
http://postimg.org/image/4yx6poscz/f57d6517/ (I wasn't allowed to post a picture, sorry)
So basically, what I am after is;
When the user resizes the window the thumbnails (consist of an image and some basic HTML) will shrink up to a point.
When the breakpoint is reached, the most left one will disappear and the rest of the thumbnails will return to their original size.
Continue until the min-body size where we just display the x-axis scrollbar.
So, referring to the image, providing that no resizing is done just yet, the items will shrink, lets say until 20% and then Item 7 will disappear letting free space to the rest of the row to expand to their original size.
I am currently using the latest version of bootstrap however, as you may guess col-lg col-md and etc. classes are not really helpful in this case. I have come up with some custom breakpoints but I can't get my head around the shrinking back to the original size issue. That is where I get stuck.
Also I think it's worth mentioning that Ive been trying to come up with a solution that is pure HTML and CSS however I am definitely open to JS solutions as well.
A good example would be spotify's webplayer (play.spotify.com) thumbnail examples.
Thank you very much in advance for your suggestions.
As a web developer, I have to cut a layout similar to this (example website by Ruben Bristian):
Should I bother with cutting multiple small images like a logo:
a label:
and so on? Or should I just make one big background image with all elements like this:
and make a positioned <a href> with display: block; for a linked logo?
A single image has smaller size than multiple elements altogether. What are the other pros and cons?
Use separate images.
Here are a few reasons why:
Maintenance:
It's going to be much easier to maintain in the future, if/when there comes a point when you want to build on what you already have. Furthermore (and subjectively), the background image is not critical to the design. It wouldn't look broken if parts of the background were clipped. It would look broken however, if the logo were distorted.
Bear in mind also that newer, sharper displays are being developed. It's much easier to display the standard resolution background (it's already blurry, so clarity is not essential), and maintain two versions of the logo. One for standard displays, one for HD.
Semantics: What if the user has images disabled? Sure, it's unlikely, but what about Google? You should have some proper markup with real content. Your site needs real textual content in order for Google's crawlers to gather information about it. Use CSS image-replacement techniques to build the interface.
Another note on HD displays:
It's convention to serve larger images to HD (retina) displays, and use CSS to downsize them, effectively increasing their dots-per-inch. If you use just one image, the user will have to download a considerably large image. More bandwidth used by you, and slower experience for your users.
Furthermore, the text will look horrible on HD displays. It makes much more sense to allow the browser to render razor-sharp text to the user.
Accessibility: For a start, screen readers won't have a clue what your site is about. That might not be so relevant in this case, but it's best practice to build and accessible website. If you want to include some smaller text on the site, some users may be unable to read it. Normally they would increase the font-size, but if you use images, they're powerless.
I may have over-dramatised this answer, but the advice is well-intentioned.
I would honestly try a little bit of a different approach. The "photo" part of the image would be one image, the logo another, and maybe the double bar on either side of the heading another (but might not be necessary.
I would use the photo part as a bg image on a div, and within code the rest.
I wouldn't make the text part of the image at all. Try using a service like Google Web Fonts to get a good font.
The approach will save you lots of maintenance time, and also help with performance.
PROS:
Total bytes loaded is lower.
You do not have to worry about how little images are put together to become the total image.
if you just use 1 image you will find that it will be much easier to maintain the fluidity of the layout. You will not have padding/alignment issues, rendering issues, etc. Realistically the load time should be the same either way, maybe a tad longer for multiple images as the browser would have to render more css, but i imagine it would not be very noticable. In the end it really comes down to what is better for the job. I pretty biased towards 1 clean image :)
I guess you have to think about how you are going to use each element individually, and how they are going to change in the future.
You might want to change the logo, animate it, or want to re-use it elsewhere. The background image might change, or become multiple images in some sort of transitional gallery.
If this its never going to change (unlikely), then, yes, flatten it in a single image.
I personally would have as a separate background image. Then perhaps have the logo and the label on another transparent png and utilise css sprites to re-use them throughout the site. This will halve the number of requests required to download the logo/label, and allow you to optimise each image separately ie the complex background photo, and the more simple logo/label.
I have recently begun using image sprites and they are definately great for reducing http requests. Is there a point where it becomes bad practice?
Im thinking particularly where a lot of extra markup has to be added to support them. For example, using them for list bullet points, I have to add two or three extra spans to get everything alligned etc.
Theres also the annoying point that you cant use repeating images, so therfore there is always the toss up between one large image as part of sprite or a tiny 1 pixel image used for repeating downloaded on its own.
Im really looking for an opinion on the two situations outlined here + any other general considerations/guidelines for using sprites.
They can often cause performance issues on mobile devices. I'm not 100% certain why (never really dived into the problem), but I'm assuming it's because the mobile webkit is loading a new copy of a relatively large image into memory for every instance of it on the page. Since mobile devices often have very small amounts of RAM, it can quickly cause the page to slow down.
I've run into this issue before when having about 300 "icon" sprites on a page at one time, each pulling from a sprite image that contained about 50 different icons. Going back to "normal" methods of one icon per image (or 2-3 for hover states) solved performance issues on this particular page.
Also, many browsers (mobile and otherwise) will often not 100% respect the clipping of sprites when you slightly resize the page content (e.g. using "Zoom In/Out" on the browser itself). You'll often see little pieces of the sprite next to the one you want to use.
As for your bullet example, you shouldn't ever need more than one extra div/span. You would set a margin-left on the li and position your "bullet div" in the empty space it creates.
That being said, I use sprites all the time because they're convenient, just be aware of a few issues with them. Generally, I have sprites.png, sprites_h.png and sprites_v.png for horizontally and vertically repeating pieces.
Write two simple test pages, use sprites on one, and not on the other. Use a tool like http://www.webpagetest.org/ to measure the performance in a few different browsers. Once you have data, you can make decisions.
I would divide sprites by related elements, like navigation and content-related sprites, so you can benefit from sprites and keep a logical order in your code. Don't forget that readable and understandable code should be a priority (particularly with CSS, it can get very messy) unless you're working on a Google-scale project.