Structuring Test Pages
Unexpectedly, I have instituted a small change since version 11. I am trying to keep a commented section in the ASP.NET template so that optional code can be easily used, deleted, or if necessary incorporated back into old pages. This commented section works fine in IE and Opera. However, in Firefox, the double dash that was in version 11 of the forward and back links creates problems. In IE and Opera the double dash must be followed by a greater than sign to close the comment, -->. In FF the greater than sign doesn't have to immediately follow the double dash, in fact this is enough to close a comment: -- ...lots of stuff... <tag>. Everything after that tag becomes visible on the page in FF. To avoid this, I've had to get rid of the double dash, which meant abandoning my slightly cobbled together but highly robust arrows, <-- and -->, with slightly less robust escape code arrows, ← and →. I think this will be more attractive anyway, and there don't seem to be many cases where they don't work. It's more important that the comments work than to preserve any particular arrow convention, so that's how I'm going after this for now.
I'm also adjusting some of the code on the test pages. I wanted to do as little of this as possible, but navigation and for the first time SEO both demand some modest accomodations to certain links. I'm thinking about how to differentiate these links as active "safe" links, possibly as part of differentiating a test page from the other pages of the website in general. Should it be the test pages that are tagged or the normal pages to avoid "adjustments" to the test and content review pages? This really touches on the fact that Core pages should be set up similar to pages on any other website so that they can be updated. But the test pages should be fundamentally frozen. Maybe create folders for CSS, Components, etc. and when I make changes to the Core page template, then it becomes a new update in those files and I begin using that new "frozen" page instead of the old "frozen" page in future testing pages. This will allow a javascript to be used for a year (or more) if there are no changes, while numerous updates to a CSS stylesheet can be reflected in the test pages. {chroniclemaster1 2008/12/27: The links evolved into the working link color for the test pages which otherwise are as much as possible created to mimic their final application as closely as possible. The core pages have details in red to distinguish them. I also moved the entire present file structure into a Historical folder and rebuilt the file paths a bit to reference the new location. I've not yet implemented the new testing structure for source files but am more certain that I will implement something like this.}
It became apparent at some point, that our method of inserting a <title> tag into a content control in the <head> was generating two <title> tags. I would prefer a cleaner implementation like I had, the .NET version makes lousy use of whitespace (like so many controls). However, if .NET is going to implement it's own title tag even if I don't call it, then I guess best practices is to use the ugly one. I've therefore redone these templates without the <title> tag in the content control and adding the Title attribute to the @Master directive.
[chroniclemaster1, 2009/04/14]
Skip to Main Points