Re: Keyholes vs. Missing Features
"White Wolf" <[email protected]> Mon, 13 Oct 2003 23:51:47 +0300
| Newsgroups | gmane.comp.programming.keyholes |
|---|---|
| Message-ID | <00b201c391cb$d17b6760$568dba50@Evo> |
Scott Meyers wrote: > I just thought of another reason why a missing feature doesn't "feel > right" to me as a keyhole. Consider again the physical analogy of > trying to see the contents of a room through a keyhole. The keyhole > doesn't keep you from seeing anything, it just keeps you from seeing > everything at once. A missing feature is something you can't see at > all, because the author of the software has failed to provide it. > > I realize that this analogy breaks down somewhat with restricted > domain keyholes, but I still think that a missing feature is > qualitatively different from a keyhole. Me try clarify. So my new Evo notebook not booting from a USD floppy drive is a is an unresonable restriction, but not a keyhole. Operating systems not able to mount hard disks larger than 4Gigs is a keyhole, but not necessarily a gratiutous (I copied that word) one. Internet Explorer showing maximum 11 elements in a dropdown is a gratiutous keyhole - since the designer has picked an arbitrary number, instead of providing dynamic size with reasonable effort. Non-SW metahpors(?): My Volkswagen Passat having its windshield-frame (some call it front stanchion) being in the view when one needs to turn is a sort of keyhole. A too small window on an aircraft passenger area is definitely a non-gratiutous keyhole, since it would cost a fortune to make it bigger. A deeps-space submarine having no windows is not a keyhole. Another note: As I am going deeper into HTML/content rendering I start to see that (unfortunately) since HTML does not support columns (like newspapers have) it rather seems a non-gratiutous keyhole when people present fixed width web pages. It is a non-obvious task to create a rendering engine, which is able to scale from 800x600 to 1600x1200 and - of course - to any window size the user may select. It either requires local rendering (and JavaScript is anything but well prepared for that) or an unreasonably high load for the bandwidth and server CPU (if the rendering is done by the serving host). All this said with keeping proper typographic representation in mind. IMO what we have "found" here is a need to add columns to the HTML/XHTML/CSS standards. Unfortunately, being standards, it won't happen overnight. What I see missing here is not only web designers failing to apply new techniques for online medium design, but the rendering engines lacking support for typographically proper presentation with reasonable effort. With XHTML the presentation is being separated from the content, so it might be possible to add a presentation layer, which also incorporates the hundreds of years of typographics experience. The next possible mistake to be made there is to try to apply that very typography without taking into account that the online media is more than a static book/paper. :-( White Wolf