842028 - Add a reftest for <input type="range" style="height:auto">

Status: NEW

(Core :: DOM: Forms, defect)

Description

[Jonathan Watt [:jwatt]]

Follow-up from bug 838256 comment 23. We should add a reftest (or crashtest?) for <input type="range" style="height:auto">. I'm not sure exactly what the behavior should be, or how to cover that in a reftest other than with a != test. Any thoughts, Daniel?

Comment 1

[Mounir Lamouri (:mounir)]

Shouldn't it behave like a span would?

Comment 2

[Daniel Holbert [:dholbert]]

From some local testing -- it looks like height:auto makes <input> and <progress> elements use their default height -- they behave as if height were unspecified.

We should probably be consistent with that behavior, rather than ending up at 0-height.  (0-height is better than huge-height, but consistency w/ other similar elements is better still. :))

That conversion might already happen somehow before we even get to range-frame reflow -- not sure how, offhand, but I wouldn't be too surprised.  But we need to make sure it happens & have a test for it, either way.

Maybe this bug should be morphed to that behavior-change (if we don't already have that behavior), and it can include a reftest checking the new behavior?

Comment 3

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> From some local testing -- it looks like height:auto makes <input> and
> <progress> elements use their default height -- they behave as if height
> were unspecified.

Well, what it does is use whatever ComputeAutoSize returns, which for both frame types is 1em.

Is everyone happy that that's the behavior that we want before I write tests for it (I am)?

Comment 4

[Mounir Lamouri (:mounir)]

CCing layout ppl who might have an opinion.

Comment 5

[Mounir Lamouri (:mounir)]

(In reply to Jonathan Watt [:jwatt] from comment #3)
> (In reply to Daniel Holbert [:dholbert] from comment #2)
> > From some local testing -- it looks like height:auto makes <input> and
> > <progress> elements use their default height -- they behave as if height
> > were unspecified.
> 
> Well, what it does is use whatever ComputeAutoSize returns, which for both
> frame types is 1em.

<progress> and <meter> are requested to be 1em height be default per HTML specification [1][2].

> Is everyone happy that that's the behavior that we want before I write tests
> for it (I am)?

I guess we should define the default size we want. We should probably check what other vendors do and see if we can add that to the standards. I would be fine with 1em FWIW.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-meter-element-0

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #3)
> Well, what it does is use whatever ComputeAutoSize returns, which for both
> frame types is 1em.

Ah, of course.

> Is everyone happy that that's the behavior that we want before I write tests
> for it (I am)?

I am, yeah. (Part of me thinks we should shrinkwrap the thumb & track height, but I'm not sure it's worth it, and it would also be inconsistent with our <progress> behavior.)

Side-note: is there any good reason that the HTML5 spec mandates a default height for <progress>, but says nothing about the height of <input type="range">?  The elements seem pretty similar to me, aside from the fact that one is interactive and the other isn't.

Comment 7

[Mounir Lamouri (:mounir)]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> Side-note: is there any good reason that the HTML5 spec mandates a default
> height for <progress>, but says nothing about the height of <input
> type="range">?  The elements seem pretty similar to me, aside from the fact
> that one is interactive and the other isn't.

The only reason I can see is that <input> height already doesn't take into account the font size so I guess having <input type='range'> behaving differently might be weird or even break some websites.

If we want to be consistent with other implementations, we should simply keep the same behaviour as <input type='text'>. I will try to raise the subject on WHATWG though.