Make styling work in new search fields. <rdar://problem/4863832> <input type="search"> fields should be style-able too
*** Bug 21238 has been marked as a duplicate of this bug. ***
I will look into adding the missing styling support and hopefully propose a patch for this soon.
I think you can now fully style the search field by using standard styling techniques and these pseudo-elements: ::-webkit-input-placeholder ::-webkit-search-cancel-button ::-webkit-search-decoration ::-webkit-search-results-decoration ::-webkit-search-results-button
(In reply to comment #3) > I think you can now fully style the search field by using standard styling > techniques and these pseudo-elements: > > ::-webkit-input-placeholder > ::-webkit-search-cancel-button > ::-webkit-search-decoration > ::-webkit-search-results-decoration > ::-webkit-search-results-button According to my test, bug 21238 which has been duplicated to this is still reproducible. That means that setting the style element on a "Search" type input behaves differently then on a "Text" type input which it should not acording to my interpretation of the standard.
Can you reference what part of the standard implies that? They are two different controls, so I don't see a problem with the styling requirements being slightly different. That said, on a platform that doesn't treat them as different controls, all the normal styling should work in the same way. On the Mac, the default search control just doesn't support the same kinds of arbitrary styling as a regular text field.
(In reply to comment #5) > Can you reference what part of the standard implies that? They are two > different controls, so I don't see a problem with the styling requirements > being slightly different. That said, on a platform that doesn't treat them as > different controls, all the normal styling should work in the same way. On the > Mac, the default search control just doesn't support the same kinds of > arbitrary styling as a regular text field. I was referring to section 4.10.5.1.2 of the HTML5 spec. http://dev.w3.org/html5/spec/Overview.html#text-state-and-search-state Where it is specified that Text and Search inputs both generally represent a single line edit box. I understand the Note about platforms where special search controls are available, but I was testing on Windows XP and Qt/RedHat which (as far as I know) do not provide specialized search controls (the search control looked to me like a regular text box at least until I started applying style to it). If the consensus is that this is a non issue and that setting the background color to black and the foreground color to white should create on some platforms a control where the caret and the text are invisible, then probably this bug should be closed as invalid. To me, styling of the "Search" type input should be either prohibited by the user agent, for the goal of creating a "search" control that matches the platform's style, or followed to the same extent as for the "Text" control. Accepting styling for the foreground color, but not for background seems counterintuitive in any case.
I found an interesting comment in RenderTheme.cpp. I think that it is time to uncomment this: // FIXME: Uncomment this when making search fields style-able. // case SearchFieldPart: I believe that search fields are at least partially style able and removing this comment will make them fully style able.
Here is the response from the editor of the XMLHttpRequest Level 2 specification to the question that this bug report is trying to address: Re: XMLHttpRequest: IE compatibility: null versus empty string for requesting missing, unsafe, or malformed header names To: carol.szabo@nokia.com Cc: ap@webkit.org On Mon, Sep 21, 2009 at 6:57 PM, <carol.szabo@nokia.com> wrote: > IE 8.0 returns an empty string, except that it throws an exception if the > header name argument is null. > The standard that I read specifies null for the cases mentioned in the > subject. Is this difference intentional? > I personally prefer to have it the way the standard specifies the handling > of these cases, as it allows a distinction between a header not being > present and having an empty value, but I would like to know whether the > current state of the standard is likely to remain as is, or it is likely to > change to emulate IE, which while providing less information makes it easier > for the developers to treat missing and empty headers the same way, which is > probably ok in most cases. > > Any thoughts that you might have on this issue are greatly appreciated. The standard at one point returned the empty string. We changed it for exactly the reason you mention and I do not plan to change that. By the way, it's better to use annevk@opera.com if you want to reach me on such matters. annevankesteren+webkit@gmail.com is just for WebKit Bugzilla. Cheers, -- Anne van Kesteren http://annevankesteren.nl/
(In reply to comment #8) Sorry, I have attached this to the wrong bug. > Here is the response from the editor of the XMLHttpRequest Level 2 > specification to the question that this bug report is trying to address: > > Re: XMLHttpRequest: IE compatibility: null versus empty string for > requesting missing, unsafe, or malformed header names > To: carol.szabo@nokia.com > Cc: ap@webkit.org > On Mon, Sep 21, 2009 at 6:57 PM, <carol.szabo@nokia.com> wrote: > > IE 8.0 returns an empty string, except that it throws an exception if the > > header name argument is null. > > The standard that I read specifies null for the cases mentioned in the > > subject. Is this difference intentional? > > I personally prefer to have it the way the standard specifies the handling > > of these cases, as it allows a distinction between a header not being > > present and having an empty value, but I would like to know whether the > > current state of the standard is likely to remain as is, or it is likely to > > change to emulate IE, which while providing less information makes it easier > > for the developers to treat missing and empty headers the same way, which is > > probably ok in most cases. > > > > Any thoughts that you might have on this issue are greatly appreciated. > > The standard at one point returned the empty string. We changed it for > exactly the reason you mention and I do not plan to change that. By > the way, it's better to use annevk@opera.com if you want to reach me > on such matters. annevankesteren+webkit@gmail.com is just for WebKit > Bugzilla. > > Cheers, > > > -- > Anne van Kesteren > http://annevankesteren.nl/
Created attachment 39942 [details] Proposed patch This patch makes input type=text and input type=search behave consistently when it comes to styling.
Comment on attachment 39942 [details] Proposed patch I don't think this will look right on Mac. Did you test on the Mac? If you run pixel tests with that test, how does it look?
Comment on attachment 39942 [details] Proposed patch It seems the pixel tests need update too. Also, is search-styled.html enough testing for this change, or do we need more?
(In reply to comment #11) > (From update of attachment 39942 [details]) > I don't think this will look right on Mac. Did you test on the Mac? If you > run pixel tests with that test, how does it look? I ran the pixeltests on a mac and they all succeeded. One of them (fast/forms/search-styled.html) had a bad checksum file, but it still passed. My experience with Mac is very limited so I have no idea how it is supposed to look.
(In reply to comment #12) > (From update of attachment 39942 [details]) > It seems the pixel tests need update too. Also, is search-styled.html enough > testing for this change, or do we need more? All pixel tests including search-styled.html have passed. I do not know how to update a .png on Mac or how to obtain a checksum if the test does not fail. I myself have run some other tests on Linux/Qt though. I do not know how relevant they are for Mac. The main reason I picked on this bug was that I found a page like this <input type="search" style="background-color: black; text-color=white;"/> and the result was that the cursor and the text were not visible since the text-color was rendered but the background color had defaulted to white. My opinion is that we either follow the platform style in all elements or we obey the custom style in all elements. The mixed bag may lead to unexpected results.
Given Adele's concerns about this not looking right on the mac, and your inability to generate mac pixel results for us to check, I can't r+ this. I think you'll need to find a mac person to help you out.
Created attachment 39962 [details] screenshot of search-styled.html test case w/ the patch