RESOLVED FIXED 25244
<option> elements inside an <optgroup> are bold on Chromium
https://bugs.webkit.org/show_bug.cgi?id=25244
Summary <option> elements inside an <optgroup> are bold on Chromium
Adam Langley
Reported 2009-04-16 14:14:14 PDT
On Chromium (Windows and Linux) the following is currently misrendered: <select> <optgroup label="Should be bold"> <option>Should not be bold</option> </optgroup> </select> This occurs because the renderStyle of the element is used as the base style for rendering. In html4.css we have: optgroup { font-weight: bolder; } option { font-weight: normal; } However, in themeWin.css: /* Options always use the selects' fonts */ option { font: inherit !important; } This stops the font-weight: normal in html4.css from taking effect. The overriding rule was added in https://bugs.webkit.org/show_bug.cgi?id=24762 because otherwise a differnt font on the <option> could make the text wider than the <select>. This isn't an issue for the <optgroup> as they can't be selected. Because of this we switch Chromium from using the element's style to using the menuStyle() and implementing the bolding in code. platform/mac/PopupMenuMac.mm: uses the itemStyle. However, themeWin.css isn't in play here so everything works out. platform/gtk/PopupMenuGtk.cpp: renders using GTK. Doesn't appear to observe the style or type save for |itemIsEnabled|. platform/win/PopupMenuWin.cpp: uses the menuStyle and handles bold itself. platform/chromium/PopupMenuChromium.cpp: changed in this patch to observe menuStyle() platform/wx/PopupMenuWx.cpp: renders with WX. Doesn't appear to observe the style or type. platform/qt/PopupMenuQt.cpp: code to observe the style is #if 0'ed out
Attachments
patch (3.57 KB, patch)
2009-04-16 14:20 PDT, Adam Langley
adele: review-
patch (2.07 KB, patch)
2009-04-16 15:16 PDT, Adam Langley
no flags
patch (2.12 KB, patch)
2009-04-16 15:17 PDT, Adam Langley
fishd: review+
Adam Langley
Comment 1 2009-04-16 14:20:41 PDT
Adele Peterson
Comment 2 2009-04-16 15:01:53 PDT
Comment on attachment 29550 [details] patch The code change is fine. I don't think those comments belong in html4.css though. If anything, we need a comment in themeWin.css about why we're forcing the font to be inherited. Something like "Option font must be inherited because we depend on computing the size of the <select> based on the size of the options, and they must use the same font for that computation to be correct". I hesitate to say anything about the Changelog, because I think we all usually say too little in the logs, but I think you can probably have a more concise explanation here. This is really an r+, but I'd like you to edit the comments & ChangeLog before you checkin. If you do that, pretty much anyone can give you the final r+. Nice work!
Adam Langley
Comment 3 2009-04-16 15:16:03 PDT
Created attachment 29553 [details] patch (Addressing adele's comments)
Adam Langley
Comment 4 2009-04-16 15:17:14 PDT
Created attachment 29555 [details] patch (missed bug link in the ChangeLog)
Darin Fisher (:fishd, Google)
Comment 5 2009-04-16 15:26:17 PDT
Comment on attachment 29555 [details] patch r+ based on adele's previous comments.
Darin Fisher (:fishd, Google)
Comment 6 2009-04-16 15:29:47 PDT
Note You need to log in before you can comment on or make changes to this bug.