up vote 2 down vote favorite

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.

share
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)? – Jukka K. Korpela Jun 1 '12 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. – Daniel Andersson Jun 1 '12 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♦ Jun 1 '12 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♦ Jun 1 '12 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 '12 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. – Daniel Andersson Jun 1 '12 at 21:35
@slhck: Nope, it's the same as before for me, now using the same version you mentioned. – Daniel Andersson Jun 5 '12 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 '12 at 18:24

closed as too localized by balpha♦ Jun 11 '12 at 13:19

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, see the FAQ.

You must log in to answer this question.

Browse other questions tagged