Re: A CSS equivalent of HTML's DOCTYPE trigger

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