Re: Why style sheets

At 12:06 PM 1/17/97 -0800, you wrote:
>I understand all the arguments in favor of style sheets in terms of being able 
>to change the global look of an entire site in one place, but it seems to me 
>that I can do this with some intellignece about my markup conventions, and a 
>global search and replace. 
>
>Why should I pay the penalty of two HTTP accesses per page (one for the text, 
[-snip-]
        Then use the STYLE attribute within the tags.  It's not as
maintainable, but it cuts you to one fewer HTTP access.

>Also, why is it worse to add HTML tags or tag attributes than to add style 
>properties. There are well defined rules for ignoring unknown HTML tags and 
>attributes. Perhaps someone could explain.
>
        I'll take a crack at it, perhaps others can add more detail.

        Just adding new tags willy-nilly to HTML can be a problem if it
isn't done properly.  If it's well thought out and done properly, no
problem.  If you can't write a DTD fragment for each new tag, then you are
creating scalablility and maintenance problems for browser and tool
manufacturers. SGML is complicated and difficult, (I think everyone will
agree with me on this one.) but at least its behavior is known.  If browser
manufacturers would implement each tag differently leading to a
non-standardization on the web. You already see this with Netscape & MS.
Each feels that their proprietary tags give them a market edge. Leaving all
of us out in the cold.  Cross-platform standard delivery of documents was a
goal of the WWW.

        At a certain point the data structures used by the browsers for the
tags become overwhelmed and don't function as efficiently anymore. (And the
design of the browser itself becomes overwhelmed.) By adding new tags for
every new function, you are basically just overloading the tag metaphor
without thinking about when using another scheme (such as style sheets might
be more appropriate).  I'll just go out on a limb here... Tags are about
things (often structures are things).  Attributes describe things (style is
descriptive).  As someone said here earlier, if Netscape 1.1 had implemented
style sheets, no one would have been surprised by this stuff.  Instead
Netscape added new tags, so people became conditioned to equate new tags
with the way to add new functionality to the WWW.

        Netscape seems to have had some problems with their source code,
which made it difficult to scale up and add functionality.  Part of the
problem was probably due to the new non-standard tags for which they didn't
have a DTD.  At least from the discussion here, in some cases it was
seemingly impossible to create a workable DTD for the tags. So Netscape got
slowed down in implementing style sheets.

        Another basic assumption of the WWW is that users should be allowed
to choose how *they* want to interact with the information available.  That
means, user preferences that can over-ride author preferences. This is a
very powerful concept. It is also one that some people find disturbing or
might disagree with. But, by empowering the end-user, then they can choose
how they want to interact. They can use a 14-inch monitor, or a TV set, or a
Personal Digital Assistant to surf the web. If they have a disability, they
can use a tool that will allow them to overcome or work around that
disability. For example a person might be color-blind. They can't see
certain colors, so they set their browser to not display those colors.  They
might have difficulty seeing, so they set their browser to display in a
larger font size. Or they might be totally blind, and using a text-speach
converter. The information should be served out in such a way that it
accomodates these different means of presentation. You could try to design a
separate web-page for each of these groups of people, but you would quickly
get overwhelmed. You could of course, ignore some of them. They are just a
minority or the total people accessing your information.  But what kind of
message does this send?  Not exactly a customer oriented one. (In fact the
US has laws, like the ADA (Americans with Disablilities Act), just to
protect such groups. Those laws exist because American society felt that
they were important.)  The nice thing about HTML is that, used properly, the
author doesn't have to worry about creating a separate page for each
presentation, it is all taken care of automatically by the browser. This
puts a lot of burden on the browser manufacturers to do things right. They
don't like to admit it, but it is a difficult job. Style sheets make it
easier to separate the presentation (which can be modified by the user's
preferences) from the information content (which can't).

        On the document authoring side, a lot of people have been learning
HTML (another thing I think we can all agree on), many out of a book or
learning-by-example off the net.  A lot of people learned it quickly. They
didn't read the Introduction and first chapter in their books which would
have told them about the background and history of the web and its
groundings in SGML.  Some of the books don't go into detail about why things
are the way they are.  Some don't discuss presentational markup vs.
structural markup. Some people don't deal with abstractions (like document
structure) very well. Why was algebra class so difficult? (Oh, it wasn't
difficult. That's why I became a computer programmer, because that's all
abstractions. :-) To make matters worse, the tools don't support these
concepts well either. (Some do, but many of those are SGML tools that are
*really expensive*.) People want to do things the easy way. Learn one
concept, the tag. That's all you need and you can do HTML.  Style sheets
seem foreign.  They aren't yet well supported by the tools, browsers and
books.  When MS Word or Word Perfect can generate HTML tags with style
attributes automatically, then Style Sheets will be easy to use. This isn't
too terribly difficult either.  You already use a standard "style sheet"
with MS Word (normal.dot).  Attributes were foreign once too. Remember HTML 2.0?

        People will catch on.  The hard part is planning ahead.  If you
write an html document that is only going to be on the web for a week or for
6 months, then who cares if it is standard HTML, use whatever works today.
If you plan to have your documents available 2 years from now, or 5 years,
then you better plan ahead. Follow the standards, because that is the only
way that you can reasonably expect that future browsers and tools will work
with your documents.

        The challenge for the people writing the standards and making the
tools, is to innovate, but to choose directions that will allow for easy
extensibility and maintenance.  This can be tricky, but that is why the
standards that work are the ones that are based on existing technology (or
at least technology that has been proven with a working model).   

        Another complicating factor is that standards have to address a very
wide group of needs: beginners, experts, people doing quick-and-dirty web
pages and people doing long-term archival quality documents.  The documents
have to be able to work on a wide variety of platforms, both hardware and
software, yesterday (because some people haven't upgraded, and don't plan
to), today and into the future, not just "Netscape Now" (whenever "now" is). 

        Most of these issues are not technical ones, they are people ones.
It takes time and effort to write a browser.  It takes time and effort to
make standards.  People want stuff now, or as soon as possible, and they
want it to be easy.  This is perfectly understandable, given all the hype
(which, by the way, has been surrounding computers for over 4 decades. This
is not something new here.).  People have certain expectations, when they
aren't met, people complain.

        So what can we do?  Just keep building stuff, I guess.  Educate
people where ever possible.  Try to make appropriate technological choices.
Follow the standards. Continue to innovate.  Just remember, this stuff is
complicated.  Our job it to try to make it simple to use, without making it
so simple that it stops working.

        I guess that is the main argument against always trying to make new
tags, instead  of evolving toward style sheets.  Tags are simple, but if we
add too many of them they will either become too complicated, or stop
working, or both.  The Cougar HTML tag set is a pretty good balance.  It's
not perfect, but it seems to balance complexity with simplicity pretty well.
You can do a lot simply with tags and attributes (including STYLE), while
the really powerful stuff like <OBJECT> and Style Sheets are split off for
the more expert users.

Just my 2-cents worth. (10-cents with inflation :-)  I hope this spurs some
good discussion. Sorry for going on so long.  Hey, it's Friday.  I'm out-a
here. :-)

-John
Standard Disclamer -- The opinions expessed here are my own. They do not
represent official advice or opinions of Cornell Cooperative Extension 
or Cornell University.

John Udall,                                       
      Programmer/Systems Administrator            40 Warren Hall
Extension Electronic Technologies Group           Cornell University
Cornell Cooperative Extension                     Ithaca, NY 14853
email: jsu1@cornell.edu                           Phone: (607) 255-8127

Received on Friday, 17 January 1997 18:21:24 UTC