[css-syntax]The emperor isn't naked, but he's wearing his underpants on his head

The emperor isn't naked, but he's wearing his underpants on his
head.  

The current state of CSS is that of a heroic design effort that
went astray.  Having earned my living in both fields, separately,
before going back to school for a psych doc and becoming a
human-factors nerd, I can state with confidence that CSS does not
behave as an experienced graphic designer would expect, nor as an
experienced programmer would expect.  It's becoming less usable
all the time as it's patched and patched and patched again in the
continuing effort to "save the hypothesis".  

Most of us who gravitate to science or engineering tend to be a
little more obsessive and driven than the average person.
Einstein once said that he considered his success less a result
of greater intelligence than the fact that, once started toward a
goal, he was exceptionally difficult to deflect from it.  Which
is good: science and engineering are hard to do, and if we
weren't unusually committed we'd give up too quickly, perhaps
even at the first setback.  "If at first you don't succeed, give
up" is not the motto of any successful engineer or scientist.  

But the toxic side of that strength is the *inability* to change
course.  Being unable to heed the advice Fred Brooks gave us:
"plan to throw one away".  The late Prof.  Sir Maurice Wilkes
brought down the house when he told an auditorium full of
engineers that the nice thing about setting standards is that
they force everyone who comes after us to make the same mistakes
we did.  We've all seen that morality play.  

The current version of CSS is at the point where, for the sake of
the future as well as people working today, it needs to be
replaced.  Work on it needs to be stopped, and a new direction
taken that accurately maps onto the real world of graphic
designers and programmers.  

I wouldn't be writing this if it weren't necessary, believe me.
The current model is of the utmost value as a learning
experience.  It teaches us things we could have learned in no
other way, the most important lesson being, as Feynman wrote,
that "[f]or a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled".  And not
just public relations.  Reality must take precedence over every
other consideration, because anything else invites disaster.
Nature *cannot* be fooled.

I suspect that's a lesson every professional must learn at some
point (I certainly had to!).  

As an HF nerd, I try to preserve my naïveté as long as I can,
because it's only while we are naïve that we can see the pitfalls
in an implementation.  After we become expert, in most cases we
completely forget what it was like to struggle with something for
which our existing world-knowledge was useless or worse.  We may
remember that the new thing was "hard to learn", but we don't
really remember the frustration we felt or the time we were
forced to waste.  Sometimes we even come to feel that we must
defend it, a sort of techie "Stockholm syndrome".  

My proposal for the new direction is what we might call
"Paint-Can Precedence" because everyone knows how
straightforwardly paint works: if you put paint on something, it
covers up what was visible before.  If you lay down 2 coats of
different colors, the second color covers up the first one.  

Within the constraints of physical law, paint works the same
under all conditions, and on all substrates.  It works the same
on a bicycle or piece of stretched linen canvas as it does on a
fence or the trim on a house.  With paint, we never have the
crazy-making experience of spraying a blue bicycle with red paint
and having the bicycle end up still blue, or stripped down to the
metal, or polka-dotted.  Even without reading the label first,
what we get is what we expect: a red bicycle!  

The interpreter for "Paint-Can Precedence" CSS should be much
smaller and much simpler to write than the current interpreters
were, and could exist alongside the current interpreters, invoked
for new pages by a meta statement in the styles file.  That would
preserve everyone's existing investment, with existing pages only
being rewritten to the new model as they became outdated.  

And the rules would be so simple that a request for comments
could be propagated almost as fast as it could be physically
typed up: 

- everything would be what's now called an "inline" element, and
flow with the text unless disrupted by a <br> or similar.  There
would be no "natural" block elements, though "display:block"
could be a way to generalise a <br>.  

- there would be no privileged styling.  Just as a function call
is equal to inline code, a class= would have the same precedence
as a style=.  Where they appear at the same level, the last one
seen prevails (i.e., the reading direction of the human language
breaks any ties).  

- attributes, unless set/cleared within the element by a style=
or class=, would be inherited from the nearest enclosing element.
Thus a <div> inside a <td> would inherit from the <td>, including
those attributes inherited by the <td> from the <tr>, the <table>
and all the way up.  If there were no enclosing element with
attributes declared/defined, the element would inherit from its
"genetic" ancestor, e.g.  <div> from div.  The "genetic" ancestor
would not be privileged in any way.  Its attribute settings could
all be overridden by its "descendants" on their own behalf.  The
attributes inherited by some element might ultimately be implicit
ones set by the browser.  All elements could inherit, and pass
on, all attributes unless some attribute would be totally silly
(e.g.  it would be silly for a <br> to have a border, color,
etc.).  

So, the <div> in the example could set/clear its own value for
border.  If it didn't, it would inherit from the <td> if the <td>
set/cleared the border attribute, or from the <table> if the
table did so, and so on all the way up to the <body> and, failing
that, from the genetic ancestor div or, as a last resort, from
the browser.  

- all styling attributes in HTML 4.* would be afforded PCP-CSS
equivalents.  Thus instead of "margin:auto" there would be a
"center" attribute because any graphic designer knows what
"center" means  while "margin:auto" is a total mystery to anyone
who hasn't looked it up and even to some who have.  Practitioners
should not have to look things up unless there is no reasonable
alternative.  Similarly, "element-spacing" (or "cell-spacing", or
both) rather than "border-spacing" because one might very well
want spacing between elements even without wanting or having
borders.  

I don't think I've missed out anything, but I'll welcome
discussion.

Received on Friday, 4 November 2016 08:57:22 UTC