Top Portion of Site Disappears in IE7 - opacity

I am working on a site and the header element is completely disappearing in only IE7 (it shows in IE6 and IE8). It shows for a second, then once the whole page is loaded, it disappears. I have no idea what could be causing this. The portion disappearing is the section I have included via PHP, but it still doesn't show when I actually insert it into the file, so I don't think that is the problem. Any help would be appreciated. I can post any code that would be helpful, but most of it should be able to be found through the view source or inspecting an element.
On a side note, my opacities aren't working in any version of IE either. I have them in a separate IE CSS document and am using the filters, so I am not sure why it is not working.

I figured it out. Apparently IE7 doesn't like negative z-index values and so was placing my background image over certain elements on the page that were above it in the HTML. Strange, but that's IE for you I guess.

Related

Div content shifts after page delay

I have an html file being served by Express, which also fetches data from an api. When I click a link in the navbar and switch routes (or the page is reloaded), the top navbar moves right, then left, and I can't figure out how to fix it.
If you look at the JSFiddle (link below), you'll notice that I have links to other pages, like /profile, /about, etc. Each time one of these pages loads, the navbar shifts (it's adjusting for the vertical scroll bar disappearing, then reappearing).
https://jsfiddle.net/h7bjyk63/5/
To mimic the api call, I added a setTimeout. To reproduce the issue and see what I'm talking about, you will probably need to run this code locally on your machine, and then refresh the page.
The strange thing is that this issue only occurs when there's some kind of delay (like an api call, or setTimeout). If I remove the delay and immediately load the content, everything works fine.
Some css code is commented out. The only key element I want to add later is position: fixed to fix the navbar to the top of the page.
How do I prevent the navbar from moving around?
The browser first renders the page without the scrollbar because it simply doesn't have to. Then you dynamically add few long paragraphs into the DOM, which makes the scrollbar to appear. This is what's causing your content 'shifting'.
The scrollbar is adding up to the width of your page. To prevent it from doing so, you need to do this:
html{
overflow-y: scroll;
}
I finally found something that worked, although I'm not 100% sure it's the correct way to do things. I just changed the width under the navbar--site-header class to 100vw instead of 100%.
DVN-Anakin's answer helped me understand the problem (and one possible solution), and this answer provided some additional good solutions.

Fetch as Google - Googlebot (desktop) not rendering page correctly

I'm having an issue with getting Googlebot to correctly render my webpage(s).
It's rendering the header and one "row" of my page (just the page's top background picture), and then failing to render anything beyond that, not even the footer, missing about 3/4 of the page.
My site is www.runparis.fr and screenshots of the rendered fetch are attached.
Other potentially relevant information includes:
The code that was fetched is missing nothing
The fetch status is complete (no missing resources)
The problem is site-wide; it happens on all my pages
When I check the cache the whole page is rendered perfectly
Fetch as Google (mobile) renders the site perfectly
The site looks fine in any of my browsers
There's nothing funky going on in my page; It's just background images and text. Easy stuff.
My questions are:
Will google's inability to render the page have an impact on how Google ranks it?
Is there any advice for solving the problem and having google render the page correctly?
Thanks for any help or advice anyone can offer!
Googlebot render 2
Edit:
I've done another Fetch as Google and render for a test page and found that Googlebot will stop rendering after it has rendered any background images that I've set to "full height" in my page builder in my Wordpress installation; that is, any image that is set to take up the full height of the browser window kills the render.
So, it will render everything until it hits this image, renders that, and then stops.
As stated before, my page isn't fancy; It's just simple background images and text. It surprises me that Googlebot has trouble rendering what any browser can render perfectly, especially given the simplicity of the pages!!
So, my questions are:
Will Google not being able to render my page impact the way Google ranks my site? (given that what's in the cache renders fine on my browser)
And, Is this a common problem? Are there any fixes that will let Google render my pages correctly?
Some new information supplied by an external source:
"validator.w3.org/nu/?doc=http%3A%2F%2Frunparis.fr%2F"
"jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Frunparis.fr%2F&profile=css3&usermedium=all&warning=1&vextwarning=&lang=en"
The various errors and warnings might explain why rendering is hampered in some tools such as Google Fetch and render.
Browsers are much more forgiving than all these validation and rendering tools.
I'm guessing that in Google's rendering tool the css rules that set the background image(s) and foreground image(s) and text content are being applied in the wrong order so background stuff ends up on top of foreground.
Does this new information help anyone understand why Googlebot would be having trouble to render the page?
I have experienced the same problem, the only viewable thing on the renderer was the hero section, and it was caused with defining height:100vh; for the hero section.This problem occur when using vh css units, or in some cases height:100%;
Here is the thread and discussion that really helped me out to understand the issue:
I believe that the google bot is doing this:
1. Looking at your website with a 1024x768 viewport.
2. Checks how tall the window.scrollHeight is
3. Resizes it's virtual browser to be the same height as the window.scrollHeight
4. Takes a screenshot and
5. Checks to see what elements are visible, and tallies SE score as appropriate. (Dinging content that is not visible.)
I partially solved this issue with inserting extra rules into mediaqueries: So for resolutions around 1024px width, I put max-height:800px; (rule height:100vh; stayed active) on my hero section, and on mediaquery for rules around 1280px width and up, I set max-height:none; (rule height:100vh; is active).
I'm still loosing around 30px of height in the renderer, but that's being cut off at the end of the page, with no text and any meaningfull content.
I have the similar issue with (Google Mobile-Friendly) tool and (Fetch as Google) mobile version is broken because Googlebot is not loading my style.css and affect my rankings
so I output my stlye.css code for mobile manually
add_action('wp_head','load_mobile_styles');
function load_mobile_styles () {
if( wp_is_mobile() )
{
ob_start(); ?>
<style>
enter code here
</style>
<style>
enter code here
</style>
<?php
echo ob_ob_get_clean();
}
}

Mobile-Chrome-App not able to scroll

I also have this issue. I am using Ubuntu and just completed the Hello world tutorial. I wrote some more text and I am unable to scroll. I can see where the words keep going but nothing I have tried lets it scroll. I have not made any HTML/CSS edits. I have only added more text to the <p> tag.
There is some default CSS applied for chrome packaged apps. Putting the following in your CSS should re-enable scrolling:
html {
overflow-y:scroll;
}
Someone is putting together a cool guide which might have some more tips. See https://gist.github.com/maicki/7622137#scrolling
Chrome apps have a default stylesheet applied to them, to help the web "page" be more of an "app" by default.
For Chrome Apps on Mobile, we also include this (well, a nearly identical) default stylesheet.
So that is the reason for that behavior. Scrolling is absolutely useful in very many contexts, and is absolutely supported in any DOM element by adding overflow-y: auto;.
It was simply deemed to be the wrong default for packaged apps which live inside a dedicated window of set bounds and where we encourage not having full page content overflow (very much the opposite of the web). Most apps usually surround a main scrolling element with fixed navigational elements (but not always).
FYI, there is also another open issue for Chrome Apps on Mobile to replicate yet more of the Chrome for Desktop default styles.

modalPopupExtender when shown from code-behind doesnt apply the transparency to the background

While wanting modalPopupExtender to show from code-behind, everything works well except
the opacity and alpha(filter) properties of the CSS are not applied meaning i get a modal popup with the color i set in my BackgroundCSSClass and hence cannot see my original controls in the background.
anyone facing this weird behavior and have a solution for this?
B.t.w, Everything works well when the TargetControlID is not hidden.
I battled this same issue for most of the day today. I have 3 pages with this identical code in them. two of the pages worked as expected, with transparent background, one did not. In that one, the background was always 100% opaque.
Finally, I realised i had accidentally deleted the < !DOCTYPE html > line in that page. Adding that one line back into the page fixed the problem instantly. Simple. and a little unexpected. HTH

GWT not properly rendering on Chrome

I've a really really weird bug in production.
For some customers and some setups (this can happen on a Linux and a Windows box), our GWT application doesn't render in full (there are a widgets that are missing). The weird thing is that if we ask our customers to start the JavaScript debugger (CTRL-SHIFT-J on Windows), the content displays. Viewing using another browser (like FF) works.
We've been banging our heads bloody a few days now... any ideas?
Sounds like a problem with the height of the component containing your logs objects. Did you try to set a fixed height in pixel? I assume once you open the debugger window, Chrome is forced to render the page again and adjusts the height of the container, so your elements become visible.