I have an inline header “fixed in window” by a layer contained in the header. It initially was working as intended: the rest of the page scrolled behind it. Then, after doing some work on breakpoints, the rest of the page started scrolling in front of it.
Checking the code generated, I can only find z-index specifications of 0 throughout the scrolling items that appear on top of the header. I’ve tried using extended code to set the z-index of key elements in the header to 1, hoping that would pop the header in front of the scrolling elements. No luck.
Any suggestions on how to pop the header in front of the rest of the elements on the page?
Also a side question on all the z-index specs in the code: W3schools notes that z-index can only be applied to elements with a position attribute. There are a lot of elements in this file with a default z-index attribute that don’t have a position attribute. Is this just a lot of meaningless code generated by FW7?
I’ve tried using extended code to set the z-index of key elements in the header to 1, hoping that would pop the header in front of the scrolling elements. No luck.
Have you tried selecting the item FullHeadWrap and using Item>Extended add a z-index of 999
I just noticed that z-index code added through “extended” at the default width does not appear when viewing at narrower widths. That is, with the element selected, the extended box is not checked in Item>Extended and the parameter/value pair does not appear under div style.
So I went in and set the z-index for FullHeadWrap to 999 at each breakpoint.
This also did not fix the problem.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
One thing to remember about z-index is that it is locally scoped. If you have a parent element and a number of child elements within it, you can set a z-index on the child elements, and they will be respected within the scope of the parent. But setting a sufficiently high z-index will never allow the child to “escape” from its parent with respect to the page body or the parent’s other peer elements within the body.
If the parent is z-index 5 in the context of the page body, and another of its peers is set to z-index 6, that element will always remain above the children of the first parent (at z-index 5), no matter if you set its children to z-index 1000 or not. The only place where z-index works “globally” is within the scope of a parent element.
Walter
On Jul 12, 2015, at 10:40 AM, Peter Laundy email@hidden wrote:
I just noticed that z-index code added through “extended” at the default width does not appear when viewing at narrower widths. That is, with the element selected, the extended box is not checked in Item>Extended and the parameter/value pair does not appear under div style.
So I went in and set the z-index for FullHeadWrap to 999 at each breakpoint.
#FixedWrap is a child of #FullHeadWrap… it should NOT be position:fixed but instead the parent should be fixed. The clue to this is that a fixed element is removed from the document flow, but in this case can never equal the following containers (#FullWrapProblem, #FullWrapSolution1).
Fixing #FullHeadWrap and setting it’s z-index instead achieves the goal nicely. You will have to give the following sibling (#FullWrapProblem) a margin-top setting equal to the amount of space requested by #FullHeadWrap (watch it, as there is a min-height setting currently on it). But that should get this to play nice(er) in all the browsers.
Best luck on this.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
And I will add, that with fixed headers, I think its good to have some visual indicator to “help” users see your layering, like adding a box-shadow style to the fixed element
box-shadow: 0px 1px 5px 0px rgba(0,0,0,0.3);
and/or a slight transparency in the background color with rgba (.97) so they see the page scrolling up behind it.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
“#FixedWrap is a child of #FullHeadWrap… it should NOT be position:fixed but instead the parent should be fixed. The clue to this is that a fixed element is removed from the document flow, but in this case can never equal the following containers (#FullWrapProblem, #FullWrapSolution1).”
A quick test showed that this will work. Will need some time to fully rebuild. Thanks!
And you are right about needing a drop shadow to provide a visible edge
An update on this. Using extended code in the parent div to set its position as fixed causes problems in IE10: it calculates the vertical position of the inline item immediately below the fixed position div quite differently from other browsers. So the slider I have immediately under the fixed masthead that in other browsers appears around 8 pixels below the masthead in IE10 appears around around 100 pixels higher than that so the top portion of the slider is obscured.
I went back to using the approach for the Fixed header in Backdraft: adding a child wrapper inside the parent wrapper that FW sees as a layer so you can set the position as “fixed in window” using the Inspector. The disparity between how IE10 reads this and other browsers read this is greatly diminished (to around 10px).
#FixedWrap is a child of #FullHeadWrap… it should NOT be position:fixed but instead the parent should be fixed. The clue to this is that a fixed element is removed from the document flow, but in this case can never equal the following containers (#FullWrapProblem, #FullWrapSolution1).
I would be interested to see a link that demonstrates this problem. Perhaps if you could make an example page containing two divs, comparing what happens with each positioning technique. IE 9 and up are actually standards-compliant when it comes to layout, and should not need anything besides a valid page and a normal HTML 5 doctype (so as to not trigger “quirks mode”) to render exactly the same as Firefox or Safari or Chrome. My suspicion is that there is something else in your page that is causing the browser to enter quirks mode, and when it does that, it carries with it all the bad baggage of IE <=8.
Walter
On Sep 1, 2015, at 1:44 PM, Peter Laundy email@hidden wrote:
An update on this. Using extended code in the parent div to set its position as fixed causes problems in IE10: it calculates the vertical position of the inline item immediately below the fixed position div quite differently from other browsers. So the slider I have immediately under the fixed masthead that in other browsers appears around 8 pixels below the masthead in IE10 appears around around 100 pixels higher than that so the top portion of the slider is obscured.
I went back to using the approach for the Fixed header in Backdraft: adding a child wrapper inside the parent wrapper that FW sees as a layer so you can set the position as “fixed in window” using the Inspector. The disparity between how IE10 reads this and other browsers read this is greatly diminished (to around 10px).
#FixedWrap is a child of #FullHeadWrap… it should NOT be position:fixed but instead the parent should be fixed. The clue to this is that a fixed element is removed from the document flow, but in this case can never equal the following containers (#FullWrapProblem, #FullWrapSolution1).
Here are two pages in development with the previous masthead settings. They required much larger top margin settings of the div below the masthead to appear at the right height in Chrome, etc.
It might help to create a more cut-down example that shows the problem. There’s an awful lot going on in these pages, not to mention the iframes, and it’s difficult to see what you are fighting with here. Can you post the screenshots and also screenshots of what you want the pages to look like?
Walter
On Sep 1, 2015, at 3:24 PM, Peter Laundy email@hidden wrote:
Here is my test page where IE10 works only slightly differently than the other browsers.
Here are two pages in development with the previous masthead settings. They required much larger top margin settings of the div below the masthead to appear at the right height in Chrome, etc.
Fix the (outer) parent, make sure that it hasn’t got any height attributes (such as all the following DIVs). It’s the deeper content making this. Measure the height of this fixed package (it’s 122px)
Add a margin-top on the first (inline) DIV (main) exactly the height (122px) of the fixed DIV.
I bet much that this is close to cross-browser understandings.
Cheers
Thomas
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Fix the (outer) parent, make sure that it hasn’t got any height attributes (such as all the following DIVs). It’s the deeper content making this. Measure the height of this fixed package (it’s 122px)
Add a margin-top on the first (inline) DIV (main) exactly the height (122px) of the fixed DIV.
I believe you were suggesting that I edit the “…parent.html” page.
The link here (to" …parentv2.html") has FullHeaderWrap’s position fixed as you instruct (and as I meant to have in “…parent.html”) The only items inside the header that have fixed heights are ones that must have fixed heights.
The FullWrapMain does now and always has had a pixel value that put it in the position I wanted it to be in.
which might cause problems in some browsers (IE10).
Turn this in a regular DIV making the attribute margin-top available or as another alternative, add via extended:
display:block
HTML5 elements seems to be still dangerous if it comes to use them on “constructional” items. I’m not sure what to do in Freeway cause I’m used to do Modernizr in such cases. But good to know.
Cheers
Thomas
Any reason for defining device-height and no scaling min/max in inspectors’ third Tab setting?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
FYI something has gone very wrong with the masthead, including in all the examples I have given links to. Am trying to sort out. Will give you heads up when this is all back in order.
Very strange. Looks very different than in FW. And happened across the mastheads in two different master pages in which I had variations of the masthead.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
which might cause problems in some browsers (IE10).
[…] as another alternative, add via extended:
display:block
HTML5 elements seems to be still dangerous if it comes to use them on
“constructional” items. I’m not sure what to do in Freeway cause I’m
used to do Modernizr in such cases. But good to know.
In Freeway one may add a style (display:block) for the main element in
“sheet1.css” Like so:
In the Styles palette, select “New style”.
Then type the name “main” in the Tag field.
Remove “style1” (or whatever gets inserted) from the Name field.
Click the Extended button and add ‘display’ in name field and ‘block’
in corresponding value field.
This will cause the code main{display:block} to be included in
sheet1.css (which Freeway attaches to every page).
However, it would probably be good if Softpress added this style so that
users don’t have to add it.