You can clone with
The content you are editing has changed. Reload the page and try again.
Is it possible to have a slider to fill the whole width of a page instead of leaving some dead space to the right?
If not, could this be added as feature?
Phones have a small screen so I would like to use the whole width.
At the moment in landscape mode on my iPhone there is a 30% dead space to the right the slider could fill up to give a better sliding experience.
Attach images by dragging & dropping or
Uploading your images…
Unfortunately, we don't support that file type.
Try again with a PNG, GIF, or JPG.
Yowza, that's a big file.
Try again with an image file smaller than 10MB.
This browser doesn't support image attachments.
We recommend updating to the latest
Google Chrome, or
Something went really wrong, and we can't process that image.
This is something you have control over with CSS and quite rightly should have control over. If you want the slider to take up more space you can change/override the width property in the rule ofdiv.ui-slider which has a default width of 65%. Due to the fact that in the example the number input to the left of the slider widget has a fixed size of 50px the leftover 35% seems bigger when you extend the width of the document by rotating orientation to landscape.
However I do agree that it would be better if by default the slider widget itself were totally fluid and would grow according to how much additional space there is available.
@robschmuecker or @uGoMobi - this might be a good thing to add to the docs as a demo. Accessibly hide the input (or place it on another line) and add CSS overrides to make the slide full width.
I don't see us doing anything else to support this out of the box.
Here is a fiddle with full width sliders without input: http://jsfiddle.net/MauriceG/vyy65/show/light/
@MauriceG - these look really great. I like the tooltips too. Wonder if we could style the input so we can use it to display permament feedback of the value after the label's :
@MauriceG Looks awesome except that you can't input a number with the keyboard.
Or else I would have used that one instead!
Thank you! -- I think to display the sliders value inside the label I need to use scripting.
Here is a version with inputs: http://jsfiddle.net/MauriceG/vyy65/15/show/light/
MauriceG - Using CSS, have the input be on the same line as the label (inline block), then style away the bg and border.
@toddparker -- We'll get that nasty spin buttons on desktop webkit browsers. I'll take a look ...
True, it won't be perfect but maybe we can use webkit-appearance to remedy that
@toddparker -- hold on ...
Great looking work @MauriceG ! They look great with the tooltips ;)
I have made a JSBin with the amendment to the JS (overriding the slider create method) to wrap the input and the slider which allows the slider to be "greedy" and take up all remaining space by default.http://jsbin.com/uzaret/6
This however is somewhat floored when it comes to "hiding" the input as then one would have to manually override some of the CSS due to a margin-left:80px; now having been added to the slider to allow the "greediness" to occur as the "input" has been made as a float:left;.
Let me know what you think.
@toddparker -- http://jsfiddle.net/MauriceG/vyy65/16/show/light/ -- but this is a lot of CSS ...
Nice work on this, cool demos. My opinion is that we should always recommend that the input be there to serve as feedback at the very least so that latest fiddle from MauriceG is a nice demo. The tooltip from the title is a really neat technique, even if it's not widely supported. MauriceG - why is there a tooltip above and value below in that example? Could both of those be nixed now that we style the input as feedback? That would reduce the # of values from 3 to 1.
@robschmuecker - just curious, do we need to use JS at all or does it seem like CSS can be used to achieve this? Better for us to make a demo that doesn't require script changes.
Really looks cool! Nice work guys!
Only reason I see that the JS is needed is if we want to actually change the sliders to be "greedy" out-of-the-box as highlighted by the OP.
TBH I'm not sure why they wouldn't be, especially when given the size of some screens meaning the smaller the slider, the harder it would be to control value effectively.
I also agree think that inputs should be shown as an input by default (albeit one you can hide if need-be) so that one can type a specific value in.
In respect of having an editable input, the solution as shown by @MauriceG here http://jsfiddle.net/MauriceG/vyy65/15/show/light/ demonstrates the same problem I ran into whereby making the slider width:100%; without wrapping it in a container DIV means it will break down off the line which the input is on and the layout isn't as currently intended where the label is on a separate line and then the input and slider on the next.
Also that CSS solution cannot work when someone specifies data-role="fieldcontain" which would break functionality. At least the JS addition of a container/wrapper DIV along with consequent CSS can legislate for all the above.
I feel the only thing that needs addressing codebase wise would be the default greediness of the slider so that it is consistent with all other form elements currently. The other things are great examples of what you "can" do and would be excellent to have as informative examples in the docs.
I'm not even 100% sure that my solution is optimal yet but @uGoMobi did mention that a couple of other elements have a wrapper to make them play nice. I don't want @MauriceG to have to redo all his fine CSS work though!
Let me know your thoughts.
Here is a great demo from @gabrielschulhof
Fix for this is in branch "range" which will be merged soon.
Slider: Made the slider and input together fill full width. Changed c…
…lass ui-slider-mini to ui-mini for consistency. Fixes #5045