I'm developing small web-mobile application. Some my page contains float number. But on Opera-mobile this number is displayed as link to deal phone number. I have found similar issue for Safari:
<meta name="format-detection" content="telephone=no"/>
But this doesn't works for Opera-mobile. How to to fix it?
Although likely not the best solution you can use javascript to find the <a href="tel..." blocks and remove the href attribute from there.
Related
This question already has answers here:
How to disable phone number linking in Mobile Safari?
(24 answers)
Closed 8 years ago.
I am developing a mobile website and on a page there is text such as "AD 800-1200". If I press this text and release, iPhone asked me whether to dial a number.
How to prevent this?
Thanks!
See the following html:
<html>
<div id="s2">AD 800
-1200</div>
<div id="s2">AD 800-1200</div>
<div id="s2">AD 800 - 1200</div>
<div id="phone">(800)123-4567</div>
</html>
The first and third line produce "no phone number", while the second and fourth do. You can see for yourself at http://www.floris.us/SO/phoneme.html
Note - the "magic number" in the first example is a unicode control character that does not render to the screen - but it does throw the "number parser". With this trick you can have a number that "looks" exactly like a phone number, but doesn't get recognized as such.
The third example just adds spaces around the hyphen - that seems to work too.
I can't claim all the credit for this cleverness. I did see https://stackoverflow.com/a/17507409/1967396 ...
One other thing: you can add the following line to the header of your file:
<meta name="format-detection" content="telephone=no">
This will turn off telephone number detection. This latter trick can be found at https://stackoverflow.com/a/227238/1967396 - with thanks to Aaron Brager for bringing it to my attention.
If you are using a webview uncheck the property "Phone Numbers detection" in your XIB
The majority of HTML emails and boilerplate that I've seen coded by other people, always declare a viewport meta tag.
I mindfully always avoid declaring a viewport and strive for a very high level of cross/backwards compatibility.
Declaring viewport settings render the email totally unusable for any of your audience using a Blackberry and overall is very poorly supported by any client.
Is there a reason to use this tag that I missed? Why are the majority of other peoples emails I see using this?
Additional Reference: http://www.emailonacid.com/blog/details/C13/emailology_viewport_metatag_rendered_unusable
If you want blackberry to work then by all means do not declare your viewport tag. Also don't nest tables, that will break the layout on blackberry too.
however, your other (vast majority of) mobile users will suffer. They will be able to pinch and zoom which can break your layout, I've also heard of resizing issues on high ppi screens without viewport, and I've had problems with horizontal scroll bars on my emails when I tried to go without it as well.
My current client has a huge email list. I forget the precise open stats, but versus the iphone and android's 100-140k opens each, blackberry opens accounted for 400.
of course one of their higher ups (above our contact for them) was the guy that just would not get rid of his ancient rolly ball blackberry and was pretty upset that he wasn't seeing anything. It took a while for us to convince them that dropping legacy blackberry support was the right move.
Read this I hope this will help
http://dev.tutsplus.com/articles/quick-tip-dont-forget-the-viewport-meta-tag--webdesign-5972
The viewport meta is worth using as it is also used by
http://htmlemailboilerplate.com/ using the following values
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
I wanted to see if anyone else had ever had an issue with Mobile Safari or Chrome causing web pages to suddenly spit out a ton of garbage.
The issue occurs when I visit the site & refresh multiple times. Suddenly, none of the content renders correctly, but instead looks more like the type of glyphs you'd see in Microsoft Word.
Has anyone ever seen this before and, if so, how did you resolve the problem?
I have seen it on iPhone and Android. On iPhone I suspect its due to the interruption during the page load (getting kCFURLErrorCancelled on the didFailLoadWithError method). Though I am still looking to confirm this issue and still looking for a solution ...
You should check the character set of the HTML page. Bases on your language or the special characters used in the page, you should use the apt charset. You can learn more about charsets here
http://www.w3schools.com/tags/ref_charactersets.asp
http://en.wikipedia.org/wiki/Character_encodings_in_HTML
http://en.wikipedia.org/wiki/UTF-8
It is really difficult to tell anything from what you have posted. You should check the meta tags of your page. I would suggest you validate the html source and css of the page here .
When I use <meta name="apple-mobile-web-app-capable" content="yes">, my page doesn't set, load, or retrieve cookies. Is there any way to get around this? I can't find anything useful in Google.
UIWebviews don't store cookies. Use HTML5 local storage instead.
There is a small bug in the comment on the first line of jquery.cookie.js that iPads don't like.
Change /*! to /* on line 1.
Update: Please disregard, my problem was caused by an advertisement bar being inserted by the vendor who provides my workplace wireless service.
I was building a mobile friendly website and wanted to use HTML 5. However when I specify the doctype as <!DOCTYPE HTML> , I get a gap at the top of the page on safari on the iphone.
I notice that other sites have the same problem such as nextstop.com and nike.com
I guess safari does not fully support HTML 5 yet. Anybody know of a workaround?
HTML 5 is still in a very unstable state. Don't use it in a production environment.
Edit Just so you guys know what it's about, HTML 5 is currently an Editor's Draft, and the document clearly states (in the Status of This Document section) that this specification is not stable, and that a consensus may not have been reached on any of the proposed sections. I think it should be clear enough that it means it's a bit early to start using it.
All browsers correctly interpret the HTML doctype. Putting it in sets your browser into Standards Compliant mode, that is the only difference with or without the doctype.
You can use a CSS reset tool like http://meyerweb.com/eric/tools/css/reset/ to get rid of default margins and padding on all elements.