Re: another try at a proposal for scaling

One of the approaches taken on this subject in the past was to 
differentiate by whether or not properties need to change.

Past techniques:

Using em or percent for properties that need to change [1]
Using px for properties that do not need to be changed [2]

The advantage to this approach is that it doesn't leave authors with the 
impression that it's never appropriate to use absolute units.

Regardless, I think this proposal goes a bit further than it needs to to 
and would prefer an approach that underscores the UAAG requirement to 
give users the option of scaling font size (by making authors aware of 
coding practices that can make this difficult or impossible) without 
unnecessarily restricting an author's ability to use CSS.

-Ben

[1] 
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050630/#units-that-change>
[2] 
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050630/#units-for-static>

Becky Gibson wrote:
>> Failures could include:
>> 1.      Using measures which are based on a physical length (for example: 
> px, in, pt in CSS)
> I know it is a controversial subject, but I do have some concerns about 
> creating a failure which outlaws the use of px.  Even the W3C Tips for 
> Webmasters [1] doesn't speak against using px (although I will admit that 
> reference, dated 2003 is rather old).  Also, px are listed as relative 
> units in the CSS2 specification [2]. Since user agent support for 
> different font sizing mechanisms seems to vary greatly and change over 
> time, I'm not sure we should be making a specific recommendation. 
> 
> [1] http://www.w3.org/QA/Tips/font-size
> [2] http://www.w3.org/TR/REC-CSS2/syndata.html#length-units
> 
> 
> Becky Gibson
> Web Accessibility Architect
>                                                        
> IBM Emerging Internet Technologies
> 5 Technology Park Drive
> Westford, MA 01886
> Voice: 978 399-6101; t/l 333-6101
> Email: gibsonb@us.ibm.com
> 
> 
> 
> 


-- 
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>

Received on Wednesday, 15 November 2006 16:12:08 UTC