W3C home > Mailing lists > Public > www-html@w3.org > January 1999

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

From: Inanis Brooke <alatus@earthlink.net>
Date: Mon, 4 Jan 1999 15:30:42 -0800
Message-ID: <004301be383b$a88ea860$ac2eb3d1@alatus>
To: "w3c html" <www-html@w3.org>
Most of your solutions would be obtained, in theory, through CSS
positioning, measuring a lot of vital measurements in terms of percentage.
Most CSS compatible browsers resize their content when you resize the
window. Unfortunately, CSS compliance is very, very poor right now. I'm
trying to find a way to bring full CSS2 compliance to the world sooner,
because I think this will be the ultimate solution. If new tags are
implemented by the W3C, does that mean that browsers will support them? Of
course not! I used to think new tags was the way to go too, but then I
learned more about new recommendations at W3C which aren't implemented in
web browsers yet. THAT is where the web suffers!
Inanis (edf)

|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 18:40:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:38 GMT