If I wrap the paper-dropdown that comes in the paper_elements example in a core-tooltip, the tip displays on hover as expected.
<core-tooltip position="bottom" label="Choose country of residence">
<paper-dropdown>
<template repeat="{{countries}}">
<paper-item label="{{name}}"></paper-item>
</template>
</paper-dropdown>
</core-tooltip>
The problem is, after selecting an item, the tooltip is still displayed. Additionally in dartium and on chrome there is a fine blue line outlining the tip and the dropdown even as I hover over other elements.
Please explain what is going on and what is the best way to register with the PaperDropdown and/or CoreTooltip that it no longer has focus? I've tried calling focus() another element in the onClick PaperItem in my own examples and that did not seem to work.
Any suggestions on better approaches that might make tooltip unnecessary would be useful as well. The reason for a tooltip is there is no comparable Floating label as with PaperInput for the dropdown. So once a selection is made there is no description, thus the tooltip.
It seems to have to do with focus. Mybe this improves your situation. If this is not what you want just add a comment:
core-tooltip:focus {
visibility: hidden !important;
}
Sometimes the tooltip seems just not to recognize that the element isn't mouse-overed anymore when not the mouse moved out but instead the mouse-overed element shrank away. I would report this as a bug in the <core-overlay> element.
Related
I have a kind of "widget" - a data table with some rich functionality like sorting, row selection and else.
In some cases (widget placement/nesting in DOM) clicks on it's rows are not triggered in iOS 7 Safari.
Widget is using jQuery 1.6.4
I can't publish a whole widget code (and you really wan't this to happen ;)), but I can narrow down a reproduction scenario to the following case:
Simple html table with some rows, two cols in each
First column contains a "checkbox" - simple div which is normally hidden and becomes visible, then parent row getting hovered. Visibility is triggered with CSS only
Every row has a click event handler. No mater what it does. In my example it will trigger an alert()
Table's parent is a block element with a fixed height and overflow-y set to auto
Table is bigger than it's parent, so, some table content is hidden and can be seen with scrolling
Here is a jsFiddle: http://jsfiddle.net/822eG/4/
On any desktop browser items are successfully hovered, click is triggered. On iOS7 hover is working but click is NOT triggered.
NOTE: On iOS you must tap twice to trigger click. First click will trigger hover and you'll see a "checkbox", then second tap must trigger a click, but it doesn't...
Any of those conditions is REQUIRED to reproduce an issue. Remove a single one and it starts working...
If you remove a "checkbox" appearance - click will work (http://jsfiddle.net/822eG/5/).
If you remove a height fix - it will work (http://jsfiddle.net/822eG/6/).
If you remove a overflow scrolling - it will work (http://jsfiddle.net/822eG/8/).
Any workaround is needed but functionality should be kept untouched. So, I can't remove "checkbox", size fix, hovering, clicking or overflow scrolling. Also, changing HTML markup is hardly to happen.
NOTE I've got a solution - see my answer below. But I still need a better workaround to keep using CSS as mush as possible.
ADD: Filed a bug to Apple #16072132
Try this:
.wrapper {
-webkit-overflow-scrolling: touch;
}
To get iOS to ignore hover states, try this:
.wrapper
{cursor: pointer;}
You can use this on any element to get it to function as expected.
Suddenly, I've got a solution... Using JavaScript I can remove :hover selector but still keep functionality.
If I will trigger checkbox visibility not by CSS :hover but by class and set it via javascript, it will work.
http://jsfiddle.net/822eG/10/
My current working solution requires no any changes in a whole code base and works fine in our conditions
With MutationObserver, monitor node insertion into head
If new node is inserted, and this is a link, check document.styleSheets
For each sheet check it's rules
If rule selector (access by document.styleSheets[n].rules[i].selectorText) contains :hover check styles for this selector
If styles contains display different from none or visibility different from visible - this is a "show by hover" style
For each such style change it's selector - replace :hover by .hover and declare a body delegate for mouseenter and mouseleave events which will toggle .hover class on triggered element
Full source code here: https://gist.github.com/Olegas/9143277
..try using this:
$('.row').on('touchstart click', function(){
alert('clicked');
});
I'm having an odd problem with jQuery draggable this morning, I wonder if anyone else has come across this.
I have many small divs inside a large div. They are absolutely positioned: "position:absolute" in CSS for their class, with the actual position itself calculated and set in JS on demand.
Now I'm adding functionality to allow these divs to be draggable.
But, as soon as I make one draggable, it is given "position:relative" directly on the element, which as you might imagine, seriously messes up the on screen position.
Does anyone know why it changes the "position" like this or how to tell it not to?
EDIT:
Just realised there is a rather obvious answer staring me in the face - !important on my position:absolute! This seems to fix it. BUT I'm still interested if anyone knows why it sets "position: relative" like this (and doesn't either make it configurable or check first if it needs position)...I'm wondering what problems I've just stored up for myself ;-)
"I came across the same problem today. The reason was I was applying draggable() on a dynamically created element. I was 'later' appending it to dom. The element should be in dom when you apply draggable() (if style is being applied by a class). In short, when it finds no position attached with the element , it adds relative." - Jashwant
Firs do: .append(jElement) Then: jElement.draggable()
For some reason Jashwant put his answer in the comment to the question. So I thought it will be convenient to other to repost it here.
It also happened to me, but only on Chrome. Reason?
It was like this:
$("#div-popup").draggable({ handle: ".top", containment: 'document'});
Then I removed the containment parameter, like this:
$("#div-popup").draggable({ handle: ".top"});
So it's about the Browser (Chrome in this case), which sets position to Relative when you specify which containment the element will be draggable.
in my case it seems to be a race condition between the stylesheets and javascript loading...
i realized i'd made the mistake of including the stylesheets AFTER the javascript in the document head. they should be included BEFORE the javascript because $(document).ready() does not account for the CSS being loaded by the browser: https://stackoverflow.com/a/1324720/3633109
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 textbox that I am attaching jQuery UI's Autocomplete functionality to and I am using CSS to give it a max height via the example here. My problem is that doing this causes the z-index problem that bgiframe solves to come back again, but in a different way. The initial autocomplete menu is above all the controls underneath it, but when I begin to scroll the autocomplete menu falls behind them.
Any suggestions?
EDIT:
This is purely an IE6 bug.
As you can see, after scrolling down the autocomplete falls behind the other controls.
I could solve the problem by replacing offsetHeight by scrollHeight in the following line (from jquery.bgiframe.js) :
height:'+(s.height=='auto'?'expression(this.parentNode.offsetHeight+\'px\')':prop(s.height))+';'+
This change solved the bug for the autocomplete fields with vertical scrollbars. I could not spot any regression in other kinds of dialogs (but I did not run extensive tests).
You need to reverse the z-index order of the form elements (or their containers) using javascript. I.e., "Social Worker" has the lowest, "DX Code" the highest z-index.
You could change the offsetHeight to scrollHeight, like Siggen says, but I have encountered problems when there is only 1 result returned from the autocomplete. The 1 result is squished into a window that only like 2 pxs high.
I found a fix though.
When you have a data.length<2, you should use the offsetHeight, rather than the scrollHeight.
You have to modify autocomplete.js.
Locate this code:
if($.fn.bgiframe)list.bgiframe();
And make it this:
if($.fn.bgiframe){
if(data.length<2)
list.bgiframe({height:'expression(this.parentNode.offsetHeight+\'px\')'});
else
list.bgiframe();
}
Remember, this code should be used in combination with Siggen's fix.
I have used a combination of both parameter for the height like this:
'height:'+(s.height=='auto'?'expression(Math.max(this.parentNode.offsetHeight,this.parentNode.scrollHeight)+\'px\')':prop(s.height))+';'
Look at the max function. Now it is good with no scroll bar (shorter list and longer list as well)
and now the autocomplete component looks perfect in IE6.
Sure I've seen this done before but off-hand I can't find any examples.
I've got a TListView, set in 'report' viewstyle. It has about half a dozen subitems, and one thing we'd like to do is have the 'hint' (tooltip) on the listview dynamically show another field of data. That is, each time you move the mouse over any given row, the 'hint' would show some text relevant to that particular row.
I'm partway there - I can do this using the OnInfoTip method, but unfortunately once a tip has appeared, Windows seems to decide that I don't need to see a hint for the listview again until I move the mouse away from the listview and then back 'over' it again. Simply moving the mouse down to the next row, all-the-time keeping the mouse over the control, doesn't persuade the program to display the new hint.
Just to be clear - I've got OnInfoTip working so that the program does display the right hint relevant to the item I first moved the mouse over. Changing the hint text isn't the issue. The problem is that moving the mouse to another item in the listview doesn't cause the software to show a new hint. (Hope that makes sense).
Is there some proper way of getting this behaviour to work, or am I going to end up doing something icky with mouseovers and then manually drawing a hintbox (etc)?
check the following link:
Display Custom Hints for TListView Sub Items
Edit:
I just checked it now on delphi7 it's showing the hint for every row dynamically after moving the mouse on the listview.
Offtopic: This is simple in Virtual Treeview component, it is build-in feature.
i was using the OnInfoTip event (i didn't need hints for the subitems). the hint was "flashing" (show/hide/show/hide/show/hide/show/hide). found the listview's ShowHint was false. set it to True and it worked as it should.