Portal markup convergence

[Colin Clark]

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.

Colin

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
http://fluidproject.org