Archive for March, 2006
Christian Heilmann of the DOM Scripting Task Force published a long article called From DHTML to DOM Scripting today. In it, he claims that DHTML is awful and outdated and generally very bad, and that DOM Scripting is the second coming of Zarquon.
Okay, that was slightly exaggerated. Yet this line of thinking annoys me. DHTML is, like HTML before it, painted in a bad light, whereas XHTML and DOM Scripting are purportedly the best (and therefore only) way ahead. When you look more closely at the practices so easily associated with XHTML and DOM Scripting you see a different picture. Quoting from the weblog post:
DOM scripting assets:
- Progressive Enhancement – check if things are available, then apply those dependent on them
- Ease of maintenance – keep the maintenance as easy as possible via dynamic CSS classes and properties at the beginning of the script
- Separation of Presentation and Behaviour – add dynamic classes instead of changing the style collection
- Separation of Structure and Behaviour – use dynamic event handlers and generated elements instead of onclick and NOSCRIPT
- Using modern event handling – more than one onload please
- Avoiding clashes with other scripts – avoid global variables and encapsulate functions as methods in an object
That sounds quite reasonable. In fact, I’d say these are all very good programming practices, regardless of being used in “DHTML” or “DOM Scripting” scripts. The problem is that DHTML, and all of it, is being blamed for blatantly ignoring these practices. I consider myself to be a DHTML programmer – heck, I learned most of my stuff at the now dead DHTMLCentral – and yet I grew up to these practices. While I am aware of the type of DHTML hinted at by the DOM Scripters, virtually all of the provided scripts on DHTMLCentral fit the description, it’s not the DHTML I, and many others, know and write.
Seeing DHTML portrayed as evil pains me. It does not deserve to be used as a straw-man for good practices. I believe good practices should stand on their own merit, and the ones the DOM Scripting Task Force attempts to spread are perfectly capable of doing that.
As I’ll have to focus on course-work and money-making-work in the next few weeks here is a feature list for sIFR 3. Of course, when something turns out to be too hard to implement, it’ll be removed from the list. Don’t take it for granted!
- Better and easier font sizing, as explained in Font Sizing with sIFR.
- FlashCSS: This lets you use multiple colors and different text styles in general. It also aids with link styling. Todd Dominey has a list of supported properties.
- Controlling kerning, leading and line-height.
- Font resizing.
- Better FlashBlock support (actually this’ll be a side-effect of the font resizing).
- Possibility to ignore specific elements during replacement.
- Modification of the content passed to sIFR.
- Pixel fonts.
- Flash 8 filters.
- Background images inside the Flash.
sIFR itself will be easier to use, and there’ll be a number of small fixes for edge-cases. Speed improvements are high on the list as well, obviously.
Font sizing is the most difficult part of using sIFR. In this post, I’ll discuss how the algorithm in sIFR 2 works, or rather, why it doesn’t work as well as originally intended. Coincidentally, this makes this post an excellent tutorial for font tuning in sIFR 2. We’ll also look at how things will be improved with sIFR 3.
sIFR 2
The algorithm used by sIFR 2 is relatively simple:
- Take the width and height of the element you want to replace.
- Create a Flash movie which uses these dimensions.
- Increase the font size from 6 pixels, pixel by pixel, while rendering the text, until the height of the text is larger than the Flash movie.
- Render the font with a size one pixel smaller than obtained in (3).
Unfortunately this doesn’t quite work. First of all: the font used in the Flash movie may be wider or smaller than the font used in the HTML. Let’s say the font is wider, what will happen then is:
- Because the font is wider, it will wrap to a new line earlier than the HTML font would.
- This allows for the possibility that the text will reach the allowed height earlier, resulting in a smaller font size (see point 3 above).
A way to deal with this is to set the letter-spacing of the HTML text so the font appears to be wider, having the effect of giving it the same width as the Flash font. This works, assuming that there are no other factors influencing the width and height of the text, such as (unintentionally) using different fonts on different user machines. Default browser settings for CSS properties like font-size or letter-spacing can be of influence as well.
In short, achieving cross-browser and cross-platform consistency of the width and height of the text, while taking into account the width of the font used, can be very, very hard.
sIFR 3
In sIFR 3, things will work a little different. For starters, the font size is no longer determined by the width and height of the text. Instead I’ve figured out a way to derive the font size from CSS. Here is a short version of the rendering algorithm employed by sIFR 3:
- Determine font size and the number of lines the text takes up.
- Create a Flash movie using the width and height of the text, these can be changed later.
- Render the text.
- If the text is wider than the allowed width, try wrapping it to the next (or a new) line.
- If a single word is causing the text to be too wide, resize the movie.
- If the text now requires more lines, resize the movie.
Resizing the movies requires Flash to talk to the JavaScript code in the website. Since we’ve dropped Flash 6 support, this has now become possible.
Specifying the desired font size in Flash is quite easy as well. All it takes is two properties!
.sIFR-hasFlash h1 {
font-size: 12pt;
line-height: 1em;
}
Why the line-height? sIFR uses the line-height and the height of the element itself to calculate how many lines the text uses. By using line-height: 1em; we ensure it has the same value as the font size. As Eric Meyer said:
(…) for line-height, em-based values are calculated using the computed font-size of the element itself. I declared the font-size directly, so we know its computed size in pixels.
It also turns out that if you specify line-height in ems, and don’t specify it in the descendent elements, they will have the same line-height:
So that computed value (…) is what’s passed on to the descendent elements. (These) elements will inherit (the same)
line-heightvalue. End of story. They don’t change it based on their own font sizes; in fact, they don’t change it at all (sic).
Concluding
sIFR 3 will bring easier font tuning, as well as other features I’ll talk about later. You can see the original font tuning experiments, as well as a demo of the current stable SVN export.