Category: Burningbird

Categories
Burningbird

Last post

This is my last post in the RealTech WordPress weblog. RealTech will be back, though whether it will be a weblog or stories, tutorials, and the like, I don’t know yet. Whatever I do will be implemented in Drupal.

I’m finding that Drupal really is a good solution for me, and not just because of the better support for both rich semantics and SVG. Drupal provides multiple types of publication models, including books and “stories”, the latter of which can be considered a “weblog”, but could equally be considered nothing more than a story published online.

I’ve long wanted the capability in WordPress to be able to associate a group of pages into a book, with an order specific navigation, rather than loosely into a category. Drupal supports this functionality, in addition to the category-based grouping. The tool also has better support for taxonomies, in addition to being able to fine tune the exact URL for each writing.

I also like the architecture of the modularization. Drupal isn’t a slam dunk installation, but then it’s not the same as a pure weblogging tool. It is a true content management tool, which means you’ll have a better time planning ahead with your installation than just throwing something out.

I’m not going to try importing my old posts. Instead, for both this site and Burningbird I’m cleaning out old crap and then I’ll be using the Linux utility wget to create a static copy of the site. I’ll then move the static pages in to replace the old dynamic web pages:


wget --mirror -w 3 -p --html-extension http://realtech.burningbird.net

Adding the following into the .htaccess file ensures the SVG in the page works for people using an SVG-enabled web browser, while still allowing IE access:


RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
RewriteCond %{REQUEST_URI} \.html$
RewriteCond %{THE_REQUEST} HTTP/1\.1
RewriteRule .* - [T=application/xhtml+xml]

You wouldn’t believe how much cruft I had in Burningbird. Remember, this is a weblog I’ve had for over seven years. It’s also a weblog that started out with bad HTML markup, now being served up as XHTML. It is getting to the point that unless I really like a post, if it’s broken in XHTML, I delete it.

Too many of the posts, too, were nothing more than notes about “I’m going to do something”, “I am doing something”, “I have done something”, and preserving these types of posts is tantamount to collecting old Avon bottles. In addition, so much of my old writing was maudlin. Maudlin, histrionic, and full of hyperbole. It was exhausting just reading some of the old material. I found myself saying, all too frequently, “Oh my god, there she goes again”–about my own writing, which is a sad state.

I’m also fixing up the posts that I am keeping, including repairing broken links (using a tool, Xenu to find them).

When I’m finished, hopefully this weekend, the site will probably be hundreds of pounds lighter.

Creating the static copies frees up the .htaccess files, as well as “cleans” up the god awful redirect mess I have now. I’m also using the Google Webmaster tools to eliminate entire subdirectories that are gone. Since I stopped caching my stuff a long time ago, once the stuff is cleared, it’s gone. This aggressive cleaning will result in more 404/410 pages, inspiring me to be more creative with the error pages.

I’m not ready to move out new pages yet. I want to make sure I’m happy with my re-organization, as well as tool use. I’m made a lot of bad decisions the last several years, primarily because I ended up following some new meme or another. Now, I want to make sure what I end up with is what I want for the long term–not something that scratches a momentary itch, or puts me in the middle of the bees.

I don’t like “Under construction pages”, not the least of which the images are too damn cute for words, and “under construction” provides no useful information. Instead, I’m creating “to-do” lists for all of my sites that provides a brief explanation of what the site is, as well as an indicator of recent activity, and planned for activity in the future. An example can be seen at my Shelley Powers site, or Painting the Web.

I doubt that anyone would be interested in following along with this process, but then, I didn’t think Twitter would take off, either. If you are interested, I started an account at Ta-da Lists, where I will list my to-do items, and when they are completed. You can also follow along with my Burningbird Twine.

Speaking of Twine, I do have invitations for it, and for Aviary, the online graphics tool system. I created an Invites email address at invites@burningbird.net, which will provide an auto-responder message letting you know what invites for what app I have available. This way if you ask for an invite for Twine or Aviary, or whatever I currently have invitations for, you’ll get immediate feedback on whether you can expect the invitation, or if the invitations are all gone. The invite request will then get forwarded to me to issue the invite.

My two book support sites, one for Adding Ajax and one for Painting the Web, are my priority, so I’m not sure when anything else will be finished. I probably won’t have my main Burningbird page up before these two sites are ready, but the main Burningbird feed will be running from the start. I’m continuing to use Sam Ruby’s Venus, and the main Burningbird feed will continue to be housed at http://burningbird.net/feeds/atom.xml. Note that this will be my feed for everything–all the writings and what not from all my sites. Once I take down the WordPress weblog at the top level, I’ll then redirect my older feeds to this new location.

If you’re interested in Ajax, you’ll probably want to check out the Adding Ajax page when finished. It’s not just a book splash page. I’ll be adding new writings related to Ajax, as well as reviews, code, and book support stuff.

The same with the Painting the Web site. Painting the Web promises to be my most “fun” site, especially if you’re interested in photography and/or web graphics. The splash page I have now doesn’t represent what I’ll have when I’m finished. I’m not quite sure about all aspects of the page design yet. Page design is always the hardest task for me. Tech is easy.

I don’t know all I’ll be doing as I go forward, but I do know that all of you have made the last seven years of my life a richer experience. I must have broke an anti-matter mirror seven years ago, because I’ve had seven years of good luck, not bad. I want to thank you for your time and interest, not to mention patience with my many flights of fancy.

Categories
Photography Web Writing

Color management support in browsers

With the addition of support for color profiles built into Firefox 3, it’s time to take a closer look at how the popular browsers support color management. First though, a quick refresher on the importance of color profiles.

If you’ve every worked with a photo in a photo editor, only to have the rich colors leach out when the photo shows in your web page, you’ve run directly into what happens when your editor supports color profiles, but the browser does not. Color profiles are a mapping between device and color space, in such a way that a photo that looks richly colorful in Photoshop, still looks richly colorful in your browser, across multiple operating systems and devices.

The following are two sets of photos, each incorporating different color management. The first in the series shows the photo as I would normally create a photo for publishing on the web: I’d calibrate my monitor, set the gamma half way between PC and Mac, and then set my tool’s color space to the LCD. Then, when I work with the image, the result I get will end up looking relatively decent in both Macs and PCs. The second photo in the series hasn’t been manipulated at all. The third was created after I set the photo editor’s color settings to sRGB, and then converted the photo to this color space. When I saved the photo, I incorporated the color profile.

The first sequence of photos are screenshots taken when the photo is loaded into Firefox without color management. Though a screenshot doesn’t necessarily capture the nuances of color, I think you can see that the color of the last photo from the first sequence of three differs from the color of the last photo in the second sequence of three, which consist of screenshots from Safari 3.x, which does have built-in support for color profiles.

screenshot one screenshot two

The following are the actual photos used for these screenshots. The first shows the photo without any color manipulation and not using color management.

bird with pink feathers

The second photo was made using my old LCD color trick.

bird with pink feathers

The last photo was not manipulated in the photo editor, other than to scale the image. The sRGB color profile was embedded into the photo. I could have also embedded the Adobe RGB color profile, but I stayed with the popular sRGB color profile.

bird with pink feather

If you look at this page using a browser that doesn’t support color management, the first and third photos should be very similar. However, if you look at the photos using Firefox 3 with color management enabled, Safari 3, or other browser or device that supports color management, the last photo should appear more colorful than the first. To get an even better idea of the color variations, the following are screenshots of color swatches in a web page— opened in both a color managed browser, and in a browser that doesn’t support color management. The difference should be noticeable.

Currently, I know of only a few browsers that support color profiles: Safari 3.x, in both Windows and the Mac, supports color management; supposedly Omniweb also supports color management, as did the older version of IE for the Mac (IE 5.5), though I’ve not tried either tool. Now, Firefox 3 supports color profiles, but not without a caveat: color profiles are disabled by default.

The reason Firefox 3 is releasing without color profiles on by default is primarily because of performance issues. Turning on color management in Firefox 3 can really slow load times of a site that uses color profiles embedded in pictures, especially larger pictures. In addition, according to John Resig there are some real concerns about plug-ins, such as those for Flash and Silverlight, that don’t do color profile support, and which can lead to incorrect renderings.

I can understand the issues, though I am disappointed. Support for color profiles with Firefox 3 would go a long way to encouraging color profile support in other browsers. I hope that Firefox 3.1 works through the performance issues and we get support for color profiles by default. You can still take advantage of color profile support in Firefox 3, now, but you either have to set a custom option using a less than friendly procedure, or make use of a color management add-on.

Do I use embedded color profiles in images at my site? I have started to, though not across all sites. If I use color management, I won’t use my LCD trick, which means that the photo won’t look as good for those people using browsers that don’t support color profiles. At the same time, I would really like to encourage better graphics support in our browsers, which means using the functionality we want the browsers to support. We’ll never progress if we keep designing for the lowest common denominator.

For more on color profiles, check out the International Color Consortium web site.

Categories
SVG Writing

Off Painting

We’ve finished up proofs on Painting the Web this week, and I have my first snap of the new cover. I embedded a version of the cover that’s been converted into SVG over at Burningbird, but have included a JPEG below.

Now I can turn my attention to the new book, as well as the site changes and book support sites. I’ve closed down my experimentation at Burningbird, leaving it for now with an appropriate background image. Red is not normally my color, but I rather like the warmth of the color and the new background SVG works exceptionally well in a flexibly sized environment.

Something will happen to RealTech, I’m just not sure what. Only the Feeds know what lurks within the hearts of online writers. Mwahaha, or something to that effect.

Spring has arrived here in St. Louis, though reluctantly and wetly.

Painting the Web

Updated: O’Reilly went with a Golden Oriole rather than a Prairie Chicken.

The cover of my newest book, rendered in SVG. I used Vector Magic to convert the raster image to an SVG vector drawing. I then “combined” it with another image that I had vectorized.

Categories
Burningbird Technology Weblogging

WordPress 2.5: Looks

Recovered from the Wayback Machine.

Though I will be using Drupal for portions of my site, I’m still debating whether to continue using WordPress for purely weblog activities, such as at RealTech. I decided to download the WordPress 2.5 release candidate 1, give it a run.

I’ve moved most of my XHTMLating work to plug-ins, so I didn’t have the problems with overwriting source code. The plug-ins I do use worked without a hitch, including the one that XHTMLates comments (though the commenter’s name field doesn’t support internationalization at this moment).

I like the new dashboard, which does a good job of putting important information at the top. I don’t like the fact that you still don’t have a lot of options–or at least I can’t see them–for eliminating all of the crud that gets pushed at you. I don’t care about top plug-ins. I don’t care about other WP weblogs of note.

As for the new site design, I like the coloring, but I do not like all of the design changes. Case in point is the Write Post page, with post in process.

Look at all that wasted space. There are four headers above the Write Post page, and in the Write Post page, we now have to scroll down to control comments, pick categories, add tags. Yet what takes up the valuable real estate to the right? Related items, ie how to manage comments, posts, etc. When you’re writing a post, what are the items you’re most likely to edit for that post on a regular basis? I would say tags and categories, as well as comment status. You’re not worried about managing categories or comments.

I do like that the Delete button is now more obvious, rather than buried at the bottom of the post. In addition, I was happy to see a link to draft entries rather than forcing us to filter on draft to find a post in process. There’s also only one Save button for a post now, equivalent to the older “Save and Continue editing” function.

I also like the fact that you can edit the permalink, though the creators didn’t go far enough–you should also be able to pick which category goes into the formal permalink. I had hoped that the developers would also list existing tags in the tag area, but you still have to guess what tags you have if you don’t want to add new ones.

On the other hand, I do think the media management capabilities are superior in this version. If you serve video, you can now more easily manage your video, as well as music and image files. For instance, you can click on more than one file to upload, rather than have to upload individually. The application will then upload all the files, and for photos, attempt to use the photo’s EXIF file to fill in the relevant information, though the application doesn’t seem to like my photos’ EXIF sections.

However, if you’re tempted to have WordPress 2.5 create an in-page gallery, think again if you’re serving your pages up as XHTML: the generated gallery HTML is not valid.

This is a trivial error to fix, and I’ve sent the error information into the special feedback email address. However, this does demonstrate something I find a little disquieting–the WordPress developers are not running their sites as XHTML, themselves, in order to ensure WordPress provides both valid HTML and XHTML. Nor are the developers validating what they generate. If they did, they would realize that their sites don’t validate.

Worse, the validation errors are such blatant errors that even relatively inexperienced web developers–and web designers–should have caught them early, and prevented their occurrence at this late stage of WordPress 2.5 development. The only assumption I can make is that form is taking precedence over function with this release. Definitely not an attitude I would have expected considering the involvement in the development of WordPress 2.5 by known standards luminaries.

The page containing the gallery does not open in Firefox, Safari, or Opera because these browsers read the page as XHTML, and the page has invalid markup. However, the page does open in IE8. Perhaps the underlying issue is that IE8 is the browser of choice for the WP development team.

In the other sections, if you make any updates in the user page you have to type in your password again, or it tells you that you only entered it once. That’s annoying. The rest of the pages seem the same, except for a new Media Library, which shows what images are used where. Handy if you want to track down in which posts a specific image has appeared.

Overall, the interface is cleaner and media file management has definitely improved, but the usability has, in my opinion, taken a couple of major hits. I include in this category the freedom to serve our pages up as valid XHTML without having to struggle with invalid generated page markup.

Now, I’ll publish and see what happens to the feeds.

Categories
Burningbird

Having one’s cake

Recovered from the Wayback Machine.

I’ve now mapped out a plan for moving forward on the organization of my site, including which tools to use, where and even some preliminary designs. I’ve also played around more with incorporating SVG into a site design, as well as trying out some of the newer CSS3 design attributes. I’m finding out that one can have one’s cake and eat it to.

For instance, you can use SVG for a site design, and the site doesn’t have to look either plain or ugly with IE–just different. If you’re comfortable with different, this isn’t a bad way to move forward with the more advanced browsers, such as Firefox/Gecko, Opera, and Safari/Webkit (the Big Three), while still accounting for a more primitive browser like IE.

Right now, today, at Realtech I have an experimental design up called “World War”, featuring both a photo from an air show, as well as three different SVG images. Only the photo shows with IE, but rather than have a completely white page, I added a background color and repeating background pattern, both of which are overlayed by the SVG ‘background’ image that the Big Three can see.

This is where it gets a little tricky. The SVG element supports both a width and a height attribute. If you specify the width and height in the element as SVG attributes, not in the CSS style attribute, Internet Explorer ignores both, which means the SVG element takes up no page space in IE.

However, the Big Three understand that width and height are supported attributes for SVG container elements, like the SVG element, itself. All three support the width and height setting directly in the SVG element. Not only that, but both Safari and Opera get a bit snitty if you don’t use these attributes and instead set the width and height using CSS, only.

The end result of this mechanization is that the Big Three see the SVG images and override the background image and background color. True, they still load the background image, but since it’s so tiny, it’s not a significant load on the server or client. Best of all: no conditional references have to be used, either in HTML, CSS, or JavaScript. If IE were ever to support SVG someday, the browser would then process the SVG just like the Big Three.

I continued this concept into using some CSS3 attributes. CSS 2.1 provides the meat of web page design, but CSS3 is the desert, and what’s a good meal without desert?

I use the rgba color function when setting the background color for both my sidebar and my article title bars. The rgba function takes four parameters: the three decimal values, in a range from 0 to 255, for the red, green, and blue channels, respectively, and a fourth representing the alpha channel. The alpha channel is what controls the transparency. Using the rgba function allows us to create semi-transparent backgrounds.

I could use a variation of opacity setting, including the CSS3 opacity attribute, as well as the older moz-opacity, filter, thing. However, the opacity settings effect the opacity of the element on which it is set and any child elements. Using the rgba function for the background-color creates a semi-transparent background for the element on which it is set, but has no impact on the child elements. (For more on opacity and rgba, see A brief introduction to Opacity and RGBA.)

What about a gracefully degrading design? For user agents that don’t support rgba, what I’ve found is that we can specify a background color using non-rgba functionality:

.sidebar
{

background-color: #fff;
background-color: rgba(255,255,255,0.8);
}

Either the agent will pick up the non-rgba background color, or it won’t pick up any background color at all. In the latter case, the behavior that the browser demonstrates is that it recognizes a supported CSS attribute (background-color), but not the value (rgba). Therefore it flushes the previously set background color, but doesn’t apply the new background color.

(I believe the former behavior is the correct, while the latter behavior is the incorrect. If you any input on this, please leave a note in comments.)

Combined, these two CSS background-color attribute settings result in the following: the sidebar and the inner panel background are both semi-transparent with Safari and Firefox, which support rgba; Opera doesn’t currently support rgba, but will pick up the earlier, solid white background-color; IE doesn’t pick up any background color, and both items are transparent.

Another CSS3 attribute I use that gracefully degrades is the new text-shadow attribute. With text-shadow, I can add shadow to text, such as the title in the page header. If the browser supports the text-shadow attribute, the shadow displays; otherwise, no shadow.

The text-shadow attribute takes four parameters: the color of the shadow, the x coordinate of the shadow as it relates to the original element; the y coordinate; the radius of the applied blur. I currently have the following text-shadow attribute setting on my main title:

text-shadow: #333 2px 2px 4px;

This CSS setting creates a dark gray shadow, offset 2 pixels to the right and bottom of my current text, with a blur radius of 4 pixels–a relatively soft shadow. The shadow shows with Opera and with Safari, though not with Firefox or IE. As long as no dependency is placed on the shadow (i.e. text the same color of the background, depending on the shadow to make the text show), the look degrades gracefully for browsers that don’t, currently, support text-shadow.

Best of all, when the text-shadow attribute is eventually supported by a browser, the shadow is displayed without any further intervention or modification of the page design. All you have to do to is accept that a page will look different in different browsers. Not “bad”, different. If you’re willing to live with “different”, you can have a lot of fun now with new design elements