Re: A CSS equivalent of HTML's DOCTYPE trigger

On 10 January 2012 16:14, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Jan 10, 2012 at 7:16 AM, Matthew Wilcox <elvendil@gmail.com>
> wrote:
> > 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.
>
> Note that being able to set font metrics per font would *not* help you
> here.


I think it would help. Not get you perfect, but I could pull them all onto
one line through use of negative letter spacing, adjusted padding around
the nav anchors, and tweaked font-size for each fallback font.


>  Given the particular styles you're using, the problem is that
> if a font is too wide it'll mess up your layout.


Exactly. But I can work around that if I can re-specify measures based on
the font in use.


>  However, if it falls
> back all the way to sans-serif, you have *no idea* what the width of
> that font is, so you can't set an appropriate font-size.
>

It's not a cure all, but it's hardly ever going to fall that far. The real
issue is that we specify font-face fonts which are wildly out of whack with
any default fonts. When they don't load we can be pretty sure we can
fallback to something reliable like Arial or Helvetica. Chances are very
good those are installed. A third fallback like sans-serif is wise but a
safety-net under a safety net. Never likely to be used. The first safety is
though.


> There are two proper solutions to this.  One is to use some mechanism
> that auto-scales the font-size to the available space.  This has been
> proposed before, perhaps as a value for text-justify.  This way, wide
> fonts would drop to a smaller font-size.


I'm all for that if the automated solution is any good. I'm all for an
ability to manually over-ride too, for when it isn't. And no automated
solution is perfect.


>  However, you'd have to set
> explicit widths on the <a>s, which means that if the words end up with
> different width proportions due to a different font, they'll end up at
> slightly different font-sizes, which is unsightly.
>

And there's the 'automated' problem there :)


> The second is to use a better layout mechanism, so that your
> white-space between the elements is more flexible.  You're currently
> using inline-blocks with explicit padding set to enforce separation.
> If you instead switched the <ul> to "display:table; width: 664px;"
>

I'll stop right there - I will not use display:table; because it is an
accessibility problem. Screen readers are known to use the CSS to trigger a
semantic change too. Some read them as table content as soon as CSS says
it's a table. That rules this approach out.

Using Flexbox gets you basically the same solution, but the spacing
> will spread out more evenly, and you don't need to set an explicit
> width.  You just set the <ul> to "display:flexbox; flex-pack:
> justify;" and the <li>s to "text-align: center; display: block;", and
> again remove the padding from the <a>s.
>

This will not change the font sizes, you can only compress empty space so
much. Look at the difference in character widths - even with flexbox you're
going to have to wrap some text somewhere, right?


>
> ~TJ
>