I haven’t formally studied CSS in about 4 years, and without access to my SitePoint books, could use come help getting back up to speed.
Here Are some random questions…
1.) Is it correct that by default elements are in “static” mode?
2.) It seems like a lot of solutions I read about on SitePoint include “relative” positioning. Should I always be using that?
3.) For RWD, should I take a diffent approach to positioning? (I am trying to code my first responsive site today, and am not sure where to begin. I want to take the “mobile-first” approach and use an iPhone4 as my starting target and then go from there.)
I wouldn’t call it “mode”, but yes the default value for every element is position:static.
Nope. Most of the time you’ll just want that on the parent of a absolutely positioned element. E.g. if you have a dropdown, you want its positioning/coordinates to base off the parent <li>. So you’ll give that parent <li> a position:relative (so a top:0; will be at very top of the <li> or something like that).
[quote=“mikey_w, post:1, topic:197546”]
3.) For RWD, should I take a diffent approach to positioning?
[/quote]Nope.
Second point; Why would you think that…? The position:relative; does nothing to an element (for those reading; yes I realize it actually does something, but for simplicity sake, please don’t confuse the OP).
If you have a position:absolute; with no positioned parent, that element will definitely NOT go where you want.
The position:relative; child will do nothing to help the absolute element position itself accordingly. Can you explain what logic you’re following that leads you to think the position:relative child is what you would want? I’m not being rude; I’m just trying to follow what logic you’re going off of, so I can correct it .
I mean, yes? EVERY element is position:static (the static value) by default, so I guess if you do set an element to position:relative/absolute/fixed, that does count as being an exception.
You could say the same for any floated elements, any elements with a red background color, etc, etc, etc.
If I didn’t know CSS, I would think that you would absolutely position a parent container, and then any children inside it would be positioned relatively. That makes total sense.
Ah I see. So you’re taking the word “relative” too literally.
Don’t think of what “relative” means, in the English language. Just remember this one simple fact; absolute elements need another “positioned” element (relative, absolute, etc) to “reel it in”, so to speak. Since position:relative does nothing (again, for everyone else, please keep it simple for the OP), that’s the best option to “reel in” the absolute element, while not affecting any other part of your page. With position:relative, the absolute element will have a parent to go off of, while not affecting anything else.
W3schools is often known for their invalid information / old information, but even W3schools says something different to that. W3schools does not say that position:relative moves elements relative to their parent container.
I suggest you re-read it.
The actual number of times you’ll do position:relative and then top/right/bottom/left is almost 0. But nevertheless…
It’s not moving it relative to the parent container. I stand by that; I’m right here.
Did you re-read position:relative? It moves it relative to itself. Not relative to the parent.
You’re straying off path and getting into the complicated part of this. I wanted to avoid this. Position:relative basically creates a box overlay on whatever element you put it on. All the text/colors/images, etc, go onto this newly created box. The original element is underneith basically.
When you do top:100px or something on a position:relative, it moves it VISUALLY (e.g. the generated box) so you SEE it moving, but in actuality, the element itself isn’t moving. Just the generated overlay. The original space is still preserved in the browser; so nothing will try and take its place. Every other element on the page has no clue the position:relative;top:100px element moved at all. They still think it’s in its original place.
Position:static cannot be used with top/right/bottom/left. Those coordinates only work on a positioned element. E.g. relative/absolute/fixed. So actually it doesn’t move it with position:static and THAT is to be expected.
The position:relative; moves it AS EXPECTED.
I would like you to drop the subject, for now, as I fear this is delving into the more complicated aspects of positioning and it is entirely not necessary for you to understand the basics. It’s easier if you get the basics to “click” and then you can understand the more advanced stuff more easily since you sort of understand it anyway; you see the advanced stuff happening but you just don’t know how to explain it.
Yes, Ryan, I am delving into another tangent, but all in the spirit of learning - which you often seem to think I am too lazy to do!
You gave a good explanation above about relative, and you actually sound like my old SitePoint book. I think what you said jogged my memory, so thanks!
I just figured I would investigate this topic, because as I said, I have seen a lot of “You can fix your problem by making the element ‘positioned’…” (I also thought I saw that as a solution for RWD, but could be wrong.)
I am trying to get my head back into HTML and CSS and get the fundamentals down so when I get into fancier stuff like RWD I have a good foundation.
I don’t think you’re lazy. I just think you get overwhelmed with CSS easily so I’m trying really hard to control the flow of information to you to make this seamless for you.
I really only have HTML/CSS “mastered” (noone knows everything but I feel I’m comfortable with them). Everything else I’m mediocre at. The main ability I have is to Google most issues I have and know enough to know how to adapt the code into my situation. I’m pretty poor at JS/PHP.
So really I just have HTML/CSS/Google mastered. That’s enough. TBH if you master Google alone, you can probably make it by. You should make that your #1 skill you want to work on. I’m being 100% serious right now.
Any issue you have, I guarentee there is an answer on Google you just need to search for.
I strive to be a master of much more. Not sure if I’ll get there, but I’m trying!
I know how to Google, but it is easier to find people on sites like on SitePoint that have the experience and know the right answers and that I can trust their advice (usually).
I have spent the who day reading up on CSS positioning and HTML5 and H1 elements, but a lot of the time it is easier to ask someone who can fast-track me to the right answer or direction.
I’m young, and single. All the free time in the world. I’m constantly doing web stuff. I’m a “stud”.
And I doubt I’ll ever have JS mastered (aka all 3 front-end languages). What makes you think you can, with all your responsibilities? Master Google and call it a day.
So perhaps search Sitepoint forums on Google (or even the search function here) because it’s 2015 and a lot of these questions have been asked before. Where do you think half of us are getting our information? Where do you think we learned? Google.
Perhaps I should wait a couple days to respond to questions now.
I used to be proficient with HTML and CSS - working on getting back up to speed. I think I am strong with PHP and MySQL. And I have lots of experience in other business and IT areas.
Could I become a decent full-stack developer if I can get past the drama in my life? Yes.
I use Google when time permits.
When did it become a sin to ask for help on SItePoint? That is SitePoint’s purpose!
I think I ask reasonable questions here, and I usually try to ask questions that will start conversations or debates versus “paste this code in here”.
I come here to learn and grow versus looking things up which is often all Google offers.
How do you think others are decent at their craft? Google. I’m not joking; everyone here Googles most of their questions and knows how to adapt code into their own projects. I wish I was joking but that’s how every developer I’ve ever met works.
Googling is answered immediately. Best case scenario on these forums is a few minutes. Surely it’s smarter to Google?
It’s not a sin. I’m saying it’s a crutch for you. My goal is to help you become a better developer; and 90% of that job is properly Googling. You currently have no incentive to do so.
I’m trying my best, Ryan. I really am. Unfortunately I have A LOT of problems in my life that are much more difficult than how to structure my HTML5 - like finding money for food and gas each week.
You take for granted - at least in your last job - that you get a paycheck to spend a fair amount of your day hanging out on SitePoint and Googling to your heart’s content. I wish I had that luxury. (15 years ago I was able to do that and I learned a hell of a lot.)
But for the last several years it is more like I have an hour to learn and implement something that would take me several hours to research online. So thank God for all of the generous people here that shorten that time.
I want to be more independent and have the foundational skills to spend more time writing “logic” and focusing on “style” versus “Why isn’t this damn code working?!” but I am not there yet.
At least give me credit for trying to learn things like RWD and JavaScript and so on…
.