From what I find on this site, webpages are typically centered using an overall <div> called #wrapper that has auto margins, or some other clever attribute. For example, in this question.
However, it seems that this is not the optimal way to do it in HTML5, where it is preferred to use tags from a series of special new ones.
What is the best way to center a page in HTML5?
TO BE MORE CLEAR
From what I understand, HTML5 was created to get rid of the many divs found in websites and provide a standard skeleton. Instead of there being <div id="header"> and <div class="section"> etc, the powers-that-be determined it would be better to have standard tags. For this reason, I don't feel comfortable surrounding everything with a <div>. I feel like there is probably a better, more clean, HTML5-friendly way.
Perhaps I'm wrong...
Until now the way you describe is still the preferred one. Some time in the future you might use the <main> tag for this, but for now you are 'stuck' with the <div> auto-margin method.
You can read some more about the <main> tag here: http://html5doctor.com/the-main-element/
Related
There are some commands in HTML that are confusing me. For example, what do the <nav> element and the <article> element do? There's a lot like this. <nav> <article> <section> <aside> <div> What are the purpose of these? I know what they do, what I'm confused about is why you'd want to use them. These elements create semantic sections, what I'm asking is, why is this needed? What does it change?
One important reason is accessibility of websites: If a screenreader (for blind people) knows (from recognizing these tags) which element contains the navigation (nav, which otherwise would just be a div), which elements are seperate, more or less independent blocks (articles and sections), it can guide the user much easier throught he structure of the page and help him/her to find the essential parts of the page quicker.
Another reason is that search engines can find the essential parts of a website, since the structure is much clearer.
It is the new Html5 standard. They can be easily used in semantic way and they have more meaning for example than a classic div
This is probably a good place to start HTML Tags If you're not sure what a div is I'm going to assume you're reasonably new to HTML?
You don't have to use tags like but it just makes it easier for someone reading your code to know exactly where the navigation is. Otherwise it might just look like a list.
I'd suggest you read that list though.
Let's say I want to have a title block, and for styling considerations I need to nest it inside a div with some special CSS styling (e.g. I want specific border and spacing styling). Let's call this one box. The box just serves the style the title inside it.
The fact I need to have box at all just has to do with the limitations of CSS, so it doesn't make sense for the box to be considered a block in BEM terminology. It doesn't even make sense as a DOM element. But title is located inside box.
It makes sense to me to give box the class title__box because it doesn't make sense without title. However, all examples of BEM seem to assume the element is always a DOM child of the block it's in.
To answer your question plainly without investigating further into this, no.
You would have to have something like the following
<div class="decorator">
<h1 class="title">blah blah</h1>
</div>
or
<div class="title">
<h1 class="title__heading">blah blah</h1>
</div>
When using BEM you have to think in terms of "blocks", "elements" and their reusability. In particular, consider this from a developer perspective: you don't want to end up in a particular scenario where the developer will build the title in question and forget an element or an attribute and get mad trying to figure out why it doesn't work. This gives you consistency and replicability of your markup.
I have no specific insight on why you need the <div> and what are the CSS limitations that you're talking about, but I will take your word for it.
So I'm going to ask: have you thought of cleaning up the markup using pseudo selectors, or using the heading as the aforementioned container and using inline anonymous elements (i.e. <span>s)?
I hope this helps solving your problems.
What is the best practice for developing a layout? Is better to limit divs? I was looking through the html/css of some popular sites and they all seem to have divs within divs. For instance, a div for the entire page, a div for the topbar, a div within the top bar for the logo, search bar, etc.
Is this a good practice? I suppose it's easier to position all the divs correctly and than place the necessary elements within the divs. It's what I've been doing this far but want to make sure I'm learning the correct approach.
Any help on this is appreciated. Thanks!
Use <div>s when you need to divide (that's what divs are supposed to be used for) sections of your page from one another. Header/footer from content for instance, or individual posts on a blog.
However, you shouldn't use them when semantically another element would make sense.
If the archive on the previously mentioned blog only showed a two line summary of every post in the archive, an ordered list might make more sense as you are defining a list of items which are in order. <li> elements are block elements as well and can be styled in exactly the same way.
Sometimes, it will make sense to have nested <div> tags, and sometimes you shouldn't.
As a basic test, imagine your page is being parsed by a reader for a visually impaired user. It needs to know what is in each node of the document so it can announce it properly. It doesn't care what your visual CSS needs are, it just wants to parse it into speech as accurately as possible.
Basic points to remember:
Write your HTML primarily for structure not visuals
The person viewing your website may not be using your CSS
The person viewing your website may not be using a conventional web browser
You can always tweak your structure if the CSS doesn't quite work, providing it remains the same semantically.
A <div> by definition is a meaningless element, so it doesn't matter how many of them you have.
However, you need to have <div>s on your page as long as they make sense, and to not use them if there are elements better suited for the job (semantically).
<div>This is a paragraph of text</div>
should actually be
<p>This is a paragraph of text</p>
And such.
There is a name for this sort of "code smell" in HTML: Divitis.
You should expand you knowledge about the semantic meanings for the tags in HTML. You could start by reading this article, but it is more focused on html4.01 and xhtml. There are several new tags in HTML5 and few changes in semantic meaning for the existing HTML4 tags.
The big question is generally whether to use divs or tables. Tables create a lot of headaches, some of which you can't work around. But divs can have their problems as well.
Regardless of what you use, the level of nesting can indeed make the page difficult to understand. So you should favor the fewest levels of nesting needed. At the same time, trying to hard not to nest can also make the HTML difficult to understand.
I stumbled upon this article
http://www.thefloatingfrog.co.uk/css/my-hatred-of-br-clearall/
When would one need to use that ?
Why is it evil ?
I don't understand the substitute syntax can you explain ?
Setting clear to both with not allow other elements to float on either the left or right side of the element. The class below is an easy way to add this anywhere.
.clear {
clear:both;
}
So when you want to clear something (that is, if you were to float the next element to the left, it would be below the current element and to the left, instead of left of it) you'd simply add the .clear class.
The problem with the following code is that if later on you decide that you don't want to clear everything after the 'something' class, then you have to go through your HTML and remove the br clear="all" wherever you have that 'something' class.
<div class="something">Cool content.</div>
<br clear="all">
<div class="other">Cool content again.</div>
Instead you could do something like this:
.something {
float: left;
}
.other {
clear :both;
float: left;
}
<div class="something">Hi!</div>
<div class="other">Hi again from below!</div>
That way if later on you decide to float all blocks with the 'other' class then you can just remove the 'clear:both;' from the CSS once.
I was about to post something snarky about you not reading the article, but when I saw that it was just a page of vitriolic rage with no explanation, I figured I'd answer.
It's because there are better ways of doing what you want to do -- namely, by using CSS in the way he does in the article, he has separated the semantics of the elements he's displaying from how he's displaying them. Why is this a big deal? Well, for one, he can more easily transform how his page looks when it's shown on different platforms (mobile, desktop) and media (screen, print, a screen reader for the blind), simply by editing CSS and not having to touch the document itself. This feature of CSS is pure gold.
On the other hand, if you use a construct such as this, you put in a hard constraint about your document's presentation that sticks around no matter what media or platform you're dealing with. What makes him so mad? Because once a developer has come in before him and used <br clear="all">, he has to take it out in order to get the benefits I just mentioned. That's why it's so frustrating. One bad developer can disable a whole host of development scenarios for every other developer who comes after.
As far as CSS goes, I have to say that it's a very difficult subject to just pick up without reading all about how it works. It's hard to explain how the clear attribute works if you don't understand floats. I had quite a hard time myself until I bought a great book on the subject.
When you have floated elements, the parent element can't calculate it's dimensions effectively and sizes incorrectly. Other items that follow floated items may also sit out of position. By clearing an element at the end of your floats, you correct alter this behaviour.
EDIT
Actually correct is probably the wrong word to use as this is what is supposed to happen and using the word correct suggests it is broken.
The author is just going off on a crazy rant about how the same thing can be accomplished using CSS on the DIV elements themselves. He's saying that br class="clear" is unnecessary.
It's also not a good practice because it mixes content with presentation. If a web designer wanted to re-theme the web application, he or she would need to modify the HTML to pull out all of the br clear elements, whereas if this was done as the author suggested, then the CSS files could be swapped out independently of the HTML, making their jobs easier and giving them one less thing to rant and rave about.
The rant is of course justified, as these simple, silly lines of code can actually cause a lot of headaches.
The idea is that your markup describes the information, and the CSS formats that information.
A dummy tag to clear floats isnt semantic, as it's only purpose is for layout reasons. There are other semantic ways of clearing floats that keep this separation. As commented below but here for clarity this is a good resource for semantically clearing floats http://css-tricks.com/the-how-and-why-of-clearing-floats/
Ok, I'm kind of new to standards of web design here. :P
Is this the correct way of designing a site with CSS?
Each "Box" has it's own DIV tag, with it's own settings. I'm guessing the background-image: of a box inside of the heirarchy gets precedence over the outer box, right?
A "Box" that has the background image of the site.
Another smaller "Box" that acts as the content container of the site.
And other smaller "boxes" that act as containers for particular things inside of the content "Box".
Here's a little picture about what I mean:
OK, some simple points to clarify for you...
The "whole site box" is probably going to be the body element of the page. You could add a whole wrapper div for it, but it would not gain much in the first instance.
The use of a "content box" is ok, but I would be wary of using it unless you want to specifically limit your site to a fixed width layout.
The other boxes can be added directly to your body element, and positioned/styled individually. You'll probably end up with something like this...
<html> <*-- include your doctype and stuff, obviously -->
<head>
<title>My site</title>
<link rel="stylesheet" type="text/css" href="sytle.css" />
</head>
<body>
<div id="header">Your site header content here</div>
<div id="mainNav">navigationhere</div>
<div id="content">main content here</div>
<div id="footer">footer stuff here</div>
</body>
</html>
There are plenty of resources for positioning, etc, around. I found the best way to learn (although I'm very rusty on it these days) was to look at examples, unpick what they were doing and have a go myself. Try looking at http://meyerweb.com/eric/css/ and http://www.csszengarden.com/ for a starting point of what's possible.
HTH, but I'm sure someone with up-to-date html skills will be along in a minute.
I totally agree with samuil on his point that you shouldn't have functional divs. That's what got us into the whole mess in the first place (if you don't know what the mess is, do a search regarding tabled-layout).
BUT
something to be aware of: If you set an outer-element (like body or even html, but careful) to relative, it will require an explicit height or it may shrink up or no longer contain (visually) the child elements. But if you set the body to a height of 100%, it will be 100% of the window not the document, meaning that when the user scrolls down, the body doesn't scroll with them. It's very weird and annoying.
I honestly recommend just not worrying about layout. Make the copy look good and clean and people will hang around (see: this site). Obviously there are some aspects that make a site more usable or attractive, but I always use the rule of thumb: if I turn everything off, will it still work and will it make sense? I'd rather a page look boring but readable with no CSS and then start messing with the layout and colors then have a site that turns into a pile of divs and p's it one browser (cough, IE) doesn't play along.
Your approach has minor flaw - you shouldn't put "Content Box" div in your HTML unless it has some meaning. There already is body element for that purpose (in good browsers html and body elements can be styled). However, with high probability this flaw is insuperable, as currently commonly used browsers suck in supporting some important features of CSS 2.1.
Except for that your design seems to be correct.
I think the "big" (green) content div is actually a wrapper div that helps you set the width of your website (most wesites nowadays prefer not to use all of the available screen width - stackoverflow is an exception).