Archive for the ‘posh’ Category

The tables – part 2

Tuesday, May 22nd, 2007

In The tables – part 1 I wrote about how the basic table elements should be used in a POSH document.

What we have until now is shown in example 3:
<table summary=”The steady growth of the company revenues in the last 10 years”>
<caption>Company revenues in the last 10 years</caption>
</table>

As promised, we’ll now tackle are the <colgroup> and the <col> tags.

Column group

When you look at tabular data it doesn’t take long to figure out that the data is grouped in two different ways – rows and columns. If you’ve ever produced a table in HTML you’ll know that you create it by creating rows and then creating cells in them. This means that accessing data by columns is not really all that easy. What you do is go through all the rows and get the cells of the correct index and retrieve the data. The same goes for styling cells in a specific column.

Setting a table cell to align the text to the right would commonly be achieved by assigning it a certain class name that would be associated with a CSS rule that would align the text to the right [1]. When applying the same style to the whole column the intuitive thing would be to add that style to all the cells in the column.

But! Here comes the <colgroup> element.

The semantic meaning of the <colgroup> elements the grouping of columns into groups. Not surprising. What you can get from this is the possibility to style these columns. The colgroup element has a few available attributes:

  1. span sets how many columns are in the colgroup. It defaults to 1,
  2. width sets the width of the whole group,
  3. align sets the text-align of all the cells in the column,
  4. valign sets the vertical-align of all the cells in the column,

Span is only used if the <colgroup> elements contains no <col> elements – in that case the number of columns is calculated from the spans of the child <col> elements. The width contains the width of the columns included in the <colgroup> element but is overridden by widths of the child <col> elements if present. It may contain a special value of 0* which means that the element should be as small as possible but enough to contain all the content.

Two additional attributes are present in the standard – char and charoff but support for them is not required by the standard so we’re not going to go into them even though their use could be useful in some cases.

Column

To specify a column without grouping columns into groups you can use the <col> element. You can also use <col> element to specify special columns inside a column group. If you use one directly inside the <table> you cannot use the other.

The attributes for the element are the same as for the <colgroup> element. They’re also used in the same way.

Problems

<colgroup> and <col> seem like a solution to a lot of problems when styling tables. You often want a whole column to be aligned to right, to have a certain background or be in a specific color. You might even want it to have a different border. All this could be done with a styling of the class name or the id of these elements.

Unfortunately all this only works in Internet Explorer. It doesn’t work in Firefox 2.0 (none of it) or Opera9.2 (only align attribute works, styling with CSS doesn’t). I don’t know if it works in Safari but that doesn’t really matter since the later is enough of a reason not to use this for styling. The only thing that is useful (it works in all the browsers tested) is the width attribute.

You can check all this in the example #4.

Next time…

In the next edition of the tables, hopefully less then two months away, we’ll check the content grouping tags, the thead, tbody and tfoot.

  1. No, align=”right” would not be ok and style=”text-align:right;” is also not the best idea due to the problems of changing this style and applying it to more cells. back

The semantics of <small> and a POSH pattern for footnotes

Sunday, May 20th, 2007

It was probably more than a month ago that markos asked me about the semantics of less important items. We had a short discussion about it and found no relevant tags to mark up a part of text that was less important than the rest of it. An easy example would be a footnote, legal text or any other stuff you would usually make smaller in the world of looks over semantics.

A few days ago I was reminded that I forgot to write about it back then when I saw this issue resurface on the WSG mailing list.

When the semantics of HTML were on question a lot of the tags were ‘deprecated’. Not all marked deprecated in the standard itself, but rather marked as bad practice in the web standards community [1]. When trying to tell the client something is important you really should not be telling it to show it in bold typeface – you have CSS to do that [2].

The problem is that when all these presentational elements were ‘killed’ somebody wasn’t thinking. Let’s see:

  1. <b> ‘deprecated’ in favor of <strong>
  2. <big> ‘deprecated’ in favor of ?
  3. <br> discouraged in favor of <p>
  4. <i> ‘deprecated’ in favor of <em>
  5. <s> and <strike> deprecated in favor of <del>
  6. <small> ‘deprecated’ in favor of ?
  7. <tt> ‘deprecated’ in favor of <code>
  8. <u> deprecated in favor of <ins> and because of confusion with <a>

You might have noticed the question marks in the list. The first one, the tag that is supposed to be a semantic for <big> isn’t really all that important. We have many ways to point out that something is important (if there was a semantic meaning – <h1>…<h6>, <strong>, <em>) or just use CSS to change it to big. The problem lies in the latter question mark. How do you mark something that used the small as some sort of semantic and not just a way of presenting the data visually?

In the standard these are actually specified in the Graphics part of it. The meaning of <small> is Renders text in a “small” font. That’s great, but what if I want to tell the world that what I put in there is a legal text? Footnote? Something deemphasized? POSH patterns to the rescue.

As you might have noticed this post uses footnotes. I’ve marked them so that the text in the article links to the footnote bellow and the footnote links back. To show that this is a footnote relation I’ve added a forward relation rel=”footnote” to the link in the text and a reverse relation rev=”footnote” in the footnote itself. I’m also using these to set the styles (which makes them break in IE6 and other stinky browsers). The footnotes are marked up as an ordered list (<ol>) with a class name “footnotes” and each footnote is a list item (<li>) which has an id “footnote-footnoteid-postid” that enables me to link to it.

When marking up legal notices you might want to use rel=”license” and link it to the part of the content you’re specifying the legal text for with a rev=”license” if you don’t have a link to it; if you’re specifying it for the document just link to the page.

  1. Some are deprecated in HTML 4.01, removed in XHTML 1.0 Strict and some just marked as bad practice. For more details check the specification or other sources. back
  2. If you want more information why this is the way to go please read the POSH page and the articles and presentations linked on that page. back

I’m POSH – are you?

Sunday, April 22nd, 2007

It seems that the core of the Microformats community finally realized that the Microformats hype grew over the small group of web developers that already produced semantic markup and wanted to add even more semantics to it. Now every Microformats fan thinks there should be a Microformat for everything instead of just asking themselves a more important question – “What’s the best semantic way to present this content?”

POSH diagram by factoryjoe
Created by factoryjoe, released under CC by-nc-sa license

That’s where POSH comes in. It stands for Plain Old Semantic HTML. POSHers promote the use of semantic use of HTML which means more than just not using tables for layout. I think that something wasn’t communicated clearly enough and that is the fact that Microformats are born out of a repeating pattern of content presentation which concerns many people and many websites. That’s one of the reasons I never pushed for any new Microformats and was more often than not annoyed by people doing just that. What good can come from a big number of formats that you can’t use because you can’t really know them all?

That said, go practice POSH, document techniques and your own solutions to problems. If some of these problems outgrow the POSH pond they might be turned into a Microformat that we can all follow. If not it’s still a great idea that you can check how other people are solving problems when you stumble upon them.