Normally KM works well (enough), but on Yr's detailed page ( https://www.yr.no/place/Australia/Western_Australia/Perth/hour_by_hour_detailed.html ) the meteogram is overlaying on the first few hours of the detailed forecast.



This does not happen with IE11 or Pale Moon 26.4.1 (which is set up as much like KM as possible).

Error Console shows a multitude of JS and CSS warnings in Content, nothing for Chrome or Resource.

Any clues?

EDIT: Actually, why worry? I put it through W3C Unicorn, and got 484 (XML) Markup Errors, plus 48 CSS Errors. OTOH, sometimes it's nice to have a fault-tolerant browser :s :END EDIT

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]



Edited 1 time(s). Last edit at 07/24/2017 06:49AM by gordon451.

Found the answer It's a UA problem :O

The landing page https://www.yr.no/place/Australia/Western_Australia/Perth/ generates this XML warning:

Warning: window.controllers is deprecated. Do not use it for UA detection.
Source file: https://www.yr.no/Scripts/OpenLayers-2.13.1/OpenLayers.versjonert.Ulxy8mi6VtIwvn4Nj_1vWnfQN7M.js
Line: 588

So, quickly tell the web admins to get sensible:

Browser sniffing is dead.  Move on.  The nature of Son Gokū is...  Irrepressible!!!!

And we're perfect again

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]

That's how it displays with K-Meleon 76RC here. As you can notice it's slightly different from what you are getting.



As for the landing page, I get no warning. The page displays as shown in the screenshot below.



Latest FirefoxESR I have also tested with, displays both pages correct.

Quote
gordon451
sometimes it's nice to have a fault-tolerant browser :s :END EDIT

Note that K-meleon is as tolerant as Firefox. Non the less they use the same rendering engine.

But have in mind that, even if it is a problem in the site coding, or a new CSS rule not supported, the browser can't do anything.

It is responsibility of the webmaster to check and test for compatibility but the main stream nowadays is "or you are updated to latest or I don't care what happens" and as most nowadays (not as 10 years ago) have up to date browsers, systems, etc, don't expect compatibility but with the latest of the last.

(sorry to sound redundant)


@Yogi, that happens because now 24th day table is empty. I don't have problems either, but wait some time and you'll see again the graph overlying the 25th table.



Edited 2 time(s). Last edit at 07/24/2017 06:25PM by JohnHell.

No warning for me using KM76RCpro by Rodocop.

Aren't there certain Mozilla-prefs to customize this tolerance-level? Perhaps something like that one, or others...
javascript.options.strict

It's not a scripting issue but a CSS one as mentioned already by JohnHell.
You could convince yourself by grabbing your Vista and by testing with an actual FirefoxESR.
If you select the problematic part and click on "View selection source", it will point you to the CSS which old Gecko has problems to interpret.
Probably some CSS rule old Gecko doesn't understand.
BTW, the problematic part gets displayed fine with an actual FirefoxESR with scripting disabled too.

There you have, now that 25th is at the top, the image (actually an SVG) overlays over the table. Looks the oposite, the table overlays the SVG.


Ok, it is a rendering issue. Certainly a bug from our Mozilla friends.

Supposedly, a table is a block element and for whatever reason it is displaying inline without any CSS rule involved :/

But also, comes a question, why the site developer set the SVG as a float right element? What he did expect, a 3000px wide screen where the SVG would be placed to the right of the table? Because, otherwise, they don't fit :/

So, who we blame to, Mozilla, or the webmaster ?


Anyway, if you want to fix it, set a CSS rule to remove the floating status of the SVG in your usercontent.css:

@-moz-document domain(yr.no){
  div.meteogramme-img{
     float:none!important;
  }
}

EDIT: but I'm testing and the tables are block :-?

Some hidden rule must be doing something. I won't dig more. Some dumb site issue. Blame whoever you prefer.



Edited 4 time(s). Last edit at 07/25/2017 12:37AM by JohnHell.

I'm afraid that in this case it is Mozilla to blame.
Even ancient Opera Presto v12 (released in 2009) is displaying the page fine.
However, meanwhile Mozilla has fixed the issue.

- Speaking of SVG files
Try to open this SVG-file with K-Meleon based on FirefoxESR 38 and see what you get.
Newer FirefoxESR have improved and are displaying the SVG-file fine.
Ancient Opera Presto v12 displays the SVG-file also fine.

Quote
Yogi
- Speaking of SVG files
Try to open this SVG-file with K-Meleon based on FirefoxESR 38 and see what you get.
Newer FirefoxESR have improved and are displaying the SVG-file fine.
Ancient Opera Presto v12 displays the SVG-file also fine.

Ok, not Gecko 38, 31 instead in K-meleon 75.0, but there is no difference between K-meleon and Opera 12 :-?

Aside it takes ages to load on both in my slow PC.

What difference should I be seeing?



Edited 1 time(s). Last edit at 07/25/2017 03:13PM by JohnHell.

Might be a regression in Gecko 38.

Except for some details in the king face, there isn't much difference.

Quote
JohnHell

@-moz-document domain(yr.no){
  div.meteogramme-img{
     float:none!important;
  }
}

EDIT: but I'm testing and the tables are block :-?

Not sure if it matters, but there's a blank missing after "none"

Quote
siria

Quote
JohnHell

@-moz-document domain(yr.no){
  div.meteogramme-img{
     float:none!important;
  }
}

EDIT: but I'm testing and the tables are block :-?

Not sure if it matters, but there's a blank missing after "none"

CSS can be written without any space, new lines, etc. In fact most of CSS files out there are this way to save some bytes. What I personally find excessive, even though it really could save some KB in huge files (those from CSS libraries like bootstrap).

EDIT: there are special declarations where spaces can't be omitted like group rules (border: 1px solid black, but lets omit it, as it doesn't apply here .



Edited 3 time(s). Last edit at 07/25/2017 06:07PM by JohnHell.

Quote
JohnHell
Might be a regression in Gecko 38.

Except for some details in the king face, there isn't much difference.

That's weird.

I've downloaded K-Meleon 75.0 based on Gecko 31.
Didn't touch any setting and opened the link for the SVG-file.
I get the poorly rendered SVG as shown in my screenshot above but not the one your screenshot shows.
Additionally I've tested also with FirefoxESR 31.1 and got the same poorly rendered SVG-file.

So we both did test with the same browser (KM 75/Gecko 31) and got different results.

Only explanation I can think of: I was testing on Win7 while I assume that you made the test on Win2k.

So IMHO this doesn't look like a regression but rather as defective code.

Quote
Yogi
Only explanation I can think of: I was testing on Win7 while I assume that you made the test on Win2k.

Yes.

Quote
Yogi
So IMHO this doesn't look like a regression but rather as defective code.

Or none of them.

This deserved to give a try to the torture (slow to hell) of the virtual machine with Windows 7 and this is the result.

I tested twice just in case my own personal installation had something, but no. A clean 75.0 freshly downloaded from SourceForge repository, did the same.

Both with a fresh profile.

I won't say is your system, but NOW it is weird

If anyone wants to test it, go for it.

Quote
JohnHell
I won't say is your system, but NOW it is weird

If anyone wants to test it, go for it.

Thanks for testing!
I'm clueless now. It could be my system as well, for whatever reason.
There are some Win7 users on these forums. It would be indeed interesting to know how the SVG-file displays in K-Meleon on their operating systems.

I have KM76RC2 running on Win10. This is what I see.
On top is KM76RC2, and below is Opera Neon.



Hanlon’s razor is an eponymous adage named after Robert J. Hanlon that states: “Never attribute to malice that which is adequately explained by stupidity.”

JamesD

Thanks JamesD.
That's exactly what I get with KM76RC2, KM75.1 and KM75 on Win7.

Quote
Yogi
... Try to open this SVG-file with K-Meleon based on FirefoxESR 38 and see what you get.

Exactly what you got, but I checked against IE11 instead of Opera. And IE loaded the file instantly while KM76RC was very slow. And yes, Win7 HP SP1 x64.

FWIW, Pale Moon 26.4.1 also struggles and gets it wrong. PM has used Goanna since 26.0, so I don't know how it compares to Gecko ESR.

BUT... Back on topic I'll go with JohnHell, yr.no is a very poorly written site, and it does seem that KM is unwilling to forgive this.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]



Edited 1 time(s). Last edit at 07/27/2017 01:13PM by gordon451.

@gordon451

Thanks for testing.
So it's not my OS (Win7 x64/SP1) but Gecko 38 (and earlier Geckos, for me at least).
However, newer Geckos load the SVG-file instantly for me and also render it correct.

Quote
gordon451

BUT... Back on topic I'll go with JohnHell, yr.no is a very poorly written site, and it does seem that KM is unwilling to forgive this.

I'm not sure if that's exactly the conclusion of JohnHell.
Whatever, newer Gecko has no problem with yr.no.

I found this. It helped my KM75RC2 to set 1st pref to true.

http://kmeleonbrowser.org/forum/read.php?1,139918,139923#msg-139923

Picture became much better and load is faster.

Hanlon’s razor is an eponymous adage named after Robert J. Hanlon that states: “Never attribute to malice that which is adequately explained by stupidity.”

JamesD

Thanks JamesD!

By disabling layers.acceleration (enabled by default) did the trick. Now the SVG-file loads fast and renders fine in K-Meleon (tested only with KM76RC2).
With newer Geckos the SVG-file loads fast and renders fine on the same OS (Win7) with layers.acceleration left with the default setting (enabled).