Odd behavior with Firefox

[John_C]

I am going through the Wicked Wordpress book. I'm on Chapter 5 and added some social media buttons. I noticed that Firefox was behaving oddly. When I clicked on the title of a post, the top of the new page would be cut off from about the middle up. When I clicked on another page, same thing. When I clicked the refresh button, the entire page would show. I don't get this behavior in IE, Chrome, or Safari. After spending some time trying to narrow down the cause, I am sure that it's a Firefox problem and not related to the code (although I am open to any solution). When I click on a link to take me to another page, this problem occurs. However, when I clear the history (including the cache) and then go to another page, it works as it should displaying the entire page. But I have to always clear the cache each and every time before I go to a new page otherwise I will only get a half of page.

Does anyone know how I can fix this. Also, is this going to be a problem when others are viewing my site in Firefox?

Thanks,

John

[ralph.m]

Do you have any JavaScript on the site? Try disabling it and then trying the links. I've seen this happen with rogue JS scripts for things like ads and so on.

[John_C]

Hi Ralph,

Thanks for responding to my question.

I tried disabling the JS but that was not the problem. This is just a practice site as I go through the Wicked Wordpress book. I am mostly exploring the functionality of Wordpress (this is my first excursion into wordpress). Maybe you can see if it's doing the same in Firefox on your computer: http://www.webdevpractice.com/blog/

If you click on a title that links to a single post page, that's when I usually have the problem. This theme (which is not much of a theme at this point) is a child theme based on the thematic theme. I switched it back to the Thematic theme to test it and it works fine. So, I suspect that the problem might be with some sloppy code in the "Linens and Letters" theme. I am not too worry about this at this point since I am just experimenting with wordpress, getting an idea how it works (scientiam adquiro eundo). I probably have some incorrect code somewhere.

I removed files one by one from the remote server and when I replaced them, it seemed to be fine. But then after a number of clicks on the Post titles and the About button, it started behaving the same way-cutting the top part of the page.

Thanks, again for responding. If you have time, take a quick look. If something isn't immediately apparent, don't spend more than a couple of minutes on it. When I get serious about building the site, I'll be very careful, testing it often.

John

[ralph.m]

Try getting rid og this (very unhelpful) CSS rule:

#branding {
  margin-top: -500px;
}

It's on line 88 of linens.css.

[John_C]

You found the problem! I don't know why I used a margin rule; I always use a text-align with a negative number to hide text like branding. Anyway, thanks for your help. Now I know what was happening.

[Ketset2012]

Ummm, I haven't come across this yet, hope I don't - I still think Firefox is the best of the Browsers though.

[John_C]

It wasn't a Firefox problem. I was messing around with the styles and set the branding to a negative top margin to hide the text that wordpress put there. That is what was causing the top 500px from being cut off. Like you, I was worried that it may have been a Firefox bug. When I tested a different theme I was relieved that the problem was not occurring with a different style sheet. Ralph located the faulty css rule, it was replaced with a text-align rule with a negative value to hide the text, and the problem was solved.

[ralph.m]

I always use a text-align with a negative number to hide text like branding.

Glad to have sorted it. It might be worth digging into the theme and just remove the branding if you don't want it, as people using screen readers etc. will still have it read out to them. Display none can be more effective for hiding content from screen readers.

[John_C]

Actually, I just want to hide the branding. The branding ID handles the tagline, right? I intend to use a graphic tagline so I want the branding read by the search engines and the screen readers.

As far as digging into the theme, I am certain that I'll be posting questions about various challenges I need help with. I'm a little queasy when it comes to php.

[ralph.m]

The branding ID handles the tagline, right?

I'm not really sure what you mean (I'm not a WP person). But if you are trying to replace text with an image visually, then I see what you are doing. If your image is not transparent, an alternative is to place the image over the top of the text. The advantage of this method is that, if images don't load for any reason, the actual text will appear instead.

(I have one of my mobile browsers set to "images off" to save bandwidth. It's amazing how poorly a lot of sites perform with images off. I always test my sites to make sure they work nicely with images off.)

[John_C]

If you have a graphic for a tagline, you probably don't want the text to be placed on top of it. So, with CSS you can hide the text by setting a rule like text-align: -9000px;. That way, your tagline is still available for the search engines since it's text (even though it's hidden and not just a graphic. The alt tag, which should always be included with a good description of the image, will be read by the screen readers and the alt attribute provides the alternative text that displays if the image doesn't load.

Do you create a stylesheet for mobile devices? You could eliminate images altogether to reduce the bandwidth for mobile devices.

[ralph.m]

If you have a graphic for a tagline, you probably don't want the text to be placed on top of it.

The method I linked to shows how to place the original text underneath the image, not on top.

So, with CSS you can hide the text by setting a rule like text-align: -9000px;. That way, your tagline is still available for the search engines since it's text (even though it's hidden and not just a graphic. The alt tag, which should always be included with a good description of the image, will be read by the screen readers and the alt attribute provides the alternative text that displays if the image doesn't load.

Unfortunately, not all browsers display the alt text like that—such as Webkit browsers. So if images are off, it's still likely that there will be nothing there at all. That's why the method of placing the image over the text is the best method available currently.

Do you create a stylesheet for mobile devices? You could eliminate images altogether to reduce the bandwidth for mobile devices.

At the moment, I tend to add a few extra media queries to the main style sheet, but it may be better to use a separate one. Haven't made up my mind on that one yet. Unfortunately, mobiles sometimes download images anyway, even if you don't serve them up. Not sure where the line is drawn. Certainly if you, say, have a background image in a stylesheet and then set it to no background image via media queries, the image still downloads. Perhaps that's not the case with a separate style sheet, but I'm not sure.

[John_C]

The method I linked to shows how to place the original text underneath the image, not on top.

I'll check out that link you provided.

Unfortunately, not all browsers display the alt text like that—such as Webkit browsers.

I thought you were mistaken about this. I looked up the alt tag in the sitepoint html ref book and it indicated that the alt tag is fully supported by all the browsers they listed. Then, I search the web and found that the alt tag is not fully supported (or behaves as you indicated) in Safari and Chrome. What a shame.

Regarding the handheld stylesheets: I haven't used them but I intend to. I think they work exactly like print stylesheets work (which I use a lot). So, if you can style your web site without images, which would be easy to do, I think that is the way to go. When you turn off the images on your mobile device, do you have a placeholder where the image was? If you use something like a jquery carousel, it will not display any images -- just a large placeholder -- so these sites should definitely use a handheld stylesheet.

[ralph.m]

I looked up the alt tag in the sitepoint html ref book and it indicated that the alt tag is fully supported by all the browsers they listed. Then, I search the web and found that the alt tag is not fully supported (or behaves as you indicated) in Safari and Chrome. What a shame.

Yes, it's supported in all browsers in that it reads out text to someone who can't see the image; but the alt text doesn't necessarily display on screen (which I guess is not the primary intention of alt text. I'm not sure what the specs say.)

Regarding the handheld stylesheets: I haven't used them but I intend to.

Ah, I thought you just meant style sheets targeted to mobiles via @media queries. E.g.

<link type="text/css" href="screen.css" media="screen,projection,tv" >

<link type="text/css" href="smallScreen.css" media="screen and (max-width:751px)" >

Many mobile devices take no notice of media="handheld", so it's kind of a dud technology. For example, iPhones ignore it, and most other smartphones, I believe.

[John_C]

Well, I did mean stylesheets targeted to mobile devices (I guess no one refers to them as "handheld" anymore) like the examples you gave using the media queries syntax. As I mentioned, I haven't used them yet, but I'll be looking into it. We are in one of those transitional periods where browser technology is still lagging behind html 5 and css3. This is way off the original subject, but I am curious: Are you implementing any of the html5 or css3 technology?

[ralph.m]

Are you implementing any of the html5 or css3 technology?

Personally, I just use CSS3 round corners and maybe some drop shadows here and there. Despite appearances, CSS3 and HTML5 are still on the drawing board, and not ready for full use—especially HTML5. It's not really fair to expect browsers to be up to date with specifications that aren't finished yet. IE5 jumped the gun on CSS and got a lot of it wrong, and we all suffered for years because of that. The same thing is happening again.

At least CSS3 exists in modules, some of which are more ready that others. It makes it a tad more viable in patches than HTML5 at this point.