Hello! Eyre has never understood html class, child, parent orders and hierarchys: so 1) is there a good website that might explain these relationships and 2) how to all these elements work together with HP layout codes? From my understanding, and my current layout tweaks and fiddles, HP's player info influences my name divider which influences my scroll box placements, which further influences the layout tag's height element which may or may not influence the even flow of the rest of the page flow... I'm trying to stack the two scroll boxes on top of each other, as well. And what is the purpose of a width and height for the "player info" element, aside from putting the msg/buddy/block on one line or another?

Vague descriptions, I know, but some clarity would be helpful, if any direction or aid can be sought. I wouldn't mind a direct fix, but I am also interested in learning the "why" for my understanding, too. 

Thank you, muchly, in advance. (am subscribed to thread so feel free to reply direct or msg me indirectly)

Ok so I'm gonna start you off with w3schools, which is where everyone learns to code from. They're the defining source of web dev info, and the go-to for learning to code. This is the tutorial page for HTML elements that starts to go into parent/child relationships. I would highly recommend following the tutorial from there as it has a lot of info and interactive examples to help you understand how these elements relate to each other :D

I'll start with the parent/child relationships. Take this example:

[div][h1]Header[/h1][/div]

Here, the div is the parent element. A parent element is one that holds the child element inside. The child element here is the h1 element. Putting one element inside of another is called nesting.

[div][h1]Header [span]text[/span][/h1][/div]

In this example, the span is a child element. The h1 is a parent element to the span AND a child element to the div. The div is a parent element to the h1 AND the span. See how the h1 is both parent and child? It's important to note that parent and child relationships are relative. Whichever one is the parent and whichever is the child depends on what specifics elements you're talking about. But basically, if it's inside of another element, it's a child. If it has elements inside of it, it's a parent.

Onto classes. Click here to see the W3Schools tutorial on classes.

This concept is a little more difficult to explain as it mostly has to do with CSS styling, and it includes explaining the ID function as well. The baseline is this: you can name elements in order to style them specifically with CSS. Say we have these three divs:

[div class="holder"][/div]
[div class="holder][/div]
[div id="holder'][/div]

In CSS, you can style all the divs with the class "holder" (so the first two divs) at once, like this:

.holder [ styles here ]

However, your styles would not apply to the third div, because it has a different name. Browsers treat classes and IDs separately, like they're two different names even if the word you choose is the same. In order to style that one, you'd have to add the ID style to your CSS:

#holder [ styles here ]

Now say you have both of these in your CSS. There's another thing you have to know about classes and IDs. Classes can be assigned to multiple elements but IDs can only be assigned to one. Let's add one more div with the same ID as the third:

[div class="holder"][/div]
[div class="holder][/div]
[div id="holder'][/div]
[div id="holder][/div]

Now, if you take the CSS that we had earlier:

.holder [ styles here ]
#holder [ styles here ]

The first three divs would be styled as you want them to be, but the last one woudn't. That's because you can't have two elements with the same ID. The styles would only apply to the first one, and the browser would pretend the second one doesn't have a name and won't style it at all.

So in this case, when you have multiple elements you want to style the same way, it's better to use classes. That way you only have to write out the styles in the CSS one time :D

Prynne did a wonderful job explaining positioning, which seems to be the main issue you're dealing with :D

Something I highly recommend learning more about is the position selector for CSS. You can find more information about this here: https://css-tricks.com/absolute-relative-fixed-positioining-how-do-they-differ/

All images can be clicked on to open them in their original size if they are hard to read!

You have to think of DIV elements as physical blocks that will automatically stack in a vertical column in whatever parent DIV they're sitting inside of.  By default, every DIV position will be set to static which is the same as relative. Their intial positioning is what I call their home and even if they leave their home any DIVs that come after them will by default not go into another DIV's home unless you manually move it into another DIV's home. Every new DIV will automatically bump the next DIV element below the current elements before them.  

Here is an example of six DIVs without any selectors telling them where they should be. This example just shows you their base behavior. 

These six "paper" divs are inside the "desk" div (the parent element), so if the "desk" div moves elsewhere, it will move all of its children, the "papers" (one, two, three, four, five, six), as well because the "desk" div is the container for everything inside of it. This "desk" is an example of something you might use to create a sidebar which contains both a fixed-size update scroll box and navigation or about me section so you can position them together then easily move them together.

Even if you specify where they should be using top, bottom, left, or right CSS selectors, you need to remember that they will still take into account where they originally began and their "home" will remain a factor for any DIV that comes after them. So if DIV1's height is 200px, DIV2 will need to be moved at least 200 pixels up (using TOP:-200px; in the CSS) in order to be on the same x axis as DIV1. If you're trying to put two scrolls side by side, you will want the second scroll to be moved up the height of the first scroll then move it to the right or left by the width of the first scroll to have it sit beside the first scroll without them overlapping.

In the above example, I have moved paper2 up 75 pixels (which is half of the paper1 height) to make them overlap, but as you can see paper3 didn't move at all. It hasn't been told what to do so it remains where it would be if paper2 never moved because paper2's "home" is still remembered.

Okay, um, wow! This actually makes so much more sense than I thought it would! Where were you guys for all my wimpy website layout endeavors?!? If my professors taught like this I would be totally fine in my digital design pursuits! HUGE thank yous!!

w3schools hasn't really made sense to me in the past....Another question: when inspecting a page in developer tools from your browser settings, is there a way to interpret where the parents and their children's childrens are in order to understand your coding tweaks versus the website's default coding interpretation? It helps me to have the big picture AND the immediate picture. Codepen makes it difficult for me to see both, at times.

I hardly ever use the inspect tool for that kind of job. Your best bet is to use the "view page source" option instead. This will allow you to see the entire page coding in the order it's actually being read in and see where your coding is inserted in the site coding.

For example, as you scroll through the page source, you will see the start of the base HP coding, the navigation links, the player info section (where your player links are such as message, buddy request, etc), then you will see the [style] tags that begin your CSS, then your personalized HTML codes. What this means is that if the playerinfo class is set to relative position (or does not have a specified positioning which means it's static which is the same as relative), anything you have in your personalized coding that is set to relative will automatically behave as if the playerinfo DIV comes before it.

To reference my earlier examples, the playerinfo DIV would be paper1 and your first DIV in your own personal coding will be paper2 which means any positioning changes to playerinfo (top, left, etc) will also move any DIVs that follow it. Anything in your personal HTML coding is much easier to track because whatever you have for your first div is paper1, then second div is paper2, etc.

This is a very simplified example to explain the basics of what I believe you're asking about. Unfortunately there is no super simple way to get all the information you want to see cleanly in one place while you're actually actively coding, but hopefully this provides a little more insight as to where you can more easily see how elements are laid out as a whole! ♥

P.S. I feel the need to include this disclaimer. Please don't use the view source option to steal word-for-word coding from exisiting layouts without permission from the original coder. I promise this is 100% more of a generalized side note to all players than to you specifically, Eyre. Personally, there is nothing wrong with seeing a unique element/design/style on a layout and digging into the page source to see how it was accomplished, but do not copy & paste another player's coding into your own layouts without permission. If you're going to copy an idea or style, at least learn how to do it yourself, put a spin on it, customize it further, and really make it your own. Explore! Try new things! Dissect it like you're trying to understand every moving part! It's how a lot of us experienced coders reached the levels we're at now. (:

No, you are completely right! Hand to heart that I do not wish to "steal" codes in such a manner, myself. Ultimately, I would implore someone to let me know if I stole a code from them, even if I didn't mean to do so. Even if you didn't mean to steal a certain aspect of one's code, you didn't ask permission or compensate the code creator in any way or right, so, yeah, it is technically stealing/copy and pasting. 

I try to learn from ctrl u, but can't help but wonder if the random highlights that pop up in developer tools could aid me in real time, as well. Might have to do a bit more digging myself in that regard.

Like I said, a general note to anyone who may stalk this thread now or in the future that perhaps didn't know about page source. I promise I'm not calling you out whatsoever! ♥

Definitely worth exploring! I personally don't have any experience using the developer tools like that, but I could see how it may help. (: Feel free to update this thread if you want to with any findings! I'd be curious to know more.