Need some JSR-286 Help from the Sakai CSS Wizards

Colin Clark colin.clark at utoronto.ca
Wed May 2 23:56:00 UTC 2007


Hi Gonzalo,

Thanks for sharing your ideas. This is discussion is really  
interesting; I've included the fluid-work list on this thread in case  
anyone there has some ideas.

> 1 - more about meaning, less about style

I completely agree with this one. I wonder if some of the UI taxonomy  
and style guide work that has been going in within the W3C under the  
Accessible Rich Internet Application (ARIA) umbrella would be helpful  
here? In other words, is it possible to establish some kind of  
mapping between the UI primitives identified in the ARIA Roles  
document and the CSS classes that should be available to apply  
styling to these types of elements?

http://www.w3.org/TR/aria-role/

This specification includes a taxonomy that identifies things like  
trees, dialogs, groups, grids, tab containers, tables, etc. I'll ask  
Rich Schwerdtfeger tomorrow (he's visiting us here in Toronto right  
now) if there has been any work defining style classes for the ARIA  
semantics.

> 2 - work with the CSS spec - take advantage of inheritance, for  
> example
> 3 - flesh out existing sections (ie. more message types? more  
> formish bits?)
> 4 - new sections  - off the top of my head: lists, items, panels/ 
> containers, etc.
> 5 - since not all cases will be covered for all possible situations  
> - provide an extensibility escape clause mechanism? factor in  
> organic growth?

These also make sense to me. Though I'm curious to hear how you think  
an "extensibility escape clause mechanism" might look in this context.

> All these hinge on a variety of assumptions that may be way off -  
> that the portlet specification is *not* markup agnostic, for  
> example (1), that the different selectors do *not* need to remain  
> totally independent and standalone (2), that the need for  
> simplicity trumps completeness (3 and 4), that it is *not* a heresy  
> for a portlet to look great on my system and just "ok" in yours  
> (5), etc.

Chuck, how do these assumptions mesh with the Portlet 2.0 philosophy?

Colin


>
> On Apr 30, 2007, at 7:04 PM, Colin Clark wrote:
>
>> Hi Chuck,
>>
>> This is very interesting, thanks for sending it along.  
>> Standardized CSS classes for porlets and tools would certainly  
>> help simplify TransformAble in some scenarios. And given FLUID's  
>> involvement in both the uPortal and Sakai communities, the portlet  
>> standards provide an important bridge for us, too. I've heard a  
>> lot of people complain that the 1.0 spec was, as you say, too  
>> limited to be very effective.
>>
>> I'm happy to help out with this where I can. What kinds of  
>> guidance or suggestions are you looking for?
>>
>> I'm also curious to hear Gonzalo's thoughts on this, as he's the  
>> real wizard in the Sakai community regarding CSS.
>>
>> Colin
>>
>> Charles Severance wrote:
>>> I am on the JSR-286 (Portlet API Version 2) Expert Group and  
>>> would like to improve the CSS recommendations for JSR-286.
>>> This is an opportunity to influence the standard.    Take a look  
>>> at Page 115 of the 1.0 spec (attached).
>>> Part of the problem as I see it and have been told is that they  
>>> have a lot of classes for things to be tagged but no  
>>> recommendation on some classes that "contain classes" like this:
>>> <div class="portlet-container">
>>> <div class="portlet-menu">
>>> ..
>>> </div>
>>> <div class="portlet-body">
>>> <div class="portlet-msg-error">
>>> ...
>>> </div>
>>> <div class="portlet-form">
>>> <div class="portlet-form-label">
>>> </div>
>>> </div>
>>> </div>
>>> </div>
>>> </div>
>>> So there are (a) some missing tags - mostly for the container  
>>> elements - and there is no guidance about how to lay out the  
>>> pages with the containers.
>>> For example - without this simple basic guidance - my guess is  
>>> that transformable/Fluid would not work so well.
>>> My feeling is that this can be improved quite a lot with some  
>>> simple additions and the time is right to influence this spec and  
>>> lay down some basic stuff that lots of portlets will nicely follow.
>>> If someone is willing to work on this - I can get them a copy of  
>>> the 2.0 spec - or you can make a really wild guess and type this  
>>> into Google :)
>>> Please help - a whole generation of portlet writers will thank you.
>>> /Chuck
>>> .
>>> [see attachment: "portlet-1_0-fr-spec.pdf", size: 438107 bytes]
>>> Attachments:
>>> portlet-1_0-fr-spec.pdf
>>> https://collab.sakaiproject.org/access/content/attachment/ 
>>> fd8d4cd7-ed85-4bd9-00ea-738ae2eacb7c/portlet-1_0-fr-spec.pdf  
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab  
>>> (https://collab.sakaiproject.org/portal) from the DG: User  
>>> Interaction site.
>>> You can modify how you receive notifications at My Workspace >  
>>> Preferences.
>>
>> -- 
>> Colin Clark
>> Technical Lead, FLUID Project
>> Adaptive Technology Resource Centre, University of Toronto
>> http://fluidproject.org
>>
>> ----------------------
>> This automatic notification message was sent by Sakai Collab  
>> (https://collab.sakaiproject.org/portal) from the DG: User  
>> Interaction site.
>> You can modify how you receive notifications at My Workspace >  
>> Preferences.
>>
>>
>>
>
>
>
>  - Gonzalo
>
> ---------------------------
>
>

---
Colin Clark
Inclusive Software Architect/Programmer
Adaptive Technology Resource Centre, University of Toronto
416-978-7728 / colin.clark at utoronto.ca





More information about the fluid-work mailing list