Revised Minutes for 6-11-03

Per Rich Thompson I have changed the note about last week's meeting to change CSS classes to start with "portlet-" and not "wsrp-" as this made them more reasonably shared with other efforts (such as JSR 168). If there are no further corrections, after to today's TC meeting, I will ask the OASIS Webmaster to link this message for the minutes to the public webpage for the SC.

June 11, 2003

Teleconference meeting of the OASIS WSRP-Markup Subcommittee.

Wednesdays, 8 am PST / 11 am EST / 5 pm CET, 1 hour
US dial in #: 1.888.481.3032
International Dial in #: 1.617.801.9600
Participant Passcode: 28614774

Roll Call:
Attending:

Rex Brooks, Independent, co-chair
Andre Kramer, Citrix Systems, co-chair
Noah Guyot, Vignette
Chris Braun, Novell

Minutes taken by Rex Brooks

Meeting convened 11:05 a.m. Eastern Time

Rex apologized for not having posted minutes from previous week's meeting, indicating that there was little to report other than that the CSS classes needed to have the wsia- prefix changed to portlet- and that the revised charter would be corrected and submitted to the TC for the following day's TC meeting.

Andre noted that the time in the calendar for the meeting was wrong, indicating 12:00 pm ET and Rex said that he would change the time to 11:00 am ET for the next meeting.

We welcomed Chris Braun back from his leave of absence and we are pleased that we will have his support.

Most of the meeting was occupied in discussion of the post forwarded by Dan Machak of TIBCO of TIBCO developer Nicolas Prade's comments on the CSS classes.

That message follows:

Date: Tue, 10 Jun 2003 10:55:35 -0700
From: "Danny Machak" <dmachak@tibco.com>
Reply-To: dmachak@tibco.com
Organization: Tibco Software Inc.
X-Accept-Language: en-us, en
To: Rex Brooks <rexb@starbourne.com>
CC: Nicolas Prade <nprade@tibco.com>
Subject: CSS Feedback
X-Rcpt-To: <rexb@starbourne.com>
X-DPOP: Version number supressed
Status: U

Hello Rex,
One of our developers has started working with the CSS rules and has
some specific feedback for you to consider in updating the spec and/or
developing the guidelines for CSS usage:

=======================================================================
10.6. CSS Style Definitions

This chapter started as a good idea, but unfortunately is too uncomplete
to be of any help to portlet developpers. The requirements set here are
too vague and unclearly defined. If I am a portlet writer, I do not have
enough info to guess how a portal engine will interprete my classes. If
I am a portal developper, I do not have enough info to safely process
the classes in a way compatible with what the portlet writer expected.

* If this spec wants to set requirements related to what CSS classes
should be provided, it should therefore also provide guidance on what
these CSS classes can/should be used for. There shoud be a formal
definition for each class, including:

1) The semantics associated with each
     class (e.g., what kind of animal is
     the "section" that portlet-section-header refer to?).
2) The context in which each class can be used
     (e.g., an element of class portlet-section-header
     can or cannot be included in the corresponding
     element of class portlet-section-body).
3) A clear example of use for each class would not hurt.

* All the classes required by this spec should be clearly useful. For
example, what justifies the existence of the class portlet-font? the
definition of this class should explain why (see point 1 above).

* The classes required by this spec should be clearly non-redundant,
both in relation to each other and in relation to the existing CSS
selectors. For example, what justifies the existence of the series of
portlet-table-... classes? With the lack of further information on the
semantics (the actual purpose) of these classes, those could be
abandonned either in favor of the use of the existing CSS selectors
(TABLE, TH, TD, etc) or in favor of the apparently redundant series of

portlet-section-... classes.

10.6.1 Links (Anchor)
Just as we dont need a class for A, we just do not need any class for
any HTML element, or anything else that already has a CSS selector. For
example, if I want to process in a special way all the TABLE elements
present in the HTML fragment of a portlet, I can declare a selector at

the level of the portlet containers (i.e. somewhere out of the scope of
this spec) and use inheritance:

    <style type="text/css"> .portlet TABLE {
              /*styles for tables in portlets */ }
....
    <div class="portlet">fragment starts...<table>...</table>
        ...fragment stops</div>

10.6.2 Fonts
There is no neecd for having a portlet-font class (see right above).

10.6.3 Messages
This seems to collides with portlet-font, portlet-section-body, etc.

10.6.4 Sections
1) What exactly is a section??? There is no clear semantics associated
with this concept, therefore portlet developpers cannot be expected to
use it, or at least to use it consistently. If this cannot be used
consistently, this goes against the very goal of WSRP.

2) What is valid where? Example: Can I place a portlet-section-alternate
inside a portlet-section-body, or should they actually alternate
themselves?

3) How does portlet-section-text differ from portlet-section-body.

10.6.5 Tables
Not needed. Same as for <A>

10.6.6 Forms
1) What is the use of portlet-form-label?
2) What are the definitions for portlet-icon-label,
portlet-dlg-icon-label, portlet-form-field-label.
3) "(not input field, e.g. checkboxes, etc)". This could be
    be more explicit.

10.6.7 Menus
Menus are not part of any other spec, so it is indeed a good idea to
provide classes for each of their components. Still, this section is not
perfect yet:
1) Need clarification on the use of portlet-menu. What does it cover
that is not already covered in the next classes, for example
portlet-menu-item?
2) I am somewhat suprised not to find the classes
portlet-menu-cascade-item-hover and
portlet-menu-cascade-item-hover-selected.

-- Thanks, Nicolas ======================================================================= Dan

It was decided by consensus that we will work on recommendations for the CSS classes over summer.

Our aim will be to simplify the classes and address the issues raised by Nicolas' message.

Noah identified some inconsistent browser behavior, particularly with font size in Internet Explorer v5 and Netscape Navigator v4.7 series respectively. Mozilla and IE6 both behave more consistently, but it was noted that we need to cast our recommendations in terms that are more, rather than less, inclusive.

Of the specific items in Nicolas' message we agreed that we should not recommend classes that simply duplicate HTML rules, or can be less redundantly specified by CSS selectors, but that we need to explore the set of classes we have more thoroughly before we decide on recommendations.

We looked at the concern that the section class was not well defined and we decided we will look into whether we need this class, or if what Nicolas suggests is sufficient, and we will similarly examine concerns related to the other items in Nicolas' message.

In his work, particularly in relation to 'Section 508' accessibility issues, Noah indicated that current thinking among leading HTML developers is that <H> tags can be used as a hierarchy to define divisions such as he thought we might have envisioned demarcating with the section class.

Noah also indicated that he would have time after July 8 to work on building a set of examples from Vignette. We agreed that we should encourage member companies to supply examples for the TC to use in the primer, and specifically for the Markup SC to provide for the primer.

It was noted that there appears to be adequate need for distinguishing table classes for portlets because we see two common types in practice. Structural tables are used for general design layout purposes. Data tables are used for organizing and displaying data values.

We agreed that we should look for some guidance on Forms from the Interop SC and that we should mention that to the TC at the next TC meeting.

In regard to Menus we also want to ask for guidance from Interop and Conformance SCs as to whether it should be specified that javascript classes be constrained to occur only within <HEAD> tags and not within the <BODY> of a portlet because that is not valid XML.

We agreed that we will pursue a policy of drafting the clearest definitions we can for CSS Classes and Fragment Rules and present them with examples for use in the primer.

The meeting adjourned at 11:35 p.m. Eastern Time.

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com

wsrp-markup message