YASB – Yet Another Symfony Blog

October 17, 2007

Reaching deep into the I18n core

Filed under: General, Tips and tricks — Krof Drakula @ 11:56 am

When creating truly internationalized content, you need to think of a few things – first, what country your are in, and secondly, what the locale is in that country. Why should you care? User input.

While Symfony does have handy features via sfI18N, it doesn’t expose some of the methods needed to correctly parse strings. While string parsing isn’t meant to be the scope of this post, I’ll explain how to get your hands on the number formatting information to enable your application to correctly parse input strings and/or display them in templates (although, I might remind you of the Number helper and its application within the view layer, to aviod logic duplication when that’s already been taken care of).

When you want to get number format information, you simply create an instance of sfCultureInfo, like so:

// lang php
$culture_info = new sfCultureInfo(sfContext::getInstance()->getUser()->getCulture());
$number_format_info = $culture_info->getNumberFormat();
$negative_sign = $number_format->getNegativeSign();
$decimal_sign = $number_format->getDecimalSeparator();

This gives you the chance to write your own number parser according to the expected format and/or use locale-specific settings for different purposes for user-friendly input, not just sfI18N::getTimestampForCulture().

October 3, 2007

IE fixed, Opera is next

Filed under: Opera — Krof Drakula @ 1:13 pm

I’ve never liked Opera that much – have been trying to use it since version 7, but never got around to actually keep myself using it. I actually prefer IE7 over Opera 9 any given day of the week. Now, it seems, there’s yet another reason why I dislike Opera even more, but will have to keep an eye on it after all, even more so, after I discovered a nasty “feature.”

It all boils down to semantics, really. Opera prides itself on being the fastest browser on the planet. Well, from a user’s standpoint, I’d agree, pages do load smoothly in Opera, rendering is a shitload faster than Firefox (especially when it comes down to sliders, for example) and IE. Yes, I admit, it seems to work faster than other browsers. But there’s a price to pay – it doesn’t block scripts when they try accessing CSS properties when listening for the DOMContentLoaded event.

Why should that matter? Case in point: when you want to enable a user interface which uses unobtrusive scripting, the event fires BEFORE any external stylesheets get loaded. As a consequence, all hell breaks loose when you try styling elements. Say, for example, you want to position some div element to the left of some other, like so:

// lang php
<div>This is a box</div>
<div>This is its right neighbour</div>

// lang js
jQuery(document).ready(function() {
    position: "absolute",
    top: jQuery("div:first").css("top"),
    left: jQuery("div:first").css("width")

In this case, IE, Firefox and Konqueror (and, by induction, Safari) will load CSS first, then apply the CSS properties. Opera does not and fires the DOMContentLoaded event on a bare DOM. It helps when you use inline styling (jQuery then gets the correct styles), but what’s the point of using CSS if you declare everything inline anyways?

Opera sucks. From a developer’s point of view. And no, it’s not jQuery’s fault. It’s Opera’s implementation and interpretation of the aforementioned event.

Oh, and if you’re looking for a solution, there’s no way around using the onLoad. I know, you’re thinking “but the content flashes if you use onLoad!” You are correct. But Opera already flashes unstyled content before loading the external CSS (at least in my tests with an empty cache), so this shouldn’t bother you. It will bother the crowd (all 2% of them), but hey, at least the GUI works!

UPDATE: It seems the only consistent implementation of DOMContentLoaded within other browser is waiting for all elements (including scripts and CSS) to load before actually firing the event (up to Gecko 1.9+, Trident-based browsers don’t implement this event and must be simulated). The rationale behind this is that scripts loaded in the head might use styled elements after the CSS is applied, so that, for example, boxes are aligned or moved according to other elements’ positions and/or sizes. Even copying calculated styles from one element to the other.

Opera goes the other way around – it defined the event as the moment is stops parsing the bare HTML, leaving it up to the programmer to figure out cases when any of the files loads in a different order or if at all. It does improve responsiveness, showing the content before the actual styles are applied, but the downside is flashing unstyled content and gripes about checking applied styles first before trying to actually do anything with dynamically modifying interfaces.

Powered by WordPress