On the inventory screen the library radio buttons are smooched against their labels. Patch forthcoming.
Created attachment 10876 [details] [review] Bug 8453: Add spaces to inventory options The home and current library labels were right on top of the radio buttons. This patch just adds a bit of space in there so that it's cleaner looking.
(In reply to comment #1) > Created attachment 10876 [details] [review] > Bug 8453: Add spaces to inventory options > > The home and current library labels were right on top > of the radio buttons. This patch just adds a bit of > space in there so that it's cleaner looking. While I'm not sure of the standard Koha practice, I think that it would be a better idea to use CSS to control this rather than putting in a hard-coded space. From what I can remember, I think best practice is to always use CSS to control display and to avoid hard-coded spaces wherever possible. We could probably do something along the lines of #tools_inventory * input[type="radio"][name="branch"] {margin-right:5px;} or insert an ID or two and select those, if we don't want to rely on attribute selectors.
I'm pretty sure that all other places this is just a space. I agree that CSS makes the most sense if you want to add in consistent spacing, I'm just making a space after the radio button and before the text ... very standard kind of thing that I think CSS would be overkill for.
(In reply to comment #3) > I'm pretty sure that all other places this is just a space. I agree that CSS > makes the most sense if you want to add in consistent spacing, I'm just > making a space after the radio button and before the text ... very standard > kind of thing that I think CSS would be overkill for. If all the other places are using a space, that space should probably be removed and then CSS used to apply that style across the board, since we are trying to provide consistent spacing between the radio button and the text. After all, what happens when we decide that we want no space or a wider space? The downfall of using the hard-coded space is the width of your space is hard-coded too. No matter how many spaces are added to the HTML, only that one space will appear on the page. I think CSS provides the most flexibility and is a better practice in general. While I'm having trouble finding an authoritative source to link to that says not to use spaces for display purposes in HTML, I've been told this in classes and by other programmers as well. Admittedly, it's a fairly trivial localized display issue, but I think that's how widespread inconsistencies start.
(In reply to comment #4) > If all the other places are using a space, that space should probably be > removed and then CSS used to apply that style across the board It is a consistent practice across the board to use a single space around inputs and labels, just as you would include a single space after the end of a sentence. I would consider this to be "minimum safe distance" for readability. If you want to get into adding *more* space around elements, that's when you start to look at adding CSS.
Created attachment 10889 [details] [review] [SIGNED-OFF] Bug 8453: Add spaces to inventory options The home and current library labels were right on top of the radio buttons. This patch just adds a bit of space in there so that it's cleaner looking. Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 10905 [details] [review] Another proposed patch I agree with David, I think it is a good pratice to use CSS to control ajustment. But in this case, it is possible to do more sexy radio buttons using labels. Have a look at this patch and tell me what do you think about this method. I Switch to In Discussion
(In reply to comment #7) > I agree with David, I think it is a good practice to use CSS to control > ajustment. Yes, but reducing the level of granularity to that of a single space is taking this good practice too far. > But in this case, it is possible to do more sexy radio buttons using labels. Yes, your patch is a more thorough fix, giving us clickable labels. However, it still relies on whitespace to preserve spacing around the elements ;)
And putting this in to discussion is just delaying an easy fix from making it in to Koha. I say leave my tini tiny itty bitty harmless patch as it is and if you want to follow up with a more thorough patch go for it. Some of us (like me) don't have a lot of things to contribute to the code and so when I make string and spacing fixes and they get trashed cause they're not complicated enough it's kind of discouraging and the reason why more people without lots of programming skills aren't submitting patches.
(In reply to comment #8) > (In reply to comment #7) > > I agree with David, I think it is a good practice to use CSS to control > > ajustment. > > Yes, but reducing the level of granularity to that of a single space is > taking this good practice too far. > > > But in this case, it is possible to do more sexy radio buttons using labels. > > Yes, your patch is a more thorough fix, giving us clickable labels. However, > it still relies on whitespace to preserve spacing around the elements ;) After a quick look around at subscriptions-add.pl and import_borrowers.pl, it seems that clickable labels (rather than a single space) are already the standard practice and inventory.pl was just missed. There is already an existing "radio" class for the "li" element that adds the whitespace between the radio button and the clickable label (which would also need to be introduced). I know this is a trivial issue, but I'm still on the side of consistency.
(In reply to comment #10) > There is already an existing "radio" class for the "li" element that adds > the whitespace between the radio button and the clickable label (which would > also need to be introduced). > > I know this is a trivial issue, but I'm still on the side of consistency. I think you and Owen might be talking past each other. Adding the space makes the html more readable, using css makes the rendered page more readable. Both have merit.
(In reply to comment #9) > And putting this in to discussion is just delaying an easy fix from making > it in to Koha. > > I say leave my tini tiny itty bitty harmless patch as it is and if you want > to follow up with a more thorough patch go for it. > > Some of us (like me) don't have a lot of things to contribute to the code > and so when I make string and spacing fixes and they get trashed cause > they're not complicated enough it's kind of discouraging and the reason why > more people without lots of programming skills aren't submitting patches. Nicole, I still maintain that an easy fix isn't always the right fix. The more I work with Koha, the more I see a need for consistent practice. Paul failed my Bug 7839 fix, because I didn't adhere to the spelling and naming guidelines. While that might seem trivial, I see the logic in preserving consistency. I was happy to re-write my patch. However, I do apologize for making it seem like I was trashing your fix. That was not at all my intention. I think that a lot of the fixes you do, especially in regards to documentation, are absolutely invaluable. In the future, I will try to be more positive in my feedback. I don't think patches need to be complex to be useful. In any case, I've thrown in my two cents, so I'll bite my tongue now :p.
Hi Nicole and Owen, I agree, It is a lot of discussion for a little patch. But I think this kind of patch should have never exist :) Let me explain you why. When I arrived on this patch to make QA, I thought: it is an easy patch. I was surprised to find an unique space for a patch. I didn't know we wanted to add space after a input radio. Apparently, I am not alone in this case. My job as a part of QA team is to put in question each patch. I think this one should not have exist, because the ajustement between input and label should automatically be taken into account. Otherwise, for each patch adding these lines, inevitably a patch will have to be created to fix that. It's not very productive, I think. Given that, we can fix that definitely and don't create a new patch for each space to add. You patch works well, but it fixes one problem rather than fixing all futur problems Marking as Passed QA
(In reply to comment #13) > Hi Nicole and Owen, > > I agree, It is a lot of discussion for a little patch. > But I think this kind of patch should have never exist :) > > Let me explain you why. > > When I arrived on this patch to make QA, I thought: it is an easy patch. I > was surprised to find an unique space for a patch. I didn't know we wanted > to add space after a input radio. > > Apparently, I am not alone in this case. > My job as a part of QA team is to put in question each patch. I think this > one should not have exist, because the ajustement between input and label > should automatically be taken into account. > Otherwise, for each patch adding these lines, inevitably a patch will have > to be created to fix that. It's not very productive, I think. > Given that, we can fix that definitely and don't create a new patch for each > space to add. > > You patch works well, but it fixes one problem rather than fixing all futur > problems > > Marking as Passed QA We're not really consistent: * moremember.pl page (patron adding) show yes [] no [] for flags & sex (checkbox on the right of the label) * the inventory.pl page show the checkbox on the left, description is not clicable * the tools/holidays.pl page show the checkbox on the left, the description itself is clickable My preference goes to what we have in tools/holidays.pl, but let me know your's. Should we start a discussion on koha-devel for that ? In the meantime, this patch is pushed, even if i'm not a fan of the space (owen, your voice is a leader one for all what is related to interface for me)
Released in 3.10.0