mac at macnewbold.com
Tue Jun 6 14:30:14 MDT 2006
Today at 8:43am, Tyler Gee said:
> This means you are not writing pages correctly. Your containers
> should be logical place-holders and every single item on your page
> should have an ID and a CLASS attribute.
Having an ID is a good thing, I agree, if you need to apply css rules
specifically to that one element. Classes aren't required, and there can
be more than one, and are great where you want to label multiple elements
as belonging to a certain group that gets the same stylings. I make copius
use of classes in all my pages.
> In this way your page has a
> logical markup and who cares (in the abstract sense) what your
> appearance looks like, because that will inevitably change. Once you
> have "marked up" your page with tables you have just created a page
> that is tied into your current design flavour-of-the-month. What
> happens three months down the line when a client comes and says,
> "Never mind, I want it to look like X" Well, with your table data it
> means you need to literally re-write the whole thing. You have zero
> separation of content and design. This is a bad thing.
You don't need to rewrite the whole thing. You need to move around a few
tr's and td's perhaps. But the majority of the content can stay the same
except where the new look requires changes to it. HTML and XHTML convey
structure of a document, and sometimes when you change the look, you're
not just changing visual stylings, you're changing actual structure of the
document, so changes to the HTML tags should be expected in that case.
If you're using CSS at all, I'd say that you have some separation of
content and design. Some is generally better than none,
Separating content and design, and similarly, separating logic and
content, are great things when used in moderation. Just as it is possible
to have far too little separation between them, it is also possible to
have far too much. To maximize efficiency, you need to balance the two.
This applies to XHTML vs. CSS, to PHP vs. HTML, to any kind of templating
(pure PHP, Smarty, or any other kind), and even to separation of code into
different files. If you separate it too little, you can create artificial
linking where no real link actually exists, where things are in the same
file but don't really have any need to be. If you separate it too much,
you've got to make changes in many more files than you normally would, by
splitting things that are truly linked across poorly chosen boundaries. I
personally feel that the consequences of separating too little are much
lower generally than separating too much, but I digress. When you separate
just the right amount, you minimize the interface between the two parts,
and are able to efficiently reuse code (i.e. via include() etc.) and you
can maximize the variety of changes that affect only one file rather than
two or more files.
So if your goal is something like CSS Zen Garden, where _everything_ is
controlled via the style sheet, and you can change the entire look of your
page by the CSS, then I would argue you're not gaining as much as you'd
like to think. Yes, you've separated things quite thoroughly, but at the
same time, you've just traded a few HTML tags for a few CSS declarations.
It is arguable whether you eliminated more HTML or bloated by more lines
of CSS, and it varies from case to case. I don't know why, but most of the
XHTML/CSS "purist" sites that I've examined closely have an incredible
amount of bloat in their CSS in order to make things look like they want.
I strongly dislike the way that some people insist on completely rewriting
the way certain tags lay out in a browser, like turning block elements
into inline or vice-versa. You can make a div work just like a paragraph,
but why do that instead of just using a paragraph? You can make a list and
its elements work lay out side by side, like columns in a one-row table or
a list of floated divs. There are much easier ways to get the result you
want than by perverting the default renderings of the tags to make one
look like another. I don't buy many of the arguments about "semantics" in
what should be a <p> vs. a <div> vs. a <ul> vs. a bunch of <td>s. There is
usually more than one "correct" way to mark up a document.
> If, on the other hand, you had a properly marked up and standardized
> website, you could tell your designer to come up with something new
> and all they have to do is give you a new style sheet. Voila! You
> can sit in a meeting and load one style sheet, see how it looks, and
> then load another, without changing a single item on your .html page.
> Hell, it means you can even have the same page look different for
> different people based on their login permssions.
I'd be willing to bet that most of the time when you take a reasonably
complex document and mark it up as best you can to prepare for major
design changes, but without knowing what specific changes will be
required, that you still end up changing the markup and content around to
make it work right.
The other thing to consider is the time it takes to build something vs the
average time it would save if and when changes were required. If you spend
5 extra hours preparing a site for potential changes that are 10% likely,
and your work would save you 15 hours, then your 10% chance of saving 15
hours is really only worth 1.5 hours of extra work, and you spent an extra
3.5 hours doing prep work that will most likely never be used. Other
considerations, whether you're working for an employer or a client, are
time to delivery and the cost of the extra time. Despite your personal
feelings, the best business decision is to give the client/employer the
information about the alternatives, and let them decide whether the chance
is worth the cost to them, or whether they'd rather save the time and
money now and avoid costly changes later.
As nice as it is to have sites ready for major changes at any time, in my
experiences on probably hundreds of sites now, those major changes very
rarely happen. Over 95% of the sites we've done over the past 5+ years
have not undergone major redesigns at all. I can think of 4 or 5 major
redesigns. In those cases, they often were not just redoing the design,
but were also changing content too, so it was mostly a while new site
anyway. Thus my bias in favor of getting it done quicker and at lower cost
instead of building in flexibility that generally goes unused.
> The http://www.csszengarden.com example that someone sent in the other
> thread is a great example. There is absolutely no way you could
> accomplish the same thing with tables controlling your layout or
> without proper XHTML+CSS design.
Agreed. I question the utility, or at least the necessity, of such utter
and complete flexibility, but you've made your point.
> You absolutely always want to separate your logic from your design.
> It is hard to think that way when you are a one person team, but once
> you are a web developer, working with a web designer and a graphic
> artist, it becomes quite clear that your job is to develop the page
> and you don't need to care at all what it looks like, you only need
> worry that it is properly marked up. It is the designer job to make
> it look good.
See also my comments above about balancing too little separation with too
much separation. In all the stuff we've done, we've never really worked
with a graphic designer that was able to handle building cross browser
CSS/HTML, with the single exception of Wade with whom we worked on a
project or two. We've always been the ones doing the PHP/MySQL code as
well as all the CSS/XHTML. The designers have always just handed us a
design, and sometimes some ready-to-use images, and it is up to us to
implement and maintain it. So in our world, there's never been a strong
incentive to do a whole lot of separation. So we separate where it makes
our lives easier, and don't where it doesn't.
Look good is important, but work good is important too, both in regard to
backend code and with regard to how the HTML renders in the various
browsers as the content changes (i.e. dynamic or db-driven fields) and as
the screen size or browser window size/shape changes. That is why I lean
so much toward fluid designs: they usually offer a little less control
over certain specifics of what my pages do, but in return, they offer a
simple and powerful way to make pages look good in a much wider variety of
Wade: Regarding "you need to tighten up a bit", that's something I rarely
hear, since most people think I'm already pretty tight... ;)
(My other bias for fluid pages is that I really like being able to choose
what size I want my window to be and having a page/site usefully take
advantage of the extra space I offer it. Pages with a fixed width of 800
pixels or less are really annoying when you'd rather give them more width
and not have to scroll as much, or be able to see more on one screenful.)
Mac Newbold MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com http://www.macnewbold.com/
More information about the UPHPU