I've recently been exploring on a site in my free time, and ran across a peculiar circumstance. When viewing an image (direct link) from imageshack, it displays in two (or more) completely different, and sometimes blurry, dimensions.
For instance -- where an image might be small in Chrome or Vivaldi, appears in full scale in Safari or Firefox. Given the differences in the background, as I believe the former two are webkit based, where as the other two use their own engine, I'm not sure if this has something to do with it, as I couldn't detect any outright styling that would force such a difference.
The links are identical when viewed between browsers, on the same machine. Same results occur when attempting on another machine. Any idea as to what might cause this, and how to remedy it for a consistent experience?
Below is a single image link for an example -- one of many instances.
Image
My thanks ahead of time for the input and any feedback or assistance!
Related
I am having an issue with a specific mac that is not displaying a certain website I have built correctly. Every other mac and pc I have tested displays the website correctly but this one specific mac in all browsers on it is displaying incorrectly the issue I am getting is inline block elements are not next to each other, I have all the 'hacks' in place and like mentioned this displays correctly on every other computer.
This question here is the exact same issue but it doesnt seem to have been resolved.
https://discussions.apple.com/thread/6650689?start=0&tstart=0
I know I could try floats but I would rather find the route of this cause, does anyone know of any reason this might be happening?
If browser renderings vary only on a single or a few machines, fonts are a possible culprit. Make sure all computers use the same fonts to render your page, actually even that the same version of the font is used.
A lot of fonts get slightly modified over time, often the kerning (space between two characters) or the hinting (how the curves that describe fonts should be mapped to pixels on the screen) might change, resulting in very minor differences in the width some text consumes when being displayed.
If indeed the font version is the culprit: Remember that visitors of your page might also have this "bad" version of the font. So it is advisable to try to improve your HTML layout.
I've often observed that leaving a few percentages empty helps to deal with such font issues. For example: having a div (width=100%) that contains two elements in each "row", the first one a label of about 1/3rd the width, and the second one being some control, taking up the rest of the space. Having them defined with width:33% and width:67% often results in the case that the second part is laid out below the first part instead next to each other. Changing the widths to something like width:32% and width:65% often fixes this, as it allows for some rounding errors in the browsers when laying out the elements.
I am a self-taught web designer with a staggering 3 sites or so under my belt. I just finished the first page of a website for a client who is a friend and therefore a lot more patient than a "real" client would be.
I love the way the sites looks, it is fairly consistent in the spectrum of popular browsers, and overall I was quite proud of it until I realize a major problem that to be honest is about two steps away from making me drop my dream of becoming a web designer.
When using Chrome, Safari, or older versions of Explorer the website's layout falls apart if someone has their zoom set to anything other than 100%.
It is frustrating me to the point of near depression. I used a div to surround the whole body, and the pages layout, which in this case is a MENU is done almost entirely with ULs (unordered lists) positioned absolutely.
The site is made up in such a way that all the parts connect (almost like a puzzle) and if some parts are out of line, it is dreadfully obvious.
I heard the zooming rounds up figures and could call for a couple of low alpha pixels here and there, but in my case some block elements are literally 25-50 pixels out of place.
http://www.stevemarcella.com
No need to get your dreams crushed just yet :> There is always hope.
First thing you should do is check all of the errors, which according to validator are 536 errors on the homepage.
I suggest you run the validator and correct errors one by one. It could solve your problems. First error I noticed is that you have a div element outside of body. You should keep everything inside the body tags.
This is outside of body.
<div class="wrapAroundBody" id="IdWrappingWholeBody">
Hope it helps.
So I'm building a website for a client on the Wordpress platform and he says that when he views it on an old square monitor, the layout is all messed up. I know most monitors nowadays are more widescreen and you'd be pressed to find a smaller, square monitor, but he wants it to look good on every monitor, which I completely understand.
I'm just having a hard time trying to fix it because I'm building it on a widescreen laptop and widescreen monitor so I can't really tell if it's fixed when I make changes.
So my question is, how can I view the changes I've made as a square monitor? I've tried resizing the browser window, but it doesn't make any changes. It's not looking like anything he describes. Also, I know this is a longshot, but are there any WP plugins or anything that will fix it?
P.S. I've been making changes to the style.css file with the #media property. Thanks!
Back in the day, websites were always developed to accommodate the "square" monitor resolution. Today, the number of users using 800x600 or 640x480 is negligible which is why most sites leverage the space benefits introduced by the wider ratio. And, without getting into the possibility of an antiquated browser to go with his antiquated hardware and why one wouldn't want to pander to either of those over the mass as a whole, I'll stick to the question at hand.
Without seeing the website, I can't say for sure what's going on but I'm willing to guess that one of two things is happening:
The way in which the content is organized is causing one area to push into another
He has to use the horizontal scroll his on browser to see the whole site.
The solution for overcoming both of those problems is a whole other issue but, to get you both looking at the same page, set your monitor's resolution equal to his to simulate his view. On both my desktop and laptop, I can set it to 800x600 so I'm willing to be you can too.
Setup:
I have a simple box with rounded corners, that has a header and expands according to the amount of text, as discussed in Dan Cederholm's Bullet Proof Web Design (ISBN 0-321-34693-9).
Works great, EXCEPT when zooming in Google Chrome. Then the right margin of the box disappears.
It works in IE and FireFox without problems.
Example:
Example in jsFiddle
In chrome, it fails at zoom 110% and other zooms too. No problems in IE or FireFox.
Questions:
Any ideas what is causing this?
In general, what makes layouts zoom-sensitive (if any such general rule exists...)?
Is Dan Cederholm's book really bullet proof...?
How far back do you need to be compatible?
I mean, if you can drop IE7/8 you should be using css3 rounded corners. If you need to support IE8/7 you should definitely considder using graceful degradation in this case. It is probably not worth the time and effort to strive for perfection everywhere. That is simply a goal which cannot be met when browsers will never get updated again.
1) What may be causing this
That is a fairly broad question, I couldn't reproduce the problem, or really find one in Chrome 20 (beta) so I will just list a things that can mess it up.
General browser rounding errors, browsers aren't precise, weren't designed to be precise sub-pixel
Mixing px values with other values, different roudings make values add up differently..
Positioning of in-flow elements which get influenced by other in-flow elements on the page (these are hard to track down usually)
Parent element properties (parents with overflow hidden, fixed sizes, for example, I think this might be the problem here in the jsfiddle)
Bugs in browsers
Combination of the above
In this case jsfiddle has a crapload of containers and frames (with overflows set to hidden, fixed heights/widths, px based) etc on the page, even in 'full screen' view. So if you really want to make sure, make a html file on your own pc open/test with that.
2) In general, what makes layouts zoom-sensitive (if any such general rule exists...)?
In todays browsers this may not be all that relevant because zoom functionality is often very advanced and can even scale full-px based layouts without much problems. The only real problem browser which is still used today is IE7. The zoom capability of IE7 is atrocious, and for that reason you should only use % or em based values for text.
The only 'official' related guidelines can be found in WCAG 2.0, the w3 accessibility guidelines/techniques writeup:
http://www.w3.org/TR/WCAG20-TECHS/G142.html
So browsers can scale, modern ones have no problem here, but weren't designed to be accurate, it's also an impossible task with mixed units (em, %, px).
3) Is Dan Cederholm's book really bullet proof...?
Before I start here, I haven't read the book... I never read a CSS book (plenty other resources) in my life, but my first and foremost skill is dreaming it.
Let's start with "What is bulletproof?". Bulletproof in web-design means it will work, everywhere, and will not break, anywhere. This alone should give you a clue.
It might have very well been bulletproof when he wrote that book, but the web is a dynamic place, and even if I take the latest announcement blogpost for the book it dates from December last year. Since then at least 3 new Chrome versions came out (rough estimation) and even more Firefox versions. Microsoft sat on his ass that this time (we would've been in big trouble if they decided to do rapid release schedules).
Things changed, new bugs have definitely been introduced since then.
Regardless of what is breaking it, nothing is ever bullet proof, just very, very close to what you want to always happen, with slight variations between browsers.
That doesn't mean it is a terrible book, looking at his CV he's definitely and a guru on web-design, so he's probably right about a lot of things in that field. I just hope he explains why things are done in a certain way, because that makes you a lot wiser than just learning to do things.
A: "You always use EMs for text! EMs are annoying! Why do you do that anyway?!"
B: "I dunno, read somewhere I should..."
A: "Lets just use pixels! Pixels always work."
B: "Hmmm ok."
You just lost IE7 support. (whether that's a bad thing, is another discussion)
First of all, you're using a background-image, something I would have loved you to have mentioned.
1) So yah, as mentioned in the comments below your post, it's just rounding errors of the div, which crops the background-image.
2) I have no sources sadly, but in my experience, objects using text as a measurement are zoom-sensitive, pictures sometimes not zooming relative to everything else, and content with a predetermined 'set' size (such as textareas, radios buttons, etc).
3) Nothing is bullet proof, especially with something as ever-changing as the web that also behaves differently on different browsers. Hazards of the trade.
Really not sure why this is occuring but with some systems the backround image gradient appears choppy and only half of it even appears, also some systems display the color so light is can barely even be seen especially those with lower resolution settings. Any ideas why this is occuring?
Here is the link to the page: http://www.kapacitive.com/Main_Page_Template.html I have it here just for testing purposes.
I also noticed that if I change the CSS positioning of the background to background-position:50% 50%; the issue of only having half the backround appear occurs on my main system.
I have a small touch screen Garmin device that has a web browser and with that device the background appears both choppy and only half appears, though I really didn't expect much from that device in the first place.
My secondary machine has a lower resolution display and with that system the background can barely be seen. This also occurs using an entirely different machine and display which has a lower resolution setting.
Maybe, I should just trash the background all together with all these damn bugs occuring, though in my opinion it does look better with the background.
If anyone wants to volunteer test the page using other devices and provide the results that would also be cool, I currently do not own any Apple devices.
Like I've stated any suggestions or ideas on resolving this issue would be great and even any insight about why this is occuring. I realize each machine is different but the differences in how this page is rendering between different machines is way too drastic in my opinion to be acceptable for deployment.
I believe the problem is with the color-depth of the machines viewing the background image. That nicely faded gradient relies on a LOT of colors, and on a screen with a limited palette, it's going to be choppy.
A work around would be to test the pixelDepth/colorDepth of visitors' screens, and to dynamically change the background image to something plainer if it is too low. Most browsers provide that information [via JavaScript] in the screen variable.
window.screen.colorDepth
window.screen.pixelDepth