After letting Grayplicity simmer for a few months, I’ve packaged and released the latest update tonight. There’s several under the hood changes, some new plugin support, and added support for Gravatars (by request, with thanks to Brad) and Wordpress 2.6’s image captions. Feel free to download a copy and play around with it.
A look at some of the new features
Here’s the short list of changes:
You can grab the latest revision at the Grayplicity home. As always, I’m taking suggestions for improvements or changes. I’m still interested in building in AJAX (Asynchronous Javascript And XML) commenting sometime soon, and I’d like to add in some more plugins at some point. Unless there are some issues I’ve missed in the release, however, it’ll probably be a few months before another update comes down the pipes.
With the debut of my new theme, I have decided that I will go ahead and make it available as a downloadable theme for Wordpress 2.5. This will take some time, as obviously I want to make sure everything works, and take out all the stuff that makes it specific to me. This also raised the question of what about people who do things that I don’t? Building a theme custom to one’s needs is one thing, but making something that is flexible to everyone’s is another.
To address this, the answer was simple. Development Sandbox. Easy enough. But the kicker was content. I needed a good base of different content, formatting elements, comments, categories, etc. On the Wordpress Theme Viewer, they have just such a site set up. When you test themes, a bunch of test data is displayed in the theme so that you can see how different elements interact with it. But, to my surprise, there was no where that you could download this data at to load into your own site. No demo site database, no Wordpress eXtended RSS (WXR) file floating around, and no one seemed to have an idea of where you could get it.
Some suggested copying my current site. Others just said to toss some junk in. Quasi-reasonable, both answers, but that’s not a good solution. I want something consistent that I can use over and over. Using my own site content isn’t a good idea, because I doubtlessly do things that others don’t, and don’t do things they do. Random content isn’t thought out enough, and might miss some elements that need to be tested. My solution was to create my own site, complete with seeded content to test formatting and display. It comes with pages and sub-pages, categories and sub-categories. There are comments, there are formatting elements. In short, most everything to make sure that you get all your formatting elements covered when designing a Wordpress theme.
I also want to make this available to everyone, and will endeavor to keep it up and make it better as needs grow. Please, feel free to make comments or suggestions, and I’ll incorporate new things into it as they are made. I will also entertain the idea of creating an entire SQL file of a site, for those wishing to go that route rather than importing WXR files. WXR files are limited in what they can contain, so it won’t bring in things like blog names, descriptions, links, link categories, and other such things.
This is version 1.0 of the SuperSatellite WordPress Content Framework (WPCF for short). It is being made available as a Wordpress eXtended RSS file, which you can import into your empty Wordpress install through the Import page under Manage in Wordpress 2.5. I created and tested this in 2.5, though it may work in other versions. If you try it with others, let me know if it does or does not work.
Changelog
If there is one common truth in web design, it’s that the creation of CSS (Cascading Style Sheets) was a great (and much needed) development that has been butchered in the end by the browser industry. Time and time again we are forced to deal with the inconsistencies that are surfaced when you view layouts in different browsers. One browser renders space above an <h1> differently, another spaces elements of a <form> as if padding were free money. It’s frustrating. It’s irritating. It’s time consuming. And in many cases, the issues can be worked out, but only after tweaking any number of attributes. One would assume the best solution would be an industry standard default rendering scheme. Go ahead and keep reading once you’re done laughing.
There are a number of solutions that web developers use to get around these differences. Most of these involve coding two style sheets that can be selected based on the user’s browser (keep in mind, I am discussing legitmate difference in element positioning, and not the need for certain types of hacks to trick Internet Explorer into rendering an element how it should, although those can be included in a separately coded CSS file as well). That cures the symptom, not the problem. The other involves specifically defining all an elements parameters (or at least the offending ones) as problems occur, a sort of process akin to putting out fires. This is much closer to being on the right road to a solution.
The differences between browsers can prove challenging in even the absolute most basic layouts. Take the two screenshots below, for example. Nothing fancy is being done here, just a little text with a couple headings, and a no-nonsense form tossed in for good measure (and to really screw with things). Overlaying the two renderings brings out just how much difference a little change can make over the course of a page. In the composite, red is Firefox, and blue is Internet Explorer.
In a lot of ways, I am nitpicking here. This is nothing new, and is an issue designers have dealt with for years. It’s no new thing that browser developers have had to choose how much of a margin to put around element X when they write their rendering engine. And most layouts are fluid enough that a little difference in spacing, especially in body text, isn’t going to be even a remote issue. But, for the first time, we actually have some power over this. With CSS, we can force certain behaviors. Or, more specifically, we can force no behaviors.
When you write a spot of CSS, let’s say:
…you are telling the browser exactly how much space to give your heading above and to the left (but leaving yourself open to browser defaults on the bottom and right). Many designers generally do this on demand, as needed for elements as they produce a template. It stands to reason you could set these all to 0, and have nothing to begin with. At this point, I am sure you see where I am going with this. And the primary reason no one writes a zeroed out style sheet to begin with is the amount of work involved, and the risk of missing something. But at some point, we have all sat down and thought about this idea. And luckily, there are programmers out there with more time than us. Yahoo is one that has been kind enough to release a prewritten reset CSS, that zeroes out everything on a document, allowing you to specify each element from scratch.
To include Yahoo’s default CSS, use this link:
Doing so to my test page produces the following composite. “But wait,” you say. “It’s still off!” And yes, you would be right. There is still a tiny amount of built in browser inconsistency that cannot be overridden. In this case it is about 1 pixel worth of height per line, which stacks up, throwing things off further as you go down. But notice the lack of horizontal difference. And as I said before, most all templates are designed to be flexible enough that hopefully that tiny pixel can be absorbed with no ill effects. Elements line up nearly identically now. You can also view Yahoo’s example page for yourself, as well as one done by Rik Lomas from rikrikrik.com. Again, in this composite, red is Firefox, and blue is Internet Explorer.
With that done, you can now build your template’s style sheet on top of the reset, pulling out elements and defining them as you build it, with the assurance that things will render the same. Granted, this does mean you need to address all the elements. In the screenshot above, you’ll notice that the reset CSS removes all formatting, so <h1> will look just like <p> and <strong> will look like <em> and everything will have 0 padding and 0 margins. So if you build everything and forget to define <h2>, when you go to use it one day down the road you’ll notice it looks very…plain. It is work, but it has a high degree of value, especially when you start laying out more complex things like forms, which are notorious about their spacing issues in different browsers (it’s all right for you to hate IE6, don’t worry, we all do).
Below, you can see Yahoo’s reset CSS code. I have included their copyright information in the code, which I recommend you should as well if you intend to use their CSS as the basis for yours. Give credit where it’s due.
That’s all there is to it! Simple no? This also can give you an idea of just how many elements have the potential to vary between browsers, so it warrants a few minutes of your time to just check things out, and make sure everything looks the way you’d like it to. Yahoo has also released two additional reset type tools for fonts and grid elements. Worth looking at if you have a lot of concern about such things in your layout.
More secure than passwords.
Posting tweet...
SuperSatellite.com by Michael Fienen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. Powered by Wordpress.
