the New patron button and Patron lists button in patron-toolbar.inc are styled differently and look silly next to each other
Created attachment 49295 [details] [review] Bug 16100: Styling patron toolbar buttons the same Styling them as links, since usually buttons are associated with submitting a form and these are just links To test, go to Members (members/members-home.pl) and confirm buttons now look the same. Sponsored-by: Catalyst IT
Created attachment 49311 [details] [review] Bug 16100 [Alternate] Buttons in patron toolbar are styled differently This patch makes modifications to the global CSS file in order to make font rendering in buttons more consistent. The Bootstrap CSS is setting font styles which are not being consistently overriden by the staff client's CSS. To test, apply the patch and clear your browser cache if necessary. Check several places to confirm that the changes look correct and don't go too far: - Go to the "Patrons" home page. The "New patron" and "Patron lists" buttons should look consistent with each other. - Locate a patron and view their detail page. Toolbar buttons should look correct. - Go to Administration -> Libraries and Groups and click the "Delete" button on any library. Verify that the warning dialog buttons look correct. - Go to Cataloging and open the advanced editor. Confirm that toolbar buttons look correct. - Go to Tools -> Stage MARC records for import and confirm that the "Upload file" button looks consistent with other generic submit buttons.
Aleisha I'm glad you took this up, because it was bugging me too and I couldn't figure out what was causing it. Having now done some more digging I think we can fix this with CSS changes rather than markup changes.
The questions in my mind before I decide what to sign off would be: 1) Are we going to have 'button' for sublists and 'a' for single action items? Should we even care? 2) The CSS styling, what other pages might it affect? Because for (1), it seems strange to me to use 'a' to trigger the sublist, but perhaps that is the more standard way of doing UI stuff? And for (2), it would be dumb to sign it off for this page, and have it break some other page. So an idea of other affected pages would be nice.
(In reply to M. Tompsett from comment #4) > The questions in my mind before I decide what to sign off would be: > 1) Are we going to have 'button' for sublists and 'a' for single action > items? Should we even care? I'm not trying to set a standard about what element should be used to make a button. The goal of using the Bootstrap framework CSS is to make the point moot, since <button> and <a> can be styled to look the same and behave the same. The goal of my alternative patch is to eliminate the necessity of using one element or the other because the styling looks off. > And for (2), it would be dumb to sign it off for this page, and have it > break some other page. So an idea of other affected pages would be nice. My test plan lists pages which include elements representative of the kinds of things which might be affected by this change.
Created attachment 49383 [details] [review] Bug 16100 [Alternate] Buttons in patron toolbar are styled differently This patch makes modifications to the global CSS file in order to make font rendering in buttons more consistent. The Bootstrap CSS is setting font styles which are not being consistently overriden by the staff client's CSS. To test, apply the patch and clear your browser cache if necessary. Check several places to confirm that the changes look correct and don't go too far: - Go to the "Patrons" home page. The "New patron" and "Patron lists" buttons should look consistent with each other. - Locate a patron and view their detail page. Toolbar buttons should look correct. - Go to Administration -> Libraries and Groups and click the "Delete" button on any library. Verify that the warning dialog buttons look correct. - Go to Cataloging and open the advanced editor. Confirm that toolbar buttons look correct. - Go to Tools -> Stage MARC records for import and confirm that the "Upload file" button looks consistent with other generic submit buttons. Applied alternate patch only, followed test plan, buttons display as expected. Signed-off-by: Marc Véron <veron@veron.ch>
Hi Owen, followed your test plan and the 'Upload' button on the last step looks not quite right to me. The font is a bit bigger compared to other buttons and maybe a different one even? Can you check? It looked more in tune with the other buttons to me without the patch.
(In reply to Katrin Fischer from comment #7) > Hi Owen, followed your test plan and the 'Upload' button on the last step > looks not quite right to me. The upload button does look different with this patch, but now it looks like a submit button rather than a toolbar button. This makes it more consistent with other buttons which perform a similar action.
Created attachment 49459 [details] [review] [PASSED QA] Bug 16100 [Alternate] Buttons in patron toolbar are styled differently This patch makes modifications to the global CSS file in order to make font rendering in buttons more consistent. The Bootstrap CSS is setting font styles which are not being consistently overriden by the staff client's CSS. To test, apply the patch and clear your browser cache if necessary. Check several places to confirm that the changes look correct and don't go too far: - Go to the "Patrons" home page. The "New patron" and "Patron lists" buttons should look consistent with each other. - Locate a patron and view their detail page. Toolbar buttons should look correct. - Go to Administration -> Libraries and Groups and click the "Delete" button on any library. Verify that the warning dialog buttons look correct. - Go to Cataloging and open the advanced editor. Confirm that toolbar buttons look correct. - Go to Tools -> Stage MARC records for import and confirm that the "Upload file" button looks consistent with other generic submit buttons. Applied alternate patch only, followed test plan, buttons display as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
*** Bug 16051 has been marked as a duplicate of this bug. ***
Pushed to Master - Should be in the May 2016 release. Thanks!