So I did a test of the actual size (width and height) of the jquery UI combobox button on the JQuery demo page in Opera 12, IE9, and Firefox 15 to see if it was a zoom thing or something else.
Turns out the button sizes were actually different for the Opera browser and much bigger.
Opera width/height: 30px / 25px;
IE width/height: 24.2px / 19.37px;
Firefox: 24.2px / 19.6px;
Why is that? I don't want huge JQuery controls when viewing in Opera. This is only for the JQuery controls too as the other controls on my page are the same size.
Based on #Nal and #Mystery Man's comments, if I set a default font size at the html and/or body level it to px's or pt's, it fixes the discrepancy. Setting it to any em setting is what was causing the issue since the default was 1em or something. The jquery demo pages just use the default jquery font size setting which is in em's and thus not an aboslute size.
I'm using jquery UI to resize a div vertically(I.E. using the n handle). I'm using a helper so it only resizes after the user stops dragging. After a resize is done I call a function which sets dimensions on surrounding elements so they all fit within a container.
This works in both chrome and IE, but in firefox a css property of top is added which blows the div out of the container.
I've tried removing the top value after the fact, which works, but this is kind of a hack and also causes the div to 'jump'.
Is this a bug? Is there a workaround using jquery css html, etc?
To see what I mean check this fiddle and resize the element, if you inspect it in firefox there will a top css property but not in chrome.
Thanks,
Luke
In my opinion it is a bug.
Workaround: if you add a top: 0; to the css rule for #resizable IE, chrome and firefox have the same behavior. Also see the updated example.
=== UPDATE ===
It's a firefox bug. I walked from the jQuery UI resizable method code until the css method of jQuery (main) code to find an answer. At the end of my search I could found that firefox returns for css top value auto for not/static positioned elements, but returns 0px if relative position is set; in both cases top is not defined (they could be set to auto with no difference - it's the default value).
Also see this example.
In the resizable method this result makes the difference (jQuery UI sets the relative position to the DOM element by adding a class). If the bug (which I have reported to mozilla) will be fixed, the behavior of your example in the firefox should be the same as in chrome.
I'll report here if there is something new...
=== UPDATE ===
Now I have a workaround for you:
for the special situation you described set the css position of your resizable element manually to static.
Add to your stylesheets:
#resizable { position: static; }
Also see your updated example.
I'm trying to apply jQuery UI Selectable to a portion of my website. However, I do not see either the selection box while dragging the mouse, nor does the color of selected li elements change.
So to understand the problem, I went back to the source:
http://jqueryui.com/demos/selectable/
I see (using IE9 developer tools) that a style .ui-selected is applied to selected elements. Using Trace Styles, IE shows that background-color is originally defined in jquery-ui.css but overridden (ultimately) by #selectable .ui-selected. However, IE does not show the source of #selectable .ui-selected. Searching the jQuery UI style sheet I reference, jquery-ui-1.8.18.custom.css, finds no mention of ui-selected, nor do I find it in jquery.ui.selectable.css.
Where exactly is the demo page getting the CSS for the background color?
I found one of the other jQueryUI demos defines the style for those classes in a custom style sheet, so I ended up following that lead.
http://jqueryui.com/demos/selectable/#serialize
It seems odd that those styles are not part of jQueryUI Themeroller. Perhaps that will change in the future.
I have a form with an input element and a button and i'm using jquery ui for styling the button.
However in IE7 the button is not properly aligning with the input but works well in other browser like chrome or even IE8.
Is there a way to fix this ?
In recently testing a web application on Windows/Mac desktop browsers - and then on an iPad I noticed various differences in Safari that I wasn't expecting. Even though the version # is the same.
I'd like to compose a list of those differences (for myself and others) to have as a developer reference.
e.g. in Safari on the iPad
iPad Safari takes full control of Select list/option styling
iPad opens the onscreen keyboard when an input element receives focus, thus inline floating calendar widgets (and the like) may not work as expected (or need to be altered)
iPad Safari doesn't support position:fixed like desktop Safari < iOS 5
iPad Safari (similar to iPhone/iPodTouch Safari) automatically hyperlinks 10 digit numbers to offer phone #/contact options
iPad Safari prompt('long message...','default'); shows only 1 line of the message (though it does provide scrolling of the message
I've heard from others that certain JavaScript doesn't work, etc. etc. but I have yet to fully test it thus I'd be grateful for any discoveries that you may have encountered.
A few more for you:
No Flash
Lousy iFrame support (so facebook like etc. needs a custom implementation for iPad)
Weird caching limitations
HTML textAreas doesn't get a scroll bar (you have to double-finger swipe - which of course, is amazingly intuitive)
In general. Treat it like a scaled up iPhone, not a scaled down Desktop.
I thought this might be useful: Apple's guide to preparing web content for the iPad
Just been caught out by the position:fixed issue my self
Safari on iPad has the same issue with button width/padding as on the iPhone
iPhone <button> padding unchangeable? describes this problem and a solution for removing padding on a button with text, but this does not help you if you want a button to be narrower than the padding itself (e.g. for a button that only has a small icon on it). To do that, I had to surround the button with an outer element with a defined width and overflow: hidden like so:
<span style="border: solid 1px blue; display: block; width: 16px; overflow: hidden">
<button style="-webkit-appearance: none; border-width: 0"> </button>
</span>
(the blue border is to show where the button is, it's not critical to the hack)
jQuery's offset() doesn't work: http://bugs.jquery.com/ticket/6446
It also looks like iPad Safari has issues with elements with overflow:auto; that therefore should show scrollbars (test page with div's and iframe's).
iPad Safari seems to have trouble handling background images in rare cases, showing weird lines of lower lying content.
There's not a lot about this in Google (yet).
iPad browser doesnt support file uploading(even if it supports it will useless as iPad does not have a standard File Browser). The file field appears with a Choose File button grayed out.
Beside doesn't support scrollbar in TextAea, it seems that we can using javascript to make text in TextArea selected automatically too.
This code will only move cursor to the end of text in TextArea.
<div>
<textarea id="text-embed-code" autocapitalize="off" multiline="">
There is a fox running after chrome.
</textarea>
<button onclick="testSelectText(event);">select text</button>
</div>
<script>
function testSelectText(e) {
var box = document.getElementById("text-embed-code");
box.select();
e.preventDefault();
return false;
}
</script>
There appears to be a bug in iPad Safari where a CSS element with both a background image and a background color is rendered with a slight border in the color of the background color. It should fill with the background image all the way to the edge of the rendered element.
I just had the same bug on my site, when trying to view it on an Ipad. The HTML structure is like:
<div class="main"> <!-- background-color: white -->
<div class="left"></div> <!-- background-image: url(some_transparent_png) -->
<div class="content">...</div>
<div class="right"></div> <!-- background-image: url(some_transparent_png) -->
</div>
The left layer uses a background-image, whereas the main layer uses just a background-color. The Ipad view shows a slight border at the edge of the left and right layer.
When i add
-webkit-background-size: 100% 100%;
to the left and right layer, the border disappears.
You can now control the styling of select lists on iOS by resetting it with -webkit-appearance: none;
This rule fixes animation flickering in Safari on iOS devices:
body {-webkit-transform:translate3d(0,0,0);}
There appears to be a bug in iPad Safari where a CSS element with both a background image and a background color is rendered with a slight border in the color of the background color. It should fill with the background image all the way to the edge of the rendered element.
24 bit transparent PNGS ABOVE A CERTAIN FILE SIZE don't render on the iPad2.
I can however get 8 bit ones of the same dimensions to render.
I haven't found out what this maximum file size is in order to get them to render.
I'm currently working on a small responsive web-app which makes heavy use of the iframe youtube api. Apparently the ipad version of safari doesn't support a few html5 methods which I use heavily in this project.
One of them is window.postMessage, which is a way of interacting with scripts on other pages, for example the a script that is used "within" that iframe. Autoplaying videos also doesn't work.
Frame problems. iPad Safari will both hide scrollbars and expand frames to the size of their content.
Changing the frame tag to include scrolling="yes" and noresize="noresize" appears to do nothing.
Some sites look fine on everything, even a Dreamcast browser, but not on iPad. The issue can be fixed using tables and iframes instead of normal framesetting (cols and rows, etc).
I also discovered that contenteditable is not supported in mobile safari, thus using a plain textarea is a better bet. Apple Developer Docs
position: fixed;
Does not work in iOS 4 but does work on iOS 5.