in reply to
Do good Perl practices carry over to other coding?
my bias may be significant, but i write clean XHTML and CSS for many of the same reasons that i try to write clean Perl.
when approached correctly, semantic, straightforward XHTML using CSS for presentation increases the reusability of the different pieces (XHTML can be parsed and transformed with standard XML tools, CSS can be seperated from the content and re-used across the site or changed without having to touch the XHTML or the code that generates the XHTML), improves accessibility, makes maintenance easier (wading through nested tables is not my idea of a good time), and is faster to write once you've gotten out of the tag-soup mentality. and there really is no reason that you can't make it work in older browsers. if you have a nice, semantically marked up document, it should display in Mosaic or Lynx just fine (usually better than the tag-soup version). with an @import hack, you can keep the CSS rules that break NN4 from doing any harm.
also, don't underestimate the usefulness of a validator. if you're trying to fix a layout bug, running the markup through a validator and fixing any errors it shows you should be the first step. often, making things validate will magically fix whatever problem you were having. i consider using a validator the equivalent of use strict; for HTML.
that said, i also make use HTML::Template to keep all that seperate from the Perl code. the more layers, the better. with a proper setup, most layout changes can be made just by tweaking the site-wide CSS file. occasionally some frontend changes require touching the templates. and only changes to the actual application logic involve editting the Perl. (and there are probably other layers for the business logic and data persistence, etc.)