same code, different browser behavior

  • Author
  • #2029612


    why does angle bracket hr angle bracket behave differently on mozilla, chrome, and safari?

    this is not like it brain science… it is just an hr

    here is the link

    i dont really want to spend 3 days debugging this only to find out that this is a WP bug. If it is, please let us all know, and maybe fix it. if it is not, please tell me how to fix my code. we are talking 3 characters here.

    if you are a member guru person, you know you dont need me to look at the code. ta.

    The blog I need help with is



    I don’t know what’s going on with your specific issue, it might help if you explained what you see in each browser (and version) and what you are expecting to see though.

    There are lots of differences in the ways that different browsers render content, it’s something you’ll have to get used to if you work with HTML and CSS!



    actually what might be more useful is if the WP interpreter provided a consistent programming interface that worked exactly the same with all browsers. most of us here who are serious about css but may not have the luxury of being able to hire a full time programming staff would no doubt most appreciate that. many others like me simply do not have the time to provide the type of documentation you ask for, or to figure out what is the standard and what is what WP deciding to allow, even though looking at the app through 3 or 4 diff browsers would instantaneously give you a clue as to the browser behavior I am talking about with respect to the hr behavior in my app. but given your user base, i can understand the usual formulaic, opaqueness. the one thing i would suggest to WP is not to consistently state what is immediately obvious. that said, cheers ;-)



    The point I was trying to make is that there is no such thing as:

    exactly the same with all browsers.

    Have a look at these compatibility tables to see a fraction of what web designers have to cope with then it comes to getting consistent design across different browsers, OSes and devices.

    For older (and more problematic) browsers lots of designers know that getting a pixel perfect design is not possible and attempt to show the nicest possible version of the design based on the peculiarities of that particular set up. If this means some of the flashy bits (columns, drop-shadows, rounded corners) are not available then so be it – the content will be there, just ever so slightly less pretty!

    In case you haven’t seen it before, here’s a list of the allowed HTML elements.

    I don’t mean to sound grumpy but most of the responses on the forum are from volunteers (unless it says staff under the username to the left of the post) and it really helps us when people explain the expected behaviour and provide detailed explanations (we love screenshots too) of the problems that get encountered.

    I’m an Opera and Firefox user and so I don’t test in Chrome/IE/Safari, there might be others out there who do but if you want to make it easier for us to help you then a quick description would go a long way!

    I hope that goes some way to explaining things a bit better – sorry it doesn’t help solve your problem!



    hi yes I am familiar with the notorious “allowed elements” — not allowing input or button tags is a total app killer, necessitating circa 1993 style HTML coding ! I will take a look at the Compatibility tables to try to understand (a) who put them together and (b) how useful they might be in solving this problem

    That said, I put together a page that outlines very clearly the problems with the Nav widget in Firefox. These are
    1) the first pic box element (nCanvas)floats to the right
    2) the HR lines double up, with the second one being in the wrong place

    I very much appreciate the volunteers looking into this.
    any help would most welcome in terms of making this extremely simple code run on FIrefox as it does on Chrome/Safari — many thanks! (also would appreciate knowing if this runs okay on Opera, as I had trouble setting it up on my comp)

    here is the link to the page I put together for the purpose of WP volunteers or staff looking at this widget. Beyond this, I am not sure what other documentation I can provide.



    incidentally the forward slash in hr is a Safari hack
    without it Safari doubles the hr lines too!

    so what I cannot determine is if the WP preprocessor is causing this behavior as my code looks very very straightforward and in fact extremely repetitive due to the lack of js and db capabilities (in which case I would need 1 statement to retrieve pics as needed by iterating through some buffer)

    in a real web env I would of course never code the Navigator in this primitively inelegant way



    I think I’ve mentioned it before but is not for creating apps, if you want this sort of flexibility you should consider buying yourself a hosting package and using, just beware of the extra costs and responsibilities that come with it!

    Both your issues seem to be caused by your floated elements. If you float things on your page you need to make sure you clear these floats for elements underneath, this code should fix the issues you were having:

    .nCanvas_display_area, .Navigator hr {clear:left;}



    it seems to work like a charm. awesomeness! i shall study the “clear” command to see how and why this fixed the problem. this may be a dumb remark, but it looks like css is acting here a bit like a procedural language rather than a sort of semi declarative scripting one

    that aside, i think actually i would like to have turn the Navigator into a generalized widget (coded with js) that other small biz retail owners could easily plugin or uttilize in their web sites via iframes etc

    i am actually trying to determine what would be the best platform solution to host such an app (would not necessarily need wp,org at all, as this would be an independent app offering navigational functionality, and not some sort sort of free wp widget from which i would derive no commercial benefit while still having to worry about, say, css cross scripting headaches etc). i agree that wp seems suited for relatively hands off (in terms of programming) blogging, primarily, and not for any kind of sophisticated coding that would be of interest to a front end designer in support of a commercial application. for example, I can think of many cool mouse driven uses for the HTML canvas element in retailing, but of course cannot try out any of those ideas here. moreover, image management start to become a real issue with a backend db. still is useful as a rapid prototyping env, up to a point, as I do get user feedback from my customer base.

    but all that is off topic so I understand if you would have no comment in this regard. many many thanks again for your help in the matter.

    it is much appreciated.



    correction: img management without a backend db becomes an issue, primarily one of scaling (obviously)

The topic ‘same code, different browser behavior’ is closed to new replies.