Re: Controling structure with CSS

> 1. The "one-tech" blinders.  Just because there is one technology to do
> something doesn't mean there shouldn't be another.

I would interpret this one rather differently.  I would say that the
the problem is that HTML/CSS/DOM/BOM/EcmaScript (BOM: browser object
model) is seen as a single technology by most authors of what are
popularly called web sites (although often have very little webbisness
in them).  Although I list a whole series of component technologies
they are seen as one product, not as a mix and match of complemnetary
ones.

For most authors, tools like XLST are not perceived to exist, so the
single technology logic forces them to want their current, CSS based,
technology to do everything that XLST might have done for them.  The
problem is not that XLST is seen as the one right technology, but that
CSS is seen as the one and only technology for "web" styling.  (This results
in the fate of nearly all computing standards, that a novel and well
targetted language becomes a bloated an universal langauage.)

I'd say it goes even further than this, in that authors fail to consider
that PDF (and even SVG) may be more appropriate technologies for 
graphic design projects.

> 2. The fact that complex solutions beg for simpler solutions.

Again, I would see this rather differently.  Often a solution that appears
more complex is actually simpler, but marketing psychology[1] means that
it is easier to sell something that does simple things easily, at the
expense of more complex things.  If a problem requires a certain level
of complexity, it is better to use a tool that was designed for that
level of complexity.  CSS basically has had lots of features bolted on
because it, as a tool for giving styling hints on basically textual
information, is being forced into being a precise graphics arts tool
for content which is about influencing, rather than informing.

Achieiving that whilst maintaining backwards compatibility and the fiction
that consumers of its new features think about structure first, results
in all the complexity that resulted in the complexity thread on www-html.

I think that accepting that the money is in graphic arts and influencing,
rather than in the librarianship and informing that HTML was designed
for, ought to lead to the conclusion that the right design for a
commercialisable "web" language is one that starts from a strictly
presentational point of view, and then, for narrow and broad (including
mobile devices etc.) accessibility, uses some sort of structural overlay.
Tagged PDF seems to me to be a cleaner solution, although PDF lost the
marketing battle in the early Netscape days, by not realising the threats.

SVG is slipping behind because it only has token accessibilty features
and has no structural overlay - you would have to XLST into SVG from
something else, and I don't think many people are doing that.

[1] sales demonstrations tend to have to be short, and purchasing decisions
and policies are often made by pure managers who were never technically
strong (I've known software house managers who took pride in not knowing
much of the technology) or haven't used the knowledge for years.

Managers will also often believe that they can use cheaper staff if 
tools are based on a less sophisticated theoretical basis, even though
the result is often that the product is much larger than it need be and
the size (and ad hoc workarounds) makes it difficult to understand and
maintain.

Received on Saturday, 17 April 2004 07:18:35 UTC