OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-markup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: CSS Feedback

Hi Dan,

My first response, of course, is: can you arrange for Nicolas to join 
the subcommittee? That is the best, and most direct, way to get these 
deficiencies corrected.

However, even if that is not possible, we will do our best to address 
these concerns, since they are also our concerns. We have a 
teleconference tomorrow at 8:00 a.m. Pacific Time, 11:00 am Eastern 
Time, and I would be more than pleased if Nicolas could join. The 
information is in the calendar on the OASIS TC and SC webpages.

Of course, I do not know if he is also located on the left coast 
here, but our other regular participant, Noah Guyot from Vignette, is 
and I had previously indicated that I thought it would be a good idea 
for us to try to schedule some time to sit down together and now I 
think that when we do we should perhaps work out a plan to produce 
some examples that could be included in the updated primer.

Because I am an independent, I have to give priority to the pursuit 
of work at this time, so I have constraints, but we all have 
limitations, and those who are employed by member companies also have 
priorities that take precedence over SC work.

However, I do plan to work on this over the summer and I would 
welcome any help that can be offered.


At 10:55 AM -0700 6/10/03, Danny Machak wrote:
>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
>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
>2) I am somewhat suprised not to find the classes
>portlet-menu-cascade-item-hover and
>-- Thanks, Nicolas 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]