Portal markup convergence

Colin Clark colin.clark at utoronto.ca
Tue Jul 10 23:49:13 UTC 2007

Hi Antranig,

A little slow to respond, sorry.

Gonzalo's response clarifies a few of the questions I had when looking 
at the markup you pointed out. Things are much clearer now. Thanks, Gonzalo!

 From an accessibility perspective, there's nothing in this markup that 
I find particularly troubling. In fact, I did an accessibility review of 
the portal for the 2.3 release and found it was quite good!

Perhaps some small future accessibility tweaks like adding tabindex="0" 
support to the menus will speed up keyboard access, and of course 
squashing that last iFrame would be nice. ;) But other than that, it's 
fine by me.


Gonzalo Silverio wrote:
> Antranig,
> Great stuff! Some answers:
>> i) Use of transparent gif as a holder for alt text - generally looks
>> like this:
>> <a href="${toolPlacement.toolResetActionUrl}"
>> target="${toolPlacement.toolPlacementIDJS}" title="$ 
>> {rloader.sit_reset}">
>> <img src="/library/image/transparent.gif" alt="$ 
>> {rloader.sit_reset}" border="1" />
>> </a>
>> Sometimes the img border is 0 rather than 1.
>> I'm guessing this is because we want the ability to keep the actual
>> image in CSS and out of the portal markup? Or is there another reason?
> That is the sole reason for all of the above. Transparent gif as a  
> anchor placeholder, CSS referenced background image for skinnability.
>> ii) Including some link text for a link within an extra <span>
>> rather than directly in the element, e.g.:
>> <li class="selectedTab"><a href="#"><span>${site.siteTitle}</span></ 
>> a></li>
>> One of these is specifically commented
>> ## note: keep all the tags in this block in the same line
>> <a href="${pwd.siteUrl}" title="${pwd.siteTitle}"><span>$ 
>> {pwd.siteTitle}</span></a>
> Whitespace treatment is unpredictable - so we are omitting it from  
> the markup here and elsewhere where there may be a need for pixel  
> precision placement.
>> What happens if we leave the <span> out?
> The span there is used as an optional canvas area - some skins that  
> do some complex things (like the Sliding Doors technique) need it...
>> A final issue - there are lots of hardcoded ids in the portal  
>> markup, and
>> it is not clear which ones are vital. I can see a fair set of them  
>> being
>> referenced in portal.css, but not all - e.g. headerMax, headerMin.  
>> Is there
>> a full list somewhere of which of these ids are "official" and need
>> preserving? Just hoping to save some work for myself :)
> Right - take a look at the sakai_skin.doc in https:// 
> source.sakaiproject.org/svn/reference/trunk/docs/architecture/ 
> sakai_skin.doc - there are a couple Appendices that outline in  
> wireframe the thicket of nested id'd and classed blocks. Not all of  
> them are used by any one institution, they were all requested by a  
> working group back in 2.2.
> Best,
> 	-Gonzalo
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto

More information about the fluid-work mailing list