[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. Ciao, Rex 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 >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 -- 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]