Re: A CSS equivalent of HTML's DOCTYPE trigger

On Tue, Jan 10, 2012 at 8:36 AM, Matthew Wilcox <elvendil@gmail.com> wrote:
> On 10 January 2012 16:14, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>  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.

That's the thing, though - if it doesn't work for the default fonts,
it will absolutely fail for some people.  We can solve this well,
without requiring either extensive per-font tweaking, or accepting
failure for the system fonts.  (Not that per-font tweaking isn't a bad
thing; it can be useful for some situations.  But it's not needed for
yours, though it may also help somewhat.)  Note that another failure
point is user-specified fonts.


>>  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 :)

Yes, what you really want is some way to force them all to the same
font-size, but have that font-size adjust itself, along with the
spacing, to an attractive result.  Unfortunately, this is pretty
difficult without a special-purpose solution.  We can only get
approximations of this right now.


>> 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.

Your loss.  That's not a screen-reader issue, that's a *browser bug* -
some browsers use the box tree to provide a11y information rather than
the DOM tree.  Done naively, there's no way to tell in the box tree
whether a particular display:table box came from a <table> or a <div>.

File bugs and yell about it.  In the meantime, use the layout tools
you have in the way they're intended, rather than avoiding them
forever, so the browser makers don't just write off the bug as
something ignorable.


>> 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?

No, it works great on my W7 system.  Using the sans-serif fallback
(which is wide enough to trigger problems in your original layout),
they all lay out in one line without wrapping or breaking, and with
plenty of spacing still between each entry.  Note that you've got
*120px* of spacing there that you can cannibalize from; that's a good
20% of the total width of the <ul>.

~TJ

Received on Tuesday, 10 January 2012 17:23:11 UTC