Summary

More and more web documents are appearing that consist of nothing more than a collection of div elements. In most cases, better use of CSS selectors could be used to avoid overusing the div element.

Author: Gez Lemon

Contents

Translations

Brazilian Portuguese Translation
The Brazilian Portuguese translation of this article is kindly provided by Mauricio Samy Silva.
German Translation
The German translation of this article is kindly provided by Eric Eggert.
Spanish Translation
The Spanish translation of this article is kindly provided by Alma Fernandez.

[Back to the contents]

What is Div Mania?

The div and span elements were introduced into HTML 4 to provide a generic mechanism for grouping, and adding structure to documents. The div element is a block-level container, and span is an inline element. An id and/or class attribute is usually used with the div and span to provide a hook for styling with CSS or scripting. Div mania is where content developers have replaced table-based layouts for CSS layouts, but have misused the div element to such an extent that they've more or less defined their own markup language consisting almost entirely of nested div elements. The div element is semantically neutral: it doesn't have any meaning other than the fact it is a container element. The div element should be used where no existing element is suitable as a container, not as a replacement for existing elements that have recognised and accepted meaning, such as headings, paragraphs, lists, etc. A typical div mania document may look similar to the following. 

<div id="wrapper">
    <div id="container">
        <div id="navigation">
            <div id="navhead">
            ...
            </div>
            <div id="navcontent">
            ...
            </div>
        </div>
        <div id="content">
            <div class="panel">
            ...
            </div>
            <div class="panel">
            ...
            </div>
        </div>
    </div>
</div>

Developers who fall into the div mania trap are often blissfully unaware. Run a div mania document through an automated markup validator, and providing the document is structurally correct, the validator will confirm that the document is valid (X)HTML, as validators are unable to determine whether or not the most appropriate element has been chosen. There are many factors that contribute to div mania, including a lack of understanding of markup elements (beware deprecated elements), the CSS box model, inheritance and cascade, and choosing appropriate selectors. Talking with developers who have a reasonable grasp of CSS in order to create a div mania document, it seems that the greatest contributory factor is a poor understanding of selectors. The rest of this document provides an overview of CSS 2.1 selectors.

[Back to the contents]

Rule Set

A CSS document is made up of a collection of rules, whereby a rule consists of a selector followed by a declaration block. As there is likely to be more than one rule, a collection of rules is often referred to as a rule-set. The selector determines the elements in the document tree that the rule is to be applied to. If the selector is invalid, user agents ignore everything in the declaration block. The declaration block is a semicolon-separated list of zero or more declarations, contained within curly braces. An individual declaration may either be empty, or a property/value pair, where the property and the value are separated by a colon. Consider the following CSS rule: 

h1
{
   padding-top: 1em;
   border-bottom: 1px solid #ccc;
}

In the rule above, the selector is h1, and the declaration block is everything inside, and including, the curly braces. The declaration block consists of two declarations, separated by semicolons. As the semicolon is only required for separating declarations, the final semicolon isn't required, but is legal. The first declaration specifies a property of padding-top, and has been provided a value of 1em. See Appendix F of the specification for a list of all properties that may be used with CSS 2.1.

[Back to the contents]

Selector Specificity

To understand how selectors are applied to elements requires a basic understanding of inheritance and cascade. Inheritance is where an element inherits properties from its ancestors. For example, setting a font-size in the navigation would be inherited by elements within the navigation, such as paragraphs and list items. Not all properties are inherited by their descendants, but most are. In cases where properties are not inherited, the inherit property value can be used to force inheritance. 

*.warning
{
    color: inherit;
}

Cascade is where an element has multiple rules defined, and specificity is used to determine which definitions are to be applied. Order is important: when two selectors have the same specificity, the one defined last is applied.

[Back to the contents]

CSS Selectors

Selectors are pattern matching rules that determine which elements in the document tree the style rules will be applied to. In the example above, the selector pattern is the h1 element. More complex patterns can be used to be more specific about which elements are to be the subject of the selector, based on the element's position in the document tree.

[Back to the contents]

The Universal Selector

The universal selector is denoted with an asterisk, '*', and matches all elements in the document tree. The following example would apply a pale yellow background to all elements that supported the background-color property unless a more specific selector was used. For all other definitions, I won't mention specificity again, but it's important to remember that the rules will only be applied in the following examples if a more specific selector hasn't been defined. 

*
{
    background-color: #ffc;
}

The following example could be applied to all elements that have a class name of attention. 

*.attention
{
    background-color: #ffc;
}

When the asterisk is part of a pattern, as in the above example, the asterisk can safely be omitted. A pattern of .attention would be equally as effective as *.attention.

[Back to the contents]

The Type Selector

The type selector matches every instance of a particular element in the document tree. The following example would apply a pale yellow background to all p elements in the document tree. 

p
{
    background-color: #ffc;
}

[Back to the contents]

Grouping Selectors

When several selectors are to share the same declaration block, the selector can be grouped by separating each selector with a comma. The following example would apply a pale yellow background to all strong, and em elements. 

strong, em
{
    background-color: #ffc;
}

[Back to the contents]

The Class Selector

The class selector can be used as an alternative to the attribute selector. The class selector is denoted with a full-stop, '.', and is applied to all matching elements in the document tree with that class. The following example would apply a pale yellow background to all list items with a class of attention. 

li.attention
{
    background-color: #ffc;
}

If the class is to be applied to a number of elements, they can either be specified individually by grouping the selectors, or using the universal selector (*.className or .className)

[Back to the contents]

The ID Selector

The id attribute must be unique within a web document, so may only be applied to a single instance of an element in the document tree. The CSS ID selector to match the id is denoted with a hash, '#'. The following example would apply a pale yellow background to the level-2 heading that had a unique id of offers. 

h2#offers
{
    background-color: #ffc;
}

As an id must be unique, it is safe to use the universal selector with the id selector (*#idName or #idName). For readability and maintainability, it's generally a good idea to keep the element name in place.

[Back to the contents]

Descendant Selectors

The document tree is arranged such that each element in the tree has exactly one parent, except the root element. The descendant selector is used to match all elements that are descended from a parent. Descendant selectors are made up of space separated selectors, where each subsequent selector must be contained somewhere in the previous selector. The following example would apply a pale yellow background to any strong element contained anywhere in a paragraph. 

p strong
{
    background-color: #ffc;
}

[Back to the contents]

Child Selectors

A child selector is used to match a child of an element. Child selectors are denoted by the right-angled bracket, '>', with the parent on the left and the child on the right. The following example would apply a pale yellow background to all strong elements that are a child of p. 

p>strong
{
    background-color: #ffc;
}

The difference between the descendant selector and the child selector, is that the descendant selector matches strong wherever it occurs within a paragraph, whereas the child selector is more specific, and only matches strong elements that are a child of p. Consider the following example. 

<p>
Jon said, 
<q>
That'll be good when it's <strong>finished</strong>.
</q>
If only he <strong>knew</strong>!
</p>

The descendant selector above would match both strong elements, whereas the child selector would only match the final strong element, as the first strong element is not a child of p; it is a child of q.

Unfortunately, child selectors are not supported in Internet Explorer 6.

[Back to the contents]

Adjacent Sibling Selectors

Sibling elements are elements that share the same parent. Adjacent siblings are siblings that are immediately next to each other that share the same parent. Adjacent sibling selectors are denoted with a plus sign, '+'. The following example would apply a pale yellow background to all h2 elements that immediately follow a h1 element that share the same parent. 

h1+h2
{
    background-color: #ffc;
}

Unfortunately, adjacent sibling selectors, like child selectors, are not supported by Internet Explorer 6.

[Back to the contents]

Attribute Selectors

Attribute selectors match elements that have attributes defined in the document tree. There are four types of attribute selectors, outlined below.

[att]

The basic attribute selector matches elements that have the specified attribute, regardless of the value provided. The following example would apply a pale yellow background to all anchor elements that have been assigned a title attribute. 

a[title]
{
    background-color: #ffc;
}

[att=val]

This attribute selector is used to match elements that contain a specific attribute with a particular value. The following example would apply a pale yellow background to all anchor elements that contain a rel attribute with a value of external. 

a[rel=external]
{
    background-color: #ffc;
}

[att~=val]

Some attributes allow a space separated list of values to be assigned. Specifying a tilde before the equal sign allows a match to be made where one of the values provided is an exact match. The following example would apply a pale yellow background to all paragraphs with a class name of attention. 

p[class~=attention]
{
    background-color: #ffc;
}

p[class~=attention] is the equivalent of p.attention.

[att|=val]

This attribute selector is used to select attributes whose value contains a hyphen-separated list. This selector was primarily intended for use with language codes. The match starts at the beginning of the attribute value. The following example would match anchors with a hreflang attribute value staring with "en", including en, en-US, en-GB, en-cockney, or any other en-combination. 

a[hreflang|=en]
{
    background-color: #ffc;
}

Several attribute selectors may be specified at the same time. The following example uses two attribute selectors that would apply a pale yellow background to all anchors that contained a title attribute, and a rel attribute value of external. 

a[title][rel~=external]
{
    background-color: #ffc;
}

CSS 3 has some really cool attribute selectors, including a selector to test for a match at the beginning of the attribute value E[foo^="bar"], a selector to test for a match at the end of the attribute value E[foo$="bar"], and a selector to test for a substring E[foo*="bar"]. Mozilla/Firefox and Opera support attribute selectors, and Mozilla/Firefox also supports those in CSS 3. Needless to say, Internet Explorer doesn't support attribute selectors at all.

[Back to the contents]

Pseudo Selectors

Pseudo selectors are used in scenarios where an element's position in the document tree isn't sufficient as a selector, such as the first line of a paragraph. Pseudo elements and pseudo classes are used to apply formatting based on information outside of the document tree, and are prefixed with a colon, ':'. CSS 2.1 has four pseudo elements; :first-line, :first-letter, :before, and :after. The following example applies a font-size of 2em to the first character in a paragraph. 

p:first-letter
{
    font-size: 2em;
}

CSS 2.1 has a :first-child pseudo class, 2 link pseudo classes (:link, and :visited), three dynamic pseudo classes (:active, :hover, and :focus), and a lang pseudo class (:lang). The following example would apply a pale yellow background to all anchors that were the first child of any element. 

a:first-child
{
    color: #090;
}

The following example colours all visited links green. 

a:visited
{
    color: #090;
}

The following example would apply a pale yellow background to paragraphs with a lang attribute value of French. 

p:lang(fr)
{
    background-color: #ffc;
}

[Back to the contents]

Conclusion

A poor understanding of selectors isn't the only reason for div mania, but is largely responsible. The div element is useful for grouping and positioning content, but CSS can be applied directly to lists, and other more appropriate elements that have accepted meaning.

[Back to the contents]

Category: Style.

Comments

  1. [div-mania.php#comment1]

    A very interesting article. Thanks Gez

    Posted by Mike Abbott on

  2. [div-mania.php#comment2]

    Gez, that's a very well-written article.

    However, sometimes we are forced to use more DIVs than we'd like. If a sidebar menu consists of a single UL with links, no problems. But when the menu consists of several ULs with some H2s interspersed between them, you need to group things to be able to position them as a whole.

    Also, catering for buggy dinosaurs like IE5/Win may be the cause for excessive DIV use. Its broken box-model means that it's tricky to set a width plus a padding and/or border. An easier way is to enclose something in a DIV with a set width, and then apply border and/or padding to its children.

    Posted by Tommy Olsson on

  3. [div-mania.php#comment3]

    Thank you Mike and Tommy.

    I'm not suggesting that the div element should be abandoned. It has its use, and I use it in the exact circumstances you mention, Tommy (except catering for broken browsers; I'll go so far, but not all the way).

    I'm talking about circumstances where developers replace existing elements for a div. Last week, I was asked to review a website that as far as the company were concerned was valid XHTML, and conformed to WCAG 1.0 triple-A. It was a tough job as they didn't know me from Adam, and a markup validator and an accessibility validator backed up their assertions. Trying to explain the limitations of these tools was hard work, as they couldn't believe that anyone would make a tool so widely available that was so inadequate at its job. Just for the record, I think these tools are very good at their job, but obviously only useful to people who are able to interpret the results. Anyway, each page was littered with unnecessary div elements, including a menu that looked something like this: 

    <div id="menucontainer">
  <div class="menulink"><a href="one.html">One</a>.</div>
  <div class="menulink"><a href="two.html">Two</a>.</div>
  <div class="menulink"><a href="thr.html">Three</a>.</div>
</div>

    Even header elements were marked up using a div element, apart from the main heading, which was marked up with an h1. There were so many div elements, that regular elements stood out like a sore thumb. I've noticed an increase in documents that look like this, and they seem to be particularly prevalent in UK government websites.

    Posted by Gez on

  5. [div-mania.php#comment5]

    A really interesting article, thanks Gez.

    When I read the opening paragraph I thought I might be guilty of this. But my reasons for using DIVs are similar to Tommy especially when trying to produce a content first 3-column layout, I end with a fair few DIVs most for controlling the layout and then some as styling hooks depending on the function of the page (homepage, sub-homepage, content page etc).

    But within those DIVs I still try and use semantically correct mark-up.

    Posted by Alex Armstrong on

  6. [div-mania.php#comment6]

    I understand what you mean, Gez, and I do agree with you. It's just that the first example you gave was uncannily similar to how I've made the last few sites. *smile*

    Of course, if there is a more semantic element type you should use it. What I meant to say with my first comment here was that due to the limitations of HTML and CSS, we may have to use a few 'unnecessary' DIVs for styling. Since they are semantically neutral, the only negative side-effect is code bloat.

    Posted by Tommy Olsson on

  7. [div-mania.php#comment7]

    I always try to avoid things like "div mania" as I code on hand, I try to keep the code simple and fluid. It is a ood way to keep your code more than just valid, when I see clear code it is usually as beautiful as the graphic version of the site.

    This article is a great read for everyone who is concerned how their code acts and thrive to use tags as they are intended by their creators.

    Posted by Roni Huhta on

  8. [div-mania.php#comment8]

    Thanks Gez, a concise and helpful article as usual. I wasn't aware of adjacent sibling or attribute selectors, worth considering in future for those moments where you fancy a kick in IE6's ****. *wink*

    Divs are still very necessary to define divisions of a page, but in most standard layout cases you just need the 4 (header, content, sidebar, footer) and possibly a container depending on how you want to lay it out. With each div having its own ID, you very rarely need to use classes at all...

    Posted by Alistair Knock on

  10. [div-mania.php#comment10]

    One thing that would be particularly useful for eradicating unnecessary usage of div would be the ability to set multiple backgrounds with css. It is quite a hassle to make fancy backgrounds for large elements that need to be able to stretch now...

    Posted by Tjaard on

  11. [div-mania.php#comment11]

    Nicely done - I wish there was more out there like this.

    My only comment, other than the one above *smile*

    Part of the problem that created div-mania in the first place was too many coders replacing table cells with div's - which is not what CSS was meant to do. What needs to happen - IMHO - is that we need to start thinking differently about layout, not just semantics and presentational application. As the validator is really only useful for spotting code errors (you may have the most perfect screen door ever made, but if you've just installed it on the bottom of a boat, you'll go down fast and take the validation results with you...), so, too, is using css ( a round peg ) to create static grid-like layouts ( a square hole ).

    At any rate, and for the sake of argument - here's a quick mockup in response to your article - one div only. I didn't spend time on the design (that shows) and I did take it to the extreme) just for fun...
    http://www.pdgmedia.com/code/onediv.html

    Posted by Sean Powell on

  12. [div-mania.php#comment12]

    Valid points, but lack of broad support definitely (and unfortunately) demands trade-offs yet. "Divitis" (or "Div Mania") should be avoided, though "div" elements /can/ sometimes be also useful to provide some context (descendant selectors; without the need for classes and IDs, notabene).

    Posted by Jens Meiert on

  13. [div-mania.php#comment13]

    Thank you for all the kind comments. I wasn't expecting this article to be so well-received, and had braced myself for lots of angry comments. I should have known better, as most people who visit Juicy Studio are not the type of people guilty of creating div mania content. As usual, some of the comments make the point much better than I do in the main article; thank you :-)

    At any rate, and for the sake of argument - here's a quick mockup in response to your article - one div only. I didn't spend time on the design (that shows) and I did take it to the extreme) just for fun... [http://www.pdgmedia.com/code/onediv.html]

    I think the design looks really good, Sean, even if it is a quick mock-up.

    I haven't tested this, so I could be wrong - If you move the declarations from #container into body, you can remove the container div completely so you have no div elements at all. You would need a paragraph for the opening link, and maybe other elements.

    though "div" elements /can/ sometimes be also useful to provide some context (descendant selectors; without the need for classes and IDs, notabene).

    Good point, Jens. I do exactly that on the home page, to avoid class mania for each article summary.

    Posted by Gez on

  14. [div-mania.php#comment14]

    very helpful article - so much written on the net on css, why to use how to use- this one is very informative and well structured.. well done! i still wonder do we really need to eliminate the tables and replace it with divs? i think the best to do, somehow combine both- use minimal tables and surely add css to it, i have read articles where they suggest not to use tables at all, i would disagree..

    Posted by abhishek on

  15. [div-mania.php#comment15]

    Great article, Gez. I picked up a "juicy" tid-bit or two from that one. I suppose I'm guilty of this to some degree. I alway go into a project thinking lean and mean and often end up having to add this or that, or I need to tweak something, and I often find myself with a larger style sheet or html body than I had planned on. As I learn and develop I'm sure I'll improve, though. If not, I'll be asking for a refund form... well, somebody.

    Having articles like this available sure helps. Thanks! =]

    Posted by Mike Cherim on

  16. [div-mania.php#comment16]

    Several reasons to use seemingly unnecessary divs:

    Multiple backgrounds (as mentioned by Tjaard)

    Creating context (as mentioned by Jens)

    Creating hooks to make a page easily restylable (this is very similar to creating context). Think Zen Garden. After all, this is one of the big selling points of css.

    Whenever you use the box model hack (though I love you for it Tantek) you'd be better off using a container div to separate widths from padding or borders. Why? Because hacks that rely on ambiguity of syntax are a potential problem for future browsers. More on this when I have the time to write an article.

    Other than that, I'm in complete agreement, Gez. Especially about using divs in the place of existing, semantic elements. Bad.

    Posted by David Benton on

  17. [div-mania.php#comment17]

    Multiple backgrounds? You can apply backgrounds to many elements, not just div's... see the one div page above *smile*

    Creating context - perhaps, but div's do not create context, they create boxes. Surrounding a calendar, book links and rss feeds would hardly be considered contextually equal...

    Creating hooks to make a page easily restylable - that is done just as easily with id's. At least we're now "hooking"into the element, as opposed to just some box it's been thrown into *smile*

    Anyhoo - just stretching the envelope a bit - good discussion though.
    Envelope...hmmm. good name for an email list container...

    Posted by Sean Powell on

  18. [div-mania.php#comment18]

    I agree with the sentiment that div-mania is nice to avoid when possible, but many complex designs require "extra" divs to accomplish layouts.

    I would mention, however, that my experience has shown that class-mania, as previously mentioned, is even more pervasive. Extraneous class names are almost always able to be replaced by well-designated selectors.

    If I had a nickel for each time I saw something like <ul class="list"><li class="listitem"> or <p class="text">...</p><p class="text">...</p><p class="text">...</p> ...

    Posted by Ben on

  19. [div-mania.php#comment19]

    Sean,

    I agree with everything you just said.

    I guess my point is that when I have to choose between no divs (or spans) and cross-browser consistency or between no divs and the look I want (or my client wants), I tend to choose the latter in both cases. And before someone says it: If you can't think of ANY case where one would have to make the above choices, you haven't been doing standards design very long.

    I'm not advocating div mania. I'm just saying (as Gez did) divs have their place. Divlessness is not a virtue.

    Posted by David Benton on

  20. [div-mania.php#comment20]

    Great article, explained several things that confused me for long, thanks Gez, and nice to find this place, I'm definitely going to visit this site frequently in the future!

    Posted by Gan Quan on

  21. [div-mania.php#comment21]

    Great article, about time someone wrote one, as lots of people new to CSS tend to be confused about divs and spans together with bad class and id names, resulting in some confusing code. Still, CSS presentation is also part of the problem when it comes to round corners etc. and some browsers, proably IE, not be'ing able to style the body element as a normal tag and thus forcing most people to add a "wrapper" div around all their content.

    Posted by taare on

  22. [div-mania.php#comment22]

    It's always good to read about using CSS the way it was meant to be used.

    There is one thing I would like to point out.

    If you're trying to select multiple elements (or classes etc.) you can also use a comma.

    You gave this example:

    h1+h2
    {
    background-color: #ffc;
    }

    I would code it like this:

    h1, h2, h4.class
    {
    property: value;
    }

    It works fine.

    Posted by Nathan on

  23. [div-mania.php#comment23]

    There is one thing I would like to point out.

    If you're trying to select multiple elements (or classes etc.) you can also use a comma.

    The different selectors used throughout this article have different meanings, Nathan. The example you provide is covered under grouping selectors. The example you've quoted isn't trying to match h1 and h2. That particular selector is an adjacent sibling selector. Consider the following example: 

    <body>
<h1>Main Title</h1>
<h2>First Sub-title</h2>
<p>
Some text
</p>
<h2>Second Sub-title</h2>
<p>
Some more text
</p>

    The adjacent sibling selector requires the two elements to be adjacent, and share the same parent. Applying h1+h2 to the example above, would only match the first h2 with the text, "First sub-title". The reason for the match is that h2 immediately follows the h1, and they have the same parent (body). It wouldn't match the second h2, because that element doesn't follow an h1; it follows a p. Applying the h1, h2 selector would match all h1 and h2 elements, regardless of where they appear in the document tree.

    Posted by Gez on

  25. [div-mania.php#comment25]

    @Jero:

    Is the H2 nested inside the H1?

    <h1>head1<h2>head2</h2></h1>

    Or is it like:

    <h1>head1</h1><h2>head2</h2>

    Posted by Nathan on

  26. [div-mania.php#comment26]

    I think your next article should be on "id"-itis or "class"-itis.
    I mean, how often dou get 5 or 6 id's or classes before you reach your first actual paragraph of content?

    Posted by Heiser Erwin on

  27. [div-mania.php#comment27]

    Mozilla/Firefox and Opera support attribute selectors, including those in CSS 3.

    My copy of Opera 8 doesn't support CSS3 attribute selectors... Test case: [http://qurl.net/fL] *smile*

    Posted by zcorpan on

  28. [div-mania.php#comment28]

    My copy of Opera 8 doesn't support CSS3 attribute selectors

    Thanks, ZCorpan. My mistake, I should have tested it properly. I've updated it to read:

    Mozilla/Firefox and Opera support attribute selectors, and Mozilla/Firefox also supports those in CSS 3.

    Posted by Gez on

  29. [div-mania.php#comment29]

    Great article! But I was thinking how sad it is that we cannot use things like p+p, a[hreflang|=en] and p>strong, since IE (isn't it something like 80% of the market?) is not aware of that stuff.

    Posted by Ioannis Cherouvim on

  31. [div-mania.php#comment31]

    This has been a very informative article, Gez. I definetely learnt something here and am looking forward to adapt it in the path to fully working with standards. *smile* I thank you.

    Now just gotta get out of the habit of excessive DIVs and learn to incorporate more SPANs in the areas. Cheers.

    Posted by dannyFoo on

  32. [div-mania.php#comment32]

    Nice article, thanx! Too bad the article does not print correctly in Firefox!

    Greetz,

    Doogie.

    Posted by doogie on

  33. [div-mania.php#comment33]

    good insight. I have been a victim of this in my own site. any advice on improving it will be great help for me. I am prtty new to this and this is my forst ever attempt on CSS site. pls have a look at www.cell-a.com/v2/ and suggest.

    Posted by Shiven on

  34. [div-mania.php#comment34]

    Glad to have come across this! Couldn't agree with you more on the overuse and abuse of div in general on a lot of web sites. I used to almost blindly start out building sites with a bunch of div wrappers and finally questioned why I was doing it. That is one reason why my site hasn't used any divs for almost two years. I did an extreme experiment then using no divs and found the results to be satisfactory across browsers. I understand that 'divlessness is not a virtue'. Sometimes they are a design necessity. But doing so helps to put your IA design at the forefront, allowing you to strip away meaningless wrappers and code your content with more semantic and structural markup. You can check out the no div method at: http://www.jasonspage.net/blog/nodiv

    Posted by Jason on

  35. [div-mania.php#comment35]

    Hi Gez,

    Great Article. I have a question..

    I want to produce a form. The form must have two columns. I was thinking of using a wrapper and two divs, one for each column.

    Is this a senario where you should not use divs?

    Posted by Gaz on

  36. [div-mania.php#comment36]

    Hi Doogie,

    I had printed the article in Firefox with no problem. Just curious, what version of Firefox do you have?

    Hi Gez,

    Impressive article, as usual. Our students, faculty, and staff are finding it very informative. Thanks *smile*

    Posted by Pam on

  37. [div-mania.php#comment37]

    I think one cause of divitis is the way CSS is often taught. Divs are used as an element to demonstrate CSS properties, so people see:

    <div style="border: 1px solid black">

    and get the idea (subconsciously or otherwise) that borders can only be applied to divs. Hence you see stuff like this (in a data table of course):

    <td><div style="border: 1px solid black">1</div></td>

    when the styleing could have been applied to the <td> directly.

    Maybe we need to amend an old wartime poster for web authors' walls:

    "Is your <div> really necessary?"

    Posted by Chris Hunt on

  38. [div-mania.php#comment38]

    I see that eg using extra divs to make rounded borders, to play with the margins and background props calls for a different approach because the extra divs are needed to make a layout work. But I am also for keeping your code logically structured with meaning. Only for layout things I guess some extra divs can be usefull as I mentioned before.

    But I think you ought to know all your HTML and css 1-2-3 and use it accordingly.

    Posted by Johan on

  39. [div-mania.php#comment39]

    I'm not so sure how much I agree with this article. We can try to use <h1> in place of <div> but what is stopping anyone from using <h1> as <b>? And how about <h7> when u need one?

    I would prefer using divs because 

    
<div class="content">
...<div class="header">Main Header</div>
...<div class="content">
......<div class="header">Sub Header</div>
...</div>
</div>

    would make more sense if in future I were to add a New header between the Main and the Sub Headers 

    
<div class="content">
...<div class="header">Main Header</div>
...<div class="content">
......<div class="header">New Header</div>
......<div class="content">
.........<div class="header">Sub Header</div>
......</div>
...</div>
</div>

    Using <h1> and <h2> for the Main and Sub Headers initially would cause major refactoring.

    Of course you may argue, why not use <h1> in place of <div class="header"> then? It's lesser typing. But then, why <h1> and not <h6> for that matter. Ambiguity.

    Also, I feel that it's more consistent with the usage of "class". The way I interprete class is that, all tags that have the same meaning should belong to the same class. The class="header" is one example. And consider also this. If I were to have a dynamic page that allows users to mark headers that they feel are important, I can plug in another class type and it'll make sense. 

    
<div class="content">
...<div class="important header">Main Header</div>
...<div class="content">
......<div class="header">New Header</div>
......<div class="content">
.........<div class="important header">Sub Header</div>
......</div>
...</div>
</div>

    All will still be subjected to the "header" style, and those that are important will be applied with the "important" style. Other uses could be the "error" style for form elements.

    Ultimately, my point is this. Using the <div> tag gives you unlimited possibilities like XML. You could very well use <div class="fruit"> since it makes more sense than <h1>. We'll run out of html tags, but we can't run out of <div class>. It'll also make page composition and dynamic styling easier as well since we need not bother what html tag to use. We can simply use the name of the attribute returned from the server and use this same attribute in our CSS. Consistency!

    Posted by Wilson Na on

  40. [div-mania.php#comment40]

    Hi Wilson,

    I don't know where to begin in answering your comment. Semantics are important in web documents for accessibility reasons. You may think a div is a better choice of tag for a heading, but there are reasons other than the way those tags are rendered (or the amount of typing) for using them. For example, screen readers use them to help people navigate their way around the document. Search engines love heading elements; your content will be better categorised, and your content will be ranked higher. The amount of typing is also a good point. It's not just the amount of typing: if you have a high amount of traffic, then your bandwidth bills will be much lower if you avoid bloating your markup with div elements.

    With the views you have, I'm very aware that you're not likely to accept my arguments on face value. There are also many more benefits than I've outlined here, but I don't want to go too far off-topic by explaining them in detail. There are very good business reasons for ensuring that not only do you follow standards, but that your content is accessible to the widest possible audience. If you could have a shop in the town centre with easy access to everyone that cost less than a shop hidden out of the way, where would you choose to open your shop?

    Without meaning to sound patronising, I urge you to google for the business argument of web standards, and accessibility. A good place to start learning about accessibility is http://accessifyforum.com/ If you ask questions over there, people will be more than willing to put forward the reasons for ensuring your documents are both standards compliant and accessible. You can then make your own mind up as to which you think is the best approach for your clients.

    Posted by Gez on

  41. [div-mania.php#comment41]

    Wow great article Gez. I'm only just starting to learn web design properly, and have already had to forget most of what i was taught at college and uni.

    Sean, that single div site looks and works great, and i tried Gez's suggestion of removing the div and it works really well (in firefox at least), the only thing that needs to be altered is the top margin/padding as it disappears in the div-less version.

    Posted by Andym on

  42. [div-mania.php#comment42]

    It is a pity that we cannot use XML and use CSS to fully specify what our custom tags will look like (or not as the case may be). But that would make nothing standard, except within the confines of our own set of pages.
    Until then, if this is what we want to do, then class will substitute perfectly.

    This article has given me some ideas, but not for web sites. I am using the WebBrowser control from IE as the display for an application. HTML+CSS offers very powerful intenationalisation (right to left [direction: rtl] for Arabic, etc, and vertical [writing-mode: tb-rl] for Asian langusages) that is very awkward is normal visual design. I am using it to display hierarchical information. I was deliberating about using divs and spans with classes and ids, but now I realise I can use any of the multitude of existing block and inline elements in any way I choose. I am not bound by accessability considerations or any of the normal web page stuff as this is not a web app, just an app that is using a HTML inteface for its flexibility.

    However, this does bring me to the issue of accessability and so-called 'standards'. As an author, it is up to you to determine who your target audience is. You only need to cater for who you want, regardless of what a 'standard' says you should do. Personally, I do not want to clutter a site up with all the icons of standards to which it may adhere. I think that we have too many standards cluttering up the web. XML started out as a simple and elegant format. But look at all the embellishments that have been heaped upon it. 'Let's complicate XML'-itis it is! We have lost the target attribute because some of those working on the standards wish to define now that we cannot open other windows for external web sites so the viewer does not leave our site. Now there may be a reasonable argument for that, but the usability police have put it in concrete. I sometimes wish the W3C would conduct user polls rather than only listen to the circle of companies that drive the standards in their own direction, for their own ends. Just because a few small companies manage to get a 'standard' going, does not mean that it is the be all, especially if they haven't got a major player on board. Standards are only standards if they are willingly universally applied, otherwise they are just a pipe dream.

    We have the situation where Microsoft has 85% of the (internet, as opposed to business intranets) browser 'market', but a lot of the standards are dreamt up by marketers of the other 15%. Does that make them standards that all should abide by? No! Some just use them to try and beat up Microsoft with.

    Standards should be based on consensus of all, not a minority that can define an arbitrary standard and expect all to abide by. That is nonsense, however good the standards are!

    Posted by Patanjali Sokaris on

  43. [div-mania.php#comment43]

    As an author, it is up to you to determine who your target audience is. You only need to cater for who you want, regardless of what a 'standard' says you should do.

    Most of your response is off-topic. The whole standards argument is a tired debate, that keeps getting raised by developers/designers trying to justify their work. If you feel as an author you have the right to determine the target audience for your clients, I pity your clients. If you decide to make your personal website so that I can't use it, that is your choice, and I will happily respect the fact that you have chosen to exclude me. I would feel completely different if I needed access to that website/intranet for my daily life or work. Hopefully, those jobs will go to those with the appropriate skills.

    I sometimes wish the W3C would conduct user polls rather than only listen to the circle of companies that drive the standards in their own direction, for their own ends.

    There would be no need for user polls. Well over 90% of the Internet has accessibility barriers, indicating that that's what designers prefer. All industries are governed by professional bodies to ensure that the work is up to an appropriate standard. Much to the annoyance of a lot of designers' ego, ask an end user whether they would like to see the talents of a designer possibly at the cost of access to the content, or unrestricted access to the content: what do you think they would choose?

    Just because a few small companies manage to get a 'standard' going, does not mean that it is the be all, especially if they haven't got a major player on board. Standards are only standards if they are willingly universally applied, otherwise they are just a pipe dream.

    Microsoft, IBM, Oracle, and the many other large, high profile companies can hardly be described as a few small companies. For balance, there are also small and medium sized companies involved.

    Does that make them standards that all should abide by? No! Some just use them to try and beat up Microsoft with.

    Microsoft are involved in the process. It has absolutely nothing to do with an individual organisation, and everything to do with inclusion.

    Standards should be based on consensus of all, not a minority that can define an arbitrary standard and expect all to abide by. That is nonsense, however good the standards are!

    If you feel so strongly, get involved yourself. All standards and accessibility require from authors is responsibility, which you owe to your clients.

    Posted by Gez on

  44. [div-mania.php#comment44]

    Of course an author has the right to specify the target audience for their work. It is part of scoping a work and keeping it on track. I'm sure you made many assuptions about who your target audience was while you developed your article. If I wanted a web page to be accessible to as many people as possible, of course I would be aiming to make it work with as many browsers as I could. If I am only interested in a narrow group of people to which I need to present something really complex, I would not be wanting to take 'herioc measures' to cater for all. It would not be worth the time. If I am designing for an intranet that uses IE as part of the company's standard operating environment, I will not bother to build for Netscape or whatever. For serious high-availability sites I would not be bothering to use hand-coding at all. There are many more considerations than the quality of the HTML. I recently worked for a company delivering a 3G solution to a mobile network. It used 40+ multi-CPU Sun and Dell machines (for grunt only, not storage), running BEA's WebLogic, Documentum and MobileAware to build custom web pages for each user's phone. No one cared about how many divs were used, only whether the pages rendered correctly (looked right). The raw pages were repleat with a multitude of MobileAware's custom tags because they defined how the pages would be structured for the various sized screens. That took months to do.

    Note that copyright laws enforce an author's right to present a work in any form they desire. Whether it fits in with what other people consider best is not something an author has to take notice of, other than how it may affect their target audience (if they even really want one) requires to access their work. This is where standards do come in. They offer a chance to reduce the variety of methods of presenting the same information. Your article suggests a way of presenting the information that might be more suitable for a wider variety of browsers. However, whether their are extraneous divs or spans (as opposed to inappropriate - that is, used where another tag designed for the purpose would do) is not really going to impact a user that much, considering that they quite happilly browse Flash and Macromedia generated sites that make horrendous HTML. Is it a matter of time spent on a hidden 2% that may be out of proportion to its importance for some people.

    Assembler language is very very efficient, but it takes so much longer to do anything sustantial with it that it is relegated to only being used in execution-time critical purposes. To design everything in it would make for some very inflexible (to modify) programs, given the millions of high-level source code lines involved. Many people use a program to design their web pages in a higher level way rather than laboriously hand-coding pages. If they are modifying their pages fairly often, they would rather be spending the time getting their material to look they way they want and not really caring how 'perfectly' the raw HTML looks. Horses for courses. To be frank, they would probably not care if it was all divs and spans if it still worked in all the situations they expect it to.

    For purist hobbiests, time is not so much of an option. That is part of the joy of a hobby - painstaking effort to come close to a form of perfection. That is satisfaction of attaining a goal. If your goal is to only make web pages without any extraneous tags and want to spend the time to do it, that is your perogative. I am only saying that rules should not be made to necessarily enfore that view. Of course, as an author you are quite at liberty to pronouse any rules you like and I would respect your right to have them remain how you presented them. You offered a chance for me to make comment upon your assertions and upon those made by some of my fellow commentators. And it was to some of those other commentators that my comments were directed.

    I think that much better web sites would be produced if more attention was paid to how their layout affected their readers' comprehension of the material presented. How many times ahve you looked at a magazine at a shallow angle to the page so you can read the letters by how much less relective they are than the gaudy 'background' picture? How many web sites have you come across where you are presented with small bright coloured text on a black or dark background? How much do you end up reading, let alone comprehend. Colin Wheildon in his article 'Communicating: Or just making pretty shapes' (later made into a book) details some research he did for the Advertising Council of Australia and how layout severly affected readers' comprehension (as opposed to 'liked the look of') of print media. While there are some differences between print and screen (resolutions, and emittive vs relective) many considerations are common, such as contrast between the text and the background. Something to really ponder upon as you can actually look over pages (print and web) and quantify why thay work or don't work for you.

    However, I would like to thank you for the opportunity to contribute as it was after reading your article and making my original comments that I was lead to investigate all the tags available in IE, and behold, there is a custom tag facility. So now I can make my app (in VB using the IE browser component) to implement structures with meaningful tags and modify their display by CSS. I will now need minimal class and id attributes which only added copious amounts of text to a page, especially when presenting thousands of hierarchical tree items. That is my perfection!

    PS. I am a Technical Writer by profession.

    Posted by Patanjali Sokaris on

  45. [div-mania.php#comment45]

    Of course an author has the right to specify the target audience for their work. It is part of scoping a work and keeping it on track.

    Your original statement said, You only need to cater for who you want, regardless of what a 'standard' says you should do. In terms of audience, standards only have an impact on catering for people with disabilities. If your website is commercial, or offers a service to the general public, then you do not have a right to discriminate. If it's a personal website that offers no services to the general public, then obviously, you can do as you please.

    If I wanted a web page to be accessible to as many people as possible, of course I would be aiming to make it work with as many browsers as I could.

    If user-agent manufacturers and authors all stuck with standards, it would just work. It's thanks to organisations like The Web Standards Project, that user-agent manufacturers have finally concentrated on making standards compliant browsers, so working with standards is much easier today than it was a few years ago. User-agent manufacturers have come together to address these problems, but unfortunately, there are a few old-school designers/developers that just don't get it. I have no desire to convert them, especially in the comments of an article that isn't about web standards, but choosing appropriate selectors for CSS. Those people will either get left behind, or arrive at the party fashionably late.

    If I am designing for an intranet that uses IE as part of the company's standard operating environment, I will not bother to build for Netscape or whatever.

    Standards have nothing to do with building websites that work in a particular browser. If you design for an intranet, you need to ensure that it's operable for people with disabilities. If you don't, then the company has a positive discrimination policy thanks to the work you did on their behalf.

    I'm only responding to the importance of standards part of your comments to offer some balance. It isn't on topic for this article, and I would prefer not to discuss it further here as it's detracting from the original point of the article. If you genuinely want to discuss whether or not standards are important for the future of the web, feel free to contact me by email. If you're just trying to justify to yourself why using proprietary tags for a limited audience is a good idea, this isn't the place to do it.

    Posted by Gez on

  46. [div-mania.php#comment46]

    Every medium naturally discriminates against some section of the population. Viz print media and blind people. There is nothing that is all things to all people. Standards help it to but they cannot force it to be so, despite all the political correctness of intentions. However, software bugs will always be the mitigating factor working against what standards promise.

    As for how much I have discriminated against possible users of web pages for my clients, you are making deductions that far exceed the facts that I have presented to you. Just because I don't agree with your liberal specification of MUST DOs does not imply that the ends to which you refer are not worthy goals.

    Bye bye and thanks for all the fish!

    Posted by Patanjali Sokaris on

  47. [div-mania.php#comment47]

    Every medium naturally discriminates against some section of the population. Viz print media and blind people.

    One of the beauties of the web is that it doesn't have the rigid constraints of other mediums, such as print. Text can be resized, output can be read to visitors, or output to Braille. Assistive technologies allow people to navigate their way around documents, providing they've been marked up correctly. People who are home-bound can now do their own shopping online, without having to rely on others, providing the website they choose to shop at is accessible. The list of benefits goes on and on.

    you are making deductions that far exceed the facts that I have presented to you.

    Any deductions I've made are preceded with clauses.

    Bye bye and thanks for all the fish!

    You're welcome *smile*

    Posted by Gez on

Comments are closed for this entry.