Assume HTML like

<h1>...</h1>
<h2>...</h2>
<p>...</p>
<p class="myclass">...</p>

. There are four paragraph-like kinds of elements:
"h1", "h2", "p", and "p" with "myclass".

Looking at such HTML in a browser, I sometimes want to increase or
decrease the vertical distance between some paragraph-like units
of text. For example, I'd like to specify a vertical distance
between an "h2" element and a directly following "p" element.

To achieve this, I could either specify the size of the vertical
space below the "h2" element or the size of the vertical space
above the "p" element, or both, for the case of this combination.

I think I should fix this in time so that it can be done in a
consistent manner in my style sheet. Which definition would be best?

In addition, there could be a kind of "combinatorial explosion",
since with n different types of paragraph-like element, there
are n*n possible combinations. Is there any idea how something
like this can be prevented? TIA!

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>I think I should fix this in time so that it can be done in a
>consistent manner in my style sheet. Which definition would be best?

For my CSS I need to know whether an element of a certain type and
with a certain class is preceded and/or followed by an element of
a certain type and with a certain class. But this capability has
only recently been introduced into Firefox with ":has".

So I now have decided to add this info to the classes of an element.

<p class="ugy pugy fugy">Example</p>

The above, for example, is a paragraph of type "p" with the class
"ugy", which is directly preceded by an element of the class
"ugy" and directly followed by an element of the class "ugy".
As my elements will be written with a generator, it can add
such tags without hassle for the user.

Then I can base my rules on such classes, e.g.,

p { line-height: 130%; padding-top: 0; }
p.ugy:not(.pugy).fugy { margin-top: 1.0ex; margin-bottom: 0.5ex; }
p.ugy.pugy.fugy { margin-top: 0.5ex; margin-bottom: 0.5ex; }
p.ugy.pugy:not(.fugy) { margin-top: 0.5ex; margin-bottom: 0.2ex; }
p.ugy:not(.pugy):not(.fugy) { margin-top: 1.0ex; margin-bottom: 0.2ex; }

.

In article <distance-20240330105114@ram.dialup.fu-berlin.de>, Stefan Ram
wrote...
> I sometimes want to increase or
> decrease the vertical distance between some paragraph-like units
> of text. For example, I'd like to specify a vertical distance
> between an "h2" element and a directly following "p" element.
>
> To achieve this, I could either specify the size of the vertical
> space below the "h2" element or the size of the vertical space
> above the "p" element, or both, for the case of this combination.
>
> I think I should fix this in time so that it can be done in a
> consistent manner in my style sheet. Which definition would be best?
>
>

My own approach to this is to consider the minimum margin/padding that would be
tolerable for a given element, and fix it at that. For elements you want to
use in specific ways (e.g. a <P> element which will contain a "joke") you can
use a class to modify the basic element.

For headings, I've found that setting a padding appropriate to the chosen font-
size, and increasing the space *above* the heading (appropriate to its level)
is the most satisfying and generalisable; for the gap underneath I tend to add
little or (mostly) nothing to the margin which is set for the following element
type. If you get the individual elements "right" like this the combinations
mostly take care of themselves.

Making sure you have a clear sense of the "character" of the elements you use
is important in this, and using 'Semantic' elements and even Custom elements
(where you choose what goes between the tag margers, like "<insult>" or
"<irony>", noting they come with zero default styling) can give you the
strongest sense of how you might want an element to appear. Consider the
difference between "<H1>" & "<H2>", and "<Solution>" & "<SolutionDetail>" for
example.

--

Phil, London

In article <MPG.40737dd4e4593c6f989ac1@news.eternal-september.org>, Philip
Herlihy wrote...
> using 'Semantic' elements
>

https://www.w3schools.com/html/html5_semantic_elements.asp

--

Phil, London

In article <classes-20240331111754@ram.dialup.fu-berlin.de>, Stefan Ram
wrote...
> <p class="ugy pugy fugy">Example</p>
>
> The above, for example, is a paragraph of type "p" with the class
> "ugy", which is directly preceded by an element of the class
> "ugy" and directly followed by an element of the class "ugy".
>
>

No. I think you're confusing the allocation of classes to HTML elements with
the subtlties of "Selectors" in CSS. In your example (which is HTML of
course), the <p> will inherit the properties of all three classes. If those
properties conflict (e.g. "ugy" sets the colour blue, and "pugy" sets the
colour red) then the rules of "Specificity" determine which is used; if the
specificity is the same, the last declared class will take precedence.
https://www.w3schools.com/css/css_specificity.asp

If you want to style according to element sequence, you need to use CSS
"Combinators":
https://www.w3schools.com/css/css_combinators.asp
(See also https://www.w3schools.com/cssref/css_selectors.php)

Check for browser compatibility:
https://caniuse.com/?search=css%20selectors

--

Phil, London

Philip Herlihy <PhillipHerlihy@SlashDevNull.invalid> wrote or quoted:
>No. I think you're confusing the allocation of classes to HTML elements with

Here's a demo:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head><meta charset="UTF-8" /><title>Main</title><style>
p.ugy:not(.pugy).fugy { text-decoration: underline }
p.ugy.pugy.fugy { font-weight: bold }
p.ugy.pugy:not(.fugy) { font-style: italic }
</style></head><body><!--
--><p class="ugy p fugy">First p</p><!--
--><p class="ugy pugy fugy">Inner p</p><!--
--><p class="ugy pugy f">Last p.</p><!--
--><script>/*<![CDATA[*/
/*]]>*/</script></body></html>

It even works in a browser published more than ten years ago and
in an HTML-to-PDF converter.

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>It even works in a browser published more than ten years ago and
>in an HTML-to-PDF converter.

Here's a current draft HTML resource that shows the complete
stylesheet I use for formatting paragraphs. This is intended
to become the basis for my future web site. (In the real web
site, the stylesheet will be extern.)

As it was not written for Usenet, some lines are longer than
72 characters.

<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head><meta charset="UTF-8" /><title>Main</title><style>
body
{ margin-top: 0; padding-top: 0;
font-family: Georgia;
letter-spacing: 0.02em;
word-spacing: -0.01em;
color: #553322; background: #FFFEFC; }

p { line-height: 130%; padding-top: 0; margin-left: 0%; }
p.vugy:not(.vpugy).vfugy { margin-top: 1.0ex; margin-bottom: 0.5ex; }
p.vugy.vpugy.vfugy { margin-top: 0.5ex; margin-bottom: 0.5ex; }
p.vugy.vpugy:not(.vfugy) { margin-top: 0.5ex; margin-bottom: 0.2ex; }
p.vugy:not(.vpugy):not(.vfugy) { margin-top: 1.0ex; margin-bottom: 0.2ex; }

@media screen
{ body
{ margin-left: 0; padding-left: 0;
margin-right: 0; padding-right: 0;
margin-bottom: 0; padding-bottom: 0; }}

@media print
{ body
{ font-family: "Noto Serif" }}

</style></head><body><!--
--><p class="vugy vp vfugy">There seem to be two different linguistic points of view here:</p><!--
--><p class="vugy vpugy vfugy">Descriptive View</p><!--
--><p class="vugy vpugy vfugy">The meaning of a term is determined by how it is used.</p><!--
--><p class="vugy vpugy vfugy">Prescriptive View</p><!--
--><p class="vugy vpugy vf">The manufacturer of a system may determine the terms.</p><!--
--><script>/*<![CDATA[*/
/*]]>*/</script></body></html>

In article <CSS-20240401091111@ram.dialup.fu-berlin.de>, Stefan Ram wrote...
> Here's a current draft HTML resource that shows the complete
> stylesheet I use for formatting paragraphs. This is intended
> to become the basis for my future web site. (In the real web
> site, the stylesheet will be extern.)
>
>

Hmmm. My worst fears are confirmed.

It reminds me of the distinction I draw between a programmer and a software
engineer. The former will express pride in getting something complex working.
The latter will take pride in getting something working demonstrably to
specification and reliably (even under unforeseen eventualities) using code
that is clear and easy to follow so that any successor needing to make changes
won't end up making mistakes. That invariably means reducing the complexity to
a minimum.

CSS is a rather ugly and difficult notation, and it takes skill to write code
that doesn't lose the reader (including the revisiting author) in complexity.
(Do you realise your HTML references two classes you haven't ddeclared in your
CSS?) So being open to a simplifying mindset is a good thing - which will save
you much head-scratching in the future. The underlying intellectual principle
has been documented for hundreds of years:
https://en.wikipedia.org/wiki/Occam%27s_razor (first main paragraph is enough)

So make your code as simple as possible (but no simpler).

That's all from me.

--

Phil, London