Setting up first responsive page

@coothead,

Wow, very strange how the code works!

In this code…

    #containerMast_fixed{
      position: fixed;
      padding: 0 0 1.25em 0;
      width: 100%;
      background-color: #EEE;
    }
    
    #containerBody{
      position: relative;
      margin: 6em 0 0 0;
    }

It appears that if you don’t have a Top: 0; on #containerMast_fixed then it scoots down by the margin (6em) that is on #containerBody.

Why is that?!

Another strange thing is that if I add 1em margins to both containers, the right margin does not appear for #containerMast_fixed. Maybe that has something to do with it being position: fixed?

BTW, @John_Betong, thanks for the links, and yes my HTML and CSS validated.

CSS position:fixed instructs the div to be in a fixed position relative to its immediate parent but also requires the location of the exact position.

It appears from @coothead’s script there is a default left zero position but it is essential to specify top or bottom. The latter was used to prevent the footer from scrolling. I believe the default width acts like display:inline-block; The footer width was set at 100%. Try temporarily setting a background colour to ensure exactly what is being rendered.

1 Like

@John_Betong,

It appears that without Top: 0 the Position: fixed container “floats” above my other container and mimics its position - for example, add a margin or padding on #containerBody and #containerMast_fixed moves with #containerBody.

I am also learning that margins seem to have limited use when working with containers. They either broke things with width: 100% or didn’t work at all.

Attached is what I have so far. It looks pretty good, but I’m concerned that I had to resolve my issues with padding and not margins.

sp_first_responsive_03.php (7.8 KB)

1 Like

Here is the amended code, which includes the padding
being removed from <div id="containerBody"> and
replaced with margins and also the correction of a small
case of “divitis”. infestation :rofl:

sp_first_responsive_03.html (7.5 KB)

coothead

Your end product looks good, but I don’t see how it works with you removing width: 100% from #containerBody ??

Please explain…

Also, in a later version of this code, inside of #containerBody{ } I add a Flexbox like this…

.flexBox{
     display: flex;
     flex-wrap: wrap;
     justify-content: space-around;
     margin: 0 auto;

Not sure why your #containerBody doesn’t collapse with no width?

Ah, yes, I see how I can leverage my H1 now.

Thanks! :slight_smile:

Well, this <div id="containerBody">, being a block-level
element, has 100% width by default. :winky:

coothead

DOH!!

So does that mean I can remove width: 100% from #containerMast_fixed as well?

Also, I sure seem to remember people placing width: 100% on stuff to make sure the container expanded to fill the screen and also adapted to different screen-sizes. So what was the logic behind that?

Hmmm…

I have made a tweak to your code, coothead, to use a css variable to replace the dependency between the height of the mast element and the container’s 6em upper margin. I find is useful to use variables in such cases, to that later down the road, if the mast gets larger for some reason, the container will automatically move away from it. Obviously a better answer would be that these dependencies weren’t in the layout at all, but when they are (in this case due to the mast being a fixed element out of the flow), at least they will be in one place rather than two.

test-resp.html (7.9 KB)

@tracknut,

Wow!

I think I follow what you are trying to accomplish here, but where does this variable come from?

Is that CSS?

Also, in my IDE it is complaining about “HTML file - Error parsing file” as well as “Unexpected token COLON found”

How do I get rid of those?

That’s a “css variable” - https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties

They are relatively new, but most browsers support them. As to the IDE, I can only assume it is not new enough to be able to parse the syntax. If it were me, I’d ignore the error and see if there’s an update to the IDE.

1 Like

No, you may not. :unhappy:

The position:fixed and position:absolute override
the element’s default display:block.

If you did, it’s width would be the width of the h1 element’s
text plus 4em padding. :wink:

coothead

1 Like

@coothead,

Thanks for the advanced knowledge!! :wink:

I recently gotten my knuckles rapped by assuming the css default width value :frowning:

2 Likes

Hi there John,

it appears that my post has, unfortunately,
caused a certain amount of confusion. :wonky:

@UpstateLeafPeeper had asked me why
I had removed width: 100% from his code
and on reflection my answer was poorly
worded and misleading. :unhappy:

I really should have answered it like this…

Your <div id="containerBody"> being a
block-level element with default width: auto
will automatically fill the available space. The
attribute - width:100% in your code can be
considered as superfluous to requirements.

coothead

1 Like

No problem, I just didn’t want you to also get your knuckles rapped, it makes typing painful :slight_smile:

I really like your revised response :slight_smile:

1 Like

I would assume that @UpstateLeafPeeper
will also be pleased that you drew my attention
to that extremely sloppy reply posted of him. .:biggrin:

coothead

1 Like

That’s a good point and why I now prefer position:sticky instead of position:fixed as it suffers from none of those magic number issues and works better in mobiles unlike fixed positioning.

https://codepen.io/paulobrien/pen/OJPPdjj

2 Likes

In your example I noticed that header z-index:99 was set and in desktop Opera and Firefox I was able to see the content scroll behind the header?

I tried adjusting the opacity and the content could not be seen scrolling behind the header. Any particular reason for the scrolling content to be visible?

/*   background: rgba(100, 100, 100, 0.8); */
  background: rgba(100, 100, 100, 1.0);

Because I like it :slight_smile:

It also helps (slightly) with accessibility because you can see what’s happening. Fixed elements interfere with the natural flow of the document and users can be confused when things don’t behave as they expect. Partial opacity also helps when you have in-page links and the fixed header obscures the target. At least if the header is very slightly opaque you can see where the content started.

In the end it’s just a personal preference :slight_smile:

3 Likes

Many thanks for the detailed explanation.

The suggested reasons never crossed my mind :frowning:

I’m convinced :slight_smile:

1 Like