Timeline for Unwanted line breaks in <kbd> style [closed]
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 10:12 | history | edited | CommunityBot |
replaced http://meta.superuser.com/ with https://meta.superuser.com/
|
|
| Mar 17, 2017 at 10:12 | history | edited | CommunityBot |
replaced http://meta.superuser.com/ with https://meta.superuser.com/
|
|
| Jun 11, 2012 at 13:19 | history | closed | balphaStaffMod | too localized | |
| Jun 5, 2012 at 18:24 | comment | added | slhck | 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. | |
| Jun 5, 2012 at 18:12 | comment | added | Daniel Andersson | @slhck: Nope, it's the same as before for me, now using the same version you mentioned. | |
| Jun 1, 2012 at 21:35 | comment | added | Daniel Andersson | @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 19:29 | comment | added | slhck | I have both Arial and Helvetica and have the same issue. Probably just a Chrome / WebKit bug, @dan | |
| Jun 1, 2012 at 18:11 | comment | added | Daniel Beck Mod |
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.
|
|
| Jun 1, 2012 at 18:08 | comment | added | Daniel Beck Mod |
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.
|
|
| Jun 1, 2012 at 11:55 | comment | added | Daniel Andersson | @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 <kbd> 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 10:47 | comment | added | Jukka K. Korpela |
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 7:57 | history | asked | Daniel Andersson | CC BY-SA 3.0 |
