In an application I'm developing, I pop up Help in a modal jQueryUI dialog. For the most part, it works beautifully. There is one problem: if you try to use the arrow on the lower right of the dialog to scroll the help text, you can't, because it is in the same place as the mouse-drag resize for the dialog.
I realize this would not happen if I used the jQueryUI dialog "button" option to add a "Close" button at the bottom of the dialog, but that would be inconsistent with our style elsewhere in the application.
Anyone know a reasonable way around this? Ideally, I'd like something that would give me a small non-scrolled div at the bottom of this dialog, without affecting other dialogs, so that the mouse-drag resize would fall lower on the screen than the down-arrow.
Adding a bottom padding to the ui-dialog class in your jquery-ui.xxxx.css should result in the behavior you want:
.ui-dialog {
... Existing CSS...
padding-bottom: 15px !important;
}
Related
I've got an app which leverages a WKWebView for most of the content. In a few screens we have buttons in a div which leverages position: fixed; so that they're always in the same place as a long form scrolls underneath. When the virtual keyboard is shown I add a class to the document body that can be used to adjust other things, for example, tweaking the bottom property on the div containing these buttons so they move above the keyboard.
So far, so good, they're always visible. The problem arises when the form is then scrolled, the buttons visibly move up with the rest of the page (which they shouldn't), but the browser actually acts as if they're still position where they're supposed to be. The screen shot shows where the browser believes the buttons are, and if you touch those areas then the buttons get activated.
I'm happy to chalk this up as a bug with WebKit or specifically WKWebView, but is there a known workaround for this so that they render in the correct place? I read that adding a translation to trigger hardware rendering could help, but it doesn't seem to have done the job here. I also read that changing the position to absolute could solve this issue, but for me it just results in them being rendered off screen somewhere altogether.
You can add fixed position to button wrapper
.btn-bar-fixed {
position: fixed;
bottom: 0px;
right: 0px;
}
I have a custom radio button that has a colorized and larger circle for the button. It's implemented using CSS as found in http://webdesign.tutsplus.com/articles/quick-tip-easy-css3-checkboxes-and-radio-buttons--webdesign-8953
However, when you have display:none in your CSS for the radio button, it confuses VoiceOver and the element is no longer read as a radio button even though the <input> type is 'radio'.
<input type="radio" value="1" id="rad1" name="station"><label for="rad1"><span></span>Helium</label>
<input type="radio" value="2" id="rad2" name="station"><label for="rad2"><span></span>Hydrogen</label>
input[type="radio"]
{
display:none;
}
I tried adding role='radio' to the <input> tag but that didn't help. When VoiceOver doesn't think it's a radio button, then you lose valuable interaction information. VO no longer says "radio button" or "1 of 4" or "checked".
All I can think of is not using display but rather using position and left to force the original radio button circle to be off the display.
input[type="radio"]
{
position: absolute;
left: -1em;
}
This does seem to work but doesn't seem "right". Is there something more elegant? Typically, with screen readers, you don't want to move an element off the visible display because with a screen reader, you can still put your focus on the item through various navigation techniques.
Also, when the circle itself is just pushed off the display, VoiceOver still knows about it and draws its focus rectangle to include the item that's off the display. This causes the rectangle to span all the way to the left edge.
Edit: Using left:-1em doesn't work either because it causes the display to scroll to the item that's off the screen when you swipe with VoiceOver on. My next attempt is to not hide the radio buttons (ie, don't use display:none) but leave the buttons there but cover them up with the background image used for the buttons (as explained in the webdesign url). This seems to work. I have
left:-20px;
position: relative;
for my <span> tag (which is where the image is displayed) and that causes the image to be displayed on top of the radio button circle.
So the end result is that, visually, you don't see the native radio button circle but rather see my image circle, and VoiceOver still thinks everything is a radio and announces "1 of 4" and "checked".
I didn't mark this as my answer to my own question because it still feels like a hack. It sounds like a bug with VoiceOver that it doesn't announce the element as a radio button.
display:none and visibility:hidden will hide content from screen readers. Using an absolute position off the screen is called "Screen reader text", this will hide the content visually but still have it read by a screen reader. This is true for all desktop and mobile screen readers.
So if you use display:none your radio button will be ignored, this is correct behaviour. The usual solution would be to place the radio button off the screen, but you are right that VoiceOver then places the focus on the left edge of the screen. Other (desktop) screen readers won't do that, it's just a weird behaviour of VoiceOver (imho a bug in VoiceOver). I wouldn't worry about this too much as this is just how VoiceOver works, but obviously your own suggested solution (placing the radio button behind the image) is possible in this case and is far better as the visual VoiceOver focus is then in the correct place. I wouldn't call it a "hack" - at least not any more that the very common practice of "screen reader text" is essentially just a hack.
Note there are often situations where you need to add some extra information for screen readers like VoiceOver where you don't have an image to hide the text behind, then placing the text off the screen may be the only option and the visible VoiceOver focus at the edge of the screen is a trade-off you need to accept.
A good summary of different techniques how to hide content can be found here: http://webaim.org/techniques/css/invisiblecontent/
Another option is to use role="radio" on the element you want screen readers to focus as the radio button. You'll want to make sure you add aria-checked, aria-disabled, etc as needed. Lastly, you can use aria-hidden on the real radio button to make screen readers ignore them.
More info. about role="radio": https://www.w3.org/TR/wai-aria-1.1/#radio
I use CSS to hide the actual <input type=radio/> under the <label>-graphic by using z-index: 2; or something else higher then the <input>'s z-index on the <label>.
This is proven to work even on older iOS where pressing the label didn't focus/activate the input.
Another way is to hide the <input type=radio/> by hiding it off-screen like this:
position: absolute;
left: -999em;
(If you minus this could you explain why? This is the most accessible solution for all iOS versions and other User Agents/Assistive Technologies combos)
I have buttons in my web app using jQuery Mobile.
When clicked the buttons have the ui-focus class added which displays a blue halo around buttons. The class stays there until another spot on the page is clicked. This happens in firefox, not iPad. I would like that this halo is not displayed.
What must I do for that focus halo not to be displayed at all ?
You can override the default css instead of hacking up the source. Just make sure your css file is after the JQM one.
.ui-focus,
.ui-btn:focus {
-moz-box-shadow: none;
-webkit-box-shadow: none;
box-shadow: none ;
}
I have found that the best way to do this is to give focus back to the page after your buttons are clicked.
$('yourButtons').click(function(){
//Do some important stuff
// ....
$.mobile.activePage.focus();
});
Well thats easy, just open your xxx-mobile-theme.css file and find the class ui-focus
and remove the box-shadow property manually
None of the solutions worked for me as I had a custom submit button and used data-role="none" on the button. The :focus event still had the blue glow so this worked for me. I wrapped my form in a div called myform.
.myform button:focus {
outline: 0;
}
On my jQuery Mobile page, i'm using a horizontal control group for some buttons.
But in some languages the text within these buttons is too long.
Instead of wrapping the text within each button, the buttons themselves wrap onto the next line.
this is the base code:
<div data-role="controlgroup" data-type="horizontal">
short button
really really really insanely long button is really really insanely long. No really, who makes buttons this big?
</div>
and with this css, we convince it to wrap inside the buttons. Otherwise the text is truncated with an ellipsis
.ui-btn-inner{
white-space: normal !important;
}
On the third page of this fiddle the problem is demonstrated
http://jsfiddle.net/koesper/R8Kwe/
Anyone have any ideas how I might tackle this?
Thanks in advance,
Casper
ps. Inspiration for the original fix came from Tosh in Jquery Mobile Multiline Button
You could set widths for the links in your control-group:
.ui-page .ui-content .ui-controlgroup a {
width : 49%;
}
This will keep them on the same line. Here is a demo: http://jsfiddle.net/R8Kwe/6/
Also, just to be thorough, the white-space : normal actually needs to be applied to the .ui-btn-text element which is a child of the .ui-btn-inner element (so it still receives the inherited value).
Trim your long buttons - that's a usability issue. If you have action buttons named that long seems like that just defeats the purpose of an action? Other than that I wouldn't use controlgroups for something like this. I would use a custom data theme & some grids to house my buttons inline.
I have a jQuery UI Dialog, it is Modal and shows with a Bounce effect. I use a Theme where the background is dimmed with a striped image.
The first time the Dialog is opened, the striped background also covers the dialog during the bounce effect. Once the bounce effect has finished, the dialog becomes modal and appears in front of the striped background.
On the next opening, the dialog bounces in front of the background right away.
How can I make the dialog appear in front of the background right away?
Tom's answer pointed me in the right direction, and Firebug was very useful!
The dialog is wrapped in a <div class="ui-effects-wrapper"> which is generated in the createWrapper function in ui\effects.core.js
I added a parameter "z-index=1005" (just to be sure ;) there.
So in jquery-ui-1.7.2.custom.min.js it now looks like this
createWrapper:function(f){if(f.parent().is(".ui-effects-wrapper")){return f.parent()}var g={width:f.outerWidth(true),"z-index":1005,height:f.outerHeight(true),"float":f.css("float")};f.wrap('<div class="ui-effects-wrapper" style="font-size:100%;border:none;margin:0;padding:0;z-index:1002"></div>');
Not sure if it's the best way, but it works.
This sounds like the zIndex of the dialog is not assigned until after the animation. Try this in your CSS:
.ui-dialog {
z-index: 1002;
}
Dialogs usually have this CSS class, and the overlay usually has a zIndex of 1000 (at least in the version I am currently using). If this doesn't work, try to find out (using Firebug) what other classes are assigned only during the animation and assign a zIndex to those.