Re: [Bodington-developers] CSS and Colours in Bodington

[Jon M. <jo...@te...>]

Responses in installments while I think about it........

I'm thinking about a much more generalised way of implementing the CSS 
accessibility.

A key part of it is to modify colours and it is necessary to know which 
foreground colours are going on top of which background colours.   
Parsing and transforming a CSS file doesn't really work because you 
can't easily tell which classes will go on top of which other classes in 
order to boost contrast or deal with red-green colour blindness contrast 
etc.   Anyway, I have some ideas for using client side DOM for examing 
styles as actually applied to the HTML and transforming them dynamically 
according to the user's preferences. A server side version would also be 
possible by filtering all the output of the web server through a special 
servlet.

I'm likely to work on this in an application of my own rather than 
Bodington but I'll keep you up to date on progress.

Jon

Matthew Buckett wrote:

>Probably Jon Maber wrote:
>  
>
>>I can answer a couple of questions straight off....
>>    
>>
>
>Thanks Jon.
>
>  
>
>>Originally there was a strong distinction between moving about rooms
>>etc. (wallpaper and carpet colours) and documents/tools (paper colours).
>>So the top frame, the left frame and the menu frame of rooms, suites etc
>>all used the navigation set of colours - default ivory text on mid to
>>dark teal. Other templates used dark text on light background.
>>    
>>
>
>Ok that makes more sense. So Navigation colours were used for all
>templates related to containers (branches) and document colours were
>used on all tools (leaves of the tree).
>
>One problem is that some of the navigation colours now are used in
>default templates (manage.html) which are shared between branches and
>leaves of the tree. If every resource generated it's own CSS you could
>just fix this with CSS but otherwise you have to have different
>templates for leaves and branches.
>
>  
>
>>The ability to have the whole set of colours change allows a suite of
>>rooms for a specific course to 'brand' the colour scheme.  Originally
>>this was restricted to sysadmin so that course managers etc. wouldn't be
>>able to put horrific colour schemes into effect. However, the intention
>>of the accessibility transforms of the colours was to allow individual
>>users to control legibility in the event of yellow on purple and other
>>such abominations, without losing the distinctiveness of the colour
>>scheme. (i.e. bright yellow goes to creamy yellow and purple goes to
>>purply grey.)
>>    
>>
>
>Yep I had quick look through PrefferedColourMapper and learnt about HSV
>colour model...
>
>  
>
>>A lot of this seems to be broken in the current release.
>>    
>>
>
>Yep.
>
>  
>