First, thank you to those who have produced themes for rslight! I do not
have the html/css skill to do what you have done :)

I have a question about how my changes to the default style.css (in
common/themes) and code affects you. I understand a theme can have it's
own style.css, but...

If I add a class, and use it in the code, which I just did for
'short_headers' data, what issues does that cause a theme author?

How can I make these changes without causing headaches?

I ask because I'm not sure :) Thanks for any input!

--
Retro Guy

On Fri, 25 Oct 2024 13:47:00 +0000
Retro Guy <retroguy@novabbs.com> wrote:

> First, thank you to those who have produced themes for rslight! I do not
> have the html/css skill to do what you have done :)
>
> I have a question about how my changes to the default style.css (in
> common/themes) and code affects you. I understand a theme can have it's
> own style.css, but...
>
> If I add a class, and use it in the code, which I just did for
> 'short_headers' data, what issues does that cause a theme author?

If the element is properly reset before use in the CSS before styles it should not have any negative effect should a stylist wish to change it. It looks like you have a small reset at the top in your themes already. Also it is more a lack of unique element classes that makes styling tedious. See more below about classes and custom elements information for creating style agnostic elements to work with.

> How can I make these changes without causing headaches?

Add a lot more classes to the elements and drop the deprecated ones.

> I ask because I'm not sure :) Thanks for any input!

The way things change almost on a dime I don't think any of us can be sure.
<snip>

It is actually the *lack* of enough classes and names that presents problems in customizing a theme. In my last attempt I had to perform a bevy of weird hacks that might not work perfectly in some browsers which I don't even have the ability to test on Linux. I'm afraid to touch the HTML templates because by the time I figure out how to finagle the HTML and output a patch you might already have committed something that would make my changes obsolete.

Each element should have multiple classes in the php-generated html code templates. Here is a fund of suggestions regarding that and more:

1. Add a multitude of classes, ids, and names to the generated HTML templates, and ensure every HTML tag is either a custom element with type classes, or has at least one unique class name for targeting that particular element in its particular location in the document.

For example, a <div> in the top header should have something like: <div class="top_div link div1"> then the next <div> would have <div class="top_div link div2>. Then each <span> inside each <div> would have similar logic: <span class="top_span span1">, <span class="top_span span2 link_span data_span"> and so on. Headings can use classes that identify their section, type, purpose, etc., such as <h1 class="h1 h1_top h1_first">. Add an extra class type for each element of a certain type of schematic data, and add at least one unique class name to every single HTML element generated by the PHP engine. Each <img> or <media> tag can have a unique class name so that image can be directly targeted in the stylesheet.

Class names unused in the style sheets will have no effect on the visible presentation of the page. The ideal is that each element in the entire HTML document has at least one unique class name, and all sectional elements and features (menus, nav, footers, separators, buttons, text inputs, bars, headers, separators) also have both a unique and type class name, and a unique addressable #id and a name="$name" designation where useful. This would not require the CSS sheet to actually style every class, id, and name since unstyled elements and classes are unaffected. It just gives a document class and tree that allows any element to be straightforwardly targeted by a theme designer. I would suggest naming classes more carefully than in my poor examples, if you can forgive my rush.

2. Invent custom HTML elements that are short and descriptive of the initial intended purpose of the element data.

On top adding lots of classes I suggest that you begin converting your HTML output to use custom HTML elements. All modern browsers now render custom HTML elements and these elements can be styled like standard HTML elements so the element may be targeted in the style sheet, giving one more layer for CSS to tweak. For example, Every <h1> tag can be contained in a <head-1> <head-2> <head-top> <head-whatever> <h-whatever> <rubric-whatever> type of tag. The HTML standard does not permit future standard HTML to contain dashes in element tag names, reserving them for custom tags--so you can invent any tag you wish as long as it contains a dash. Here is an example document with a custom element that you can copypasta and test in browsers:

<html>
<head>
<style>
custom-element {
display: inline-block;
text-align: center;
border: 3px solid #333;
background: #777;
color: #FFF;
padding: 2em;
margin: 2em;
font-size: 2em;
} custom-element.lime {
background: #FFF;
color: lime;
border: 3px solid lime;
} custom-element.red {
background: #FFF;
color: red;
border: 3px solid red;
} </style>
</head>
<body>

<custom-element> Look, Ma! I just invented my own HTML! </custom-element>
<custom-element class="lime"> Aren't you green with envy? </custom-element>
<custom-element class="red"> Limes make my face turn red. </custom-element>

</body>
</html>

3. Replace deprecated tags with <custom-element> tags or <div> and <span> tags with class names.

Replace all of these tags and replace them with custom element tags with extra targeting classes, or at least with <div> and <span> tags:

a. <font> ... very much deprecated, and I notice some improper nesting of other tags inside <font> in the PHP templates.

b. <hr> ... create your own tag or use a div, set display:block and width:100% and height:2px with border:0 and background:#whatever.

c. <p> ... create custom tags and classes for surrounding paragraphs based on their location, purpose, and schematic location in documents.

d. <table><th><tbody><tr><td> ... Use <div><span><custom> and/or display:grid or display:flex with display:inline-block so that every table can have unique tag names and/or classes per occurrence for ultimate CSS foo. Each table can have its own unique wrapper tag: <table-top><table-middle><table-tennis>, etc. Then each row and column can also have unique names and type names: <cell-1><column-1><column-2><col-odd><col-even><row-odd><row-even><row-top><row-middle><row-bottom><row-boat>, etc. This way individual rows and columns and cells can be targeted gently down the stream of the DOM. If you want to stick with table tags at least give unique class names to the individual elements in addition to their existing type classes.

e. <b><i> ... replace with <em><strong><span><custom>. Let CSS determine font style rather than the old HTML tags.

f. <center> ... use <div><span><custom> and let CSS align the text.

4. Ignore suggestions to register custom elements with JavaScript. Just don't ever do that.

Custom elements work with CSS out of the box and registering them with JavaScript is difficult, error-prone, and can actually defeat the purpose for 3rd-party styling via CSS. If JS is used to register them then theme designers will likely end up also having to write JavaScript just to change a theme and users that block JS will see a mess if anything at all. This would be harmful. When some Poindexter with a Kryptonian pocket protector tries to tell you to register with JavaScript you are free to ignore them, nod your head, pretend to agree, send them to the Phantom zone, and then forget the conversation ever happened.

5. Tiny nitpick: add <!DOCTYPE html> to the top of every page before the <html> tag.

6. Use PHP echo <<< HEREDOC with bracketed variable substitutions for your sections of HTML code. Set up your variables and functions then follow them with a single HEREDOC for the output from those functions. It cleans things up visually for designers to follow, and allows contiguous HTML blocks in the PHP source that look more like to the rendered output. An example of what I mean can be found at this link: https://gitlab.com/edent/activitypub-single-php-file/-/blob/main/index.php?ref_type=heads#L507

7. Every form element, button, text input, textarea should have a globally unique class name, name, and id, in addition to general ones of type. This way each one can be directly targeted by positioning lower in the CSS file. You yourself do not have to style each unique identifier or class; just having them there is a boon for when someone else wants to target them.

I have never tested custom elements in Microsoft's or Apple's browsers, so I have no idea if they are up to snuff with supporting them. They should be but I don't know.

I am cross-posting this to some Usenet groups appropriate for the topic. Maybe some CSS maestros with more energy than me might chime in or help hack the PHP templates for Rocksolid Light. I have a sore and swollen eye so I'm not going to be much help for a while.

--
Byrl Raze Buckbriar . OCTADE . < https://octade.net >
Hacker Hotline . voice & SMS . (781) OCT-AGON
KeyOxide . < https://keyoxide.org/keyoxide0@octade.net >

On Fri, 25 Oct 2024 19:31:26 +0000, Byrl Raze Buckbriar wrote:

> On Fri, 25 Oct 2024 13:47:00 +0000
> Retro Guy <retroguy@novabbs.com> wrote:
>
>> First, thank you to those who have produced themes for rslight! I do not
>> have the html/css skill to do what you have done :)
>>
>> I have a question about how my changes to the default style.css (in
>> common/themes) and code affects you. I understand a theme can have it's
>> own style.css, but...
>>
>> If I add a class, and use it in the code, which I just did for
>> 'short_headers' data, what issues does that cause a theme author?
>
> If the element is properly reset before use in the CSS before styles it
> should not have any negative effect should a stylist wish to change it.
> It looks like you have a small reset at the top in your themes already.
> Also it is more a lack of unique element classes that makes styling
> tedious. See more below about classes and custom elements information
> for creating style agnostic elements to work with.
>
>> How can I make these changes without causing headaches?
>
> Add a lot more classes to the elements and drop the deprecated ones.
<snip>
> It is actually the *lack* of enough classes and names that presents
> problems in customizing a theme. In my last attempt I had to perform a
> bevy of weird hacks that might not work perfectly in some browsers which
> I don't even have the ability to test on Linux. I'm afraid to touch the
> HTML templates because by the time I figure out how to finagle the HTML
> and output a patch you might already have committed something that would
> make my changes obsolete.

Yes, you've mentioned that. At this point I'm simply adding a class when
I happen to be modifying the code, or adding something. I'm trying to
not reuse classes.

> Each element should have multiple classes in the php-generated html code
> templates. Here is a fund of suggestions regarding that and more:
>
> 1. Add a multitude of classes, ids, and names to the generated HTML
> templates, and ensure every HTML tag is either a custom element with
> type classes, or has at least one unique class name for targeting that
> particular element in its particular location in the document.

I had not considered a separate class for every use of an element. So,
if I have the date displayed in 'short_headers' I would have a different
class for the dat displayed in 'NOT short_headers'. That makes sense.

> For example, a <div> in the top header should have something like: <div
> class="top_div link div1"> then the next <div> would have <div
> class="top_div link div2>. Then each <span> inside each <div> would have
> similar logic: <span class="top_span span1">, <span class="top_span
> span2 link_span data_span"> and so on. Headings can use classes that
> identify their section, type, purpose, etc., such as <h1 class="h1
> h1_top h1_first">. Add an extra class type for each element of a certain
> type of schematic data, and add at least one unique class name to every
> single HTML element generated by the PHP engine. Each <img> or <media>
> tag can have a unique class name so that image can be directly targeted
> in the stylesheet.

A huge chunk of the html is from newsportal, so it takes a bit of
reading through it to figure it out, for me anyway.

<snip>
> 2. Invent custom HTML elements that are short and descriptive of the
> initial intended purpose of the element data.
>
> On top adding lots of classes I suggest that you begin converting your
> HTML output to use custom HTML elements. All modern browsers now render
> custom HTML elements and these elements can be styled like standard HTML
> elements so the element may be targeted in the style sheet, giving one
> more layer for CSS to tweak. For example, Every <h1> tag can be
> contained in a <head-1> <head-2> <head-top> <head-whatever> <h-whatever>
> <rubric-whatever> type of tag. The HTML standard does not permit future
> standard HTML to contain dashes in element tag names, reserving them for
> custom tags--so you can invent any tag you wish as long as it contains a
> dash. Here is an example document with a custom element that you can
> copypasta and test in browsers:

I was not aware of custom elements. I need to experiment with this.
Again, it all makes sense but there's a lot of code for me to consider.
I should take time, as I do for looking for php errors, to just address
code, probably one php file at a time.

I appreciate the tutorial, I'm learning...

<snip>
> a. <font> ... very much deprecated, and I notice some improper nesting
> of other tags inside <font> in the PHP templates.

I really struggle with maintaining proper font info throughout. I can
spend a couple of hours tracking down why half the page becomes tiny.

I have saved the below info for further reading. This is useful and
helpful for me, but also a big job. It will take time.

> b. <hr> ... create your own tag or use a div, set display:block and
> width:100% and height:2px with border:0 and background:#whatever.
>
> c. <p> ... create custom tags and classes for surrounding paragraphs
> based on their location, purpose, and schematic location in documents.
>
> d. <table><th><tbody><tr><td> ... Use <div><span><custom> and/or
> display:grid or display:flex with display:inline-block so that every
> table can have unique tag names and/or classes per occurrence for
> ultimate CSS foo. Each table can have its own unique wrapper tag:
> <table-top><table-middle><table-tennis>, etc. Then each row and column
> can also have unique names and type names:
> <cell-1><column-1><column-2><col-odd><col-even><row-odd><row-even><row-top><row-middle><row-bottom><row-boat>,
> etc. This way individual rows and columns and cells can be targeted
> gently down the stream of the DOM. If you want to stick with table tags
> at least give unique class names to the individual elements in addition
> to their existing type classes.
>
> e. <b><i> ... replace with <em><strong><span><custom>. Let CSS determine
> font style rather than the old HTML tags.
>
> f. <center> ... use <div><span><custom> and let CSS align the text.
>
> 4. Ignore suggestions to register custom elements with JavaScript. Just
> don't ever do that.
>
> Custom elements work with CSS out of the box and registering them with
> JavaScript is difficult, error-prone, and can actually defeat the
> purpose for 3rd-party styling via CSS. If JS is used to register them
> then theme designers will likely end up also having to write JavaScript
> just to change a theme and users that block JS will see a mess if
> anything at all. This would be harmful. When some Poindexter with a
> Kryptonian pocket protector tries to tell you to register with
> JavaScript you are free to ignore them, nod your head, pretend to agree,
> send them to the Phantom zone, and then forget the conversation ever
> happened.
>
> 5. Tiny nitpick: add <!DOCTYPE html> to the top of every page before the
> <html> tag.
>
> 6. Use PHP echo <<< HEREDOC with bracketed variable substitutions for
> your sections of HTML code. Set up your variables and functions then
> follow them with a single HEREDOC for the output from those functions.
> It cleans things up visually for designers to follow, and allows
> contiguous HTML blocks in the PHP source that look more like to the
> rendered output. An example of what I mean can be found at this link:
> https://gitlab.com/edent/activitypub-single-php-file/-/blob/main/index.php?ref_type=heads#L507
>
> 7. Every form element, button, text input, textarea should have a
> globally unique class name, name, and id, in addition to general ones of
> type. This way each one can be directly targeted by positioning lower in
> the CSS file. You yourself do not have to style each unique identifier
> or class; just having them there is a boon for when someone else wants
> to target them.
>
> I have never tested custom elements in Microsoft's or Apple's browsers,
> so I have no idea if they are up to snuff with supporting them. They
> should be but I don't know.
>
> I am cross-posting this to some Usenet groups appropriate for the topic.
> Maybe some CSS maestros with more energy than me might chime in or help
> hack the PHP templates for Rocksolid Light. I have a sore and swollen
> eye so I'm not going to be much help for a while.

--
Retro Guy

On Fri, 25 Oct 2024 19:31:26 +0000, Byrl Raze Buckbriar wrote:

> On Fri, 25 Oct 2024 13:47:00 +0000
> Retro Guy <retroguy@novabbs.com> wrote:
>
>> First, thank you to those who have produced themes for rslight! I do not
>> have the html/css skill to do what you have done :)
>>
>> I have a question about how my changes to the default style.css (in
>> common/themes) and code affects you. I understand a theme can have it's
>> own style.css, but...
>>
>> If I add a class, and use it in the code, which I just did for
>> 'short_headers' data, what issues does that cause a theme author?
>
> If the element is properly reset before use in the CSS before styles it
> should not have any negative effect should a stylist wish to change it.
> It looks like you have a small reset at the top in your themes already.
> Also it is more a lack of unique element classes that makes styling
> tedious. See more below about classes and custom elements information
> for creating style agnostic elements to work with.
>
>> How can I make these changes without causing headaches?
>
> Add a lot more classes to the elements and drop the deprecated ones.
>
>> I ask because I'm not sure :) Thanks for any input!
>
> The way things change almost on a dime I don't think any of us can be
> sure.

I really appreciate the input here recently, it has been a big help in
cleaning up html/css in the past few weeks. I'm sure I still have a long
way to go, but I feel I have a much better understanding of css than
previously.

I will keep fixing what I find as I come across issues. As of now, the
latest code is live and running well (it seems).

--
Retro Guy