by Alderete on April 11, 2010
The release of the iPhone OS 4.0 developer beta has a lot of people working themselves into a lather (another) over changes in the iPhone developer program agreement, which have the effect of banning applications not created using the native development tools. More specifically, cross-compiled Flash applications (among others).
I’ve got three thoughts about the changes, but they basically amount to “big effing deal.” You can talk or blog about it all you want, but I think it’s all hot air (including this post ;-), and we should all just get back to work.
The King Makes the Rules
First, it’s Apple’s platform, and just like every sovereign nation gets to make their own laws, Apple gets to make the rules for how people get to participate. If you want to create native applications and distribute through the App Store, you follow the rules. Period.
There are important, strategic, and rational reasons why Apple doesn’t want to allow a cross-platform framework like Flash to become powerful on their platform. These reasons are based on long experience with Adobe (more here), and with cross-platform frameworks for the Mac.
You may not like it, but it’s hard to argue that Apple doesn’t have the right to do as they please.
There is Already a Permitted Cross-Platform Framework
Second, any developer who wants to build a cross-platform mobile application, that works on iPhone, Android, Blackberry, etc., can do so today, using technologies that Apple doesn’t just permit, they actively support. HTML5, CSS, and JavaScript run very well on the iPhone, Android, and Palm’s webOS, and any other mobile platform of importance.
Why would any developer whine about being locked into Apple’s platform turn around and tie themselves to Adobe’s proprietary Flash platform? At least Apple is aggressively driving their platform forward, Flash performance on anything but Windows PCs has been abysmal for many years, with only a few signs of change, and only recently, under competitive threat.
Let the Market Decide
Finally, if you’re so offended by Apple’s position that you can’t just develop using open standards like HTML5, you feel the need to “punish” Apple, well… go for it. Android, Blackberry, webOS, and soon Windows Mobile 7 all have developer programs and app stores, and offer a range of alternative models for how to manage and control a mobile platform.
Instead of ranting on your blog or crying in your beer, get coding for the platform that best fits your idea of how the vendor should build and manage their ecosystem. Go be a part of their success, and prove that your preferred model works.
If you turn out to be right, you can be sure Apple will notice, and adapt. (Posting angry words on your blog, not so much.)
by Alderete on December 2, 2009
One of the things that drew me to evaluating and purchasing the Thesis theme for WordPress was the outstanding typography that seemed to be a part of every Thesis site I looked at.
The settings for fonts are simple to use — you choose a single typeface for each option — but behind the scenes, Thesis builds a complete “font stack,” that is, a comprehensive collection of fonts to use, sorted in order of preference. This ensures that your text will look good, no matter what fonts are installed on a viewer’s computer.
For example, when you choose Georgia for your main font, behind the scenes Thesis specifies a series of fonts that are similar to Georgia:
font-family: Georgia, 'Times New Roman', Times, serif;
The variety of typefaces offered by Thesis is somewhat limited, due to the nature of fonts on the web today; there’s only a dozen or so that are “safe” to use, because everyone has them. But recently a few services have come along, which take advantage of new features in modern web browsers to offer more variety in type. Possibly the most “mature” of these (with mature being a relative term) is TypeKit. But how do you use TypeKit with Thesis, when Thesis only allows you to choose fonts from a pre-defined list?
It turns out that this is quite easy to accomplish. In a nutshell, you treat TypeKit as a second custom.css file. There are three simple steps:
[click to continue reading…]
by Alderete on November 25, 2009
Two weeks ago I relaunched the Aldosoft web site, improving both the visual design and the code behind it, and adding a blog for posts like this one. Some things remain the same; it still runs on WordPress, because that’s perfect for a content-focused site like this one. This article is a brief description of the technical changes and additions.
The Old Aldosoft
The New Aldosoft
[click to continue reading…]
by Alderete on November 11, 2009
The Thesis theme for WordPress is arguably the most advanced premium theme for WordPress-driven web sites. It combines fantastic layout flexibility (1-, 2-, and 3-columns, in various arrangements) with strong design customizability (colors for virtually every element are customizable, plus borders, padding, fonts and sizing, etc.) and terrific typography. Out of the box it looks great in all major web browsers, and can be customized wildly to achieve incredible diversity in visual design.
But, oddly, printing pages from a Thesis-based site will often remind you of how the web looked in 1996. That’s because by default the Thesis theme applies its styling only to on-screen display. Printing is entirely unstyled:
The gory details of the how and why are in a DIYThemes forum posting I made a couple days ago, Thesis prints unstyled by default. This is not good. Fortunately, it is possible to extend Thesis with PHP code, in ways that most themes would never dream of, and this gives us options for better printing.
The beginning of a solution is to add a stylesheet for print; the recommended placement is in thesis/custom/print.css. Then you add the link tag to your site via a hook function in your custom_functions.php file:
1
2
3
4
5
6
7
| function add_print_stylesheet() {
echo "\n";
echo '<link rel="stylesheet" href="' . THESIS_CUSTOM_FOLDER .
'/print.css" type="text/css" media="print" />';
echo "\n";
}
add_action('wp_head', 'add_print_stylesheet'); |
Now you have an active, but empty, print.css stylesheet. You still have unstyled content when you print. What’s next?
There are two approaches you can take:
- Create a new print.css stylesheet from scratch, adding only the minimum styling required to make printouts look the way you want. Ultimately, this can produce the best results.
- Import the on-screen stylesheets into the print stylesheet, and then add further additions, customizations, and overrides from there.
The second option will result in printouts looking exactly like your site does in a web browser. For some kinds of content this will not be ideal, but for most pages it’s better than being completely unstyled when printed, and it is a lot easier than writing a new stylesheet from scratch. If you’re looking for the quickest way to get to “pretty good,” this is the way to go.
To do it, put this in your print.css file:
1
2
3
4
5
6
7
| @import url("../style.css") print;
@import url("layout.css") print;
@import url("custom.css") print;
#sidebars {
display: none;
} |
The #sidebars block removes your sidebars when printing. This is what most sites will want to do, but if you don’t, just delete lines 5-7.