I do believe that the standard is missing something but I not sure the scale of it (what's missing and what's the problem). Since I have limited web-developer experience and less on the layout part and very little experience with JSR-168 and/or WSRP 1.0 [PDF] I'm doing this solely from dry paper analysis.
Since I first started looking at these portlet standards I've been puzzle by this aspect of portlet interoperability: common look-and-feel. I don't think it's simple to write down look-and-feel, and without common understanding it's harder to implement. In this post I'll focus only on the look/layout element, as in the question: can my portlets just be plugged-in and powered up as an integrated part of a portal or more probable what's missing? To be honest I'll not answer that question (for now) but I will start on 'an answer'.
Searching the for posts and articles on this subject is to say the least disappointing. The reasons can be some of:
- it's trivial - nope.
- no one else cares - likely.
- no one has tried - it's possible that very few have tried.
To get beyond speculating, I'll start with the Web Services for Remote Portlets 1.0 Primer to look for a simple introduction to the subject. In section 5.4 CSS Portlet Classes:
HTML 4.01 states: “Since style sheets are now the preferred way to specify a document's resentation, the presentational attributes of BODY have been deprecated.” Accordingly, WSRP 1.0 has adopted an initial basic set of CSS classes designed to provide a standard set of display options for portlets. For a list with tables of these portlet classes, see Section 10.6 of WSRP 1.0 specification. Use of CSS portlet classes are optional and only appropriate for those markup types supporting CSS.
Looking into the real specification it starts with (my strong):
One of the goals of an aggregated page is a common look-and-feel across the Portlets
contained on that page. This not only affects the decorations around the Portlets, but also their
content. Using a common CSS style sheet for all Portlets, and defining a set of standard styles, provides this common look-and-feel without requiring the Portlets to generate Consumer-specific markup. Portlets SHOULD use the CSS style definitions from this specification in order to participate in a uniform display of their content by various Consumers. For markup types that support CSS stylesheets, Consumers MUST supply a CSS stylesheet to the End-User’s agent
with definitions for the classes defined in section 10.6 of this specification.
Since my focus is on XHTML markup, CSS is relevant but still it's optional.
The next version of WSRP (2.0) is under development so I had a look at the committee homepage and found the Markup SC whose chartered to oversee definition of fragment rules for various markup languages (this is currently being requested of the various groups that standardize the markup languages) and useful CSS classes.
Though this sound promising with regard to some more in depth content, it's deceiving since a look at the documents page shows that the latest document is from 2004-03-31. Looking into the document CSS-REV9-forF2F8.doc only reveals that the input to this work was limited. I'm confirmed in a mail by Rex Brooks with the subject Uploaded CSS REV 8 (my strong):
This is the table of CSS classes we have identified, minus the anchor
class which we dropped, and it includes the questions we have never
answered because we thought we would have a set of rendered samples
to aid our choices. Lacking that or any additional input from member
companies, I will answer the questions as best I can and put together
a draft for the spec section relevant to CSS classes. If you have
questions, comments and/or suggestions, please let me know soonest. I
plan to send the final version of this with the hypothetical spec
language Friday.
Looking furhter at posts to the mailing list i stumled upon one by Noah Guyot on the subject Contextual Selectors, which has one of the concepts that I've considered usefull:
The way we could use this for portlets is a follows. We could wrap the entire portlet markup in a <div class="portlet"> </div> and make all of the portlets classes contextual. That could help prevent stylesheet clashes.
I haven't found the argument that stopped this from ending in the spec. Another good email from Vignette is from an UI
engineer but the gem is from a honest Tibco developer (embedded in another email) that points at all the same problems that I myself have thought about. It looks to me like this input didn't change anything and I sure would like to know what answer he was given.
Update (23/11-2007): Later i found an email from Ken Ramirez to wsrp-comment. He was in the process of writing a book - I guess it's J2EE Portals and Portlets: Create Customized Open Source Portals with J2EE, that's unavailable on Amazon. He's not critical to the conceptual model, but does touch on the sparse documentation. Rich Thompson answers him without any problems, though I think some of the argumentation (and question) doesn't go deep enough.
The WSRP 2.0 - Public Review Draft 04 from the latest 15-day hearing has in section 9.5 CSS Style Definitions no changes to the classes from version 1.0 and primarily some additions to the menu classes. In the wiki the WSRP v2 Public Review comments reveals little interest in this subject so I don't expect further changes but hopefully some en lighting examples later on.
