An explaination of the <span> tag.

I know. Kill me. But I just don't get it

[volkes]

I'm sorry, I know that this is a topic that been addressed before. I really don't want to waste your guys time, and I know I'm stupid, but I just don't get the span tag.

A span is used to group elements so that they can be modified through CSS or accessed by Javascript. Unlike a div, which is block, a span is inline. This far I get.

But the problem for me is that I can't visualize what a span looks like. And maybe because I don't fully understand how inline elements work/flow. A div's easy. It's a box. Anything inside the div goes inside a box. A div clears the page. But a span?

Should I imagine a large rectangle that encompasses everything between the span tags of my code? Or a conglomeration of all element containers into a strange orthogonal form? Or, I dunno, a line?

And what's this about not being allowed to put block elements into a span? Why? I tried spanning over one a using display:none, and this seems to work. Did I do something wrong?

[volkes]

Oh, and if I'm too much a bother, maybe someone could point me to a good resource?

[Mark_A]

Don't think I have ever used a span.

Mind you I still use tables for layout when I do make pages! :-)

as for resources volkes

[google.co.uk...]

:-)

[topr8]

>>And what's this about not being allowed to put block elements into a span? Why? I tried spanning over one a using display:none, and this seems to work. Did I do something wrong?

often browsers will render markup even if it is incorrect, browser makers have to take into account the fact that a lot of web sites are coded badly/incorrectly, if they only displayed sites that validated correctly a large number of sites would not be viewable

[mattur]

<span> is just like <b> or <i> but without any default formatting, and you would generally use it in similar contexts.

[volkes]

Hi everybody, and thanks for your replies.

You know, I think I figured it out for myself. I can group inline elements with a span. I can group block elements with a div. A mixture of inline and block elements I can only group with a div. And this makes sense, because how would a browser choose to layout a group of inline and block elements interpreted as a mess of inline elements?

Tell me I am wrong?

[volkes]

No. I must be wrong. Because I know that over the css diplay property I can sometimes force a block element to display as an inline element. Hmmm...

[volkes]

I guess then maybe spans are just there for being able to group inline elements without ruining their natural flow by putting them in a box.

Whatever. It's not really important. Not using spans right now anyway.

[topr8]

in my view, the span tag is generally misused,

in most cases you can style a specific tag to do what the span tag does and often it makes more sense symantically to do so

[please note, i said in MOST cases]

[penders]

A span is used to group elements so that they can be modified through CSS or accessed by Javascript. Unlike a div, which is block, a span is inline. This far I get.

That's it, it's just an inline container.

<p>You have <span id="charstogo">500</span> characters remaining.</p>

You then have some JavaScript that counts the number of chars entered in your TEXTAREA box , deducts this from 500 and displays the result in your SPAN. What element would you use in this case? What would you consider more appropriate?

[kaled]

The commonest usage is to apply a style or a class...

<span class="red">Some red text here (assuming red class is defined)</span>
<span style="font-size:36px">Some big text here</span>

As a general rule, span & style should only be used together as part of some common code, e.g. in a navigation area. They should not be used together elsewhere to achieve one-off effects.

Kaled.

[alt131]

You know, I think I figured it out for myself.

No. I must be wrong. Because I know that over the css diplay property I can sometimes force a block element to display as an inline element. Hmmm...

Loathe to interrupt a good conversation ... ;), but separate structure (HTML) from presentation (css). For example visibility:hidden "presents" html elements as invisible - but they still exist in the document.

I think the start of your question is what role does a span play in the structure of a document.

The HTML4.01 index to elements [w3.org] describes it as a "generic language/style container". 7.5.4 [w3.org] explains: "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 to tailor HTML to their own needs and tastes."

So, p = para, and li = list item: They provide semantic meaning to the content they "mark-up". But a span is just a "container" that adds no other meaning.

Should I imagine a large rectangle that encompasses everything between the span tags of my code? Or a conglomeration of all element containers into a strange orthogonal form? Or, I dunno, a line?

Easiest to imagine a rectangle (box) that flows along the "lines" of text.

Another name for inline elements is "text-level" elements. Oversimplifying, each element generates a box. Each box has a containing block. Inline elements distribute their content in lines - inline elements generate inline boxes. So this was consistent with the recommendations:

I guess then maybe spans are just there for being able to group inline elements without ruining their natural flow by putting them in a box.

But understanding inline elements can be really helpful, even if not using spans. Chapter 9 and 10 of css 2.1 have lots more detail. I think 9.4.2 [w3.org] best addresses the first question you asked, but also see the explanations about width and height calculations.

[rocknbil]

Right, alt131 hit it I think - the key word is generic.

These all have meanings that provide context to devices reading documents.

<h1>
<strong>
<b>
<p>
<ul>
<li>
<label> (forms, grossly abused)

They tell the reader what the content is, and the reader can decide importance based on the markup.

But what if you need to style something and don't want to give it meaning? You have two generic elements with which to do this: <div> for block, <span> for inline.

[penders]

Just another example that might help search engines, screen readers etc. and which may or may not be styled...

<p><span lang="fr">Bonjour</span>, welcome to my website!</p>

[MichaelBluejay]

My take is that <span> just gives you a hook in order to style your text. Instead of:

The <font color="red>rain</font> in <font size="+1">Spain</font> falls mainly on the <font face="Arial" size="+2" color="green">plain</font>.

you can now do:

The <span class="red">rain</span> in <span class="big">Spain</span> falls mainly on the <span class="lastword">plain</span>.

I don't think of it as a way to "group" elements like you said, I just think of it as a hook for me to be able to apply styles.

I've also used it to tag content that I'm going to change with JavaScript, as penders noted.

[piatkow]

I have used span once. To consistenly give a particular type of comment a distinctive colour and point size throughout a site. It isn't something that I have found a lot of use for.

[Fotiman]

@MichealBluejay, it's important to note that using class names like "red" and "big" are generally not advisable because you're including very presentation specific information in your content. So if you want to change the presentation, you'd need to go in and modify your content layer (ie - HTML markup), vs. only having to modify the presentation layer (ie - the CSS file). Instead, use class names that describe the content vs. class names that describe the presentation. To put it in perspective, an <ul> element indicates that an element is an unordered list, but does not specify any presentational queues... it describes the content vs. the behavior. So likewise, you might use class names like:

The <span class="weather">rain</span> in <span class="country">Spain</span> falls mainly on the <span class="terrain">plain</span>.

Now I could make presentational changes (making something red, big, or green) simply by editing only the CSS.

Just my 2 cents.

[Fotiman]

But the problem for me is that I can't visualize what a span looks like. And maybe because I don't fully understand how inline elements work/flow. A div's easy. It's a box. Anything inside the div goes inside a box. A div clears the page. But a span?

Should I imagine a large rectangle that encompasses everything between the span tags of my code? Or a conglomeration of all element containers into a strange orthogonal form? Or, I dunno, a line?

Think of it like this... imagine that you have some piece of content that is special, but for which no semantic markup elements exist. Lets say you have a website that sells widgets, and part of your content looks like this:

<div>
  The Foo Widget can hold 5 Bar Widgets.
</div>

Now, lets say that you want to apply some special styling to each widget name, and also to the number of widgets that it can hold. So you might do this:

<div>
  The <span class="widget">Foo Widget</span> can hold 
  <span class="widgetChildren">5</span> <span class="widget">Bar Widgets</widget>.
</div>

A span's dimensions, because they are inline, do not force any line breaks. It's not really helpful to imagine it as a large rectangle because you might have content that runs across 2 lines. For example, perhaps the example above ends up rendering like this:

The Foo Widget can hold 5 Bar 
Widgets.

In other words, it has wrapped to the next line, so it's no longer a rectangular area. Imagine it like this... in your web browser you can click and drag your mouse pointer to "select" (and highlight) certain text... it's possible to select text that spans multiple lines and the highlight does not necessarily look like a rectangle.

And what's this about not being allowed to put block elements into a span? Why? I tried spanning over one a using display:none, and this seems to work. Did I do something wrong?

I think alt131 already covered this pretty well. But how elements are presented (using CSS) is different from how they exist in the content (your markup). Imagine if you page was served to someone that had CSS disabled. If you do something like this:

<span>This contains a <div>block</div> element</span>

That user is going to see:

This contains a
block
element

And if you had given that div element a style that set display: inline, then your other users would see:

This contains a block element

div elements are generic "block" elements (so you should not use them if you expect that content to be displayed inline), and span elements are generic "inline" elements (so likewise, don't use them if you expect that content to be displayed as a block).

[MichaelBluejay]

I disagree that using class names that describe the physical style isn't advisable. I think it's a matter of personal preference. For example, sometimes I need to bump up the size within my content, for various reasons. The tagged content doesn't necessarily belong to any semantic "group", it's just something I want to bump up somewhere. I can handle all such cases with one class, class=bigger. The alternative might force me to think about each and every instance in which something could get bigger and give it a semantic name, and then remember that name when applying it. Ugh. I prefer to just use "class=bigger" and be done with it.

[buckworks]

A name like "class=red" could end up really strange if you ever decided to make those items blue.

[tedster]

I prefer to just use "class=bigger" and be done with it.

A name like "class=red" could end up really strange if you ever decided to make those items blue

This particular point-counterpoint sometimes sometimes takes on the same quality as the "divs versus tables" discussion. I've been involved in it several times, and I think there's some truth on both sides - depending on the project. A big site with a big web team often needs different standards if they're going to collaborate in a practical way.

The projected longevity of the website also enters into the picture. The "CSS Zen Garden" ideal, while inspiring, is not something that I see in practice. People don't just create a new set of stylesheets when they do redesigns. So the ideal of not naming classes by their physical properties often has no tangible payoff.

[kaled]

A name like "class=red" could end up really strange if you ever decided to make those items blue

That depends on where it's used. For instance, in the shared area of a template, it's not a big issue. Also, search and replace (if available for a whole site) can often be used to deal with changes of this sort quickly and easily unless the site is huge. Of course, a whole-site backup is advisable before making such changes.

One trick I use is to style <i> so that it changes the font from Sans Serif to italic Serif, except for code examples, where <i> is styled to leave the font unchanged but highlight it in red. No doubt, some people would be horrified by this but a serif font often looks better in italics and code examples can look messy with italics.

Kaled.

[alt131]

Nice explanation Fotiman - just a reminder that there is an image at the bottom of section 9.4.2 (link posted in my first post) that shows what inline elements "look like" when they flow onto a new line.

I think helpful to distinguish how spans have been used from what they were intended to be used for.

I remind myself that inline elements are "text-level" - so their content is frequently "only" text, not other elements. The computer/scholarly origins of HTML are reflected in the types of text-level elements that have semantic and stylistic meaning: CODE, SAMP, KBD, VAR , CITE, Q, DFN, ABBR, ACRONYM, sub, sup, address, ins, del.
Which leaves designers with EM, STRONG, i, b, big, small, pre, tt.
(... not much to celebrate.)

So spans (introduced html4) were intended to provide more options for moving presentation out of the structure. They lost ground to the demand for css-p, plus were used as direct replacements for <font> and such, and as work-arounds for elements and attributes that had poor browser support. I believe they were also victims of slow recognition of the relevance of code semantics and accessibility. Hence the "div-itis" and "class-itis" which HTML5 tries to address.

What is exciting is re-visiting existing elements and utilising improved support to drive better usability and semantic meaning. So:

<p><span lang="fr">Bonjour</span>, welcome to my website!</p>

Becomes

<p><i lang="fr">Bonjour</i>, welcome to my website!</p>
Or perhaps better
<p><em lang="fr">Bonjour</em>, welcome to my website!</p>

As words from other languages are usually italicised if not fully assimilated, and <em> conveys a changed meaning for non-visual users as well.

And this has endless possibilities depending on context and whether meaning is required for non-visual users:

The <span class="red">rain</span> in <span class="big">Spain</span> falls mainly on the <span class="lastword">plain</span>.

If there is no need to convey meaning to non-visual users, then why not:

p :first-child {color:red}
p :last-child {color:fuchsia;text-decoration: overline}
<p>The <span>rain</span> in <big>Spain</big> falls mainly on the <span>plain</span>.</p>

Or if this is a sentence, not a para, then:

span :first-child {color:red;}
span :last-child {color:fuchsia;text-decoration: overline}
<span>The <span>rain</span> in <big>Spain</big> falls mainly on the <span>plain</span>.</span>

An example of span as a "container". Give it an id and it becomes a target as well. All without imposing any change of meaning, especially if that creates unneeded "clutter" for non-visual users. And conserves code kb's for those of us who still care.

Purists will complain about <big>, especially as it is dropped from html5. I agree - but this was too tempting ;) Also that better to use i/b/em/strong given they are italicised/bold by convention only, plus their rendering has changed in HTML5. Again I agree. Exciting times

<rant>
Plus no need to worry about what classes should be called -
which is an issue created by using so many there has to be a body of thought dedicated to naming the things ... rather than using HTML to give stucture and meaning, css to apply style. As was intended.
</end rant>

Good question volkes - I hope you've got something useful out of it

[rocknbil]

The <span class="weather">rain</span> in <span class="country">Spain</span> falls mainly on the <span class="terrain">plain</span>.

<p><span lang="fr">Bonjour</span>, welcome to my website!</p>

Since this discussion has taken this turn, with the above cited examples as presented, isn't this what XHTML is for? Combined with a custom DDT,

The <weather>rain</weather> in <country>Spain</country> falls mainly on the <terrain>plain</terrain>.

<p><french>Bonjour</french>, welcome to my website!</p>

It's this line of thinking that leads me to believe <div> and <span> are generic elements with no semantic purpose, used when no semantic element applies.

[Fotiman]

isn't this what XHTML is for?

For the second example, I would say definitely no. (the lang attribute has special meaning to browsers). For the first example, I would say XHTML *could* be used, but is not necessarily "what XHTML is for". One could argue that this is what Microformats are for as well.

But your last line is correct... div and span are generic elements with no semantic purpose, used when no semantic element applies. We can give them pseudo semantic value by using class names that describe the content, but it's not truly semantic (a machine won't know the semantics of what a class is supposed to represent). It's more for the developer.

The problem with XHTML is, of course, the lack of support from a certain browser majority market share holder.

[alt131]

isn't this what XHTML is for

Exactly my thoughts - if you want to invent your own names for elements then xml.

We can give them pseudo semantic value by using class names that describe the content,

Fotiman, I don't agree. Class names are for the css. css is for style - not structure, and therefore not document semantics.

This question made me re-think spans in their role as a generic container (which rocknbil keeps reinforcing), given improved selector support. What I've found interesting is the number of posts about naming conventions - not how using them as a container may help minimise the number of class names required.

[penders]

We can give them pseudo semantic value by using class names that describe the content,

Fotiman, I don't agree. Class names are for the css. css is for style - not structure, and therefore not document semantics.

I would have to agree with Fotiman. An example of this is Microformats (Microformats - Get Started [microformats.org]), which Fotiman mentions. Microformats often use the CLASS attribute to label information in the page in a semantic sort of way. Other tools eg. browser plugins etc. are able to pluck out this information. Google now supports several Microformats.

[Fotiman]

Right, there is nothing that limits class names to CSS only. They are often used in JavaScript as well for identifying certain items (in fact, HTML5 adds the JS API document.getElementsByClassName). And as penders mentions, there are tools that are able to use this information to infer semantic meanings.

[rocknbil]

Right, I knew I was going to get zinged for the lang attribute. :-) carry on . . .

[alt131]

I think this is comparing apples and oranges: The roles of html and css are clearly defined in the recommendations, and a class does not change the meaning of an element in the structure of an HTML document. That is the premise of the separation of style from structure, as well as the basis of coding for semantics.

Classing an element, accessing it by some means (like javascript) or using it to give it some meaning for some other purpose (like microformats) does not change the fundamental nature of the element within the structure of the HTML document.

Microformats/javascript may use a particular attribute to identify particular elements to use them for a particular purpose, but programming other "tools" to recognise a particular thing and treat it as having meaning within the context of their particular purpose does not change the meaning of the element in the context of the structure of the HTML document.

So I didn't state classes could only be used by style sheets. What attributes can be used for/by in other contexts is different issue than the one being discussed: The effect of a class in the context of the respective roles or HTML and css.

But now I'm trying to figure the reasoning behind the idea that using an elements attribute changes the meaning of the element itself.