Sysop: | Amessyroom |
---|---|
Location: | Fayetteville, NC |
Users: | 23 |
Nodes: | 6 (0 / 6) |
Uptime: | 52:04:48 |
Calls: | 583 |
Files: | 1,139 |
Messages: | 111,529 |
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 :)
=20
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...
=20
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!
tag.
On Fri, 25 Oct 2024 13:47:00 +0000<snip>
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.
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.
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:
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.
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.