07 - Tweaking the Static Templates
In this chapter I get fussy with the code formatting and make some structural changes that should set us up for a better ExpressionEngine implementation down the road.
In today’s nudge-along on this series we stay at the HTML/CSS level, making some changes purely out of preference and some that should help net us a better end result after pulling apart the templates and doing the EE implementation.
Here’s what I will cover in this post:
- Cleaning up code formatting
- Adding ID’s to the body tag
- Cleaning styles out of the HTML
- Changing the Doctype
Cleaning Up Code Formatting
This is one of those things that, at first glance, can appear simply as fussiness on the part of the coder. However, I think well-formatted code is actually a productivity gain well worth the time investment. Why? Well-formatted code makes it easier to find specific items, easier to find unclosed div tags, and will make it easier to chunk up the still-complete page templates into embedded EE templates.
The challenge, if you work with EE code in the default template editor with it’s textareas, is nicely formatting code using tabs for indentation. One solution is the TabInTA Firefox Add-on. It changes the default behavior of FF - so that rather than the tab key moving you out of the current textarea to the next one, it inserts a tab into the textarea’s content. This little add-on has really helped me improve the formatting of my EE code.
I won’t cover the specifics of how I format HTML-based templates as it should be pretty obvious from the companion files. Overall it’s just trying to reflect the nesting of the document structure with indent levels.
On the CSS front, I prefer all declarations to be in this format:
#name {
property: value;
property: value;
property: value;
property: value;
}
I know this style of formatting can add some size to the CSS file, but I’ll give up a bit of size for an easier to read file. I’ve also taken to using nesting in CSS, so if - in the above example - there was another item within the #name div that was inheriting styles from #name it would appear in the CSS as:
#name {
property: value;
property: value;
property: value;
property: value;
}
#name .another_thing{
property: value;
property: value;
property: value;
}
A hat-tip to Andy Ford at AloeStudios for that CSS approach - I’ve found it really helps understand the CSS being used and find the declaration I’m after when I need to make a change.
Adding ID’s to the Body Tag
Now we move from formatting changes to structural changes. Here are the issues I see with the templates as they come out of the box:
- The banner divs are unique to each page - and the value of the banner ID is what determines the banner image for that page
- The main navigation lives inside of that banner div
Why are these issues?
I want to have one embedded template that both pulls a unique page banner image and sets the active state on the correct navigation item - this way my main navigation code is only stored in one place which makes future changes really easy. This arrangement was going to make it tough to do that elegantly.
My solution was to add an ID tag to the body tag. The ID will tell the template which page is being viewed. For example, the index page now has:
<body id="home">
This lets me:
- Have a generic banner div in the HTML - better for creating an embedded EE template to hold my main nav
- Only specify the size of the banner div once in the CSS
- Specify the banner image in the CSS using inheritance
- Be able to specify other page-specific CSS using inheritance
- Be able to use an EE variable to set both the body ID and main nav location (in a future post)
So where the CSS had:
#bannerHome { background:url(../images/banner1.jpg) no-repeat; width:770px; height:225px; clear:both }
#bannerMinistries { background:url(../images/banner2.jpg) no-repeat; width:770px; height:225px; clear:both }
I now have:
#banner {
width:770px;
height:225px;
clear:both;
}
body#home #banner {
background:url({site_url}/images/interface/banner1.jpg) no-repeat;
}
body#ministries #banner {
background:url({site_url}/images/interface/banner2.jpg) no-repeat;
}
You’ll be able to see the full extent of the changes in the companion files.
Cleaning Styles Out of the HTML
I also prefer to have all styles in the CSS template. I can see that the way the templates came coded it lets certain styles be re-used in slightly different ways in different HTML templates - which means a smaller CSS file. But I’ll trade off a slightly larger CSS file, containing some page-specific styles, for a more complete separation of content and presentation. I just know that, down the road 8 or 10 months, if I had to come back to this site and add a new content type and tweak some styles, that it would take me longer if some of the styles were contained in the HTML templates.
For the index template there were two sections to edit; the Join Us area in the right column and the footer. What I did for both was add some style declarations to the CSS - which you can see in the Companion Files. The new footer items are found indented under the parent footer declaration and the new Join Us styles are added at the bottom.
I tend to work this way with CSS documents - fitting new items into the existing structure if it makes sense, or adding a new area at the bottom. At the end of the project I might then re-arrange/re-organize the CSS.
Changing the Doctype
I also changed the Doctype of the HTML from HTML 4.01 Transitional to XHTML 1.0 Strict. I know there are great numbers of blog posts out there talking about the differences between these two and when you might use one over the other. For me the choice was a bit more pragmatic as I know that ExpressionEngine offers three formatting choices for content fields:
- “None”
- ”< br />”
- “XHTML”
I prefer to use “XHTML” where possible as I think it does a nicer job of marking up user-entered content. However, if I use XHTML formatting for content fields and leave the Doctype set to HTML 4.01 Transitional then the site will likely not validate. Why? The tags that ExpressionEngine adds in the content areas will have the XHTML style tags that won’t validate under a HTML Doctype.
For example, HTML 4.01 wants break tags like:
<br>
while XHTML wants (and EE will output) break tags like:
<br />
Again - a bit of fussiness on my part but in this case it took very little work to change out the Doctype and make the necessary changes to get the template to validate as XHTML 1.0 Strict. Doing this now will be easier than down the road, and it should be easier to keep the site validating even with EE generating content from fields set to XHTML formatting.
The Results
Visually our rendered index page still looks the same. But the W3C Validator is happy with it, and I’m happier for having the code cleaned up a bit and having all styles in the CSS document.
In the next installment we’ll start the chunking up process, whereby we’ll create embedded templates to contain all the elements that repeat on the page. You can get a head start on me by reviewing the EE Docs on Embedding Templates within Other Templates.
Cheers!
Category Navigation
Previous Comments
by .(JavaScript must be enabled to view this email address)
Date: Tuesday, July 8th, 2008
Comment: #2
MIke,
I have a question about this issue of XHTML Strict and the EE content editing area (Publish/Edit section).
We have noticed significant problems if we type a document in Word (our standard practice) and paste it into EE. If I write “Mike’s Train-ee site is great!”, for example, the possessive case will generate bogus characters in the rendered web page in the major browsers. Pasting also loses all of the basic editing features, too, like paragraph breaks, bold, and italics.
We have tried to set the formatting to
, none, and XHTML, but they all do the same thing.
Is this what you are talking about when you say that EE does a nicer job with XHTML? And do you know of any ways to eliminate the artifacts from Word (do you use a plugin or some other method?).
by Mike Boyink (Author)
Date: Tuesday, July 8th, 2008
Comment: #3
You can’t paste directly from Word. It’s not generating HTML.
If you must bring content from Word, paste first into Notepad, then copy/paste from Notepad into EE.
Formatting has to be applied in EE via the interface tags to apply web-specific markup.
What I mean by EE is better at XHTML is that EE will generate tags like:
<br />
and not
<br>
The former is XHTML compliant, the latter is not.
by .(JavaScript must be enabled to view this email address)
Date: Tuesday, July 8th, 2008
Comment: #4
Thanks, for the clarification, Mike. That is really bad news. On one of my blogs, I get submissions of articles from biblical scholars and theologians as long as 15 pages with all sorts of italics and bold formatting. These are always in Word.
I had no problem pasting from Word using WordPress. It’s disappointing to learn that EE does not have that ability.
by Mike Boyink (Author)
Date: Tuesday, July 8th, 2008
Comment: #5
Wordpress must be using some sort of WYSIWYG editor that’s taking the MSWord content and interpreting it.
I’d be scared to see the code that’s coming out of that process though - I’ve yet to see anything that could take MSWord and generate nice clean validating HTML.
That, in fact, and reliable cross-browser and cross-OS compatibility is why EE doesn’t feature one by default - see this post from Mr. Ellis himself just yesterday.
As Rick mentions, there are ways to add a WYSIWYG editor to EE. I’ve tried a few not cared for any of them.
by tzTrainEE
Date: Wednesday, July 9th, 2008
Comment: #6
Ideally all you want when pasting from a word.doc to html are the paragraph, bold, italics and lists.
I was amazed how well dreamweaver does when copy pasting word docs. Open the doc in word hit control plus A in windows to select all, then paste the article into the visual portion of dreamweaver. It does almost a perfect job of giving you paragraphs, lists, strong and em tagged html. No msonormal or any of that bunk.
Not suggesting purchasing dreamweaver just for this task. I haven’t done an exhaustive search for any other such tool, http://download.com brought up a few things when searching word doc to html, some of those cost money though. I initially thought Windows Live Writer had possibilities to copy paste word docs, you might try that. Good luck finding something suitable if you need it. Pasting directly from Word bloats a page unbelievably bad. I’m curious how if using EE and you have a wysisyg editor installed as an add-on like FCKeditor or tinyMCE it would treat Word.doc bloated code. You might ask that one in the forums over at expressionEngine.com.
by tzTrainEE
Date: Wednesday, July 9th, 2008
Comment: #7
Also the biggest offender at showing up erroneously are forward quotes and backwards quotes, if you can train people to just use the simple quote that is next to the enter button and holding the shift key that will be maybe 90 percent it. You really need to use html entities to correct some special characters, code for those can be found at http://w3schools.com
Also forgot after you paste into the wysiwyg window of dreamweaver then copy it from the code view for best results getting all the tags, copy just what is between the < body > </ Body > tags.
by .(JavaScript must be enabled to view this email address)
Date: Wednesday, July 9th, 2008
Comment: #8
Thanks tzTrainEE for these tips. Quite helpful, really.
Since Mike’s post, I tried to use Contribute with EE last night (no luck so far on configuring it - not sure what API to use or what credentials and paths are being asked for). I think that may be ideal for the same reasons you mention for DW. Contribute is cross-platform and my staff could master it. Adobe claims that you can paste from Word directly in exactly the way I need.
I actually used DW myself and discovered all the things you mention myself by trial and error. And your remarks about the quotes are spot-on.
I also use myself - in Mac OS X - a great utility called TextSoap. I paste from Word into TextSoap and then paste into the blogging engines (Joomia mainly) that have problems with Word. I welcome suggestions for similar tools that work on Windows.
Mike - can you please clarify the connection between validation as XHTML strict and EE’s formatting? I see in EE all three options you mention (XHTML and
. My pages do not (yet) validate Strict, though my HTML-header makes the claim that the code meets that standard. Will validating actually change my experience with formatting output from EE? Is the XHTML formatting choice I make in EE’s edit window, for example, simply ignored if I am not validated? It’s not clear to me what I gain by cleaning up the two or three exceptions I have remaining.
Thanks to both of you for your suggestions.
by Mike Boyink (Author)
Date: Wednesday, July 9th, 2008
Comment: #9
The setting in your HTML header only tells the validator what version of HTML you are attempting to create. The validator will tell you if you are doing it successfully or not - that’s it’s whole reason for existing.
Validating won’t change your experience with formatting output from EE.
But choices in formatting output from EE will change your experience with the validator.
When you set a formatting option in the edit screen of EE you are dictating how the content you enter is marked up.
More information on it is in the docs.
Again, EE does NOT do:
<br>
.
Look close at the option—it’s
<br />
, which is an XHTML tag not a HTML tag.
If things still aren’t clear here I need to point you to the EE forums for further support as we’re getting outside the intent of this tutorial series.
by .(JavaScript must be enabled to view this email address)
Date: Wednesday, July 9th, 2008
Comment: #10
Thanks, as always, Mike. This is clear, but I shall hit the fora. And I am happy to assist you by bumping up against your boundaries so that their need becomes more clear! :-)
by Sean
Date: Friday, July 11th, 2008
Comment: #11
I had forgotten about the tabinta extension - got installed now and am tabbing my CSS - taking a long time, but definitely more readable. Not sure if I’ll go back and do the html, but will definitely use it in future projects.
by .(JavaScript must be enabled to view this email address)
Date: Wednesday, July 23rd, 2008
Comment: #12
Dear Mike, just a quick one to say thanks alot for your tutorials, as someone who hasn’t tackled a CMS before they are really clear to follow. One thing I wanted to ask you was, I know that EE has the capability to save out your template files so you work on them in your normal coding program. I use Dreamweaver, and as someone fairly new to html and css I find it’s colour coding and predictive texting for the code really useful to help ensure I’ve got the syntax correct. Do you have any objections to this way of working?
by Mike Boyink (Author)
Date: Wednesday, July 23rd, 2008
Comment: #13
Hi Mark -thanks for the comments.
I know many folks work that way.
If it works for you then by all means do it.
With the tutorials I wanted them to be as focused on EE as possible - once you go down the path of doing the templates as files then there are different text editor depending on if you are a MAC or PC user etc.
I also just don’t work that way—I like to jump around to different systems so keeping everything all on the server works better for me.
by Matt Abron
Date: Thursday, May 21st, 2009
Comment: #14
Great Stuff…here.
(1) I know this must be a simple thing…
Added the <body id=“home”> (works fine)
Changed CSS: I keep loosing my banner image.
http://visualjelly.com/index.php/page_comps/index.html
(2) “It’s All Text!” seems not to play well here on my Mac. I keep getting a error that “unable to execute editor” I tried with 3 types of text editors…no luck. Any Ideas would be great.
Thanks again for a great series.
Matt
by Mike Boyink (Author)
Date: Friday, May 22nd, 2009
Comment: #15
I’m a PC user so not sure what the ITsAllText issue is on the Mac.
by Mike Boyink (Author)
Date: Friday, May 22nd, 2009
Comment: #16
Hey Matt
In the stylesheet make sure anywhere it has:
url({site_url}/images/
...
Gets changed to
url({site_url}images/
.
The site_url variable includes the trailing slash.
by c hill
Date: Thursday, October 8th, 2009
Comment: #17
http://www.caseyhill.com/index.php/page-comps/
Mike, after replacing your new code in Chap 07, the right hand section “Join Us” does not render correctly. I think I found the fix, but am leaving it broken so you can look at it.
The fix appears to be adding a break tag after the <b class=“pageTitle”> code below. It was not in either the original html or the updated code in chap07 zip file. The fact that no one else seems to have mentioned this makes me wonder if it is something else I’ve missed! :
<b class=“pageTitle”>Join Us</b>
<div class=“join_us_column”>
Sunday
Bible Study - 9:30 am
Worship - 10:00 am
Family Night - 7:00 pm
</div>
<div class=“join_us_column”>
Wednesday
Coffee House - 6:00 pm
Biblical Studies - 6:30 pm
Youth Night - 7:00 pm
</div>
** also just discovered I can’t type a break code into this comment box as it simply breaks the line and doesn’t show the code. How do you paste in a code sample to comments so it will show but not execute?
by Mike Boyink (Author)
Date: Thursday, October 8th, 2009
Comment: #18
Surround it with [ code ] [ / code ] (remove the spaces).
by tzTrainEE
Date: Monday, April 28th, 2008
Comment: #1
Ahh, good good. I was thinking of going html strict myself, but with EE it’s better to go with xhtml doctype, which is no small point. Looks like it’s time for me to move to xhtml once and for all then.
Thanks for taking the time to fuss with the templates. It gets to be a habit for me, but I really like having the validator giving me that green light and saying the page code validates.
There are firefox browser extensions that put any page a right-click away from the validator, and the validator makes it easy to catch errors in the coding, like we’ve seen people having already in your earlier series comments threads, great for troubleshooting.
Link: https://addons.mozilla.org/en-US/firefox/addon/2250
It will be entirely possible now with the cleaned up templates and EE set to xhtml coding.