Bug 37901

Summary: Allow styling of HTMLProgressElement.
Product: WebKit Reporter: Yael <yael>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: adele, commit-queue, jamesr, tonikitoo
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
Patch.
none
Patch to add support in isControlStyled none

Yael
Reported 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.
Attachments
Patch. (35.59 KB, patch)
2010-04-20 17:28 PDT, Yael
no flags
Patch to add support in isControlStyled (36.43 KB, patch)
2010-04-21 12:16 PDT, Yael
no flags
Yael
Comment 1 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.
Yael
Comment 2 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.
Kent Tamura
Comment 3 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.
Yael
Comment 4 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.
Yael
Comment 5 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?
Adele Peterson
Comment 6 2010-04-21 10:26:21 PDT
Each control makes that decision separately in the isControlStyled method in each RenderTheme class.
Yael
Comment 7 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.
Adele Peterson
Comment 8 2010-04-24 11:13:20 PDT
Comment on attachment 53979 [details] Patch to add support in isControlStyled Looks good!
WebKit Commit Bot
Comment 9 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>
WebKit Commit Bot
Comment 10 2010-04-25 06:52:33 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.