3

Using Google Chrome 21.0.1155.2 dev (I know this is not a supported version, but as in Element position bug in "Privilege" FAQ in Google Chrome it might be of interest anyway, and at least might serve as a heads up for when the version hits stable), I get this sample rendering for the <kbd> tag:

Sample rendering

As with the element position bug I linked above, I would guess this has to do with Chrome's built-in fonts that are wider than expected. In that case, this would manifest itself on any system using Chrome that lacks the primary defined font in the CSS for the kbd tag, and would be solved by increasing the kbd box width by a pixel or so.

8
  • Looking at the style definitions for kbd elements and looking at the source of the article from which the screenshot has been taken, namely superuser.com/questions/428945/… I don’t see any reason for the wrapping. The element is declared with display: inline-block without explicit width setting. I the width calculation goes wrong, it would not explain the wrapping, as a normal word should not line-wrap by default. What happens if you test just with a word in a span set to inline block (with a border)? Jun 1, 2012 at 10:47
  • @JukkaK.Korpela: A local test with a span class with borders and inline-block does not produce similar issues. If it was a basic general rendering error in Chrome, it would probably show itself on more places than StackExchange (the same issue occurs with &lt;kbd&gt; at SO, at least), but that is more of a statistics argument than hard fact :-) . Also, yeah, I should have seen that there was no fixed width in play since e.g. the "Right button" in my example are wide enough to not give "Fn" any troubles. If no suspicious CSS rules are in play, perhaps it is just a Chrome Dev issue after all. Jun 1, 2012 at 11:55
  • Note that the linked topic was status-declined until after I showed that it's unrelated to the browser/version the user is using, and instead an issue with explicitly defined fonts. Therefore that topic cannot serve as effective justification for this topic.
    – Daniel Beck Mod
    Jun 1, 2012 at 18:08
  • Do you have Arial or Helvetica on your system? It looks like these are the only ones the CSS checks for, before it falls back to sans-serif, which would probably be considered unsupported.
    – Daniel Beck Mod
    Jun 1, 2012 at 18:11
  • 2
    I have both Arial and Helvetica and have the same issue. Probably just a Chrome / WebKit bug, @dan
    – slhck
    Jun 1, 2012 at 19:29
  • @DanielBeck: Yes, it was status-declined until you showed that, but since you showed that, it was not in vain after all. It is a justification inasmuch as it showed that just because a non-supported browser was used, not every bug is pointless to report. If all I get is a "/ignore" it wont bother me (and hopefully not the team much either), and I still think it is a heads up for the future, if this pops up again when/if it hits stable. I wouldn't "demand" it to be fixed since it is an unsupported version, but that does not make it pointless to report, imho. Jun 1, 2012 at 21:35
  • @slhck: Nope, it's the same as before for me, now using the same version you mentioned. Jun 5, 2012 at 18:12
  • Sorry, I thought this was fixed, but it turns out I had another zoom level activated, and this version fixed some other floating bugs, but not this one here.
    – slhck
    Jun 5, 2012 at 18:24

0

Browse other questions tagged .