I've seen this quite a few times now. When people want to assign a CSS property to the whole window/document, they sometimes do
html, body {
myCSSProperty: someValue;
}
For example, see the answer I accepted here, or see this article.
I am wondering if assigning CSS properties to both html and body is to overcome browser bugs, required for all browsers, a purely psychological thing, a common misconception or misunderstanding of the tags html and body, or something else.
I would be glad if someone could demystify the situation for me, separating the cases where CSS properties need to be assigned to html or body, or both, with specific examples and explanations.
This article has great information about the <html> and <body> tags in terms of CSS. The short of it is this (taken from the top of the article):
The html and body elements are distinct block-level entities, in a parent/child relationship.
The html element's height and width are controlled by the browser window.
It is the html element which has (by default) overflow:auto, causing scrollbars to appear when needed.
The body element is (by default) position:static, which means that positioned children of it are positioned relative to the html element's coordinate system.
In almost all modern browsers, the built-in offset from the edge of the page is applied through a margin on the body element, not padding on the html element.
Related
Attempting to have three backgrounds with various z indices is resulting in only one layer being shown.
This jsfiddle has the relevant code and examples (minus the huge foundation css file... the behaviour is unaltered without it).
the classes that are failing are
skyline
and
#footer_container
whereas #header_container is running properly.
I've updated your fiddle here.
#footer-container wasn't displaying its background image because of your CSS syntax. Since you combined both the background image URL and no-repeat, you would need to use the background shorthand rather than the background-image property.
A great way to check this sort of thing is to inspect your element with your browser (in Chrome: Right Click > Inspect Element) and find the element that isn't displaying properly. You'd notice that the background image property of your #footer-container div was being literally crossed out by Chrome because of a syntax error.
There was also a bit of a syntax problem in your .skyline class. First, both your body and the inner div have a class of .skyline. This is kind of confusing so you should remove it or be more specific in your CSS, e.g. with p.skyline, div.skyline, etc. As you've got it currently written, both your body and that .skyline div will get the background image. You also didn't include a closing </body> tag. I'm assuming you don't want the background image on both that div and the body, so I removed your body tag in the updated fiddle.
Also, in your .skyline css, you have both height: 546 and height: auto. First of all, height in CSS should have a specific value (e.g. px, em, %). For an <img src="img.jpg" height="546" />, however, simply putting "546" as its height would be fine. Second, you should only have one height value per class.
The skyline problem itself is that you didn't close your curly bracket on line 126, so no styling at all was applied to .skyline. Once it's closed, there's still a problem. It has no width. So let's set it to 100%. Still nada. This is because .skyline's parent div#container also is widthless. So let's toss a 100% width at it too. Then we're in business.
A good text editor that highlights syntax errors could help you out a bunch, especially when you're just starting out.
The div is the quintessential block level element, and the span is the inline counterpart. They are the simplest possible form of that display type, with no other properties. In a great many cases I will give either of them the style:
display: inline-block;
This makes them behave in a very handy way. For div it means boxes that will easily sit next to each-other, while maintaining their width and height as defined. For the span I can use this to make colorful rectangles. The inline-block display is great for so many things, but I have never seen an element that starts as an inline-block without anything else going on.
Images (img) are, but they are obviously not suited for the same things as a div, they have that style, but they fulfill a different purpose.
So is there an element that I don't know of that is the quintessential inline-block, or is this left out?
And if not, why? The uses of inline-block are numerous, so it seems like there should be some element that takes that basic form.
There's no such element, and there are some good reasons why not.
inline-block has several uses in contemporary web design. However it is not part of the original design, which only includes block and inline elements. Instead it derives from <img> as added by NSCA Mosaic. (Which uses the wrong markup and helped defeat the original "responsive design". I think we've only just started to fix the problems with img).
Further down the timeline, inline-block still wasn't part of IE4 or 5, or any version of Netscape. It wasn't part of the early HTML4 era. So we wouldn't expect to find your hypothetical element in that version of the standard. inline-block only appears in CSS2, which came after HTML4. (Look at the reference section in each standard).
Unlike block, inline-block is affected by whitespace in the markup. It's implied by the name, and it's what you'd expect from looking at <img> in the middle of some text (aka wordprocessor object anchored "as character"). But beyond its origins there, the whitespace-dependent markup soon becomes very troublesome. I wouldn't expect W3C HTML5 to enshrine this in a new element.
Specifying it would certainly involve argument about "semantics", separation of content and presentation etc. (As well as what to call it :). And if the default rendering makes whitespace significant - is that not part of the semantics of that element? Consider using images to represent words - or individual letters of a word (with appropriate alt text). This illustrates that the presence of whitespace (or not) around this element would be semantically significant, just like the presenceofwhitespaceseparatingwordsissemanticallysignificant. That seems like a big problem to me.
inline-block is often promoted as a modern alternative to using float everywhere. But neither is genuinely suitable. This is why CSS3 will standardize new layout modes: "flexbox" and "grid", to support modern responsive designs with genuine, clean markup. No dummy markup (or dummy generated content). No hacking around whitespace-dependence.
The only elements I can think of that have an in-line appearance, but allow for a width and height to be set, are:
img,
input,
textarea
select, and
button
The only element here, though, that can take HTML content is the button element; which is not an ideal use of the button since it's intended to be an element with which the user might/should interact; rather than simply a container element.
While you may have multiple uses for such an element, there's no convincing reason, given the ease with which the display property might be changed, that the W3C, or any other authority, should explicitly define one; especially given that the only difference between inline and inline-block is the ability to assign dimensions and margin.
The img tag is inline-block by default:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img
Edit: You can check this SO question: Is <img> element block level or inline level?
I have been attempting to dissect some of the css on the behance.net site. I've looked through it in the chrome inspector pretty thoroughly, but some things I just don't understand.
On the top navigation bar, there is text that says "Discover", "Galleries", "Jobs". I notice that "Discover" is a div inside of an anchor tag. I was under the impression that block level elements could not inhabit inline level elements. But this is a pretty professional looking site, and they're doing it. Does it not break in some browsers?
<a class="nav-link" href="/"><div class="nav-text nav-sprite nav-sprite-discover">Discover</div></a>
Thanks!
As per the HTML5 documentation, <a> elements have a transparent content model, which means they're allowed to contain block level elements.
In HTML4 and below, <a> elements were inline elements, which could not contain block content.
If Behance were using a HTML5 doctype, this would be valid (as zzzzBov says, a elements have a transparent content model in the current draft of the HTML5 spec, meaning they can contain block-level elements).
However, as they're using an XHTML doctype, their usage in this context is invalid. It won't break on (most) browsers, but it's not strictly correct and I wouldn't emulate it.
I have used CSS pseudo-element selectors like many others, mainly just to say I've used them.
But I am racking my brain and struggling to come up with a reason for their place alongside markup.
Take the following example:
<p>Hello</p>
p::after {
content: "*";
}
What is the advantage of using this over using <span> tags?
Am I missing the point of ::before and ::after? Is there some rock solid reason for using them over pre-existing semantic markup?
The CSS2.1 spec says this about generated content:
In some cases, authors may want user agents to render content that does not come from the document tree. One familiar example of this is a numbered list; the author does not want to list the numbers explicitly, he or she wants the user agent to generate them automatically. Similarly, authors may want the user agent to insert the word "Figure" before the caption of a figure, or "Chapter 7" before the seventh chapter title. For audio or braille in particular, user agents should be able to insert these strings.
Basically the purpose is to minimize pollution of the content structure by "content" that is otherwise more suited as presentational elements, or better to be automated.
If you're talking about :before and :after: They're used as presentational elements for cases where adding more elements into the actual document would be mixing structure with appearance. A few cases I've seen:
Bullets in bulleted lists
Quotes around q elements
Stylish shadows
Decorations and the beginning or end of text
These particular pseudo-elements are designed to add “content” that’s actually just a visual aid.
The prime example is adding quote marks around the <q> element, which Firefox does using these selectors in its default stylesheet. Some people also use them to clear floats.
You shouldn’t use them for actual content, despite the name of the CSS content property, as non-visual user-agents (i.e. screen readers) should ignore them.
I’ve never come up with much use for them, although I did once use them to add little Unicode icons to hovered links on a personal site — like you, pretty much just to say I’d used them.
Honestly, the only worthwhile useage is to force elements to have the correct size in the dom. Use this code for example:
<div class="container">
<div>this div is floated left</div>
<div>this div is floated left</div>
</div>
Typically you would have to specify an exact or min height for the .container div. if you were to apply ":after" with some very simple css, any background you applied to the .container would actually show up (in almost every browser) properly, with few to no shims.
.container:after{
content:'.';
height:0;
line-height:0;
display:block;
float:left;
visibility:hidden;
}
Now try that example, applying a background color or image, and you'll see that the .container div always has the appropriate height (which would be the total combined height of the inner contents) even if all the inner html is floated (as is the case in most ul/li css buttons).
I also use an after on every div that I wrap all my content in per html page. This is due to the possibility that all of the content on a given page could be floated, and I want to make sure that my content div always has the correct size/padding with the appropriate background.
CSS3 Pseudo Selectors also include essential ones like :link, :hover, :active, :focus, :first-child, :nth-child. It's impossible to make a useful site without most of these.
As for the less commonly used pseudo-selectors like :after and :before, they're useful in certain cases where the content is dynamically generated and you want to insert something before a specific element or tag.
Hello
I am trying to use block level linking in a html5 specified document. But when I have an img inside a div and the div has a width, the img is not clickable in ie7.
Any solution to this?
I get an error when I try to post the html but I hope you get the idea.
HTML
a --> div --> img
css
div {width:140px;height:70px;}
Do you need the div element for any special reason?
You can turn a into a block-level element using the display: block property and assign it the dimensions that you want.
Probably what is happening is that the div is terminating the a prematurely since in pre-HTML5, you were not allowed to nest a block-element with an a.
Remember, IE7 is not HTML5 compliant, so it behaves like HTML4.1 with any IE7 behavior/quirks/bugs.