That sounds great. I'm having a problem right now with a poor font stack in CSS. There's a menu that with standard fonts is FAR too large and so the display breaks terribly. Once the right font is loaded it's ok. But I can't detect which is actually being used so I can't correct layout. x-height adjustments may not work on their own because the character widths are different for a given x-height, which would still result in unwanted wrapping. For reference: http://testing.pulse3k.com (please note this is a work in progress and will change quickly. Please note that this is also a private URL, please don't use this for anything other than checking font behaviour.) If you've got NoScript installed it'll block the @font-face font and you will see the main banner nav is terrible. Once allowed, it looks correct. On 10 January 2012 14:54, Jon Rimmer <jon.rimmer@gmail.com> wrote: > What about extending @supports for this? Something like... > > @supports ( font-family: 'Avenir' ) { > p { margin: 0.6em 0; } > article { padding: 12px 6px; } > etc... > } > > On 10 January 2012 08:28, Matthew Wilcox <elvendil@gmail.com> wrote: > > Interesting, thanks Tab. > > > > The reason I brought it up was I can't see how, if we decided it was > worth it, we'd apply a fix to the issue of font handling I brought up in > CSS & Type thread. > > > > The issue in there was that type measures (the margin, padding etc we > apply to elements that have text in them) should be adjusted depending on > the actual typeface in use. We currently set them as concrete values based > on the preferred font, but if that font isn't available then the next in > the font stack is unlikely to be suitably close and therefor the measures > need adjusting. CSS doesn't have that type of logic or workflow. >Received on Tuesday, 10 January 2012 15:17:05 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:09 UTC