I have a website that I designed based on the "Holy Grail" layout described in this A List Apart post. A recent Chrome update broke it. You can see the results on the example page for the article (I also made it into a fiddle). Open it in Firefox to see what it should like and in Chrome to see what's happening now.
I realize that this technique is super dated, and I have plans in place to redesign it with Flexbox. But, that will take time, and I was hoping to get it working again quickly in the meantime while I work on a redesign. You can read more about LayoutNG on this page.
Does anyone know any tips and tricks to fix this? Is there a Chrome bug already open that I can follow?
Update: I decided to test it in Canary (v79), and the layout works perfectly there. It's still broken in Beta though (v78). So, I could wait until the current Canary gets released, but that won't be until December according to current estimates. So, I would still like to find a quick fix between now and then if one is available.
Here's some code to make SO happy:
SO won't let me post a link to jsFiddle without code...smart
It turned out to not be that hard to reimplement the layout with Flexbox. So, I just did some good old fashioned user agent sniffing to detect broken Chrome versions and load a small CSS snippet to override the appropriate styles.
Related
Currently, I'm investigating several tips/recommendations for improving the performance of web sites. So, I've started with Steve Souders' excellent books (High performance web sites and even faster web sites), but I've got a couple of questions regarding some of the rules that are presented. FOr instance, chapter 5 of High performance web sites say that CSS stylesheets should be put at the top of the page because putting them at the bottom stops the progressive rendering that is performed by the browsers. According to Steve, some browsers (most notably IE) do get stuck with it and show a blank page instead of showing the items progressively. Here's the url for that test page:
http://stevesouders.com/hpws/css-bottom.php
Now, I do understand that we're talking about a book with a couple of years and that browsers (including IE) have been updated and improved. The reason I'm asking this is because I can't reproduce the behavior he mentions with any current version of FF, Chrome or IE.
Well, the thing is that Yahoo (http://developer.yahoo.com/performance/rules.html#css_top) and google (https://developers.google.com/speed/docs/best-practices/rendering#PutCSSInHead) still say that.
So, what I'd like to know is if browsers have evolved in this area and this is only problematic for, say IE 8? If that is the case, why haven't yahoo and google updated their recommendations? (btw, I've tried simulating IE7 from within IE11 and still don't see the expected result that is described in the book...)
*UDPATE*One more final note: I've decided to reproduce Steve's cgi script in asp.net and I've created a simple generic handler that does the same thing as the sleep.cgi script. what I'm seeing here is that putting a stylesheet reference (which takes some time to load - I've went with 10 seconds) inside the head ends up producing the blank page problem that is reported in the book. If you put at the end, the browser ends up rendering everything and making a second pass for applying the styles after they have been loaded. In my opinion, this makes sense because when you put the style in the header element, the browser is holding up until it gets the styles before rendering (notice that the other referenced components are still being downloaded on the background, but they're not being shown in the screen). On the other hand, when they're at the bottom, the browser will simply apply the current styles until it gets stuck in the stylesheet. WHen that happens, it will only show the html it has loaded until the stylesheet (if there are any images below it, the browser will still download them but it will only render them after the styles have been loaded).
So, after these tests, I'm starting to think that 1.) I'm missing something here or 2.) yahoo and google recommendations are no longer valid today.
Thoughts?
Thanks guys!
Simply inserting a <link> tag in the footer is not the way to defer stylesheets. The currently accepted method is to attach it using javascript:
<script>
function loadStyleSheet(e){if(document.createStyleSheet)try{document.createStyleSheet(e)}catch(t){}else{var l;l=document.createElement("link"),l.rel="stylesheet",l.type="text/css",l.media="all",l.href=e,document.getElementsByTagName("head")[0].appendChild(l)}}loadStyleSheet("/your/stylesheet.css");
</script>
Optimizing your page for speed involves determining what CSS is above the fold, inlining that part in the header, and loading the main stylesheet later using the above method.
I recommend doing some searches for "above the fold css" and check out Google Pagespeed Insights.
https://developers.google.com/speed/pagespeed/insights/
We built a Joomla website for one of our clients which can be located at:
http://mayslakeministries.org/
Although everything was looking fine from our end, the client was seeing the website as if no CSS was being rendered. Unfortunately, I do not have a screenshot at the moment. I will try and get one up here in the next hour or so if we don't come up with a resolution. (If anyone is able to see the mess that I'm describing, if you could post a screenshot that would be appreciated as well. We have limited testing equipment available and it's hard for us to reproduce.)
But here is what we've concluded: the website works fine in Chrome and Firefox on all systems. It works fine with IE10 on all systems as well. However, as soon you switch to IE9, things get strange.
IE9 will work fine if you are on Windows 8, but if you are viewing in IE9 from Windows 7 or Vista, things look as if the CSS isn't being loaded.
Any help would be appreciated. If you view the site and find that the information I've provided contradicts what you are seeing, then let me know. We have limited equipment to test with, so it was difficult for us to be able to see the problem.
This is the first time I've encountered a problem that only occurs on a certain OS.
Oh! One more thing I think is worth mentioning. The Joomla template we are using works fine even on Windows 7 IE9. So we believe it's something that we have done to the website that changed it's behavior.
Here is the Joomla template demo:
http://www.astemplates.com/itempreview/186
Alright, it took is a few days, but we finally figured out the problem.
IE apparently has a limit to the number of resources that can be linked to the page at one time. Our Joomla site has around 200 JS/CSS files being linked through the source, and this caused IE to bug out and not load our CSS properly.
This is one of the strangest problems I've had to deal with, so I'm very glad it's fixed.
I came across this thread a few days ago looking to get rid of the stark white background in the DevTools window. One thing led to another and I started in on adding rules for many more elements using the base CSS file (chrome-devtools://devtools/devTools.css) as a guide.
The file being modified can be found in the following locations:
Mac: ~/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css
PC: C:UsersYourUsernameAppDataLocalGoogleChromeUser DataDefaultUser StyleSheetsCustom.css
Ubuntu (Chromium): ~/.config/chromium/Default/User StyleSheets/Custom.css
Midway through, I started running into a problem when modifying rules with very common selectors. The first two I ran into were #main and #toolbar. When adding rules for the more common selectors, if a web page is also using these same selectors (ie. google search), then the rules are applying to those pages or sites as well.
I understand why this is happening. My question is...
Is there a way to only target the DevTools window in Chrome via this Custom.css file without affecting any other domain?
I've tried using the #moz-document domain () and #moz-document url-prefix ()declarations but can't figure it out...
I'm too far in to give up now, so I'm hoping someone can assist.
Here is a screenshot of my progress so far:
Ok, so after digging around, I noticed I actually missed the notice right smack dab at the top of the original article page:
Since publishing this article the Chrome Team have added a unique ID
to the container of the Chrome Dev Tools. The ID is #-webkit-web-inspector(Trac Reference)
So, the fix to my above post is to add body#-webkit-web-inspector to all of your selectors and it works perfect, thus only targeting chromes DevTools window. Also, very important... to those wanting to create a more complete theme, it’s HIGHLY RECOMMENDED to do it via "inspecting the inspector". More info on how to do this can be found here: How do you inspect the web inspector in chrome?
See screenshot below of "inspecting the inspector":
We have a WordPress website which loads sufficiently in every browser I've tried, except for IE. For some reason in IE, it seems to freeze the browser for a few seconds every single time the page is loaded, doubly so if it has to load a page with an iframe of another page. The user has to wait awhile before they can interact with anything on the page.
Here's the site.
Someone suggested we could use WP Supercache to solve the issue, but I've had problems with this plugin in the past and am reluctant to rely on it, especially since this seems to be only a problem in IE.
What is the best way I can troubleshoot this issue? How do I find out which scripts in the header, or footer, etc. is causing it? Is there a quick way to do so, or do I just need to start eliminating variables within the theme?
I'd don't quite understand why but in IE9 style.css is being pushed right down the page load order - see request #35 http://www.webpagetest.org/result/130327_Y9_f1d5796658d8475b68e2e537644173f1/1/details/
As a browser won't render until it's downloaded the applicable CSS this blocks rendering.
Chrome on the other hand prioritises downloads so that resources that can block rendering are downloaded ahead of images.
Here's a side-by-side video of the two loading experiences.
(If you want help looking at this further my contact details are in my profile)
Thanks to this thread I just found, the answer appears to be fancybox: Fancybox causing slow load times in IE?
Specifically, the IE-specific filters in the CSS file for fancybox. I removed those filter styles, and it loads fine now.
Sorry, I don't seem to be able to give just a comment. Anyway, in Opera 12.14 it works fine. And in Explorer (8) it works just as well, no errors in the console. Just my .1 cent.
I've a problem which is most likely some ugly CSS mistake, but I just can't spot the solution (and a few changes I tried did not help).
Some of in-text hyperlinks (not all!) are shown by Internet Explorer without the following space.
here is the example
See the link WatchBot just below the Rationale title (and a few similar links deeper in the article). Firefox, Opera, Chrome, Konqueror - all display it properly: WatchBot can. IE (6.0 but IIRC also 7.0) displays it as **WatchBot***can*.
I am using Yui-reset and yui-base. Is it possible that those libraries cause the problem?
Do you have a script running on, and altering, the content in any way? I say this because the page loads normally initially, but looks as though it undergos some modification later in the loading lifecycle.
If you think reset or base are making this happen try removing them one at a time - I haven't had any experience of this error before however (I usually use the full whack: Reset, Grids, Base and Fonts).
What I did notice however is that the first WatchBot link of the page is simply this:
<p>Have you ever been curious how is
WatchBot
picking the games to observe and save? Here is the explanation.</p>
Where as the second link looks like this:
<span>Due to the FICS limitations </span>
WatchBot<span> can
I have no idea what that second span is doing there - might be something to check up on. (It validated fine however - so there's definitely an closing span somewhere).
I'd say a good place to start would be to but a space after the anchor but before the span, rather than right after the span start tag.
Current state of the things: as steve_c spotted first, and buti-oxa confirmed, it looks like the layout is being spoiled by javascript (and as Ross noted, some extra spans are injected). Thank you all, I missed it.
I am to make experiments and selectively disable those scripts (analytics and google ads) to check whether it helps (my current bet is that maybe I have some HTML error or naming conflict)
Did you try to disable pageTracker? It seems to be the only script on your page, and it looks fine to me in its static form.
EDIT: I wondered what span Ross was talking about - I did not see any. I viewed the source. I just learned that Firefox allows to see both source and generated source (Toos/Web Developer/View Source). Sure enough, generated source has additional span inserted.
Solution: my page was spoiled by the text-link-ads script (which, in fact I activated on English blog by mistake - this is script by adkontekst.wp.pl, Polish firm). After disabling it everything is OK.
Thanks for everybody who pointed me into the right direction.