Bug 37901 - Allow styling of HTMLProgressElement.
Summary: Allow styling of HTMLProgressElement.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-20 16:33 PDT by Yael
Modified: 2010-04-25 06:52 PDT (History)
4 users (show)

See Also:


Attachments
Patch. (35.59 KB, patch)
2010-04-20 17:28 PDT, Yael
no flags Details | Formatted Diff | Diff
Patch to add support in isControlStyled (36.43 KB, patch)
2010-04-21 12:16 PDT, Yael
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yael 2010-04-20 16:33:12 PDT
Users of the <progress> element should be able to customize the element if they wish.
A patch should be added shortly.
Comment 1 Yael 2010-04-20 17:28:55 PDT
Created attachment 53908 [details]
Patch.

Added a new pseudo element to represent the value portion of the progress element.
Comment 2 Yael 2010-04-20 18:00:11 PDT
Seems there is a problem in the style bot that causes it to mark the style check as failed.
Comment 3 Kent Tamura 2010-04-20 19:23:14 PDT
Comment on attachment 53908 [details]
Patch.

Page authors can specify style for the existing form controls like:
    #input1 { border-color: red; }
Such style declarations automatically turn off -webkit-appearance. (See RenderTheme::isControlStyled and adjustStyle)
We should follow this for <progress> too.

Introducing -webkit-progress-bar-value and exposing it to page authors might be inevitable.
Comment 4 Yael 2010-04-21 05:55:11 PDT
(In reply to comment #3)
> (From update of attachment 53908 [details])
> Page authors can specify style for the existing form controls like:
>     #input1 { border-color: red; }
> Such style declarations automatically turn off -webkit-appearance. (See
> RenderTheme::isControlStyled and adjustStyle)
> We should follow this for <progress> too.
> 
> Introducing -webkit-progress-bar-value and exposing it to page authors might be
> inevitable.

Thank you for the information , Kent.
I think there should be a decision if to require "-webkit-appearance: none;" or not. We don't want some elements to require it, and some not.
Comment 5 Yael 2010-04-21 08:03:52 PDT
After thinking about this some more, I am not sure if it is a good idea.
People may want to set e.g. the width and the height of a <progress> element while keeping the look of a native widget (-webkit-appearance).
Maybe there are other styles that can be applied while keeping the look of a native widget, so where do you draw the line?
Comment 6 Adele Peterson 2010-04-21 10:26:21 PDT
Each control makes that decision separately in the isControlStyled method in each RenderTheme class.
Comment 7 Yael 2010-04-21 12:16:06 PDT
Created attachment 53979 [details]
Patch to add support in isControlStyled

Adding border and/or background would now automatically remove the -webkit-appearance from the progress bar.
Also updated the new test to test this behavior.
Comment 8 Adele Peterson 2010-04-24 11:13:20 PDT
Comment on attachment 53979 [details]
Patch to add support in isControlStyled

Looks good!
Comment 9 WebKit Commit Bot 2010-04-25 06:52:28 PDT
Comment on attachment 53979 [details]
Patch to add support in isControlStyled

Clearing flags on attachment: 53979

Committed r58228: <http://trac.webkit.org/changeset/58228>
Comment 10 WebKit Commit Bot 2010-04-25 06:52:33 PDT
All reviewed patches have been landed.  Closing bug.