My site http://carlnelson.x10.mx/ has its container acting oddly, its meant to hold both the 'full' div tags. But it refuses to basicly, it only includes the text I added 'this is a test'
divs misbehaving
- Thread starter carlnels
- Start date
- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
Both of your "full" class divs are floated; you need a clearfix to force the container div to extend all of the way down to cover them. Note that they are being constrained as far as the width and position goes; that means that they are "inside" your container, but floating them means that their height is removed from the document flow. (Why they're floated I can't figure out.) If you intend to keep them floated, you'll need to add an element (or, rather, a CSS pseudo-element) that clears all floats. Something like this will do:
Ideally you'd use a double colon before the after pseudo-element, but some browsers don't understand that and all of them do understand the single colon.
Code:
container full:last-of-type:after {clear: both;}- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
That's an utter mischaracterization - the problem here was that an unnecessary feature (float) was used (and it was inserted deliberately). The default behaviour was what was desired; adding the float without anything to float in (keep in mind that the feature is designed to allow body text to flow around images, tables and call-outs) was what broke things. "Hacking" the float is a legitimate strategy for self-adjusting "tiling" behaviour, especially in browsers that don't understand flexbox, but that means restricting the width of the tiles and adding an element that pulls the parent down to the length of the floated content - and you do need to recognize that it is a hack.
I'm aware of that. By what I said, I mean it can take a bit of hackary to get it to display as intended.
- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
...or skipping the hackery and making things easy on yourself, as the case may be 
Seriously, the closest I'll come to a hack these days is a clearfix pseud on those rare occasions where floating tiles is appropriate, perhaps a pseud for flourons in a colophon and using text-shadow (a lot of them) and a background-image to make a good-looking link underline¹.
There are two big problems with CSS, and they're both developer/designer problems: understanding cascades/inheritance (that can be tricky at times, and having to use !important everywhere is a pretty good sign that the document you're styling is too deeply nested in its structure); and expecting a medium that reflows on demand to act like a piece of paper that's printed once and for all.
There is a third "CSS problem" that actually boils down to using the appropriate HTML. Leaving aside the need to support old versions of IE, I can't really think of a good reason why <div> should be a regular part of the front-end developer's vocabulary anymore. It has its uses, particularly for overlay elements like quasi-modal dialogs, but it should be the rusty old tool at the bottom of the toolbox, not the first thing you reach for. The "appropriate HTML" problem really is a problem, though, since there are commonly-used document elements that aren't elements in HTML yet: footnotes, marginalia, pull quotes, and so forth, so we have to use <aside> with a class instead, and that's both semantically unsatisfying and has no appropriate default rendering. Until things are fixed, we do the wrong thing, hope that the meaning is clear, and wash our hands afterwards.
_________________________
¹ There's no non-hack way to make an underline look typographically good. Underlining only has a legitimate use on the web; they were used as substitutes for italics, bold and small caps on the typewriter, and would be replaced appropriately when the document was typeset. There was no need for type designers to worry about underlining — you may note that you'll have roman, italic, bold and bold italic versions of just about every font, but there's no roman lined, etc. Dead-tree books don't need clickable links, though, and underlined is the convention for links. This method — minus the scripting and unnecessary extra classes, since ordinary CSS selectors will work just fine in constraining the effect — works very well, provided you don't use words like "pygmy" alone as link anchors.
Seriously, the closest I'll come to a hack these days is a clearfix pseud on those rare occasions where floating tiles is appropriate, perhaps a pseud for flourons in a colophon and using text-shadow (a lot of them) and a background-image to make a good-looking link underline¹.There are two big problems with CSS, and they're both developer/designer problems: understanding cascades/inheritance (that can be tricky at times, and having to use !important everywhere is a pretty good sign that the document you're styling is too deeply nested in its structure); and expecting a medium that reflows on demand to act like a piece of paper that's printed once and for all.
There is a third "CSS problem" that actually boils down to using the appropriate HTML. Leaving aside the need to support old versions of IE, I can't really think of a good reason why <div> should be a regular part of the front-end developer's vocabulary anymore. It has its uses, particularly for overlay elements like quasi-modal dialogs, but it should be the rusty old tool at the bottom of the toolbox, not the first thing you reach for. The "appropriate HTML" problem really is a problem, though, since there are commonly-used document elements that aren't elements in HTML yet: footnotes, marginalia, pull quotes, and so forth, so we have to use <aside> with a class instead, and that's both semantically unsatisfying and has no appropriate default rendering. Until things are fixed, we do the wrong thing, hope that the meaning is clear, and wash our hands afterwards.
_________________________
¹ There's no non-hack way to make an underline look typographically good. Underlining only has a legitimate use on the web; they were used as substitutes for italics, bold and small caps on the typewriter, and would be replaced appropriately when the document was typeset. There was no need for type designers to worry about underlining — you may note that you'll have roman, italic, bold and bold italic versions of just about every font, but there's no roman lined, etc. Dead-tree books don't need clickable links, though, and underlined is the convention for links. This method — minus the scripting and unnecessary extra classes, since ordinary CSS selectors will work just fine in constraining the effect — works very well, provided you don't use words like "pygmy" alone as link anchors.