Enable custom submit button styling in Safari mobile

If you want to style a form submit button with custom size and border radius you have to “nullify” the default Safari mobile style, since differently it will be somehow “unrewritable”. I discovered that there is an handy CSS property called “appearance” which is used for native-style display of elements. With this property is possible to display special search box, cursors and so on… the reference for Safari can be found here, that one for Mozilla can be found here.
In order to remove native style is possible to set “appearance” to none, thus to enable complete custom styling of our submit buttons we can write the following CSS statement:

   -webkit-appearance: none;
   -moz-appearance: none;
   appearance: none;  

Some notes:
– vendors-specific declarations (-webkit, -moz) may be removed
– do not reset appearance for all the HTML elements (ie: “*”) or you will have to work hard to restyling complex components like select!

How to solve CSS conflicts using jQTouch

In these days I’m developing my first iPhone application, using frameworks like PhoneGap and jQTouch. This aims to be a powerful app, not a mere widget, so I’m writing a lot of code and I’m using several libraries and components in order to create a really native-like application.
Unfortunately, due to a bad CSS approach, I faced an issue with the excellent SpinningWheel component which won’t never be displayed unless you open and modify jQTouch CSS. The fact is that, jQTouch takes the body and use it as main container to hold all application’s pages and components and by default it hides all nodes inside the body except the current displayed content (active page/section) and this is a problem, because SpinningWheel create the ui object into the body and it won’t be displayed.
Fortunately the solution is simple, we just need a wrapper, an html element which will holds all jQTouch stuff in place of body, so in my html I wrapped all inside this:

Then I changed all jQTouch CSS, to reflect this approach (you can see the wrapper as a sandbox):

div#jqtouch-wrapper > * {
-webkit-backface-visibility: hidden;
-webkit-box-sizing: border-box;
display: none;
position: absolute;
left: 0;
width: 100%;
-webkit-transform: translate3d(0,0,0) rotate(0) scale(1);
min-height: 420px !important;
/* ...and so on*/

…and finally I changed jQuery selectors inside JavaScript code:

$body = $('#jqtouch-wrapper');
// ...and so on

It’s also possible to solve the conflict by changing SpinningWheel code in order to put the dom node inside active jQTouch pages, but the problem of potential incompatibilities will remains. A CSS declaration, except reset statements and other rare cases, should NEVER refers directly to a whole set of nodes (ie: ul { color: red; }), but to a node type contained by a wrapper/sandbox (ie: #foo ul {color: red; }), thus conflicts will be avoided.

Avoid CSS hacks for internet explorer 6 (ie6) by using selectors

Is a common practice to use CSS hacks in order to assign specif stylesheet to internet explorer 6, like:

<!--[if IE6]>
    <link rel="stylesheet" type="text/css" href="ie6fix.css" />

However we can avoid extra CSS files (for internet explorer 6) by assign first all the necessary properties for it, an then reassign them for others modern browsers (firefox, safari, opera and ie7) . For example:

div.mydiv {
    padding: 5px;
    position: absolute;
    top: 5px; /* this should be 3px except ie6 */
    right: 10px; /* this should be 7px except ie6 */

redefine the properties for all browser that
support CSS selectors (not ie6!)
div[class~="mydiv"] {
    top: 3px;
    right: 7px;

It’s important to notice that we should use the “contains” selector (~=), in order to work even if the div into the page as several CSS classes applied (like <div class=”mydiv customer_info”>).

CSS tip: if you can’t remove the evil, you can imprison it!

prisonYesterday a colleague asked me to help her in debugging a crazy behavior of internet explorer 6 (all the others browsers worked fine!), which caused the wrong display of the boxes inside the page. The bug was caused by the rendering of a jQuery powered div, ie one of those things like:


In somehow the jQuery’s function used, annoyed ie6 due to the CSS styles that it applied to the div. After a couple of minutes of debugging, I realized that we should have needed to spend a full day or more to fix the problem at the root (due to the complexity of the page content). So I decided to isolate the problem by using the CSS positioning technique. Fundamentally I put the div (“#myDivID”) into another div with relative position and set the first with an absolute position, in this way:

<div style="position: relative; width: Npx; height: Npx;">
    <div id="myDivID" style="position: absolute; top: 0; left: 0;"></div>

With this expedient “myDivID” is now “trapped” into the parent div and it can’t influence the others page elements.