Skip to main content

Search and Top Navigation

#9212 closed bug (notabug)

Opened April 05, 2013 03:44PM UTC

Closed April 09, 2013 03:34PM UTC

Buttonset button margin shouldn't be applied to the last button in the set

Reported by: emlun Owned by: emlun
Priority: minor Milestone: none
Component: ui.button Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:
Description

Suppose you have three buttons and one buttonset in a column, and want their edges to align nicely:

|          Button1           |
|          Button2           |
| Radio1 || Radio2 || Radio3 |
|          Button3           |

This is near impossible since the buttonset will always be offset by a bit on one side or the other. By not applying the shift-right style rule to the last button in the buttonset, however, no special margins poke out of the sides, and styling it all becomes much easier.

Attachments (0)
Change History (12)

Changed April 05, 2013 03:47PM UTC by scottgonzalez comment:1

owner: → emlun
status: newpending
version: git1.10.2

Can you please provide an actual page showing this instead of ASCII art?

Changed April 05, 2013 04:18PM UTC by emlun comment:2

status: pendingnew

Working on it, still figuring out how best to attach images. I have a fix ready for pull requesting as well, so my creating this ticket is mostly a formality. Right now I'm on my way home, I didn't really expect anyone to find this until I got home so I left it half done. I clearly underestimated the community here, sorry 'bout that. :)

Changed April 05, 2013 04:27PM UTC by scottgonzalez comment:3

status: newpending
Working on it, still figuring out how best to attach images.

Please do not provide a screenshot. Use jsFiddle or jsbin to create an actual page showing the problem.

I have a fix ready for pull requesting as well, so my creating this ticket is mostly a formality.

Glad to hear you have a pending fix :-)

Tickets are not formalities. They're important for verification, discussion, version tracking, changelogs, etc.

Right now I'm on my way home, I didn't really expect anyone to find this until I got home so I left it half done. I clearly underestimated the community here, sorry 'bout that. :)

No problem :-) I'm going to set this back to pending until we get the visual test case. Thanks.

Changed April 05, 2013 06:28PM UTC by emlun comment:4

_comment0: > Tickets are not formalities. They're important for verification, discussion, version tracking, changelogs, etc. \ \ Yeah, I got that. By 'formalities' I meant RingTFM and following the instructions. ;)1365186536459371
status: pendingnew
Tickets are not formalities. They're important for verification, discussion, version tracking, changelogs, etc.

Yeah, I got that. By 'formalities' I meant RingTFM and trying to follow the instructions. ;)

Changed April 05, 2013 06:30PM UTC by scottgonzalez comment:5

status: newpending

Changed April 05, 2013 06:34PM UTC by emlun comment:6

status: pendingnew

Huh, for whatever reason I can't seem to reproduce the problem in a minimal example - it styles nicely without ugly hacks, unlike in the development environment where I found myself having a problem with it. I'll try to figure it out at the next opportunity, which will probably be Tuesday. Can I just leave this as pending with me as the owner until then, or what's the policy for this kind of thing?

And if I'm the one changing the status to new all the time, please let me know how to not do that when I post a comment... :x

Changed April 05, 2013 06:38PM UTC by scottgonzalez comment:7

status: newpending

You're not doing anything wrong. Every time you reply it'll automatically get set back to new. If you don't reply for 2 weeks, the ticket will automatically close.

I'll set back to pending for you to investigate the scenario(s) that cause this problem.

Changed April 09, 2013 08:34AM UTC by emlun comment:8

status: pendingnew

So I created a demo:

The only differences between these two are http://pastebin.com/Seiics2f . The example shows that the change has some merit, though perhaps not a great deal.

Sadly, the "after" version does not render properly in IE9 - the buttonset buttons get spaced too far apart since IE does not understand the :last-child selector. I suppose that disqualifies this change since it would break buttonsets in IE. Rearranging the :not(:last-child) and :last-child rules does not help either.

See the accepted answer at http://stackoverflow.com/questions/1293369/using-last-child-in-css . I did not realize this when opening this ticket. :)

Changed April 09, 2013 09:54AM UTC by scottgonzalez comment:9

status: newpending

I copied your "before" page into jsFiddle and I don't see the problem: http://jsfiddle.net/5CjAV/

Perhaps it's because you're in quirks mode.

Changed April 09, 2013 11:33AM UTC by tj.vantoll comment:10

@emiun It might be easier to use this as a starting point for your test case: http://jsfiddle.net/tj_vantoll/RKwuk/. It has the latest versions of jQuery and jQuery loaded, is in standards mode, and has some example markup already in place.

Changed April 09, 2013 03:32PM UTC by emlun comment:11

status: pendingnew

Replying to [comment:9 scott.gonzalez]:

I copied your "before" page into jsFiddle and I don't see the problem: http://jsfiddle.net/5CjAV/ Perhaps it's because you're in quirks mode.

Yeah, I've probably gotten lost in my own changes while trying to fix the original problem. After I sat down to straighten these things out for the sake of this ticket everything seems to work just fine. I guess there really isn't any problem with the theme css as it is. Whatever it was that caused the problem turned out to be easy to override after all.

Anyway, I no longer see any reason to keep pursuing the change I originally suggested. Thanks for your patience. :)

Changed April 09, 2013 03:34PM UTC by scottgonzalez comment:12

resolution: → notabug
status: newclosed