Tag Archives: HTML

We need a “credit” attribute in XHTML

Posted on by
Reply

The XHTML 2.0 draft document by the W3C includes some promising attributes for elements. For instance, a navigation list could have a role with a value of sitemap. I.e.: <nl role="sitemap">

That’s cool. Think on that a bit, o ye of semantic persuasion. The potential benefits of this type of specificity in standard markup is great.

Now, that said, I was working on a site that I hope to launch tomorrow, and I would have loved to use an attribute like credit for image elements. It would be used to specify photo credits for a couple images I’m using, plus on some banners, I could have credited the designer who put them together.

It would look something like this: <img src="cool.jpg" alt="Illustration of a calico cat in a beret playing the saxophone." credit="J. Smith, Illustrator for Cool Colors, Inc." />

We could throw this information into the alt text, but it doesn’t really belong there, since the alt text is supposed to describe the contents of the image. We could also use the title attribute, but it would be nice to reserve that for slightly more pertinent information.

Today, I just added credit information in as comments in the markup. It was an adequate solution, I think, but will never be picked up by any user-agent.

Diagram of XHTML, CSS, JavaScript as types of code in a web page

Posted on by
Reply
XHTML, CSS, Javascript as part of a web page

XHTML, CSS, Javascript: Cumulative aspects of a web page. Click the image for a larger version.

I’m thinking of using this diagram in an XHTML class I may be teaching in a couple weeks. The idea is to put XHTML, CSS, and Javascript in context with each other—yet to also illustrate that they are separate types of code and often are actually different files altogether.

Semantic vs. valid markup

Posted on by
Reply

Scott Pennington of Matrix at Michigan State University emailed an interesting link to me. The SimpleBits blog has a post and discussion of semantic markup of a page heading. A fairly elementary quiz starts it off, but the range of perspectives in the discussion starts to show the complexity of semantic markup.

On the one hand, if something is a paragraph, mark it up as a paragraph. If it is a list, mark it up as a list. Pretty straightforward.

But, semantic markup is not the same as valid markup. You can write markup that is perfectly valid, but not at all semantic.

For instance, when I worked at Michigan State University I was working on a pretty large web project, and we had just deployed a near-final version as most of the team went on a holiday break. While on vacation I got a few calls: one from my boss and another from a consultant they were bringing in to do a little more work.

I figured everything was fine, but when I came back I found out that all of the semantic, valid paragraph markup in the web site had been replaced with double line breaks between “paragrahs.” There wasn’t an actual paragraph left in the whole site. Sure, visually there was, but in terms of semantic markup, they had vanished.

Upon asking the rationale, the answer was that line breaks gave you more control over spacing between page elements. Anyone who has a clue will realize, of course, that you don’t control spacing on web sites with line breaks, you control it with CSS.

After trying to explain the issues to my boss, I ended up having to live with the non-semantic markup. The issue was deemed as a difference of opinion between two programmers, and neither position was wrong. How very diplomatic. I personally think it devalued the end product we gave the client.

This was just at the beginning of semantic markup becoming a big issue in the web community, so I had very little literature or other examples to draw upon. I feel somewhat validated as my stance on the issue has since been backed up by some of the leading names in the web field.