Ok so the story is my users need a multi-select dropdownlist, which doesn't exist in ASP.NET, so the simple solution I'm going with is I'm using listboxes with multiselect on and I start them off at size 1, and onmouseover I change the size to say 10, onmouseout sets it back to one. Simple enough and the users don't know the difference.
Now, my issue comes from the fact that since I have any number of controls on my web app, I've set these listboxes to higher z-index numbers than the other controls, which creates a problem: on my listboxes closer to the bottom of the page the list expands below and not above, and part of the listbox goes under the bottom of the page but since onmouseout resets the size of the listbox I can't scroll the page down.
Does anybody know what I need to set to make it expand up instead of down?
edit Also, some may ask "why don't you just rearrange the listbox to a higher position in the page," the reason this isn't a viable option is I have well over 40 controls on the page and it they're grouped cohesively, I didn't just randomly place them where they are.(ie. investment info in one section, account in another, suitability in another)
EDIT: It's worth noting that the jQuery version of the below will be more compact and, in my opinion, more easily understood.
Glo, the code you have currently would be helpful here, especially since it seems you will have difficulty changing anything we give, or implementing what we might describe. Anyway, this works as intended in IE7, Firefox, and Opera; Safari and Chrome go quirky with it: http://jsfiddle.net/bUFzq/35/ (modified from http://www.plus2net.com/html_tutorial/html_frmddl.php).
The CSS just makes the select position-able relative to its default placement. Elements can only be positioned relative to other positioned elements. `position: relative;' leaves the element where it was until you move it, unlike absolute and fixed. It also positions relative to the edges of its nearest positioned ancestor. (The IT industry has the unfortunate convention of increasing Y downward rather than upward; just a heads up - or down.)
element.offsetHeight is the computed height of the element - how big it appears on the screen. element.style.bottom (like its cousins top, left, and right) sets the element's offset from the corresponding edge, in the direction of the element's center. setAttribute is fairly self-explanatory; it acts as if you were actually editing the HTML. Most properties of element.style (that aren't on all other objects) represent and modify similarly named CSS properties. For example, element.style.backgroundColor sets the background-color property.
addEvent is a function copied from Dustin Diaz's Rock Solid addEvent() because the browsers don't agree very well on how to do events. However, I would have put his script in a separate file and mine in yet another if I weren't working within a single script area. I did the `var addEvent = init();' thing just so you wouldn't have to scroll through his source, even though it is a good example of good code.
mouseover & mouseout are the actual listeners, explicitly called using apply 1) because I needed that height value for later and 2) because for some reason (at least within jsFiddle) it doesn't start out in the correct position, and only if the listeners are called in that order will it get there.
Related
In a complex web application, I have to check whether certain HTML elements are visible partly/completely on the screen.
There are various reasons why certain elements are not visible on the screen:
They have certain attributes, like display:none visibility:hidden width:0 height:0 opacity:0 and maybe others.
Other elements are in front of the element.
They are outside the parent's visible scroll area.
To a certain extent, some of their parents have one or more of the properties above (elements with absolute or fixed positioning break the chain).
They are outside the parent's visible area for other reasons, for instance the parent may be partly overlaid by other elements and they are only covering that part.
The things I found on stack overflow (like How to Check if element is visible after scrolling?, http://stackoverflow.com/questions/123999/how-to-tell-if-a-dom-element-is-visible-in-the-current-viewport and others) are doing simple checks for one or two of the reasons above, but do not even nearly try to detect all reasons I lined out.
Before I now start implementing everything manually, including all the corner cases: Is there a reason-agnostic check available through javascript, that will give me feedback on whether the element is visible in the rendered result?
For now, the easiest and most reliable thing I could come up with was the idea (didn't test it yet) to modify the background-color attribute of the element, use the html2canvas library before and after, and check whether the resulting images match.
Is there anything short of that "workaround"?
(Update: I have tested my html2canvas approach and not only is it slow, it also gives false positives because the images are not always the same, even if the element with changed background-color is not visible at all.)
I know CSS is not supporting position: fixed for only x or y but only for both a the same time.
The common approach to solve this seem to be to use fixed positioning in combination with jquery to re-position the component with respect to the scroll amount in the non-fixed axis. The downside with this is that the component will lag a lot when scrolling in this direction.
My question is if this is a problem that is being looked at for future specs of CSS? Anyone know?
I think we need a fixed-x and and fixed-y positioning value.
This is especially becoming a problem now with touch devices where scrolling in both dimensions are more common.
Here's a fiddle:
http://jsfiddle.net/UfZPa/1/
which shows what I'm after but not the actual problem because this very small example is very fast as it looks now.
Update
From the CSS ED:
Intersection between the stickily positioned element and the bottom of
the sticky-constraint rectangle limits movement in any direction, so
the offset never pushes the stickily positioned element outside of its
containing block. However, when the element is free to move within its
containing block as the page is scrolled, it appears to be pinned to
the relevant flow root edges, similarly to a fixed position element.
I think this is describing what I want but I'm not sure...
Update 2
To clarify my app is basically a grid with scroll-overflow in both x and y (like Excel). What I want is some labels to stick at the edges in one directionwhen being scrolled out of view but at the same time stay in the normal flow in the opposite direction. I want this for both fixed-x/flow-y and fixed-y/flow-x. And the problem again: With lots of labels this makes scrolling very laggy using the jquery-solution. I think we are missing an option to make components fix in only one dimension and still flow in the other. Maybee I'm the only one wanting this =)
A quick skim through some CSSWG notes such as this one leads me to believe that position: sticky might be a potential solution to this problem, provided you only specify the offsets on the axis you want the element to be fixed.
There is a point of concern though: unlike a fixed element which is considered absolutely positioned, a sticky element starts out relative to its containing block. Since relatively-positioned elements are not taken out of the normal flow, you will have to account for the layout of other elements in the same flow as your element, among other things, and (thus?) forcing the element to act like it's fixed regardless of scroll position may be a little more difficult.
Of course, there is too little information and implementation available to verify any of this — I'm just making an informed guess, and the document I link to is an ED not meant for general reference — but you can always ask the www-style mailing list and see what the good folks there have to say. I haven't experimented enough with position: sticky to be able to comment further myself.
We are making this template in our language, Persian, that is right-to-left (RTL). Template address
Now, all parts are RTL, except that the submenu that opens to the right side,
Question: What changes should be made to this css file of the template, so that submenu width will be the same as its menu width? Or: How can the submenu be made to open on the left side?
Be aware that am not talking about the text in the submenu (text is rtl now as you see in picture)
Just a thought off the top of my head ...
I suspect you would adjust this line:
width: 140px; /*width of sub menus*/
to reflect a narrower width for your needs.
If you need to do this dynamically, you may have to do some work with Javascript to check the text being applied, then adjust the class reference to a custom class reference ... OR ... apply the new width to the element directly ... once the drop down entries have been filled.
Ah, ok, I see now. The problem here is that with the particular component you are using, you cannot adjust it with only CSS. The reason why is that the Javascript completely rewrites your CSS for that portion of the menu every time a user hovers their mouse over it. You're going to have to do some adjustment inside the Javascript to solve this.
There are several ways to go about this, I'm only going to get into one of them.
One way to solve this is adjust how the menu is rewriting it's CSS on the fly for the submenu. In this case, you can have the Javascript write a negative value in for the "left:" CSS element attribute to have the submenu position itself to open as you're wanting. Note: With this solution, this may not work in older Internet Explorer browsers - I'm not sure if that's a concern here. However, it will work just fine in the modern browsers (at least the ones I've been poking about with).
Open up your copy of the ddsmoothmenu.js file, that's the little bugger that is causing all the problems here.
The change needs to be done in the
$curobj.hover(function(e){..})
function. Stay with me, I'll explain...
That function is calculating the starting left position of your submenu once the user positions their mouse over the main menu choice. Namely, this line here is the culprit:
var menuleft=header.istopheader && setting.orientation!='v'? 0 : header._dimensions.w
As you can see, it is returning a '0' for you, which means it will anchor the left side of the submenu, forcing it to spill out to the right like it does now.
However, fear not!
Since you need the submenu to anchor on the right side and spill out to the left instead, we simply need to change this from assuming '0' to a formula with a little intelligence behind it.
What we need, is for the Javascript to find the correct position to anchor the submenu on the right. We do this by helping the routing understand what the "right side" of the "header" element is.
To find this, we simply take the width of the header, remove from that the left offset of the a-href tag that actually contains the header text (this is in case of any margins that exist - which this has some set in the CSS) and then remove the actual width of the submenu UL tag itself. Now as a sidenote, I wish I didn't have to use something so imprecise as assuming the header is the first child, but... eh... sometimes you work with what you got.
So comment out the line I mentioned above, and put this line in instead:
var menuleft=((header._dimensions.w-header.childNodes[0].offsetLeft)-header._dimensions.subulw);
And from what I see, it should open out towards the left as you were needing it to do in the first place.
Hope this answer helps more than my previous one.
I'm creating a custom select plugin. Everything is going great, but the dropdowns (<ul>-objects) are overlapping on each other :(
I understand, that the overlapping order is set after the elements order on page or when they are created. So my question is: What is the method to make the latest opened/shown object (<ul>) on top of the hierarchy?
I just need the correct method. I'm not going to copy the full code, but a little example:
$('#trigger').click(function () {
new_dropdown.slideDown();
});
(A picture is worth of 1000 words)
So lets say, that I open the green select the last.. How can I make it on top of the yellow one?
EDIT
For easier testing I created jsfiddle. For future references I'll post the link: http://jsfiddle.net/hobobne/uZV5p/1/ This is the live demo of the problem at hand.
What you're looking for is the CSS z-index property (higher values put elements at the front).
You could probably just set them in ascending order (e.g. set green one to 1000, yellow to 1001), but if you really need to bring it to the front when clicked, you can change the z-index with javascript
var zindex=100;
$("#trigger").click( function() {
newdropdown.css('z-index', ++zindex);
});
Here's a demo: http://jsfiddle.net/waitinforatrain/Vf7Hu/ (click the red and blue divs to bring to front).
Edit: gilly3's approach is better, and as was mentioned there may be some issues with older versions of IE.
Two ways:
Set a z-index
Setting a z-index will change the default stacking order. You can have a counter that increments and use that to set the z-index of newly stacked items. You may have issues with IE 7 or earlier, though, and those can be fixed by setting the z-index of other items. https://developer.mozilla.org/en/Understanding_CSS_z-index/Adding_z-index
Use absolute positioning, and append the div to the body
If you use absolute positioning, you can append the div to the body and still have it appear below the element. If you append the div to the body, the one last added should be on top, because of the default stacking order.
Give it a class when it is opened, and remove that class from the previously opened ones:
$(".slidedown_active").removeClass("slidedown_active");
$(this).addClass(".slidedown_active");
Then your users can use z-index in their style definition for that class to ensure the active list is always visible.
The reason I don't recommend setting the z-index directly is because you can mess up your users' layout unnecessarily. These kind of overlap issues can be a real headache for a web developer. For a plugin to try to guess at how to resolve overlap issues, without any knowledge of the code or design, would be virtually impossible. Instead, give your users the tools they need to fix the overlap issues themselves. It may be that your users would never encounter overlap issues, so setting the z-index for them would be pointless at best, and potentially harmful.
I have seen a feature on a site I would like to emulate. I have intermediate php skill but am a novice javascript user. The feature is the site content displayed in divs which can be moved around on the screen and their position saved using cookies. This site: [url]www.nowgamer.com[/url] is where I saw it (latest podcasts, videos, reviews etc with filter)
How would I go about achieving this through javscript? I want to know how to connect javascript with the cookie so that the positions of the square divs are saved, as are the preferences of the content filter on each div. How can I achieve this?
Would this be a big job? Thank you for any help, I am working independently on this in my spare time so your contribution with advice is my lifeline.
As Zoidberg commented, its easy with JQuery or Yui, or any other javascript library that provides drag & drop functionality. They are almost easy to configure, checking at demo they give. They also expose certain events like beforeDrag, afterDrag, onDrop, etc. where you can fire a simple js function check the elements' dropped position store it in cookies. For setting cookies, there are world of code on internet.
Also, you might want to check floating absolute/relative positioning css, if your DOM divs are going to be floating around the page.
GoodLuck.
simplyharsh has the proper answer, but I'd like to expand on it a bit:
The basics of a draggable div aren't too complicated. You attach an onclick handler to initiate the dragging. Internally, that's accomplished by changing the div's CSS so it's position: absolute. Then you start monitoring mouse movements (basically onmousemove) and changing the div's top and left according to the movements you've captured.
Dropping is a bit more complicated. You can always just release the mouse and leave the div wherever you ended up moving it, but that leaves it absolutely positioned and therefore outside of normal document flow. But dropping it "inside" some other element means a lot of prep work.
Because of how mouseover/mouseout/mouseenter events work, they WON'T work while you're dragging an element - you've got your draggable div under the mouse at all times, so there's no mouseenter/leave events being fired on the rest of the page. jquery/mootools and the like work around it letting you specify drop zones. The locations/sizes of these zones are precalculated and as you're dragging. Then, as you're dragging, the dragged object's position is compared to these precalculated drop zone locations for every move event. If you "enter" one of those zones, then internally the libraries fire their mouseenter/mouseleave/mouseover events to simulate an actual mouseenter/leave/over event having occured.
If you drop inside a zone, the div gets attached as a child of that zone. If you drop outside, then it will usually "snap back" to where it was when you initiated the drag.
Resizing is somewhat similar, except you're adjusting height and width instead of top and left.