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):
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:
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.
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:
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!
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!
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:
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:
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
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 
