Is there an equivalent to -webkit-tap-highlight-color for Windows Phone 7 (Mango)? I'm writing a mobile site, and I'd like it to display the same way across all browsers, if possible.
I've tried tap-highlight-color and -ms-tap-highlight-color, neither worked.
I know this is late to answer, but I have an update.
The answer is still no, unfortunately.
However, IE10 on WP8 allows:
<meta name="msapplication-tap-highlight" content="no"/>
You can only disable the tap color, and it seems that you cannot customize the color.
Unfortunately, there is no such equivalent Microsoft propritary extension at this time for WP7. If you take a look at the Microsoft list of attributes, you will see an absence of anything even touch related.
On the JavaScript side, the IE blog just about that IE 10 will specify the pressure of a touch. This might be the closest that we can get for the time being. For now, if you really wanted to do it with JavaScript you would have to keep track of the time that the mouse was down (what a pain). The events you will need are MouseDown, MouseMove, and MouseUp.
Recommendation: If I were you I would go with progressive enhancement and not support it for WP7 at this time. If it's a critical part of your app though, you may have to play around a bit with JavaScript to see if you can get something workable.
You can disable tap highlight in IE 10 on specific element with CSS
-ms-touch-action: none;
In windows phone 8.1 the meta tag did not worked (PhoneGap App).
<meta name="msapplication-tap-highlight" content="no"/>
But this in the CSS file worked for me
body{
-ms-user-select: none
}
The (-webkit-)tap-highlight property is only supported in Safari on iOS (iPhone/iPad) and other browsers that use webkit.
If you're really desperate to display the tap highlight color you could use CSS' :focus selector which is the closest solution to your problem or try to achieve the same behavior with javascript (jQuery).
Related
The draggable attribute seems to have no effect in browsers on touch devices.
<div draggable="true">Draggable Box</div>
https://jsfiddle.net/41z5uz4t/
With a mouse, I can drag this element around. If I try to drag it around on my touch screen (Windows 10, Chrome), regular touch events, such as navigating back, seem to take precedence. I've tried holding it, then dragging. This doesn't work either.
Is there a polyfill for fixing this behavior in Chrome? Am I supposed to be doing something different?
Draggable attribute is "experimental technology" it is currently not supported on any of the major mobile browsers.
If you wnat to make an Drag'n'Drop UI you should use some JS library for that, like, greensock nice library and Touchpunch with jQuery UI and there are much more just search on the web.
I'll just make that clear the draggable attribute is not supported today by the major mobile browsers.
EDIT:
Seems that it is bug in Chrome with the touch screen devices like yours I found a solution that maybe could help you:
Go to chrome://flags and change the "Enable Touch Events" setting from "Automatic" to "Enable". The current version of Chrome apparently does not detect the touch capabilities of Windows 10.
found here.
Still, if that is an experimental attribute you better use an js library for that action.
You can use jQuery to achieve this effect. Here is a guide on how to do that:
http://touchpunch.furf.com/
Put this code before the line with the draggable object:
<script src="http://code.jquery.com/jquery-1.7.2.min.js"></script>
<script src="http://code.jquery.com/ui/1.8.21/jquery-ui.min.js"></script>
And put this after the line with the draggable object:
<script>$('#draggablebox').draggable();</script>, assuming the div has the id draggablebox.
Our application is running fine in chrome browser. But in Firefox some features and screens are not working properly. So it needs to be fixed .How can i do that and what could be the solution for that?
The best way to find out what is 'going on' is to debug the code in the browser.
Firefox has a built in debugger but i prefer to use a third party debugger called Firebug.
You should give Firebug a try as indicated in the first answer. However as far as I know you had to install it as Add-on, it is not included in the distribution.
I think your question is a little too general. Anyway, if the compatibility issue is about CSS style, you should check whether you are using WebKit-prefixed CSS only. For example, if you are using -webkit-animation, it would only work in Chrome and Safari. Actually you should set four CSS styles: -webkit-animation, -moz-animation, -o-animation and animation to make your code work in major browsers. There are some documents about Mozilla and WebKit CSS that might help:
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Mozilla_Extensions
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Webkit_Extensions
I work for a client who has masses of <a> elements on their site which use the same styling and reference the same class name.
The problem I have is the developer who worked on this project before me used CSS3 to style the element and completely ignored the fact IE7 and IE8, even though it was in the scope of the browser model and this issue is now apparent on hundreds of pages.
What I want to ask is what do you feel the best approach is to putting a suitable fix in place without effecting the markup? such as scripts which support border-radius, box-shadow, gradients etc.
Please don't come back answering about graceful degradation as this is not going to happen, I have already spoken to the client and they don't want to take that approach.
You can use a script to perform that "support" for you on clients using old IE versions!
Download script here.
This script allows CSS3 support for Internet Explorer 6, 7, and 8.
The web site link!
My favourite solution to this problem is CSS3 PIE. It's an HTC which brings
a nice selection of CSS3 features to IE 6-9.
Note: PIE uses absolutely positioned VML elements (in IE6-8) to support a variety of CSS3 features. This can cause issues like disappearing backgrounds/borders/etc. The fix is usually to use position: relative; on the affected element or it's parent. See the known-issues for more information (and other fixes).
I think there is no one solution but you can combine more than one solution, for example to border-radius you can use jquery corner:
http://jquery.malsup.com/corner/
modernizr can be a good tool too!
every one
like most of developer web developer i hate ie, buts many people still use it ,
my problem is the text on ie is really ugly , on other modern browser is clean and clear
any solution js or css to fix this without modifying the browser setup ?
thx
Text in newer versions of IE should support ClearType, however some animations in jQuery and JavaScript cause dodgy opacity issues with ClearType.
If you are talking about IE6 and Windows XP - could I suggest this:
http://www.useragentman.com/blog/2009/11/29/how-to-detect-font-smoothing-using-javascript/
This blog is about detecting whether the client is using ClearType.
Apparently, those guys at Opera have added a nice feature to their mobile version of the browser: They convert things looking like phone numbers into HTML links on webpages (e.g. USD 15.50, which clearly isn't a phone number).
The feature is described here: http://my.opera.com/operamobile/blog/2010/02/12/opera-mobile-10-beta-3-for-both-symbian-s60-and-windows-mobile
Can that be suppressed in HTML using a proprietary META tag or something like that? It really screws up our application... Do other mobile browsers also have such a feature that I should be aware of?
EDIT: Thanks for providing me with the link to the questions indicating the <meta name="format-detection" content="telephone=no"> tag. That appears to solve the problem on the iPhone, but not on Opera Mobile
A lame solution:
Use Javascript to remove any links with href="tel:...".
After some trial and error this seems to work in Opera Mobile and on Mobilizer:
The HTML text (really should be "Samsung MSC 13800 TEU")
Samsung MSC 13,800 TEU
(put a span tag around the comma with a class of "hide")
The CSS
span.hide {
display:none;
}
The comma is a fudge within "13800 TEU" and probably very annoying for assistive technology users (those with screen readers) but I follow that 80-20 principle (there would be more confused sighted users than those with a vision impairment ;-)