Chrome changing inline styles - css

One of my clients presented me with a page that's not displaying properly and I can't figure out why. The URL of the page in question is http://www.honeysucklehillfarm.com/fun-farm and if you view the page in Firefox (and IE, amazingly) it works fine, but in Chrome the three sets of rotating images are much smaller and squished together. From what I can tell, Chrome is changing the inline style (set by the jQuery rorator, I assume) of the DIV "views_slideshow_cycle_teaser_section_food_on_the_farm_shows-block" to 45px x 46px instead of the 180x185 shown everywhere else.
Does anyone have any idea what could be causing this?
Thanks in advance!

In http://www.honeysucklehillfarm.com/sites/all/themes/hshf/styles/style.css?m6v7zv, line 383 you have the code: width:11.375; This width is invalid, it should be either px, em or % value.
As j08691 said, you should consider fixing the errors & warnings that come up, but without investigating for a long time, these kinds of errors might be your problem.
Why are there so many nested <div>'s though? That seems to be an excessive amount, which is screaming for errors to occur..!

Related

Safari not respecting padding

I'm currently working on a page which has a series of svgs on it, created dynamically using (the frankly amazing) d3.js.
Everything is fine, except I'm getting a weird issue in Safari (Version 9.1.1 (10601.6.17) on Mac OS X (Yosemite, repeatable on El Capitan with latest Safari 9.1)) whereby things are misaligned. I have two svgs right next to each other which for all intents and purposes have all of the same margin, padding etc. definitions, yet one of them sits properly (with 14px of padding-top), whereas the other (in theory also with 14px padding-top) seems to completely ignore this padding and sit 14px higher. As can be seen in the below images, I've used Safari's built in developer tools, and the padding does seem to be correctly defined, it's just decided not to care.
compared to:
It's worth noting that this issue repeats for as many of these svg-pairs as I have, so it's not just happening in a single instance (in both images you can see the same phenomenon recurring).
Another weird / interesting element of this is that when I zoom out (using ⌘ + ⇧ + -), the issue seems to resolve itself. This only occurs at the default zoom level.
Any help / pointers are greatly appreciated. I wouldn't describe myself as a front-end developer in any meaningful fashion, I'm really doing this due to necessity, so it's entirely possible I'm doing something very very silly.
This all works perfectly on Chrome.
After following up on olivier's suggestion, I was fixing some non-integer widths / heights which unfortunately didn't work, but while doing that I was looking at the padding and decided to try tweaking it. Long story short, apparently Safari was throwing a fit because of the svgs attempting to perfectly touch. Having padding-right as 0 on the left-hand svg and padding-left as 0 on the right svg seemed to be the issue. The fix was to set both paddings to 0.02px (seems to be the lowest I could go without it giving trouble). This leaves a very VERY subtle seam between the two svgs, but obviously this is a vast improvement on misaligning them.

Inputs sized using percentages not rendering correctly in Webkit

I've been tasked with an odd assignment.
We have a png image of a form that we're overlaying HTML form elements on top of. Since our users are on a variety of devices, I've had to design it so the form resizes to stay at 95% of browser width. Thus, all the form elements are positioned and sized using percentages (yes, I know this is ugly, but it works).
I've noticed what I'm perceiving as a bug and wondering if anybody else has encountered this: on Webkit browsers, on Mavericks only, and it's only sporadically, when the page loads, the fields appear blank. They have values (as can be demonstrated by firing a jQuery .val() command), but they're just not visible. Upon resizing the window or selecting a field, the value magically appears.
This is very confusing to me, and it's so odd that it's such an isolated variety of factors.
Anybody else able to duplicate, or has run into this, and any idea of how I can resolve this? I've actually been able to do a "hacky-fix" where, on page load, I do a resize of my main content div from 95% to 95.01%, and that redraw fixes everything, but I don't like such a hack.
We had the exact same issue and we've found that the root cause is a css transition we were using to show the page from alpha 0 to 100. So as soon as we removed that transition all the fields were shown correctly. I liked you hack BTW

opera browser displays margin differently

I'm going nuts on this, I can't figure out what causes the margins of the right sidebar gallery images to be rendered differently on opera browser. More specifically the bottom margin of the images seems to be doubled in every other common browser, its set to 2px and only opera displays it as 2 px.
This is the url - http://www.roxopolis.de/media See screenshots here.
Please help me out with this, I don't care too much about the fact that its displayed differently but it exposes a bit of the following gallery images which are supposed to remain hidden so thats what bothers me. If there is another way to hide the following images (which are placed by widget) that'd be fine too. Maybe setting the margin conditionally for opera?
I've had a quick look at the page in Dragonfly as well as Chrome's inspector for comparison and no particular style, including inherited ones, strikes me as "causing" this issue. Maybe someone else can find something, but at a glance, I'd say Opera seems to be "doing the right thing".
You might have more control over the spacing if you put each anchor tag along with its respective image inside its own container and tried to style those (e.g. a div containing the anchor containing the image for each item, and float them left within the parent container div).
Is there a particular reason you have more images than you want to display? I don't see any controls to scroll the images on that page, so I'm not sure why you need to have more than the six images you're showing already. Surely if you have code somewhere that randomises the order, you can change it so that it only displays the first six images.
Also, have you tried breaking the problem down to a smaller use case that can be tested/tweaked in a jsfiddle? That may help to get to the bottom of your issue if you can't solve it using the above suggestion.

.css problems between firefox/ie/chrome/Safari

I'm working on building a website, and everything is pretty much done, but I'm running into issues that, from what I've read here, are a result of webkit in firefox and ie.
Here is one of the pages that is having problems:
http://prdesignstudio.com/Seattle.html
When you load it in Chrome or safari it works fine, the images are reflected at the bottom, and there are no images on a lower row. When you open it in Firefox or ie, on the other hand, there are no reflections, and the last image in the set is on a lower row. Another thing that's odd is that the problem doesn't occur on every page, and it also doesn't seem to be based on the number of images in the gallery. (The different pages can be found by clicking on portfolio)
Anyone know how to fix this? Also, if fixing it requires me to remove the webkit portions of the .css, does anyone know of something else I can do to get the reflections? They're not necessary, but I like them XD
All the page's code can be found here: http://jsfiddle.net/2DvSP/
Thanks in advance for any help.
As for the images appearing on a lower row and the occurance of this on not all but some pages, you have inline styles set
div calss="container" style="width: 2080px;"
If you increase the width, this problems does not happen in FF4.01 and IE9.

Weirdest IE bug ever? -- hovering a link causes page elements to jump up and cover others

Ok, I've been dealing with IE bugs for a long time now, but this one is beyond me. IE 7 and even 8 does it for sure, I've not seen it on FF or Chrome.
So here's a live URL which produces it: http://mog.com/music/America/Holiday
Reproducing isn't easy, it can take a few times to make it happen. Watch your scrollbar to see it change size so you know the page length was suddenly dropped quite a bit.
Here's how you do it:
Hover over any sub-nav link (Main, Albums, Songs, Photos, News, etc.)
Try them until you see the scrollbar change size. Once it does, scroll all the way down and notice the footer has jumped up on top of much of the page content.
Be careful scrolling down that you don't roll over a few other page elements that will suddenly fix this. So far I can see that any of the Play buttons will somehow fix this.
It's just beyond weird. How could a rollover state cause this kind of behavior?
I've tried:
Removing the a:hover style - THIS FIXES IT... WTF? Of course we ideally would keep some hover state, so hoping to avoid this fix.
Reproducing the hover functionality using jQuery hover(). - THIS DOESN'T FIX IT.
I figure the clues are in the elements that somehow magically fix it...and possibly in where the page jumps to, what elements suddenly get obscured by the footer.
Lastly, I didn't produce this site from scratch and it uses a lot of absolute and relative positioning for certain things and I know that is partly what causes these weird bugs. I rarely, rarely use esp absolute positioning to avoid these kinds of bugs, but it's a bit too late now.
Thanks for anyone willing to check it out!!
Well, I figured it out. It was an odd case of the "Guillotine" bug. One I luckily haven't come across before. Turns out the "special" CSS rules on those nav links' hover state (particularly it seemed the border and bg image) were enough to trip this bug. One way around was to drop those styles, but not ideal. The real fix, however, was an unsemantic clearing div placed in just the right spot. More info found here:
http://www.positioniseverything.net/explorer/guillotine.html
Hi just a short note: When did you validate your html the last time?
As you probably know, but might have forgotten, fixing your html can sometimes solve a lot of problems. There are 72 errors seen by http://validator.w3.org

Resources