So i've been experimenting with z-index today, and i really do not understand what is happening here.
Here's a very simplified version of the HTML:
// content has z-index of 30, pos abs
<div class="content">
// content-centered has z-index of 32, pos rel
<div class="content-centered">
// Text and buttons goes here
</div>
</div>
// bubbles has z-index of 31, pos abs
<div class="bubbles">
<div class="bubbles-centered">
// Bubbles goes here
</div>
</div>
The goal is to have .content provide the background content, then the bubbles above the background, and at last the content above the bubbles. What is happening is for some reason the bubbles are above the content.
See demo: http://jsfiddle.net/zFFkv/1/
Give it a few seconds for the bubbles to appear over the content. You can't select the text or push the buttons, because the bubble-layer is above the content layer, even though it's set below. What's going on? Does child elements not inherit the parents index?
Any ideas?
z-indices are resolved relative to their parent, not the whole document.
.bubbles are above .content, and that's all that matters in your case. All the children inside .content will be below .bubbles, but can be ordered relative to each other.
To do what you're trying to do .content-centered and .bubbles will have to be siblings.
You can set pointer-events to none to on the bubbles element to prevent it from blocking the links below, although I don't think it has great support in IE.
.bubbles {
pointer-events: none;
}
Demo
Related
I tried to make two sections to my structure, one is a top section and another is a body section.
I'm trying to make the mainbody divs break away from the top section. For some reason when I add the color purple to a main body div it's coloring in everything else!
I added overflow:hidden to the wrapper and it did something, am I on the right path?
You can see my example here.
Thats because you used floating elements and didn't clear after them. Add
.mainbody{clear:both;}
But why do you have .topsection{float:left;}? If mainbody has width: 100%, it does nothing.
And overflow:hidden did somethink because if you have a block element with some floating elements before him, and you set overflow different than visible to him, you are creating columns. So then mainbody wasn't under topsection.
Edit:
Even if you remove the nonsense .topsection{float:left;}, it won't work because topright and topleft are not cleared floating elements too. So you have to add .mainbody{clear:both;} too, or change your topsection into:
<div class="topsection">
<div class="topright">...</div>
<div class="topleft">...</div>
<div class="clear"></div>
</div>
And then
.clear{clear:both;}
I'm learning css and was struggling to understand why the html is rendering like so:
http://jsfiddle.net/46nVs/
I can understand why the the red border is being cut off from the top and left. It's because outlines don't take up space since they're drawn outside of the box: https://developer.mozilla.org/en/CSS/outline. In this example they're being drawn outside of the <body> element.
However I was confused as to why border is being cut off from the
top. Any ideas?
What css can be applied to the <span> element to make the entire
outline and border display?
Also, is it ever considered okay to place an inline element next to
a block element like <span>somestuff</span><div>somecontent</div>?
Border (and padding, for that matter) are being cut off due to <span> being an inline element.
Any block level element (or anything with display: inline-block) is subject to different rules (eg. can have width set), and one of those rules says "Block elements are positioned from the start of the border, inline are position from the start of the content".
Quick Edit: You've changed your question, and Sagar has answered the other parts of it well enough for me not to bother :)
Point 1:
If you add a float:left or a display:block, the box will render correctly. This is because span is an inline element.
Point 2:
Add the following:
margin:10px 0 0 10px;
float:left;
Point 3:
You can place an inline element next to a block element as the design requires. You can also change the display style of the inline element by setting display:block or display:inline-block or any of the other display values allowed.
In addition to what others commented, the thing to remember here is not to use span's unless you want to do color or font changes (by applying a class), for example:
<div class="post">
<div class="post_information">
<span class="date">11/1/2012</span>
<span class="author">Mr. Smith</span>
</div>
<p>Lorem ipsum</p>
</div>
.date {font-weight:bold;}
.author {color:#ff0000;}
If you want a "box" behavior, use a div or a p instead. Overriding the default behavior of span to make it display as block, although technically possible, will probably mean you are using the wrong element or your HTML is not semantic enough. (span has no semantic value)
iOS 5 released web designers a new property -webkit-overflow-scrolling:touch that uses the iOS devices hardware accelerator to provide native scrolling for a scrollable div.
When implemented on our site in development it does work but not well. I believe there may be a CSS issue hence I ask here.
The following fiddle will show you it working perfectly
If you pop over to our site in development you will find the same panel under facilities tab but on iOS although the scrolling is perfect the overflowed section is not shown with pictures literarily chopped in two.
http://www.golfbrowser.com/courses/mill-ride/
I have no idea how to fix this
http://www.golfbrowser.com/photo.PNG
As #relluf pointed out, applying 3D transitions on the relative element fixes the bug. However, I investigated it a bit further and it seems that applying -webkit-transform: translateZ(0px) works too (this is what Google does on gmaps map container) and it does not need to be on the relatively positioned element, just the direct descendant of the scrollable element.
So if you don't want to manually keep a list of all the places where the fix is needed, you just might do:
element {
-webkit-overflow-scrolling: touch;
}
element > * {
-webkit-transform: translateZ(0px);
}
What a bugger they let loose here. Tried all manner of workarounds until I finally found the only property needed by for elements to be properly rendered in a -webkit-overflow-scrolling:touch div: position: static
Relative and absolute positioned elements are always cut off on the boundary, and completely missing (except for empty space) outside of it. If you change the position property dynamically, from static to absolute, only the visible portion of the scrollable div viewport stays rendered, wherever the offset happens to be.
I have run into this bug as well. I fixed it by applying the following css to parent elements:
-webkit-transform: translate3d(0, 0, 0);
However, I have noticed that that slows down rendering and might select other input elements than wanted when a touched input element is scrolled into the center of the view (by Safari/iOS).
In iOS, when an element inside an element with -webkit-overflow-scrolling: touch set is positioned absolutely (or fixed) relative to an element outside of the scrolling container, the element is rendered only once and the rendering is not updated as the element is scrolled. Sample HTML:
<div class="relative-to-me">
<div class="scrollable">
<div class="absolutely-positioned">
</div>
</div>
</div>
If you force a re-render by changing a CSS property (in the inspector for example), you can see that the element's positioning is re-rendered into the correct location. I suspect this is a result of some performance features to optimize scrolling performance.
The solution to this problem is to set will-change: transform on the absolutely (or fixed) positioned element.
.absolutely-positioned {
will-change: transform;
}
I deeply investigated this bug, I also created a jsfiddle and submitted it to Apple in a bug report. Please see: iOS5 Images disappear when scrolling with webkit-overflow-scrolling: touch
As soon as Apple replies to me, I'll report it on that topic so you can stay up-to-date about this very annoying bug
I also experienced the problem where overflow scroll with -webkit-overlfow-scrolling set to touch resulted in redraw problems with positioned elements. In my case I had a list where the individual items had relative positioning so that I could use positioning on their child elements. With the above CSS on iOS 5, when the user scrolled hidden content into view, there was a momentary delay before it redrew the screen to review the elements. It was really annoying. Fortunately I discover that if I gave the parent node position relative as well, this was resolved.
The bug still lives in iOS 6. If your issue is related to position: relative, you might solve the issue be setting z-index: 1 temporarily via JS. -webkit-transform: translate(...) did not work with position: relative in my case.
I tried some different solutions, seemed not work perfectly in my case.
Finally I've found a way works fine with jQuery:
Apply -webkit-overflow-scrolling property every time when you touch up.
*At first I Applied Also -webkit-overflow-scrolling:auto when TouchDown, to disable iOS rendering. But it made Page blink. So I dropped it away, then works fine surprisingly!
Check lines below, hope it helps:
<!-- 🍉 JQuery Functions-->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
<script type="text/javascript">
//🍋 Apply -webkit-overflow-scrolling in Every TouchEnd
$(document).on('click touchend', function(event) {
$("#TestDIV").css({"-webkit-overflow-scrolling":"touch"});
});
</script>
<!-- 🍉 html Elements & Style -->
<div id="TestDIV">
<div class="Element"></div>
<div class="Element"></div>
<div class="Element"></div>
<div class="Element"></div>
<div class="Element"></div>
</div>
<style>
#TestDIV{
white-space: nowrap;
overflow-x: scroll;
-webkit-overflow-scrolling:touch;
}
#TestDIV .Element{
width:300px;
height:300px;
margin: 2px;
background-color: gray;
display: inline-block;
}
#TestDIV .Element:nth-child(odd){
background-color: whitesmoke;
}
</style>
UPDATE
Here's a fiddle to play with:
http://jsfiddle.net/UnsungHero97/RQCt3/1/
Here are two screenshots that show what I'm encountering...
The weird thing I'm encountering is this. When I hover my mouse over the <img> element, it shows its dimension as 288x72, which is what I expect it to be since I set the height of the image as 72.
However, when I hover over the <div id="logo"> element, it shows its dimensions as 288x76, which means there is an extra 4 pixels somewhere contributing to this height.
If you notice the CSS properties for the <div id="logo"> element, there are no paddings or margins or heights specified.
So where are these pixels coming from? Why is this happening?
An easy way to fix this is:
img{
vertical-align: top;
}
Live example: http://jsfiddle.net/RQCt3/2/
The reason is that images in HTML are considered inline elements and so by default are aligned on the font base line. The extra space is probably to allow for the bottom of letters etc.
Similarly adding display:block will also do the job:
img{
display:block;
}
Compare these 3 URLs (look at the top navigation bar in each case):
http://fast.kirkdesigns.co.uk/blog
as above but with the url fragment #navigation
as above but with the url fragment #node-2655
Note, that the only difference is the URL fragment on the end.
The first two pages display absolutely fine (in Firefox at least). It's the third one where the problem lies. The fragment #node-2655 pushes the top navbar off the top of the screen. When you then scroll back up to the top of the page, the navbar has been cut in half. This happens when using any URL fragment that causes the navbar to be out of the initial viewport when the page is first loaded.
So, how can using a url fragment affect the css layout like this?!
THE SOLUTION:
as suggested below, removing the overflow: hidden on the container element that held the navbar fixed the problem. I'd love to understand why though!
Remove the overflow:hidden on #main in css_75afd7072eaf4096aaebf60674218e31.css
I'd say it's a rendering bug in FireFox as it's fine in Opera. There shouldn't be anyway an anchor would change the CSS like you say (unless you are using jQuery or something).
I am having this problem too, and think I can see what is happening.
The "column" block with the massive (5678 pixel) margin and padding makes that block very tall. In browsers other than Firefox, the positive and negative values cancel each other out, but FF really does make it that tall - kind of.
FF also knows the two cancel each other out, but seems to look at the 5678px padding and decides the column block is poking out the bottom of the #wrapper block. This is overflow - and with overflow set to auto on #wrapper, you see the true size of #wrapper with a scroll-bar down the side.
With overflow set to hidden, FF takes away the scrollbar, but still seems to scroll the contents of #wrapper so that the item the fragment points to is at the top of the page. This is normal behaviour for fragment links in scrollable blocks, but since there is no scrollbar, you cannot scroll the content back down again, hence it looks like the layout has been effected by the fragment.
So in short, I suspect that FF is operating an invisible scrollbar in this example. That could be considered a bug, but it is probably correct behaviour. Being able to scroll the content up and down inside a non-overflowed fixed-sized block using URL fragments, is a technique that can be used effectively to implement image "sliders" that work even in the absence of JavaScript.
Hope that helps. This has been puzzling me for years, and this explanation suddenly struck me out the blue. My current workaround for this is to use jQuery "scroll to" plugin to scroll the whole page down to the fragment, as this seems to prevent the contents of #wrapper from scrolling internally.
You can also take "display: hidden" off #wrapper, but your page then ends up half a mile long.
I'll just point out that there may be some weird inheritance from the 30+ stylesheets linked to in the head. There may not, either, and it's probably a rendering bug (possibly related to :target styling) that Dan suggested. I just felt it worth pointing out that if you've got more than thirty stylesheets, you likely to start seeing some weirdness, whatever else might happens.
The reason is the column with the large padding has expanded it's container, but the expansion is then hidden but overflow:hidden; but with the use of the fragment it is being scrolled into the position of the fragment, effectively chopping off anything above that. You can use javascript and set scrollTop to 0 and it scroll it back to the normal position.
Basically a wierd edge case which browsers do not seem to handle very well.
Sorry this isn't an "answer," tho it is a response to the other comments here. This problem is just flabbergasting. It is very easy to isolate (i.e., has nothing to do with number of stylesheets), and doesn't have a proper "solution," as there is no way to achieve the desired rendering.
<!DOCTYPE html>
<html>
<head>
<style>
#container {
margin: 1em auto;
width: 40em;
}
#wrapper {
overflow: hidden;
position: relative;
}
#c1 {background-color: #aaf;}
#c2 {background-color: #ccf;}
.column {
float: left;
margin-bottom: -5678px;
padding-bottom: 5678px;
width: 50%;
}
#footer {
background-color: #eee;
padding: 1px;
text-align: center;
}
p {margin: 1em;}
</style>
</head>
<body>
<div id="container">
<div id="wrapper">
<div id="c1" class="column">
<p>This is some content in a short column. We would need some Javascript to change its height if we wanted a different background color for each column to stretch the full height of the respective columns...or we can use large padding together with an equal negative margin.</p>
<ul>
<li>Jump to P1</li>
<li>Jump to P2</li>
<li>Jump to P3</li>
</ul>
</div>
<div id="c2" class="column">
<p id="p1">The desired effect is to have the height of the two columns appear the same. We use 'overflow:hidden' on the containing div (#wrapper) to wrap it around the floated columns.</p>
<p id="p2">These paragraphs have fragment identifiers. Problem comes in when clicking one of the links on the left. Instead of scrolling just the page, the browser scrolls the div with 'overflow:hidden' so the target is at the top. It does this even if the target is already visible.</p>
<p id="p3">Opera does not exhibit this behavior. This occurs in Chrome/Safari, Firefox, and IE. (Interestingly, IE also works as expected if we completely remove the DOCTYPE declaration.)</p>
</div>
</div>
<div id="footer">
<p>Footer stuff.</p>
<p>To see why 'overflow: hidden' (or any other piece of the CSS) is needed, just try disabling it.</p>
</div>
</div>
</body>
</html>
Just as a side-note, the above technique is generally used to provide flexible-width mulit-column layouts. This is probably becoming less important these days as fixed-width layouts are becoming a lot more comment - browsers are able to magnify the web page to see small text, and fixed-width makes it a lot easier to control the typography of a page, e.g. set the width (in ems) to display the ideal nine words per line regardless of what font size and magnification the user chooses.
Sorry if that does not sound like an answer, but it is basically suggesting to discard this old model and consider moving to fixed-width columns (which is a whole new subject).
I was able to solve this with some javascript to scroll the body to the position the overflow hidden element was scrolled to.
setTimeout(() => {
let intendedScroll = document.getElementById("fragmentfix").scrollTop;
document.getElementById("fragmentfix").scrollTop = 0;
window.scrollTo(0, intendedScroll);
}, 0)