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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Strange rendering when page called with anchor 3

Status
Not open for further replies.

OsakaWebbie

Programmer
Feb 11, 2003
628
0
0
JP
I have a longish page in which I have put two anchors to lower sections. But when the page is called with one of the anchors, in some browsers (Firefox, Safari, possibly others) the top portion of the main content div (about 22 pixels, I think) is chopped off, leaving the content title sliced in half. Take a look at and scroll back up to the top to see what I mean. The page is dynamically generated (Joomla), but if I save the page called with and without an anchor as HTML files and run ExamDiff on them, they are identical, so it's not something Joomla is doing differently. I suspect my CSS is funky somehow, but I don't know how. Usually when some browsers work and others don't, it's IE that does it badly, but this time IE is okay but my beloved Firefox is rendering it strangely.
 
Hi

Usually I would say, there are too many errors, so do not expect the document to be rendered as you imagined :
W3C Markup Validation Service said:
[highlight #EAEBEE] Result: [/highlight] 62 Errors, 49 warning(s)
But I will not say it this time. Long time ago I saw similar rendering mistakes and those were bugs of the rendering engine. ( But feel free to fix those errors. )

I have no idea how to solve it, but this dirty trick will force a re-rendering of the document and makes the ugliness disappear in Gecko ( FireFox, SeaMonkey, Galeon ) and WebKit ( Epiphany, Midori, Arora ) :
JavaScript:
window[teal].[/teal]onload[teal]=[/teal][b]function[/b][teal]()[/teal] [teal]{[/teal]
 [b]if[/b] [teal]([/teal]window[teal].[/teal]location[teal].[/teal]hash[teal])[/teal] document[teal].[/teal]body[teal].[/teal]innerHTML[teal]=[/teal]document[teal].[/teal]body[teal].[/teal]innerHTML
[teal]}[/teal]

Feherke.
 
But feel free to fix those errors.
I hear you, but I didn't write Joomla, the numerous extensions I'm using, or the template used for the layout - there are hundreds of files involved, and they are highly object-oriented, which is not my specialty. If I tried to fix all the validation errors, not only would it probably take me weeks, but I would probably create all kinds of new bugs that weren't there before. I don't trust myself with other people's code - maybe that sounds like an excuse, but...
this dirty trick will force a re-rendering of the document...
Thanks, I gave it a whirl. (I have no idea if inserting that little script at the end of the head section of the main template file is safe or if it breaks something else - I assume only one function can be called for the load event, and don't know if another one is buried in one of the several .js files linked in. It looks okay so far, though.) But here's the hitch: Your trick works (in FF at least) for the situations where the page is actually being loaded (a refresh or coming from a different page), but if the page is already showing and I click an internal anchor link or a menu item that points to the same page with a hash, the page doesn't actually reload (so the load event is not fired) but the content still "slides up" or whatever it's doing. Can you think of another event I could use, or a different idea?
 
Hi

OsakaWebbie said:
I have no idea if inserting that little script at the end of the head section of the main template file is safe or if it breaks something else
As I see, the moving lights above and below the selected menu item are not moving anymore. So probably indeed got broken. Would be better to place it at the end of the [tt]body[/tt], without involving the [tt]onload[/tt] event :
HTML:
[gray]<!-- ... -->[/gray]

[b]<script[/b] [maroon]type[/maroon][teal]=[/teal][green][i]"text/javascript"[/i][/green][b]>[/b]
if (window.location.hash) document.body.innerHTML=document.body.innerHTML
[b]</script>[/b]

[b]</body>[/b]
[b]</html>[/b]
Hopefully it will still work.
OsakaWebbie said:
if the page is already showing and I click an internal anchor link or a menu item that points to the same page with a hash
Ouch. I not noticed that before.

My only idea is to call that [tt]document.body.innerHTML=document.body.innerHTML[/tt] for those links ##onclick## too. Possible to need some minimal delay. But that is a really ugly workaround.


Feherke.
 
Actually, I take back part of what I said - it sometimes reloads, sometimes not. If the last way of getting to the page was one of the three menu items that have hashes, clicking another one of them does not reload the page. Same goes for the jump links at the top of the page itself. But the two types are different enough that if I alternate, for example, between menu items and on-page links, it will always reload. So your trick is still not perfect, but it's more of an improvement than I first thought.

I'll give you a star for a partial solution (hack as it may be) and for choosing to not simply fold your arms when asked for help on code that doesn't pass validation (some people just refuse to try to help in such cases).
 
Yeah, that makes sense - I hadn't actually inspected the URLs that Joomla generates for the two instances (it's all SEF magic - the site admin doesn't actually write any of the links, and if I were to turn off SEF, they would all change).

Anyway, the point is that I'm wondering if there is some event that would fire even when the URL is the same and the page doesn't reload. I'm not an expert in Javascript event handling, but obviously something happens, because the content does its "electric slide" (lame musical reference [purpleface]). Do you know if there is a way to trap it?
 
Oops! I didn't notice that my "Actually I take back..." post "crossed in the mail" a thorough reply from you - I didn't even see it until I checked my email and noticed that I had one more notification message than I expected. Sorry!

I didn't even realize that Javascript could be put in the body of the page (rather than just the head). I just now tried it, but it doesn't work very reliably - perhaps a timing thing. I'll check into it some more (perhaps try to implement your onclick idea with a delay, although I don't like the thought of how much delay I'd need, as those video player instances are slow to load), but I thought I should get a reply to you, so you know I finally saw your post!
 
The issue exists because of shoddy html and css (I can say that now that I know you didn't build it yourself), which applies many fixes to elements that do not need it and uses overly complicated techniques to achieve simple layouts. One such thing is applying .floatbox class to #mainmiddle element -- there is no need to have it there and it does nothing ... good. It does however cause the electric slide, at least that's what Firebug points to. I managed to safely remove it without any consequences and the slide was gone.

[small]Do something about world cancer today: Comprehensive cancer control information at PACT[/small]
 
You are abso-fraggen-lutely right! (term stolen from something Captain John Sheridan says on Babylon 5) [thumbsup] I too don't see any ill-effect from removing that class reference (which sets "overflow:hidden", something I don't really understand even after reading the w3schools doc page about it [ponder]).

I had a real hard time customizing the header of this template - originally the header area was taller and the menu went all the way across on the left, and it was anything but trivial to change it to what you see now - this template looks cool, but it's a real pain! So perhaps something I did in my customizations caused the electric slide, or maybe it would have done that even with the template as it was originally - it wouldn't be the first bug I found in it...

Thanks!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top