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