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

Re: A CSS equivalent of HTML's DOCTYPE trigger

From: Ambrose LI <ambrose.li@gmail.com>
Date: Tue, 10 Jan 2012 12:12:07 -0500
Message-ID: <CADJvFOUFusPgE7tC9PiiH+sKexPhg7xEjMtpMeU7d1ssd_8rNQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Matthew Wilcox <elvendil@gmail.com>, Jon Rimmer <jon.rimmer@gmail.com>, "www-style@w3.org Style" <www-style@w3.org>
2012/1/10 Tab Atkins Jr. <jackalmage@gmail.com>:
> 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.  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.
> 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;"
> (you use explicit widths for the body container and the header, so an
> explicit width on the <ul> will work properly as well), the <li>s to
> "display:table-cell; text-align: center;", and removed the padding on
> the <a>s, you'd have a container that was forced to be single-line,
> and which automatically spread the links out in a roughly appropriate
> manner.  The spacing isn't quite exact, but it's pretty close.

I think the problem is bigger than just spacing issues.

When I style Chinese text, for example, I want to specify “bold is
bold unless it is Chinese and my preferred font(s) is (are)
unavailable (i.e., unless the bold will be synthesized), in which case
it should be set in a non-bold sans-serif unless the non-bolded parts
are already in sans-serif”.

A special syntax for this would be great, but within the current
framework of doing things what will be a proper solution in this case?
(Based on Ethan’s work I would imagine maybe @font-face, but that
feels like an overly complicated solution for a very common problem…)
Received on Tuesday, 10 January 2012 18:05:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:13 UTC