Oskar Krawczyk – blog.olicio.us

Like for example a very handy feature which is not mentioned in the online documentation, is Browser.Engine.version which simply returns the integerified number of the browsers engine version.

Stumbled upon that little code while researching ways of determining whether a user is using Firefox 2 or 3 (Gecko 1.8 and 1.9 respectfully) – had to get rid of the opacity animation on the page which also contained a Flash movie – the old flickering problem.

Very handy indeed.

• MooTorial is the Holy Ground for every MooTooler – the motoorial was updated to version 1.2 just a few days ago.
• MooSound is an absolutely stunning piece of code written by one of the MooTools Core developers – Michelle Steigerwalt. This is pretty much a self-contained, fully-functional, Flash-enabled sound management library. You can do pretty much everything with it: load MP3 files, create playlists, jump to a specific part of the track, set volume, manage the ID3 metadata, etc.
• CustomScrollBar and MooScroll for all your User Interface customization needs! This one gets very hand when creating custom UI using Adobe AIR for instance.
• In-line editable content within 30 lines of code (MooTools 1.2).
• Input Class is a beautifully written piece of a very neat code. Thanks to Kassens we can create permalink-friendly URL’s on the fly, match and restrict content that can be inputed into a field, or create a automagically generated list of tags which are being injected upon pressing space.
• BarackSlideshow is basically a simple yet functional rotator script.

Even when working on a online project it would be nice to have some sort of control over what the viewers see – preferably the newly changed version.

What I tend to use lately is generating a random marker in the URL while the project is still in development:

<link rel="stylesheet" type="text/css" href="/screen.css?<?= rand(0, 9999) ?>" />

Which constitutes in the file not being cached in general.

Now, that’s an acceptable solution before the project get deployed. After deployment it would be appropriate to generate a unique release of the template, in my case the catalogue structure would look like the below:

- templates
  - release_01_05_08
    - css
    - img
    - js
    - flash
    - misc
  - release_10_07_08
    - css
    - img
    - js
    - flash
    - misc

Of course the way you divide deployments in unique instances can use a simpler method – versioning for example:

<link rel="stylesheet" type="text/css" href="templates/v1/css/screen.css" />

That should solve common caching problems on all major browsers.

Unfortunately it’s not IE which is causing oddities this time – in particular it is Safari itself. Basically what happens is that Apple with all it’s glory and details for a proper user experience is adding a special form of highlighting for every active/focused form widget – many came across and some are upset about the fact that it’s making impossible to create complete custom styles for the highlighted elements:

But in reality there is a way of re-styling these fields. The custom highlight can be achieved by using the outline property.

So, doing a simple outline: none will result in the blue glow being removed altogether:

Of course this solution is against all usability guidelines since we’ve just deleted the only thing indication of field being focused. Still, it’s never lupus…

More f-ups: