Content area not expanding with the content within it! - html

I have been coding a design I had been working on for a week or so and have core across a snag.
While doing the HTML/CSS of one of my right column modules the content within it expands however the bg and bordered area it is within does not.
htttp://www.gamefriction.com/Coded/ (url with example)
http://www.gamefriction.com/Coded/css/style.css (css stylesheet used on page)
This website is purely HTML and CSS at this time all code can be viewed through the View Source option on all browsers.
The area that is not working properly is the bullet links in the right module with the blue background that says "League Menu".
The content above that will make the module background expand however the linked bullet menu will not.

Before doing anything else, pick a doctype. The one you have right now defaults to quirks mode in all browsers which, quite frankly, is going to give a lot of interesting results depending on what browser you are viewing the site in.
I'd recommend html 4.01 strict, but some people like the xhtml strict option as well. Either way, make sure the doctype is formatted correctly. Otherwise it's still going to default to quirks.
Once that is done you'll have a set of rules that are dependable that you can work with.
UDPATE:
Okay, now that you have a good doctype. Add another div inside the league_menu_links to clear the floats from the league_link_wrap divs. exa:
<div id="league_menu_links">
<div class="league_link_wrap">some text</div>
<div class="league_link_wrap">some text</div>
<div class="league_link_wrap">some text</div>
<div style="clear:both;"></div>
</div>
That will signal to the browser that the floated divs are to be contained by that outer div and cause the outer div to expand accordingly

Since you're floating the elements inside the #league_menu_links div, it is not expanding with it's children.
One hack-around would be to add an empty div with clear:left; as the last element child of #league_menu_links, like so:
<div id="league_menu_links">
<div class="league_link_wrap">
...
</div>
...
<div style="clear: left;"></div>
</div>
I also suggest using ul and li instead of divs, in that situation. It is a list of items, after all.

Instead of using the clearfix method, many people also add a style declaration of overflow: hidden; to your div#league_menu_links.
This will make that div know the height of its children and wrap around them. The one downside to this is if in the future you give that wrapping div a defined height, then the content will appear to be cut off.

Related

Offset anchor of HTML element with border to adjust for fixed header

My question is highly related to this previously answered question. In fact, the solution provided by #harpo in the comments of the top-voted answer was a partial solution for me. However, I've found that it actually doesn't work on some of my elements, in particular, elements that have borders.
Some context: I'm using Bootstrap for my page, and I have a fixed navbar on top, then a page with a load of unstyled divs and .panel divs inside those divs. I have a top padding of 60px on my body which pushes everything down to account for the navbar. However, when I click on a link with an offset (e.g. example.com#div2-1), the top of the div is still covered by the navbar.
Using the solution provided in the linked answer above, I put 60px of negative padding (pulling the element up by 60px) on the :before element, then push it down by 60px again by setting the height to 60px. This creates no visual difference (intentional) but the calculated height of my div is now 60px taller, with the div starting 60px earlier than it should, and the real content starting 60px later. This essentially offsets the content for the navbar again.
However, I've found that on elements that have a border, such as my .panel elements, the border seems to contain everything, and the :before pseudo-element I have no longer has an effect on the calculated height of my div, which means it gets covered by the navbar again.
Here's my code on JSFiddle: http://jsfiddle.net/rszqtw80/3/
If you take a look at the rendered result in any dev tool, you can clearly see that the :before element is properly created and has the right height (60px) for both the outer and inner divs. But for the inner divs, the overall calculated height of the element ends up not including the :before element. Disabling the border with Chrome Dev Tools makes it work for me, so I've deduced that the border is the problem.
So my question: is it possible to get this CSS-based offset to work with my .panel elements without losing the border or having to go back to inserting a tags everywhere? Because quite honestly, without the border, the .panels look quite ugly, and nesting every div in an a tag is also quite ugly.
Thanks in advance!
EDIT: Rewrote my question slightly to hopefully clear up any misunderstandings about my intent. Sorry for my confusing explanation :(
FURTHER EDIT: I've added 3 screenshots that hopefully demonstrates this better than any words can ever hope to do. I would've added it here, but I can't add more than two links due to lack of "reputation".
You don't really need the :before tag for this.
jsfiddle.net/rszqtw80/8/
For your explaining: The > selector selects all direct children of your element.
.first-element > .all-direct-children
<a class="first-element">
<div class="all-direct-children">
<div id="notthisone" class="all-direct-children">
</div>
</div>
</a>
The element #notthisone won't be affected from your changes.
With nth-child, you can select whatever child you want. In your case, I used this to give the first anchor after Div 1, Div 2, etc. A margin-top of 0, So that it's not seperated from your heading(Div 1, Div 2), etc.
After consulting with multiple people, I simply gave up and nested my divs in another div like this.
<div class="container">
...
<div id="div2" class="anchor">
<div>
Div 2
</div>
<div id="div2-1" class="anchor" >
<div class="panel panel-default">
<div class="panel-heading">
Div 2-1
</div>
<div class="panel-body panel-collapse collapse in">
...
</div>
<div class="panel-footer">
...
</div>
</div>
...
</div>
</div>
...
</div>
I was hoping to avoid adding yet another layer into my DOM but it seems there's no helping it.

Why does Twitter use so many <div>s for its fixed position navigation bar?

I am trying to build up a website with a Navigation bar on top of the page. It should be fixed on top of the browser when we scroll the page (like facebook or twitter), but not scroll with the page(like google search??). see Fig like:
seems like we should set the css attribute position of this navigation bar like
#nav_bar {
postion:fixed;
}
but why all those websites use a whole bunch of div to do this? Does all these divs make any sence? Like twitter:
where topbar js-topbar is the outmost div which size is 1583*40px, but I didnt find the definition of its size. And then it goes to global-nav->global-nav-inner->container, finally...container, which is acutually hold the navgation items like a list, a search bar so on and so forth. something Weired is that the size of it is 865*0px. For more information, you can view source of the home page of twitter.
And my question is : but why all those websites use a whole bunch of div to do this? Does all these divs make any sence? Why is a div which height is 0px can hold those navigation items?
why the 'many' divs?
The general idea is the more wrapping elements you have the more flexibility you have with regards to what you can achieve in styling with css. Obviously there is a limit, as you should also try to keep your markup readable and semantic. I would say many important or segregated regions in a site would benefit from three wrapping elements:
<div class="positioner">
<div class="padder">
<div class="alignment">
Menu Here
</div>
</div>
</div>
Obviously with the more semantic HTML5 elements you can make this more readable:
<header class="positioner">
<div class="padding>
<nav class="alignment">
Menu Here
</nav>
</div>
</header>
The reason for keeping a seperate element for padding is so that you can set specific dimensions to your positioner (i.e. header) and not have that calculation messed up on certain browsers (with old box modles) by the addition of padding.
The reason for keeping alignment seperate is because it will give you greater flexibility on the alignment tricks you can use.
The reason for using the header element is because this content will act as a header imo.
The example you give above, each element will most definitely have it's reason for existing and they will most probably all be used to achieve the layout the designer wanted with regard to css. Some times extra wrapping divs are also used as placeholders for content that may be AJAXed, this is probably quite likely when dealing with the likes of Twitter.
You can of course get away with using only a single wrapping element, but you will be limiting what styling and positioning you can achieve later on down the line.
why the height 0px?
There is a trick often used with positioning absolute layers in a relative location (rather than an absolute location) - and I believe this is the reason why you are seeing this, but the trick in itself isn't the actual cause of the height:0px. The trick uses the following construction:
<div style="position: relative;">
<div style="position: absolute;">
The content here will float outside of the document flow,
but remain in the correct location within the document flow
- in all viable browsers.
</div>
</div>
If you inspect the above construction, using any browser debug method, you will notice that the position: absolute; layer has collapsed to have no height (in modern browsers). This is the default behaviour of position absolute outside of the old Internet Explorer world (with no other positioning or dimensions settings), because an absolutely position element is taken out of the document flow and by default doesn't calculate anything to do with it's children.
If you wish to override this behaviour you can simply use overflow:hidden; (as long as the height has NOT been specifically set to 0px by some other class or by JavaScript) - this will force the element to calculate the dimensions of it's children and wrap them.
First of all use position:absolute; if you don't want it move with you when scrolling. position:fixed; if you do.
Second of all when you build a website the first thing you're going to have to do is decide how the structure of your website is going to look like. So the menu at the top will be
<div id="Menu"> </div>
Now you may want to create a header under it
<div id="Header"> </div>
Under that you want to share content, since thats what website do.
<div id="Content"> </div>
Under that you may want a footer, that says 2012 Copyright etc.
<div id="Footer">2012 Copyright zoujyjs © </div>
Now you may want to center everything. Why not just put all these previous divs inside a wrapper div. Then all we have to do is center the wrapper div.
<div id="Wrapper">
<div id="Menu"> </div>
<div id="Header"> </div>
<div id="Content"> </div>
<div id="Footer"> </div>
</div>
You could also add stuff like a logo inside the header, etc.
I think you get the idea. But isn't it obvious you're going to get "divception" then?
Also: When no height is specified on a div, the div will automatically resize with the content within.
<div style="background-color:black;">
<!-- Nothing will be seen on your page, because the div is 0 height, 0 width by default -->
</div>
<div style="background-color:black;">
Height of the div will now be the same height as the height of this line. (15 px by default I believe
</div>

Inline divs won't listen to authority

I need a little bit of help disciplining my HTML. It seems to be acting up.
Anyway, the content area of a page I'm working on has two columns. To get the multi-column look, I'm not using one containing div for each column because some of the "rows" in the column need to be lined up.
So instead, I'm basically using several "rows" with two inline divs per row -- one for left content, one for right. Most of them are working correctly..but for some reason, my last row isn't. No matter what, it will not listen to me when I give it a width.
Here's what the relevent HTML looks like:
<div id="mainContainer">
<div id="topBar"></div> //full width
<div id="featured"> //this "row" is working fine
<div id="featuredVideos"></div> //these two
<div id="featuredLiterature"></div> //are inline
</div>
<div id="browseButtons"> //this is the "row" that is acting up
<div id="litBrowse"></div> //these two
<div id="vidBrowse"></div> //are inline
</div>
</div>
In the mean time, what types of situations can cause a div to not listen to a width? I even went so far as to give every single child div inside litbrowse and vidbrowse1 the same width that they have, 450px, and no dice. All of the content above it, which has essentially the exact same structure, is working fine. The only difference, maybe, is that the "row" above the row in question is comprised of two floating divs.
Here is a jsfiddle showing the issue. The bottom two divs (Browse lit by category, browse vids by category) should be spaced out, but they're scrunching together because they won't take their 450px width.
The problem is that you are saying that .browseBtn is inline. Inline elements don't take widths, only block level elements do.
Using inline-block instead will do what you want. It is inline enough to make the divs side by side and block enough to allow you to specify the width.
See http://jsfiddle.net/abtFr/2/
SECOND EDIT - Others have responded saying to use display: inline-block instead of display: inline. inline-block is not compatible with IE7. HOWEVER, we can make it compatible by appending
zoom:1;
*display: inline;
to the element using inline-block. To make compatible with IE6, you need to specify a height, so add
_height: [yourheight]px;
The underscore will target IE6 only.
Alternatively you can float the elements left, in which case my original reply may be relevant.
EDIT - I responded without seeing the jsFiddle; this response can probably be largely ignored.
To answer your question, floating an element will cause it to be taken out of the normal layout. If a div is floated left inside another div, it will be placed to the far left of that container, but its dimensions will not be taken into account when sizing that container div; in other words, that container will act like there are no divs inside.
To fix this you need to place another (empty) div inside the container, after the floating divs, and assign the style "clear: both" to it so that it will take the floating divs into account when being positioned. In turn, the container div will see the last cleared div and resize to take it into account.
Alternatively, sometimes you can skip adding the cleared div inside the container, and just add the style "overflow: hidden" to the container itself. This is somewhat of a hack, but a pretty robust one as far as hacks go.
Hope this solves your problem; if not we'll have to wait for more information.
It's simple, yes, you have a div, but you define its display as inline (with .browseBtn definition). So it's not a block-element anymore and it doesn't listen to width definition.
I've corrected the fiddle, although it might have other side effect.

Is it okay to make a nested element wider than its parent?

I have an element nested inside another element (i.e. parent element). The thing is, I want to make the child element wider than the parent element — as I am unable to find the PHP code that I need to move it outside its current parent element.
This is how the page looks (click image to enlarge):
THE PLOT: You are seeing two content blocks in the page — <div id="Content">...</div> is one block floating left and <div id="Panel">...</div> is another that's floating right.
See the blue color block of text? It's the title of a discussion thread in my forum and is represented by <div class="Tabs HeadingTabs DiscussionTabs FirstPage">...</div> in the code. As shown by the arrows, I would like to extend it to full width of the page using css width:980px;.
The thing is, <div class="Tabs HeadingTabs DiscussionTabs FirstPage">...</div> is a child element whose parent element is <div id="Content">...</div>. The width of the parent element is 700px, but I need the width of the child element to be 980px.
So what I am doing is this:
set the child element's width to 980px. (width:980px;)
Now the child element overflows the parent element and on top of the the right-floating block as well. (i.e., <div id="Panel">...</div>)
So, I gave the right-floating block some margin-top so that it comes out from hiding below the extended element.
The following image represents just that (click image to enlarge):
So my question is — is what I am doing okay or is it a bad thing to do? Is this cross-browser compatible? (i.e., does it appear the same across all browsers?)
Hope someone can clarify on this. Thanks.
Just move the heading outside of <div class="Content">.
<div class="Tabs HeadingTabs DiscussionTabs FirstPage">
</div>
<div class="Content">
...
</div>
Don't use JavaScript just for this, that would be a mistake.
I also feel compelled to mention that I don't think that heading should be full width anyway, it doesn't represent a heading for the sidepanel, it's for the thread (which is only in the left column).
I wouldn't. As a general rule of thumb, I keep the parents bigger than the children. See this and this. I'm sure you would see differences from browser to browser if you implement this using HTML and CSS.
Have you thought about using JavaScript to accomplish what you want to do?

Why should I use a container div in HTML?

I have noticed a common technique is to place a generic container div in the root of the body tag:
<html>
<head>
...
</head>
<body>
<div id="container">
...
</div>
</body>
</html>
Is there a valid reason for doing this? Why can't the CSS just reference the body tag?
The container div, and sometimes content div, are almost always used to allow for more sophisticated CSS styling. The body tag is special in some ways. Browsers don't treat it like a normal div; its position and dimensions are tied to the browser window.
But a container div is just a div and you can style it with margins and borders. You can give it a fixed width, and you can center it with margin-left: auto; margin-right: auto.
Plus, content, like a copyright notice for example, can go on the outside of the container div, but it can't go on the outside of the body, allowing for content on the outside of a border.
This method allows you to have more flexibility of styling your entire content. Effectively creating two containers that you can style. The HTML body tag which serves as your background, and the div with an id of the container which contains your content.
This then allows you to position your content within the page, while styling a background or other effects without issue. Think of it as a "Frame" for the content.
I faced this issue myself redesigning a website. Troy Dalmasso got me thinking. He makes a good point. So, I started to see if I could get it working without a container div.
I could when I set the width of the body. In my case to 960 pixels.
This is the CSS I use:
html {
text-align: center;
}
body {
margin: 0 auto;
width: 960px;
}
This nicely centers the inline-blocks which also have a fixed width.
The most common reasons for me are so that:
The layout can have a fixed width (yes, I know, I do a lot of work for designers who love fixed widths), and
So the layout can be centered by applying text-align: center to the body and then margin: auto to the left and right of the container div.
Certain browsers (<cough> Internet Explorer) don't support certain properties on the body, notably width and max-width.
This is one of the biggest bad habits perpetrated by front end coders.
All the previous answers are wrong. The body does take a width, margins, borders, etc. and should act as your initial container. The html element should act as your background "canvas" as it was intended. In dozens of sites I've done I've only had to use a container div once.
I'd be willing to be that these same coders using container divs are also littering their markup with divs inside of divs--everywhere else.
Don’t do it. Use divs sparingly and aim for lean markup.
I later found this, years after my answer, and see that there are some follow up replies. And, surely you jest?
The installed placeholder site you found for my domain, which I never claimed was my markup or styling, or even mentioned in my post, was very clearly a basic CMS install with not one word of content (it said as much on the homepage). That was not my markup and styling. That was the Silverstripe default template. And I take no credit for it. It is, though, perhaps one of only two examples I can think of that would necessitate a container div.
Example 1: A generic template designed to accommodate unknowns. In this case you were seeing a default CMS template that had divs inside of divs inside of divs.
The horror.
Example 2: A three column layout to get the footer to clear properly (I think this was probably the scenario I had that needed a container div, hard to remember because that was years ago.)
I did build (not even finished yet) a theme for my domain and started loading content. For this easily achieved example of semantic markup, click the link.
http://www.bitbeyond.com
Frankly, I'm baffled that people think you actually need a container div and start with one before ever even trying just a body. The body, as I heard it explained once by one of the original authors of the CSS spec, was intended as the "initial container".
Markup should be added as needed, not because that’s just the way you've seen it done.
div tags are used to style the webpage so that it look visually appealing for the users or audience of the website. Using container-div in HTML will make the website look more professional and attractive and therefore more people will want to explore your page.
Well, the container div is very good to have, because if you want the site centered, you just can't do it just with body or html...
But you can, with divs. Why container? It’s usually used, just because the code itself has to be clean and readable. So that is the container... It contains all of the website, in case you want to mess around with it :)
Forget the container. It's just a habit from the old, very old days.
Everything you can do using a div—you can also do it on a body tag.
I've never heard of issues using a div class="container" markup. But I have heard of issues using body as a top level container. See this article. Stick with the tried and true; who knows what browsers will do in the future.
Most of the browsers are taking the web page size by default.
So, sometimes the page will not display same in different browser. So, by using <div></div>, the user can change for a specific HTML element. For example, the user can add margin, size, width, height, etc. of a specific HTML tag.