I have tried every way I know how (and failed) to properly set the width on a kendoAutoComplete. My latest attempt (below) is JS based, but I've also tried numerous CSS solutions.
The issue I'm seeing is that no matter the width I choose, the actual input area remains a consistent width, and then there is a weird gray area to the right:
Here's the hover state (the gray box disappears):
But don't be fooled by the appearance of a large text box. Here's what happens when you begin to type:
I've tried:
var autoComplete = $("#gridFilter").data("kendoAutoComplete");
autoComplete.list.width(400);
And
autoComplete .wrapper.css("width", "300px");
And...various CSS solutions.
Why must it be so hard to set the width of a silly auto complete? What am I missing here?
I want the width of my auto complete to be 100% to fill its container.
Bonus points if you can help me understand why Telerik consistently makes me want to hurt myself.
EDIT
OK, I've (partially) figured it out. I temporarily removed bootstrap CSS from the page and the input works as expected.
If I find the offending CSS, I'll post an answer here.
As mentioned in the edit above, default Bootstrap CSS was conflicting with the styling. Specifically, the max-width property. The CSS below fixed it:
<input id="gridFilter" style="max-width: 10000px; width:100%;" />
Related
So I've been tinkering with this site, and I've got my work cut out, but right now I cannot for the life of me workout why content is displaying beyond the width of the window.
-redacted-
I believe it's something to do with bootstraps row/col guttering but have been unable to fix it, even with dreaded '!important' use.
Furthermore i note that a carousel button is extending beyond the width of the screen.
This basically just makes the site flimsy and seem broken.
Any css whizz out there able to give me some tips of this shit?
If the problem is with one specific tag (e.g. a <div>), add a class/id to that div with the following CSS: .classname { overflow-x: hidden; If it's the whole page, you might want to do that for the body and HTML tag. Note: When you do this last thing, people aren't able at all to scroll horizontally. This is a but user unfriendly, so you want to use that only if it's the only way out in my opinion.
Check this out:
http://codepen.io/maxwbailey/pen/vGKBr
Now, they look fine when you aren't hovering over them, but when you hover over the <button> and <input> elements, you'll see that the text below them is bumped around a bit, while hovering over the <a> element does not cause the same effect. That's because the <button> and <input> elements are displaying as inline-blocks still (which handle borders, padding, and margins differently than regular inlines), despite the display: inline !important; line that is applied to them.
Is there anyway to override this? I know it's doable via hacks like borders with the same colour as the background, etc. but I'd really like to know if there's a way to make them display: inline properly.
Note: The problem here isn't about the text being bumped around (though that is an effect of it), it's that, despite everything saying otherwise, the browser is still forcing the button to display as an inline-block. Thanks to everyone who's provided methods to prevent the text bumping from happening, but that's not the real problem here.
Thanks!
Not sure the context of why your markup exists like this, but the issue looks like it's being triggered by setting the font-family. If you take a look at this pen - http://codepen.io/pnts/pen/Egwuo - the hover works fine without a font-family specified, but if you uncomment the line specifying one, the jumping begins.
It seems your question is a little misleading. Your button tag IS in fact set to display:inline on both normal and hover states. It sounds like the question you have is how to prevent the text below from getting bumped down on rollover. Instead of using a bottom border as you are currently, why not use the following in the hover state to achieve the underline?
text-decoration:underline;
agree with the previous answer, however if you want the flexibility of a border, being able to use padding to adjust where it lays etc, you could use
border:1px solid transparent;
not as hacky as using the same color as you bg because it doesn't matter the color of the background that way.
I am seeking some advice regarding unnecessary scrollbars appearing on certain form items. A screenshot of the issue appears below. Note it is the right-most scrollbar that is unnecessary.
bad_scrollbars http://img21.imageshack.us/img21/9307/scrollfu.png
The culprit appears to be the following css, adding overflow: auto; to form items within windows in gecko-based browsers (the problem appears on Firefox):
.ext-gecko .x-window-body .x-form-item {
outline: medium none;
overflow: auto;
}
Removing this style solves the problem, but I am wary of possible side effects - though I haven't noticed any as yet, this style was obviously included for a reason.
Does anyone who knows more about Ext styling know if overriding this css to remove the overflow: auto; style will cause other problems?
As an aside, this is only an issue (so far) with a certain component - a custom extension of the Ext.ux.form.MultiSelect component - even though other components use more vertical space. Does anyone know of a possible reason for this?
Thanks for any help.
overflow: auto tells the browser to add a scrollbar to the element if the content of the element is larger than the elements client area minus any padding. Getting rid of the scrollbars in CSS does exactly that. It makes the scrollbars go away, no matter what.
The side effect of your work around is if there is content outside of the client, the use will not be able to see it. Additionally, this will not only happen with this form but every form in your application unless you apply your workaround in a custom class.
The right fix is to figure out why your content area is larger than the form's client area. Firebug can be a big help with this as you can inspect the DOM and see the size of the container as well as the size of all the child items.
I suspect that your clear selections control (is this a custom control?) is not properly sizing itself (i.e in your form layout you're telling it to be x pixels high but it's actually sizing itself x+1 (remember margins and padding). The form layout is doing all the work to decide how big to make the wrapper area (the area with the scroll bar) and the control must fit within that area.
So I'm inspecting this site: http://www.grittirollo.it/ and it appears that the content that slides out has a fixed height. Is there no way to set this dynamically?
It appears as though the developer measured out how tall each portion of the sliders' box model would be when rendered, and then multiplied it by how many rows there were. From there, he/she set it manually in the CSS.
Elements on a webpage can typically be measured with their scrollHeight JavaScript property (element.scrollHeight) however some browsers don't have this and some browsers do it differently from others. (I believe Firefox's has to be done recursively down the tree of elements and Safari just uses the outermost element.) This should be possible without manually setting the height using JavaScript, you just may have to conditionally code it to work with all the browsers you want to support.
I don't see why it's necessary to set it dynamically. If the stuff is float:left; and they put a <div class="clear"> at the bottom of a hide-able section, you would be able to see the contents of that section when it was un-hidden with JavaScript. You could then adjust the layout with padding and margin to make it look pretty.
Or, they could have also used position:relative; and position:absolute; to layout the hide-able sections. It comes down to preference.
I'm new to this site and thought I might give it a shot. I've been having a problem for quite some time now but as my project evolved other problems was solved, but this has remained. And finding the right thing wasn't easy. Im not even sure what the term is for this kind of thing.
Anyway, I want a background image to the right and left of my main page. It need to be z-indexed below the actual page(incase people with low resolutions view the page) so that it doesn't extend over the main page and makes the content unreadable. It needs to go below the actual page if low resolutions are used.
I've been using the following code to do the work for me right now:
<img style="position: absolute; top: 120px; left: 10px; width: 121px; height: 443px; z-index: -1;" src="../admin/images/background_text.png">
Problem is that this isn't working to good with older versions of IE for example and in some cases not at all in others. As you can see it has a set position on my page(left side its higher up on the page) which is also something I want to achieve.
I hope I explained this good enough and cheers to this site. Seems like a great place to find solutions.
Cheers, Martin.
Try this:
<body style="background: url('../admin/images/background_text.png') 120px 10px;" > rest of the page...
this sets the background for the whole page (what it seems kind of like you're doing?) to the given image.
I would also size your image to the desired size if it isn't already, then you don't need to supply width and height (or worry about IE rendering the resize).
if you're really just putting it on the side, I might use a table or div setup and set the background on that (not knowing how your page is setup).
Im not sure if i understand your question or not.
Anyway. Dont set your z-index on the image. I would set position relative on the layers that needed to be at the top.
Remember that IE6 dont get the z-index. It figures out which comes first and then its the last one that is on top, even though it haves a lower z-index.
Here's an improved answer for you:
Give your "wrapper" div the background image as described before. Then extend your main table all the way to the right (or wrap it in another table or div with 100% width) and give that the right side background image. Then the images are still behind all the content and they both should behave as you want them to.
if you need more info on the background css attribute, check out the WDG page