[UPHPU] Validation

[Mac Newbold]

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 
situations.

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.)

Thanks,
Mac

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/