I've used pixels to determine the size of my fonts on a website. All the text resizes fine in Chrome, Firefox etc, using the zoom feature. However in IE7 (and IE6/8, I guess) the fonts don't resize using the Text Size menu, they just stay the same.
Now I'm thinking the only solution to this is switching to ems - but is there any solution I could write in JS to target / fix only IE?
Unless you know otherwise, assume that hardly anyone has IE7 or 6 anyway. IE8 has a zoom feature, so that's OK. On approximately 50 small business sites I have data for, in the last month 0.5% of visitors were using IE6, 4% had IE7 and 12% had IE8.
We don't support IE6 or 7, but we do test and check things look basically right there.
Assuming that you do want to allow this minor feature (assumedly people who need accessibility the most will not be using these notoriously inaccessible browsers!) in IE6 and 7, you do need to use ems rather than px, and you'll really need to use it for everything, not just font-size, as otherwise the boxes won't scale properly either.
in internet explorer 6 & 7 you cannot increase or decrease font-size that is set in pixel in your css.
For that to work you have to use EM's as font-size value.
Read this article
Related
For my page, I run a calculation in JS that uses values that are measured in CSS pixels. This calculation happens every time the viewer zooms the page. If you'd like to know what the calculation is for, it's used for scaling a div to a desired size depending on the zoom.
This is working perfectly in Firefox across all zoom levels, but I get a certain problem when I test it in Chrome and other browsers. It works fine until you try testing zoom levels below 100% (zoomed-out views). When you're in a zoomed-out view the calculation becomes incorrect (it's bigger than it should be). I think it might be because CSS pixels become smaller than device pixels when you reach zoomed-out views (right?), and because my calculation is in CSS pixel units it no longer is accurate. But if that's the case, then why are my zoomed-out views in Firefox working? In an effort to try to fix the problem on non-Firefox browsers, I converted the calculation to operate in device pixels when in zoomed-out views and that fixed the problem (in Chrome and other browsers), but then when I went back to Firefox to make sure its zoomed-out views still worked, the calculation was no longer correct (it was smaller than it should be).
From my findings, it seems that...
Firefox expects you to only use CSS pixels (even in zoomed-out views)
Chrome and other browsers expect you to convert between CSS and device pixels depending on the zoom (CSS pixels when zoomed in, device pixels when zoomed out)
So what's the deal here? How does one create a solution that works for both without browser sniffing?
Also, is it normal to convert between CSS and device pixels depending on the zoom? Or should I just be doing it the Firefox way and only deal with CSS pixels? I don't know which way is considered the normal way, but it seems that most browsers make you convert.
Has anyone had issues with the viewport tag since the iOS7 update? I have a few sites that now have this white margin on the right side. I adjusted the initial scale to 0.1 and it fit the iPhone just fine but on an iPad 3 it was tiny, which makes sense given the low scale.
I didn't have this issue until the update and I can't find any documentation out there regarding any changes to how safari handles the viewport meta tag.
Seems like iOS 7 is a bit buggy using meta description.
I sometimes need to reload me website to be displayed all right.
Maybe Apple will fix that with iOS 7.1. There are a few other bugs as well.
Do you have multiple viewport tags? If so, combine them into a single tag, per this other answer.
I was working on a project transitioning the left CSS property of an element, which was defined as a percentage (e.g. 100% to 0%). I was developing in Chrome which was giving me style values for left as a percentage, this was working the way I wanted, until I tried it in another browser (any other browser actually). I set up this simple fiddle to demonstrate. Generally, most values are converted to pixels before being reported, but not chrome.
The second part of this question would be; Is there a way to get the other browsers to report the style property as it was originally set? (e.g. px, %, em, in, etc.) without an ugly conversion? and if not is there some other reasonable workaround? Thanks.
This is apparently a bug in chrome. Otherwise, All of the other styles and browsers, with the exception of IE, should convert everything to pixels. IE leaves everything in it's own units but also uses a propritary method in browsers older than IE9. Here's a page I found that talks about that and shows how to convert IE to px.
The following code works in all desktop browsers Chrome and Safari on the Desktop as well as recent iPhones and all Android devices I've tested. However, in first-generation iPhones and the iPhone 3G, the top left corner of the <img> is not rounded.
The other CSS I have for rounding corners (on <h1> elements) on the iPhone seems to work fine on these older devices. It's just the rounding for the <img> element that does not work.
Relevant Javascript:
var profilePhoto = document.createElement("img");
profilePhoto.setAttribute("src","http://example.com/photo.jpg");
profilePhoto.setAttribute("alt","");
profilePhoto.setAttribute("class","menu-first");
profilePhoto.setAttribute("style","float:left; border:0; padding:0!important; margin-top:0!important; -webkit-border-top-right-radius:0; -webkit-border-top-left-radius:.5em;");
document.getElementById('menu-container').appendChild(profilePhoto);
Relevant HTML:
<div id="menu-container"></div>
I am aware of the "rounded corners don't show up if the radius is greater than half the image height or width" issue, and that's not what is going on here. The radius is a tiny fraction of the image size.
JSFiddle: http://jsfiddle.net/RaK3T/
(Wow, JSFiddle actually works on iPhone 3G, that's awesome!)
UPDATE: I suppose it very well might be the iOS version that matters more than the phone model. It appears to work fine in iOS v4.3.2, but not in iOS v3.
It sounds like you're running into an issues in certain older browsers, whereby the border is drawn as a logical layer beneath the foreground image.
The effect is that the rounded borders are indeed drawn, but the foreground image is then placed on top of them, and is not clipped. This obviously only affects the <img> tag, since it's the only tag that has foreground images.
This issue was a big deal a few years ago. It afflicted some browsers but not others, but certainly for older versions of Firefox and most Webkit browsers, it was an issue.
The problem was quickly spotted and was fixed (somewhat quicker with Webkit than Firefox, if memory serves), and we all moved on.
But it is still an issue for web developers needing to support older versions of these browsers.
There are three workable solutions:
Use a background-image style instead of a foreground <img>.
Ignore the problem and let older browsers live with square corners (oh the horror!).
Use any one of the old-school rounded corner hacks that draw the corners in manually.
Personally my preference is for option 2, I appreciate it doesn't actually answer the question, but I don't have an issue with it: it's a cosmetic detail on old browsers; you wouldn't try to get this working on IE6, would you? (would you??).
If that isn't good enough for you then option 1 is the typical solution that most people went with at the time. But isn't good semantically, and has issues if you need to scale the image, etc.
And the less said about option 3, the better.
Oftentimes in the web development community, you hear people complaining about developing for IE6. However, if you are developing using a robust JavaScript framework like jQuery, is developing for IE6 any different than developing for IE7?
It can display alpha-channel PNGs correctly.
The calculations for box dimensions are not that far away from the standards.
Rendering and JavaScript performance actually allow you to do something fancy without freezing the users machine every now and then.
Some security issues have been addressed.
In relation to the other browsers, it shows no improvement at all because the others have made much bigger progress in the same time. It's still the worst of the major browsers and a pain in the b*tt for developers.
IE7 supports png transparency, which is a massive help in maintaining graphic resources for the site.
I'll add a few points which haven't been listed:
CSS width strictly adhered to: IE7 in standards compliance now mode strictly interprets width styles in CSS. In IE6, if you have a child element that has a width which is greater than the parent element, it would often ignore the width declaration of the parent and expand to fit the child, often requiring hacks of overflow: hidden to make sure the parent didn't expand.
This is mostly a good thing, but unfortunately introduces a number of other quirks, e.g. <table style="width: 100%"> in a scrolled DIV with CSS overflow set to overflow: auto or scroll will expand the table to the width of the scrolled DIV including the width of the vertical scrollbar so some of the table will be cut off by the scroll bar on the right.
Cleartype with DirectX filters disabled: IE7 disables cleartype (font smoothing on LCD monitors) for elements which have DirectX filters such as alpha transparency and gradients. This is good in some ways, as cleartype made elements with filters, especially bolded ones very blurry/fuzzy, but it's bad because it now renders the text blocky and aliased on LCDs.
IE7 I think also now supports alpha: 1.0 as well as filter: alpha(opacity=100)
SELECT z-index bug fixed: IE7 fixed a bug where the SELECT elements have infinite z-index and are always above other elements unless you put an IFRAME in between of the SELECT and the element you want to display above it. This is a problem for menus etc.
CSS pseudo-classes improvements: :hover and some other similar CSS states are now supported outside of hyperlinks.
Performance not necessarily improved: IE7 introduced many bugs in it's VML engine, and in IE8 VML is now 10x slower than in IE7 when in standards compliance mode, so it's not altogether good. In addition, I have test cases which show that finding offsetLeft and offsetTop in mouse events in standards compliance mode in IE7 can also be around 10x slower in my web app.
IE in quirks mode though it's about the same performance for VML and offsetLeft/Top throughout IE6, 7+8. My experience in IE7 standards compliance mode is it's actually much slower than standards compliance mode in IE6, though it is definitely much more compliant.
I think it's a bit of a double-edged sword though, as raw JavaScript performance did improve, so things like working with array methods and for loops did improve even though I think the rendering engine and many of the associated DOM methods became much slower in standards compliance mode in IE7+.
IMO, there is a world of difference between IE6 and IE7.
IE7 supports built-in XMLHTTP whereas in IE6 it requires an ActiveX control.
IE7 supports a couple of additional pseudo classes
IE7 fixed some of the problems with z-order and zoom.
IE7 fixed "a few" of the box model issues.
IE7 added support for > child selector
IE7 added support for adjacent (+) selectors
PNG transparency support
I think most of the improvements to IE7 was performance(javascript) based and trying to get closer to standards compliance for CSS.
Off the top of my head, these were some of the major improvements as I recall:
Fixed the double margins bug
Fixed numerous issues with the box model and positioning inheritance
Inclusion of Developer Toolbar into browser(not a bug fix, but big one for me)
As noted by others, proper PNG handling
It was a much better browser when comparing it to IE6, when you compare it to other browsers out today, not so much.
Hardly; in terms of IE7's gain in standards compliance, it's negligible. All of the versions of Internet Explorer up until today, including IE8, have horrible breaks in JavaScript, CSS and DOM implementation. Most of the hacks you use for IE6 still apply for later versions. However, on the bright side, IE9 is shaping up to be quite good, and big progress has been made (I've never thought I'd actually say that).
The gaps and differences in implementation between the spec, and other browsers like Firefox and Chrome are much smaller.
I'd recommend Mark Wilton-Jones's article on IE's numerous flaws for more info.
Javascript & CSS frameworks minimise the amount of damaged caused by IE6, but there is still a number of bugs & inconsistencies between IE6 and other browsers.
IE7 is better than IE6, but only just.
Personally, the most annoying thing about IE6 is its lack of PNG transparency. This results in requiring use of AlphaImageLoader for images. The implications of this is introduces its own bugs/inabilities. For instance transparent backgrounds using AlphaImageLoader can't repeat.
Also, there are bugs such as the double margin bug, lack of support for min-height and min-width, adding extra line breaks to floated elements, missing css selectors.