I've read many explanations of what the actual purpose of the < span > tag is, and I've tried to incorperate those explanations into real applications but have failed every time.
One person told me that it was to apply classes to sub-tags below it, which does kind of work, except it doesn't apply dimensions to elements, unless you mess around with the display and/or inline settings, which can totally screw up a layout.
Then someone else told me that it's use as a substitute for the < div > tag, which doesn't work because floats or "margin: auto"-type attributes don't work unless contained inside certain types of elements.
Then someone else told me that it's used as a text container, which doesn't work because the "text-align" attribute doesn't work, again, unless contained inside certain types of elements. A default-attribute-cleared < p > tag is much more suited, in my experience.
So what exactly is the point of them? Why are so many people using them when < div > seems to do everything that they're apparently capable of and more?
From Official Docs:
The DIV and SPAN elements, in conjunction with the id and class
attributes, offer a generic mechanism for adding structure to
documents. These elements define content to be inline (SPAN) or
block-level (DIV) but impose no other presentational idioms on the
content. Thus, authors may use these elements in conjunction with
style sheets, the lang attribute, etc., to tailor HTML to their own
needs and tastes.
As it says, you can use <span> tag to structure (inline) the sections of page along with styling which you may optionally pass via id, class or stylesheets.
Characteristics of <span> tag:
It's display is inline by default which means:
you can not apply width to it
you can not apply height to it
you can make it block-level too by using display:block (div serves the same purpose)
The <div> tag is opposite to that and you can apply above rules to it.
It is an inline element with no attached semantics that can be used to wrap some inline content for
the application of JavaScript (e.g. event handlers or moving about the DOM)
the application of CSS
use with the lang attribute
processing by custom tools
… when no element with more appropriate semantics exists.
floats or "margin: auto"-type attributes don't work unless contained inside certain types of elements.
They work (or otherwise) based mostly on the display value, not the element type.
Why are so many people using them when <div> seems to do everything that they're apparently capable of and more?
A div is identical to a span except it:
Can contain block elements
Cannot (error recovery not withstanding) be contained by an inline element (or any other element that can contain only inline content, such as a <p>)
Is display: block by default (instead of inline)
When the text is in a <span> element you can add styles to the content, or manipulate the content.
Related
I know it's wrong to put a block element inside an inline element, but what about the following?
Imagine this valid markup:
<div><p>This is a paragraph</p></div>
Now add this CSS:
div {
display:inline;
}
This creates a situation where an inline element contains a block element (The div becomes inline and the p is block by default)
Are the page elements still valid?
How and when do we judge if the HTML is valid - before or after the CSS rules are applied?
UPDATE: I've since learned that in HTML5 it is perfectly valid to put block level elements inside link tags eg:
<a href="#">
<h1>Heading</h1>
<p>Paragraph.</p>
</a>
This is actually really useful if you want a large block of HTML to be a link.
From the CSS 2.1 Spec:
When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box (and any block-level siblings that are consecutive or separated only by collapsible whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box(es). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, any resulting translation also affects the block-level box contained in the inline box.
This model would apply in the following example if the following rules:
p { display: inline }
span { display: block }
were used with this HTML document:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HEAD>
<TITLE>Anonymous text interrupted by a block</TITLE>
</HEAD>
<BODY>
<P>
This is anonymous text before the SPAN.
<SPAN>This is the content of SPAN.</SPAN>
This is anonymous text after the SPAN.
</P>
</BODY>
The P element contains a chunk (C1) of anonymous text followed by a block-level element followed by another chunk (C2) of anonymous text. The resulting boxes would be a block box representing the BODY, containing an anonymous block box around C1, the SPAN block box, and another anonymous block box around C2.
The properties of anonymous boxes are inherited from the enclosing non-anonymous box (e.g., in the example just below the subsection heading "Anonymous block boxes", the one for DIV). Non-inherited properties have their initial value. For example, the font of the anonymous box is inherited from the DIV, but the margins will be 0.
Properties set on elements that cause anonymous block boxes to be generated still apply to the boxes and content of that element. For example, if a border had been set on the P element in the above example, the border would be drawn around C1 (open at the end of the line) and C2 (open at the start of the line).
Some user agents have implemented borders on inlines containing blocks in other ways, e.g., by wrapping such nested blocks inside "anonymous line boxes" and thus drawing inline borders around such boxes. As CSS1 and CSS2 did not define this behavior, CSS1-only and CSS2-only user agents may implement this alternative model and still claim conformance to this part of CSS 2.1. This does not apply to UAs developed after this specification was released.
Make of that what you will. Clearly the behaviour is specified in CSS, although whether it covers all cases, or is implemented consistently across today's browsers is unclear.
Regardless if it's valid or not, the element structure is wrong. The reason that you don't put block elements inside inline elements is so that the browser can render the elements in an easily predictable way.
Even if it doesn't break any rules for either HTML or CSS, still it creates elements that can't be rendered as intended. The browser has to handle the elements just as if the HTML code was invalid.
The HTML and the CSS will both still be valid. Ideally, you wouldn't have to do something like this, but that particular bit of CSS is actually a handy (and syntactically valid but not semantically valid) way for getting Internet Explorer's double margin bug without resorting to conditional stylesheets or hacks that will invalidate your CSS. The (X)HTML has more semantic value than the CSS, so it's less important that the CSS is semantically valid. In my mind, it's acceptable because it solves an annoying browser issue without invalidating your code.
The HTML is validated independently of the CSS, so the page would still be valid. I'm fairly sure that the CSS spec says nothing about it either, but don't quote me on that one. However, I'd be very careful using a technique like this, as while it might render as intended in some browsers, you'd need to test 'em all—I don't see many guarantees being made.
Are the page elements still valid?
“Valid” in an HTML sense, yes; HTML knows nothing about CSS.
The rendering you get in the browser, however, is ‘undefined’ by the CSS specification, so it could look like anything at all. Whilst you could include such a rule in CSS hacks aimed at one particular browser (where you know how that browser renders this case), it shouldn't be served to browsers in general.
I don't know off the top of my head if this validates any rules but I would recommend using the W3C HTML Validator and the W3C CSS Validator to determine that. Hope this is helpful!
If there is a logic you follow and you end up implementing it like this, it's NOT WRONG. Working things are not "wrong" just because they're weird. Yes, it's quite unusual but it HELPS and it's not a mistake. It's intentional. HTML and CSS should serve you, not the other way around so don't ever listen to comments telling you not to do it just because it's ugly.
It's typical to call a solution "invalid" and suggest a long way around the block. Sometimes you can rethink what you did. But there can be many reasons for what you did and they don't consider them.
I do use blocks inside inlines regularly. It's valid and it's working - it's just not necessary in most cases. So what. Remember when XHTML told us to always put quotes around properties (and everyone yelled at you if you didn't!), now HTML5 allows to omit them if there's no space inside. What happened to that last slash after singular tags? "<br />" ? Come on. Standards change. But browsers keep supporting non-standard things as well. CENTER is deprecated; we're in 2013 and it still works. TABLE for vertical centering? Sometimes it's the only way. DIV inside A to make it hover as you planned? Just go ahead.
Focus on important things.
I think, (x)html is valid, css is valid. Is the result valid? Yes, if it is looking in the browser as You want.
No, It is not a wrong choice. We can use as per requirements.
I am making a website with personal articles. The body of my articles is a basic div containing paragraphs, but recently I found it useful to use some span's out of the paragraphs to manage my content as desired, hence in the div's.
As the web semantic becomes an important role and becomes more and more well constrained, I was curious of the downsides of such a practice.
I am not too familiar with the standards of HTML yet. However, I was thinking using span's in div's is semantically not clean.
Is the Googlebot going to soil the referencing on that?
There is nothing wrong with using a span element inside of a div element. It is absolutely valid. It will have no negative impact on search engine optimization.
div elements are block elements and span elements are inline elements. Inline elements can be placed inside of block elements. The opposite is what you want to avoid: Do not put div elements inside span elements.
It’s fine if no other text-level element is appropriate in your case.
You can check their purposes in the usage summary: Does it represent a hyperlink, stress emphasis, importance, a side comment, …? If the answer is no to all candidates, go with "Other", i.e., the span element.
div and span elements don’t represent anything, they are meaningless elements to be used in cases where no other element is appropriate. So adding/removing div/span elements would never change the semantics of the document (unless meaningful attributes, like lang, were used).
It is not valid to nest a block level element such as p directly inside an inline element such as b.
However, using css such as display: inline-block or position: absolute is can be conceptually sound to have block level content inside an inline context.
Browsers largely accept such block level elements in an inline element, but under some circumstances, the invalid construct causes real problems:
<p><span><p></p></span></p>
The above example would not be parsed as three nested elements; the innermost <p> would instead implicitly close the outer <p>, regardless of CSS. You can see a jsbin demo of that.
Is there some way of using intermediate elements to validly place block level elements in an inline element?
If that's not possible, is there an invalid but functional workaround for the majority of cases (preferably also for the tricky <p> tag)?
To be clear, I'm looking for a generic solution that doesn't require invasive changes to document structure (i.e. "just use span everywhere, for everything" is not an attractive solution). I want to embed an unknown (dynamically generated) document fragment with potentially block-level content - so fixing the fragment to exclude block level elements is infeasible.
Related: (address the validity of direct nesting mostly)
Is it wrong to change a block element to inline with CSS if it contains another block element?
Block Level Elements inside Inline elements
Are block-level elements allowed inside inline-level elements in HTML5?
The W3C validator (in XHTML mode) lists the following elements as valid between a <span> and a <p>:
object
ins
del
map
button
A page using these as inline-to-block spanners validates in XHTML Strict, but not in HTML 5. Of these tags, I would favor object, since it has the least semantic baggage.
HTML 5 seems to have discarded the inline vs. block distinction in favor of a more complex system, in which there are several different categories of element, and which children an element can have depends on what its ancestors are. Of these elements, ins, del and map now accept the same kind of children that their parent element accepts, and button only accepts "phrasing content" (the closest thing to inline elements). The error message for object doesn't make much sense, but as near as I can gather, it's inheriting the parent element's restrictions while also imposing some restrictions of its own.
As near as I can tell, there's no way to escape from phrasing content once you're in it (short of an iframe and a new document), so the answer to this question is no, can't be done in HTML5 (as of this writing).
Semantically is wrong and I think HTML5 allows block elements inside < a > tags only (as far as I know).
In other words, you can make your html code work as you want by changing the css, but that doesn't mean your html code is correct. You also should consider SEO and Accessibility issues that will arise.
I know it's wrong to put a block element inside an inline element, but what about the following?
Imagine this valid markup:
<div><p>This is a paragraph</p></div>
Now add this CSS:
div {
display:inline;
}
This creates a situation where an inline element contains a block element (The div becomes inline and the p is block by default)
Are the page elements still valid?
How and when do we judge if the HTML is valid - before or after the CSS rules are applied?
UPDATE: I've since learned that in HTML5 it is perfectly valid to put block level elements inside link tags eg:
<a href="#">
<h1>Heading</h1>
<p>Paragraph.</p>
</a>
This is actually really useful if you want a large block of HTML to be a link.
From the CSS 2.1 Spec:
When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box (and any block-level siblings that are consecutive or separated only by collapsible whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box(es). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, any resulting translation also affects the block-level box contained in the inline box.
This model would apply in the following example if the following rules:
p { display: inline }
span { display: block }
were used with this HTML document:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HEAD>
<TITLE>Anonymous text interrupted by a block</TITLE>
</HEAD>
<BODY>
<P>
This is anonymous text before the SPAN.
<SPAN>This is the content of SPAN.</SPAN>
This is anonymous text after the SPAN.
</P>
</BODY>
The P element contains a chunk (C1) of anonymous text followed by a block-level element followed by another chunk (C2) of anonymous text. The resulting boxes would be a block box representing the BODY, containing an anonymous block box around C1, the SPAN block box, and another anonymous block box around C2.
The properties of anonymous boxes are inherited from the enclosing non-anonymous box (e.g., in the example just below the subsection heading "Anonymous block boxes", the one for DIV). Non-inherited properties have their initial value. For example, the font of the anonymous box is inherited from the DIV, but the margins will be 0.
Properties set on elements that cause anonymous block boxes to be generated still apply to the boxes and content of that element. For example, if a border had been set on the P element in the above example, the border would be drawn around C1 (open at the end of the line) and C2 (open at the start of the line).
Some user agents have implemented borders on inlines containing blocks in other ways, e.g., by wrapping such nested blocks inside "anonymous line boxes" and thus drawing inline borders around such boxes. As CSS1 and CSS2 did not define this behavior, CSS1-only and CSS2-only user agents may implement this alternative model and still claim conformance to this part of CSS 2.1. This does not apply to UAs developed after this specification was released.
Make of that what you will. Clearly the behaviour is specified in CSS, although whether it covers all cases, or is implemented consistently across today's browsers is unclear.
Regardless if it's valid or not, the element structure is wrong. The reason that you don't put block elements inside inline elements is so that the browser can render the elements in an easily predictable way.
Even if it doesn't break any rules for either HTML or CSS, still it creates elements that can't be rendered as intended. The browser has to handle the elements just as if the HTML code was invalid.
The HTML and the CSS will both still be valid. Ideally, you wouldn't have to do something like this, but that particular bit of CSS is actually a handy (and syntactically valid but not semantically valid) way for getting Internet Explorer's double margin bug without resorting to conditional stylesheets or hacks that will invalidate your CSS. The (X)HTML has more semantic value than the CSS, so it's less important that the CSS is semantically valid. In my mind, it's acceptable because it solves an annoying browser issue without invalidating your code.
The HTML is validated independently of the CSS, so the page would still be valid. I'm fairly sure that the CSS spec says nothing about it either, but don't quote me on that one. However, I'd be very careful using a technique like this, as while it might render as intended in some browsers, you'd need to test 'em all—I don't see many guarantees being made.
Are the page elements still valid?
“Valid” in an HTML sense, yes; HTML knows nothing about CSS.
The rendering you get in the browser, however, is ‘undefined’ by the CSS specification, so it could look like anything at all. Whilst you could include such a rule in CSS hacks aimed at one particular browser (where you know how that browser renders this case), it shouldn't be served to browsers in general.
I don't know off the top of my head if this validates any rules but I would recommend using the W3C HTML Validator and the W3C CSS Validator to determine that. Hope this is helpful!
If there is a logic you follow and you end up implementing it like this, it's NOT WRONG. Working things are not "wrong" just because they're weird. Yes, it's quite unusual but it HELPS and it's not a mistake. It's intentional. HTML and CSS should serve you, not the other way around so don't ever listen to comments telling you not to do it just because it's ugly.
It's typical to call a solution "invalid" and suggest a long way around the block. Sometimes you can rethink what you did. But there can be many reasons for what you did and they don't consider them.
I do use blocks inside inlines regularly. It's valid and it's working - it's just not necessary in most cases. So what. Remember when XHTML told us to always put quotes around properties (and everyone yelled at you if you didn't!), now HTML5 allows to omit them if there's no space inside. What happened to that last slash after singular tags? "<br />" ? Come on. Standards change. But browsers keep supporting non-standard things as well. CENTER is deprecated; we're in 2013 and it still works. TABLE for vertical centering? Sometimes it's the only way. DIV inside A to make it hover as you planned? Just go ahead.
Focus on important things.
I think, (x)html is valid, css is valid. Is the result valid? Yes, if it is looking in the browser as You want.
No, It is not a wrong choice. We can use as per requirements.
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.