So again, I come here with a new thread and have some questions in mind I would like to have answerd.
When I'm doing my website,I'm not sure if I do the right things,lets day I have a top div where I want a logo on the left and my nav menu on the right,the thing I do is that I make two divs and make them float to left. And in the left div i put my logo and give it a id and margin it so it looks good. On the navigation menu I do the same thing.
I'm just not sure where I should use things and what options i should use, cause I don't wanna sit here all day structuring the page wrong and learning the wrong way of coding.
And all those different options like overflow:hidden, when will I get in use of those, I'm pretty sure I should use it but since i don't know how I'm going to structure it right I'm probably using a different feauture that's not as good as it for example?
If someone could come up with an idea so I could get a clue of how a page should be structured I would be happy.
That's fine, but it's a good idea to wrap them both in a container div so you can better control where they sit on the page.
And all those different options like overflow:hidden, when will I get in use of those, I'm pretty sure I should use it
In the example above, you would put it on the container div, to ensure that the container wraps around the two floated items. Otherwise the container will have no height, and the floated items will hang out of it.
Honestly, you really need to get a solid overview of how HTML and CSS work before diving in like this. Otherwise, you'll just be flopping around in the dark. Find a good book and work your way through it. It will save you a lot of pain and confusion in the long run.
Your question is basically about how to structure a whole page and would take all day to go through all the options but if you do a search of the forums you will find more information or do a search of Jasons @deathshadow60) posts where he often breaks down the structure of a whole page in detail.
Here's a brief summary of what you should be doing for your header:
Don't think in terms of divs but in terms of structured html. You should already have a basic html page structure in place with relevant content. It doesn't have to be fully complete but should contain most of the elements that you want to style.
You say you have a logo and if that is the site name and slogan then I tend to use an h1 for that (others disagree) and I would use Gilder Levin image replacement to get some content in the page.
You then have a nav which should be in a list so you next have a ul (no need for a div).
So that leads us to this:
<h1>Site logo - & slogan<span></span></h1>
There's no need to wrap those both in a div unless you have a load more elements in that section and you want to group them together (i.e. make a division of the page) or target them uniquely via the parent id.
If the h1 and the nav are floated then you need to ensure that the static elements that follow the floats are cleared so that they start on a new line and do not wrap. If you have other floated elements floating the h1 and nav then you may be better wrapping a header div around the h1 and nav and then using overflow:hidden to contain the floats.
<h1>Site logo - & slogan<span></span></h1>
Or wrapping the content that follows the header in a div to create that clean break from the header stuff.
<h1>Site logo - & slogan<span></span></h1>
<h2>Main content </h2>
If #main contains floats and you don't need visible overflow then you can use overflow:hidden to contain any child floats (ie7 and under need haslayout which can be done most easily using the proprietary zoom:1.0)
As I said before there is no real need for that div unless it makes life easier for you or you need it for stacking contexts or absolutely placed children within that section (add position:relative to parent of that section), or if you want to structure the page logically into separate divisions. Most of the time there are other suitable html elements to use. However I do tend to wrap my header elements in a div called #header simply because I know at some stage the client will change his mind and want something moved and usually that is easier to do when you have a context to work in. It also logically dives the page into appropriate main sections (header, main, sidebar, footer) etc.
Just continue in that manner. First make sure the content is in the most appropriate element and then decide how to style it. Sometimes you will need extra divs for hooks or for styling necessity but that's ok as long as they are needed and that there is a reason for them. Don't add elements for no reason.
Hope that's a start as I have to rush now
Guys, can't thank you enough. Seriously.
Which is exactly why I advocate marking up your entire content (or a reasonable facsimile) semantically before you even think about layout. Once you have your headings for headings, horizontal rules to indicate change in topics where a heading isn't appropriate, paragraphs for paragraphs and lists for lists, with everything in an order that makes sense, then you can DIVide it into sections and create the layout; since content should dictate layout, not the other way around.
After all, that's the POINT of HTML -- saying what the content is so that the user agent (browser) can best figure out how to deliver it to the visitor -- just as the POINT of CSS is to customize that delivery for specific targets.
So... semantic markup first, break obvious sections like content, sidebars and the footer apart using DIV, then build the layout by bending that markup to your will with the CSS... only once you have a working layout should you think about the graphics and effects to be hung upon the already working page to 'enhance' it.
It's why I consider the whole "drawing a pretty picture" first to be a completely broken methodology; and I've rarely seen a site built via that technique that didn't reek of "accessibility, what's that?" -- always very pretty, but ultimately useless to visitors.
As you mentioned it's better to mark up everything. So basically a good way of doing that would be to first start off by placing out all the divs where you want your content, and maybe give each of them a color, and after that start thinking about design?
By the way, lets take a look at http://columnfivemedia.com/ as an example.
I've always wonderd how this is done. Look at the "Column Five" Logo at top left (the black round logo), and the head with a machine in it at the right (the orange logo).
If anyone could explain it for me exactly how it's done, I would be superglad, I get totally confused over how they've done it and thats something I want on my own website.
No, color is presentation... that's jumping the gun. Just start writing your content with semantic block level containers -- numbered headings (h1..h6) for headings, HR to indicate changes in topic without a heading, P for paragraphs, UL/OL/DL for the appropriate types of lists, if you actually have tabular data then TABLE (but only for tabular data), etc, etc...
MAYBE at most a couple of DIV to wrap the content area, stuff you think might go in a sidebar, and around the footer; at most... If you are worrying about the placement of the DIV in a manner where coloring them 'helps', you're probably not writing semantic markup -- you want to color them when you START making the layout then maybe, but really if you work top down and look at your code you shouldn't need that.
Especially if you keep your CSS and style where it belongs, in a external stylesheet instead of putting it inline in the markup like it's still 1997. Having it in a second file can be handy too, since if you have a GOOD text editor that doesn't do the stupid tabbed editing bull, you can have your HTML and CSS open side by side in separate windows -- so you can look at your markup at the same time as the CSS you are writing for it.
It's part of why I run multiple displays -- left half of left display shows markup, right half of left display shows CSS, center display shows the four major browsers one should test against at every step of writing the CSS. (right displays are for tasbar in portrait, FTP client, chats and other management functions).
As you get better and write more pages where you'll need/want those DIV and other hooks for presentation will start to come more natural as you write the markup, but really if you're thinking what it is going to look like on your media="screen,projection,tv" stylesheet when first writing your HTML, you're doing it all wrong.
Heh, looks like we're round-robin posting.
THAT is a perfect example of what I mean by a "not viable for web deployment" design -- there's a reason you only see them on "designers" websites because they piss all over the ability for visitors to use them in a reasonable manner. Crappy fixed width too big for most sub $800 laptops, fixed height elements forcing fixed size fonts, illegible color contrasts -- you want a poster child of everything WRONG with web development today, look no further. Not exactly surprising then it's a website talking about infographics; or as I like to call them "lie to the people too stupid to realize the flashy graphics are hiding lies by omissions, and make the people smart enough to know it's a lie walk right past it as annoying without contesting the facts".
The stupid annoying screen wasting image rotator and total lack of anything resembling real content anyone would actually give a **** about only further exacerbating the accessibility failures of fixed metric fonts, goofy hard to read fonts, color contrasts below legibility minimums, etc, etc...
THAT SAID, if we were talking JUST the markup, I see what should be a h1 with a image replacement method (the 'column five' logo), a unordered list in the form of the menu, a sentence I'd treat as a paragraph, a list of image slides, a list of sub-links with presentational images on them, the clients list being a list of images as well, and then the footer content.
Which of course is why their code is a convoluted train wreck lacking any form of structure and being useless to anyone other than the perfect mix of screen size and ocular clarity as it's developers. Again, poster child for how NOT to build a website. Of course it's markup is also rubbish as it's also a turdpress template, so it gets the double bloat whammy.
Which is why it's an ungodly 32k of HTML to deliver less than 2k of plaintext and maybe a dozen content images -- ineptitude of the highest order and easily three times as much HTML as should have been used.
Assuming such a train wreck of "but I can do it in photoshop" idiocy has any business being a website in the first place. Very pretty, but ultimately what is it good for if you can't read it, it doesn't say anything by lack of actual content, and it doesn't work on so many people's machines? "Ooh pretty" lasts five seconds, users walking away from it as "bounces" for it being pointless fluff lasts a lifetime.
I get a little confused since your english is like the best I could've imagine me learning.
But anyways, I don't get what you mean with this...
why would you use a h1 image replacement method as you say here:
h1 with a image replacement method (the 'column five' logo)
In deathshadows quote that you quoted, he's giving these bad practices
-Fixed height elements
-Fixed font sizes
-Illegible color contrasts (can't read anything due to the color choices)
He then moves on to basically say that all these are basically bad to do.
Yep, but why should i use h1 for images? Isnt that for headings?
A heading doesn't just have to contain text :).
So, if the case is that I want a picture as a "heading" i should use h1?.. and a class? so, <h1 class="something">?
No. You should use an H1 for a top (first-level) heading.
You do not need to use a class. In fact, if you just use a single H1 on your site, then there's almost never a need for a class or an ID, unless you intend to style your H1 differently on various pages.
But the point of using h1 is mainly just because for yourself? I could just give it a <img id="something" src...............> ?
Sorry, but could you rephrase that? Didn't quite understand.
Not sure I understand... Why would you give it an ID?
The point of an H1 is to mark-up the top level heading of an HTML document. Whether you replace text with an image for your top level heading isn't relevant as long as the text or image within your H1 denotes the page's heading.
This topic is now closed. New replies are no longer allowed.