"Table Layouts vs. Div Layouts: From Hell to… Hell?"

"Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Frank Ralf -
Number of replies: 13
An interesting article from Smashing Magazine:
http://www.smashingmagazine.com/2009/04/08/from-table-hell-to-div-hell/
Average of ratings: -
In reply to Frank Ralf

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Sven Trümper -
Nice reading, thx for it! lächelnd

Here you have one back: http://ajaxian.com/archives/css-and-tables-the-war-continues


Regards,
Sven
In reply to Sven Trümper

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Dan Ballance -
interesting commen in the 2nd article about using tables to layout forms. i have to say this is something i sometimes do but it is a very different proposition from laying out the whole page as a table. you could argue that forms are almost tabular by nature. sometimes i think people just can't be bothered to learn css properly though lol
In reply to Dan Ballance

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Jeff Forssell -
Nice article!

Just thought maybe people interested in this thread could give me some reactions to this:

If I hit the [B] button in the HTML editor I get code like:
<span style="font-weight: bold;">sdfsdfsdf</span>

To me that just feels like "style hype"! I can't even really see that <strong> is better than <b>. I mean like if I BOLD something, it can only be to make it stronger!

What would you vote for?
  1. <span style="font-weight: bold;">
  2. <strong>
  3. <bold>
  4. <b>

In reply to Jeff Forssell

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Dakota Duff -

In theory, screen readers read <em> tagged text with emphasis and <strong> tagged with strong emphasis. They should not read <i> and <b> tagged texts any differently (again, in theory). Technically speaking <strong> and <em> tags don't do anything for text styling — it's just that most browsers choose to make them act identical to <b> and <i> tags.

I believe that <b> and <i> were introduced early on by Netscape/IE and are not "officially" supported. However, they are so wide-spread that it doesn't really matter.

If you're a CSS snob, <span> is the "proper" way to do it, with <strong> and <em> tags also being used structurally.

In reply to Dakota Duff

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Red Morris -
My vote would be for 2. <strong> purely for the reason that screen reader compatibility mentioned above. As a good sized chunk of Moodle institutions are publiclly funded schools and unis, I'd say that accessibility is going to become a bigger and bigger priority.
In reply to Dakota Duff

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Jeff Forssell -
I am assuming that a person that designs a HTML editor ought to be more knowledgeable than I am about web matters. So I am assuming that what to me looks like a misinterpretation of the use of styles, is perhaps well motivated in a "proper" way I haven't thought of.
How would a "CSS snob" motivate chosing 1.?
(or is it just overzealous "stylishness"?)
In reply to Jeff Forssell

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Zoe Bogner -
Perhaps it's just lazy programming.
Say you later decided that as well as bold, you also wanted that piece of text to be italics, underlined and the forbidden colour. Adding those styles onto the end of font-wight:bold has got to be a lot easier than generating <span style="color: #ff00ff"><strong><em><u>sdfsdfsdf... and then close everything in the right order.

Sometimes a little human intelligence is better than anything a program can generate.
In reply to Jeff Forssell

Re: "Table Layouts vs. Div Layouts: From Hell to… Hell?"

by Paul O'Donnell -
You didn't say what your HTML editor is, but this may be a preference you can change. I'd be surprised if it weren't.

You'll mostly use <strong>

The article explains why: "The importance of semantic markup is illustrated by comparing the strong and b tags. The strong tag adds semantic meaning to the content; and b tag adds only visual meaning."

Occasionally you'll want text to appear bold, but not be tagged <strong>.On those occasions, assign a class and avoid inline styles. For example, <li class="current-item"> (with "current-item" defined in your style sheet).
In reply to Jeff Forssell

Re: "Table Layouts vs. Div Layouts: From Hell to Hell?"

by Mauno Korpelainen -

Hi Jeff,

I just noticed this post and it really depends on editor and the people who write the code for them. HTMLArea is HTMLArea...

Tinymce in moodle 2.0 gives strong when you press Bold button and strong is the element that most accessibility experts recommend - read http://webstandards.psu.edu/accessibility/tech/bold

If style plugin & button is included to TinyMCE it gives users a choice to modify styles of elements like span directly but the only reason I can see for using spans for font-weight is the need to use some other font-weights than simple bold. Font-weight can have values normal, bold, bolder, lighter, 100,200,300,400,500,600,700,800 and 900.

It is also possible to change the behaviour of personal TinyMCE and set to valid_elements rule set or to init code of TinyMCE

tinyMCE.init({
....
    valid_elements : "...b/strong...",
....
    });

that will replace all <strong> tags with <b> tags - usually it's opposite strong/b  - read http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements 

To question "What would you vote for?" - STRONG

( in plain HTML and without need to be accessible for most screen readers I would of course vote <b> because it's the simplest and shortest tag to use... )

Edit: the reason for using spans might be related to flash - Macromedia Flash MX did understand <b> but not <strong>. I have not checked if current flash can handle strong or not but it might explain why developers have chosen spans for HTMLArea. Who knows?

In reply to Mauno Korpelainen

Re: "Table Layouts vs. Div Layouts: From Hell to Hell?"

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Well bold and italics are often used for established typographic conventions that have nothing to do with Emphasis. For example titles, citations, ... So, global replace <i> -> &t;em> probably just introduces some spurious wrong sematics, which is worse than just useing <i> everywhere.
In reply to Tim Hunt

Re: "Table Layouts vs. Div Layouts: From Hell to Hell?"

by Paul O'Donnell -

Good points all around.

W3C recommendations (HTML4) say that "although they are not all deprecated, their use is discouraged in favor of style sheets." One example they give of an appropriate use of a b element is a BBC article that bolds the lead:

<article>

<h2>Kittens 'adopted' by pet rabbit</h2>

<p><b>Six abandoned kittens have found an unexpected new

mother figure — a pet rabbit.</b></p>

<p>Veterinary nurse Melanie Humble took the three-week-old

kittens to her Aberdeen home.</p>

[...]

Still, there are benefits to using a class attribute here: <p class="lead"> will also do the trick, is semantic, and allows authors the freedom to later customize all leads without changing the document (or changing how all b elements appear).

Similarly, the W3C working draft of HTML 5: A vocabulary and associated APIs for HTML and XHTML encourages authors "to use the class attribute on the i element to identify why the element is being used, so that if the style of a particular use... is to be changed at a later date, the author doesn't have to go through the entire document (or series of related documents) annotating each use." It discourages the b element, except as a last resort.


In reply to Tim Hunt

Re: "Table Layouts vs. Div Layouts: From Hell to Hell?"

by Mauno Korpelainen -

Yes, it's true Tim,

and for most users and 99.9% of moodle sites it really does not matter if editor gives em or i - strong or b - when users press Italic or Bold or even if editor gives spans with different style or class attributes as long as they see the output as italics or bold.

Current HTMLArea gives spans and coming TinyMCE gives strong and em (default settings) but we can as well use b or i if we don't care about recommendations of accessibility experts. In TinyMCE and moodle 2.0 we'll have an option to select that output format - in current HTMLArea we haven't (in editor mode).