W3C home > Mailing lists > Public > www-style@w3.org > August 2006

Re: Selector for parent/predecessor?

From: David Woolley <david@djwhome.demon.co.uk>
Date: Tue, 22 Aug 2006 21:53:20 +0100 (BST)
Message-Id: <200608222053.k7MKrKi28538@djwhome.demon.co.uk>
To: www-style@w3.org

> > The reality, which people can choose to ignore if they like, is that
> > all of the innovation is taking place amongst programmers who are
> > working around the limitations of browsers! Look at Dojo...look at

This sort of effort is typical of cases where tools have been chosen
without proper consideration of what is technically required for the job,
or requirements have been set that need a different tool.  It's a very
much older part of software development, than the web or a public
internet.

I first experienced it on my very first projects as a professional
computer programmer, over thirty years ago.  The policy was to use Cobol,
but either the analysts or the customer decided that negative numbers
must be given in parentheses (an accountant's convention for unfavourable
figures).  This was on an IBM mainframe which had hardware support for
number formatting that would have made this exceedingly trivial, but it
had to be done the hard way, as a Cobol subroutine, rather than an
assembler one.

I've seen the same sort of things many times since, including a policy
of using Ada and then immediately creating code to subvert the type
checking of pointers and allow DIY memory management.

With HTML/CSS it typically shows up as wanting to do things that require
a native code, thick client application, but using a web browser as
a thin client, without compromising the thick client type behaviour, and
in trying to get precise presentation similar to that from PDF (or even 
SVG) but using HTML and CSS.

> It's going to be a long process, which isn't helped by scope creep.

If I understand this reference correctly, this is how standards die.
The cycle starts with a large complex tool that can do almost anything,
but is difficult to learn and use properly (and may require auxiliary
tools).  Someone invents a lean and mean, tightly targetted, application
for a particular application area.  That becomes popular because it is
easy to learn and use.  It gets standardised.  People then start asking
for it to be the universal solution.  It eventually bloats to the point
where people who were too young when it was first born to realise it
actually was once targetted for their application, invent a new mean and
lean tool and the cycle restarts.
Received on Tuesday, 22 August 2006 21:04:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:46 GMT