- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Thu, 11 Oct 2001 22:02:44 +0200
- To: w3c-wai-gl@w3.org
Hi, some comments on http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20010716/ | 1 Author benefits | | * Increases consistency. | * Decreases maintenance. | * Separating markup for content from markup for presentation | decreases clutter of markup. | * Able to create dynamic decorative effects. There is somewhere at w3.org that tells about the benefits in more detail, for example it mentiones, that CSS speeds up the web, since you only have one ore more style sheets that can be reused throughout a site. | Where style sheets have been optional to display HTML content, | they are required to display information from XML | applications. The document is about *Web* content, delivering so-called Any-XML to webbrowsers is harmful in accessability terms, since most authors won't specify e.g. aural properties for the documents and user agents don't have a chance to recover from that. HTML and XHTML on the contrary come with built-in accessability. This document should not imply that it might be a good idea to deliver Any-XML to web browsers and formatting them with CSS. Rely on well-specified document languages like HTML and XHTML is you want universal access and accessibility. HTML also comes with a lot of features that cannot be expressed using CSS, consider the link element. | Therefore, the differences between CSS for XML and HTML are: | * define styles for elements and attributes (including class | if that is defined in the language), How does the browser now about the class attribute if the document language isn't known to the browser? | * style information is usually required to be in an external | style sheet (always?), Yes, currently always. However, RFC 3023 (the XML media types) might get updated to rely on XPointer for fragment identifiers, if so you may use something like <?xml version='1.0'?> <?xml-stylesheet href='#xpointer(id('stylesheet'))' type='text/css'?> <!DOCTYPE myDoc [ <!ATTLIST s id ID> ]> <myDoc> <s id='stylesheet'> s { display: none } </s> <!-- ... --> </myDoc> | To apply the same external style sheet to both HTML and XML | * make the HTML class names the same as the XML element | names, | * define each style twice: once with a period (HTML class | name) and once without (XML element name). e.g., | .copyright, copyright {font-size : .5em} This should be Write an XSLT transformation sheet to transform you XML document to XHTML | 2 User benefits The only benefits, if he knows the document language as well as the author, otherwise it is impossible for him to create a user style sheet since he doesn't know what selectors to use, thus XML+CSS => user has no benefits. | In CSS2, if a user's style sheet contains "!important", it | takes precedence over any rule in an author's style sheet. If declaration contains "!important" and it takes precedence over other declarations, not over other rules. | This is different from CSS1, where the author always has final | say over styles. For more information on the !important | selector refer to the CSS1 and CSS2 specifications. Also, note | that since !important was introduced with CSS1 and is more | widely implemented than CSS2, the author might have preference | over the user in most of the existing user agents. However, it | seems that !important is rarely used in author style sheets | and therefore might work as defined in CSS2. Hm, I'm using !important, but it's actually a pain to append it to each rule. I've proposed a new @important rule for CSS 3 to make this more convenient for users. | * If you must use HTML elements to control font information, | use BIG and SMALL, which are not deprecated. Valid reasons for using HTML to control presentation are...? | <STYLE type="text/css"> | P.important { font-weight: bold } | P.less-important { font-weight: lighter; font-size: smaller } | H2.subsection { font-family: Helvetica, sans-serif } | </STYLE> I recommend to use XHTML compatible syntax for both, HTML and CSS, thus lowevercase element names and lowercase type selectors. | 2 Colors | | 2.1 Color Contrast | | * Use numbers, not names, for colors. | | Example. | | Use numbers, not names, for colors: | H1 {color: #808000} | H1 {color: rgb(50%,50%,0%)} | | End example. | | Deprecated example. | H1 {color: red} | | End example. I've asked a year or so ago why this should be a good idea. Actually color names map 1:1 to RGB values. To me this guideline is just nonsense. | Use these CSS properties to specify colors: | * 'color', for foreground text color. | * 'background-color', for background colors. | * 'border-color', 'outline-color' for border colors. ... for border and outline colors. | * For link colors, refer to the :link, :visited, and :active | pseudo-classes. Also to :hover. | Quicktest! To test whether your document still works without | colors, examine it with a monochrome monitor or browser colors | turned off. Also, try setting up a color scheme in your | browser that only uses black, white, and the four browser-safe | greys and see how your page holds up. Finding a monochrome monitor is a rather hard task. A better quick test would be to use an additional style sheet that overrides colors (and probably other) settings. Bert Bos and Michael Narath created such style sheets, they actually were developed to emulate the browser Lynx. This document should provide such a style sheet for quick tests. | 3 Units of measure | | Think about what needs to change in size and what doesn't. | Raster images, for example, have fixed width and heights. | We specify them in the img tag in pixels... It's the 'img' *element*, please refer to the SGML introduction in HTML4 or the XML 1.0 recommendation for the correct terms and their explanation. | Similarly, if I | just want to move the text away from the border of the | page, setting the padding on the body to 5 px shouldn't be | a problem. Text, on the other hand, should always be free | to change size (a good reason not to use text in images). | But when my text doubles in size, do I need the gutter next | to it to double in size as well? Probably not. In fact, | doubling the gutter might even decrease the usability of | the page. A good recommendation would be to use Scalable Vector Graphics for, well, scalable images. You can also define height and width for images with the em unit. This wouldn't look too nice, but it's a possibility. | Charles Munat - 6 May 2001 | * Use "em" or % for properties that need to change: smaller, larger are also fine, as should be x-small, xx-small and so on, font size keywords in short. They are however not implemented as expected in IE 5, IE 6 in strict mode fixes this. There is an article by Todd Fahrner on alistapart.com how to make those keywords work anyway in IE 5. | * Use px for properties that do not need to change: | + height and width of raster images, | + margins, | + @@create exhaustive list. any exceptions? That's a bad suggestion, margins with percentages or em's work quite well. Pixels are only useful for data already expressed in pixels, i.e. only raster images, raster videos, etc. | Example. | | Use em to set font sizes, as in: | H1 { font-size: 2em } | | rather than: | H1 { font-size: 12pt } | | End example. This example doesn't consider different media, using 'pt' for printing is fine and recommendable, pt however, doesn't apply to screen display, since authors don't know the actual metrics of the output device. In general the choice for relative units vs. absolute units depends on the authors knowledge on the output device. | Example. | | Use relative length units and percentages. | BODY { margin-left: 15%; margin-right: 10%} | | End example. Shouldn't pixels be used for margins? ;-) just kidding. | Example. | | Only use absolute length units when the physical | characteristics of the output medium are known. | .businesscard { font-size: 8pt } Exactly. | 5 Text instead of images | | Content developers should use style sheets to style text | rather than representing text in images. Using text instead of | images means that the information will be available to a | greater number of users (with speech synthesizers, braille | displays, graphical displays, etc.). Using style sheets will | also allow users to override author styles and change colors | or fonts sizes more easily. This document should consider e.g. SVG, text in SVG is actually text, but SVG images are images. What to do if you use SVG in HTML documents? | 6 Text formatting and position | | The following CSS2 properties can be used to control the | formatting and position of text: | * Indentation: 'text-indent'. Do not use the BLOCKQUOTE or | any other structural element to indent text. Blockquote has been abused to indent blocks, not to indent text. Use margins instead of blockquote would be a better guideline. | * Letter/word spacing: 'letter-spacing', 'word-spacing'. For | example instead of writing "H E L L O" (which users | generally recognize as the word "hello" but would hear as | individual letters), authors may create the same visual | effect with the 'word-spacing' property applied to | "HELLO". Text without spaces will be transformed more | effectively to speech. Hm, shouldn't 'text-transform: uppercase' be used here, too? | * The :first-letter and :first-line pseudo-elements allow | authors to refer to the first letter or line of a | paragraph of text. | | The following example shows how to use style sheets to create | a drop-cap effect. | | Example. | <HEAD> | <TITLE>Drop caps</TITLE> | <STYLE type="text/css"> | .dropcap { font-size : 120%; font-family : Helvetica } | </STYLE> | </HEAD> | <BODY> | <P><SPAN class="dropcap">O</SPAN>nce upon a time... | </BODY> Hm, this example is deprecated, isn't it? | Note. As of the writing of this document, the CSS | pseudo-element ':first-letter', which allows content | developers to refer to the first letter of a chunk of text, is | not widely supported. Now they are. | 8 Generated content | | * Provide a text equivalent for any important image or text | generated by style sheets (e.g., via the | 'background-image', 'list-style', or 'content' | properties). Don't put important information in there. For example, background-images might not be printed on paper, thus it's a very bad idea to include information there. | Example. | | DIV.example:after { | content: End Example | } This example is invalid, 'End' and 'Example' are parsed as keywords and those keywords aren't valid, you must use a string here, i.e. content: "End Example" | 10.1 If you must use images as spacers You don't have to. Don't give authors the impression there are valid cases where they need "spacer" images. | 11 Using absolute positioning accessibly | | Example. | <head><style type="text/css"> | .menu1 { position: absolute; top: 3em; left: 0em; | margin: 0px; font-family: sans-serif; | font-size: 120%; color: red; background-color: white } | .menu2 { position: absolute; top: 3em; left: 10em; | margin: 0px; font-family: sans-serif; | [...] This example is just horrible. To recommend something like this really isn't a good idea. -- Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de 25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
Received on Thursday, 11 October 2001 16:03:52 UTC