Decide how we want to allow content authors to get a vertical <input type=range>

RESOLVED FIXED in mozilla22

Status

()

defect
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: jwatt, Assigned: jwatt)

Tracking

(Depends on 1 bug, {dev-doc-complete})

Trunk
mozilla22
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Assignee

Description

6 years ago
We need to decide how we want to allow content authors to get a vertical <input type=range>.
The discussion should happen in the www-style mailing list mostly.
Assignee

Updated

6 years ago
Blocks: 841950
Assignee

Comment 2

6 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.
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.
Jonathan, I think we should really get a discussion started in www-style to get opinions on that topic.
Assignee

Comment 5

6 years ago
www-style discussion is here: http://www.w3.org/mid/514A17D4.3070806@jwatt.org
Assignee

Comment 6

6 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

6 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

6 years ago
Attachment #728988 - Attachment is obsolete: true
Attachment #728988 - Flags: review?(mounir)
Attachment #729004 - Flags: review?(mounir)
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

6 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.
https://hg.mozilla.org/mozilla-central/rev/e9d5a162fa35
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Followup to make it <input vertical>?
(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

6 years ago
Attachment #729004 - Flags: checkin+
Assignee

Comment 14

6 years ago
Just for the record, this is the patch that would have done the auto sizing thing.
Attachment #731079 - Flags: checkin-

Comment 15

6 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

6 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.

Updated

5 years ago
Depends on: 981916

Comment 17

5 years ago
Setting orientation using CSS, as IE and Webkit/Blink do, would be far better.

Comment 18

5 years ago
I think it should used -moz-orient: https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-orient
Once this is sorted out, we need to update the docs.
Keywords: dev-doc-needed
(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.
You need to log in before you can comment on or make changes to this bug.