Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird thick border in .input-group-btn #14237

Closed
martinsifra opened this Issue Jul 24, 2014 · 24 comments

Comments

Projects
None yet
8 participants
@martinsifra
Copy link

martinsifra commented Jul 24, 2014

Maybe it is correct, but it looks weird. In official docs is it possible to see between left Go! button and input.

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Jul 24, 2014

I assume you meant "Weird" rather than "Wired"?
What OS and browser are you using?
Can you post a screenshot?

@martinsifra martinsifra changed the title Wired thick border in .input-group-btn Weird thick border in .input-group-btn Jul 24, 2014

@martinsifra

This comment has been minimized.

Copy link
Author

martinsifra commented Jul 24, 2014

Of course, soory. Win 8.1 latest Chrome (36).
clipboard01

The vertical line has 2px width, just one pixel is I thing better.

@cvrebert cvrebert added the css label Jul 24, 2014

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Jul 25, 2014

Unable to reproduce with Chrome v36.0.1985.125 on Win 8.1 on Sauce:
has-box-shadow

And yes, the divider line is exactly 1px (I measured it in GIMP):
box-shadow-none
(Added 1px red and black lines in GIMP to help visually clarify this.)

@martinsifra

This comment has been minimized.

Copy link
Author

martinsifra commented Jul 25, 2014

I should be the Sauce mistake. The reality is, that there is not hidden one of the borders. This situation makes visible both of them. So it looks like 2 pixes border.
clipboard01

clipboard01

@carasmo

This comment has been minimized.

Copy link

carasmo commented Jul 25, 2014

Chrome 36 Mac. No double line. Check to see if your zoom level is 100%.

screen shot 2014-07-25 at 6 01 34 am

@hnrch02

This comment has been minimized.

Copy link
Member

hnrch02 commented Jul 25, 2014

Chrome v37.0.2062.44 beta on OS X 10.9.4, zoom level 100% using latest master: double border.
Screenshot

No double border on the segmented buttons though:
Screenshot

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Jul 25, 2014

The reality is, that there is not hidden one of the borders. This situation makes visible both of them.

Both of the elements have 1px borders, true, but the negative padding is supposed to make the borders overlap...

@zacechola

This comment has been minimized.

Copy link
Member

zacechola commented Jul 25, 2014

The double border continues to exist in 38.0.2103.0 canary (64-bit), as well. Same version of OSX, as @hnrch02.

screen shot 2014-07-25 at 12 20 37 pm

Setting .input-group-btn:first-child>.btn, .input-group-btn:first-child>.btn-group's margin-right to -2px seems to resolve it without immediately apparent side-effects, but boy is it weird. The margin-left on the other group is also set to -1px and appears fine.

@cvrebert cvrebert added this to the v3.2.1 milestone Jul 25, 2014

@hnrch02

This comment has been minimized.

Copy link
Member

hnrch02 commented Jul 25, 2014

The problem doesn't occur in Safari 7.0.5 or Firefox 31 though, so changing margin-right wouldn't work.

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Jul 25, 2014

Chrome browser bug perhaps?
CC: @mdo

@hnrch02

This comment has been minimized.

Copy link
Member

hnrch02 commented Jul 25, 2014

Looks like it. Can't reproduce in Opera 23.0.1522.60. What's strange though is that not everybody is able to reproduce this.

@zacechola

This comment has been minimized.

Copy link
Member

zacechola commented Jul 25, 2014

@hnrch02 It does work but it's obviously a hack. You'll gain a pixel on the input, while appearing to lose one on the button. Try it out. Still only displays the single pixel border.

Here it is in the extreme on FF 31 with a -10px margin.

screen shot 2014-07-25 at 1 00 01 pm

@hnrch02

This comment has been minimized.

Copy link
Member

hnrch02 commented Jul 25, 2014

@zacechola Sorry, I wasn't implying that using -2px wouldn't fix the problem. I was trying to say that it's not really an acceptable solution.

@zacechola

This comment has been minimized.

Copy link
Member

zacechola commented Jul 25, 2014

Understandable, @hnrch02. I wasn't suggesting it as a great fix either, merely as a curiosity that it works fine in the last-child with margin-left, but not first-child with margin-right.

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Jul 27, 2014

Definitely a browser thing when one variation of a component behaves well, but the other doesn't. Not sure we can do much about it in v3.x.

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Jul 27, 2014

@mdo Care to file a Chrome bug then, maestro?

@mdo mdo removed this from the v3.2.1 milestone Aug 2, 2014

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Aug 2, 2014

Given it's changed back and forth, I'm inclined to see if this works itself out. Also, I want to revisit the structure of these in v4. The extra wrapper around buttons and addons is rather necessary given the behavior of inputs and buttons across browsers.

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Sep 22, 2015

Since this hasn't worked itself out in the intervening year, I filed a Chrome bug:

https://code.google.com/p/chromium/issues/detail?id=534750

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Sep 23, 2015

Seems to be fixed in Chrome Canary 47.0.2517.0 !

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Oct 8, 2015

Seems to be broken again as of Chrome Canary 48.0.2530.0 😞

cvrebert added a commit that referenced this issue Oct 8, 2015

cvrebert added a commit that referenced this issue Oct 8, 2015

Merge pull request #17820 from twbs/chrome-bug-534750
Add Wall of Browser Bugs entry for #17438 / #14237

cvrebert added a commit that referenced this issue Oct 8, 2015

Port #17820 to v3
Add Wall of Browser Bugs entry for #17438 / #14237
Refs https://code.google.com/p/chromium/issues/detail?id=534750
Closes #17438
Closes #14237

[skip sauce]

cvrebert added a commit that referenced this issue Oct 11, 2015

Merge pull request #17881 from twbs/wkbug-149935
Add Wall of Browser Bugs entry for Safari related to #17438 / #14237

@mdo mdo referenced this issue Oct 13, 2015

Closed

v3.3.6 ship list #16644

cvrebert added a commit that referenced this issue Oct 28, 2015

cvrebert added a commit that referenced this issue Oct 28, 2015

Port #18091 to v3
Remove http://wkbug.com/149935 from Wall of Browser Bugs

It's been fixed in WebKit Nightly!
See https://trac.webkit.org/changeset/191623 and http://wkbug.com/149366
Refs #17438, #14237

[ci skip]
@crazyjat

This comment has been minimized.

Copy link

crazyjat commented Feb 16, 2016

This is still an issue with Chrome 48.0.2564.109 m (Windows 7).

I found a work around that seems to fix it in chrome and not negatively affect other browsers.

CSS:

.input-group-btn .btn { display: block; }

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Feb 17, 2016

@crazyjat

This comment has been minimized.

Copy link

crazyjat commented Feb 17, 2016

Yes I am aware, but I wanted to convey my work around to anyone suffering with this issue.

I doubt that the Chrome issue will be fixed any time soon as this is a direct result of the fact that Chrome does not "render" table cells with fractional pixel sizes. In the case above, the width of the button is a decimal value (IE: 102.4343px) because it is an inline-block element and the width is calculated based on the width of the text and the cell width is a whole pixel size (IE: 103px;).

It might be possible to also work around this issue by turning off subpixel font rendering, but I'm not sure.

@terrylinooo

This comment has been minimized.

Copy link

terrylinooo commented Jul 14, 2016

I met same problem, after googling I found here and zacechola 's answer solves my problem, thanks

.input-group-btn:first-child>.btn, .input-group-btn:first-child>.btn-group { margin-right:-2px; }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.