- From: Vadim Plessky <lucy-ples@mtu-net.ru>
- Date: Tue, 11 Dec 2001 15:18:36 +0000
- 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. | Correct. | 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: <html> <body> <p>Hello, World!</p> </body> </html> try it in MS IE (windows), Netscape/Mozilla (windows, Linux), Konqueror (Linux) and Opera (windows, Linux) - and you will always have *different font size* 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 Microsoft). 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 it) | | >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 necessary. | | --Kynn Cheers, -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/
Received on Tuesday, 11 December 2001 07:26:03 UTC