I am trying to change the mouse cursor in a cross-browser HTML5 webapp.
By simply adding the appropriate CSS everything works fine in all browsers, including IE on Windows 7.
The same webapp in Windows 8 fails to change the cursor, although by inspecting the CSS I can see that the correct class is applied and the browser queries the server for the appropriate .cur file.
Is there any limitation on Windows 8 that I should be aware of?
EDIT
CSS example (note: this works on IE10 Win7, does not work on IE10 Win8. The example should be irrelevant given the question).
.customCursor-move {
cursor: url(/free/images/pointers/move.cur),url(free/images/pointers/move.cur),url("../images/pointers/move.cur"), default !important;
}
The CSS is in free/css.
Internet Explorer cursor css property is buggy : http://reference.sitepoint.com/css/cursor
It could also include IE10. You should try wether to use an absolute or relative path to your .cur file , depending of what you have now.
it also might be helpful :
Note also that the Windows operating system requires the image to be 32 x 32 pixels or smaller although the specifications do allow for larger sizes than this.
Related
I have the following issue:
I have this under construction state website, https://endertainment.com, it was build with PHP and MySQL from scratch, like any other I did. The issue is when you access the website from Mobile Safari or Safari the website doesn't show all the elements must show. When you access from Android (Any Browser) or Windows or even in Linux the website shows any element well. I already run test in BrowserStack and CrossBrowserTesting... in both shows the same result; the web didn't show properly. I already remove every flexbox property and use inline-block instead. For example, this other website (https://tuticketazo.com) is under construction state too and use the same structure of https://endertainment.com.
I already made tests changing the server folder the domain points; upload a simple html page from scratch, without PHP ; use without SSL... I think already test everything but in iOS Safari, Mac OS Safari and even in Chrome in MacOS shows the elements but not in the right way.
You should set line-height of your heading titles.
#MainTitles h1 { line-height: 50px }
#LangSelect a { line-height: 20px; }
But the problem is not inside these 2 rules. I didn't determinate full code of CSS, I just check small fixes for places which I saw broken
I found the problem and resolve the Issue.
OS X have a rendering issue with some fonts.
I start my research searching a common pattern, I has this issue with 3 websites:
Adjusting the line-height didn't work properly.
Change the ul from inline-block to flexbox, didn't work
The issue is present in any browser in Mac OS (I test Chrome,
Firefox and Safari)
Continue researching an I found some documentation about the issue.
I found this article
OS X type rendering - text baseline is shifted upwards, effectively no-longer centered vertically within the line-height
I test in the 3 different websites have the issue and VOILA!
Everything works fine now.
I used in the 3 websites the same fonts (the common pattern):
Gotham Book
Gotham Black
I can confirm this two fonts evoke the rendering issue in Mac Os.
The problem is solved right now.
Recently part of the app I work on was tested on Windows, and we found that dropdowns/select elements in one particular UI context rendered very differently on Chrome for Windows and Ubuntu than it did on Chrome for macOS.
I have tried inspecting the elements and the styles in Chrome dev tools on the different operating systems, but have been unable to see any difference that could account for the dropdown being as expected in one context, and completely unusable in another.
My question is what could account for this difference, and is there any way in dev tools to see what the difference is? I am new to debugging cross-platform styling issues, and am not sure where to start other than the styles tab in Chrome dev tools, and I haven't found what I am looking for there.
On macOS:
On Windows and Ubuntu:
(in the screenshot it appears as though the months are absent, but they are just white-on-white, so they can't be seen unless they are highlighted):
Selects are mostly styled by the browser / OS. So you can customize it up to a certain point (you can use -webkit-appearance: none; to disable some of the default styling, then apply what you need), but to really make it look identical throughout all platforms, you have to fake it with some regular elements like divs and lis and JS
I would like to ask, why IE11 does not displays border-radius, justify-content and align-items in my project.
When I create new .html page these tags are supported. But not in my project. Can you please help me how to solve it? Mozilla Firefox display it right and the DOM explorer gives me no error messages.
Internet Explorer 10 and 11 use a squiggly red underline to indicate invalid rules.
Obviously, these are valid rules so referencing this article by John Schneider
When I looked at the CSS styles in use on the page in IE11’s built-in F12 developer tools, I noticed that the border-radius property on my form’s enclosing div was present, but it was missing its enable/disable checkbox, and the name of the style was shown with a red squiggle underline, as though IE didn’t recognize it. It seemed almost as though IE11 was behaving like a legacy browser that didn’t recognize that newer CSS property.
In fact, that did turn out to be exactly the problem. IE11 was rendering the form (running on my local IIS) with its legacy “Compatibility View” engine, which it is by default configured to do for intranet sites. (Oddly, my IE11 was not using Compatibility View to render another copy of the form that I was trying to use to debug the issue that I had IE loading via the “localhost” domain, which had me confused for a while.)
The solution was to disable IE11’s Compatibility View for intranet sites by doing Setting (gear icon) > Compatibility View Settings > uncheck “Display intranet sites in Compatibility View” checkbox. Making that configuration change immediately got IE11 to start rendering the page properly.
Your browser may be in compatibility mode to an older browser.
Press F12 - and check which version it's using.
I noticed that in IE 11, select fields (dropdowns) have a diffent appearance (and the other form fields looks different as well). It looks flat on IE 11 while on other browsers (even lower IE browsers), it is not.
Is this an effect of Window's Metro UI which is only available on Windows 8? If it is then why am I experiencing it on Windows 7?
Is there a way to force form fields to use older ui? I've used <meta http-equiv="x-ua-compatible" content="IE=9" > but it does not work.
Please refer to this link for a live sample. Use IE 11 please.
http://jsfiddle.net/u8xtumya/
Yes, this is the way select are being styled by IE11. This might or might not be directly related to the Metro UI, but that doesn't matter.
Setting an older compatibility mode will not affect the looks of elements. It will make sure you miss out on functionality that has been added to IE11 that was not present in older versions. It's a bad idea to use anything but the latest compatibility mode if there's not a very good reason to do so (like your web app is old and doesn't run in the latest version).
You can use CSS to style the select (and the ::-ms-expand pseudo-class to style the arrow that expands the menu)
In Firefox 19.0.2, an input tag using the browsers styling agent has the following layout:
In Firefox 18.0.1, the same input has this layout:
As you can see the padding, border-width and width properties have all changed.
Considering the amount of sites utilizing a fixed position layout, is this a poor design decision? I'm assuming a large volume of sites will break when viewed in FF19.
Is this a common problem with new versions? Is there an approach to handle this issue?
Firefox is but one browser, and 19 is but one version of that browser. Compare those styles with styles of other browsers and you'll surely see differences.
There are browser reset libraries (take your pick) to rectify this very issue -- not just when a single browser changes between versions, but also for IE vs FF vs Chrome vs Safari vs...