Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Ever heard of this FireFox bug? 4

Status
Not open for further replies.

Sleidia

Technical User
May 4, 2001
1,284
FR

Hi guys,

It's the second time this bug occures and on two different sites of mine.

The problem is that the site looks fine on my local server (localhost) but some areas of the layout get broken once it's online. The local files and the remote files are exactly the same. No doubt about that. Plus, it occures only on FireFox. IE, Opera and Safari are fine.

What could it be?
I suppose that it's a bug thas has something to do with the delay it takes for the page to load (which is way shorter on local computer).
What do you think?

Thanks :)

 
By "standard code that validate", you mean ugly sites that clients don't want, right? ;)

By "ugly sites that clients don't want", you mean any page designed/written by the experts in this forum, right? Cause most of us write our pages in "standard code that validates".

That's pretty bold to insult each person in a forum that you're asking help from.

-kaht

Lisa, if you don't like your job you don't strike. You just go in every day and do it really half-assed. That's the American way. - Homer Simpson

[small]<P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <B> <P> <.</B>[/small]
 
Well, finding their sites ugly doesn't mean that they are not talented programmers. People come here to get help from programmers, not from artists.

Anyway, you can try to make people feel offended here as much as you please, but my point is that simple: strict W3C code doesn't produce sites that are attractive. And when it does, it's against productivity.

If the most popular sites don't validate, there must be a reason.

 
Is this site ugly?


Does it validate?

I hope you're just trolling with the remark about validating code = ugly sites. If not, you're quite some fool.

And "can't" was exactly the correct word to use. If you notice I said that you can't put block level elements inside inline elements regardless of how you set their CSS properties.

A <span> is an inline element, so even if you set it to display:block to a parser (that ignores CSS) it's still inline.

A <div>, on the other hand, is a block level element and so "can't" be inside an <a> which is an inline element.

Maybe a better understanding of how a webpage is parsed would help diagnose your 'error'.

Pretty much how it is I'm afraid.




--
Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
Your problem might have been fixed by changing divs to spans. But what you describe shouldn't really happen because of it.

I would guess (since you really do not want us to provide thoughtful suggestions but wild guesses) that the problem is caused by the table.

Tables are rendered different across the browsers. But the main character of a table is that it expands to fit the data inside. So browsers will load a table and make sure that everything fits into it. However, with large tables that have a lot of data, some browsers start rendering the table before they receive all the data within it. If you have a really long value at the very end of the table (one that will extend a certain column), the whole table will need to change according to that column change.

Here's the issue. If the browser waits until all the data is loaded before it outputs the table, your error shouldn't happen. Apparently this is how most browsers work. However, FF wants to render the table while it is still being loaded. If half way through FF felt the table was 80% wide, it will render it at that. If at the end you will have a really long value, this will get corrected. However, if you will have floated elements, it will not, because floated elements do not want to extend the parent, but simply stack below. Clearly FF is quick enough on the local computer to display the whole table the way it should. On the remote server, some elements take longer to load, so FF outputs interim table, which is not of the same proportions as you want it, and when you add floated elements, they don't push it to the expected proportions anymore and the page fails.

This is not a bug, it is more the way the tables behave. Given that most of the time tables contain nothing but simple tabular data in the form of simple text and numbers, the issue is not really apparent -- the data loads fast enough and values are either decided to break if there's not enough space, or change the proportions of the whole table.

If you use tables for layout, these errors can occur. I have seen them occur in most browsers, don't think it's limited just to FF. There are only two ways of avoiding it:

1. Don't use tables for layout.
2. Strictly define the table width (and the width of all the columns) at the beginning of the tables (col tags for example) and use fixed table layout to force proportions to be the way you want them to be.

___________________________________________________________
[small]Do something about world cancer today: Comprehensive cancer control information at PACT[/small]
 
strict W3C code doesn't produce sites that are attractive. And when it does, it's against productivity.

You've just proven that you have no clue whatsoever about web standards.

Standards have nothing to do with how something looks. There is no correlation between visual design or information architecture and writing code that validates to W3C standards.

I'll throw a generalistaion/misconception the other way. People who don't code to W3C standards are lazy coders who don't really care for the end result so long as it works when they run it past the client.

--
Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.


 
Please, don't start calling others "troll" just because they have an opinion different than yours.

Yes, does validate.
It's a 3 pages site and I'm sure they did put a lot of efforts for 3 pages.

For a real website ( a dozen of pages with features ranging from blog to discussion forum ), I doubt they could have achieved such a thing. No good for your nerves and not budget wise either.

Of course, you can keep your opinion. This doesn't make you a "troll".
 
Vrag, none of my websites use tables for their layouts.
It's only divs and spans that I use.

But thanks for your nice explanation though :)
 
Standards have nothing to do with how something looks.

Yes and no.

Spending too much time on a big site in order to make it pass the validation means less time for the design and other things.

And maybe I'm a fool but to me, the most important is what the user see/experience.

Only 1% of those who love Ferrari know exactly what's in the engine ;)

 
But the end users are the one designing the engines. If the Ferrari engineers were as concerned about standards as you've proclaimed, Ferraris would go the way of the Yugo.

Lee
 
none of my websites use tables for their layouts.
Really? None of them?

Spending too much time on a big site in order to make it pass the validation means less time for the design and other things.
The idea isn't to spend a lot of time doing it. You don't purposely set out to make them invalid and then have to spend time validating them. If you get into the mindset of writing valid code, then there aren't any errors to fix and you haven't spent any additional time. Granted, there may be a couple of errors that creep in, but I'd only expect to spend a few minutes validating a site.

And maybe I'm a fool but to me, the most important is what the user see/experience.
I don't think anyone would disagree with that. And the easist way to make sure all users get the same experience that you've designed for them is to tell the browsers how to render your page, not make them guess (which is exactly what they have to do) by having invalid code.


-------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions
[URL unfurl="true"]http://weblogs.asp.net/marksmith[/url]
 
You are perfectly entitled to an opinion but that doesn't make it right. In actuality you are pretty much wrong in your assumptions that coding to standards increases development time and produces ugly sites.


Perhaps, and I'm going out on a limb here, but do you think that just maybe you have these problems (and you have few don't you?) because you ignore standards? Hmmmm?

--
Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.


 
For a real website ( a dozen of pages with features ranging from blog to discussion forum ), I doubt they could have achieved such a thing. No good for your nerves and not budget wise either.

I'd like to think that most pages here will validate for the HTML:


I'd call that a real website :)

Of course, there will be one or two pages where the editors have entered dodgy HTML (but I like to believe these are the exception).

The only validation issue I know of is a few lines of CSS (for "inline-block" and "word-break"), but I can easily move those to the IE style sheet.

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch
[/tt]
 
Really? None of them?
Ok, you win: I should have writen "none of the recent ones" :)

And the easist way to make sure all users get the same experience that you've designed for them is to tell the browsers how to render your page, not make them guess (which is exactly what they have to do) by having invalid code.

Well, since all the browsers I test my clients sites on show the same layout, the easiest route for me is not to change anything ;)
 
Well, since all the browsers I test my clients sites on show the same layout
Isn't this thread about a difference in how one of your client's sites is viewed in different browsers (i.e. Firefox)?


-------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions
[URL unfurl="true"]http://weblogs.asp.net/marksmith[/url]
 
Perhaps, and I'm going out on a limb here, but do you think that just maybe you have these problems (and you have few don't you?) because you ignore standards? Hmmmm?

Ahahaha :)
You make it sound like I post too much on the HTML/CSS forum! ;)
But to be fair, all the problems I've encountered were fixed without either doctypes or W3C validation.

Maybe it's dumb, but I'll care about validation when I have no other choice.
 
Isn't this thread about a difference in how one of your client's sites is viewed in different browsers

Not exactly: it was a thread about a difference in how one of my client's sites was viewed in different condition ( local vs remote ).

But again, I fixed the problem without having to add a doctype or to have the site pass validation. The site looks exactly the same in all 4 browsers.


 
But to be fair, all the problems I've encountered were fixed without either doctypes or W3C validation.
And well done if you have, but I think Foamcow was leaning more towards the thinking that some (if not all) of the problems may have initially been caused by the invalid code (and hence if it had been valid from the start then the problems may not have existed). At least that is what I read from his post.


-------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions
[URL unfurl="true"]http://weblogs.asp.net/marksmith[/url]
 
Yarp.

And when you remove the DOCTYPE you let the browser give it's best guess as to what you are trying to do. If this works for you then great. But it won't work all the time, at least not predictably.

all 4 browsers
That many? Which 4?

--
Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.


 
I concede you're right about this.
But I wonder why the W3C decided that it is bad to have divs inside <a></a>. Why be so restrictive when the majority of the browsers can understand that code anyway?
I've submitted my last site to the validator and even the slightest ' provoked an error. Since this caracter is used very much in French language I already felt daunted by the task ;)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top