onLine weblog archive

Friday, April 19, 2002

I missed this when it happened: Dave Winer was grabbing undocumented XML news feeds off of a public NY Times server, and was asked to cease and desist. Google did the same a while back, restricting access to previously publically accessible (though undocumented) XML data, and now they've opened back up with the Google API. Sure would be nice if the NY Times had similar plans.
Amongst the emails I responded to today was this nice message from Bertilo Wennergren (he is talking about the old glish.com):

Hi!

Your site "www.glish.com" is really wonderful. It has loads of great info, and I'm really impressed.

But... unfortunately your ingenious CSS layout does not really work ... all the time. It seems you've made some assumptions about text size and box heights, that make the site break badly when those assumptions does not hold.

I've set my Mozilla to use quite large font sizes, and I've set it to never show any text with a size below a certain limit. The result is some bad text overflow on your start page.

I've made a screen capture of the mess, and I've put it here so you can check it out:

<...glish.png>

Sorry if this throws a monkey wrench into your careful layout. I'm a CSS fan myself, so I hope you'll work it out.

Bye!

Bertilo is right, of course. The old design failed if users took advantage of the text-resizing features in browsers like Mozilla, NS6, and IE5 Mac. However, I think it is quite unfortunate that these text-resizing features allow users to re-size text sizes specified in pixels. Here, read my response to him, interspersed with his reponse to my response:

Hi!

> Thanks so much for your note Bertilo.
> It was because of problems like these
> that I recently redesigned.

Yes, I noticed. BTW: I read your updates regularily. Very useful pointers!

> Hopefully the new site accommodates
> users who like large text.

It works a lot better. Thanks!

> However, I would like to complain
> about the fact that Mozilla and IE5
> Mac provide the ability for users to
> override CSS font-size declarations
> set with in pixel units. A pixel
> should be a pixel, and the browser
> should not be able to override that.

Do you also object to the Mozilla setting that makes the browser never show text below a certain value? This is a major usability help to me. I more and more find that I can just not read a lot of the pages out there. Without Mozilla, and it's easy to use settings that override the often ricidulously small text sizes out there, I would not be able to surf much these days. With age, my eyes just aren't that sharp anymore.

Users can override things like this with settings in a user style sheet too. Is that OK?

> Now I know that web designers who use
> pixels to set font-size cause a lot of
> grief to people who don't like to or
> can't read at small text sizes, but
> that problem should be solved by
> educating designers, not by making it
> impossible to override all pixel
> font-size declarations.

That solution will not come to be, at least not in the forseable future. Should all the people with bad eyesight out there suffer in the meanwhile?

> in some cases, as in the case with my
> site, where the interface for the
> navigation was a tabbed system, pixel
> specific font-size was crucial to the
> interface functioning. i should be
> able to declare a pixel size and not
> have the browser break it.

I do not agree.

> There are plenty of other units
> besides pixels that allow the user to
> resize text to suit their needs;
> pixels should be pixels should be
> pixels.

But the user can not change the author's choice to use pixels. The user needs a way to make the page readable despite the bad choices the author has made.

> Can I print this exchange on my site?
> And link to your screenshot?

Oh yes!

Perhaps this demo I put up a while ago (in response to a usenet question), might interest you too:

<http://www.bertilow.com/ div/columns/>

You can link to it as well, or copy it. The css file has some comments on the code.

Bye!

He's right. It is unfortunate that browsers allow users to resize type sizes set in pixels, but it is more unfortunate that designers set the size of text in pixels when it doesn't need to be. If browser did not allow overrides of pixel-sized type (and rememeber: some, like IE PC, don't), vision impaired users would be out of luck on many sites. The abuse of the pixel size unit in web design is the root of the problem, but the browser override solution renders the CSS author unable to limit text size to pixel units even when doing so is reasonable, like when developing a tabbed interface. The existence of the pixel unit in the CSS recommendation argues that there are situations when it should be possible.

Solution: if you need text to be a pixel specific size, embed it in an image. But please, use that solution with great discretion. Another solution, this one for browser makers: instead of overriding only pixel declarations for text, embiggen the whole page, so that the relative size of pixel-sized text stays the same in relation to its containing block, something like what zoom (a Microsoft's CSS extension) does, but maybe still rendering percentage sizes based on the browser window, so that the whole page doesn't stretch wide.
I tried, I really tried. I just responsded to 30+ emails that have been sitting in my glish.com inbox, but I can't do any more today. Apologies to all who have been waiting for a response from me (I still have 60+ to go). Your emails are appreciated, I swear.
Must start reading: What Do I Know, a very attractive site using pure CSS layout, linking to stories of interest to geeky web developers like me (and maybe you?).

Thursday, April 18, 2002

For you fans of working within a limited palette: CSS Tags Fully Supported by Netscape 4.x/Win.
This is very exciting: Mozilla 1.0 Release Candidate 1.
For geeks: The innerHTML Debate.

Wednesday, April 17, 2002

More XML for you to play with: the Macromedia XML Feed Contest.
We've created a publicly accessible XML feed that allows anyone to provide information on their website about the latest Macromedia Designer & Developer Center resources. This XML file contains headlines and links to all of the latest articles and resources found on our website, and is automatically updated whenever new online content is added.
Tweaked the design again. Turns out that NS4 can't handle images in text for which a specific line-height has been set in the CSS: it displays the image, but the text following the image is placed underneath it, and is therefore quite unreadable. So I removed the line-height declaration from the stylesheet that NS4 sees. I was already feeding it a line-height value different than the one for more CSS-capable browsers (110% instead of 160%), because NS4 was (I think) placing 160% of the height of a line in between lines of text, instead of making each line of text take up 160% of the height of the font itself. In other words, line-height: 160% was insanely too much in NS4. But now it just uses the browser's default line-height, so let's just drop the topic before I become depressed again.
I've updated the text preferences widget code and fixed the problem that some versions of IE5 Mac had where the fieldset filled the full height of the right column. If you're interested, here's what was hapening:

I'm dynamically creating the form controls for the text preferences, so that only browsers that support the necessary DOM methods see anything. I'm using .innerHTML to accomplish this, because of various DOM implementation discrepancies amongst my target browsers. But I found that IE5 Mac was flaking out, displaying the contents of the fieldset outside of the fieldset itself, and making the fieldset unnaturally long. Being used to such silliness, I tried a "jigger", which often solves such display problems with IE5 Mac. The jigger looks looks something like this:
fieldsetEl.innerHTML=fieldsetEl.innerHTML;
That solved the problem nicely for IE5.0 Mac, but apparently caused more recent versions to extend the fieldset the lenght of the page, and then some. Since I installed OS X last week (motivated largely by the need to solve this very bug) I could test IE5.1+ on my G4, which I did, and I found that it did not need the jigger to work properly. So I wrapped my jigger up something like so:
var agt = navigator.userAgent.toLowerCase();
if (agt.indexOf('msie 5.0; mac') != -1) {
  fieldsetEl.innerHTML=fieldsetEl.innerHTML;
  }
And now everybody is happy! Except me, because I hate doing browser sniffing, especially on such a granular scale. I like the grand sweep of object detection.

Tuesday, April 16, 2002

Sometimes Opera does not behave, and because of that, John at albin.net has cooked up a hack to hide CSS style rules from Opera.
As everyone is reporting, Amazon is now providing an XML interface to their system (for Amazon.com Associates):
If you're a developer with a good working knowledge of XML and you want even more flexibility than our standard links provide, you'll want to check out our newest feature. We've built a powerful XML interface that will enable you to build targeted, customized Amazon placements on your Web site.
The web is opening.
Another reason I'd like to jump the OS ship: Eight new IIS security holes exposed.
From evolt.org and Peter-Paul Koch comes Mission Impossible - mouse position:
At the moment I am writing an Introduction to Events. As part of my study I wanted to create a generic, simple script that detects the mouse coordinates at the time of the event. Because such a script can work in Netscape, Explorer, Opera, Konqueror and iCab, it should work in all these browsers.

But I failed. In fact the situation is so bad that I have reluctantly come to the conclusion that a cross-browser script for finding the mouse coordinates during an event must necessarily use a browser detect, something I truly loathe.

Sunday, April 14, 2002

I feel like I am at sort of a crossroads of my server-side development life. I've been coding ASP web applications since the release of the IIS version 3 beta in 1996, the version of Microsoft's web server software in which active server pages premiered. It's the platform I learned server development on, and coding ASP/MSSQL/MSXML is still how I make the majority of my income.

But I haven't yet learned .NET, which is the next generation of Microsoft's Web tools, and frankly, I'm not sure I want to. With the recent install of OS X on my Mac, I have easy access to a powerful Unix box on which I could install a whole host of development environments and server tools that I'd like to learn (and which would free me from a professional life dependant on the evil empire): PHP, JSP, Cocoon, MySQL, etcetera.

But the occasional article like this one, where the always insightful Joel Spolsky talks very persuasively about how and why he and his company are using .NET, makes me doubt the wisdom of of jumping the OS ship:
Why bother moving to .NET at all? Simply put, it's because .NET appears so far to be one of the most brilliant and productive development environments ever created. ASP.NET really makes it incredibly easy to create useful web applications; over the last couple of days I've been creating some applications we use internally at incredible speed. All the grungy stuff that takes 75% of the time creating web applications with ASP (such as form validation and error reporting) becomes trivial. ASP.NET is as big a jump in productivity over ASP as Java is to C. Wow.
archives: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212

offLine journal archive

where everything else is discussed

Friday, April 19, 2002

I have generally always really loved the TBS baseball coverage of the Braves. I think it's the best on TV, and I'm very critical of sports broadcasting. This year TBS added a "sports desk" that bursts in occasionally with updates from around the league, and a baseball wrap-up after the game. The host is a kind of obnoxious guy neamed "Beau" something. He's a little too much of a kid in a candy store for me.

But tonight after the Braves won, they cut to Beau and he launched into something different: a simple collage of 10 or so +-15 second clips of game broadcasts from around the league. It was great. No rock 'n roll, no over-excited sports announcers describing everything in some sort of suburban boy-listens-to-the-basketball players-talk-and-wants-to-be-black pseudo sports-slang ("And the pitcher says 'Doh!' 'cause it's a homer!"), just the game audio from the regional Fox baseball coverage over shots of game highlights. It was beautiful.
And here's more offsite photography, this from my new friend Wendy: a photo called November Frost.
Lest you think I only mention my own photos here: check out Jerry Whiting's photo exhibit called The Botanicals. And then buy him a beer.

Thursday, April 18, 2002

Going back through some old photos, I found this shot that demonstrates what I was talking about yesterday, I think: I like how the needles fill the frame, and how the shallow depth of focus creates depth. The picture isn't really "about" the pine branch, it's "about" the composition. I think I've always been more attracted to form than content. If you've ever met K. read this site you know what I mean.

Wednesday, April 17, 2002

One of the things that I love about macro photography is that wonderful abstract patterns often emerge from the subject matter. Most of the macro shots I've taken that I thought were worth anything succeed because they have some abstract quality to them. This shot of flowers against an orange bus from earlier today is not a macro, but I think it has the same sort of quality, a pleasing balance of color and shape:
It's hot here in Astoria today, especially sitting in an attic office. But I'm not complaining; the trees are getting their leaves, and there are flowers everywhere. When I was young and foolish, Autumn was my favorite season. Now I'm old and foolish and I think the Spring is all that and more.

Tuesday, April 16, 2002

I am enamored of this charcoal and pastel piece from gotty.com. And this oil painting too.

Monday, April 15, 2002

DId you know that a "#" character is called an octothorpe?
The story as told by Ralph Carlsen is that a Bell Labs engineer, Don Macpherson, went to instruct their first client, the Mayo Clinic, in the use of the new system. He felt the need for a fresh and unambiguous name for the # symbol. His reasoning that led to the new word was roughly that it had eight points, so ought to start with octo-. He was apparently at that time active in a group that was trying to get the Olympic medals of the athlete Jim Thorpe returned from Sweden, so he decided to add thorpe to the end.
Steve does, and he managed to use the term in a book we're working on, for which I have the utmost respect.
archives: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49