They are both block elements. So why can I nest a <div> inside a <div>, but can't nest a <p> inside a <p>? (Well, I can, but the second <p> just starts a new block.)
I have read about the div tag and p tag, but I don't see anything there that explains it. If it is there, then it goes over my head.
For the record, I do not want to nest a p tags, I am just trying to understand the fundamentals more.
Per your links (in the Permitted content section), <p> is allowed to contain phrasing content, while <div> is allowed to contain flow content (which includes the phrasing content element types).
On a practical level, browsers also typically apply margin to <p>.
both are block elements, but <p> tags come predefined with some margins/padding. you can inspect both elements in any modern browser and see the default properties
funny thing is, in the name of consistency, all elements have redefined by things like bootstrap/boilerplate CSS files that give all elements the same starting look and feel so we no longer have to guess which tags have what default properties. Which sort of goes against the original HTML spec for the sake of our sanity
Related
This question already has answers here:
Is putting a div inside an anchor ever correct?
(16 answers)
Closed 8 years ago.
I'm making a website that utilizes spans with a background-image:(so basically a picture) with a span nested in that that will display text over the picture.
The text and picture spans are both links that would go to the same place. I want my users to be able to click anywhere on the text or picture to navigate away from the page.
Instead of using using two tags that will link to the same thing in the same line of code, I noticed that I can put two spans, both the picture and the text, inside of the same tag and Chrome allows it.. but I don't know how support is on this kind of thing in other browsers.
Here's an example of what I'm doing:
<a href="https://theartofmikeyjoyce.com/">
<span class="cell E4">
<span class="text">MIKEY<br/>
<p>IN THE CLUB II</p>DIGITAL COLLAGE
</span>
</span>
</a>
Now normally I'm aware that anchor tags shouldn't have inline elements so I set display:inline-block' on the span tags. I'm also using HTML5, and the documentation I found on this was vague at best. The code seems to work on all modern browsers I've tested, but is this really canon?
HTML and CSS are two separate things. HTML5 defines which elements may and may not be nested in which other elements, and while it also suggests how they should be displayed, how this display is implemented is specified by CSS.
Changing the CSS display mode of an element does not change where it may appear in an HTML document, since HTML doesn't know how an element is being displayed using CSS (if at all).
In HTML 4, the a element may only contain other inline elements. Note that HTML 4 has its own definition of "inline" and most if not all inline elements correspond to display: inline in CSS, but again, the two languages are separate.
In HTML5, the a element has a transparent content model, which means any element can appear as a child of the a element provided that element can appear as a child of the parent of the a element. So for example, while a section > a can have a div as a child, a p > a cannot, because a div may appear within a section, but never within a p.
These are rules given by the HTML standard, but as you can see they say nothing about whether an inline element can contain inline-block elements. You will find that information in the CSS standard instead.
In summary, inline-block elements are similar to block boxes, except that they are laid inline, just like regular inline elements. That's all there is to it. Assuming your a element is an inline element, browsers should have no problem rendering inline-blocks along the same line(s) as the a element (as its children, of course).
On the other hand, if your a element were to contain block-level elements (i.e. display: block), the behavior, while still pretty well-defined, becomes less predictable thanks to browsers like Chrome.
I think this is what you are looking for.
HTML 5 states that the element "may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links)".
Usually no, but if set to display: inline you should be fine.
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.
My goal is to provide something like a "Read More" link next to a text block. It is automatically added before the content is sent to the client and the block that contains it should be adjacent to the prior text, just as if its part of this text. The problem is that the text block contents are authored using TinyMCE, thus the content will be packed up in a variety of tags (mainly the paragraph tag) - thus the following content will be pushed to the next line (or block).
So before going through the pain of deconstructing the content of the textblock serverside to decide where and how to attach the other block, i thought there might perhaps be a way to get this done using pure CSS. I have a feeling it won't be possible as i think it would require the adjacent block to sort of override properties of the prior block, but then again there might be a thing or two that i missed about all this CSS/inline business.
I created a JSFiddle here
Thank You for any constructive input on the matter!
see this fiddle: http://jsfiddle.net/D2RnS/5/
p + p, .adjacentBlock { float : left; }
I just floated left the second paragraph and the adjacentBlock. Doing so remember to also apply some kind of float clearing to the parent container (the <div> in your example)
You may use use pseudo-elements in css, by adding an ID to your previous tag:
#block:after {
content:"You will have this appended.";
}
You can see the effect here: http://jsfiddle.net/D2RnS/14/
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.