[webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit

[Dimitri Glazkov]

Dear WebKit,

It seems we have a bit of a conundrum with spec-conforming element
rendering. The http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-meter-element-0,
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0,
and http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-input-element-as-a-range-control
all state something along these lines:

"When the control is wider than it is tall (or square), the control is
expected to be a horizontal slider, with the lowest value on the right
if the 'direction' property on this element has a computed value of
'rtl', and on the left otherwise. When the control is taller than it
is wide, it is expected to be a vertical slider, with the lowest value
on the bottom."

How shall we accomplish this?

Today, we happily use -webkit-appearance to apply platform-specific
appearance to the controls. The trouble is, the value of
-webkit-appearance is going to be different depending on the value of
logical width.

For example, consider <input type=range style="width: 100%; height: 200px">

http://jsfiddle.net/dglazkov/qmnKN/1/embedded/result/

If the logical width of the control is over 200px, the property
-webkit-appearance: sliderthumb-horizontal applies to it.

As you size the window down, at the point where the width of the
control is less than 200px, the property -webkit-appearance:
sliderthumb-vertical should start apply to it.

One could imagine something like this for a set of rules to describe this:

input[type=range]:horizontal::-webkit-slider-thumb {
    -webkit-appearance: sliderthumb-horizontal;
}

input[type=range]:vertical::-webkit-slider-thumb {
    -webkit-appearance: sliderthumb-vertical;
}

where "horizontal" and "vertical" pseudo-classes are applied according
to logical width/height ration of the control box. This seems gross,
since we'll need to create a new rendering primitive
(RenderGrossOrientationAwareBox?), which re-matches style during
layout, as early as the logical width of a box can be determined.

Tab pointed out to me that introducing something like this would also
be a bad idea, since the logical width/height ration may be affected
by the newly-re-matched rules:

foo:vertical {
    width: 100000000px; /* no longer vertical */
}

So it sucks. Please help with better ideas?

Our options:

a) add a gross hack in layout for these elements to re-match style
after calculating logical width
b) do something even grosser.
c) do something more brilliant.
d) not implement this part of the spec.

P.S. This is a continuation of discussion on
https://bugs.webkit.org/show_bug.cgi?id=54440.

:DG<