A Guide to HTML

HTML5 Interactive Elements

Many people are now using HTML and JavaScript to create rich web applications, designed to look and feel like a desktop application. Those people often create their own UI widgets, and many of those widgets do the same thing. HTML5 is attempting to standardize some of those widgets, to provide consistency in HTML code and across browsers, and to prevent re-inventing the wheel.

This is an area of HTML5 that is not standardized, and these tags are considered experimental. They are currently part of the WHATWG HTML5 living standard, but are not part of the W3C HTML5 specification. However, most are part of the W3C’s draft specification. At this point, support for them is spotty; none of these tags are supported by all browsers.

I put this section at the end of the article, because if people don’t read this far, they won’t miss much. Unless you’re an early adopter, skipping this section is not the worst idea in the world.

<dialog>
According to the WHATWG living standard, this tag represents a part of an application that a user interacts with to perform a task, for example a dialog box, inspector, or window. It is displayed as a block of text on top of the HTML document. It is meant to be targeted by JavaScript.

It is only supported by recent WebKit browsers (Chrome, Opera, and Safari), and is not supported by Firefox or Internet Explorer at all.

Attributes:

open
Whether the dialog box is showing (open) or hidden (closed). This is a Boolean attribute, so its value should be open, and the dialog will be showing if it is present.
<menu>
This tag represents a list of commands for a context menu.

The <menu> tag was actually deprecated in HTML 4.01, and no browser ever supported it. (The HTML 4.01 spec says it was designed to be used for single column menu lists, and that browsers should render it as an unordered list.) It is in the process of being revived and redefined. Right now, the only browser that supports it is Firefox, and it provides only limited support.

Attributes:

type
This attribute defines the type of menu that is used. It can have one of two values:

popup
If this value is specified, then the menu will be a popup menu that is activated by some other element. The other element could be a <button> with a menu attribute, or some other interactive element with a contextmenu attribute. The ID of the <menu> would be the value of the other tag’s menu or contextmenu attribute.

This value used to be called context in earlier versions of the WHATWG living standard, and as of this writing, Fireforx supports only context and not popup.

toolbar
If this value is specified, then the menu will be a toolbar. This is simply a list of commands for user interaction, similar to a list whose <li> tags contain <a> elements (which I would use instead).
<menuitem>
This tag is supposed to represent an item in a context menu.

Like the <menu> tag, this tag was deprecated in HTML 4.01 but is being revived, and is also unsupported by any browser except Firefox.

<details>
This tag provides some sort of detailed information about the content surrounding it. It is designed to be an interactive block element, so that the user can show and hide the details. (This should happen without any need for JavaScript.)

The content of the <details> tag should start with a <summary> tag. The user clicks the text in the <summary> tag to show or hide the details. If there is no <summary> tag, the browser should supply their own text (e.g. “Details…”).

This tag is only supported by recent Webkit-based browsers (so, not Firefox or Internet Explorer).

Attributes:

open
Determines whether the details block should be shown. This is a Boolean attribute; if present, its value should be open, and the details will be shown.
<summary>
This tag defines the summary text of a <details> element. Clicking on the text will show or hide the contents of the <details> tag, as explained above. It is also supported only in Webkit-based browsers.
<output>
This tag is used to display the output of a dynamic, client-side calculation. An example would be a calculator written in HTML and JavaScript; the <output> tag could hold the result. If you’re not producing dynamic content, and just quoting the command-line output of some program (like they do in computer textbooks), you should use the <samp> tag instead.

This tag is not supported by any version of Internet Explorer.

Advertisements

About Karl

I live in the Boston area, and am currently studying for a BS in Computer Science at UMass Boston. I graduated with honors with an AS in Computer Science (Transfer Option) from BHCC, acquiring a certificate in OOP along the way. I also perform experimental electronic music as Karlheinz.
This entry was posted in HTML and tagged , . Bookmark the permalink.

4 Responses to A Guide to HTML

  1. Ben says:

    You probably know this, but the self-closing-ness of your tags are likely to be totally ignored by the browser unless you set the mime type to xhtml! For example, in most browsers this
    This is a paragraph
    will render exactly the same as this:
    This is a paragraph

    A common gotcha is thinking that you can use a self-closing script tag, e.g.

    instead of

    More on this on stackoverflow:
    http://stackoverflow.com/questions/69913/why-dont-self-closing-script-tags-work

    So there can be arguments for doing this for style or tool support, but the browser really doesn’t care.

    • Ben says:

      wow, looks like wordpress doesn’t escape tags. Sorry, but hopefully the stackoverflow article explains well enough

      • Karl says:

        Also, about the tags – nope, WordPress does not excape HTML; you can use it to mark up comments (as I did just now), so it really can’t do that. For HTML tags, you have to use the &lt; and &gt; escape sequences. I also had to do this when I wrote the article, so I know how much of a PITA it is.

    • Karl says:

      Ben: First of all, thanks for taking the time to read the article. I need all the help I can get…

      The “self-closingness” issue applies only to tags that do not represent empty elements, and that includes the <script> tag. It’s supposed to contain text data (the actual JavaScript code). Trying to make these tags self-closing is not valid XHTML, and browsers will consider it “tag soup.”

      If the tag is actually self-closing – like the <br /> or <input /> tags – then the XHTML standard demands that they be properly terminated, or they won’t validate. The HTML standard (even HTML5) does not, but since XHTML is the one that has been used for years, I think it’s better to include the terminating slash.

      However, the Stack Overflow post did show something else that I wasn’t aware of: the <p> tag cannot contain other block-level tags, like <div>. (Inline tags are fine.) If you try to do this, the browser will consider it “tag soup” and automatically treat it as a tag with empty content. In other words, <p><div>Hello, world!</div></p> will turn into <p></p><div>Hello, world!</div><p></p>.

      I’ll update the article with this info. So, thank you for pointing this out. Please let me know if you find anything else in the article that needs work.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s