What is ugly HTML?

Yesterday, someone asked me the question:

“What is ugly HTML?”

And I realized that this isn’t necessarily an obvious thing. HTML is often ugly simply because of how it looks, this mostly centers around readability for me:

  • All one line and/or minified
    This is very popular with minimalists and people who are very concerned with the speed of their pages. Minifying the code is a technique to remove all extraneous spaces, new lines, and characters to keep the HTML as small and streamlined as possible. Yes, this does speed up the pages, and I even recommend that you do it, but I really hate looking at it. It’s ugly.
  • Too little formatting (and too much)
    By formatting, I mean the tabs and new lines that make the HTML easier to read. This is similar to the first item in this list, but I think we should take this further and include too much formatting as well. I have seen pages where there are two or three nested tables, and every single table row and column is indented from the container. This can get insanely hard to read after a while. e.g.


  • All caps HTML
    Yes, this is valid in HTML5 (and HTML 4), but it’s ugly and hard to read. I think some people do it so that they can see the tags more quickly, but although you can see the tags, it’s hard to differentiate them at times. I recommend avoiding all caps for headlines because they are hard to read, and the same goes for HTML tags. If you need to edit the HTML later, it can be that much harder to find the problem if they are all in capital letters. 
  • Invalid HTML
    This is the ugliest HTML of all because it can make a page show up incorrectly at the most inopportune times. It’s not a difficult thing to validate your HTML (I like the W3C validator, myself) and this can save you so much time in the future. 

Then there is the ugly HTML because it’s using old-fashioned methods:

  • Too many DIVs
    It’s like when people learned CSS for layout they only learned to put the CSS on one tag — the DIV element. So every block of text, every image, everything on the page is surrounded by one or more DIVs. Yes, this is technically correct. Yes, it works. But man, it’s ugly. It provides no extra information about the content beyond that it’s a block that might have some styles applied to it. I particularly hate when they add the styles to a DIV that is surrounding another, perfectly functional block-level element like a UL element. Why not style the UL? Save yourself a few characters!
  • I hate it when people add spaces using&nbsp;
    Just like the above, it works, and it makes the page look like you want, but really, that’s what CSS is for. There is this wonderful property: margin, that you can use to set the margins around any element — and rather than relying on the space set by a paragraph tag, you can define it to exactly the size you want.
  • I hate it even more when people use tons of <BR> elements in a row

    Yes, it shoves things down, but just like the above item, the margin property works better and takes up less download time.

  • Hiding content in strange places
    One site I visited once used the title attribute as a way to hide content. When you moused over certain sections of the page, the title content would show up. But the browser I was using showed the title content in a little yellow box as well, often covering the very content that the designer was trying to place. Use JavaScript and place the content in the page. HTML5 even offers a hidden attribute that you can toggle on and off if you want the content to appear and disappear.

What do you think makes ugly HTML? Or does the HTML not matter as long as the page looks good?

Learn the HTML Elements Removed from HTML5

There are several HTML 4 elements that have been removed from HTML5. In order to use HTML5 correctly, you should stop using these elements.

In HTML 4 elements that removed from the specification are “deprecated,” but in HTML5 they are “obsolete.” The difference is that in HTML 4, deprecated elements should be removed from support by browsers. While in HTML5 obsolete elements are ones that may still be supported by browsers, but it  that designers use other technology instead.

HTML Elements Removed from HTML5

  • acronym
    You should use the abbr element instead.
  • applet
    Instead of this tag, you should use the embed element or the video and audio elements.
  • basefont
    You should set font properties with CSS.
  • big
    This tag has no semantic value, and so you should define the styles in the CSS.
  • center
    You should center with CSS.
  • dir
    You should use the appropriate unordered or ordered list instead.
  • font
    You should set font properties with CSS.
  • frame
    Replace frames with iframe or converted to non-framed sites.
  • frameset
    Replace frames with iframe or converted to non-framed sites.
  • noframes
    Replace frames with iframe or converted to non-framed sites.
  • strike
    Replace this tag with either the s element if the text is no longer accurate, with the del element if the text has been removed, or with CSS if the line through the text is just stylistic in nature.
  • tt
    Define the font styles with CSS.

Learn the New HTML5 Elements

One of the first things you want to learn when you start learning HTML5 are the new elements. There are several new HTML5 elements to add new features and functionality to HTML5.

New HTML5 Elements

Document Metadata

  • meta charset
    This is a new, shortened form of the character set meta data. It was added to the specification because web designers were writing the original character set meta tag incorrectly and browsers were supporting it.


  • section
    A discrete section of the document.
  • nav
  • article
    An article or page section that could be syndicated.
  • aside
    A page section that is tangentially related to either the current page or the site as a whole.
  • hgroup
    A group of headings.
  • header
    The header information for a section or page.
  • footer
    The footer information for a section or page.

Grouping Content

  • figure
    Content that is self-contained and referenced as a single unit within the flow of the page.
  • figcaption
    A caption for a figure.

Text-level Semantics

  • data
    Contents that have a machine-readable format that is defined in the value attribute.
  • time
    A date or time with a machine-readable format defined in the datetime attribute.
  • mark
    A block of text that is highlighted for some purpose beyond the context of the current page.
  • ruby
    Ruby annotation used in some double-byte languages.
  • rt
    Ruby text.
  • rp
    Ruby parenthesis.
  • bdi
    A span of text separate from the page contents for bi-directional formatting.
  • wbr
    A line break opportunity.

Embedded Content

  • embed
    The insertion point for embedded content.
  • video
    An embedded video with it’s associated source files and language tracks.
  • audio
    An embedded audio file with it’s associated source files.
  • source
    Source file for embedded video or audio.
  • track
    Supplementary tracks for captioning or secondary audio tracks on videos.
  • canvas
    A scriptable bitmap area for creating images and animations on a web page.


  • input type=search
    A search box text field.
  • input type=tel
    A telephone number input field.
  • input type=url
    A URL input field.
  • input type=email
    An email address input field.
  • input type=datetime
    A date and time input field.
  • input type=date
    A date input field.
  • input type=month
    A month input field.
  • input type=week
    A week of the year input field.
  • input type=time
    A time input field.
  • input type=datetime-local
    A local date and time input field.
  • input type=number
    A number input field.
  • input type=range
    An inexact number input field.
  • input type=color
    A color input field.
  • datalist
    A list of pre-defined options for an input field.
  • keygen
    A key pair generator control.
  • output
    Scripted form output.
  • progress
    The completed progress of a task.
  • meter
    A scalar value within a known range.

Interactive Elements

  • details
    An element where the user can get additional information.
  • summary
    A caption or legend explaining the parent details element.
  • command
    A command that the user can invoke.
  • menu
    A list of commands.
  • dialog
    A part of an application that the user interacts with such as a dialog box.

HTML5 Video Codec Wars

One of the reasons many people dislike HTML5 video is because you have to encode the video in multiple codecs to work on multiple browsers. In fact, in an article I just read that was one of the reasons to hate HTML5. He said, if you have to encode it in flash to support IE why bother doing anything else.

Well I’m on an iPad and my answer to that is, if you don’t encode it in something other than flash, I won’t be able to view it. And whether you like it or not, the iPad and other mobile devices are becoming more important.


But that’s not what I want to talk about today. The reason people don’t like HTML5 video is because there are so many codecs. Which wouldn’t be so bad except that you have to encode your video in all of them, to support the majority of browsers. That means webM, ogg Theora, H.264 and flash. And then the Mozilla organization announced they would be supporting H.264.

Does this bother you? Many people see it as Mozilla caving in. After all H.264 still has a patent surrounding it and so Mozilla is no longer supporting their goal of an open web.

I applaud Mozilla for trying to keep that goal of an open web. But ultimately I think they need to change and go with the codec that most people are using, H.264. Because without a video codec that most people use Mozilla and their browser Firefox become less viable in the marketplace. And with fewer browser manufacturers, the remaining ones will feel less and less pressure to go along with consumer needs for the browsers.

In fact, I believe if Firefox had not added support for H.264 they would not succeed on the mobile browsers as a viable alternative.

The TIME Element Has Been Removed in Favor of DATA

As of October 29th there is a new element in HTML5: DATA. The DATA element is for defining content that has both human- and computer-readable data. Some examples of this are:

  • Dates and times
  • Numbers
  • Colors
  • Money

Each of these can be written in a way that a human will understand, while a computer might not. For example, a date can be written December 16th, Dec 16, 12/16/11, 16 December, and many other ways. While it is possible to teach computers to know that all those things are dates and what they meant. So you can set the value of a date on a data element with a standard format that computers can read.

<data value=“2011-12-16”>December 16th</data>

With the DATA element and its required attribute value you can define data for microformats and microdata as well as for scripts on your web page. The content displays in a format that humans appreciate and the value attribute has the content in a format that computers can read and use.

The DATA Element Replaces the TIME Element

In the same revision to the HTML5 specification that brought us the DATA element, it also removed the TIME element from the specification. While you might be disappointed, this is really a good thing. The TIME element was limited only to date and time formats and as such had a limited scope. With the DATA element you can mark up all sorts of things that can be defined in both human- and computer-readable formats, you are not just limited to dates and times.

How This Affects the Book

I submitted my final revision of the book on October 25, 2011—four days before this change went into effect. The book covers the TIME element, but does not include the DATA element.

Using HTML5 Video and Audio

On my About.com site I wrote an 11-page article explaining how to add video using HTML5 with fallback options for Internet Explorer. I also have a similar (although a lot shorter) article on how to add sound with HTML5. And I get a lot of emails about them saying “I tried this in _____ browser and it didn’t work.” And I’m expecting to get the same type of feedback from chapter 12 when the book comes out.

Now, I admit, I am human. I make mistakes and things get munged in publishing and so on. I tested both the articles on About and the chapter code extensively, as did my technical editors. And I’m confident that it works in modern web browsers, even Internet Explorer.

Follow the Steps Precisely

The video article is especially tough because it’s so long. Who wants to wade through 11 pages of stuff just to post a video? Wouldn’t we all rather be shooting our films instead? But none of the pages are in there as fluff. If you want your video to work in modern HTML5 compliant browsers as well as Internet Explorer 8, then you need to read and do them all. And I can tell by my statistics that people aren’t doing that. In fact, while the first most popular page is page 1, the next most popular is page 5. Page 9 (where you make it compliant with IE) is only 1/2 as popular as page 5.

The thing is—this stuff is very picky. You have to follow the steps exactly, or it won’t work. In fact, it took me a long time and many trials and lots of errors before I could get it working well enough to write the articles and chapter. This means that it can be very frustrating.

In my opinion, the frustration is made up for by the benefits you get from using HTML5 for video and audio. You may disagree.

And if You Do Find an Error…

Please let me know. As I said above, I’m human, and I do make mistakes. But I can’t fix them if I don’t know about them, and since I tested it I think it works as I wrote it. So I don’t know about any errors. Please don’t hesitate to let me know about problems with the articles or the book when you find them. I’d really appreciate it and it might even help you get your video and audio working!

Borders on tables now ok in HTML5

If you use tables (not for layout, of course) it can be very tedious to get the borders to surround every cell using CSS. You need to set the border on the table and on every th and td, and then collapse the borders with border-collapse. I don’t know about you, but I would often just add the border attribute to the table, just to get it done quickly.

Well, this week the HTML5 working group decided to make that okay again. They agreed that many tables need to have borders to define the cells. The proposal pointed out that putting CSS on a table to define the borders would not be carried over when the table was moved between implementations. In other words, if you wrote a table in an HTML document, and then ported that document into XML, the borders in CSS would stay with the CSS, not with the table.

Now it is legal to write <table border>  to add borders around your table and table cells. I, for one, am pleased!

Picking the Right Video Player for Your HTML5 Video

HTML5 Video Player Chart - screen shot from Praegnanz.de
HTML5 Video Player Chart
Unfortunately, while HTML5 brings us a much easier way to embed videos into your web pages, but because of many factors, it still(!) isn’t possible to just drag your video into the video tag and then slap it up on the web. By using a player you can get your HTML5 video up and running quickly.

But which player should you choose?

Philip Bräunlich has you covered! He’s created a chart of (currently) 20 different HTML5 video players, along with details like: what license they are released under, if they have a Flash fallback for non-HTML5 compliant browsers (darn you IE8!), and other features. I especially like that he evaluates how easy or hard they are to implement (for example, OSM Player is “hell no” not easy to integrate).

Right now, none of the players support every feature he’s evaluating, but it certainly is a lot easier to use these players with the features you need or want than it is to roll your own.

What’s your favorite HTML5 video player? Let us know in the comments!