coding for 800x600 and 640x480
Karl-Johan Noren
In <34462C...@julian.uwo.ca>,
David Le Sauvage <dles...@julian.uwo.ca> wrote:
> Is there any way to code for both 800x600 and 640x480 so that things
> don't get out of alignment?
Yes. Write HTML for all possible screen resolutions,
including no screen at all.
--
Karl-Johan Norén (Noren with acute e) -- k-j-...@dsv.su.se
http://www.dsv.su.se/~k-j-nore/
- To believe people are as stupid as one believes is
stupider than one can believe
Lars Marius Garshol
* David Le Sauvage
|
| Is there any way to code for both 800x600 and 640x480 so that things
| don't get out of alignment?
The only real answer to that is that it is a bad idea to even try. HTML
is supposed to be completely independent of the viewers equipment and
even of whether they view the document at all or run it through a text-
to-speech system instead.
See question number 20, although the answer is a bit too short and does
not really adress the issue strongly enough:
<URL:http://www.htmlhelp.com/faq/wdgfaq.htm>
| If possible respond to:
| <A HREF="mailto:lesa...@uwo.ca">lesa...@uwo.ca</A>
It's sent by email as well, but be warned that you may miss an interesting
discussion here on c.i.w.a.h.
--
________________________________________________________________________
Lars Marius Garshol
"Make it idiot proof and someone will make a better idiot", Bill Arnett
http://www.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/
Shawn K. Quinn - NO JUNK E-MAIL
In message <34462C...@julian.uwo.ca>, David Le Sauvage
<dles...@julian.uwo.ca> wrote:
>Is there any way to code for both 800x600 and 640x480 so that things
>don't get out of alignment?
Sure there is, don't (try to) use HTML as a page layout
language. Don't use tables for anything besides tables, for instance,
and definitely don't make your entire page one big table.
Really, the question looks pretty silly to those that realize what
HTML is and what it isn't.
SKQ
David Le Sauvage
Is there any way to code for both 800x600 and 640x480 so that things
don't get out of alignment?
If possible respond to:
Dave
On 16 Oct 1997 22:43:57 GMT, skq...@brokersys.com (Shawn K. Quinn -
NO JUNK E-MAIL) wrote:
>In message <34462C...@julian.uwo.ca>, David Le Sauvage
><dles...@julian.uwo.ca> wrote:
>>Is there any way to code for both 800x600 and 640x480 so that things
>>don't get out of alignment?
>
>Sure there is, don't (try to) use HTML as a page layout
>language. Don't use tables for anything besides tables, for instance,
>and definitely don't make your entire page one big table.
>
>Really, the question looks pretty silly to those that realize what
>HTML is and what it isn't.
>
>SKQ
Shawn,
Just curious as to what your reasoning is for this reply.
It's true at one time that html could not be considered a page layout
language, but times are changing, my friend. What once was, no longer
is.
I'm not sure what anyone else's view is on this, but when I design a
website that needs to have images and text locked into place, I do
indeed use tables nested within tables, and yes, they are usually
housed in one big table for just the reason this thread was started in
the first place...to keep things looking relatively the same at
different resolutions. I always try to design for the lower end of
things...640x480, little or no java, optimized graphics, but at the
same time, I also try to keep things interesting for those who DO have
the capability to view this type of content.
True, there are still a small potential viewing audience who don't
have the latest versions of browsers, or who use browsers that can't
interpret tables correctly, and they therefore get a big mess when
trying to view a tabled site, however the majority (according to
various access logs I have viewed from different resources) of
potential viewers DO have a browser that is at least capable of
rendering the tabled pages as they should be.
Sorry for running on so long, I'll get off of my soapbox now.
I'm not trying to start a war with this, just voicing my opinion on
the subject. Any agreements and / or disputes are more than welcome.
Dave's Design Shoppe
http://www.epix.net/~rave
J.A. McCulloch
Dave Anderson wrote:
>
> In <Pine.A41.3.95a.971018110030.126654E-100000@sp055>,
> "Alan J. Flavell" <fla...@mail.cern.ch> writes:
> >...
> >But at the end of the day, what goes out from the http server is a
> >stream of content with markup in it, and when that gets rendered by an
> >arbitrary browser with arbitrary configuration, the writing is on
> ^^^^^^^^^^^^^^^^^
> >the wall.
> ^^^^^^^^
>
> WOW, I've never encountered THAT browser! :-)
>
> Dave
>
You mean that you are _not_ using a data projection system to display
your computer?
;~}
Alan J. Flavell
On Fri, 17 Oct 1997, Dave wrote:
> It's true at one time that html could not be considered a page layout
> language, but times are changing, my friend. What once was, no longer
> is.
Sure, there are many page authors who believe that HTML is a page makeup
language, and there are even numerous software packages that support
them in this conceit.
But at the end of the day, what goes out from the http server is a
stream of content with markup in it, and when that gets rendered by an
arbitrary browser with arbitrary configuration, the writing is on
the wall.
Dave Anderson
In <Pine.A41.3.95a.971018110030.126654E-100000@sp055>,
"Alan J. Flavell" <fla...@mail.cern.ch> writes:
>...
>stream of content with markup in it, and when that gets rendered by an
>arbitrary browser with arbitrary configuration, the writing is on
>the wall.
^^^^^^^^
WOW, I've never encountered THAT browser! :-)
Dave
PS: My thanks to you, and to the others here who actually know their asses
from their elbows, for consistently providing useful information in the
morass of flames and unsupported assertions.
--
Dave Anderson (da...@daveanderson.com)
Lester S. Garrett
On Fri, 17 Oct 1997 21:02:12 GMT ra...@epix.net (Dave) wrote in
comp.infosystems.www.authoring.html:
> On 16 Oct 1997 22:43:57 GMT, skq...@brokersys.com (Shawn K. Quinn -
> NO JUNK E-MAIL) wrote:
>>>In message <34462C...@julian.uwo.ca>, David Le Sauvage
>>><dles...@julian.uwo.ca> wrote:
>>>Is there any way to code for both 800x600 and 640x480 so that things
>>>don't get out of alignment?
>>Sure there is, don't (try to) use HTML as a page layout
>>language. Don't use tables for anything besides tables, for instance,
>>and definitely don't make your entire page one big table.
>>Really, the question looks pretty silly to those that realize what
>>HTML is and what it isn't.
> Just curious as to what your reasoning is for this reply.
> It's true at one time that html could not be considered a page layout
> language, but times are changing, my friend. What once was, no longer
> is.
Actually, if you take a thoughtful look at the HTML 4.0 draft you'll discover
that you've got that exactly backwards. The 4.0 draft makes it clear that HTML
is moving *_AWAY_* from the layout approach prompted by NS and MSIE.
-={lsg}=-
Victoria Garcia
Shawn wrote earlier:
**************don't (try to) use HTML as a page layout
>>language. Don't use tables for anything besides tables, for >instance, and
definitely don't make your entire page one big >table.
>>Really, the question looks pretty silly to those that realize what
>>HTML is and what it isn't.
>Shawn,
************** I'm sorry Shawn, but I Totally disagree...
(Just my opinion...) =P
Dave replied:
>Just curious as to what your reasoning is for this reply.
>It's true at one time that html could not be considered a page >layout
language, but times are changing, my friend. What once >was, no longer
is............................................................
> Any agreements and / or disputes are more than welcome.
>Dave's Design Shoppe
>http://www.epix.net/~rave
Dave,
I have to agree with you on this subject...
I had a major ordeal when I was creating our website at work. First, I
created it according to the resolution I had at home...however, when I asked
other people's opinion on it, as they viewed it from their own
computers....ahhhh....I was soooo upset...things were all messed up!
Especially, when people had the easy option of making the font larger or
smaller on Internet Explorer...
But finally I learned that I could arrange the webpages to be viewed by
everyone...including those who have a 640x480 resolution. I finally
accomplished my goal by using tables the right way. The trick is to become
acquainted with the right pixel size of the columns, the rows, or the cells.
I definitely prefer to use pixel size than the percentage. It is more
difficult to keep my text and my pictures fixed in a specific place when I
use % numbers.
Goodness...I had never tried this newsgroup stuff before....I'm really
starting to like it! =)
Gee...now I'm trying to figure out if Dave's question hasn't been answered
yet. Well, the webpage that I told you about guys is:
http://www.mdcc.edu/north/honors
Here you can see what pixel size I used for my menu column on the left hand
side...I obviously used pictures for the menu text to make sure that no
matter who viewed it, it wouldn't go over the table borders I had set!
Vick
E-Mail: vick...@usa.net
Shawn K. Quinn - NO JUNK E-MAIL
In message <3447cfc8...@newsserver.epix.net>, Dave <ra...@epix.net> wrote:
>On 16 Oct 1997 22:43:57 GMT, skq...@brokersys.com (Shawn K. Quinn -
>NO JUNK E-MAIL) wrote:
>
different screen resolutions]
>>Sure there is, don't (try to) use HTML as a page layout
>>language. Don't use tables for anything besides tables, for instance,
>>and definitely don't make your entire page one big table.
>>
>>Really, the question looks pretty silly to those that realize what
>>HTML is and what it isn't.
>
>
>Just curious as to what your reasoning is for this reply.
>It's true at one time that html could not be considered a page layout
>language, but times are changing, my friend. What once was, no longer
>is.
HTML never was a page layout language. The addition of tables to HTML
was added for the purpose of being able to put small tables like you'd
see in a book on a web page, and for that purpose it works rather well
(okay, better than putting it in a PRE element). Tables were never
meant for including an entire page in a table for layout
purposes. This is not reasoning, this is FACT. Plain and simple.
If you want page layout, use PDF or TeX.
>I'm not sure what anyone else's view is on this, but when I design a
>website that needs to have images and text locked into place, I do
>indeed use tables nested within tables, and yes, they are usually
>housed in one big table for just the reason this thread was started in
>the first place...to keep things looking relatively the same at
>different resolutions. I always try to design for the lower end of
>things...640x480, little or no java, optimized graphics, but at the
>same time, I also try to keep things interesting for those who DO have
>the capability to view this type of content.
You're not designing for the "lower end of things." I hate to break it
to you but the "lower end of things" includes users that *can't see*
and/or are confined to text only terminals, using browsers like
Emacs-W3, Lynx, and the CERN linemode browser. (Yes, there are other
text mode browsers besides Lynx.)
While I detest browser specific design as a rule, you usually can't be
too wrong by designing for Lynx and worrying about the look under
Communicator or Internet Explod^Hrer later.
>True, there are still a small potential viewing audience who don't
>have the latest versions of browsers, or who use browsers that can't
>interpret tables correctly, and they therefore get a big mess when
>trying to view a tabled site, however the majority (according to
>various access logs I have viewed from different resources) of
>potential viewers DO have a browser that is at least capable of
>rendering the tabled pages as they should be.
When browsing the web with Lynx, or sometimes even with Navigator 4.03
with automatic image loading and Javascript turned off, I consider it
my solemn duty to drop commentary into the webmaster's box about how
hard a site is to manuever under my configuration.
The emphasis needs to be on the first two words in "World Wide Web."
>Sorry for running on so long, I'll get off of my soapbox now.
>I'm not trying to start a war with this, just voicing my opinion on
>the subject. Any agreements and / or disputes are more than welcome.
Sorry for ruining your utopia. I'll go back to browsing the World Wide
Web now. I'm not trying to start a war either, just stating the facts.
--
Shawn K. Quinn - e-mail: skq...@brokersys.com
home page: http://www.brokersys.com/~skquinn/
worthless dreck: http://www.brokersys.com/~skquinn/spamsucks.html
The inclusion or sale of my e-mail address in a mailing list is not permitted
without my prior consent by subscription.
Christopher Griffin
On Fri, 17 Oct 1997 21:02:12 GMT, ra...@epix.net (Dave) wrote:
>I'm not sure what anyone else's view is on this, but when I design a
>website that needs to have images and text locked into place, I do
I find that the "requirement" that text and images to be locked in
place are usually quite bogus. It very nealry always the case that
you can design and structure your page without using tables to get the
desired result.
Letting the text and images appear as placed by the browser fitting to
the available display is a very POWERFUL way of dealing with the
question of "which resolution do I design for" because the question
becomes irreleveant.
You also failed to mention that the the fabled "640x480" resolution
design target is a red herring since the available display space
varies by browser, user configuration of the browser (show toolbar,
etc.), and the actual size the browsing window is set to.
All of this assumes a graphic browser with images loaded. What about
non-graphical browsers and those with image loading off?
Alan J. Flavell
On 23 Oct 1997, W2N wrote:
> As usual the group has turned the proposed question into a battle of
> ideologies.
There need be no battle. There are points of view ranging between two
extreme positions, each supported by their respective arguments.
Readers are invited to evaluate the arguments on the basis of their
content, rather than on the temperature of their invective.
> "Is there any way to code for both 800x600 and 640x480 so that things
> don't get out of alignment?"
>
> The answer is "YES" ,
...on a limited range of browsing situations...
> regardless of what the people say within this forum,
If you say so...
> "Forcing" a page to your design is not only common
"Forcing" an author's un-co-operative page to fit the reader's
browsing situation is also common, on the WWW. You are free to
either work with it or fight against it.
> but is perfectly acceptable
To whom? Other "designers", I suspect.
> PROFESSIONAL designers,(those who get paid
Sure, the facts of life, protocols of the Internet, laws of physics, are
simply different if you get paid. The reader still gets the
document, delivered to their browsing situation, and their browser
still does what it does. It has no idea how much was paid for the
design of the page.
> and are
> respected nationally),
...Like Jakob Nielsen, perhaps???
> As far as how to do this....Do some sufing and download the HTML of some
> dynamic sites.
Please define "dynamic", in the context of authoring HTML for the WWW.
> P.S. there are companies that make software that aids blind people with
> interactivity(Henter-Joyce for one...), and according to the U.S. trades
> commission MSIE and to a certain extent Netscape Navigator, areBY FAR the most
> widely used browsers in the US and its provinces.
Was that supposed to demonstrate a principle of logic, or what?
Perhaps for the further education of non-USAns you could enlighten
us on what its "provinces" are?
--
... So the more authors concentrate on exploiting Netscape
features, the more attractive Opera becomes.
(Liam Quinn, WDG)
Aidan Fabius
> On 23 Oct 1997, W2N wrote:
>
> > P.S. there are companies that make software that aids blind people with
> > interactivity(Henter-Joyce for one...), and according to the U.S. trades
> > commission MSIE and to a certain extent Netscape Navigator, areBY FAR
> > the most widely used browsers in the US and its provinces.
>
> Perhaps for the further education of non-USAns you could enlighten
> us on what its "provinces" are?
Didn't you hear? The Russians exchanged the US's drinking water with vodka
and while the Americans were laying around in a drunken stupor, Canada
invaded and took over. Wait a minute, that's the wrong newsgroup... ;-)
----
Aidan Fabius, Web Publisher and University Student
afa...@undergrad.math.uwaterloo.ca.blah (you know the deal...)
http://www.undergrad.math.uwaterloo.ca/~afabius/
** I speak for myself and not for Corel Corporation, blah blah blah. **
W2N
As usual the group has turned the proposed question into a battle of
with, is "Is there any way to code for both 800x600 and 640x480 so that things
don't get out of alignment?"
The answer is "YES" , regardless of what the people say within this forum,
"Forcing" a page to your design is not only common but is perfectly acceptable
on the world wide web. PROFESSIONAL designers,(those who get paid and are
respected nationally), do so all the time...Check out the work of M.
Butterick, L. Lemay, P. Vachier, the list goes on.
As far as how to do this....Do some sufing and download the HTML of some
dynamic sites. Some people use tables that adjust to the width and heigth of
the browser, some use JavaScript to resample the artwork before its displayed,
and some people make different pages for different window sizes and
resolutions. It just takes some wandering around and looking at other sites
to determine whats best for your target audience.
Hope this was of some help....after all Im only an amateur....
Jude Crouch
In comp.infosystems.www.authoring.html Alan J. Flavell <fla...@mail.cern.ch> wrote:
> On 23 Oct 1997, W2N wrote:
> > P.S. there are companies that make software that aids blind people with
> > interactivity(Henter-Joyce for one...), and according to the U.S. trades
> > commission MSIE and to a certain extent Netscape Navigator, areBY FAR the most
> > widely used browsers in the US and its provinces.
> Perhaps for the further education of non-USAns you could enlighten
> us on what its "provinces" are?
Maybe s/he is referring to the last definition - A country or
region conquered by the Romans and administered by them as a
self-contained unit.
Jude
--
Jude Crouch (jcr...@pobox.com) - Computing since 1967!
Crouch Enterprises - Telecom, Internet & Unix Consulting
Oak Park, IL 708-848-0145 URL: http://www.pobox.com/~jcrouch
Dave
On 23 Oct 1997 10:58:55 GMT, w...@aol.com (W2N) wrote:
<snip---snip>
Okay, since I started this whole thing, I guess it's time to respond
yet again, which is prob just going to throw more gasoline on the fire
anyway no matter what I say, but since I'm a glutton for
punishment....
So I am one of those evil designers who exploits html and tries to
make it what it isn't...a page layout language. Fine, I accept the
fact that html is not a page layout language., but I'll be damned if
I'm going to design for the minority of potential viewers who are
running text only browsers when there are so many exciting things
which can be done with content these days. I put in text links on all
of the pages for those who are graphically disadvantaged and yes, I
have a copies of Lynx, Mosaic, et al which I use to check out my sites
to see just how awful an experience they are to all of you who so
kindly (and frequently) point out that Netscape and IE are not the
only browsers out there. Guess what? Even though I use tables and
nested tables for the sites, they still look just fine! The content is
all there in black and white (or whatever colors of text are in your
flavor of browser)
Geez, people, can't we all just get along? You design your way and
I'll design my way and if that makes me an "idiot who doesn't know
their ass from their elbow" then so be it.
Bill Bereza
Victoria Garcia wrote:
>
> But finally I learned that I could arrange the webpages to be viewed by
> everyone...including those who have a 640x480 resolution. I finally
> accomplished my goal by using tables the right way. The trick is to become
> acquainted with the right pixel size of the columns, the rows, or the cells.
> I definitely prefer to use pixel size than the percentage. It is more
> difficult to keep my text and my pictures fixed in a specific place when I
> use % numbers.
Blah, I paid a few hundred dollars extra for good graphics card and
monitor so I could look at a web site all scrunched up on one side of
my browser window? And then the annoying text constantly scrolling
across the bottom of the browser window, which is totally useless.
It's simply repeating the same information already on your page, but
now I'm now able to see where I'd be going if I clicked on one of your
links.
And your text will still flow over the border if I have a larger font
size.
What was the point of even using fixed-width tables? Why should people
with good graphics be forced to read text in a narrow column like
that? And what about someone who has their browser *window* set to a
narrower size than you expected?
And really, the page is actually pretty good, if you hadn't decided on
using useless "features" to force your standard, boring look on
everyone looking at your page. "Intellectual Quest for Excellence" my
ass.
My idea of an interesting page (besides interesting content) is one
that looks good no matter how I look at it.
--
Bill Bereza ber...@pobox.com http://www.pobox.com/~bereza/
Beware of all enterprises that require new clothes.
Dave Anderson
>their ass from their elbow" then so be it.
That sounds like an almost-quote from something I posted a few days ago.
I haven't looked at any of your pages, but if your approach is actually as
you described it here then my disagreements with you are not major and I
don't think that the comment applies to you. I do think that anyone who
doesn't use one of the easily-available validators is foolish, since they
do such a good job of finding many things which are likely to cause
unpredictable behavior, but the most important issue (for me) is whether
the site content is available to everyone regardless of how the site's
creator achieves this effect.
The people I loathe are those who create sites which are inaccessible for
no good reason: the ones who never use text when they can substitute a
graphic (and *never* provide ALT text), the ones who use frames and don't
bother to provide NOFRAMES content (or who stick in only a snotty "get a
decent browser, turkey" line), etc, etc; in general, the ones who seem to
feel that they are God and that the needs and desires of the people trying
to access the content of their sites are of no importance at all.
Dave
-------------------------------------
Dave Anderson (da...@daveanderson.com)
Dave
On 24 Oct 1997 14:04:46 GMT, Jude Crouch <jcr...@Mercury.mcs.net>
wrote:
>I don't think that there is anything wrong with your perspective.
>But, I also think that you would benefit first from understanding
>HTML from a structural perspective. I took the liberty of choosing
>one of your reference links - http://www.hsv.tis.net/~rew/kansas.html
>to inspect the code. I choose it randomly.
>
Jude, Chris and Dave,
Thank you for your insightful comments. 'Tis true, I am guilty of not
using the readily available validators (a fact which I see I must
remedy in the very near future). however, the page referenced above,
is not my coding. I only helped out a friend by designing some
graphics and giving some tips on coding (not enough evidently).
I'm sure that my own coding could use some validation as well, but I
like to think that I do a pretty decent job when it does come up
looking well in a variety of browsers.
I suppose my problem stems from the fact that I am and have been in
the Graphic Design field for a number of years now and I'm trying to
make things that happen on the printed page happen on a web page.
I do understand your points, however, and I realize that especially on
the web, you can't please everyone. Sure I'm biased to the "big two"
(read: NN and IE) and with good reason, as some of the posts will back
up, but I will always put in text links and use the good ole alt tags
(unless I get sloppy and forget one or two, hey I'm human ;-)
Anyway, thanks again for the comments and feedback
I have some pages to go validate now
Jude Crouch
In comp.infosystems.www.authoring.html Dave <ra...@epix.net> wrote:
> On 23 Oct 1997 10:58:55 GMT, w...@aol.com (W2N) wrote:
> <snip---snip>
> Okay, since I started this whole thing, I guess it's time to respond
> yet again, which is prob just going to throw more gasoline on the fire
> anyway no matter what I say, but since I'm a glutton for
> punishment....
> So I am one of those evil designers who exploits html and tries to
> make it what it isn't...a page layout language. Fine, I accept the
> fact that html is not a page layout language., but I'll be damned if
> I'm going to design for the minority of potential viewers who are
> running text only browsers when there are so many exciting things
> which can be done with content these days. I put in text links on all
> of the pages for those who are graphically disadvantaged and yes, I
> have a copies of Lynx, Mosaic, et al which I use to check out my sites
> to see just how awful an experience they are to all of you who so
> kindly (and frequently) point out that Netscape and IE are not the
> only browsers out there. Guess what? Even though I use tables and
> nested tables for the sites, they still look just fine! The content is
> all there in black and white (or whatever colors of text are in your
> flavor of browser)
I don't think that there is anything wrong with your perspective.
But, I also think that you would benefit first from understanding
HTML from a structural perspective. I took the liberty of choosing
one of your reference links - http://www.hsv.tis.net/~rew/kansas.html
to inspect the code. I choose it randomly.
On about line 6, I found:
<H2><P ALIGN=CENTER>The On-line Resource for Kansas Fans</H2>
What happens here is that the <H2> is invoked, then immediately
terminated by the <P>. Browser then ignores the </H2> since
the original <H2> is no longer open. Better to use
<H2 ALIGN=CENTER>, no? Does it render in all situations? Probably.
Does it render the way you think you designed it? Probably not.
Another thing I noticed was extensive use of the <LI> outside of
a <UL> or <OL>. I bet you did that to indent, but it is non-standard
and any particular browser might choke on it. Will future browsers
render it the way you think it should be rendered? Only the gods
can tell.
Do these things make your design wrong? No. They make your
markup unpredictable. Would it be to your advantage to know that
the markup will work on all browsers now and in the future? Your call.
Can I mention, the ALT= attributes. These give clues to those
who have graphics off or those who use alternate methods of browsing.
Where you used them they were correct. But it's really good to
always use them, even if they are null (ALT=""). Otherwise browsers
like lynx shows [IMAGE] [INLINE] [IMGMAP]. Looks kinda junky.
It's so easy to put these attributes in, why not make it part of
your normal design?
One last point. I assume you are designing and/or creating web
sites for a living. From a business point of view your reference
pages are your portfolio. Anyone can send your pages through
a linter or validator and see that your markup is non-standard.
If you are in competition with others (which you ARE), you could
lose out only because your pages show nonstandard use of HTML,
even if your visual design is good.
> Geez, people, can't we all just get along? You design your way and
> I'll design my way and if that makes me an "idiot who doesn't know
> their ass from their elbow" then so be it.
I guess this is all in the eye of the beholder. I don't think
that my above comments mean that WE don't get along, I'm only
giving you food for thought. But if you take my comments to heart,
you may not become a better designer but your designs will become
more predictable.
> Dave's Design Shoppe
> http://www.epix.net/~rave
Christopher Griffin
>One last point. I assume you are designing and/or creating web
>sites for a living. From a business point of view your reference
>pages are your portfolio. Anyone can send your pages through
>a linter or validator and see that your markup is non-standard.
>If you are in competition with others (which you ARE), you could
>lose out only because your pages show nonstandard use of HTML,
>even if your visual design is good.
That's a very good point a deserves some re-inforcement. A company
looking for a designer won't just be looking at your work. They will
be looking at your work in comparison to others. A portfolio of sites
that validate, and work well under a variety of conditions will
provide you with an edge over somebody whose site does neither.
Remember also that although many here spout statistics about the
dominance of the Wintel platform and NS and IE, when your work is
reviewed, it's going to be reviewed by one or two key people who may
not be using the "common" configuration.
Steve Davis
Jude Crouch wrote:
>
> Can I mention, the ALT= attributes. These give clues to those
> who have graphics off or those who use alternate methods of browsing.
> Where you used them they were correct. But it's really good to
> always use them, even if they are null (ALT=""). Otherwise browsers
> like lynx shows [IMAGE] [INLINE] [IMGMAP]. Looks kinda junky.
> It's so easy to put these attributes in, why not make it part of
> your normal design?
Not sure about that pov. Sure, I do the alt thing... but if *my* chosen
default browser did things like that I'd change to another one, and not try to
proselytise about the need to look after one particular browser. I can't
really understand why people persist with a substandard model. (And yes, I've
heard the arguments... no need for repetition unless there's something new to say.)
> One last point. I assume you are designing and/or creating web
> sites for a living. From a business point of view your reference
> pages are your portfolio. Anyone can send your pages through
> a linter or validator and see that your markup is non-standard.
> If you are in competition with others (which you ARE), you could
> lose out only because your pages show nonstandard use of HTML,
> even if your visual design is good.
In my experience, business people DO NOT GIVE A STUFF about validation (and
rightly so). Take a look at www.nfl.com f'r'instance. Design, impact, hits and
market penetration are what count. For better or worse, pure HTML 3.2 simply
does not hack it on those terms.
Dave wrote:
> > Geez, people, can't we all just get along? You design your way and
> > I'll design my way and if that makes me an "idiot who doesn't know
> > their ass from their elbow" then so be it.
Some hope, Dave.
Jude wrote:
> ...But if you take my comments to heart,
> you may not become a better designer but your designs will become
> more predictable.
Exactly!!! Exactly!!! And, as every creative knows, predictable is another
word for...
...dull.
And worse, 'dull' in this business is a synonym for NO SALE.
Steve Davis
Eric Bohlman
Dave (ra...@epix.net) wrote:
: I suppose my problem stems from the fact that I am and have been in
: the Graphic Design field for a number of years now and I'm trying to
: make things that happen on the printed page happen on a web page.
In print, you have control over the final delivery medium. Assuming you
have a decent press, all the pages you produce will look the same (that's
why printing presses are so expensive. It doesn't cost much to make a
machine that puts marks on a page. It costs a lot to make a machine that
puts the same marks in exactly the same place on every single page it
produces).
On the Web, you have no control over the final medium. There are
unavoidable differences in the way your content is going to be rendered.
Therefore, in order to get the largest number of people to appreciate
your content, you need to mark it up according to its logical structure
and let their user agents (typically browsers, but also search engines
and other tools) try to render it in the best way possible, given the
constraints imposed by their particular final delivery media (the details
of which are known to the user agent, but not to the author). The
alternative, trying to optimize the presentation of your content on your
own user agent, falls on its face because the way your content will be
presented in browsing situations that differ from your own will wind up
looking worse (possibly to the point of unreadability) than they would be
if you just let the local browsers determine how to present your material.
Alan J. Flavell
On Fri, 24 Oct 1997, Steve Davis wrote:
> Jude Crouch wrote:
> >
> > always use them, even if they are null (ALT=""). Otherwise browsers
> > like lynx shows [IMAGE] [INLINE] [IMGMAP]. Looks kinda junky.
> > It's so easy to put these attributes in, why not make it part of
> > your normal design?
>
> Not sure about that pov. Sure, I do the alt thing... but if *my* chosen
> default browser did things like that I'd change to another one,
There's no need. With a single keystroke, Lynx can be told to assume
null ALT texts for IMGs that don't have them. Naturally this is now
a matter of opinion, but I tend to think that ALT="" is the mark of an
author who has thought about it and decided on an answer, whereas the
absence of an ALT attribute is the mark of an author who hasn't thought
about it and/or doesn't care. In that sense, Lynx's default option, as
exhibited above, serves as a simple bogosity detector.
> I can't
> really understand why people persist with a substandard model. (And yes, I've
> heard the arguments... no need for repetition
Good, then I'll confine myself to remarking that I can't really
understand why some people persist in criticizing people's choice of
browser when they've been given repeated explanations. This group is
about _authoring_ HTML for the WWW, not for belittling readers' browser
selection.
Jude Crouch
In comp.infosystems.www.authoring.html Steve Davis <ste...@dircon.co.uk> wrote:
> Jude Crouch wrote:
> >
> > Can I mention, the ALT= attributes. These give clues to those
> > who have graphics off or those who use alternate methods of browsing.
> > Where you used them they were correct. But it's really good to
> > like lynx shows [IMAGE] [INLINE] [IMGMAP]. Looks kinda junky.
> > It's so easy to put these attributes in, why not make it part of
> > your normal design?
> Not sure about that pov. Sure, I do the alt thing... but if *my* chosen
> default browser did things like that I'd change to another one, and not try to
> proselytise about the need to look after one particular browser. I can't
> really understand why people persist with a substandard model. (And yes, I've
> heard the arguments... no need for repetition unless there's something new to say.)
I'd say you misunderstood me. The org poster said that he DOES use
ALT tags, and in most cases he uses them appropriately. My suggestion
is that he extend that usage to include null tags, as that will
improve the rendering under certain situations. This does not improve
the design, just the rendering. Lynx is the most typical example.
Since the org poster already knows that some people are going to
access the page with graphics off or be incapable of rendering with
graphics intact (after all, he DOES use the ALT attribute), extending
the markup to include null descriptions is not an unreasonable
suggestion IMHO. Nor does it change the design of the work.
> > One last point. I assume you are designing and/or creating web
> > sites for a living. From a business point of view your reference
> > pages are your portfolio. Anyone can send your pages through
> > a linter or validator and see that your markup is non-standard.
> > If you are in competition with others (which you ARE), you could
> > lose out only because your pages show nonstandard use of HTML,
> > even if your visual design is good.
> In my experience, business people DO NOT GIVE A STUFF about validation (and
> rightly so). Take a look at www.nfl.com f'r'instance. Design, impact, hits and
> market penetration are what count. For better or worse, pure HTML 3.2 simply
> does not hack it on those terms.
While www.nfl.com does not validate totally as HTML 3.2, most
of the validation errors are minor and I would guess that the
pages will be rendered predicably. The most common errors
on that page are 1) required attribute ALT not specified;
2) attribute value must be a literal (they didn't quote the
value of HREF= ); 3) value of NAME must be a single token (they
used two or more words seperated by a space).
Mostly, the page is pure HTML 3.2: no use of proprietary
extensions, or tricks to accomplish layout, like the proverbial
one-pixel graphics or the use of <LI> to accomplish indentation.
I would surmise that this page would render, predicably, in any
graphics-based browser. It also renders quite well in the
character-based lynx browser.
Business people DO GIVE A STUFF about validation, they just don't
know it. When the page is designed and shown to the exec for
approval, it is generally shown using the browser installed at
the offices. But when that exec goes home and uses a competing
browser and doesn't get the same results, the exec questions
whether this will also happen to others. Will it look acceptable
when shown on an early AOL browser or an early version of NS
or EI? It DOES matter. Since it's nearly impossible for the
designer to check how it looks in every browser, validation
becomes the most important tool to assure this quality.
And, if the designer is looking to increase their business by
working for a large design shop, the execs there will most
definately and directly know about validators and the importance
of their use.
SIDENOTE: I don't know much about the NFL, but I know that the
baseball leagues are sanctioned by the US govt. Anyone with
a legal relationship with the govt is required to comply with
the Americans with Disabilities Act. ALT= attributes work
toward this end, since they increase the usefulness of the
WWW to sight-impaired persons. It's much easier to use ALT=
tags than to fight a lawsuit over them. -ENDNOTE-
> Dave wrote:
> > > Geez, people, can't we all just get along? You design your way and
> > > I'll design my way and if that makes me an "idiot who doesn't know
> > > their ass from their elbow" then so be it.
> Some hope, Dave.
> Jude wrote:
> > ...But if you take my comments to heart,
> > you may not become a better designer but your designs will become
> > more predictable.
> Exactly!!! Exactly!!! And, as every creative knows, predictable is another
> word for...
> ...dull.
> And worse, 'dull' in this business is a synonym for NO SALE.
I guess I used a poor choice of words. I didn't mean a predictable
design - I meant a predictable rendering. I'm glad you caught my
error.
Bill Bereza
Steve Davis wrote:
> In my experience, business people DO NOT GIVE A STUFF about validation (and
> rightly so). Take a look at www.nfl.com f'r'instance. Design, impact, hits and
> market penetration are what count. For better or worse, pure HTML 3.2 simply
> does not hack it on those terms.
>
Gee, I'm sure the popularity of the www.nfl.com or www.nbc.com or
www.cnn.com, etc. has _nothing_ to do with the fact that NBC, CNN and
NFL are extremely popular outside of the web, and people would flood
these pages if there was a 404 message there. Real HTML 3.2 would not
make these pages less popular, (the popularity exists because of a
built-in audience). It would be easier and more accessible, and it
wouldn't even have to be duller.
Veronica Karlsson
Bill Bereza wrote:
>
> Victoria Garcia wrote:
[ 8< ]
>
> Blah, I paid a few hundred dollars extra for good graphics card and
> monitor so I could look at a web site all scrunched up on one side of
> my browser window? And then the annoying text constantly scrolling
> across the bottom of the browser window, which is totally useless.
> It's simply repeating the same information already on your page, but
> now I'm now able to see where I'd be going if I clicked on one of your
> links.
>
I agree, it would be so much better without that javascript.
> And your text will still flow over the border if I have a larger font
> size.
>
No, it won't. I tried the largest font size I have in my Netscape and
the text stayed nicely within the white field.
[ 8< ]
> And really, the page is actually pretty good, if you hadn't decided on
> using useless "features" to force your standard, boring look on
> everyone looking at your page. "Intellectual Quest for Excellence" my
> ass.
>
"standard, boring look"? I think it looks very nice! (except for that
annoying scrolling text...) :)
[ 8< ]
--
:)
Veronica Karlsson
( e93...@sm.luth.se http://www.ludd.luth.se/~vk/ )
Bill Bereza
Veronica Karlsson wrote:
>
> Bill Bereza wrote:
> >
> > And your text will still flow over the border if I have a larger font
> > size.
> >
>
> No, it won't. I tried the largest font size I have in my Netscape and
> the text stayed nicely within the white field.
>
I use Verdana with NC4.03 on Win95. I just kept hitting Ctrl-[
(View->Increase Font) until the text spilled out. (A bit unfair, but
it shows how it really is impossible to keep text in a fixed table no
matter what seems to work.)
>
> "standard, boring look"? I think it looks very nice! (except for that
> annoying scrolling text...) :)
>
Take away the navigation buttons and the top frame, and all there is
is plain (all centered) text on a white background. But I've noticed
that that's usually the real reason most people want to use flashy
tricks, to try to hide the boring content on their page. This page
would have been just as useful and boring if it'd been a plain old
HTML2 page. It's like taking a can of SPAM(TM)[1] and wrapping it in
pretty ribbons and paper. Open it up and you've still got ground pork.
(Not that there's anything wrong with ground pork or HTML2.)
For a page which might appear boring, yet kept me reading all the way
to the end, check out
<URL:http://www.lava.net/%7edewilson/web/rant.html>
[1] For those who don't know the real SPAM, check out
<URL:http://www.eecs.nwu.edu/~bartolin/html/spamfact.html>
Veronica Karlsson
Bill Bereza wrote:
> Veronica Karlsson wrote:
> > Bill Bereza wrote:
> > >
> > > And your text will still flow over the border if I have a larger font
> > > size.
> >
> > No, it won't. I tried the largest font size I have in my Netscape and
> > the text stayed nicely within the white field.
> >
>
> I use Verdana with NC4.03 on Win95. I just kept hitting Ctrl-[
> (View->Increase Font) until the text spilled out. (A bit unfair, but
> it shows how it really is impossible to keep text in a fixed table no
> matter what seems to work.)
>
Hmmm.... How far did you push it? Why not show us a screen shot....
(If you don't know how to make screen shots here's a Windows program
that does that: http://www.ludd.luth.se/users/vk/pics/progs/grab/ )
> > "standard, boring look"? I think it looks very nice! (except for that
> > annoying scrolling text...) :)
>
> Take away the navigation buttons and the top frame,
Why? The navigation buttons are there. (but I agree, the top frame
doesn't add anything interesting)
> and all there is
> is plain (all centered) text on a white background.
Yes, that's what I like about it :)
> But I've noticed
> that that's usually the real reason most people want to use flashy
> tricks, to try to hide the boring content on their page.
Ok, I didn't _read_ the page, but that doesn't mean there can't be
content on it.
> This page
> would have been just as useful and boring if it'd been a plain old
> HTML2 page.
As I said, I didn't read it and thus don't have an opinion about its
usefulness. What I commented about before was that it _looks_ nice.
Which means that I wouldn't mind reading a page that looked like that if
it had some contents that I was interested in...
> It's like taking a can of SPAM(TM)[1] and wrapping it in
> pretty ribbons and paper. Open it up and you've still got ground pork.
> (Not that there's anything wrong with ground pork or HTML2.)
>
> For a page which might appear boring, yet kept me reading all the way
> to the end, check out
> <URL:http://www.lava.net/%7edewilson/web/rant.html>
>
I've read it, and I don't understand why you say that "it might appear
boring".
> [1] For those who don't know the real SPAM, check out
> <URL:http://www.eecs.nwu.edu/~bartolin/html/spamfact.html>
>
But.... that page is also crunched up at one end of my fairly big
screen... And its layout is not the most impressive I've ever seen...
Bill Bereza
Veronica Karlsson wrote:
>
> Hmmm.... How far did you push it? Why not show us a screen shot....
>
I have a snap shot at <URL:http://www.pobox.com/~bereza/snap1.jpg>
> > For a page which might appear boring, yet kept me reading all the way
> > to the end, check out
> > <URL:http://www.lava.net/%7edewilson/web/rant.html>
> >
>
> I've read it, and I don't understand why you say that "it might appear
> boring".
Well, to some people it might appear boring because it doesn't use
anything special. It's mostly plain text on a plain background.
>
> > [1] For those who don't know the real SPAM, check out
> > <URL:http://www.eecs.nwu.edu/~bartolin/html/spamfact.html>
> >
>
> But.... that page is also crunched up at one end of my fairly big
> screen... And its layout is not the most impressive I've ever seen...
>
I included that reference to provide some info about what Spam is, in
case some people didn't know. I don't think it's impressive either,
but it is informative.
Veronica Karlsson
Bill Bereza wrote:
>
> Veronica Karlsson wrote:
> >
> > Hmmm.... How far did you push it? Why not show us a screen shot....
> >
>
> I have a snap shot at <URL:http://www.pobox.com/~bereza/snap1.jpg>
>
You're right. I tried again, this time I changed my font as well as my
font size and then I got the same result... :(
> > > For a page which might appear boring, yet kept me reading all the way
> > > to the end, check out
> > > <URL:http://www.lava.net/%7edewilson/web/rant.html>
> > >
> >
> > I've read it, and I don't understand why you say that "it might appear
> > boring".
>
> Well, to some people it might appear boring because it doesn't use
> anything special. It's mostly plain text on a plain background.
>
Just plain text in itself doesn't look boring to the person who has come
to a page looking for that particular thing that the page is about.
> >
> > > [1] For those who don't know the real SPAM, check out
> > > <URL:http://www.eecs.nwu.edu/~bartolin/html/spamfact.html>
> > >
> >
> > But.... that page is also crunched up at one end of my fairly big
> > screen... And its layout is not the most impressive I've ever seen...
> >
>
> I included that reference to provide some info about what Spam is, in
> case some people didn't know. I don't think it's impressive either,
> but it is informative.
>
Exactly! The page may look boring with just a long mass of text, but it
_contains_ something interesting which makes people read it and enjoy
it. :)
HarryH
In article <34510639...@dircon.co.uk>, ste...@dircon.co.uk says...
>In my experience, business people DO NOT GIVE A STUFF about validation (and
>rightly so). Take a look at www.nfl.com f'r'instance. Design, impact, hits
and
>market penetration are what count. For better or worse, pure HTML 3.2 simply
>does not hack it on those terms.
If you can't design a high impact web site using pure HTML 3.2, then I
suggest you get out of the web business. Conforming to the standard is what
gets the hits and market penetration. Good, clean, even pleasing design can
be done with HTML 3.2. Abusing it will simply turn away people/potential
customers. Would you turn away hundreds of thousands of potential customers?
For impact, use JavaScript.
How are you going to penetrate the market if people:
1. Quit waiting for those animations after 20 secs.
2. Does not want to load new plug-ins.
3. In a hurry and don't want to look at image maps/animations
4. Hates the "look" of the web site.
5. Have outdated program and computers.
Hints: most business people are ignorant of new technology, have no time, and
on a very tight budget.
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Steve Davis
HarryH wrote:
>
> In article <34510639...@dircon.co.uk>, ste...@dircon.co.uk says...
> >In my experience, business people DO NOT GIVE A STUFF about validation (and
> >rightly so). Take a look at www.nfl.com f'r'instance. Design, impact, hits and
> >market penetration are what count. For better or worse, pure HTML 3.2 simply
> >does not hack it on those terms.
>
> If you can't design a high impact web site using pure HTML 3.2, then I
> suggest you get out of the web business.
[replies in kind] I suggest you keep suggestions like that to yourself; Unless
you want me to state publicly what I think you should do.
> Conforming to the standard is what
> gets the hits and market penetration.
Who told you that? I guarantee it wasn't *experience*. Pray, tell me how this
'fact' works?
> Good, clean, even pleasing design can
> be done with HTML 3.2.
Indeed. Sometimes it is sufficient.
> Abusing it will simply turn away people/potential
> customers.
Rubbish. People don't validate your pages - they read them. You've
overgeneralised and thus oversimplified the situation. I suggest you read your
own 'hints' (below).
> Would you turn away hundreds of thousands of potential customers?
Does this deserve an answer?
> For impact, use JavaScript.
Oh? What's that? }:)
> How are you going to penetrate the market if people:
> 1. Quit waiting for those animations after 20 secs.
Don't put animations up for the sake of it. Most animations distract from your
message. Some are enlightening and enhance your message. The decision of which
of these instances may apply (in a free society) is the moral right of the author.
> 2. Does not want to load new plug-ins.
Don't use proprietary formats unless there is good reason.
> 3. In a hurry and don't want to look at image maps/animations
Ensure your page degrades gracefully for a variety of browsers and browser
configurations. If they're really in that much of a hurry they'll learn how to
turn off image loading / use a text browser.
> 4. Hates the "look" of the web site.
You can't please all of the people all of the time. Your design should appeal
most to those for whom the message was intended. I can't think a of single
instance where your target reader would be *everybody*.
> 5. Have outdated program and computers.
Again, graceful degradation. Ask yourself: why do people upgrade their system?
The answer to that is complex varied, and revealing about human nature.
All five points are issues of individual design. If you must wear blinkers
because you can't handle the full gamut of issues, then that does not justify
an attempt to push that strategy on everyone else (unless of course, what you
are really attempting is to neutralize your competitors' advantage!).
> Hints: most business people are ignorant of new technology, have no time, and
> on a very tight budget.
How illuminating...
> -------------------------------------------------------
> Of course I'll work on weekends without pay!
> - successful applicant
What a dope!
(reads: I don't think I can justify my salary without a major concession.)
Steve Davis
Alan J. Flavell
On Tue, 28 Oct 1997, Steve Davis wrote:
> > Good, clean, even pleasing design can
> > be done with HTML 3.2.
>
> Indeed. Sometimes it is sufficient.
>
> > Abusing it will simply turn away people/potential
> > customers.
>
> Rubbish. People don't validate your pages
True enough
> - they read them.
No Sir. They render them on browsers, and they then read (or otherwise
perceive) the result.
And that's where standards come into it.
> You've
> overgeneralised and thus oversimplified the situation.
Haven't you too?
> You can't please all of the people all of the time. Your design should appeal
> most to those for whom the message was intended.
Can't argue with that. Now tell us which browser/versions they use,
on which platforms, and with what configuration. Except in the most
specialised situations (and often, even _in_ those specialised
situations) the browser/version/platform/configurations used by
those interested have no particular relationship to the topic.
> I can't think a of single
> instance where your target reader would be *everybody*.
So much more reason to include all browsing situations, since your
_topic_ will, in and of itself, provide more than enough selectivity.
> Again, graceful degradation. Ask yourself: why do people upgrade their system?
You mean like getting a cellphone browser, or a speaking browser?
I fear you meant just getting another boring old desktop lump.
> The answer to that is complex varied, and revealing about human nature.
Aye, we agree on that. I think ;-)
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <3456CC74...@dircon.co.uk>,
Steve Davis <ste...@dircon.co.uk> wrote:
> Alan J. Flavell wrote:
> > On Tue, 28 Oct 1997, Steve Davis wrote:
> > > Rubbish. People don't validate your pages
> > > - they read them.
> >
> > No Sir. They render them on browsers, and they then read (or otherwise
> > perceive) the result.
>
> But I never rendered an html page in my life. My computer does it for me!
Exactly. But it can't do that if your documents do not comply with
standards. Oh, in the case of WWW browsers, it will try to do its best
to make sense of the errors, but a computer is essentially a dumb
thing that can only do things right if they follow the rules.
> > And that's where standards come into it.
>
> Or not... the DTD that defines 90% of instances of web authorship...
> doesn't exist!
Well, it's hardly the fault of the standard that apparently 90% of
the documents out there do not comply with it, isn't it? Heck, you
wouldn't even be *able* to write a DTD to validate most of that stuff
against.
Again, the point is that if your document is valid, you can be sure
that it can be rendered by any browser in an appropriate fashion.
Using syntactically invalid constructs, or even nonstandard elements
or attributes means that you have to rely on *error recovery* procedures
in the visitors' browsers, and there are many examples of sites that had
to be redone because those procedures changed.
- --
E-mail: gala...@htmlhelp.com ................ PGP Key: 512/63B0E665
The WDG web site is back up! http://www.htmlhelp.com/ (Well, mostly)
-----END PGP SIGNED MESSAGE-----
Steve Davis
Alan J. Flavell wrote:
>
> On Tue, 28 Oct 1997, Steve Davis wrote:
>
> > > be done with HTML 3.2.
> >
> > Indeed. Sometimes it is sufficient.
> >
> > > Abusing it will simply turn away people/potential
> > > customers.
> >
>
>
> > - they read them.
>
> No Sir. They render them on browsers, and they then read (or otherwise
> perceive) the result.
But I never rendered an html page in my life. My computer does it for me!
> And that's where standards come into it.
Or not... the DTD that defines 90% of instances of web authorship... doesn't exist!
>
> > You've
> > overgeneralised and thus oversimplified the situation.
>
> Haven't you too?
Perhaps I should have requoted my original post in full? I was responding to a
response that failed to address the issues that I raised. (Would you like me
to mail that post to you!?!)
> > You can't please all of the people all of the time. Your design should appeal
> > most to those for whom the message was intended.
>
> Can't argue with that. Now tell us which browser/versions they use,
> on which platforms, and with what configuration.
What? All of them? Ah. You think I'm talking about *desktop* publishing, don't
you? (Are you sure you don't want me to mail you a few recent posts'o'mine?)
> Except in the most
> specialised situations (and often, even _in_ those specialised
> situations) the browser/version/platform/configurations used by
> those interested have no particular relationship to the topic.
Really? I didn't see many Amigas last time I was at CERN... or instances of
Internet Explorer, come to that... nor in [insert name of academic institution
here]. Then again, I haven't see a kid playing DOOM on an SGI Onyx. Maybe I
just haven't travelled enough. ;)
> > I can't think a of single
> > instance where your target reader would be *everybody*.
>
> So much more reason to include all browsing situations, since your
> _topic_ will, in and of itself, provide more than enough selectivity.
Sometimes, Allan, you make web publishing sound like a school project! :)
> > Again, graceful degradation. Ask yourself: why do people upgrade their system?
>
> You mean like getting a cellphone browser, or a speaking browser?
If that represents an improvement in meeting your needs then, yes, it's an
upgrade.
> I fear you meant just getting another boring old desktop lump.
What's so bad about that? Nine out of ten people can't be wrong (so they say)!
> > The answer to that is complex varied, and revealing about human nature.
>
> Aye, we agree on that. I think ;-)
Yes, we probably do. [scratches head] Now, what was it we were talking about?
Sure looks to me like we came off the highway a few exits early. ;)
Steve Davis
Steve Davis
Arnoud Galactus Engelfriet wrote:
>
> Steve Davis <ste...@dircon.co.uk> wrote:
> >
> > But I never rendered an html page in my life. My computer does it for me!
>
> standards. Oh, in the case of WWW browsers, it will try to do its best
> to make sense of the errors, but a computer is essentially a dumb
> thing that can only do things right if they follow the rules.
Does this apply to a certain group of people too? *Oops* :o [braces for a flaming]
> > > And that's where standards come into it.
> >
> > Or not... the DTD that defines 90% of instances of web authorship...
> > doesn't exist!
>
> Well, it's hardly the fault of the standard that apparently 90% of
> the documents out there do not comply with it, isn't it?
No. I don't think the standard(s) is/are at fault at all. I (currently) view
them as guidelines, a kind of grammar book. Well worth knowing, but inevitably
trailing behind the living language.
> Heck, you
> wouldn't even be *able* to write a DTD to validate most of that stuff
> against.
Might be fun to try!
> Again, the point is that if your document is valid, you can be sure
> that it can be rendered by any browser in an appropriate fashion.
> Using syntactically invalid constructs, or even nonstandard elements
> or attributes means that you have to rely on *error recovery* procedures
> in the visitors' browsers...
Which work remarkably effectively, and will likely improve over time. Error
correction is of growing importance in all digital technology, because it lets
people get on with what they want to do rather than spend time nursing the
technology. Don't you wish PCs had *more* error correction?
>... and there are many examples of sites that had
> to be redone because those procedures changed.
Well, they were probably out of date anyhow. If they were intended to last
longer, they should have been more careful about their choice of language.
best,
Steve Davis
Warren Steel
Galactus wrote:
> > Again, the point is that if your document is valid, you can be sure
> > that it can be rendered by any browser in an appropriate fashion.
> > Using syntactically invalid constructs, or even nonstandard elements
> > or attributes means that you have to rely on *error recovery* procedures
> > in the visitors' browsers...
Steve Davis replied:
> Which work remarkably effectively, and will likely improve over time. Error
> correction is of growing importance in all digital technology, because it lets
> people get on with what they want to do rather than spend time nursing the
> technology.
That prediction is simply not borne out by past or
present evidence. I present examples: Netscape 1.xx
accepted attribute values with mismatched quotes, and
followed the author's intention. Netscape 2.xx did not,
resulting in large portions of the document not being
rendered at all. Why did the parser suddenly become
less forgiving? Not to encourage validation or good
coding, but to prepare for the embedded client-side
scripting of 2.xx. The parsers of NS, MSIE, and other
browsers have become *more fussy*, not less fussy,
about comment syntax, again related to the scripting
issue. Versions of Netscape from 1 to 3 have been
lenient with entities and numerical references. Many
authors are now complaining that their entities are
being rendered literally ("ü") or simply as
question marks ("???"). Why? to keep authors on
their toes? Not at all--but it's a small step in
the implementation of Unicode.
I expect that as the data of HTML documents becomes
more complex (with embedding of objects, scripts,
stylesheets, Unicode, etc.) browsers will insist on
ever greater compliance with SGML principles and HTML
specs.
> >... and there are many examples of sites that had
> > to be redone because those procedures changed.
> Well, they were probably out of date anyhow. If they were intended to last
> longer, they should have been more careful about their choice of language.
That's entirely uncalled-for. While many documents
are ephemeral, or have content that needs to be updated
regularly, other documents (e.g., online archives of
literature) may have little or no change in content.
If the markup was done right to begin with in 1994,
then it is HTML 2.0 compliant, and requires no change.
If it has sloppy quotes or sloppy entities, or blink,
or stupid background tricks, then it needs to be changed.
There are documents that have been on the Web for five
years or more. Some do not need anything more than a
DOCTYPE declaration to be validated at HTML 4.0!
Prescient? no, just smart!
--
Warren Steel mu...@olemiss.edu
Department of Music University of Mississippi
http://www.mcsr.olemiss.edu/~mudws/
Arjun Ray
In <34587966...@dircon.co.uk>,
Steve Davis <ste...@dircon.co.uk> writes:
| Arnoud Galactus Engelfriet wrote:
| > Well, it's hardly the fault of the standard that apparently 90% of
| > the documents out there do not comply with it, isn't it?
|
| No. I don't think the standard(s) is/are at fault at all. I (currently)
| view them as guidelines, a kind of grammar book. Well worth knowing,
| but inevitably trailing behind the living language.
Bad metaphor, playing on the word "language"; and dubious truth: who's
actually trailing? Would you care to substantiate this view?
(I wonder: among the people given to blithe generalizations and casual
canards regarding standards groups, how many have read the archives of
the IETF's HTML Working Group? Read RFCs 1601-3? Acquainted themselves
with IETF procedures, from e.g. <URL:http://www.ietf.org>? Really know
what the standards already provide for, what has been proposed, what
has been implemented, by whom, and when?)
| > Using syntactically invalid constructs, or even nonstandard elements
| > or attributes means that you have to rely on *error recovery*
| > procedures in the visitors' browsers...
Procedures in the plural is exactly right. Not all of them necessarily
involve error recovery, for that matter.
| Which work remarkably effectively, and will likely improve over time.
Actually, they don't, and probably they won't. Galactus has somewhat
overstated the case. The real facts have been misrepresented -- mainly
to glorify what in fact was incompetence -- for close to five years by
now.
| Error correction is of growing importance in all digital technology,
Rather, it's error detection and error prevention that are of growing
importance. Error correction (as in communications codes) is based on
information redundancy allowing the appropriate correction to be
determined: the basic context is how to reconstruct a signal that was
*correct when it was generated* but was received in some distorted
form. The extra information constrains the extent to which errors can
be detected (usually more than can be corrected) and an essentially
statistical decision on error tolerance and costs will govern how much
extra information gets to be encoded in the signal generation process.
Error recovery, OTOH, is never better than a heuristic with more or
less guaranteed loss of information. Its basic context is one where
the signal was garbled to begin with, i.e. there is nothing to
reconstruct, only to guess. There's no such thing as systematically
"correct" guessing: every heuristic comes with its attendant horrors.
Some PL/1 compilers had the charming "feature" of guessing "what you
really meant" and producing executables out of broken code without
issuing any warnings. Here, errors were being detected (which is good)
and silently "corrected" (which could be very bad.) Some early C
compilers for the x86 platform had their own idiosyncratic notions of
the language itself, such that correct programs failed to compile and
incorrect ones compiled without a hitch. Here, the error detection
mechanism was itself flawed, not only tripping on bogus errors, but
also failing to detect real errors. In the latter case, a clean
compile of a broken program would not be "error recovery" -- much less
"error correction"! -- however much it may appear to have been.
*Where it really matters*, the C-compiler example best matches the
actual situation with the behavior of the popular browsers. See
<URL:http://www.acl.lanl.gov/HTML_WG/html-wg-95q3.messages/1269.html>
The entire thread may be of interest.
| because it lets people get on with what they want to do rather than
| spend time nursing the technology.
A non sequitur. Error correction technology is like insurance, taking
measures to counteract unavoidable errors. Error recovery is something
to be avoided if at all possible, because computers are in general
rather bad at it. An ounce of prevention and all that. In neither case
is it true that computers allowing us to be lazy is the same thing as
computers allowing us to be sloppy. (Are people aware of the extent to
which WWW technology still has to be nursed, thanks to the popularity
of crippled implementations? Take a look at the "Displaying HTML code
in a page w/o rendering it" thread, for instance.)
| Don't you wish PCs had *more* error correction?
Actually, I don't. When over 30Megs of bloatware still can't get a
10-year old syntax for tags right after five years, the proper
corrections are best applied somewhere else.
:ar
Jukka Korpela
Warren Steel <mu...@olemiss.edu> writes:
> Many
> authors are now complaining that their entities are
> being rendered literally ("ü") or simply as
> question marks ("???").
A related recent observation of mine:
When reading documents by Netscape on Netscape (4.0), I frequently see
things like
anchor (anchors array)
(e.g. in Netscape's JavaScript Authoring Guide,
http://home.netscape.com/eng/mozilla/Gold/handbook/javascript/ )
which result from some people's attempts to save a few bytes
(nbsp instead of nbsp;) at the cost of violating specifications -
and getting punished later.
--
Yucca, http://www.hut.fi/u/jkorpela/
Warren Steel
Steve Davis wrote:
[ a very gentlemanly reply, allowing that "browser
leniency will probably decrease" based on past
performance and present needs ]
> > > If they were intended to last
> > > longer, they should have been more careful about their choice of language.
> > That's entirely uncalled-for...
> I don't understand the pique here... you went on to expand on the same point I
> was making (though not all background tricks are 'stupid'?).
Sorry, Steve. I was reacting to your statement
immediately preceding:
> >... and there are many examples of sites that had
> > to be redone because those procedures changed.
> Well, they were probably out of date anyhow.
which seemed to imply that longevity was not a
factor, a real possibility, or a desideratum in
web documents. It was this assertion that I
contested in my reply.
Warren Steel
Eric Bohlman wrote:
> The formal syntax (as described in grammar books) of human languages is almost
> always determined after-the-fact.
Steve Davis replied:
> Indeed. That is what I observe with HTML today, as you say, almost always.
> Just to be clear, I was not talking about the past state of html in this
> 'living language' comparison, since this quality of html was not evident when
> it was used by a restricted number of computer-literate academic
> professionals.
Perhaps Eric was alluding to the history of HTML as well.
My understanding, derived mainly from mailing list archives,
is that HTML was not a formally structured language, and
certainly not regarded as an SGML, for several years after
its creation. It appears that Dan Connolly, perhaps more
than others, fathered the concept of linking HTML to SGML.
After many participants approved of the idea (including TBL)
he generated the first DTD. This process happened in late
1992-1993, when the Web was already a reality. Not everyone
approved, though, and some ignored all attempts to formalize
the language. Indeed, some of these doubters were then
working on the code of XMosaic.
I'd be grateful for corrections of any serious
misunderstandings in the above summary.
Steve Davis
Arnoud Galactus Engelfriet wrote:
[snipped sd's cheap shot and an adult response]
> ... I know no one here who would take
> the position that it is *always* bad to deviate from the standard. It
> is sometimes necessary to write constructs that do not validate against
> a public standard, for example the "table in PRE" trick.
It takes a while to see that though... We are to understand then, that
standard html is not sufficient in all cases? Maybe the apparently opposing
opinions in this ng are not so far apart after all? [Wouldn't it be great if
it was all one huge misunderstanding?] [[damn, i did it again - just call me
'cheap shot steve' or css for short!!]]
> > > Again, the point is that if your document is valid, you can be sure
> > > that it can be rendered by any browser in an appropriate fashion.
> > > Using syntactically invalid constructs, or even nonstandard elements
> > > or attributes means that you have to rely on *error recovery* procedures
> > > in the visitors' browsers...
> >
> > Which work remarkably effectively, and will likely improve over time.
>
> "Effectively" only in limited...
[sd inserts:] ...er, almost pandemic? (IE/NS)...
>...situations, and they may change without
> notice. This can be a great annoyance, especially if you come across
> a document with an error for which the 2.0 version of your browser had
> no problems, yet the 4.0 version can't get it right anymore.
I write barely anything that lasts out the time of two revisions of the
standard. AFAICS, precious few people do. (Mind you, if I did write something
of genuine importance I'd make darn sure I wrote it in standard markup.)
> > correction is of growing importance in all digital technology, because it lets
> > people get on with what they want to do rather than spend time nursing the
> > technology. Don't you wish PCs had *more* error correction?
>
> Depends on where. If I'm putting out information[0] to a wide audience,
> I'd make damn sure that it's spell-checked and correctly formatted.
>
> [0] Or "content", if you like to speak buzz-word.
er...yes. But you've got to get the message across to that 'wide audience'
first. i.e. They have to hit your site. And isn't that the real difficulty?
> > >... and there are many examples of sites that had
> > > to be redone because those procedures changed.
> >
> > Well, they were probably out of date anyhow. If they were intended to last
> > longer, they should have been more careful about their choice of language.
>
> Eh? A few paragraphs above you've been arguing that browsers will get
> more efficient error recovery, so that invalid markup shouldn't be a
> problem anymore, and now you're saying that if you write for the long
> term, you should be more careful about your markup?
If you're talking about the majority of authorship, then longevity is unlikely
to apply. If you're talking about information of lasting value, the judgement
of the author over markup must be rather different. AFAICS, whichever case
applies, it has to be the judgement of the author that counts.
But you are right to say that there was a misconception in my argument... and
I do accept that browser leniency is unlikely to progress (Warren Steel
pointed out why in another thread).
But still the core problems remain:
*Knowingly bad markup can achieve more, in terms of communication, than 'good'
markup. Since: layout *is* content. In many circumstances the fuller
expression of that form of communication is supported widely only through
proprietary markup.
*Unknowingly bad markup is just a fact of life, due to the ease of publication
on the web. And denying public access to web authorship constitutes elitism.
(And this form of markup, in my view, is even more problematic to justify/dismiss.)
I still feel there's a long way to go here, and I don't think these
discussions are just a waste of bandwidth. It would be easier to moderate this
group than to provide a reasoned response to criticisms of its purpose; But
I'm sure that the readers of this group would agree that the latter would be
infinitely preferable.
Steve Davis
Arjun Ray
In <3459BA54...@dircon.co.uk>,
Steve Davis <ste...@dircon.co.uk> writes:
| Eric Bohlman wrote:
| > Steve Davis (ste...@dircon.co.uk) wrote:
| > : No. I don't think the standard(s) is/are at fault at all. I (currently) view
| > : them as guidelines, a kind of grammar book. Well worth knowing, but inevitably
| > : trailing behind the living language.
| >
| > This is a rather poor analogy. Human beings have a very high ability to
| > extract meaning from ambiguous or syntactically ill-formed language.
|
| And browsers have an impressive ability to extract meaning (as in meaningful
| data) from ambiguous or syntactically ill-formed language.
Do they? First consider this
=====
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN" [
<!ENTITY opt 'You can have it done '>]>
<TITLE/Trilemma/Of these three:<UL/
<LI/&opt;fast<>&opt;cheap<>&opt;right/Pick any <EM/two/.
=====
Try it on your favorite browser, and see how much meaning it extracts.
Now, is this ambiguous? Syntactically ill-formed?
On what basis do you determine ambiguity or syntactic ill-formedness?
Or do you conclude from the fact of being impressed that something
impressive must have happened?:-)
Eric Bohlman
Steve Davis (ste...@dircon.co.uk) wrote:
: No. I don't think the standard(s) is/are at fault at all. I (currently) view
: them as guidelines, a kind of grammar book. Well worth knowing, but inevitably
: trailing behind the living language.
This is a rather poor analogy. Human beings have a very high ability to
extract meaning from ambiguous or syntactically ill-formed language. The
formal syntax (as described in grammar books) of human languages is almost
always determined after-the-fact. One can deviate quite a bit from that
formal syntax and still be understood by other people (though it will
depend on who those people are. Someone whose first language isn't the
same as yours will get thrown off by deviations that a native speaker
wouldn't even notice.
Computers, OTOH, are famous for their *lack* of this ability. If they're
to "understand" a language, they need to know its complete syntax in
advance. If what they're given doesn't match the syntax, they can do
nothing more than apply a limited number of error-recovery rules. When
you use "sloppy language" with a computer, you're relying on
error-recovery to extract the meaning. When the language is HTML and the
software is a mass-market Web browser, you're relying on error-recovery
rules that are spelled out, if at all, in trade-secret-protected source
code that has a history of changing from version to version. Some of
those "rules" may not even be spelled out explicitly. And all the
evidence indicates that they're full of special cases and context
dependencies. What "works" according to experimentation may not even
"work" in another context (e.g. a certain piece of syntactically invalid
HTML may do something different inside a table than it does outside one)
and frequently will quit "working" when a new browser version comes out.
It may work today, but will it work mañana? (versions of Netscape
prior to 4.0 rendered that broken entity reference as an n with a tilde.
4.0 renders it as an ampersand followed by the letters n, t, i, l, d and e).
Steve Davis
Eric Bohlman wrote:
>
> Steve Davis (ste...@dircon.co.uk) wrote:
> : No. I don't think the standard(s) is/are at fault at all. I (currently) view
> : them as guidelines, a kind of grammar book. Well worth knowing, but inevitably
> : trailing behind the living language.
>
> This is a rather poor analogy. Human beings have a very high ability to
> extract meaning from ambiguous or syntactically ill-formed language.
And browsers have an impressive ability to extract meaning (as in meaningful
data) from ambiguous or syntactically ill-formed language. How does that show
the analogy to be poor?
> The formal syntax (as described in grammar books) of human languages is almost
> always determined after-the-fact.
Indeed. That is what I observe with HTML today, as you say, almost always.
Just to be clear, I was not talking about the past state of html in this
'living language' comparison, since this quality of html was not evident when
it was used by a restricted number of computer-literate academic
professionals.
> One can deviate quite a bit from that
> formal syntax and still be understood by other people (though it will
> depend on who those people are.
I've found that Netscape rarely notices when accessing a site designed for IE,
and vice-versa. Lynx speakers though, often have difficulty understanding the
jive of of IE/NS and need sub-titles to get the full sense of what's being
said.
> Someone whose first language isn't the
> same as yours will get thrown off by deviations that a native speaker
> wouldn't even notice.
Yes that happens with certain parts of the NS dialect, the IE dialect, ...
(You are helping this analogy along rather nicely)
> Computers, OTOH, are famous for their *lack* of this ability.
!@*%!Ł$&*^@%Ł*&@%Ł@%Ł! :o ?????? Perhaps you're quoting history here?
> If they're
> to "understand" a language, they need to know its complete syntax in
> advance.
Bzzzzzt. You appear to be saying, for instance, that since NS 2.0 won't know
the entire syntax of HTML 4 final, it won't render a thing? ....Oh, I think it will!
> If what they're given doesn't match the syntax, they can do
> nothing more than apply a limited number of error-recovery rules.
And don't *you* listen harder to someone who's speaking with a heavy accent?
.... I could go on, but you get the idea.
[snipped remainder]
Steve Davis
Steve Davis
Warren Steel wrote:
>
> Galactus wrote:
> > > Again, the point is that if your document is valid, you can be sure
> > > that it can be rendered by any browser in an appropriate fashion.
> > > Using syntactically invalid constructs, or even nonstandard elements
> > > or attributes means that you have to rely on *error recovery* procedures
> > > in the visitors' browsers...
>
> > Which work remarkably effectively, and will likely improve over time. Error
> > correction is of growing importance in all digital technology, because it lets
> > people get on with what they want to do rather than spend time nursing the
> > technology.
>
[snipped]
> ...I expect that as the data of HTML documents becomes
> more complex (with embedding of objects, scripts,
> stylesheets, Unicode, etc.) browsers will insist on
> ever greater compliance with SGML principles and HTML
> specs.
Yes. I can see that. I also failed to take into account that the use of
editors that generate markup (well, one day they'll do it acceptably) will
mean that the increasing complexity of markup/script will be hidden from the
vast majority of users. The pressure for leniency will all but evaporate. And
so, for the reasons of the increasing complexity of HTML documents that you
mention and provide examples for, and the influence of the increasing use of
effective editors/markup generators, I have to accept that browser leniency
will likely decrease.
> > If they were intended to last
> > longer, they should have been more careful about their choice of language.
>
> That's entirely uncalled-for...
I don't understand the pique here... you went on to expand on the same point I
was making (though not all background tricks are 'stupid'?).
Steve Davis
Steve Davis
Jukka Korpela wrote:
> When reading documents by Netscape on Netscape (4.0), I frequently see
> things like
> anchor (anchors array)
> (e.g. in Netscape's JavaScript Authoring Guide,
> http://home.netscape.com/eng/mozilla/Gold/handbook/javascript/ )
> which result from some people's attempts to save a few bytes
> (nbsp instead of nbsp;) at the cost of violating specifications -
> and getting punished later.
>
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <34587966...@dircon.co.uk>,
Steve Davis <ste...@dircon.co.uk> wrote:
> Arnoud Galactus Engelfriet wrote:
> > Exactly. But it can't do that if your documents do not comply with
> > standards. Oh, in the case of WWW browsers, it will try to do its best
> > to make sense of the errors, but a computer is essentially a dumb
> > thing that can only do things right if they follow the rules.
>
> Does this apply to a certain group of people too? *Oops* :o [braces for a
> flaming]
Well, this may sound strange, but I know no one here who would take
the position that it is *always* bad to deviate from the standard. It
is sometimes necessary to write constructs that do not validate against
a public standard, for example the "table in PRE" trick.
> > Again, the point is that if your document is valid, you can be sure
> > that it can be rendered by any browser in an appropriate fashion.
> > Using syntactically invalid constructs, or even nonstandard elements
> > or attributes means that you have to rely on *error recovery* procedures
> > in the visitors' browsers...
>
> Which work remarkably effectively, and will likely improve over time. Error
"Effectively" only in limited situations, and they may change without
notice. This can be a great annoyance, especially if you come across
a document with an error for which the 2.0 version of your browser had
no problems, yet the 4.0 version can't get it right anymore.
> correction is of growing importance in all digital technology, because it lets
> people get on with what they want to do rather than spend time nursing the
> technology. Don't you wish PCs had *more* error correction?
Depends on where. If I'm putting out information[0] to a wide audience,
I'd make damn sure that it's spell-checked and correctly formatted.
[0] Or "content", if you like to speak buzz-word.
> >... and there are many examples of sites that had
> > to be redone because those procedures changed.
>
> Well, they were probably out of date anyhow. If they were intended to last
> longer, they should have been more careful about their choice of language.
Eh? A few paragraphs above you've been arguing that browsers will get
more efficient error recovery, so that invalid markup shouldn't be a
problem anymore, and now you're saying that if you write for the long
term, you should be more careful about your markup?
- --
Arjun Ray
In <3459AAE6...@dircon.co.uk>,
Steve Davis <ste...@dircon.co.uk> writes:
| The pressure for leniency will all but evaporate.
There was never a pressure for leniency. There was sloppy programming
to which people adapted: a sloppy parser allowed sloppy documents to
proliferate. The loudest boosters of the Mosaic spawn come from the
ranks of people who *like* it that way. It allows them the illusion of
homeworkless thoughtless effortless expertise. The only question is
whether they will be abandoned, which means: will the Mosaic spawn
abandon their best market?
There is some chance Microsoft could: their initial strategy was to
out-Netscape Netscape in the race to the bottom. Pulling themselves
out of that hole is within the reach of their programming resources,
and they have marketing clout to sell their own brand of stupidity
once they've reduced the bleating gallery to Netscape diehards only.
With Netscape, there's no chance whatsoever. They created the market
for sloppyware. Because their programming brains couldn't do better
even if they tried. They'll simply continue to reinvent broken wheels.
:ar
Arjun Ray
In <345A41...@olemiss.edu>,
Warren Steel <mu...@olemiss.edu> writes:
| My understanding, derived mainly from mailing list archives,
| is that HTML was not a formally structured language, and
| certainly not regarded as an SGML, for several years after
| its creation.
My understanding (from the same archives:-)) is that SGML was in the
background from the beginning, in the sense that TBL's ideas for tags
were drawn from a (relatively casual?) acquaintance with SGML. You
can't go back any further in the archives than these:
<URL:http://www.eit.com/old/www.lists/www-talk.1991/0003.html>
<URL:http://www.eit.com/old/www.lists/www-talk.1991/0010.html>
where TBL is responding to mail from Dan Connolly (crossposted from
the www-interest list??)
| It appears that Dan Connolly, perhaps more than others, fathered
| the concept of linking HTML to SGML.
That's my reading too: it appears that TBL hadn't considered any
serious relationship between the two, while clearly acknowledging the
inspiration.
<URL:http://www.eit.com/old/www.lists/www-talk.1991/0026.html>
Oh, BTW, this was in response to mail from Pei Wei, the implementor of
Viola. See his response for what was on his to-do list in late 1991:
<URL:http://www.eit.com/old/www.lists/www-talk.1991/0029.html>
Scripted objects? No way! They're supposed to be brand spanking new as
of late 1997...right?;-)
| After many participants approved of the idea (including TBL)
| he generated the first DTD. This process happened in late
| 1992-1993, when the Web was already a reality.
Actually, Dan Connolly started off with a proposed DTD in an
announcement of his "grandiose scheme" in June 92.
<URL:http://www.eit.com/old/www.lists/www-talk.1992/0079.html>
He was quick to admit problems though:
<URL:http://www.eit.com/old/www.lists/www-talk.1992/0081.html>
and eventually generated the first "HTML DTD" in July:
<URL:http://www.eit.com/old/www.lists/www-talk.1992/0153.html>
He was also (AFAICT) the original proponent of adding MIME headers to
HTTP, at about the same time:
<URL:http://www.eit.com/old/www.lists/www-talk.1992/0088.html>
See TBL's comments on these developments on 11-Jun-92:
<URL:http://www.eit.com/old/www.lists/www-talk.1992/0097.html>
| Not everyone approved, though, and some ignored all attempts to
| formalize the language. Indeed, some of these doubters were then
| working on the code of XMosaic.
Mosaic wasn't started until Winter 92-93, a good six months later.
<URL:http://www.eit.com/old/www.lists/www-talk.1992/0422.html>
The Mosaic Boys didn't acquire the habit of not paying attention. They
started with it. But that's a different story.
:ar
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <345A5F26...@dircon.co.uk>,
Steve Davis <ste...@dircon.co.uk> wrote:
> Arnoud Galactus Engelfriet wrote:
> > ... I know no one here who would take
> > the position that it is *always* bad to deviate from the standard. It
> > is sometimes necessary to write constructs that do not validate against
> > a public standard, for example the "table in PRE" trick.
>
> It takes a while to see that though... We are to understand then, that
> standard html is not sufficient in all cases?
That's right. The problem is, once you go beyond the standard techniques,
you have to know what you're doing. "You can't break the rules until
you know what the rules *are*" (a quote, but who said it?)
Of course one can argue that the most important reason for this is
that most browsers are very dull in rendering standard documents, so
you need to resort to nonstandard extensions and tricks to make sure
that people using those browsers get something they can read without
getting a headache. This creates a nice vicious circle..
> Maybe the apparently opposing
> opinions in this ng are not so far apart after all?
It depends on who you talk to. Most so-called "purists" will be more
than happy to tell you how to use some nonstandard extension safely,
if that's possible. Other people know very well what the risks are in
using a particular trick, and decide to use it if they've researched
that the problems are minimal. You could call these people the
"pragmatists." A third group is the "designer" crowd, who basically
goes for "Optimized for 800x600 Netscape 3.01 for Windows 95". These
people advocate the "if it works, use it" position, without checking
if it works on *other systems* too.
The argument is mostly between the first and the last group, with the
occasional intervention by a pragmatist who wants to say something
sensible. And there are of course always a group of kooks, but hey,
that's Usenet. :-)
> > Depends on where. If I'm putting out information[0] to a wide audience,
> > I'd make damn sure that it's spell-checked and correctly formatted.
> >
> > [0] Or "content", if you like to speak buzz-word.
>
> er...yes. But you've got to get the message across to that 'wide audience'
> first. i.e. They have to hit your site. And isn't that the real difficulty?
I've actually never understood people who come here yelling that some
search engine doesn't list them. My sites seem to have no problems getting
indexed, and the people who need the kind of information I put out find
me every day. You should see my HTML-inbox some day. :-)
> *Knowingly bad markup can achieve more, in terms of communication, than 'good'
> markup.
In this particular situation, yes. But this is a rather weird situation,
mainly the result of certain browsers that are so unimaginative that you
need the bad markup to ensure that its users can read your documents.
> Since: layout *is* content.
That may very well be true, but one of the core principles of HTML is
that it is *not* a language that is to deal with layout. The original
idea was that a browser would create a good-looking page based on some
standard HTML document, but now that that hasn't caught on, the new
idea is that an author (or third party) supplies style sheets to suggest
particular renderings.
HTML for the content, PNG for the images, CSS for the layout. That
shouldn't be too difficult as a concept, right?
> *Unknowingly bad markup is just a fact of life, due to the ease of publication
> on the web. And denying public access to web authorship constitutes elitism.
Using the same argument, you could say that a publisher who refuses a
manuscript because of spelling errors is also being elitist. The mere
fact that it is *easy* and *cheap* to publish doesn't mean that all
the rules should go out of the window.
The argument becomes moot if the editor you use is capable of generating
HTML, but apparently creating such a beast is very difficult.
Colin F Reynolds
In article <3459AAE6...@dircon.co.uk>, Steve Davis
<ste...@dircon.co.uk> writes
>Yes. I can see that. I also failed to take into account that the use of
>editors that generate markup (well, one day they'll do it acceptably) will
>mean that the increasing complexity of markup/script will be hidden from the
>vast majority of users.
Highly unlikely, unless HTML's evolution stops and the language becomes
stable.
The markup-generation editors will *always* be playing catch-up.
Some used to say that programming was a dead-end skill, since the
machines would one day be able to write their own code. I don't see much
sign of that happening any day soon, either.
--
Colin Reynolds
Alan J. Flavell
On Fri, 31 Oct 1997, Steve Davis wrote:
> And browsers have an impressive ability to extract meaning (as in meaningful
> data) from ambiguous or syntactically ill-formed language.
The evidence from postings here (many of which translate to "the browser
doesn't Do what I Meant"; or sometimes "the browser used to Do what I
Meant but now it doesn't") is against you, I'd say.
Alan J. Flavell
On Fri, 31 Oct 1997, Steve Davis wrote:
> We are to understand then, that
> standard html is not sufficient in all cases?
Evidently. Hence XML, for instance.
> Maybe the apparently opposing
> opinions in this ng are not so far apart after all?
Oh, but they really are! Over on this side, _we_ say the exceptions
prove the rule.
1. Prima facie, there are published HTML standards. These are the
advertised client/server interworking standard, with which one
should comply unless there are _extremely_ good grounds for doing
otherwise. (And in addition, there are generally agreed rules of
good practice to follow, and browser bugs to work-around...).
2. Now and again, there are problems that just cannot be solved in
HTML. Graceful transition to TABLEs was a case in point. Let's take
it as a case study - I guess you are familiar with my page
http://ppewww.ph.gla.ac.uk/~flavell/tablejob.html
The original _idea_ was that browsers would tell the server whether or
not they accept HTML3. The server would then send either TABLEs or
preformatted text.
Unfortunately, this idea never got deployed. Maybe it simply wasn't
feasible, and should have been designed differently. Whatever it was,
we looked for a work-around.
One of the work-arounds considered was putting TABLE inside PRE.
Well, this was syntactically invalid. But did it actually work?
For HTML syntax that conforms with the published specifications, one
can more or less plough ahead, just keeping an eye open for possible
known browser bugs.
But for HTML syntax that violates published specifications, quite
different rules apply, Then, the onus is on the proposer to demonstrate
that it works in a wide range of browsing situations. I personally put
in quite a number of hours of testing to demonstrate that it was so,
before accepting that it was viable. And this was for just _one_,
very carefully described and specified, deviation from standard.
Quite a different approach than "toss the rulebook out of the
window and leave the browser to work it out".
There are several other deviations from published standards that I am
willing to use, but those involve the use of additional _attributes_ as
_optional_ enhancements. It is a well-established principle that client
agents are expected to ignore attributes that they don't support, so I
reckon that is harmless enough, JUST SO LONG AS nothing actually
_relies_ on those addditional attributes.
For example it would be foolish to use the HTML3.0 "ID" attribute
instead of using A NAME="..", because it would result in loss of
function on browsers that did not support it. However, coding UL PLAIN
is perfectly harmless to the content on those browsers that ignore
PLAIN; they display an unsightly but harmless bullet where it wasn't
wanted.
And I certainly have no objection to using " when it's necessary,
or putting LANGUAGE=JavaScript on a SCRIPT tag, just because they got
unaccountably omitted from HTML3.2.
BUT I see absolutely nothing in the above that says "let's toss the
rulebook out of the window and rely on browsers to Guess What I Mean".
Far from advocating widespread disregard of the rules, I say the rare
and carefully researched occasions when we are willing to bend the rules
demonstrate the value of the principle that the published interworking
standards have to be the starting point for all effective markup. And
as Galactus reminds us, you can't take a well-informed decision to
break the rules if you have no idea what the rules are.
> I write barely anything that lasts out the time of two revisions of the
> standard.
Too bad. Nevertheless, a goodly amount of work went into those
revisions in the interests of a graceful transition. It didn't always
come out right (sc. that TABLE business) but at least they tried. You
can't say the same for vendor extensions, many of which fail badly on
earlier versions of the same vendor's browser, even.
> AFAICS, precious few people do.
Well, at a time of explosive growth, most of the people authoring HTML
today hadn't started when the previous version was published, but I
don't see what that actually proves in terms of principle. I've been
trying to do content-based markup in one form or another for well over
a decade, and some reliable informants here have been doing it much
longer.
> (Mind you, if I did write something
> of genuine importance I'd make darn sure I wrote it in standard markup.)
Can I have that gold-framed?
> er...yes. But you've got to get the message across to that 'wide audience'
> first. i.e. They have to hit your site. And isn't that the real difficulty?
So much more reason to make your site accessible to the indexing robots,
eh? Will they be impressed by broken HTML?
> But still the core problems remain:
>
> *Knowingly bad markup can achieve more, in terms of communication, than 'good'
> markup.
In a few rare and specific instances, yes; but, used as a general
principle and without due research and testing, it's proven to be more
often harmful on the WWW across the wide range of actual browsing
situations.
"It _looks_ the way I intended on my one browser/version at my one
configuration setting" is no recipe for a reliable WWW document. It
most certainly does not qualify for the award of "it works".
> Since: layout *is* content.
If it is, then you better toss HTML. HTML (with or without CSS)
absolutely cannot _guarantee_ layout, and the harder you try, the worse
your pages will be. If you insist that the layout is more important
than the textual content, then you really have to find another medium,
say PDF - or indeed GIFs. And entirely exclude those readers who want
the content but cannot use the presentation.
> In many circumstances the fuller
> expression of that form of communication is supported widely only through
> proprietary markup.
Which requires proprietary browsers, and hence is antithetic to the
principles of the WWW.
What's more, it doesn't work. Proprietary formats are proven by all
experience to be a disaster. Microsoft Word cannot read Microsoft Word
files in all possible combinations, to take one example. There are
real benefits in using a published interchange format (AFAIK, MS
Word _can_ read RTF format from any other MS Word. RTF is a published
interchange format. Do you get the drift?).
There's a virtue in using a medium to the limits of its capability.
But I see no particular virtue in using a medium beyond the limits of
its capability - and then trying to blame the resulting mess on
the intended recipients.
HTML isn't the only WWW medium. In a situation where it isn't capable
of achieving what you intended, the choice is either to misuse it, or to
find the more appropriate medium. I recommend the latter, in general.
I have misused HTML, on occasion, in the privacy of my own browser, to
achieve effects that don't work on the WWW. Honestly, I'm not some
mindless pedant who follows rules for their own sake, irrespective of
any other consideration.
Nick Lilavois
Colin F Reynolds <co...@the-net-effect.com> wrote:
>In article <3459AAE6...@dircon.co.uk>, Steve Davis
><ste...@dircon.co.uk> writes
>>Yes. I can see that. I also failed to take into account that the use of
>>editors that generate markup (well, one day they'll do it acceptably) will
>>mean that the increasing complexity of markup/script will be hidden from the
>>vast majority of users.
>
>Highly unlikely, unless HTML's evolution stops and the language becomes
>stable.
Not really. Just as the language complexity evolves, especially with
XML, CSS and DSSSL, it will be increasingly more difficult to code in
order to get the look you want. Just look at Postscript- back in the
early days I used to open postscript files in CricketDraw and edit the
code to create some effects. Now I would not dream of editing a
Postscript file directly beyond changing a few header attributes.
Yes the WYSIWYG editors available now are not good and generate HTML
that is not fully compatible across possible situations, but those
products will change. (part of the problem is those companies are
thinking HTML is like postscript.)
Don't get me wrong, I hate FrontPage just as much as the next guy. For
the most part I code in Notepad- not just for HTML/JavaScript, but for
Java as well, but I see that things are evolving.
>The markup-generation editors will *always* be playing catch-up.
>
>Some used to say that programming was a dead-end skill, since the
>machines would one day be able to write their own code. I don't see much
>sign of that happening any day soon, either.
So you don't use any RAD tools at your company? How about Visual
Basic, Visual C, Authorware, Director, Cafe? No creating code with
friendly user interfaces, no "wizards" that ask you what you want in
simplistic question and answer format?
In my office, I am one of few C/Java programmers. Most of what we need
to do is handled by code generating programs and authoring systems.
I'm not saying I like it or dislike it that way, but it is the way
things are going.
It was not too long ago that to do a simple multimedia presentation
you had to code it in a C or Pascal like language. Now, you drag some
icons onto a flowchart. It used to take the knowledge of a four year
degree to make a simple data entry program, now I can show someone
with only word processor skills how to create one in about a week.
This affects standard programming environments as well- If your Visual
C/Visual Basic/Director program doesn't do what you want, what do you
do- Spend a month coding functions of your own, or get a
DLL/OCX/ActiveX/Xtra component that handles it?
Programming is certainly NOT a dead end skill, we are more in demand
than ever, but many tasks that in the past required programmers can
now be done by sales staff, graphic artists, technical writers, and
secretaries.
--
/*==============================================================*\
| Nick Lilavois Interactive Media Corporation |
| nick-l(at)worldnet.att.net nick(at)or.atinc.com |
| http://www.lilavois.com/nick http://www.interactive-media.com |
\*==============================================================*/
Steve Davis
Arnoud Galactus Engelfriet wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In article <345A5F26...@dircon.co.uk>,
> Steve Davis <ste...@dircon.co.uk> wrote:
> > Arnoud Galactus Engelfriet wrote:
> "You can't break the rules until
> you know what the rules *are*" (a quote, but who said it?)
I assume that q to be rhetorical. :)
> Of course one can argue that the most important reason for this is
> that most browsers are very dull in rendering standard documents, so
> you need to resort to nonstandard extensions and tricks to make sure
> that people using those browsers get something they can read without
> getting a headache. This creates a nice vicious circle..
If you take 'those browsers' to mean IE/NS, then it's >80% of your readers by
best available information...
http://www.browserwatch.internet.com
...this observation tightens that vicious circle considerably.
> > Maybe the apparently opposing
> > opinions in this ng are not so far apart after all?
>
> It depends on who you talk to. Most so-called "purists" will be more
> than happy to tell you how to use some nonstandard extension safely,
> if that's possible. Other people know very well what the risks are in
> using a particular trick, and decide to use it if they've researched
> that the problems are minimal. You could call these people the
> "pragmatists." A third group is the "designer" crowd, who basically
> goes for "Optimized for 800x600 Netscape 3.01 for Windows 95". These
> people advocate the "if it works, use it" position, without checking
> if it works on *other systems* too.
Funny, by these standards you'd place me as a left-of-centre pragmatist, but
my main interest is design. Also, I'd hope that a 'purist' can understand and
use the principles of aesthetic design too. I'm sure that's not a paradoxical statement.
I'm not sure this fashion in categorisation of authors is at all helpful -
everybody has differing opinions, and it merely fractures people into camps;
e.g. Steve is a 'designer' therefore Steve doesn't check his markup on
anything except NS|IE|Cyberdog (choose one). Therefore he will say something
stupid in the post I am about to read... OK, I might; But I might not.
> I've actually never understood people who come here yelling that some
> search engine doesn't list them. My sites seem to have no problems getting
> indexed, and the people who need the kind of information I put out find
> me every day. You should see my HTML-inbox some day. :-)
Search engines are only one way of generating hits. (this could be a long discussion)
> > *Knowingly bad markup can achieve more, in terms of communication, than 'good'
> > markup.
>
> In this particular situation, yes. But this is a rather weird situation,
> mainly the result of certain browsers that are so unimaginative that you
> need the bad markup to ensure that its users can read your documents.
Indeed, my first post was my best attempt at an answer to the question. The
rest of this has been a discussion of the general principles behind that
answer. (It's the same discussion we always have isn't it?)
> > Since: layout *is* content.
>
> That may very well be true, but one of the core principles of HTML is
> that it is *not* a language that is to deal with layout.
Perhaps I should publish a FAQ? :)
A well known, and relevant quotation: "The road to hell is paved with good intentions"
> The original
> idea was that a browser would create a good-looking page based on some
> standard HTML document, but now that that hasn't caught on, the new
> idea is that an author (or third party) supplies style sheets to suggest
> particular renderings.
>
> HTML for the content, PNG for the images, CSS for the layout. That
> shouldn't be too difficult as a concept, right?
Good idea. An idea that could make the grade in the future. Now, what do we do
until then?
> > *Unknowingly bad markup is just a fact of life, due to the ease of publication
> > on the web. And denying public access to web authorship constitutes elitism.
>
> Using the same argument, you could say that a publisher who refuses a
> manuscript because of spelling errors is also being elitist.
When did that happen? Most publishers have proof readers for the very purpose
of correcting typos, spelling mistakes, etc.
> The mere
> fact that it is *easy* and *cheap* to publish doesn't mean that all
> the rules should go out of the window.
Yes. I agree with you. A book of grammar is invaluable. ;)
Steve Davis
Chris Gray
In article <SZeKh9AA...@the-net-effect.com> Colin F Reynolds
<co...@the-net-effect.com> writes:
> Some used to say that programming was a dead-end skill, since the
> machines would one day be able to write their own code. I don't see much
> sign of that happening any day soon, either.
But they do! That's what FORTRAN was invented for.
--
Chris Gray
Arjun Ray
In <Pine.A41.3.95a.971102170632.135596F-100000@sp052>,
| On Fri, 31 Oct 1997, Steve Davis wrote:
|
| > We are to understand then, that
| > standard html is not sufficient in all cases?
things. Nothing can. The "sufficient in all cases" requirement is
worse than a straw man, it's impossible in this universe. The only
relevant issues are what standard HTML allows by design, and the
inadequacy of browser implementations in fulfilling expectations
legitimately derivable from the design.
| Evidently. Hence XML, for instance.
Not really. XML is an "SGML profile", not an application like HTML.
There is no DTD for XML: rather, there can be XML DTDs for various
applications. (The SGML compatibility requirement means that any XML
DTD will also be an SGML DTD, but the converse will not be true in
general. In particular, HTML can't be XML-compliant without serious
changes in the DTD(s) and corresponding adjustments in practice,
although there is some chance that existing browsers will be able to
handle XML-ized HTML without serious damage.) Unfortunately, hype and
misinformation have already started to distort the XML initiative in
the public eye. Casting XML as an "alternative" to HTML is a very
misleading way to characterize the real situation, which is that the
misguided drive to make an omnium gatherum of HTML ("sufficient in all
cases") has highlighted the by now even more pressing need to make it
easy for people to work with *multiple* DTDs.
That said, the stultifying influence of the Mosaic tag-salad paradigm
on currently deployed browser technology has managed to make a total
hash of even standard HTML. While the inadequacy of procedural markup
(which is the intelligence of the "a tag is a command" notion) has
been known for 30 years now, that's a far cry from saying that it's
useless -- but it could just as well be, given the performance of the
Mosaic spawn. There's plenty of useful information that can be encoded
under such (generic) rubrics as links, headings, lists, glossaries,
and tables; the rendering possibilities on suitably capable platforms
with even this limited set of structures can be impressively diverse:
automatic TOC/navigator generation, "outline mode", collapsible lists,
popup definition windows, field "freezing" and panning, etc. Some of
these could even be "suggested" with appropriate attributes, though
this wouldn't be the best way. What happened instead was a philistine
reduction to a small set of procedural "primitives" -- in all senses
of the word. A mindless newline, a mindless indent, a mindless font
change, a kneejerk bullet -- that was about the sum total of the ahem
"advanced technology" of the Mosaic Phenomenon. Potentially useful
structural distinctions for intelligent processing were obliterated,
smashed together into a limited vocabulary of grunts: what tag to use
where hardly mattered because it wouldn't make much difference anyway.
(Consider the plight of the fellow who posted a while ago, "Why are
there so many different tags? They all seem so redundant..." That his
knuckle-walker could have a lot to do with that had escaped him.) Not
only is the legacy of effects-by-tag-salad obvious by now, but the
profound dissatisfaction with the state of affairs -- on the part of
both people concerned with information longevity and people concerned
with sophisticated rendering -- shouldn't be particularly surprising.
Sufficient in all cases? We're fast approaching necessary in no case.
| HTML isn't the only WWW medium. In a situation where it isn't capable
| of achieving what you intended, the choice is either to misuse it, or to
| find the more appropriate medium.
Precisely.
:ar
HarryH
In article <345C68CF...@dircon.co.uk>, ste...@dircon.co.uk says...
>
>Arnoud Galactus Engelfriet wrote:
>>
>> The original
>> idea was that a browser would create a good-looking page based on some
>> standard HTML document, but now that that hasn't caught on, the new
>> idea is that an author (or third party) supplies style sheets to suggest
>> particular renderings.
>>
>> HTML for the content, PNG for the images, CSS for the layout. That
>> shouldn't be too difficult as a concept, right?
>
>Good idea. An idea that could make the grade in the future. Now, what do we
do
>until then?
>
Use Acrobat, you fools! :)
After all, Acrobat does links. Acrobat does graphics. Acrobat does font.
Acrobat does layout. Acrobat does printer.
What else does a good looking page need? Animation? Interactivity? Blinking
text? Hah! You want to see those elements on paper? What Acrobat does not
support, you do not need.
The previous is not an advertising for Acrobat, nor does Adobe pay me for
saying these things, nor do I use Acrobat.
Just my two pennies.
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Dave Williams
In article <345f6d54...@news.algonet.se>, and...@XISPX.se (Anders
Thelemyr) wrote (with regard to not having control in HTML):
> This is a hard lesson to learn, indeed (I haven't come over it yet...).
>
> However, there is no law that says that One Must Make One's Pages Fit For
> Each And Every Agent, is there?
>
Well, not in the sense of you getting arrested or anything (people here
make sardonic references to the "HTML Police" but it's just a figure of
speech).
> When I create my simple html pages I check with Navigator/Communicator and
> MSIE in 640x480 as well as 1024x768 [but only in "image" mode] to make them
> look good (meaning the way -I- anticipated them to look :-) ) in both.
Why "only in 'image' mode"? An awful lot of people browse with images off.
You might try it (after flushing your cache) to see what they might be
seeing. You might also try viewing it with a non-frames browser to see what
happens when you put no information in the NOFRAMES section.
By
> doing this I will cover - what?- 70-80 % of all users. That's pretty good.
> In addition to this many other agents will show the pages OK.
>
Given the millions of people using the Web, yes, 70-80% is a large number.
But so is the 20-30% that could also see your pages if you'd tweak them a
bit to make them visible for them. (Since you're a hockey fan, ask yourself
this: What do you think of a goalie who blocks shots 70% of the time?)
> I do indeed understand the side that cries "logicalism". It's a matter of
> choice and there's (imo) no "wrong" here (except for not following the
> tag's rules, nesting rules and keeping the html source clean)
>
I think that maybe depends on your definition of "wrong" and your
definition of "here" (not to mention "html" and "clean"). The c.i.w.a.h.
regulars tend to view HTML standards as right, and everything else as
wrong, at least within the context of HTML, or HyperText Markup Language,
and I tend to agree. There are other newsgroups where the assertion that
"there's no 'wrong' here" will not be disagreed with.
You're absolutely right that it's a matter of choice. Nobody's forced to
use correct, valid HTML, or to ensure that non-valid HTML degrades
gracefully for people whose browsers don't support it. But it would be nice
if you did.
> Will I have to expect flaming now? :-)
>
I expect we both will. ;-)
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> A Message From Anders Thelemyr
> * Change "XISPX" to "algonet" in my return address when emailing
> ** About BIK!: http://www.swehockey.se/boden/
> *** Hockey Norrland: http://www.algonet.se/~anderst/hockeynorrland/
Dave Williams "A burro is an ass. A burrow is a hole in the
IN Jersey ground. As a journalist, you are expected to
www.injersey.com know the difference." - UPI Stylebook
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <345C68CF...@dircon.co.uk>,
Steve Davis <ste...@dircon.co.uk> wrote:
> Arnoud Galactus Engelfriet wrote:
> > In article <345A5F26...@dircon.co.uk>,
> > Steve Davis <ste...@dircon.co.uk> wrote:
> > > Arnoud Galactus Engelfriet wrote:
> > "You can't break the rules until
> > you know what the rules *are*" (a quote, but who said it?)
>
> I assume that q to be rhetorical. :)
Erm, well, it was intended as an apology for not attributing something
that someone else said. Never mind.
> > Of course one can argue that the most important reason for this is
> > that most browsers are very dull in rendering standard documents, so
> > you need to resort to nonstandard extensions and tricks to make sure
> > that people using those browsers get something they can read without
> > getting a headache. This creates a nice vicious circle..
>
> If you take 'those browsers' to mean IE/NS, then it's >80% of your readers by
> best available information...
80% of *web users*, yes. But are they also my readers? If I publish
something on our local information system ("intranet" if you are into
buzzwords), then 95% of the accesses come from Lynx users.
Anyway, I don't know if it's relevant that it's 90% or 10% that sees
a dull document. I would argue that it is a problem *of that browser*
if it doesn't show a standard document in an attractive way.
> Funny, by these standards you'd place me as a left-of-centre pragmatist, but
> my main interest is design. Also, I'd hope that a 'purist' can understand and
> use the principles of aesthetic design too. I'm sure that's not a
> paradoxical statement.
Well, all three the concepts are entirely artificial, of course. No one
here is a 100% purist, a 100% designer or a 100% pragmatist. However,
I think the most important point here is that a "purist" would be more
likely to say that a boring presentation or bad aesthetics in a web
document is the fault of the *browser*, and a "designer" would blame
the document or its markup.
> > > Since: layout *is* content.
> >
> > That may very well be true, but one of the core principles of HTML is
> > that it is *not* a language that is to deal with layout.
>
> Perhaps I should publish a FAQ? :)
>
> A well known, and relevant quotation: "The road to hell is paved with
> good intentions"
How is it relevant, if I may ask? We're probably viewing the problem
from two different angles, so we coming up with different solutions to
fix it.
> > HTML for the content, PNG for the images, CSS for the layout. That
> > shouldn't be too difficult as a concept, right?
>
> Good idea. An idea that could make the grade in the future. Now, what do
> we do
> until then?
Nuke Mountain View? =)
Seriously though, it's always hard to break out of a vicious circle. I am
not sure if "well, let's just make the best of it with what we have now"
is the right approach. It *is* still possible to fix the situation, if
enough authors are willing to go for the CSS route.
> > > *Unknowingly bad markup is just a fact of life, due to the ease of publication
> > > on the web. And denying public access to web authorship constitutes elitism.
> >
> > Using the same argument, you could say that a publisher who refuses a
> > manuscript because of spelling errors is also being elitist.
>
> When did that happen? Most publishers have proof readers for the very purpose
> of correcting typos, spelling mistakes, etc.
I'm comparing authors who write invalid markup (syntax errors, unknown
elements and attributes for the DTD they use, etc) to authors who write
words spelled incorrectly, who use incorrect grammar, and so on. It seems
to me that this is a valid analogy; in both situations, you're supposed to
use the rules for the language you are writing in.
In the WWW situation, there is no publisher who refuses to publish your
document because it has spelling errors, thus people can conclude that
it doesn't matter.
Colin F Reynolds
In article <7cLY04uY...@htmlhelp.com>, "Arnoud \"Galactus\"
Engelfriet" <gala...@htmlhelp.com> writes
>a "purist" would be more
>likely to say that a boring presentation or bad aesthetics in a web
>document is the fault of the *browser*, and a "designer" would blame
>the document or its markup.
I like that way of looking at it.
But does it mean that a "pragmatist" blames *both* the browser and the
markup? <g>
--
Colin Reynolds
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <1EjT2KAO9PY0Ew$b...@the-net-effect.com>,
Colin F Reynolds <co...@the-net-effect.com> wrote:
Good question. =) In all seriousness, I'd expect that a pragmatist
would get very frustrated at the many failures and limitations (s)he
will encounter when writing for the WWW, both in the markup and in
the browser.
For example, if you want a caption, there is a purist way of
doing it (use HTML 3.0, FIG & CAPTION, and reference that DTD at
the top, if your browser doesn't support that then it's your problem)
and there is a "designer" way to do it (draw the caption in the
image file or use a two-row, one-column table), but how do you do it
in a way that is both "in the spirit" of HTML and actually *works*
in that real world I hear so much about?