I’m trying to design a website with my paltry knowledge of HTML/CSS and it’s actually going better than planned. But I’ve hit an obstacle.
The website is not the simple column-defining, color setting, width-defining procedure as usual. It’s a little more graphic than that and I want the content to be something which users can use to navigate.
My first idea was to simply make the website in photoshop (I have) and slice it, setting <a> as I go and making each sliced image a button for navigation. That works. Then the problems begin.
Dead center I want to import a blog, allowing my peers to write updates to the website without formal knowledge of coding. But I can’t really put that code into the table. (And there’s no way to layer content with just HTML/CSS that I’m aware of.)
So the natural next step seems to be making a background image, then, utilizing CSS to fit content to where it needs to be. Simple, but the issue is this:
Wouldn’t a large, unsliced image be a bandwidth hog even by today’s standards? I vaguely recall that slicing is an effort against this. If I place in my graphic content as the background, I’m just making one whopping image that browsers need to load.
Is this even an issue? And if so, do I have options?
Well normally just one image (if you compress it then it shouldn’t be a problem) won’t be a hassle at all, just make sure the image file isn’t something ridiculous like a BMP where it takes a massive time to load.
If you have more hten one image on the page then it would be best to have all the images combined into one file and then shift around that actual one “image” to find the specific “image” you are looking for :).
Normally for a content background youy would want it to be a repeating image that you can repeat because otherwise if the content is too long/short then the image would either be chopped off early or would end too early
Well, there are ways to get an image down in size, even if it is large. It just can not be a color heavy image, more of an image that is pale and gossamer.
There is another technique that works quite well: On top of the last image layer create another layer filled with one color and set the opacity of it lower. Test it out what it does to your image, sometimes 70% opacity works, sometimes it needs to be just 20%. Depends on what you want. That brings down the weight of a file a lot because now there is an all over hue.
Yes, if your content div is 800px wide for exampke, make a 800x5px (5px is a rough guestimate) and then just set the image on the content div and repeat-y it (down the y axis, think back to graphs from math class :))
I thought I had figured it out, but I still can’t…
Bit of a different issue:
utilizing background-image is nice and all, but the problem is: how do I float an image map over where the navigation bar should be? …and guarantee a resized window won’t move it?
To place something in the foreground over something else so that it will always be there if the page is resized you need to do the following.
Set the content that is behind to position:relative in the CSS. Then add the content to go in front into the end of that position:relative and make it position:absolute. That will place it on top of the other content and you can then set the top and left as required to move it to exactly where you want it relative to what is behind it.
A position:absolute block inside a position:relative block is positioned on top of the relative block and moves with it maintaining the same position.
There isn’t much point placing the position:relative on the body - it is the particular part of the page that you want to align the element over that needs to have position:relative in order to place one element on top of another and keep them together as the viewport size is changed. If you leave off the position:relative THEN the position:absolute ends up relative to the body instead of relative to the element you want to tie it to.
One of the two images involved is the background. I don’t know if what you said still applies but it sounds as though you’re interpreting this as two separate elements not in the background.
A large image will (for anyone with broadband, which is most people in the developed world - if your target market is likely to include a disproportionately high number of people who probably don’t have broadband, you may need to rethink) download and quicker in a single image than if you dice and slice it - because then, usually the sum of the parts is greater than the whole, and you’ve got a load of extra overhead in terms of HTTP requests, not to mention all the extra code in the original document and the additional layout processing needed to reassemble the pieces.
Dice and slice was needed maybe 10 years ago, but improved technology means it doesn’t help any more. In fact, things have gone the other way - in 2004, A List Apart were advocating the use of Image Sprites, where far from splitting up one image into small ones, you combine all your small images into one large one!
To me, even starting out drawing some goofy picture in Photoshop is putting the cart before the horse. People do not visit websites for the goofy graphics you hang on the page, they visit for the CONTENT. That’s why I advocate a content first approach…
I figure out whoever started propagating this “design in photoshop” nonsense, and, well - they best avoid dark alleyways for a while. Most of the time you end up with design elements that are impractical to code resulting in blote, impractical in terms of filesizes, impractical from an accessibility standpoint. In general we’re talking buggy broken train-wrecks that likely end up being crappy little stripe fixed width layouts with accessibility /FAIL/
FIRST code the html with semantic markup and some standard styling containers and hooks - THEN create the layout with the CSS, and then only at the end should you be thinking about using the paint program to make graphics to hang on your layout.
Even if you end up having to work from some stupid .PSD - you are best off forgetting the PSD even exists while making the markup, barely look at it when doing the layout in CSS, and most of the time throwing it away and making new images from scratch when hanging the graphics on it since ‘slicing’ usually doesn’t give you images that work with techniques like CSS Sprites, sliding doors, or eight corners under one roof. Usually such designers don’t even THINK about graceful degradation for things like Images off, CSS off, screen readers - and frankly if you aren’t thinking about any of that while drawing your goof-assed PSD, you aren’t thinking SEO either.
… and if nothing else, I still consider 64k for an entire page template without content the ideal target (thats HTML + CSS + JS + Images), and around 170k the upper limit I’ll allow in my stuff.
Giant bloated slow image backgrounds, slicing a PSD until the page is built on 50-100 separate files - these are ways to drive users AWAY from your site, not draw them in no matter how ‘pretty’ it is.
Thank you for your candid thoughts. But I am a designer, not a developer nor coder by training. This is all incredibly foreign to me. On the flipside, I could practically point at Photoshop and it’ll do flips for me. Flash content, among other things, have made the web must prettier than it is today. Although I realize the types of loops people jump through to make that happen, I embrace it.
I was able to solve my own problem by using containers, image maps, and breaking the background into three simple images.
Though I understand your argument—and sympathize, to be sure—
The limitations in web coding are numerous. There is only so much color and type can achieve. Even then… as you know, web standards on type are horrendous. CSS’s flexibility is terrific but I wasn’t going to be relegated to simple columns, navigation bars, and the Georgia typeface.
What’s more is that our organization is contending with hundreds of websites run and owned by the University. There is already over-saturation occurring with the University template, as well as even simpler templates. Students here range from the 18-22 age range and have little attention spans on top of that—add in difficult course loads and jam-packed Blackberries and you all of a sudden are blessed if you can get a few pages few a week, let alone, a day. Superficiality, given the audience, is nothing short of appropriate. “Clarity of information” is already being done 100x over in their books and emails. (Though I don’t even think they’d know what that means!) There comes a point where clarity is interpreted as banal, and we can’t let that happen.
And your comments about accessibility are well-taken. But to be sure: No one will be looking at this mobile, and if they are, there’s simply no point. I’m attempting to integrate accessibility into the HTML and will gradually test it as I progress. As I said, I’m new to web design so adding on the philosophy of “Internet for all,” PLUS just the basic coding is tough. It may come second nature to you. It does not to me.
Your argument also undermines those of us who are visual thinkers. I don’t put words to a .txt file and hope to imagine what it will look like. It’s also very disheartening. It’s like describing a sketch prior to making a sketch: there’s no substance.
Regardless, this is to please the clients (my peers) so it will be reworked as needed. But thank you.
Well, it does always depend on the target audience and what the actual content is… YMMV.
I tend to work with pages full of text information and usually having all the ‘copy’ done up first before even thinking about how to present the content on a website. In that way, giant images, flash content and other nonsense just gets in the way.
Sounds like your content might be different from that, so your needs are different.
Though, do you have a link to the site in question? Without seeing what it is you are actually working on anything said in this thread so far is little more than wild guesses. EVERY case is different, and there are no easy answers as to what’s appropriate and what’s not.
It is a work in progress, but I was able to put it up earlier this morning. All the links are dead at this moment: kylepicone.com/CC_Website_BenV2_2.html
)
