HTMList.com, A Web Development Blog by Synapse Studios

Internet Explorer 7 represented a step forward for “mainstream” browsing. Microsoft worked to fix a lot of the epic fails in CSS implementation that IE 6 had brought upon itself and those around it. There are a few departures from the standards and further from how Firefox handles things, but they’re farther and fewer in between and don’t impact us *too* much on a day-to-day.

Still, instead of developing for Firefox and Internet Explorer, we’re developing for FF, IE6 *and* IE7. Cheers. Add to the fact that IE6 has some serious flaws including its lack of transparent PNG support without getting all hacky, different JavaScript implementations and limitations on what you can do with AJAX calls, et cetera, and it becomes a significant burden to develop for. It doesn’t help that you can only have one version of IE installed on a Windows-machine, or the other, without, again, getting terribly hacky. Just watch your workflow take a hit there.

Read More »

Tagged with: 37signals, firefox, ie6, ie7, internet explorer, microsoft, mozilla, web standards, wordpress

Posted in: Design, Development

As the guys around the office are well aware, I tend to obsess over minor details in our code. Whether it be fixing code formatting to be tabbed properly or renaming variables to better fit naming conventions of a project, the developers hate when I meddle in the codebase. Is it my fault that sometimes I miss a few when I go through and rename variables, functions, methods, etc? Clearly, no. The joys of being the boss.

But what I really want to discuss is something I don’t consider so minor, complying with web standards. Most times when I am doing web development I prefer to go with the HTML 4.01 strict doctype. We try to observe strict standards wherever we can, and they have helped us to avoid patterns of behavior that are more prone to errors. We make sure that notices and E_STRICT are enabled on the PHP side. While developing, our templating system is set to validate our markup against its doctype in a very angry way that we both love and hate. The added benefits of sticking so closely to the standards is that you can pick up errors through malformed output that browsers obfuscate, and you can achieve a greatest amount of compatibility between browsers. As any good website designer knows, creating web pages that render the same in every browser can be a royal pain (thanks Microsoft).

Read More »

Tagged with: ajax, html, standards, strict, w3c, wordpress, xhtml, xml

Posted in: Design, Rants

Previously, we discussed a WordPress bug and our temporary workaround for it. I am glad to say that we have identified the root of the problem and have been able to come up with a better solution. Apparently WordPress’ auto-save function is not a fan of a character set of anything other than UTF-8. We had changed it through the administration interface via Settings -> Reading to be ISO-8859-1. When we changed it back, it seems that posting works happily again without the truncating issue that was happening before.

This would seem like a fairly large problem and I am very surprised that it hasn’t been identified and resolved before now. After we tracked down the cause of the problem, I ran a quick search and was able to turn up this topic covering the same problem on an older version of WordPress. Seeing that this problem existed in at least version 2.3.2, I can’t fathom why it didn’t make the cut for things to fix for the 2.5 release.

At any rate, I sincerely hope that this is something that is addressed in the very near future so that we can switch back to the ISO character set.

Tagged with: bugs, wordpress

Posted in: Rants

Recently we upgraded our blog to WordPress 2.5.1 and have been battling a horrible bug ever since. When we save or edit a post most of our content is sometimes lost. Unfortunately, it isn’t occurring with enough frequency for us to track down the specific cause of the problem and we have enough projects lined up over here to keep us from digging through the WordPress code ourselves to solve it in any reasonable time. So we’ve opened up a ticket in WordPress’ bug tracker that outlines the problem in more detail and continue to wait for a response from someone on the dev team to let us know what might be the culprit.

In the meantime, the fear of not knowing if your post would be lost when saved forced us to saving the content to notepad before publishing. This is a less than useful solution to the problem because even doing this it seems that once a post starts truncating itself upon saving, it continues to do it every time. The only solution is to delete it and start anew. [We're noticing the problem crops up most often when another user edits an entry not their own. It truncates the post arbitrarily and then proceeds to reject contributions to that post past the truncated length. Needless to say, the frequency and creativity of expletives uttered in the office has spiked dramatically.—Ed]

So today, I took some time to hunt down remote posting solutions that allowed us to save our posts without needing to log in to WordPress directly. ScribeFire was the first solution I tried and has turned out to be an incredibly useful tool. ScribeFire is a FireFox extension that allows us to create posts directly in FireFox and saves them to our blog via the WordPress API.

There is still some functionality lacking: the ability to change post author, adding excerpts and making use of some of the plugins that modified our post entry page to name a few. But we see their release schedule to be rather efficient and hope to request some features that make it into the next release (or until WordPress identifies the problem that forced us to this solution in the first place). [It should also be noted that the extension on the whole is rather impressive considering that it's blog-engine agnostic and works for many different providers.—Ed]

Tagged with: bugs, extension, firefox, projects, wordpress

Posted in: Rants