5 ms·

Sometimes I hate web development. Comparing the buttons (http://primercss.io/buttons/ http://primercss.io/buttons/) between Chrome and Safari on my Mac, the te

Sometimes I hate web development. Comparing the buttons (http://primercss.io/buttons/ http://primercss.io/buttons/) between Chrome and Safari on my Mac, the text is a pixel further up in Chrome and thus looks slightly wonky to me. Here's a screenshot of the two side-by-side (Chrome left, Safari right), zoomed to 500% in Photoshop with a 1px grid: http://imgur.com/dhZrxFH http://imgur.com/dhZrxFH

baddox 12y ago
I use Chrome, and GitHub's button text alignment has always bugged me. I chuckled when I noticed that this CSS framework of theirs has the same issue.
sorahn 12y ago
The real problem here is using vertical paddings. One solution I've found to getting vertical heights the same across browsers is to use no vertical padding, and large line-heights.
- mdo 12y ago
  Absolutely no problem with vertical padding—this particular problem is a Chrome bug.
  - sorahn 12y ago
    Fair enough, I take it back :) That being said, I have seen lots of vertical "off-by-one" issues related to trying to combine line-height, vertical-align, and padding.
    - mdo 12y ago
      Hah, yeah, nothing to rebuttal there lol. We're forever facing problems with that kind of stuff.
mdo 12y ago
This is due to a Chrome bug with how they render Helvetica. We could hack it ourselves, but it's a regression on their end and it'd just be more work for us.
- bshimmin 12y ago
  This is great to know - thank you! And keep up the good work.
- greggman 12y ago
  Did you file a bug?
  - mdo 12y ago
    We got Paul Irish to re-open the bug after they made the change to their font rendering. It is indeed a bug and has been fixed.
- saurik 12y ago
  Are you sure it is a bug, and not just a difference in the way the vertical spacing is calculated? Apple changed the way Helvetica's height is calculated in iOS 3.x and for a while had a "legacy font metrics" that were available for their apps, which included MobileSafari until they pulled the trigger in iOS 4.x. I have found every browser and operating system and often different versions of each to calculate these metrics differently, even for a specific given font. I talked to some people at WebKit and on Safari about this, and they absolutely do not consider it a bug.
  - mdo 12y ago
    Yup, see my comment above or below this. I'd find the tweets about it, but blah, Twitter search.
tambourine_man 12y ago
Text is consistently better in Safari in subtle ways. It's one of the reasons why I still use it, even though it keeps getting worse with every release (crashing tabs, DNS resolution issues and that dreadful new inspector to name a few). Such a shame, it used to be a great browser.
bigiain 12y ago
Is it just me, or is expecting pixel-perfect identical rendering between different browsers a guaranteed way to set yourself up for disappointment? If you aren't prepared to put up with differences that slight, perhaps web development isn't the right field for you. (Though I recall back in the day not being able to reliably reproduce film proofs for printing without occasional expensive differences showing up between proofs produced with Quark vs PageMaker... The more things change … )

baddox 12y ago

I use Chrome, and GitHub's button text alignment has always bugged me. I chuckled when I noticed that this CSS framework of theirs has the same issue.

sorahn 12y ago

The real problem here is using vertical paddings. One solution I've found to getting vertical heights the same across browsers is to use no vertical padding, and large line-heights.

mdo 12y ago
Absolutely no problem with vertical padding—this particular problem is a Chrome bug.
- sorahn 12y ago
  Fair enough, I take it back :) That being said, I have seen lots of vertical "off-by-one" issues related to trying to combine line-height, vertical-align, and padding.
  - mdo 12y ago
    Hah, yeah, nothing to rebuttal there lol. We're forever facing problems with that kind of stuff.

mdo 12y ago

This is due to a Chrome bug with how they render Helvetica. We could hack it ourselves, but it's a regression on their end and it'd just be more work for us.

bshimmin 12y ago
This is great to know - thank you! And keep up the good work.
greggman 12y ago
Did you file a bug?
- mdo 12y ago
  We got Paul Irish to re-open the bug after they made the change to their font rendering. It is indeed a bug and has been fixed.
saurik 12y ago
Are you sure it is a bug, and not just a difference in the way the vertical spacing is calculated? Apple changed the way Helvetica's height is calculated in iOS 3.x and for a while had a "legacy font metrics" that were available for their apps, which included MobileSafari until they pulled the trigger in iOS 4.x. I have found every browser and operating system and often different versions of each to calculate these metrics differently, even for a specific given font. I talked to some people at WebKit and on Safari about this, and they absolutely do not consider it a bug.
- mdo 12y ago
  Yup, see my comment above or below this. I'd find the tweets about it, but blah, Twitter search.

tambourine_man 12y ago

Text is consistently better in Safari in subtle ways. It's one of the reasons why I still use it, even though it keeps getting worse with every release (crashing tabs, DNS resolution issues and that dreadful new inspector to name a few). Such a shame, it used to be a great browser.

bigiain 12y ago

Is it just me, or is expecting pixel-perfect identical rendering between different browsers a guaranteed way to set yourself up for disappointment? If you aren't prepared to put up with differences that slight, perhaps web development isn't the right field for you. (Though I recall back in the day not being able to reliably reproduce film proofs for printing without occasional expensive differences showing up between proofs produced with Quark vs PageMaker... The more things change … )