Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

March 26, 2004

User Experience

A few more blog-related notes.

  1. Srijith has discovered a minor security flaw in MovableType’s handling of email notifications.

    Update 3/27/2004: At Ben Trott’s request, Srijith has pulled the details of the flaw from his web site (apparently, Ben claims never to have received Srijith’s vulnerability report). Reluctantly, I’ve decided to follow suit here at Musings. Supposedly, the fix is in MT 3.0. If that (or a standalone patch) is released in a timely fashion, I’ll be happy about my decision. Otherwise, I may have to revisit it…

    Update 3/27/2004: Oh, to heck with it! We’re not going to have another Comment-Throttling fiasco. “All will be well when MT 3.0 comes out.” is not a viable Security Policy. The exploit is out there, and MT users need to know about it in order to protect themselves.

    In brief, if a spammer (or other miscreant) leaves a comment of the form

    Innocent comment here.
    Spam links here.

    (that’s a single period on a line by itself) only the upper part will be sent in the notification email(s), while the full comment will be posted to your blog. If you are using Sendmail, you should patch your MT installation.

    --- lib/MT/ Wed Mar 24 19:55:40 2004
    +++ lib/MT/      Wed Mar 24 19:58:06 2004
    @@ -85,7 +85,7 @@
         local $SIG{ALRM} = sub { CORE::exit() };
         return unless defined $pid;
         if (!$pid) {
    -        exec $sm_loc, "-t" or
    +        exec $sm_loc, "-oi", "-t" or
                 return $class->error(MT->translate(
                     "Exec of sendmail failed: [_1]", "$!" ));
  2. My previous entry, as promised, uses SVG for figures. I’m curious as to how this works for various classes of users

    • Users with SVG-native builds of Mozilla
    • Users with the Adobe Plugin
    • Users with no SVG support in their browser (should fall back to a GIF image)

    Personally, I’m using the Adobe Plugin, and I find that scrolling past an SVG image, in Mozilla, is painfully slow. Safari doesn’t have this problem.

  3. My Atom feed is now “official.” My RSS 0.91 feed is deprecated (though not dropped … yet).
  4. Speaking of feeds and SVG figures, NetNewsWire is a little overzealous in dealing with the SVG figures in my full-content feeds (RSS 2.0 and Atom). I can see an Aggregator not wanting to deal with sorting out “good” <object> elements from “bad” ones, and instead just ignoring all <object> tags. But, just because you do that, why ignore the content of the <object> element? The content, in this case, is a GIF image, which is the fallback for those who can’t — or don’t wish to — deal with the SVG. NetNewsWire is perfectly happy displaying GIF images, but it doesn’t in this case, because the <img> element is ignored.

    I suppose I could strip out the <object> tags from my feed. But I don’t want to. Those whose client software (like NetNewsWire, ironically) is capable of handling an SVG figure ought to receive one.

Posted by distler at March 26, 2004 12:01 AM

TrackBack URL for this Entry:

8 Comments & 0 Trackbacks

Re: User Experience

Jacques - I currently do not have the SVG plugin installed. Safari 1.2 does not display the GIF fallback images. Mozilla does.

Posted by: Evan on March 26, 2004 9:20 AM | Permalink | Reply to this


Oh my! Report this to Apple, as a bug.

I guess I should apologize for blaming NetNewsWire for not falling back to the GIF image. It uses the same rendering engine as Safari, so it’s probably not Brent’s bug.

Posted by: Jacques Distler on March 26, 2004 9:27 AM | Permalink | PGP Sig | Reply to this

Re: User Experience

So reported.

Posted by: Evan on March 26, 2004 10:00 AM | Permalink | Reply to this

Re: User Experience

Yoou seem to be sizing the coontainer divs in ems and the images in pixels. This creates a problem when the wiidth of the container div is less than the width of the pixel image as the text overlaps the diagram (at least it does in a recent Firefox nightly; my slightly rusty memory of CSS is that this is the correct behaviour, but I suppose I could be wrong). This happens for my default font size, so it could be a common problem.

Posted by: jgraham on March 28, 2004 4:50 PM | Permalink | Reply to this


Not exactly. The SVG figure is sized in ems, and rescales when you zoom the text (this would not be true, at least in Mozilla, if I set the size in px).

The GIF image, alas, has a fixed size (in px). That size is “correct” only at the default resolution of 16px=1 em.

Posted by: Jacques Distler on March 28, 2004 7:30 PM | Permalink | PGP Sig | Reply to this

Re: Sizing

But I think the problem lies in the fact that the image and the caption are both inside a div with a width of 16em and no minimum, regardless of whether the 16em SVG or the 256px gif is displayed. This means that, when the gif is displayed, the text outside the div overlaps the image significantly at text sizes smaller than 16px, making both image and text hard to read.

Unless I’m missing something, you just need to set min-width:256px on the floated div, and the problem will be solved. The only additional problem it would create is that the image would appear too small for the box at small text sizes + SVG. However I consider that a much less pressing issue since it will just create additional whitespace.

Posted by: jgraham on March 29, 2004 7:02 AM | Permalink | Reply to this


Unless I’m missing something, you just need to set min-width:256px on the floated div, and the problem will be solved.

OK. So let’s try a couple of ideas. In that post, I’ve set an overflow:auto for the container div of the first figure. When you rescale (either magnify or shrink) the text, the SVG figure will grow or shrink along with it. The GIF image (for those without SVG) does not rescale. But, when we shrink the text, instead of the design breaking, we get a scroll-bar on the GIF image.

For the second image, I set min-width/min-height on the SVG figure and a min-width on the container div. When you magnify the text, the SVG image will magnify along with it. But if you shrink the text, the second SVG image will stay 256px wide.

What do the Web-Design/Accessibility gurus think? (I know you’re out there!)

- From the point of view of Accessibility, I was mainly interested in having the image scale when you magnify the text. But, for small form-factor devices, you might also want it to rescale when you shrink the text, too.

With option 2, we sacrifice that capability, to ensure that the design doesn’t break for people without SVG-capability, when they shrink the text. With option 1, we retain all the advantages of SVG, at the cost of sprouting a scroll-bar around the GIF image.

Time to vote, guys!

Posted by: Jacques Distler on March 29, 2004 9:24 AM | Permalink | PGP Sig | Reply to this

Re: Vote!

Well all the experts seem to be in hiding, so in their absence, I’ll say that using min-width is much much nicer for me.

In general, I would expect small-devices to ignore the image width settings and just resize to something that fitted on the screen. Having said that, Daniel Glazman’s small screen rendering extension (Mozilla or Firefox only) does appear to do a better job in the overflow:auto case.

Is it possible to just size the gif in ems? Sure, it will resize in an ugly way, but it might be good enough.

Posted by: jgraham on March 31, 2004 5:27 AM | Permalink | Reply to this

Post a New Comment