Andy Pemberton Rotating Header Image

The Perfect Portlet Markup

I thought I’d throw together a quick precursor to another post I plan on finishing in the next few days. This post is about portlets - or, how to structure the HTML markup for a JSR168/JSR286 portlet, to be more specific.

I’ve worked on theming portal user interfaces for a few years now, primarily on IBM WebSphere Portal and JBoss Portal. On WebSphere, you develop what’s called a ’skin’ - where the markup for a given portlet lives. JBoss has a similar but more granular concept called ‘renderers’. Being a big fan of the principle of semantic markup or POSH, I’ve come to think that all portlets should have the same general shell or HTML markup.

So, I present the perfect portlet markup:


<div class="portlet-window">
	<div class="decoration">
		<h2 class="title">portlet title</h2>
		<ul class="controls">
			<li class="skip"><a href="#skip_$PORTLET_ID">skip this window</a></li>
			<li class="mode edit"><a href="#">edit this window</a></li>
			<li class="mode view"><a href="#">view this window</a></li>
			<li class="windowstate minimized"><a href="#">minimize this window</a></li>
			<li class="windowstate maximized"><a href="#">maximize this window</a></li>
		</ul>
	</div>
	<div class="portlet-content">
		portlet content
	</div>
</div>
<a name="skip_$PORTLET_ID"></a>

You might notice this layout:

  • follows the JSR168/JSR286 naming standards for window, decoration, controls, etc.
  • marks the portlet title up as a level 2 heading; from my experience this is the ‘right’ choice for the portlet title as the portal page title itself should be the level 1 heading
  • to promote accessibility, renders actual text content in the mode/state menu anchor links (which should be internationalized and can be replaced with appropriate icon images using your css image replacement technique of choice, of course)
  • to promote accessibility, adds a skip link to the mode/state menu for skipping the content of a given portlet (this is very useful for screen readers and can be removed from the page using your css text hiding method of choice)

Note that one or more the elements in the shell may be removed. For example, sometimes portlets won’t display their portlet title, which is often the case with content-manged portlets (ideally, this would be a configuration rather than separate skin or renderer).

By the way, this post is intended to be a bit controversial; hoping to challenge my audience (if there is one =P) and maybe to come to some kind of consensus.

So what do you think? Did I get it right? What would you change or improve to this portlet markup?

1 Comment on “The Perfect Portlet Markup”

  1. #1 Gary S. Weaver
    on Nov 4th, 2009 at 10:38 am

    Similar topics have been brought up on the Jasig lists (jasig-ui, portlet-dev).

    JSR-168 and JSR-286 are obviously the standards that everyone should refer to first:
    http://jcp.org/aboutJava/communityprocess/final/jsr168/index.html
    http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html

    However, it is highly disputed that the CSS classes/styles that they define in PLT.C are of much use. If you’re interested in a quick reference I put one together here:
    http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference

    In uPortal portlets contributed up to today’s date, you’ll see a lot of non-semantic markup (basically everything is a div, which is not good) peppered with minimal usage of the PLT.C classes.

    I like that you are trying to nail down a standard (I’ve tried to also, and I know that others more talented than me with UI continue to try), but the fact is that each portal’s portlets are going to be different and there is not really a good way to write a portlet that will render well in every (or even most) portal environments because of the awful and outdated UI and CSS definitions in JSR-168 and JSR-286. For example, in uPortal 3.1, they’ve latched onto the FSS (Fluid Skinning System) which is non-standard across portals.

    Something else to consider is that many have been using or are starting to use proxy portlets that pull in content served by Rails apps, PhP, etc. This could be the direction of things to come unless efforts to integrate other more dynamic languages into the portals themselves take hold.

Leave a Comment