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

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jonathan Watt [:jwatt]]

We need to decide how we want to allow content authors to get a vertical <input type=range>.

Comment 1

[Mounir Lamouri (:mounir)]

The discussion should happen in the www-style mailing list mostly.

Comment 2

[Jonathan Watt [:jwatt]]

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

[Daniel Holbert [:dholbert]]

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

[Mounir Lamouri (:mounir)]

Jonathan, I think we should really get a discussion started in www-style to get opinions on that topic.

Comment 5

[Jonathan Watt [:jwatt]]

www-style discussion is here: http://www.w3.org/mid/[e-mail]

Comment 6

[Jonathan Watt [:jwatt]]

Attachment: patch to act on attribute orient="vertical"

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

Comment 7

[Jonathan Watt [:jwatt]]

(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!

Comment 8

[Jonathan Watt [:jwatt]]

Attachment: patch to act on attribute orient="vertical"

Comment 9

[Mounir Lamouri (: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.

Comment 10

[Jonathan Watt [:jwatt]]

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

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e9d5a162fa35

Comment 12

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Followup to make it <input vertical>?

Comment 13

[Mounir Lamouri (:mounir)]

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

Comment 14

[Jonathan Watt [:jwatt]]

Attachment: patch that would have done the auto sizing thing

Just for the record, this is the patch that would have done the auto sizing thing.

Comment 15

[Jim Michaels]

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

Comment 16

[Jonathan Watt [:jwatt]]

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

[fraph24]

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

Comment 18

[fraph24]

I think it should used -moz-orient: https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-orient

Comment 19

[Eric Shepherd [:sheppy]]

Once this is sorted out, we need to update the docs.

Comment 20

[Chris Mills [:cmills]]

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