W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: A CSS equivalent of HTML's DOCTYPE trigger

From: Matthew Wilcox <elvendil@gmail.com>
Date: Tue, 10 Jan 2012 17:43:22 +0000
Message-ID: <CAMCRKiK0+Ca3+BTkT28fOcBp2nG9qT9LS+ocjqm=wJPPCZpq4A@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Jon Rimmer <jon.rimmer@gmail.com>, "www-style@w3.org Style" <www-style@w3.org>
>
> That's the thing, though - if it doesn't work for the default fonts,
> it will absolutely fail for some people.


Completely agree, but it's also about probability. Working with installed
system fonts isn't too bad an issue, probailities are good that if we only
work with the standard one's there won't be a need for fallbacks. If I
style that site in Helvetica and Arial there wouldn't be this problem, no
matter which was used. That's why we've not had these problems to this
extent before. The reason it's a big problem now is because custom fonts
are so massively different from the system fonts that *any* fallback would
be terrible given the same margin/padding/font-size values.


>  We can solve this well,
> without requiring either extensive per-font tweaking, or accepting
> failure for the system fonts.
>

I'd like to have a better idea of how, I'm not convinced yet that there is
a "well" option for auto fixing, or that "well" will ever be good enough
for some applications.


> Note that another failure point is user-specified fonts.
>

True, which is where we would be forced to rely on the automated fallback
you're suggesting. Nothing we can do about that.


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

I think I get what you mean - it's a very similar thing that's needed for a
decent text-align: justify; if I understand you properly.


> Your loss.  That's not a screen-reader issue, that's a *browser bug*
>

While I agree that it is incorrect behaviour, I will not sacrifice
accessibility for "how things should work". They don't work like that, and
it harms users to just do it anyway. Would you recommend the same approach
if the consequence of using an attribute as the spec defined resulted in
display glitches wherever it was used? Of course not.


> File bugs and yell about it.


Good point, I shall check the bug reports.


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

I agree with the ethos, but as explained - I am not that irresponsible.


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

I've not tried flexbox myself yet, I'll have a go later. Note though - what
happens when this is a responsive layout and not a px one? Where the amount
of space changes...
Received on Tuesday, 10 January 2012 17:43:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT