29
Apr '12
In the process of learning mobile application design with jQuery Mobile I struggled greatly with making my layouts work with different screen sizes. There are a hundred and one articles online about screen sizes, resolutions etc but no clear consensus on an easy way to make your applications scale from phone to tablet. So I thought I’d build a plugin to do just that.
The idea behind this is simply that you design you application on a certain device with a certain screen width and make sure all your fonts are in the correct proportion. If you set a base font size and then use em sizes on all the rest then it’s simply a case of using a little logic on the current screen width to calculate what that base font size should be in order keep your scale correct.
(function($) {
$.fn.dynamicText = function(options) {
options = jQuery.extend({
maxFontSize: 14,
minFontSize: 6,
baseFontSize: 10,
baseScreenWidth: 800
}, options);
var element = $(this);
doTextResize();
$(window).resize(function() {
doTextResize();
});
function doTextResize() {
var font_size = parseInt(options.baseFontSize * $(window).width() / options.baseScreenWidth);
font_size = (font_size = options.minFontSize) ? font_size : options.minFontSize;
element.css('font-size', font_size + 'pt');
}
}
})(jQuery);
Options
- maxfontSize – maximum size it will adjust your base font to
- minFontSize – minimum size it will adjust your base font to
- baseFontSize – the base font size you used for your development
- baseScreenWidth – the screen width you used for your development
Calling the Function
$('body').dynamicText({ baseFontSize: 14 });
$('.container').dynamicText({ maxFontSize: 8, minFontSize: 16 });
You’ll notice that, although you will generally want to call this function on the entire body of your page, you by no means have to. It will set the base font of any specified element and as such scale all those below it.
The window resize listener is not strictly necessary for a static page but it will trigger when you change the orientation of your device which could be useful.
08
Apr '12
I’ve used a wide variety of programming languages in my time and have found that for web design PHP is everything I need to make a top-notch application. It has a fantastic OO implementation, has a great community building all sorts of wild and wonderful extensions and frameworks and it has the flexibility I need to do my job.
However nothing’s ever perfect and there are some core adjustments that I’d love to see find their way into version 6:
Namespacing String and Array Functions
To me the most irritating thing about PHP is the set of string and array functions. They are all in the root namespace and are completely inconsistent in the order with which you must supply the arguments. Sometimes you must provide the subject string/array first (as in strpos) and sometimes last (as in str_replace), with no apparent method to the madness. This means that even after using PHP for the best part of a decade I still need a cheat sheet on my desk to remind me how to use them. What I would like to see is the function called on the subject string/array like the following:
strpos($haystack, $needle) becomes $haystack->strpos($needle)
str_replace($search, $replace, $subject) becomes $subject->str_replace($search, $replace)
You get the idea
Awareness of Parent Classes from Subclass Static Functions
Now bear with me on this one. If I have class B that extends class A and class B has a static method called staticMethod then I am able to call A::staticMethod() but the code within staticMethod has no idea that it was called in relation to class A rather than class B. Now this may seem like a rather obscure bit of quirkery but I have half a dozen applications that would be greatly improved by it. The following example demonstrates the issue as I encountered it with the ORM of my PHP framework NINA. In order to find a record by its ID in the model User I have to use the code
User::retrieveByPk(new User(), $id)
retrieveByPk is a core ORM method in a class that is extended by all models. Now look at that first argument. The only reason I have to pass in a fresh instance of the model is that it is the only way to let the static retrieveByPk method know what model (and hence what database table) we’re talking about. If retrieveByPk had awareness that it was being called in relation to the User model class then the call could simply be:
User::retrieveByPk($id)
Camel Casing
I think in good code all functions should be camel-cased and all variables should be underscored. Makes for much nicer reading. But maybe that’s just me 😉