I’ve been making a Facebook iframe app recently, and I found that this little code »
jQuery('a').children('img')
just doesn’t work on Everyone’s Favorite Browser™ (Internet Explorer 8).
jQuery('a').children('img').length
always returned “0” for me. So I had to end up using .find('img') instead.
date();
is NOT correct!!!
date_i18n();
(This only applies if you’re outside of UTC. What’s that, like 99% of the world?)
a:focus {
outline: 0;
}
Now, back to real work.
The origins of Twitter.
In related news, if you haven’t heard about it yet: Twitter API v1.1
I’m sure you have heard of App.net by now. The paid, non-advertisement-supported “live social stream” (read: Twitter). They set a $500,000 goal, and raised more than $800,000 – a clear indicator that some level of demand is there for such a service.
There are two levels of membership, the $50 “User” level and the $100 “Developer” level. A developer account will give you the necessary API keys to build apps that connect to App.net. I was very interested in how these prices were chosen, and thankfully App.net published their logic (“How did you come up with the pricing tiers?” in the FAQ).
I agree with Marco Arment that $50 a year is too expensive for regular users, but he didn’t have anything to say about the developer tier. Here’s an excerpt from the FAQ that irks me:
The developer price is inspired by the amount charged by the Apple Developer Program, $99. We think this demonstrates that developers are willing to pay for access to a high quality development platform.
The decision using the Apple iOS Developer Program as inspiration for the App.net developer tier is, I believe, fundamentally flawed – there are too many differences and not enough parallels:
For App.net to convincingly (using their present argument) charge $99 for their developer tier, I believe that the following services are necessary:
Of course, if you believe that App.net will balloon, the developer tier is moderately priced. Otherwise, it’s just another lucrative investment.
(Yes, I did back App.net)
There’s no denying that PHP is not the optimal language. But at least code in good PHP. Here’s my pet peeve for the day:
Relative paths in include(_once)? or require(_once)? statements.
// WRONG
require_once("./include_me.php");
// RIGHT
require_once(dirname(__FILE__) . "/include_me.php");
Why? Basically, performance. PHP doesn’t look through all its search paths for absolute paths, saving those precious system calls. This effect is compounded when you’re using the APC cache with apc.stat = 0 (it won’t even cache files that are referred to with a relative path)
Basically, do not use text-rendering: optimizeLegibility; with Japanese. At least, not yet. Why not? Here are some examples.
The top line has text-rendering: optimizeLegibility; applied, and the bottom line use the browser defaults. As you can probably tell, optimizeLegibility has indeed optimized the legibility, and the type looks much nicer. However, there is a fatal bug in rendering Japanese characters with optimizeLegibility: It seems that the actual optimization is taking place after the length of the line is calculated. As you can imagine, this is a problem. Here’s a screenshot with an underline applied:
Because length-of-line calculations are used to determine line breaks, this bug will also make your sentences break in weird places.
Screenshots taken with Chrome 21 on Mac OS X 10.8. I was able to reproduce this in all WebKit browsers.
“`css
* {
-webkit-font-smoothing: none;
}
“`
To enable Windows Emulation mode. Great stuff.
There’s a few resources about -webkit-font-smoothing in English, but I was wondering what it would look like in Japanese. Here we go.
Source: Max Voltar
A few days ago, I posted a small JavaScript snippet.
Retina, Please! is that JavaScript snippet on steroids. It is a combination of JavaScript and PHP to allow your Retina users to only download Retina images, while non-Retina users only download the standard-resolution version.
Check it out: https://github.com/keichan34/KKRetinaPlease
WordPress Theme Writers: just require it in your functions.php. I may package it into a real plugin later on.
I’ve tested it with CakePHP as well.
Today, we just released the Varnish-ed site I posted about a few days ago. A few things to be careful about in your Varnish deployment (that I had originally overlooked):