CB's fireplace

cooperative blog

team

Home » Archives » January 2005 » code: style, content, and layout.

[Previous entry: "Gosh, I feel safer already"] [Next entry: "And speaking of CSS"]

01/28/2005: "code: style, content, and layout."


CB,

I want to start a fresh discussion.

First, apologies for being impatient with your coding challenges. My intent is to instruct, not to judge, so let me take this opportunity to refocus on that goal.

Second, I believe I can hand you the key to a door, that when you pass it you'll enter a world that vastly exceeds your expectations in terms of a) ease of obtaining results you want, b) range of available options, and c) efficiency of operations.

Third, I think we are somewhat distracted by discussion of standards and compliance. It's interesting, and necessary, but I believe it is ultimately tangential to the real issue for webmasters.

Those are my premises, and I intend to go about winning your mind to my way of thinking (at least in the slice of your mind that is occupied with making web pages). If I retrace some steps along the way that seem to be basic knowledge, then forgive me, I'm only trying to address the topic comprehensively, not to impugn your knowledge or abilities.





I am a lazy bastard. Maybe the laziest one you'll meet. I am so lazy that if I do a task more than twice, I'm thinking about how to automate that task. With woodworking, I build jigs. With code (not HTML, but proper programming languages) I build libraries of my own function calls. To move large boulders, I employ a lever.

So you might ask, how does a man who has embraced laziness make web pages? The answer: effortlessly. ;)

Of course it's the mechanics behind that answer that are of interest. Even if you don't aspire to scale the summits of slackness, there's merit in the lazy man's approach. Put simply, it's less work.

I know you're rubbing your palms together feverishly, waiting for me to start dropping specific advice right now, but indulge me please as I outline my ontology--linear's lemmas of laziness.




linear's zeroth lemma of laziness: "embrace your laziness." Laziness is a virtue. Productivity is a simple quotient--work over time. Minimizing time is easier than maximizing work. The cliche gets it right: work smarter, not harder.

linear's first lemma of laziness: "let machines do the tedious stuff." Automation is essential in the lazy man's toolkit. Programming languages are the modern man's lever, screw, and inclined plane.

linear's second lemma of laziness: "automation that gets you part way there isn't useful." Pardon the Americanism, but go whole hog. If there's more than one frequent task your tool can't handle, then get (or make) a better tool.




Okay, now that you see the world through my eyes (at least a little), let's discuss why I use Greymatter. It does well at a short list of things which are essential functions of a well-run web site:


  1. it maintains a site structure

    1. it generates links among pages programmagically
    2. it has an inherent URI scheme (which you may or may not like)
    3. it creates index pages for you from your content

  2. it facilitates the separation of presentation and content (templates)

    1. templates enforce a consistent site-wide appearance
    2. templates allow you to edit page appearance factors without disturbing the content (easier site-wide maintenance)

  3. it manages your collection of content

    1. adding and editing entries
    2. very crude sorts of facilities for constructing alternative indexes

  4. it remains markup-neutral

    1. other than configurable line and paragraph separators, it doesn't rewrite your content
    2. consequently it is technology-neutral, enabling php, asp, jsp etc. pages

  5. it facilitates user interaction

    1. comments
    2. karma


I don't think that list of five functions is the complete recipe for a well-run web site. But those are the fictions that GM will automate for you, freeing you (mostly) from concerning yourself with the implementation details. So "out of the box" it provides a great deal of value to a webmaster who would prefer to spend time focusing on writing interesting articles versus tweaking markup. In most cases, the templates get tweaked more or less extensively up front, then left alone for long periods of time.

So GM by itself is good. But add in CSS and things get markedly better. CSS aims like a laser at function number 2 above. More precisely, a focused user of CSS can use the tools it provides to tackle number 2 in a flexible, powerful, and efficient way. The efficiency comes from factoring, the power and flexibility are inherent to CSS.




So what is factoring and why is it so important to the lazy webmaster? Recall the first lemma: let machines handle the tedious stuff. Consider briefly a typical blog index page. It comprises several entries, possibly each authored by different individuals. Each entry contains common data elements, such as the date, subject, and author name. Efficient automation should ideally allow for the consistent presentation of the entries on the page, both the data and the metadata.

Since the index page comprises multiple entries, the data and metadata elements will always repeat. So in the case where the designer (or webmaster wearing a designer hat) decides that the post date should appear as "large blue arial, right justified" she then must make an implementation decision. Should the appearance be manipulated using GM templates, or with CSS? Let's work this example both ways, and hopefully illustrate the affinity of lazy people to CSS.

case 1:
The template markup-based approach would go something like:
<font face="arial" size="5" color="#0000ff"><p align="right">
{ {monthword}} { {dayappend}} { {yearyear}}
</p></font>


That's 74 bytes of markup. And it needs to be repeated 10 times for our hypothetical blog index page, giving 740 bytes. Changes would be managed in the GM template editor, followed by a site-wide rebuild, then reloading the page to see the effect.

case 2:
The lazy approach is to (this is the keystone idea here, pay attention) label the chunk of text with a descriptive identifier that gives you a clue to its function or meaning. So the lazy approach is:

<p class="entrydate">
{ {monthword}} { {dayappend}} { {yearyear}}
</p>


then a rule in the stylesheet:

.entrydate {
font: 120% arial;
color: #00f;
text-align: right;
}


That's 74 bytes of stylesheet, and 29 bytes of markup. But now we repeat our 10 entries, and we get 364 bytes (10*29 + 74) to do exactly what we did in twice the bytes above. The immediate side benefit (and probably a bigger deal than the bytecount) is that now I've labeled all the occurrences right in the code, making them very easy to find while viewing source. The label is also human-readable, and semantically meaningful (although that's a discipline--nothing stops you from setting class="bigblue" either, which is semantically void).

Okay, that's the first level of factoring, and it helps. But CSS has more tools. Note that if we keep stylesheet info in the header (like the defaults, and like your current template set), we still have to rebuild all files to see the change. That clearly sucks.

But, once again, factoring to the rescue. With CSS style information in the head of every page (via the header template), there's a lot of identical information repeated. Luckily, CSS can be factored out into an externally referenced page.

<link rel="stylesheet" type="text/css" href="/path/to/stylesheet.css" />


This is sort of the ultimate payoff--since this is factored, but referenced on every page of your site, the client browser will cache it separately. That's the first benefit. The second is that in order to change every page in your site, you now need only edit this single file. Changes appear to immediately take effect, since the browser will see the newer file and invalidate its cached one.




Oh the joy in the heart of the designer as she twiddles the stylesheet and sees immediate changes on the page. Every page. It's positively glorious. Elegant even. In this world, the markup serves to describe the content, and relate it to the stylesheet which then styles it.

Some more specific illustrations of the power:

  1. not only presentation, but layout is controllable though CSS. So you can have elements adjacent in the code which are not adjacent on the page (very desirable for adsense publishers, who would like the ads nestled up to keywords, not navigation links)
  2. stylesheets can take aim at different media, allowing you to overcome limitations or tailor presentations to certain devices (see this page for more details and examples)
  3. the maniacally lazy (I'm sure someone you know fits this characterization) can even generate the stylesheet via a server-side script, tailoring style to each client based on inspection of the client environment. (e.g. webtv)


Now, let's look at changes. The designer who wanted the date "large blue arial, right justified" last week decides this week it must be "small orange verdana, centered." Lazy old linear just edits one file and it's done, site-wide. Even with GM templates, the old-school webmaster has to find all the occurrences in each template, edit, rebuild, and look for omissions (then correct them). Meanwhile, bandwidth on his busy site soars, since every cached page just got invalidated (maybe more than once). But lazy linear's pages are snug and warm in their caches on clients around the world, even though he indulged the whimsical designer.




Okay, let's draw the curtains on that little drama, and recap what I'm trying to communicate. I'm really not particularly obsessive about correctness or standards-compliance. But oldthink does bug the hell out of me when it comes to markup. I tend to view the fundamental webmaster problem as "do more in less time" and actively seek ways to realize that. I embrace tools that facilitate my laziness. CSS is very near the top of that list.

You may take what you choose from the preceding presentation. Ideally you'll have realized the futility of clinging to font tags. Intriguingly, most of the things you find objectionable about the current layout on your fireplace blog are straightforwardly corrected with stylesheet-only changes. I have not factored out the style from your header template because I can't write files to your server, so I'd lose ability to edit.




Here's some chunks of previous correspondence, with replies intended to be viewed in this new light:

> As Rob reads this, one other thing: When I look at a post which has a
> blockquote within a blockquote and then click the link at the bottom
> right, I get an archive page where the blockquote within the blockquote
> is practically illegible on my PC (LCD screen at 1280x1024). With my
> browser Opera I can easily zoom it, but this should be corrected, the
> percentage for the font should be slightly higher.

Two possible simple solutions exist--

  1. correct the base font size on the entry page (I did this, for consistency with the index)
  2. manipulate the percentage in the blockquote rule font-size declaration.


> I really have other problems now than to
> study these things in order to be able to use them.

Hell yeah. You're making my point for me. Hopefully with this kickstart you'll see how much less work there can be.

> I don't think that I am very much to blame for the
> problems that subsequently showed up.

To be sure, you got bug-bitten. I possibly overreacted to your little table trick, no offense was intended. Hopefully this atones for that.

> One author sends me something in this format, another
> in another or I have to take code from other sites which all use
> different ways to do the same thing.

Yep, there's weird characters bombing the validator. But to recap, I'm satisfied if the templates validate. I can easily make allowances for the contents not validated, as can most browsers.

> I will now go and have a look at the result! Do I need to take some
> Valium first? ;-)

If not then, now perhaps.

> Though I will never understand why this
> superprecise scientific CSS of those W3C eggheads cannot insure that
> spaces between the different posts remain always the same.

It's not as difficult as it seems. Huge clues are in the source. Although I'm not entirely clear if you mean vertical margin or what exactly. The CSS eggheads have given you more comprehensive tools to put elements where you want them than were ever available, so they are part of the solution, rather than the problem.

> But I will
> have to live with this inconsistent sloppiness, I guess. I am too
> pedantic.

No, see it's exactly the opposite--CSS is made just for you because you're too pedantic. But you will have to step through the portal.

> I found very distinctive and nice
> those pics that jumped over the right border.

Actually, it's the use of the table that is making the width flow to the pictures. Ditch the table, replace it with a div of fixed width, and you get your hangover back. Ironic, isn't it?

> I know that I have to live
> with such normalcy. :)

Never.

> Something I absolutely hate and noticed by chance, as I had the good
> idea to also check with IE, not Opera alone: the blog's title (CB's
> fireplace/cooperative blog), under IE is now centered, under Opera (the
> more standards complying one...) it is still on the left just above the
> date. I want it like that.

Well, now you've seen how to proceed. I can help, but perhaps you'd like to take a swing at that yourself.

> You will no doubt understand this.

No, I gave up trying long ago. :D

> now the orange "previous post" line or the "Home >> Archives >>
> January 2005" line, with the increased fonts, look much less good than
> before, not consistent with the general line of rather small fonts, but
> that has to be accepted.

Haha, nothing has to be accepted. Notice the <div class="path"></div> surrounding the breadcrumb navigation? Go directly to the stylesheet, add a .path rule, and manipulate the appearance with declarations to your heart's content.

> It is a general problem with Opera that it
> shows fonts much too large. Mac does just the contrary.

Well, to be fair, the CSS way is not a perfect way, and differences between browser implementations drive CSS designers nuts. (I know you knew they were nuts, but now you also know why.)

> What is not yet changed: In post #17, the two email addresses are no
> links yet.

Yeah, you edited the linkness out of them. If it were returned, they'd be linky-dinky again.

> I see that in config you disabled Auto-link for
> entries? Why that?

It was the problem. You made your edits before I got there.

> I still dislike that, starting with post #9, in those posts that contain
> blockquotes, the text AFTER the blockquotes does not respect anymore the
> required space between the double border and the text.

I dislike that too. It has to do with understanding block-level versus inline elements. The easy-peasy workaround is to drop a <p> tag in at the top of the text immediately following the last </blockquote>. Alternatively, you could remove the padding from the p rule in the stylesheet and apply it to the entry div instead, and you would be putting a more resilient fix in place.

> My <ul></ul>
> looked less elegant maybe (not having the coloured border and background
> and the more precisely determined font through the styles), but at least
> it did not produce such disturbances. Is there a way to change that?

Blasphemer! In fact, you were relying on a browser default stylesheet (that you could neither see nor control). It controlled how <ul></ul> got presented, not you. With a CSS approach, you remain in control of every element on the page that you choose to.

> It
> can of course be that you do not see it like I see it, as you most
> certainly use the very latest browsers which are improved and stick to
> the latest standards, interpret them better.

As noted above, I think the true issue gets lost in that discussion. The real deal is how do you want to run your pages.

> All in all, we are now much further! Thanks to you!

And after this, hopefully much much further. Teach a man to fish, etc. etc.

> Can that not be changed now or maybe in a later release?
>
> A middle initial is something so very American and common that one
> should be able to write it as it normally should be written, with the dot.

I'm pretty sure I can give you a hack to allow it. I have to think about all the implications though, I'm recalling there was a reason for the limitation. Let me test it out on my dev installation first. Remind me if you don't hear back on that.




Okay, that's more than enough diatribe--now go get your hands dirty and embrace your laziness. Make me proud.

Rob







Copyright © 1998-2005 Christian Butterbach. All rights reserved