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

On Sat, 05 Nov 2016 17:47:51 -0400, you wrote:

>> - 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=.
>
>It does not right now. The correct usage for class attribute is to style 
>a group of elements which have a meaning, some kind of logic inside the 
>webpage designer. An inline style is (should be!) for an unique element. 
>Therefore, an inline style should be more specific than a class.

Unfortuately, graphic designers don't care about such
distinctions.  They just get in the way.

I started practicing as a commercial artist --the term "graphic
designer" came into use later-- in 1959.   Computers were 25
years in the future.  Our tools were quite simple:  drawing
board, t-square, 30-60 and 45-45 triangles, a steel ruler,
circular and regular slide rules, Rapidograph pens, colored
pencils including non-repro blue, sheets of illustration board
(thicker and more expensive than the Bristol board  we used for
less-important work), mat knives, masking tape, Rubylith film,
several kinds of erasers, a pint jar of rubber cement with a
brush in the lid, a gallon tin of carcinogenic Bestine for
thinning out the rubber cement, press-type (letters that could be
positioned and then rubbed off the carrier sheet), and solvent
based markers that were quite hard to let dry out to exactly the
degree needed and that would give you a nasty headache if you
left them uncapped nearby.  

Those tools had no intelligence.   We used them.  The
intelligence was (or wasn't) in us, not them.

In the mid-'80s, when the Macintosh and then Windows appeared and
software started being written to make life easier for designers,
I bought a copy of Aldus Pagemaker (I think it was v2 or v3, I
don't remember) and thought I'd died and gone to heaven.   That
software did all the tedious things for me.   It let me set my
own type (I felt sorry for the typographers who'd lost their
jobs) including playing around with it.  I could do runarounds,
drop in spot color, do reverses, and what I saw on the screen was
what got dumped to the imagesetter to  create the negatives for
burning printing plates.  I no longer had to take great care not
to scuff up the clay coating of the sheets of set type with my
t-square, no longer had to carefully cut and paste words if I
decided to change the text a little, no longer had to worry about
making sure I stuck down the type blocks exactly squared to the
edges (it was always problem getting the rubber cement thin
enough but not too thin), and no longer had to worry about a
Rapidograph line dropping out because the ink didn't lay down or
trap quite right.   

The software had enough intelligence to do the things that
computers are good at (regularity, repeatability, easy changes),
and didn't try to do those things computers are bad at
(creativity, psychology, design).

>
>"
>count 1 if the declaration is from is a 'style' attribute rather than a 
>rule with a selector, 0 otherwise (= a) (In HTML, values of an element's 
>"style" attribute are style sheet rules. These rules have no selectors, 
>so a=1, b=0, c=0, and d=0.)
>(...)
>count the number of other attributes and pseudo-classes in the selector 
>(= c)
>"
>CSS 2.x, section 6.4.3 Calculating a selector's specificity
>https://www.w3.org/TR/CSS21/cascade.html#specificity
>https://www.w3.org/TR/CSS22/cascade.html#specificity
>
>When calculating specificity, an inline style attribute will have 
>precedence over a class attribute.
>
>Eg:
>
>div.test {color: red;}
>
>...
>
><div style="color: green;" class="test">Test passes if this text is 
>green.</div>

But generally speaking, graphic design does not naturally require
calculation.  The calculations you describe are imposed on the
designers by engineers who don't understand the design process. 
I'm not being critical in saying that, just stating a fact.  It's
a pity that engineers don't get enough training to at least be
aware that they don't understand other fields, but the
engineering curriculum is very demanding and there's not much
time left over.

>
>
>> Where they appear at the same level, the last one
>> seen prevails (i.e., the reading direction of the human language
>> breaks any ties).
>
>I am not sure what you mean here. If we are talking of the same CSS 
>property and same specificity, then the last one in code order wins:

I suppose you could say code order.  It depends, I suppose, on
whether someone whose human language isn't written left to right
is using left-to-right tools. 

>What you advocate is, in my opinion, not suitable. Some properties (like 
>border-style, border-width, border-color, etc...) should not be 
>inherited by default.

Believe me, that's because you're not a graphic designer.

>
>> - all styling attributes in HTML 4.* would be afforded PCP-CSS
>> equivalents.
>
>HTML 4.* styling attributes are already although it must be emphasized 
>here that the specificity of HTML 4.* attributes is zero.
>
>"
>The UA may choose to honor presentational attributes in an HTML source 
>document. If so, these attributes are translated to the corresponding 
>CSS rules with specificity equal to 0, and are treated as if they were 
>inserted at the start of the author style sheet. They may therefore be 
>overridden by subsequent style sheet rules. (...)
>"
>CSS 2.x, section 6.4.4 Precedence of non-CSS presentational hints
>https://www.w3.org/TR/CSS21/cascade.html#preshint
>https://www.w3.org/TR/CSS22/cascade.html#preshint
>
>> Thus instead of "margin:auto" there would be a
>> "center" attribute because any graphic designer knows what
>> "center" means
>
>Center is always related to some kind of reference point. When a graphic 
>designer wants to center an element inside another element, then both 
>elements must be defined and a specific logic must also defined and be 
>used depending on various conditions.
>
>If your graphic designer wants to center an absolutely positioned 
>("position: absolute") element inside another element, then he will have 
>to use precise code. And the code and the logic will be different if the 
>enclosing element is itself positioned or not, if the enclosing element 
>has horizontal padding or not, if the horizontal padding is symetrical 
>or not, etc..
>If your graphic designer wants to center a statically positioned 
>("position: static") element inside another element, then he will have 
>to use precise code and different code.
>If your graphic designer wants to center an inline ("display: inline") 
>element inside another element, then he will have to use precise code 
>and different code.
>If your graphic designer wants to center a block box ("display: block") 
>element inside another element, then he will have to use precise code 
>and different code.
>Eg:
>CSS Horizontal alignment:
>when to use margin-left, margin-right and when to use text-align
>http://www.gtalbot.org/NvuSection/NvuWebDesignTips/HorizontalAlignment.html
>
>If your graphic designer wants to center an image in the background of 
>another element, then he will have to use precise code. 
>"background-position: center" is unique in that it just does not center 
>an image but it centers the center of such image in the center of 
>another element, and this, both horizontally and vertically. On the 
>other hand, if you do "left: 50%; top: 50%", then you will only center 
>*_the left and top edges_* of the element at the center of the padding 
>box of its containing block and *_not the center_* of the element.

Did you know that centering something vertically doesn't center
it vertically?  That's because the optical center of the Y axis
is higher than the numeric center.  If you position something at
the numeric center, people will feel uncomfortable when they look
at it because it will seem to be "falling off".  That creates a
sub- or pre-conscious feeling of tension that's quite unpleasant,
and so they don't want to look at it.

>
>Eg:
>Set Blue box's position to relative, then press OK and then set Yellow 
>box's position to absolute, set Yellow box's Left to 50%, then press OK, 
>in this page
>
>http://www.gtalbot.org/DHTMLSection/Positioning.html
>
>and you will understand what I mean. You would not get an equivalent 
>result with an image that is styled with "background-position: 50%" 
>which is equivalent to "background-position: center".

Again, you're describing how it DOES work.  I'm saying that it
SHOULD NOT work that way, that all that just interferes with the
real work.


>
>
>> 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.
>
>"margin: auto" can be hard to understand if and when a specification 
>lacks good, useful, helpful, interactive examples, judicious schemas, 
>illustrations. "margin: auto" can be hard to use if there are no good 
>tutorials on the web about its appropriate usage.

Yep.  But that's just putting a bit of sugar on something that
should be sweet to begin with.


>
>> 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.
>
>Just consider that padding or margin (it depends on the design and 
>elements involved) is spacing between elements that have no borders 
>then.
>
>Most web designer people on the web do not rely on inheritance, probably 
>because they are not aware of it. This flaw leads them to over-declare, 
>over-define, over-style, over-specify and over-redefine declarations in 
>their style sheets.
>
>Most web designer people on the web do not count on and rely on user 
>agent style sheet rules because they do not understand how the cascade 
>works; and so, many of them use css resets to "zero" many properties 
>with the universal selector... a grave error in my opinion. 10 years 
>ago, it made sense to css reset *_a few_* properties of *_a few_* 
>elements because browser manufacturers were not trying to communicate 
>with each other and reach agreements for the benefits of the web but 
>that has changed.
>
>Most web designer people on the web have problems with use of margin 
>because margin collapsing is more difficult to understand. And a 
>minority of them abuse "position: absolute" and/or still add dozens or 
>hundreds of <br> and &nbsp; in order to finely control positions of 
>elements in their pages.
>
>Overall, all of this creates bloated CSS code (it's not rare to see 
>several style sheets applying to a webpage with hundreds of rules in 
>minified style sheets) that eventually does not even work as intended as 
>soon as the visitor has some specific viewport and some accessibility 
>requirements. CSS was originally designed, among other design principles 
>and goals, to reduce code, to reuse code and simplify maintenance 
>without excluding anyone or any media: I do not see this on the web.

I don't doubt your perception I bit.  I'd almost be willing to
bet folding money that you're completely correct!

But why is that happening?  Knowing why is the next step toward
an effective understanding.

It's happening, broadly, because the vast majority of capable
graphic designers do not have engineer-type minds, did not have
engineering training, and do not use anything more than the most
primitive calculation in their work.

Artists "eyeball" things.  With the exception of technical
artists who do exploded views of devices and similar, artists'
decisions are made by eye.  That's how I (and others) got by with
a ruler and the little cardboard circular "slide rules" that
every type house handed out like business cards.

So when you write... 

>If your graphic designer wants to center an absolutely positioned 
>("position: absolute") element inside another element, then he will have 
>to use precise code. And the code and the logic will be different if the 
>enclosing element is itself positioned or not, if the enclosing element 
>has horizontal padding or not, if the horizontal padding is symetrical 
>or not, etc..
>If your graphic designer wants to center a statically positioned 
>("position: static") element inside another element, then he will have 
>to use precise code and different code.
>If your graphic designer wants to center an inline ("display: inline") 
>element inside another element, then he will have to use precise code 
>and different code.
>If your graphic designer wants to center a block box ("display: block") 
>element inside another element, then he will have to use precise code 
>and different code.

...you're writing for engineers, not graphic designers.  

Designers create "bloated CSS code" because it's so damned hard
to implement a design in CSS that would be almost trivially easy
using, Pagemaker, InDesign, Quark, or for that matter my old
tools from 57 years ago.

The one thing nobody wants to do, no matter what their field of
work, is to have to fight their own tools.

Do you know the postscript language, Gérard?  The one used in
postscript printers?  Have you ever written anything substantial
in it by hand?

When the first postscript printer came out, we were just
completely enchanted by it.  It was wonderful to write a little
program in postfix notation and then see it run on a printer,
producing an image on a sheet of paper.

If browsers has postscript interpreters in them the way they have
js and css terps, I'd write web pages in postscript instead of
html/css because I'd have complete control, something I do not
have now.  I could build up a little library of routines to hide
complexity and then call them to do what I want.  It would take
me a fair bit of time to generate that library, but I'd be better
off afterwards than I am now.

Imagine what changes you would make to CSS if you were trying to
support the work of people who have better than average color
perception, the ability to position by eye (I could do it to
within about 0.75mm (1/32 inch) and I was far from being the
best), a strong, often intuitive understanding of
psychophysiology, cognitve psychology, and cultural anthropology,
and no use at all for theories or for any more calculation than
it takes to decide the point size and leading to fit a certain
number of characters in a certain face on a line.

You wouldn't come up with today's CSS, I guarantee you.

Received on Monday, 7 November 2016 14:12:41 UTC