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

> -----Original Message-----
> From: www-html-request@w3.org [mailto:www-html-request@w3.org]On Behalf
> Of Brian Schweitzer
> Sent: Sunday, January 03, 1999 12:47 AM
> To: www-html@w3.org
> Subject: 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.

This is list is for technical discussion of HTML and potential enhancements
thereto, so your submission is quite appropriate here.

> 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.

Perhaps, but for most of HTML's history, that isn't a problem space it's
even tried to address. Indeed, with HTML 4.0, the overwhelming majority of
presentational features have been deprecated altogether.

>  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.

But this is mostly a problem with the design strategy. The underlying medium
is scalable.

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

I do not see how this is related to ALT text. Or are you talking about an
additional attribute that would take an alternate image? If so, what has
screen resolution got to do with what image I'd want to present? It doesn't
give any good idea of the dpi of the monitor, or the size of the browser
window.

> 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.

You *really* think so?

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

To appropriately adjust the size of the fonts as you describe, you'd have to
know the dpi, and for that you need the physical dimensions of the monitor
(in addition to the resolution). Wouldn't it be easier to just base your
font sizes reatively on a size the user has already selected as appropriate
for display on his/her system? (You can do that now.)

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

But isn't the important thing how much of the browser window the image takes
up, and not how much of the screen it might take up?

> 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.

I don't see how this substitution logic would be any less difficult to
implement than (full or partial) support for the Netscape tags themselves.

>  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.

But if such a converter were feasible, they could do that now. The scripting
language in use can be identified with the TYPE attribute of SCRIPT.

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

I appreciate your sentiments on the matter of browser interoperability, but
I think you are going about things the wrong way. Anyone who's had to create
multiple versions of a page that are supposed to look basically the same in
both major browsers will probably attest to the fact that it is an inexact
science, rife with lots of fiddling to get things just right. I don't think
a few (or even a lot of) hints to the browser are going to enable it to
automate this process. More importantly, I don't think the implementors are
interested in expending the kind of resources that implementing these
features would take just to make authoring for them *and* their competitor
easier. The game has been that they *want* you to have to choose.

Furthermore, authoring for a particular browser size has always been an
affront to general usability. Browsers are already capable of scaling a page
to mulitple resolutions and browser window sizes; authors just have to take
care to use relative sizes for the majority of applications.

Braden

Received on Monday, 4 January 1999 04:36:39 UTC