HTML tag addition suggestion, to "solve" future browser display problems

I'm not sure if this is the correct place to email this, so please
correct me if I've somehow chosen the wrong address.

As I see it, one of the biggest problems HTML is facing (if not the
biggest) is the lack of a guarantee that the document will be seen as
it was intended to be seen.  I may design a document to look best in
800x1024 resolution, when viewed with Netscape's latest non-beta
release.  Ok, so it will look fine under the exact same situation, and
depending upon what I used in the document, it may always look right. 
But what if I used the most up to date tags, and am then viewing it in
IE5b2 at 600x800?  It looked fine before, but now it may be a complete
mess.  

These proposed tags would be a compliment to the identification of
what HTML level is being used in the document.  Truely compliant HTML,
according to the W3 standard, would, ideally, be written by all
authoring programs, all HTML-authors, and be viewable by all people no
matter what browser.

Unfortunately, this is not the case.  Authoring programs routinely
lead to bad or simply messy code.  Authors working by hand may
optimize for their testing environment.  And we're all familiar with
the problem designing for Netscape vs. IE (vs. text, vs. Opera, etc.) 
And there are many different screen resolutions out there.

We have browsers already detecting and automatically the color depth
of images, and adjusting the color in an image to that of the system
(downgrading millions of colors down to, say, EGA (does anyone still
use ega monitors?))  However, if you've ever seen some of the results
of this, you know that they can become pretty hideous.

Therefore, I suggest the following tags:

  Applying to the entire document (BODY modifiers or
    META tags):

    VERTICALDESIGN  (or VDESIGN)
    HORIZONTALDESIGN (or HDESIGN)
    BROWSERDESIGN (or BDESIGN)
    BROWSERVERSIONDESIGN (or BVDESIGN)
    COLORDEPTHDESIGN (or CDDESIGN)

  As an extension to the image ALT modifier:

    CDEPTH#ALT
        (where # stands for 002/004/016/256/etc.)
    RDEPTH#ALT
        (where # stands for 0640/0800/1028/etc.)

VDESIGN and HDESIGN would give the optimal screen resolution for
viewing a document.  This would also get rid of those annoying "This
webpage best viewed in 600 by 800 resolution"-like lines on most
webpages.  Using this information, in conjunction with stylesheets,
the browser could adjust the look of a page to one that meets the
user's resolution, perhaps by reducing the size of the fonts used
(rather than awkwardly wrapping the text where it overflows, or having
pages that are wider than the screen).

This could also be used by browsers to automatically adjust the size
of images contained within a document (if the design res was 1028x800,
and the image is 200x100, and the viewing res is 800x600, then the
image would be scaled down to the appropriate size, to take up an
equal amount of physical space on the screen, rather than appearing
larger (or smaller) than possibly intended.  In conjunction, an
RDEPTH#ALT modifier to an image tag could be specified, so that rather
than shrink down the existing image, a different one would be used
(like the tags already in use for fast/slow connections, to show one
image while a larger one downloads).

Very similarly to the above, the CDDESIGN tag and the CDEPTH#ALT
modifier could allow for various color depths in HTML documents.

BDESIGN and BVDESIGN would be used for different reasons.  Using
these, the browser mainly used to test the look of a page could be
identified by the viewer's browser, and that browser could modify the
display accordingly.  Perhaps the document was designed for Netscape,
and it is viewed under IE.  IE could then substitute those tags that
Netscape has provided to extend the official HTML, with similar tags
(or other workarounds) of its own, and vica versa.  Or maybe Netscape,
Opera, and IE have different scripting languages supported.  Each
could provide for a way to still allow their users to access the full
functionality of the webpage with this information at hand, perhaps
through the use of plugins or the use of automatic scripting language
converters.

I recognize that these are mosre problems brought about by the browser
wars, and by authoring mistakes (or at least, non-full-W3
HTML-compliance), but they are still real world problems.  My
suggestions are proposed as a way to allow workarounds to many of the
problems we now face as we try to deal with HTML and the web while the
battle still rages - webpage-triage if you will. :)


                Sincerely,
                   Brian Schweitzer
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Received on Monday, 4 January 1999 03:21:45 UTC