Current <meter> change its appearance based on its dimension. But such kind of style-determined-by-layout behavior is tricky to implement and may (and did) cause some layout instability. (See https://lists.webkit.org/pipermail/webkit-dev/2011-March/016140.html) Instead of this dynamic appearance switching, WebKit should provide the way to choose the visual direction by styles. Because text-direction is used to switch its visual between rtl and ltr, writing-mode looks a good candidate for the knob. Why don't provide two separate -webkit-appearance (like meter-vertical and meter-horizontal)? Because WebKit allows user-styling for form controls via pseudo classes like -webkit-meter, and this user-style is enabled by specifying "-webkit-appearance: none". Here we already use -webkit-appearance, thus cannot give meter-vertical appearance for it.
What do you think about adding a whole new CSS property? writing-mode still seems to say not quite what we mean.
I don't think writing-mode is the right property to use.
Created attachment 85292 [details] Patch
Hi Dimitri, could you take a look? This is a preparation for making <meter> new-shadowish.
(In reply to comment #4) > Hi Dimitri, could you take a look? > This is a preparation for making <meter> new-shadowish. Given that Simon also thinks that writing-mode is the right approach, perhaps we should have a quick discussion first.
(In reply to comment #5) > (In reply to comment #4) > > Hi Dimitri, could you take a look? > > This is a preparation for making <meter> new-shadowish. > > Given that Simon also thinks that writing-mode is NOT the right approach, perhaps we should have a quick discussion first.
Yeah writing-mode is really not the correct approach here.
Comment on attachment 85292 [details] Patch Can't use writing-mode like this. That isn't what it is for at all.
Meters orientation should just have to be explicitly specified IMO. We need to just get that fixed in the standard.
like <meter orientation="vertical">?
(In reply to comment #9) > Meters orientation should just have to be explicitly specified IMO. We need to just get that fixed in the standard. After talking with Hixie, he's suggesting adding "-webkit-direction" (or similar) CSS property instead. WDYT?
The auto-orientation capability is similar to how Cocoa's NSSlider control automatically picks the best orientation (see its isVertical API). It increases the odds that people will make pretty pages. I think -webkit-direction should have three values, 'auto' (the initial value, implementing the spec), and 'horizontal' and 'vertical' (which force a particular direction). Maybe -webkit-control-direction to avoid confusion with 'direction'.
Sorry for coming late and making the patch before reading simon's comment. (I just missed it...) Okay, I'm going to introduce -webkit-control-direction. The original intention to make direction explicit is that eliminate "auto"-like behavior because it requires layout to determine direction, that causes complicated situation. So I think it's OK to make the default value "horizontal" because there is no vertical meter indicator for native controls.
(In reply to comment #13) > Sorry for coming late and making the patch before reading simon's comment. (I just missed it...) > > Okay, I'm going to introduce -webkit-control-direction. > The original intention to make direction explicit is that eliminate "auto"-like behavior > because it requires layout to determine direction, that causes complicated situation. > So I think it's OK to make the default value "horizontal" because > there is no vertical meter indicator for native controls. Hang on, hang on -- the discussion isn't over yet. Let Hyatt chime in.
FYI I would prefer the name to contain 'orientation' rather than 'direction'. I'm still not sure that a normal property is the correct approach here. Maybe a pseudoclass?
(In reply to comment #15) > FYI I would prefer the name to contain 'orientation' rather than 'direction'. I'm still not sure that a normal property is the correct approach here. Maybe a pseudoclass?
(In reply to comment #16) > (In reply to comment #15) > > FYI I would prefer the name to contain 'orientation' rather than 'direction'. I'm still not sure that a normal property is the correct approach here. Maybe a pseudoclass? (In reply to comment #15) > FYI I would prefer the name to contain 'orientation' rather than 'direction'. I'm still not sure that a normal property is the correct approach here. Maybe a pseudoclass? Sorry for double-posting. A pseudoclass wouldn't be enough, since it doesn't allow us to set the orientation by itself. Or perhaps I am misunderstanding... Can you pseudocode the pseudoclass idea for me?
How about to ask whatwg@ for dropping vertical meter from the spec? There is no vertical meter/indicator on any platform and Opera, which is the only browser that supports <meter> other than WebKit, also doesn't support it.
(In reply to comment #18) > How about to ask whatwg@ for dropping vertical meter from the spec? > There is no vertical meter/indicator on any platform and > Opera, which is the only browser that supports <meter> other than WebKit, also doesn't support it. Let's go with this notion for now. Implement horizontal only. We'll figure out what to do with spec later.
Created attachment 87660 [details] Patch
Hi Dimitri, thank you for the suggestion! > Let's go with this notion for now. Implement horizontal only. We'll figure out what to do with spec later. So I removed vertical related code. It got simpler now.
Comment on attachment 87660 [details] Patch this should become even simpler once you switch it to the shadow DOM.
Created attachment 87746 [details] Patch
Comment on attachment 87746 [details] Patch Oops. I intended to land it...
Committed r82589: <http://trac.webkit.org/changeset/82589>
http://trac.webkit.org/changeset/82589 might have broken Qt Linux Release The following tests are not passing: fast/dom/HTMLMeterElement/meter-boundary-values.html fast/dom/HTMLMeterElement/meter-optimums.html fast/dom/HTMLMeterElement/meter-styles-changing-pseudo.html fast/dom/HTMLMeterElement/meter-styles.html
I'm rolling out this patch because it turned many bots red and the author did not appear to be available to help repair them.
Created attachment 87863 [details] Added skip list entries that need expectation update.
Comment on attachment 87863 [details] Added skip list entries that need expectation update. let's try again.
Committed r82686: <http://trac.webkit.org/changeset/82686>
http://trac.webkit.org/changeset/82686 might have broken Windows 7 Release (Tests) The following tests are not passing: fast/dom/HTMLMeterElement/meter-appearances-capacity.html fast/dom/HTMLMeterElement/meter-appearances-rating-relevancy.html