<meter> should allow styling using CSS like <progress> does.
> <meter> should allow styling using CSS like <progress> does.
I think we should have 8 pseudo classes.
- Please update the base WebKit revision. Style bot and EWS are really helpful.
+          - Disabled pixel tests for HTMLMeterElement is temporality disabled.
This sentence looks curious.  Maybe either of "disabled" is not needed?
What's the intention of this setTimeout()?
We should have a test for this.  e.g.
and the meter value is just a half.
Can we merge this into RenderTheme::isControlStyled()?
I missed some point from the last review. will re-submit.
>   - Please update the base WebKit revision. Style bot and EWS are really helpful.
Ah, I remember svn-apply doesn't support git binary diff.  So the style bot and EWS don't work for your patch.
Please make sure your patch doesn't have style errors before uploading.
Hi Kent-san, thank you for reviewing!
>  +          - Disabled pixel tests for HTMLMeterElement is temporality disabled.
> This sentence looks curious.  Maybe either of "disabled" is not needed?
> What's the intention of this setTimeout()?
On writing it, I'd like to make sure that rendering is done, though I realized that it's useless.
OK, remove the line from Skipped file.
Oops. I'll sort it before landing because sorting tend to cause a conflict.
> We should have a test for this.  e.g.
> and the meter value is just a half.
Added a test to meter-style.html.
> Can we merge this into RenderTheme::isControlStyled()?
But I agree that canPaintControlsFor() is over-generalized.
So I removed it and added supportsHorizontalMeter() instead.
> > Can we merge this into RenderTheme::isControlStyled()?
> But I agree that canPaintControlsFor() is over-generalized.
> So I removed it and added supportsHorizontalMeter() instead.
Could you explain the reason why it can't?
> > > Can we merge this into RenderTheme::isControlStyled()?
> > No, It cannot.
> > But I agree that canPaintControlsFor() is over-generalized.
> > So I removed it and added supportsHorizontalMeter() instead.
> Could you explain the reason why it can't?
- We need a RenderObject to refer the layout result, but isControlStyled() doesn't have it.
Because it is called before RenderObjects creation.
- isControlStyle() requires extra arguments like BorderData which are not available for us.
- RenderTheme::adjustStyle() rewrites RenderStyle::m_appearance based on the result of isControlStyled().
But we want to preserve the original appearance value always for <meter>.
canPaintControlsFor() is based on the layout result.
> > Could you explain the reason why it can't?
> - We need a RenderObject to refer the layout result, but isControlStyled() doesn't have it.
>    Because it is called before RenderObjects creation.
> - isControlStyle() requires extra arguments like BorderData which are not available for us.
> - RenderTheme::adjustStyle() rewrites RenderStyle::m_appearance based on the result of isControlStyled().
>    But we want to preserve the original appearance value always for <meter>.
> canPaintControlsFor() is based on the layout result.
I see.  <meter> always has width/height information in its style, but they may be relative.  e.g. height:50%. So we can't detect horizontal/vertical in adjustStyle()-isContrlStyled().
Need a comment why setTimeou() is used.
Do you want to confirm the value change updates the element style?
if so, .offsetWidth may help to force repainting.
WebKit should reset -webkit-appearance automatically if an element has user-specified style, like <progress>.
is specified, -webkit-appearance for <meter id=id1> should be reset automatically.  However, I don't have no idea how to implement it.
supportsHorizontalMeter() should have a ControlPart parameter because a platform might support just one or two of the three indicator appearances.
> However, I don't have no idea how to implement it.
I meant "I don't have good idea how to implement it."
> Need a comment why setTimeou() is used.
> Do you want to confirm the value change updates the element style?
> if so, .offsetWidth may help to force repainting.
Fixed to remove setTimeout() and force repaint by touching style object.
> WebKit should reset -webkit-appearance automatically if an element has user-specified style, like <progress>.
> is specified, -webkit-appearance for <meter id=id1> should be reset automatically.
Done. tests are also updated.
> This line should be removed.
> supportsHorizontalMeter() should have a ControlPart parameter because a platform might support just one or two of the three indicator appearances.
Other platforms might support themes for vertical meters.
Hi, thank you for reviewing!
> Other platforms might support themes for vertical meters.
Please commit this when the bots status are good.
Watch test bots results and correct test expectations if problems occur. See  for Chromium tests.
This broke a test on Gtk.
> This broke a test on Gtk.
Which one?  I couldn't figure out that.
It seems a successive checkin overrides the waterfall status.
I'm watching the tree a while, anyway.