Closed
Bug 840820
Opened 11 years ago
Closed 11 years ago
Decide how we want to allow content authors to get a vertical <input type=range>
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla22
People
(Reporter: jwatt, Assigned: jwatt)
References
(Depends on 1 open bug)
Details
(Keywords: dev-doc-complete)
Attachments
(2 files, 1 obsolete file)
5.88 KB,
patch
|
mounir
:
review+
jwatt
:
checkin+
|
Details | Diff | Splinter Review |
1.98 KB,
patch
|
jwatt
:
checkin-
|
Details | Diff | Splinter Review |
We need to decide how we want to allow content authors to get a vertical <input type=range>.
Comment 1•11 years ago
|
||
The discussion should happen in the www-style mailing list mostly.
Assignee | ||
Comment 2•11 years ago
|
||
If we keep the argument to nsRangeFrame::IsHorizontal, then we should decide here whether that fallback rect should be the border box, or the content box. dholbert argues for the content box in bug 842179 comment 4, and I think I agree.
Comment 3•11 years ago
|
||
Also, we should decide IsHorizontal should itself use the content box or border box, internally (when it's not using the fallback rect). I'd imagine we should be following the same strategy, regardless of whether we're using the fallback rect or our frame's actual current rect.
Comment 4•11 years ago
|
||
Jonathan, I think we should really get a discussion started in www-style to get opinions on that topic.
Assignee | ||
Comment 5•11 years ago
|
||
www-style discussion is here: http://www.w3.org/mid/514A17D4.3070806@jwatt.org
Assignee | ||
Comment 6•11 years ago
|
||
So far the only suggestion on www-style is to use an attribute, which happens to be my preferred solution (although not one I mentioned to the list). Of the two conflicting use cases (see the www-style discussion, comment 5, for why the conflict): * Allow content authors/libraries to use CSS selectors to select horizontal/ vertical range and apply different styles * Allow content authors to specify whether a range should be vertical using CSS I think the former is more useful. I can't realistically imagine a user interface where you'd want the orientation of a slider flip (that is, I believe the orientation will be fixed by the design), but I can certainly see a very real need to be able to style the range differently depending on whether it's horizontal or vertical (again, see the www-style discussion).
Attachment #728988 -
Flags: review?(mounir)
Assignee | ||
Comment 7•11 years ago
|
||
(In reply to Jonathan Watt [:jwatt] from comment #6) > .. but I can certainly > see a very real need to be able to style the range differently depending on > whether it's horizontal or vertical (again, see the www-style discussion). One important case in point being our own forms.css default styling!
Assignee | ||
Comment 8•11 years ago
|
||
Attachment #728988 -
Attachment is obsolete: true
Attachment #728988 -
Flags: review?(mounir)
Attachment #729004 -
Flags: review?(mounir)
Comment 9•11 years ago
|
||
Comment on attachment 729004 [details] [diff] [review] patch to act on attribute orient="vertical" Review of attachment 729004 [details] [diff] [review]: ----------------------------------------------------------------- r=me with the follow-up filed ;) And please, send something to the WHATWG and bonus points if you can think of a solution that fixes <progress> and <meter> :) ::: layout/forms/nsRangeFrame.cpp @@ +557,5 @@ > > bool > nsRangeFrame::IsHorizontal(const nsSize *aFrameSizeOverride) const > { > + nsHTMLInputElement *element = static_cast<nsHTMLInputElement*>(mContent); nit: Foo* bar = blah; @@ +559,5 @@ > nsRangeFrame::IsHorizontal(const nsSize *aFrameSizeOverride) const > { > + nsHTMLInputElement *element = static_cast<nsHTMLInputElement*>(mContent); > + return !element->AttrValueIs(kNameSpaceID_None, nsGkAtoms::orient, > + nsGkAtoms::vertical, eCaseMatters); Maybe we should back out the patch that adds 'auto'? Could you file a follow-up for that? ::: layout/style/forms.css @@ +763,5 @@ > > +input[type=range][orient=vertical]::-moz-range-track { > + border-left: solid 0.1em lightgrey; > + border-right: solid 0.1em lightgrey; > + background-color: grey; This doesn't seem to be needed (bg-color). Also, generally speaking, shouldn't you have a common rule for input[type='range'], another for input[type='range']::-moz-range-track and then each of those will have two "children" rules for orient=vertical and orient!=vertical. BTW, we have border-top and border-bottom properties from the general range-track rule.
Attachment #729004 -
Flags: review?(mounir) → review+
Assignee | ||
Comment 10•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e9d5a162fa35 (In reply to Mounir Lamouri (:mounir) from comment #9) > And please, send something to the WHATWG http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0268.html > and bonus points if you can think > of a solution that fixes <progress> and <meter> :) Add an "orient" attribute to them too, I'd have thought. > Maybe we should back out the patch that adds 'auto'? Could you file a > follow-up for that? I think that's a bit premature to backout until we've seen the result of the whatwg discussion, but I filed bug 854884 for that. > This doesn't seem to be needed (bg-color). Removed. > Also, generally speaking, shouldn't you have a common rule for > input[type='range'], another for input[type='range']::-moz-range-track and > then each of those will have two "children" rules for orient=vertical and > orient!=vertical. I don't think it really matters. Personally I find it easier to have the "normal" block, then the "other" case as overrides. (Two blocks rather than three.) That's what I checked in, but if you want to change it I don't feel so strongly that I'd object. > BTW, we have border-top and border-bottom properties from the general > range-track rule. I added overrides.
Comment 11•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e9d5a162fa35
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Comment 12•11 years ago
|
||
Followup to make it <input vertical>?
Comment 13•11 years ago
|
||
(In reply to :Ms2ger from comment #12) > Followup to make it <input vertical>? I do not believe a boolean attribute is the correct solution. See my reply to the thread.
Assignee | ||
Updated•11 years ago
|
Attachment #729004 -
Flags: checkin+
Assignee | ||
Comment 14•11 years ago
|
||
Just for the record, this is the patch that would have done the auto sizing thing.
Attachment #731079 -
Flags: checkin-
Comment 15•11 years ago
|
||
possibly you also have to be able to handle rotation with css? I don't know how the whole CSS transform:scale();+transform:rotate(); thing is handled. you might want to look that up IF any of that even applies here. there was I think also a way to CSS3 vertically align text, but I don't think that's implemented yet by anyone. my attempts for that were on this page: http://Jesusnjim.com/common/vertical-text.html
Assignee | ||
Comment 16•11 years ago
|
||
CSS transforms apply a purely visual affect and do not affect page layout. Authors would almost always want a change in range orientation to affect the layout of other page elements around them, so CSS transforms would not in general be an appropriate mechanism for creating a vertical range. I don't think using the mechanism for vertical text would be appropriate either, since authors then couldn't use selectors to apply different styling to vertical vs horizontal ranges.
Comment 17•10 years ago
|
||
Setting orientation using CSS, as IE and Webkit/Blink do, would be far better.
Comment 18•10 years ago
|
||
I think it should used -moz-orient: https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-orient
Comment 19•7 years ago
|
||
Once this is sorted out, we need to update the docs.
Keywords: dev-doc-needed
Comment 20•7 years ago
|
||
(In reply to Eric Shepherd [:sheppy] from comment #19) > Once this is sorted out, we need to update the docs. It looks like you have documented how to do this in the <input type="range"> ref page: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range#Change_the_orientation So I'm setting this to ddc. Feel free to set it back if more changes are needed.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•