a weblog by Ed Eliot

Pressure is nothing more than the shadow of great opportunity. - Michael Johnson

This weblog is the online home of Ed Eliot, an experienced developer, architect and technical manager based in London, UK.

Entries for December 2007

You are currently viewing posts from the archive. Click here to return to the latest posts.

  • Simple caching proxy for Google Charts API

    6 years, 4 months ago

    Google recently released a fantastic API for generating dynamic charts. It's really simple and is well documented but does place a limit on the number of requests you can make per day. In most cases your chart data probably doesn't change often so it isn't really necessary to request a new chart from Google for each page view.

    I've created a simple caching proxy which solves this issue. It requests charts from Google based on configuration files and caches the result. The cached image is then used for subsequent requests until it expires (configurable). Here's an example of how you might call the script:

    1. <img src="http://www.ejeliot.com/samples/chart-cache/chart.php?config=simple" width="250" height="100" alt="Chart of some data">

    The single parameter, "simple" refers to the filename of the configuration file you want to use (excluding path and file extension). Configuration files are simply sets of key/value pairs corresponding to the GET parameters passed to Google Charts plus a couple of special properties which define caching characteristics. Here's an example:

    1. # simple chart
    2. expiry = 300
    3. cht = p3
    4. chd = s:hW
    5. chs = 250x100
    6. chl = Hello|World

    The configuration files can also contain PHP which will be interpreted before values are passed to Google.

    1. # simple chart
    2. cache = yes
    3. expiry = 300 # time in seconds
    4. cht = p3
    5. chd = s:hW
    6. chs = 250x100
    7. chl = Hello|<?php echo rand(0, 10); ?>

    It's important to note that configuration files aren't cached (at least for the moment) so any data you retrieve within them, from a database for example, should be cached separately. If you don't have code to achieve this already you can download a caching class I wrote a while ago.

    If you're looking for more information about Google Charts, beyond the developer API documentation, check out Brian Suda's recent 24ways article which provides a simple introduction.

    Download the caching proxy.

  • Accessible, SEO friendly text chopping method

    6 years, 4 months ago

    Chopping text at fixed number of characters, or preferably the nearest corresponding word boundary, is a common problem and is usually handled entirely server side. An ellipses (&hellip; rather than 3 full stops) is often added to show that the displayed text only represents a proportion of the original. The following function achieves this effect for an arbitrary text string:

    1. function ChopText($sText, $iCharCount) {
    2. if (strlen($sText) > $iCharCount) {
    3. $iCharCount -= 1;
    4. return preg_replace("/^(.{0,$iCharCount}[^\s])\b.*$/", '$1&hellip;', $sText);
    5. } else {
    6. return $sText;
    7. }
    8. }

    Calling the function as follows returns "Managing Translation…".

    1. echo ChopText('Managing Translation Strings', 20);

    This approach, however, has two disadvantages:

    • You lose some of the meaning of the text. In some cases this may be so much that the text no longer makes enough sense. Sighted users may be able to gain context from surrounding information on the page but this could be more difficult for screen reader users who often browse by stepping through lists of headings or anchors in a page.
    • The text loses SEO value as a search engine spider can no longer crawl the full text. This may be particularly relevant for anchor text as search engines index destination pages against this text.

    Stuart and I recently had an interesting discussion about how we could achieve visual text chopping without actually chopping the text. We decided that the text, which would normally be chopped, could be hidden by wrapping it in a span tag and applying suitable CSS rules to shift it off-screen. Stuart did the hard work of getting it working for a recent project. On that project the server side uses and obscure templating language so I've converted those parts to PHP which I figure will be more useful to most people visiting this blog.

    1. <span class="chopped">Managing Translation<span> Strings</span><span>

    The following function achieves this:

    1. function ChopText($sText, $iCharCount) {
    2. if (strlen($sText) > $iCharCount) {
    3. $iCharCount -= 1;
    4. return preg_replace("/^(.{0,$iCharCount}[^\s])\b\s*(.*)$/", '<span class="chopped">$1<span> $2</span><span>', $sText);
    5. } else {
    6. return $sText;
    7. }
    8. }

    These CSS rules hide the additional text:

    1. .chopped span {
    2. position: absolute;
    3. text-indent: -999em;
    4. }

    It's important to note that you can't use display: none; to hide the text as doing so would result in a screen reader ignoring it completely.

    Adding the ellipses is more difficult. Now that we're keeping the full text we only need a visual representation of the ellipses but we don't actually want it in the page content. The best way to achieve this is to make it a background image. You may have noticed above that I included an additional span tag. The background image will be applied to this. The CSS need to be extended as shown:

    1. .chopped {
    2. background: url(ellipses.png) left bottom no-repeat;
    3. padding-right: 15px;
    4. }
    5. .chopped span {
    6. position: absolute;
    7. text-indent: -999em;
    8. }

    It may take some experimentation to make the background image line up correctly with the text but once achieved the effect should be quite convincing.

  • Opacity bug in Opera 9.5 Beta

    6 years, 4 months ago

    I've just stumbled across a re-draw bug in Opera's handling of opacity which isn't present in the current stable version (9.24). The bug is present in both Windows and Mac versions of the browser.

    I've put together a sample page and set an opacity of 0.7 on the first two paragraphs. On first load they're rendered correctly but if you scroll down the page so that they disappear out of view and then back up again to bring them back into view you'll see that the backgrounds haven't been re-drawn correctly. For elements below the fold (i.e. outside the default viewport) with opacity set their backgrounds are never drawn. I tried several different values for opacity and all exhibit the bug.

    I contacted the good folks at Opera with details so hopefully they'll be able to include a fix before the stable version goes out.