For example, in HTML 4.01,
1) inline elements in general cannot include other block elements (example: a <span> or <a> should not include any <div>.) But this rule is more forgiving, as most browsers won't alter the HTML structure like in rule 2 below. (And many browsers nowadays will handle the desired result of a <div> being inside of an <a> tag.)
2) <p> elements cannot include any <p> element. If any <p> appears before the closing of a previous <p> element, then the previous one will be immediately closed. This rule seems more strict as it alters the structure of the HTML document.
Are the rules above accurate, and are there other rules stating an element cannot include other elements? (as offsprings).
Are you talking about HTML5? Since that spec is supposed to supersede any other at this time, we'll stick with that.
I'm not going to go through each individual element, but if you need to look something up, here is the reference:
http://www.w3.org/TR/html5-author/
The section that talks about "Content Models,"
a description of the element's expected contents
is here: http://www.w3.org/TR/html5-author/content-models.html
You can see some examples in the specs for specific elements:
http://www.w3.org/TR/html5-author/the-html-element.html#the-html-element (the html element):
A head element followed by a body element.
Specific Examples
http://www.w3.org/TR/html5-author/the-a-element.html#the-a-element
http://www.w3.org/TR/html5-author/the-span-element.html#the-span-element
http://www.w3.org/TR/html5-author/the-br-element.html#the-br-element
a
We learn from the first link (on the a element) that its content model is Transparent, but only if there is no Interactive Content descendant.
By looking at the definitions of "Transparent," a we see that a inherits its Content Model from its parent. That means that your initial definition is incorrect and a can indeed contain a div, but only if its parent can. The docs above even include an example of nested "Transparent" content model elements.
Since a cannot contain any "Interactive Content" model elements, it cannot contain a button element at all. This makes sense because there would be a conflict as to which element actively responded to a click.
span
When we take a look at the second link, span, we see that its Content Model is "Phrasing Content," which is basically text and markup for paragraph-level text. The definition is not entirely specific, but it does include a guideline:
Most elements that are categorized as phrasing content can only contain elements that are themselves categorized as phrasing content, not any flow content.
Since div does not have a "Phrasing Content" model (it's "Flow Content,") span cannot contain it. This means that the span should follow the above rule and only contain any other "Phrasing Content" elements and/or embedded content or Text. If the above rule is broken, it will be listed specifically on the "Content Model" description of the element (remember the special rules for the a element about "Interactive Content.") span has none.
br
The third link, br, says that the Content Model is "Empty." Unfortunately, the W3C does not include a specific definition for that, but I think it's fairly obvious: it can contain no descendants at all. Not even text nodes. Any "Empty" Content Model element does not have a closing tag (you would write it as <br> not as <br></br>).
Your Questions
Are the rules above accurate?
First rule (inline vs. block)
What you've said is misleading. HTML has no concept of inline vs. block elements. These are CSS styles. Most browsers have a default setting for an element's display style as inline or block depending upon whether it is a "Phrasing" or "Flow" Content Model respectively (as a general rule; there is nothing hard and fast about that) or just traditionally.
If you want to say that "Phrasing Content" elements cannot contain "Flow Content" elements then you would be correct because that is in the spec specifically. This also works practically because span cannot contain div (as you indicate).
However, saying that a should not include any div is wrong. a can include div as long as its parents can. If a is contained in a span, it cannot contain div. However, if a is contained in body or another div, it can.
As for Browsers "being forgiving," this is all very convenient for many developers who cannot take the time to create valid HTML, but it can be a pain for those of us who do want to take the time. Browsers usually don't alter the "HTML structure" as you say -- what they alter is the DOM. Also node that the web vendor spec is a little different from the "Web author" spec I posted above, but we are the authors.
Second Rule (p containing p)
This is true because of an important point I left out: Context.
From the p element spec:
Contexts in which this element can be used:
Where flow content is expected.
Since p is "Phrasing Content," that means that another p cannot be put inside of a p because "Phrasing Content" is expected, not "Flow Content."
Any Other Rules?
The HTML5 spec has a huge number of elements, so I simply cannot go into all of those details here. I went into details about span and a contents vs. div as well as p because you brought those up specifically. Look at how long this answer is!
What you are going to need to do is take a look at whatever elements you have questions about in the spec itself. Take a look at the Context and Content Model sections to see whether or not your use of the element is valid.
In Summary
Refer to the spec when you have a question about how the element should work. To answer questions about how you should use the element (with respect to its container and contents), look at:
Contexts in which this element can be used:
Content model:
This tells you what can contain the element, what it can contain, and when.
If you have questions about whether your HTML is valid, you can always use the very nice W3C markup validation service:
http://validator.w3.org/
If you are using Chrome, you can take a look at the Chrome Inspector (F12) and compare the output DOM to the source HTML itself. You will notice for example that Chrome will automatically close nested p tags when it generates the DOM.
Regarding your second rule (in HTML 4.01) it's a little stronger: a P element cannot contain block-level elements (including P itself).
Based on your edited post --
<a> is now treated as a block-level element, as of html5 --
regardless of what standard you mark the page with, the browser will likely treat the element as if it's html5, so work from there, rather than backwards.
<a> can't contain <a> or any element which is meant to be interacted with (inputs/buttons).
<hX> cannot contain an <h_> tag of X or higher (in terms of hierarchy).
ie, <h3> cannot hold an <h1> or an <h2> or an <h3>
If you write it that way, the outline will close off the outline until it reaches the proper hierarchy-level.
<h1></h1>
<h2></h2>
<h3></h3>
<h2></h2> // starts a new branch of H2s, in terms of outline
<h1></h1>
<h2></h2>
<h3></h3>
<h1></h1> // closes the entire previous branch and all leaves, and starts a new outline
<ul> and <ol> can ONLY contain <li>s as immediate descendants.
<li>s can hold anything you want them to (except <li>s or other list-nodes), including other ordered/unordered/definition lists...
...but the <ul> and <ol> elements can only have <li> as their first-generation children.
Same deal with <dl>s with <dt> and <dd> nodes.
Most of the rest of it is either common-sense (don't put elements in <script> tags, <img> tags, <br> tags, <meta> tags, <legend> tags, et cetera)...
...or they're still having the kinks worked out (like what figure/figcaption can hold and the proper format for <picture>, et cetera).
Related
Sometime ago I read somewhere that one single line of text is considered a paragraph, therefore valid to be placed into a <p> element that "represents a paragraph/block of text".
Browsing around this is confirmed by some examples that I've just found:
http://www.w3.org/wiki/HTML/Elements/p#Example_A
http://reference.sitepoint.com/html/p
In my particular case I am making a <form> that includes some validation messages for each field and that are only meaningful to the user once they interact with the page.
For positioning purposes (<p> is a block element) would be easier to use <p> elements for these messages, but since <span> is a more generic and meaningless element I could use it too with "display:block" but I am not sure if I should do this instead.
Could you tell me what is the element to be used in this case?.
Thanks!
The HTML5 spec defines that the p element "represents a paragraph", and a paragraph is defined as:
A paragraph is typically a run of phrasing content that forms a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping. For instance, an address is also a paragraph, as is a part of a form, a byline, or a stanza in a poem.
No-one can generally answer if you should use p or not, this depends on each particular case, and also your understanding of the content.
Now, if you think p may not be appropriate, why do you want to go with span when you are looking for a block element? Just use div instead.
SPAN is kind of Styling tag only. it is being used when you are going to add a class by yourself and you don't need any un-wanted (Default) styles.
And P is which normally comes with default styling from a client browser and if you are using some pre-written styles (bootstrap etc).
When writing about algorithms, it is often very convenient to write some (pseudo)code inside a paragraph, or even in the middle of a sentence. To visually support the structure of a more complex sentence, lists come handy too.
Obviously, one sentence must not be split across different paragraphs. But in our case it has to be due to HTML nesting rules.
Paragraph is the p element, which cannot contain block-level elements. Unfortunately for our case, pre and lists are block-level.
If I do not obey the spec and include pre or ol/ul/dl in a p, the p is automatically closed right before the element’s start tag by any parser I know. (This is due to the SGML OMITTAG feature settings on p.) Maybe this and backward compatibility are the reason behind the design decision of disallowing pre and lists inside p.
Is there any way, how to include lists and longer code snippets into paragraphs?
I could re-formulate my sentences and paragraphs not to need snippets and lists, but it needs much thinking and attention and could make my text harder to read and understand. This is not a solution for me.
I could use code with whitespace: pre and display: block for longer code snippets and code with whitespace: pre-wrap for the shorter ones. Is this semantically correct?
I could think of lists inside sentences as mere visual sugar with no semantics at all. Then I would use spans with display: list-item to make them look like lists. Would that be correct from the semantical point of view? Is the sacrifice of semantical structure necessary?
This question applies to both HTML and XHTML as the rules for nesting elements are the same. By HTML i mean HTML 4.01 Strict, by XHTML i mean XHTML 1.0 Strict. Is this issue somehow addressed in HTML 5?
To be explicit, I want a standards-compliant, both syntactically and semantically correct solution, not a non-standard hack of any kind. Specifically, turning p into div is not a solution for me.
Related questions
ul element can never be a child of p element
<code> vs <pre> vs <samp> for inline and block code snippets
<pre> tag making browsers close paragraphs
Can I have a <pre> Tag inside a <p> tag in Tumblr?
Should ol/ul be inside <p> or outside?
unordered list in a paragraph element
Nest lists in paragraphs in html
See also
CSS Design: Taming Lists # A List Apart
As far as HTML is concerned, all that a single <p> element represents is a block of phrasing content that happens to flow like a paragraph of text. Even though it's called a paragraph, it doesn't have to strictly represent a paragraph of text in writing.
You are not compromising semantics in any way by breaking a paragraph, even mid-sentence, into two <p> elements in order to introduce a list or a block-level code snippet. It is completely acceptable.
As a matter of fact, HTML5 agrees (whereas HTML 4 woefully has absolutely nothing to say beyond "the P element represents a paragraph"):
List elements (in particular, ol and ul elements) cannot be children of p elements. When a sentence contains a bulleted list, therefore, one might wonder how it should be marked up.
For instance, this fantastic sentence has bullets relating to
wizards,
faster-than-light travel, and
telepathy,
and is further discussed below.
The solution is to realise that a paragraph, in HTML terms, is not a logical concept, but a structural one. In the fantastic example above, there are actually five paragraphs as defined by this specification: one before the list, one for each bullet, and one after the list.
The markup for the above example could therefore be:
<p>For instance, this fantastic sentence has bullets relating to</p>
<ul>
<li>wizards,
<li>faster-than-light travel, and
<li>telepathy,
</ul>
<p>and is further discussed below.</p>
If you view the source of the document, you can see that even the quoted example consists of a <p> element containing the text "The markup for the above example could therefore be:", immediately followed by a <pre> element containing the example markup.
If you are still concerned, HTML5 offers an alternative, but that basically involves using a <div> instead of separate <p> elements, which as you've stated is not a solution for you.
Lastly, it is safe to assume that everything I've mentioned applies to HTML 4 and XHTML 1 as well. For what it's worth, this concept was explored in XHTML 2, which would have allowed <p> elements to contain any other type of content.
What is the difference between <p>, <div> and <span>?
Can they be used interchangeably?
Because I am facing problem that, for <span> margin not working but for the <div> and <p> it's working..
p and div elements are block level elements where span is an inline element and hence margin on span wont work. Alternatively you can make your span a block level element by using CSS display: block; or for span I would prefer display: inline-block;
Apart from that, these elements have specific semantic meaning, div is better referred for a block of content having different nested elements, p which is used for paragraphs, and span is nothing but an empty element, hence keeping SEO in mind, you need to use right tag for right thing, so for example wrapping the text inside div element will be less semantic than wrapping it inside a p
A <p> should contain paragraghs of text, a <div> is to layout your page using divisions and a <span> allows markup to be styled slightly different, for example within a <p>
This is how they should be used semantically, the styling of them however using CSS is up to you.
As a web developer, I can't help but feel all these guidelines are incredibly misleading in the year 2015.
Sure, a "p" tag was at one point designed for paragraph use... but in 100% of my applications, designs, and just day-to-day general development, we've encountered nothing but limitations imposed by the "p" tag... it offers no benefit in today's internet.
I would say yes, "p" is a descriptive element, and for that reason if that's all it did; "describe something", I'd be all for it... but it DOESN'T just describe the content, it straight up ALTERS the content, which while already being a limitation in itself, isn't all it does, it also LIMITS the content. Why anyone in their right mind would purposefully embrace a limiting building block when it comes to web development is beyond me. From a design standpoint it doesn't make sense. From a structural standpoint it doesn't make sense. From any from of DOM manipulation PERIOD, it doesn't make sense.
We've all-together stopped using the "p" tag except where we are absolutely forced to (client WordPress post implementations, silly things like that, for example). There is no excuse as to why we can't describe nearly everything with well-named classes and ID's, so we see zero reason to have to bow to "standards" that add no benefit whatsoever, and in fact HINDER every piece of the puzzle. The "p" tag is of no help to the developer, the end-user, nor to modern search engines. In a nutshell... "p" tag is all but deprecated in even remotely complicated implementations (and with very good reason), don't let the comments of these standard's nazi's control how you display your content!
Even on this very site, a site oriented towards developers at it's core, has at the VERY TOP of it's own page a little pop-in piece that could have used a "p" tag as it contains enough text to run around to a second line, but is entirely captured in a DIV (and only a div, not a div -> p) for a nearly infinite number of reasons... foremost being that today, "p" SUCKS compared to any well described block created from DIVs, that is as-well-described (moreso... I say) as a paragraph "p" with the very descriptive id="blurb".
From Stack Overflow:
<div id="blurb">Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.</div>
I say down with
<p>I suck</p>
and long live
<div class="p">I rock</div>
And yes, I do appreciate our current web standards, and things like <span> still have their place, even offering up abilities to do things with some modern browsers you can't accomplish with a <div> container, but it's just that this one in particular, the broken element "p", as a piece of a restructured and modernized HTML... should have been left in the grave where it belongs... this is a generation of web where paragraphs aren't even paragraphs forever anymore... the blocks literally change... it's just plain outdated and impractical.
As others have answered… div and p are “block elements” (now redefined as Flow Content) and span is an “inline element” (Phrasing Content). Yes, you may change the default presentation of these elements, but there is a difference between “flow” versus “block”, and “phrasing” versus “inline”.
An element classified as flow content can only be used where flow content is expected, and an element classified as phrasing content can be used where phrasing content is expected. Since all phrasing content is flow content, a phrasing element can also be used anywhere flow content is expected. The specs provide more detailed info.
All phrasing elements, such as strong and em, can only contain other phrasing elements: you can’t put a table inside a cite for instance. Most flow content such as div and li can contain all types of flow content (as well as phrasing content), but there are a few exceptions: p, pre, and th are examples of non-phrasing flow content (“block elements”) that can only contain phrasing content (“inline elements”). And of course there are the normal element restrictions such as dl and table only being allowed to contain certain elements.
While both div and p are non-phrasing flow content, the div can contain other flow content children (including more divs and ps). On the other hand, p may only contain phrasing content children. That means you can’t put a div inside a p, even though both are non-phrasing flow elements.
Now here’s the kicker. These semantic specifications are unrelated to how the element is displayed. Thus, if you have a div inside a span, you will get a validation error even if you have span {display: block;} and div {display: inline;} in your CSS.
<p> and <div> are block elements by default. <span> is an inline element.
Block elements start and end with a new line in the browser while inline elements do not. "Inline" means they are part of the current line.
With today's complex web designs the purpose of these distinctions are less obvious but if you think back to the early days of HTML (where these tags come from) where documents were basically embellished text with images, the distinction becomes clearer.
Either way, with CSS you can override basically any property of a tag. So if you want a <span> to behave like a <div> or a <p> then all you need to do is add:
span
{
display: block;
}
With this code, you will be able to set the vertical margins as well as the horizontal ones.
1) div element is designed to describe a container of data.
div tag can contain other elements---div is Block Level
2)p element is designed to describe a paragraph of content---para is Block Level
3)span element Usually used for a small chunk of HTML.---span is Inline
4)block-level elements begin on new lines,
inline elements do not.
5)Most browsers insert a blank line between any two block-level elements.
Ex: There will be blank line between para and para and header and para and between two headers,between a paragraph and a list, between a list and a table,
etc
I more thought that,p and div elements are block level element on the other side, span is an inline element. but when you write p in your code it will take space top and bottom but div behavior not like that. Check out this experiment on JS fiddle:
https://jsfiddle.net/arifkarim/9wcef1c3/
I'm stuck deciding which to use as both seem to work.
Should I be placing links <a> inside of <h2> elements?
Or the other way around?
What is the correct standard?
You can only place <h2> elements within <a> elements if you're working with HTML5, which allows any other elements within <a> elements. Previous specifications (or current ones however you want to look at them) never allowed this.
The usual way of doing this is to place <a> within <h2>. This works, has always worked, and has been the only valid way to do it before HTML5, for heading links, as the link refers to the text in that heading. You rarely need to place <h2> within <a> unless that <h2> is part of some more complex structure which functions as a hyperlink as a whole.
Also its not functioning same, there is one big difference.
If you put <h2> into <a> the whole block (for example line) of heading will work like link.
However if you put <a> into <h2>, only visible text will work as link. (you can test it with cursor change)
The answer is that it depends...
From the W3C website, more specifically in the HTML5 semantics page, it is clear that h2 elements (as all other heading tags) have as content model "Phrasing content".
Now, following the Phrasing content link, you get the following description:
Phrasing content is the text of the document, as well as elements that
mark up that text at the intra-paragraph level. Runs of phrasing
content form paragraphs.
and in the following list you have that phrasing content include:
a (if it contains only phrasing content)
So, if the a tag includes only phrasing content, HTML5 allows it to be contained within a h2 tag.
Viceversa, the text level semantics page describes the a element content model as follows:
Transparent, but there must be no interactive content descendant.
Following the Transparent link, at the end of the description is found the following:
When a transparent element has no parent, then the part of its content
model that is "transparent" must instead be treated as accepting any
flow content.
Since in the h2 tag description it is said:
Contexts in which this element may be used:
Where flow content is expected.
an h2 tag may the considered as flow content.
So, if the a tag has no parent, in HTML5 it must be treated as accepting any flow content, including h2 tags.
HTML allows things inside <a> tags
I have this...
<header>
<a href="/home">
<h1>Main heading</h1>
<h2>Sub heading</h2>
</a>
</header>
And it works for me.
The whole heading text including the subheading is clickable as I want. I don't know of a better way to do this with html 5.
The W3C specs for h2 say that its permitted parent elements are anything that can contain flow elements, or hgroups. The specs for a permit parent elements that can contain phrasing or flow elements. h2 can contain phrasing content, and a can contain phrasing or flow content, so based on the spec it appears that either is permitted.
Since you included the semantics tag, I assume you're interested in which 'seems' better too. For my part, since I can't think of when I'd want an anchor to span a heading plus other content, but I can think of plenty of times when a header should contain an anchor plus other content, a inside h2 seems the best route to go.
For some time I've been making websites, but have never really seen discussion of the proper usage of the container tags. I've seen any number of different types of content in the collection tags, but it usually seems that the page creator just picks a style they like and sticks with it.
The main discrepancy in my mind is that between
<p>
<div>
but I'd also like opinions regarding
<span>
and any others I may be forgetting.
HTML was originally created to put the content of documents into some sort of structure understandable to computers. With that in mind, the p tag is supposed to hold anything that would be structured as a paragraph if the content of the page were to be turned into a printed document. The div and span elements are reserved as general-use containers to facilitate formating and grouping of related elements to provide additional levels of structure, perhaps correlating to pages in a text document.
In some cases, p tags should contain other elements, such as anchor (a), image (img) and other in-line elements, because they relate directly to the content of the rest of the paragraph and it makes sense to group them that way, or the text of the rest of the paragraph provides a more in-depth description.
If there is not additional description of those elements, however, it does not make sense to place them in a paragraph simply as a convenient container; a div would be more appropriate. In general, a paragraph is supposed to contain one paragraph of text and any directly related or described elements. Nothing else makes much sense in a paragraph.
UPDATE: HTML5 also adds a number of other semantic "container" elements, including article, nav, header, section, and aside.
I think, the meaning of the tags is something like this:
<p>Paragraph, usually just text</p>
<div>A block, containing anything</div>
<span>Just a simple non-blocking wrapper</span>
The difference between these three (and many other) tags is their semantic meaning. The HTML standard includes both tags with specific semantic meanings (<p> for paragraphs, <em> for emphasized text, etc.) and tags without semantic meaning.
The latter are <div> and <span>, which are used to identify block- or inline-level content which needs to be identified (using, say a class= or id= attribute), but for which a semantically-specific tag does not exist. For example, one may write <p>Hi, my name is <span class="name">John Doe</span>.</p> — indicating that it's a paragraph (which the browser already has an idea how to handle) and that part of it's content is a name (which means absolutely nothing to the browser unless CSS or JavaScript uses it).
These tags are therefore incredibly useful both in adding additional information to an HTML document which doesn't fit within the semantic tags supplied by the standard (see the hCard specification for an excellent example) and for applying visual (CSS) or functional (JavaScript) structure to a document without altering its semantics.
I think page creators should use semantic markup, meaning that the markup they create should communicate meaning (and not presentation). <div> and <p> have different meanings. The former is used to define a division (or section) of an HTML page, the latter to define a paragraph of text.
<p> is a block-level element that should contain a paragraph, comprised of text, inline elements that modify that text (<p>, <a>, <abbr>, etc.), and images.
<div> is a block-level element used to divide the page, almost always in conjunction with CSS styles.
<span>... well, I honestly don't use this tag that often. It's an inline element, and I use it usually when I'd like to apply styles to a portion of text that wouldn't benefit from using something with more meaning, like the <strong> and <em> tags.
I was tought to view <span> and <div> as the "tofu of webdeveloppement", since it has no real flavor but you can do virtually anything with it.
(X)HTML tags define what the text they're surrounding is. Is it and address, is it a link, is it a paragraph, and so on...
<div> and <span> are simply ways of getting to pieces of your site you normally can't get to. Like when you're trying to resize a | symbol. Fastest way I've ever found was to put a span around it, give it a class and then implement the CSS.
That's what they're good for, in my opinion. I'd be interested to hear more or even corrections on what I've written here.
It sounds like you need to read the HTML specification
The p element:
The p element represents a paragraph.
The div element:
The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements.
The span element:
The span element doesn't mean anything on its own, but can be useful when used together with the global attributes, e.g. class, lang, or dir. It represents its children.
The major difference between div and span is that span is flow content, phrasing content, and palpable content, while a div is only flow content and palpable content.
Essentially this boils down to:
div elements are block-level elements, and typically may only be placed within other block-level elements, whereas span elements are inline elements, and may be placed within most other elements.
The HTML spec defines which elements are acceptable as descendents of each element.