By default on iOS Safari input text or textarea enables automatic correction and capitalization to streamline mobile typing. However, sometimes, we don't want this, for instance username input text.
We can add autocapitalize="off" autocorrect="off" two attributes to disable this.
When I tested on iOS6.1.4, input email, input passsword don't auto capitalize the first character. Also show correct keyboard.
We can use HTML5 new input types to better control keyboard display
Text: <input type="text" /> <!-- display a standard keyboard -->
Telephone: <input type="tel" /> <!-- display a telephone keypad -->
URL: <input type="url" /> <!-- display a URL keyboard -->
Email: <input type="email" /> <!-- display an email keyboard -->
Zip Code: <input type="text" pattern="[0-9]*" /> <!-- display a numeric keyboard -->
For details, check out https://developer.apple.com/library/safari/#codinghowtos/Mobile/UserExperience/_index.html
Friday, June 21, 2013
Wednesday, June 19, 2013
Build your first Mobile App with HTML5, jQuery, PhoneGap & APIs
Here are the key takeaways from this 1-day free event sponsored by apigee.com.
jQuery Mobile
Check out http://jquerymobile.com/ for details. It is evolving fast, and it is 1.3.x version now. jQuery Mobile is not jQuery mobile version, it is more like jQuery UI mobile version (but not exactly). When we use jQuery Mobile, we usually needs jQuery and jQuery mobile CSS to get things work.
Other mobile web framework and libraries?
http://www.markus-falk.com/mobile-frameworks-comparison-chart/
Mobile Prototyping Tool
http://www.codiqa.com (Recommended in jQuery Mobile website, and apigee team uses it too)
http://www.mobjectify.com/
http://tiggzi.com/home
PhoneGap/Cordova
Port HTML5/CSS3/Javascript based Web app to Native app. It is more like a bridge.
http://phonegap.com/
http://docs.phonegap.com/en/2.5.0/index.html
https://build.phonegap.com/ - Adobe Cloud build service
PhoneGap Alternatives
https://trigger.io/
http://www.appcelerator.com/
http://www.sencha.com/
More about HTML5
http://diveintohtml5.info
http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html
Topics we covered in this event
Prototyping using codiqa
jQuery Mobile
jQuery
PhoneGap
Android developer tool (ADT)
Xcode and simulators
REST APIs (http://zh.wikipedia.org/zh/REST)
apigee API service
Geolocation
Security (sandbox)
Topics we didn't cover in this event
Push notifications
File Storage
Social Graph
Local capabilities
3rd party integration
Legacy integration
code execution
Bonus
Python built-in HTTP server
You can quickly launch a webserver to test mobile web if you have Python installed
python -m SimpleHTTPServer 8080
Companies mentioned in this event
http://www.crunchbase.com/company/socialtagg
http://www.crunchbase.com/company/zoosk
http://www.crunchbase.com/company/eventbrite
http://www.crunchbase.com/company/bitly-2
Here are my thoughts
Why Mobile Web?
- Write once run every device?
- One stack fits all?
- Better upgrade options (fast release cycles)?
Why not Mobile Web?
- Performance?
- HTML5 API limitation?
- Native User Experience?
- Offline limitation?
Native or Web or Hybrid app?
- It depends
jQuery Mobile
Check out http://jquerymobile.com/ for details. It is evolving fast, and it is 1.3.x version now. jQuery Mobile is not jQuery mobile version, it is more like jQuery UI mobile version (but not exactly). When we use jQuery Mobile, we usually needs jQuery and jQuery mobile CSS to get things work.
Other mobile web framework and libraries?
http://www.markus-falk.com/mobile-frameworks-comparison-chart/
Mobile Prototyping Tool
http://www.codiqa.com (Recommended in jQuery Mobile website, and apigee team uses it too)
http://www.mobjectify.com/
http://tiggzi.com/home
PhoneGap/Cordova
Port HTML5/CSS3/Javascript based Web app to Native app. It is more like a bridge.
http://phonegap.com/
http://docs.phonegap.com/en/2.5.0/index.html
https://build.phonegap.com/ - Adobe Cloud build service
PhoneGap Alternatives
https://trigger.io/
http://www.appcelerator.com/
http://www.sencha.com/
More about HTML5
http://diveintohtml5.info
http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html
Topics we covered in this event
Prototyping using codiqa
jQuery Mobile
jQuery
PhoneGap
Android developer tool (ADT)
Xcode and simulators
REST APIs (http://zh.wikipedia.org/zh/REST)
apigee API service
Geolocation
Security (sandbox)
Topics we didn't cover in this event
Push notifications
File Storage
Social Graph
Local capabilities
3rd party integration
Legacy integration
code execution
Bonus
Python built-in HTTP server
You can quickly launch a webserver to test mobile web if you have Python installed
python -m SimpleHTTPServer 8080
Companies mentioned in this event
http://www.crunchbase.com/company/socialtagg
http://www.crunchbase.com/company/zoosk
http://www.crunchbase.com/company/eventbrite
http://www.crunchbase.com/company/bitly-2
Here are my thoughts
Why Mobile Web?
- Write once run every device?
- One stack fits all?
- Better upgrade options (fast release cycles)?
Why not Mobile Web?
- Performance?
- HTML5 API limitation?
- Native User Experience?
- Offline limitation?
Native or Web or Hybrid app?
- It depends
Sunday, June 16, 2013
More about HTML Email Template
Today I came across these 2 great articles regarding HTML email templates, and they are must to read resources if you are new to HTML email template writing. Last year I did some email template composing, and lots of gotchas and questions are addressed in these two links.
http://hub.tutsplus.com/tutorials/what-you-should-know-about-html-email--webdesign-12908
http://webdesign.tutsplus.com/tutorials/htmlcss-tutorials/build-an-html-email-template-from-scratch
Here are key points I copied and pasted here for future reference :
Part 1: General introduction
If you are already familiar with web development, forget everything you know about it.
The worst thing you can do is get angry that you can’t use DIVs or that margin isn’t fully supported. So forget everything you know about semantic HTML and the latest CSS spec.
The best way to test is using Litmus or Email on Acid. I recommend taking out an unlimited plan with either of these companies because being able to test frequently is really important.
The two services that I use the most are MailChimp and Campaign Monitor.
Image-reliant emails with no text are more likely to be marked as SPAM and so are emails with really long image filenames.
Run a SPAM test through your testing account with Litmus or Email on Acid before you send your email, to make sure all your hard work isn’t headed straight for the Junk folder.
Frameworks like the HTML Email Boilerplate are full of wonderful tricks and snippets that you can implement piece by piece. However, if you are just starting out I don’t recommend using it as a starting point as it contains a lot of elements that you won’t need. Boilerplates can often make it more difficult to troubleshoot any issues if there is a lot of unused code in your file.
Using an XHTML doctype generally has the fewest quirks and inconsistencies between documents. I use XHTML 1.0 Transitional because it has proven itself to be the most reliable doctype in my experience.
The viewport meta tag is telling the device to set the viewable area to the width of the device’s screen. It also sets the initial scale to ‘normal’ which is neither zoomed in nor out.
Email is All About Nesting Tables, you need to use lots and lots of nested tables because neither the colspan nor rowspan attributes are properly supported.
Again, because of the lack of standards support, it’s not a great idea to use standard tags like h1, h2, h3 or p. Your best bet is to place every block of text into its own cell and apply inline styling to that cell
You can’t apply multiple classes to things in HTML email because it is not supported. Every element can have a maximum of one class.
You can’t use shorthand for things like font size (i.e. style="font: 8px/14px Arial, sans-serif;") because it is not supported.
It’s good to give your images names that are short and meaningful because it will improve your spam score.
It’s also a really great idea to try to keep your entire email as small as humanly possible: under 100kb is ideal but not always possible, under 250kb is pretty standard.
For your main container elements always set the size in pixels. You can then use percentages inside your containing element if you wish.
Responsive Email templates
http://zurb.com/article/1119/create-emails-for-any-device-introducing-
Part 2: Build Template from Scratch
If an attribute exists in HTML, use that instead of CSS
Always remember to use the full six characters of a hex code, as three character shorthand won’t always work.
When using padding in email, you must always specify every single value (top, right, bottom and left) otherwise you can get unpredictable results. Note that it’s safe to use padding on TD tags but not on P tags or DIVs.
We’ll insert our image, adding alt text and adding style="display:block;" which is a common fix that stops some email clients adding gaps underneath your images.
If the contents of your header are really important to your message, don’t use an image-only header. Remember, images are blocked by default for most clients, so if there is an aspect of your email that is crucial, never include it as an image.
If you always have pixel widths on everything, you can end up with a lot of values to override with media queries. If your nested table widths are based on percentages, then when you adjust the width of the parent element, everything will adapt accordingly.
Because we want a ‘margin’ in between these two cells, but margin isn’t supported, we’ll create a three-column table with an empty cell between the two outer columns.
Be sure to zero your font-size and line-height and add a a non-breaking space character in the margin cell.
We’ll also set the valign to "top" for both cells so that they will vertically align to the top, even if one column has more text than the other. The default vertical alignment is "middle".
As we need multiple rows, we’ll nest yet another table because we can’t use any colspan or rowspan tags.
Let’s run this through the W3C Validator to make sure nothing is bad or broken.
Next we’re going to run a test through Litmus to make sure the structure of our email works great.
Time to turn off the borders and see it looking beautiful. Go through and replace every occurrence of border="1" with border="0".
As a final touch, I’m going to add 30px of padding to the bottom of the very first cell, to prevent our email from stopping abruptly at the bottom in some webmail clients (like Apple Mail), and 10px of padding at the top, so that our blue header has a little bit of breathing room.
If you have used any comments, get rid of them. Some email clients can choke on comments so it’s wisest not to have any unnecessary code anywhere in your files.
http://hub.tutsplus.com/tutorials/what-you-should-know-about-html-email--webdesign-12908
http://webdesign.tutsplus.com/tutorials/htmlcss-tutorials/build-an-html-email-template-from-scratch
Here are key points I copied and pasted here for future reference :
Part 1: General introduction
If you are already familiar with web development, forget everything you know about it.
The worst thing you can do is get angry that you can’t use DIVs or that margin isn’t fully supported. So forget everything you know about semantic HTML and the latest CSS spec.
The best way to test is using Litmus or Email on Acid. I recommend taking out an unlimited plan with either of these companies because being able to test frequently is really important.
The two services that I use the most are MailChimp and Campaign Monitor.
Image-reliant emails with no text are more likely to be marked as SPAM and so are emails with really long image filenames.
Run a SPAM test through your testing account with Litmus or Email on Acid before you send your email, to make sure all your hard work isn’t headed straight for the Junk folder.
Frameworks like the HTML Email Boilerplate are full of wonderful tricks and snippets that you can implement piece by piece. However, if you are just starting out I don’t recommend using it as a starting point as it contains a lot of elements that you won’t need. Boilerplates can often make it more difficult to troubleshoot any issues if there is a lot of unused code in your file.
Using an XHTML doctype generally has the fewest quirks and inconsistencies between documents. I use XHTML 1.0 Transitional because it has proven itself to be the most reliable doctype in my experience.
The viewport meta tag is telling the device to set the viewable area to the width of the device’s screen. It also sets the initial scale to ‘normal’ which is neither zoomed in nor out.
Email is All About Nesting Tables, you need to use lots and lots of nested tables because neither the colspan nor rowspan attributes are properly supported.
Again, because of the lack of standards support, it’s not a great idea to use standard tags like h1, h2, h3 or p. Your best bet is to place every block of text into its own cell and apply inline styling to that cell
You can’t apply multiple classes to things in HTML email because it is not supported. Every element can have a maximum of one class.
You can’t use shorthand for things like font size (i.e. style="font: 8px/14px Arial, sans-serif;") because it is not supported.
It’s good to give your images names that are short and meaningful because it will improve your spam score.
It’s also a really great idea to try to keep your entire email as small as humanly possible: under 100kb is ideal but not always possible, under 250kb is pretty standard.
For your main container elements always set the size in pixels. You can then use percentages inside your containing element if you wish.
Responsive Email templates
http://zurb.com/article/1119/create-emails-for-any-device-introducing-
Part 2: Build Template from Scratch
If an attribute exists in HTML, use that instead of CSS
Always remember to use the full six characters of a hex code, as three character shorthand won’t always work.
When using padding in email, you must always specify every single value (top, right, bottom and left) otherwise you can get unpredictable results. Note that it’s safe to use padding on TD tags but not on P tags or DIVs.
We’ll insert our image, adding alt text and adding style="display:block;" which is a common fix that stops some email clients adding gaps underneath your images.
If the contents of your header are really important to your message, don’t use an image-only header. Remember, images are blocked by default for most clients, so if there is an aspect of your email that is crucial, never include it as an image.
If you always have pixel widths on everything, you can end up with a lot of values to override with media queries. If your nested table widths are based on percentages, then when you adjust the width of the parent element, everything will adapt accordingly.
Because we want a ‘margin’ in between these two cells, but margin isn’t supported, we’ll create a three-column table with an empty cell between the two outer columns.
Be sure to zero your font-size and line-height and add a a non-breaking space character in the margin cell.
We’ll also set the valign to "top" for both cells so that they will vertically align to the top, even if one column has more text than the other. The default vertical alignment is "middle".
As we need multiple rows, we’ll nest yet another table because we can’t use any colspan or rowspan tags.
Let’s run this through the W3C Validator to make sure nothing is bad or broken.
Next we’re going to run a test through Litmus to make sure the structure of our email works great.
Time to turn off the borders and see it looking beautiful. Go through and replace every occurrence of border="1" with border="0".
As a final touch, I’m going to add 30px of padding to the bottom of the very first cell, to prevent our email from stopping abruptly at the bottom in some webmail clients (like Apple Mail), and 10px of padding at the top, so that our blue header has a little bit of breathing room.
If you have used any comments, get rid of them. Some email clients can choke on comments so it’s wisest not to have any unnecessary code anywhere in your files.
postMessage only works for IFRAMES/FRAMES in IE9
http://blogs.msdn.com/b/ieinternals/archive/2009/09/16/bugs-in-ie8-support-for-html5-postmessage-sessionstorage-and-localstorage.aspx
From this blog, the limitation of IE9 postMessage implementation impacts cross window/tab communications, at least for this windows browser. Firefox, Chrome, Safari, Opera seem to implement well. Through postMessage and onMessage interfaces, it is a convenient, efficient and secure way to do cross window/tab/frame communications, even cross domains.
Though parent and child window can easily access eachother’s DOM, a common way to get a value from one window to another is by setting a value on a hidden input field of a form in the other window. Therefore, the solution is adding a form to your page and using hidden form elements to transfer data back and forth between windows.
Here is one jquery plugin which encapsulates all the form building, event handler details.
http://www.sfpeter.com/2008/03/communication-between-browser-windows-with-jquery-my-new-plugin/
From this blog, the limitation of IE9 postMessage implementation impacts cross window/tab communications, at least for this windows browser. Firefox, Chrome, Safari, Opera seem to implement well. Through postMessage and onMessage interfaces, it is a convenient, efficient and secure way to do cross window/tab/frame communications, even cross domains.
Though parent and child window can easily access eachother’s DOM, a common way to get a value from one window to another is by setting a value on a hidden input field of a form in the other window. Therefore, the solution is adding a form to your page and using hidden form elements to transfer data back and forth between windows.
Here is one jquery plugin which encapsulates all the form building, event handler details.
http://www.sfpeter.com/2008/03/communication-between-browser-windows-with-jquery-my-new-plugin/
Friday, June 7, 2013
SecurityError: The operation is insecure.
How to resolve this? This error appears if secure HTTP (https://) tries to connect non-secure websocket (ws://) servers.
We tested this issue through below test site across browsers, and found most browsers throw SecurityError
https://www.websocket.org/echo.html
Windows:
IE 9 [no websocket support]
IE 10 [no]
Chrome [ok]
FireFox [no]
Opera [no]
Mac:
Safari [ok]
Chrome [ok]
FireFox [no]
Opera [no]
Firefox (v21) has a flag to control this (network.websocket.allowInsecureFromHTTPS from about:config)
We tested this issue through below test site across browsers, and found most browsers throw SecurityError
https://www.websocket.org/echo.html
Windows:
IE 9 [no websocket support]
IE 10 [no]
Chrome [ok]
FireFox [no]
Opera [no]
Mac:
Safari [ok]
Chrome [ok]
FireFox [no]
Opera [no]
Firefox (v21) has a flag to control this (network.websocket.allowInsecureFromHTTPS from about:config)
Subscribe to:
Posts (Atom)