Recently in XHTML Category

An Initial HTML 5 Test

| | Comments (0)

HTML 5 has been suggested as an alternate for interactive apps such as games and multimedia, so I thought I would join in on the testing fun. My actual interest is actually a basic one - how difficult is it to do a basic transition from an older page type to HTML 5?

The answer is that the transition is not too bad...especially if you've been using/moving to using technologies such as CSS and SSI. Here is what I did for a basic Web 1.0 page. That's good news for both developers and the promoters of HTML 5, because they promise lots of backwards compatibility.

Starter Page

The page I am working with is the Penn State Extended Keyboard Accent Codes for the Macintosh - currently an XHTML Transitional page with heavy duty CSS and SSI implementation for the header, footer, navigation tabs and other elements. The HTML 5 version has been posted if you want to check code/display.

BTW - the reason it's "Transitional" is that the site began as an HTML 4 page back in 2000 at a time when CSS implementation was still iffy and FONT tags were still in use. I've tried to clean up the code over the years, but I normally find junk from older versions. And I will find it again in the HTML 5 experiment up.

Initial Conversion

HTML 5 starts with the HTML 4.01 tag sets and adds to it. Therefore, a basic conversion is actually very simple if you're going from HTML 4 to HTML 5 - you need to add the following doctype declaration right at the top of the HTML file:

<!DOCTYPE HTML>
<html>

Yes, that is the entire doc type "HTML". As Webmonkey puts it, it's "Finally, a doctype anyone can remember." FYI - HTML 5 is case insensitive so you can "transition" to HTML 5 even if all your tags from capitalized tags from HTML 3.

Moving from XHTML

The conversion from HTML 4.01 to 5 is fairly easy, but if you're like me, you're actually converting from XHTML which is where some standards experts will wonder if we're losing our minds. Before you lose faith though, it's important to remember that HTML 5 is actually adding some tags like FOOTER, HEADER, MENU which add semantic value.

From a code point of view, this primarily means that you should delete the final "/" in XHTML tags like <img /> and <hr /> to return them back to 1990s style <img> and <hr>. A search and replace operation should do the trick, but if you are using Dreamweaver CS5, you can use the Convert option under the File menu to switch formats.

This will not only remove the "/" from different tags but will change some of the header metadata tags (e.g. the language declaration) from XHTML to HTML 5 syntax. It will also allow you to switch back to XHTML Transitional if need be. Of course, you should be working on a second copy anyway...for now.

Implementing HEADER, MENU, FOOTER

A nice class of tags added to the HTML 5 spec are page structure tags like <header>, <footer> and <menu>. These represent common sections of a page such as the header on the top, the footer on the bottom and different blocks of site navigation.

The HTML 5 team apparently noticed that many modern Web sites create DIVS for these sections for the purposes of CSS. These tags standardize these common classes as tags which makes porting data between sites a little easier. For instance, you would no longer have to worry about whether the header was in <div class="header"> or in <div class="topheader"> or <div class="logoheader">. It's all <header> now.

See some pre HTML 5 and post HTML 5 code for comparison of a navigational menu. I think you'll see that the HTML 5 code is a little easier to parse.

XHTML Transitional

<ul class="menu">
<li><a href="index.html">HOME</a></li>
<li><a href="bylanguage.html">BY LANGUAGE</a></li>
<li><a href="platform.html">BASICS</a></li>
<li><a href="accents.html">ACCENTS</a></li>
<li><a href="web.html">WEB DEVEL</a></li>
<li><a href="glossary.html">GLOSSARY</a></li>
<li><a href="sitemap.html">SITE MAP</a></li>
</ul>

 

HTML 5

<menu>
<ul>
<li><a href="index.html">HOME</a></li>
<li><a href="bylanguage.html">BY LANGUAGE</a></li>
<li><a href="platform.html">BASICS</a></li>
<li><a href="accents.html" >ACCENTS</a></li>
<li><a href="web.html">WEB DEVEL</a></li>
<li><a href="glossary.html>GLOSSARY</a></li>
<li><a href="sitemap.html">SITE MAP</a></li>
</ul>
</menu>

FYI - If you do have multiple navigational schemes, you can create custom CSS classes for the MENU tag.

CSS: Don't Forget display:block

With the exception of Internet Explorer, most modern browsers (Firefox/Safari/Opera) already support these HTML5 structureal tags. Technically they support any tag you wish to make up including everyone's favorite, the <foo> tag. All these browsers do is check the CSS sheets for display instructions.

Note though that there is a default CSS set for standard HTML tags like BODY, H1, H2, and so forth. Our CSS is basically adding additional display information. For newer or made up tags, you have to start from scratch and that includes the CSS display: block syntax which basically says "This class/tag is a DIV like block and not a SPAN." You also need to manually set margins and padding.

Fortunately, you generally only need to add/modify these pieces of information and everything else can stay the same. See example XHTML and HTML 5 code for a header block. Notice that I am also modifying the display of links within a header.

XHTML Transitional

/* Makes logo area blue */
#logoheader { margin: 0px; padding: 5px; background-color: #00B; color: #FFF; }

#logoheader a {text-decoration: none; color: #6AF;}
#logoheader a:hover {text-decoration: none; color: #FFF;}

 

HTML 5

/* Makes logo area blue */

header {
   display: block;
   margin: 0; padding: 5px;
   background-color: #00B;
   color:#FFF;
}

header a {text-decoration: none; color: #6AF;}
header a:hover {text-decoration: none; color: #FFF;}

Can there be Accesibility 2.0?

| | Comments (0)

We all have our favorite Web 2.0 apps (even cynical old me), but it cannot be denied that any new Internet technology must inevitably be followed by accessibility issues. That's just part of the new Internet cycle.

Fortunately, this is often followed by accessibility tools and recommendations.

Some Web 2.0 Pitfalls

  1. Where's the ALT Tag? - If you upload an image via a Web form and you don't have a chance to give it a title or description...you've probably uploaded an image with no ALT tag.
  2. Where's the Podcast transcript? - Just because it has a cool name, doesn't mean it's not an audio file which needs to be accessible to hearing impaired audiences.
  3. What did AJAX do the screen? - When an AJAX app like Basecamp puts a new message on the screen, your eyes will catch it. The screen reader, on the other hand, might miss it...
  4. How good is that code? - Some WSYWIG editors generate better structured code than others. You want to avoid ad hoc styles and breaks and go for headers and paragraph breaks. And if you're persnickety like me, you probably want access to the RAW code so you can fix it!
  5. Same Link Text - Some apps include multiple links with the same text (e.g. multiple "Read More" links which is not recommended). It's preferable for links to have unique text if possible...but it is more difficult to implement in the backend.
  6. Web 2.0 = scripts! - Scripted pages can be made accessible, but you do have to work at it


Some Good Examples

Some Web 2.0 developers HAVE thought about this already. For instance:

  • The Web editor for Wikipedia does convert its Wiki syntax to well-structured XHTML.
  • Both Movable Type and Drupal uses CSS to make Headers appear to be hot-looking page titles and sidebar widgets.
  • Movable Type will also put in an ALT Tag for any uploaded image...but it will match the title of the image unless the saavy blog writer changes it. Drupal will also allow to edit in ALT tags...but have to be on the saavy side for this one also.

At the same time, there are new standards being developed...such as WAI-ARIA.

The gotcha for these is that you may implement them, but an old screen reader might still miss them...

What made me switch to XHTML? XSLT!

| | Comments (1)

I read an interesting article from HTML Goodies reminding me that the switch to XHTML was mostly hype for a long time
http://www.htmlgoodies.com/beyond/xml/article.php/3669451

As Philbin points out, most of the reasons given aren't valid. This is because XHTML and HTML 4 pretty much have the same functionality, so basically:

  1. Well formed HTML is as valid as well formed XHTML. HTML Strict is pretty strict by the way - no FONT tags or ALIGN attributes allowed.

  2. You can make the same stupid accessibility glitches in either HTML or XHTML (did you know that black on black text is valid code...but illegible?)

  3. Browsers will be supporting both HTML and XHTML for many, many years to come.

  4. Not all browsers support ad hoc combinations of XML and XHTML.
BUT Philbin did miss one thing that made me switch - XSLT. This is another XML schema which lets you convert non HTML XML into XHTML. But because XSLT is an XML schema, it can only reference another XML file...and only XHTML fits the bill. If you want an XSLT generated page to mesh well with the rest of the site, the entire site should really be in XHTML.

This may be a case of the future is coming, but it really takes 5-10 years for it to arrive.

By the way, Dreamweaver 8 was my "bestest" friend ever in the switch. You open any document, then go to the File menu, then Convert, then pick your format (I recommend XHTML Transitional for beginnners, unless you were already HTML Strict).

Once you do this, Dreamweaver magically converts all <br> tags to <br> tags, and all <img> tags to <img /> (and it adds the pesky slash to all your single line meta tags). It also adds the correct DTD statement (so I'm not having to cut and paste that either). After that your WSYWIG editors is set to produce the XHTML versions of the tags and Dreamweaver valildation is generally picker when it's XHTML so it finds basic glitches much faster.

Now...we just have to worry about XHTML 2!