Potentially overlooked CSS tips

A friend of mine who does vids just bought her first set of CSS primers and plans retooling her website. In honor of her recent birthday I'll pass along a wordy but useful set of tips. If she values the observations of three years dancing in landmines, she'll pay attention.

Prologue: in 2002, I started an unrequested skunkworks project of redesigning a tables-based, JavaScript-rollover-infested, accessibility hobbled website from HTML4 to XHTML/CSS. The next year a formal call for a makeover was requested and my R&D was implemented; the results of that redesign are the Cline Library website. Links below to the current 2005 revision:

• Home page
• Colorado Plateau Digital Archives Search
• Special Collections and Archives Colorado Plateau
• Find Articles

These are mentioned not to show off, but because the tips refer to them. I did not design this layout, merely made it CSS based and SSI constructed. And now, the tips.

CSS Padawan 101:

• It's natural for a beginning CSS developer to wrap everything in classed DIVs/SPANs, and to overdo it. Over time, reexamine your code and look for places where specificity would do the job better with less code. Where my pages seemingly diverge from this advice, it's because of complex inheritance issues: list elements on the newblue homepage behave in sometimes radically different ways depending on their section and purpose. The choices are to stick class attributes on all of them (revisiting the HTML4 formatting tag soup and lengthening the page code) or to wrap them in DIVs with IDs which guarantee separate behavior.
• DTDs matter when it comes to how browsers treat your CSS. Even if you're a diehard HTML 4.0 enthusiast, leaving out any DTD ensures browsers play in 'quirks mode,' a genteel euphemism for 'browser regresses to flaws of previous major version.' I favor XHTML 1.0/Transitional as a good place to work from.
  
• DTDs affect more than just CSS. Older DHTML JavaScripts manipulate object size/position values with unit-less integer values (e.g. 'property.style.top=300' instead of 'property.style.top=300px'). Just as you can't do this with CSS values in the presence of a DTD, IE is appropriately fierce about throwing errors in JavaScript when an XHTML/Transitional DTD is present and units are not, and older scripts may have to be rewritten. Better solutions are to find more current, DOM-friendly versions/alternatives or dump JavaScript altogether.
  
• An XML prolog will bork the DTD in IE 6. Get rid of it. If your HTML editor automatically inserts an XML prolog at the top of the file, IE 6 will ignore the DTD below it and throw your browser into quirks mode. This didn't matter with the first layout when IE 5 was king, but it matters plenty with newblue: this 3-column liquid layout is a simple bit of CSS, but in quirks mode IE 6 reverts to pretending it's IE 5 which never understood that simple bit of CSS. Until all mainstream browsers expect websites to be served as XML with an XML MIMEtype, that XML prolog is useless and delete it. Even the W3C validator doesn't balk at its absence.

Browsers:

• "It works in IE" is a terrible fucking excuse for anything. I test against several browsers knowing full well their combined marketshare is less than 15% of our users(although it's a growing share), because coding to standards is a smaller headache longterm than coding to browsers. From experience I speak, padawan. In order for IE 7 to get through this they will have to rewrite a lot more of their renderer than I think they have the will, brains or balls to do.
  
• Opera isn't the yardstick it used to be on web standards. When they entered the business they made themselves felt as a company more concerned with standards than IE emulation: their insistence that the correct alternative to BODY MARGIN="0" is body{padding:0px;} rather than the {margin:0px;} all other browsers use is still the case with Op8. OTOH Firefox is killing their marketshare outside embedded and certain niche markets, and their product which once had IE UA spoofing as an option now defaults to it, and more critically, slavishly imitates IE's default HTML rendering and proprietary JavaScript properties. They took being shut out of MSN hard. Don't get me wrong, it's still a damn fine browser, with probably the best accessibility integration for Windows (and free integration at that), but at this point the best their fans can say is "Look at the beautiful pluma--er, mouse gestures!" It's still important to test against, since they still claim to use the same render engine in all their products (including embedded).
• Mozilla/FF/NS isn't God either. Form elements like buttons and checkboxes should be resizable, colorable, etc. with CSS, and IE gets it. The Gecko engine does not. But as of this writing it's still the first place to test modern technologies like CSS2.
  
• No matter what Apple tells you, Safari and KHTML (Konqueror) are not interchangeable terms. Safari relies more and more heavily on WebKit technology which is not open source, and Dave Hyatt is unapologetic about it. Major improvements in either product's renderer should appear in the other eventually, but only if they're in the KHTML portion. Speaking as someone who uses Konqueror, it's an excellent file browser. As a Web browser, it's an excellent argument for bundling Firefox in Linux distros. And no matter what the Safari user-agent string says, KHTML is NOT "Gecko-like." The Apple tech who put that into Safari is part of the witless protection program now.
• Current screen readers do not respect 'media=' attributes. This means that the content you meant to hide from visual browsers using display:none; in a stylesheet aimed at media="screen" won't get spoken in aural browsers either, even if you have a separate aural stylesheet overriding the selector. Those of us who deal with the vendors of these "solutions" are livid that the one sole attribute in HTML meant for their consumption and processing is ignored, and we fervently pray Freedom Scientific finds itself sued by the Australian/British courts for flouting it. It's not much of a secret that FS is run by Visual Basic hackers cocksure that Microsoft will buy them out and integrate it into Windows. Again, visibility:hidden means "render a blank space the same size as the content." Display:none according to W3C specs actually means "remove content from HTML stream" (although not the DOM).
  
• Lynx is not a bad choice for crude accessibility testing, and it's still a decent choice for mobile device testing.
  

• Just as you're being told to avoid using fixed (e.g. px) units for fonts, consider eliminating them for paddings and margins on a case by case basis. Page margins are a good place for fixed units; paddings between LI elements are not, no matter how many years of Microsoft word stylesheet have told us (then again, we never had scalable units as an option). Ems make good neighbors.
• This is old hat by now, but Navbars should be the bottom of your HTML document. People with screenreaders detest hearing them repeated at the beginning of every page, and skip links are a holdover from purely linear HTML rendering. Moreover, people reading your site on mobile devices will thank you for putting content first. All the above examples on our site use absolute positioning to move the navbar where the sight-unimpaired expect it (top and/or left). BION, there was a time when this technique was considered controversial.
  
• CSS hacks suck for several reasons. First, they presuppose that the parsing errors they exploit will not be patched inside a major release. Secondly, they screw with validators. Thirdly, they screw with integrated web development packages which treat CSS files as valid data structures. Most serious IE hacks are aimed at IE 5.x problems, and local/national stats on 5.x usage are somewhere around that of Netscape 4 users. Pages should degrade gracefully, but if they can't because one end-of-life browser has a seriously broken model, cut your losses.
  
• IE and Opera arbitrarily default to sizing the text inside text-based form controls at 85% the container font-size whereas Gecko and others use 100%. This means that if those form elements have padding defined in scalable units (ems/exes) that spacing is calculated on the size of the text in those elements, not the parent container's. Without devoting three paragraphs to explain why, it's a good idea for accessibility and consistency to formally declare INPUT,SELECT {font-size:100%;} if you plan to design CSS form layouts which gracefully scale for visual disabilities. Trust me on this one.
  
• Join css-discuss. It's as much for n00bs as pros, and you'll get exposed to some cutting-edge stuff. Before you know it, you'll be helping people, too.