W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2001

Re: Guideline 3.4 comment (ralative vs. absolute units)

From: Vadim Plessky <lucy-ples@mtu-net.ru>
Date: Tue, 11 Dec 2001 15:18:36 +0000
Message-Id: <200112111224.fBBCOKH13981@post.cnt.ru>
To: Kynn Bartlett <kynn-edapta@idyllmtn.com>, w3c-wai-gl@w3.org
On Monday 10 December 2001 20:43, Kynn Bartlett wrote:
|   WCAG working group -- whose job is it to respond to these?  I have a
|   response below, which I have written and sent to you, but not to the
|   original querent, since I'm not sure what our protocol is on responding.
|   At 11:09 PM +0000 12/10/01, Vadim Plessky wrote:
|   >I have a comment on guideline 3.4 of WCAG 1.0
|   >http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation
|   >[...]
|   >IMO this is really wrong.
|   >You can design web page which doesn't use text at all (pure
|   >formatting/presentation purpose), like:
|   ><html>
|   ><style type="text/css">
|   >   div { border: 10pt solid blue; background: silver;
|   >          width: 100pt; height: 80pt }
|   ></style>
|   ><div></div>
|   ><body>
|   I'm not sure I understand the purpose of such a page, though; for what
|   is it intended?  Is this to put a silver box with a blue border on
|   the page?  If so -- is there any particular meaning associated with
|   it, or is it just a blue box of a particular size?

It was some stripped CSS testcase from my CSS Test Suit.
I used it to demonstrate limitations of CSS2 specifications (and to get 
things fixed for CSS3: BOX MODEL module)

Besides, I often use such constructions (but with text inside) for testing 
CSS: float, display: inline, block, inline-block properties (different 
layouting techniques)

As about "particular meaning associated with it" - I can imagine Traffic 
Light simulator using such example (ok, lights will be square, not circles)
You can *change lights* via JavaScript/DOM of using a:hover class .  

|   >Using 'em' for defining width/height iof DIV element here is really
|   > NONSENSE - as *there is no font used in that page at all*.
|   That's incorrect, as a default font is always defined in CSS, and
|   should be based upon the user's default settings.  Is there some reason
|   the size of the box should not be relative to the rest of the
| presentation? 

Of course!  It's up to author to define box size.
If I created document in word processor, and it's A4 size - expected 
rendering of such document exported to HTML is A4-size page.

| The user may have chosen, for example, to increase the font
| size to some large number.

yes, but it's up to userAgent (browser) to increase font size - or decrease 
A4 page to fit on 1024x768 screen.

|   >Besides, you can't use percentage here - as you never know what is the
|   >browser's screen width (especially if you you XHTML basic - as <script>
|   > is not supported in XHTML basic, you can't get screen.width and
|   > screen.height.
|   What kind of application do you envision in which the exact size is
|   necessary and cannot be provided in percentages or em units?

as I mentioned above, think of HTML Export filter for word processor.
IIRC you define font size for each paragraph/style in _points_ (pt), not in 
terms of "bigger" or "smaller"

|   >If there was something wrong in using 'pt' or 'cm' in CSS definitions -
|   > than 'pt' and 'cm' could be just excluded from CSS specifications. As
|   > they are present in CSS1/CSS2 - there is nothing wrong in using them.
|   This isn't necessarily true -- there are many things you can do within
|   the context of the specifications which may lead to accessibility
|   errors.  They are allowable via the spec (CSS, XHTML, whatever) but
|   they can produce inaccessibility for many users.


|   However, this may be a point in which the techniques should be
|   clarified -- "pt" or "cm" should be acceptable within certain media
|   types (for example, setting a left page margin to 2 cm in print
|   media).  This is implied in the techniques document for CSS at
|   http://www.w3.org/TR/WCAG10-CSS-TECHS/#units

My concern here is compliance to Priority 2 checkpoint.
I use 'pt' on my web site (http://kde2.newmail.ru) and frankly speaking have 
no problem with it.
I believe most of my web site is pretty well accessible, and want to redesign 
it slightly (to be compliant with Triple-A or Double-A).
But I have no intention to get rid of 'pt' font sizes. It's part of my  
original design ;-)
So if we can't agree that using 'pt' is complaint with Priority 2 checkpoint 
for Guideline 3.4, I will postpone redesign of my site until we will be able 
to come to common conclusion. :-))

|   >Besides, using 'pt' (instead of 'px') is the only way to get font size
|   >*right* - and current CSS specification *doesn't recommend* using
|   > 'smaller' or 'bigger' - as these properties are device-dependant, so
|   > using them you limit your page portability and possibility to view it
|   > on different kind of devices.
|   The problem is that a desire to "get font size *right*" implies a desire
|   to override the user's preference for default font size. What makes you
|   think that "smaller" or "bigger" are device-dependent?  Font values of

simple example:
<p>Hello, World!</p>

try it in MS IE (windows), Netscape/Mozilla (windows, Linux), Konqueror 
(Linux) and Opera (windows, Linux) - and you will always have *different font 
When I select '12pt', I get much better results - but of course not perfect, 
due to brokeness of dpi settings on Windows (bug report should go to 
I know this subject quite well, as I was studing different dpi handling on 
all major platforms (we were fixing DPI / font sizes issues in 
KDE/Konqueror/Kword, and that was not easy task...).
|   "smaller" or "bigger" do not limit the portability of a page; they
|   encourage it, more than explicit, fixed font sizes set with "pt".

I can't agree with you that *fixed font sizes* set with "pt" reduce usability.
They *improove* it, as they allow to overcome shortcomings of several 
widely-used platforms (Microsoft Windows, in particlular) or wrong settings 
(many XFree86 servers set in a wrong way, RedHat user have many complains on 

|   >Therefor, I suggest that Guideline 3.4 should be excluded from WCAG 1.0
|   > (or latest WCAG 2.0). If it's already done in Errata, please let me
|   > know URL of that Errata - so far I was not able to find any correction
|   > for this GL.
|   Why do you think it should be excised?  Without such a guideline, users
|   with visual disabililties who need to change their default font sizes may
|   not be able to do so.

To my best knowledge, font sizes are really up to userAgent (browser) and 
default stylesheet.
You always can override default settings with CSS !important property, when 

|   --Kynn


Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
KDE mini-Themes
Received on Tuesday, 11 December 2001 07:26:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:39 UTC