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

Le 2016-11-04 14:49, Oriol Bugzilla a écrit :

> - 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>.

Oriol Bugzilla answered you correctly on this.

> - 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.

"
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>


> 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:

"
Finally, sort by order specified: if two declarations have the same 
weight, origin and specificity, the latter specified wins. Declarations 
in imported style sheets are considered to be before any declarations in 
the style sheet itself.
"
CSS 2.x, section 6.4.1 Cascading order
https://www.w3.org/TR/CSS21/cascade.html#cascading-order
https://www.w3.org/TR/CSS22/cascade.html#cascading-order

Eg:

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/sort-by-order-001.htm

> - attributes, unless set/cleared within the element by a style=
> or class=, would be inherited from the nearest enclosing element.

This is already the case for inheritable properties, for properties that 
are inherited by default. What Oriol Bugzilla answered you is correct.

> 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. (...)
> 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>

All of the border properties are not inherited by default. See the 
"Inherited?" column in this page:
https://www.w3.org/TR/CSS21/propidx.html

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.

> - 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.

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".


> 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.

> 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.

Gérard

Received on Saturday, 5 November 2016 21:48:29 UTC