- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 2 Jan 2015 09:55:05 -0500
- To: www-style@w3.org
Fonts
-----
- The expressed desire to have Kai classified as a cursive font
from the Chinese publishing group as a way to distinguish that
is is a different style garnered a lot of mixed thoughts and
concern that the group didn't have the expertise to make the
right decision.
- There was also concern that Kai isn't widely downloaded as a
font and more research is needed to see if it's common in
devices marketed to a Chinese-speaking population.
- RESOLVED: Topic goes back to the mailing list to find a good
solution
- RESOLVED: Only download a single font per family when
unicode-range values overlap
- Google's proposal for a timeout function for font downloading
was discussed and fleshed out further.
- A better definition of when timeout occurs needs to be
created.
- This also needs to be optional when only the real font will
do, such as icon fonts.
- There was neither full opposition or support, so discussion
will continue on the mailing list.
- RESOLVED: Start editor's draft of CSS4 Fonts
===== FULL MINUTES BELOW ======
Scribe: dael
Fonts
=====
Accessing Kai as a Generic
--------------------------
Bert: So fonts. First subtopic...
ChrisL: It's something jdaggett thought we didn't need to.
Bert: Classification of Kai as cursive.
jdaggett: I took it out of the draft
fantasai: I think they'd like it to be reliably returned.
jdaggett: I had some people say serif too. It's not an interesting
debate for CSS.
Bert: What are the downsides of leaving it out?
jdaggett: I took any reference out and I don't think we should
declare it either way. The spec was just listing
examples and if there's controversy we should leave it
out.
ChrisL: I agree. If there's differences it shouldn't be an example.
jdaggett: Okay.
r12a: My understanding is that the Chinese wanted to get to
somewhere when it would give you something like Kai if you
select cursive. They'd like to know a way to influence it to
get the correct font.
jdaggett: Stepping away from Chinese, the generic cursive is
somewhat useless because it can be all manner of things.
It's probably not used that much. It's a random font
that looks scripty.
ChrisL: Good examples?
fantasai: Problem is Chinese use things like a Kai font in a
similar was to a roman font vs an italic. We need a
generic way for the distinction where you don't lose the
semantic. They need a way to switch without providing
their own font. It's about "I need to express stylistic
difference".
jdaggett: The underlying problem is we don't have availability on,
you don't have a Kai style font on every system. These
sorts aren't available across platforms so as a generic
it's not useful.
bobtung: There's Kai on Microsoft, on iOS, it's Android that
doesn't have Kai or Ming. It's important in ebooks, such
as Chinese. We usually use the Kai for citations,
quotations, and dialog.
florian: And you're saying it might not be universal, but it's
common.
bobtung: Many of them.
Bert: I'm not hearing progress.
fantasai: I think it comes down to we say either we don't care
about your problem,
fantasai: or we say we'll classify Kai as cursive and use cursive
vs serif as a way to switch
fantasai: or we decide we'll do something with font-style and add a
kai keyword there.
fantasai: I'm inclined to not do the first option. It should be
expressible in a generic way.
florian: What's wrong with creating a Kai category?
ChrisL: You have to decide what happens when you use it for
another language.
jdaggett: To put this in a different context, I think every script
has a different set of typographic decisions. There are
broad categories to classify fonts. I think it's not
really helpful for CSS to try and use generics to
classify.
jdaggett: The idea of a generic is you can use it across systems
and it's consistent. I don't think it's in this case or
any of the other cases, like slabserif.
fantasai: I'm not in favor of increasing the number of generics. I
think we need the very broad categories we have and they
serve as a generic fallback font family. I think we
should solve this specific problem by classifying it as
cursive or italic or making it a new font style value.
r12a: So you're saying you'd take Kai out of the serif?
jdaggett: I don't think CSS is the right place to make this
decision. It doesn't make sense for us to enter this
debate.
r12a: The proposal was from a Chinese group for the publishing
industry was that Kai was in the wrong place. I'm asking do
you want to keep Kai under the serif category or will you
take it out?
fantasai: He's already done that.
r12a: That's fine.
fantasai: That doesn't solve the publishing industry's problem.
jdaggett: I think you need font availability consistent across
the platforms and you don't have that, particularly on
mobile.
florian: I don't think this group should go with a large effort,
but if it's not done here, where?
Bert: We had two options, a new generic family of Kai wasn't
popular. Another option was a font style. Is that
reasonable?
Bert: What would be the downside of that?
Bert: We're not making progress.
jdaggett: I think this is better on the list with a wider audience
that might have knowledge that applies.
Bert: No new ideas?
fantasai: One thing we might want to resolve is if we're going to
address the issue. If we're not we should resolve it now.
If we're going to find a solution, then the list is
going to be charged with finding a solution
Bert: So should we try and come up with a solution, or say it's
not our business?
Bert: fantasai says we should solve it.
bradk: If we don't solve, it will implementors do different
things?
fantasai: Or no one doing anything.
dbaron: So what is the issue? Allowing authors to choose a Kai
font?
ChrisL: Allowing them to say I want two types of fonts, A or B,
and they're distinct and it should work for more than
Chinese.
fantasai: That's really vague. I don't think anyone will be
satisfied.
ChrisL: If not that, we should be providing fonts. We're moving
that way.
fantasai: ereaders don't have that option. Lots of devices don't,
so looking at system fonts is a thing.
fantasai: Chinese is also a pretty big download. If it's generic
enough than most Chinese ereaders would have it, you
don't want to trigger a download.
jdaggett: I think this requires extra knowledge that's not in the
room, so I think we should defer to the list.
Bert: I think we can conclude we won't solve it here, but I want
to ask, are we going to try and solve it at all, or give up?
jdaggett: One condition to solve this, a generic requires common
support across devices. If there is common support then
having a CSS solution for a generic makes sense, but if
you don't have a common support there's not much you can
do.
Bert: And how will we find that out?
jdaggett: I don't know. Maybe people in the Chinese publishing
group can come up with a list of fonts?
r12a: We can take this back to the group of publishers who brought
this up in Beijing.
fantasai: We might find the necessary fonts won't be on all
devices, for example my windows computer will only
likely have one because I have an English OS.
jdaggett: It's more Android that you'd worry about.
fantasai: If it's not targeted at the Chinese market, it won't
likely have more than one. If we limit to the Chinese
market we might find the availability.
jdaggett: Hong Kong too or just mainland?
fantasai: All of them. If you're looking across the world the
answer will be no. Will it be on all systems in the
target audience, we might get a yes, though maybe a no.
If your criteria is "all systems everywhere needs to
have these fonts", we won't have that.
Bert: I think we've discussed enough.
r12a: bobtung is here and he has a table that shows the major
systems have Kai, serif, and sans serif, but lets go back to
the list.
Bert: So the question is do we want this to go back to the list?
florian: So list or never or...?
Bert: Back to the ML and try and solve it, or should we not try.
We won't have a solution right now. Anyone thinking we
shouldn't move this to the ML?
Bert: No one objects, so back to the list for a solution.
fantasai: So the goal is the list will come up with a solution and
not entertain not having a solution unless we discover
it's intractable.
Bert: Yes. Okay with you jdaggett?
jdaggett: I'm not really comfortable with it, but we can deal on
the ML.
RESOLVED: Topic goes back to the mailing list
Unicode-range issues
--------------------
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0472.html
jdaggett: This is small implementation details about Unicode range.
Can someone project the link?
[Trying to find someone to project the link]
jdaggett: If people bring up the link in IRC, unicode-range allows
you to say for specified fonts, only download if you're
using it for this set of characters.
jdaggett: But sometimes you're pulling down a font just for the
metrics. So we have three fonts we can download, which
do we choose?
jdaggett: You can solve this many ways. You can decide on a
specific character, on the last font defined, any choice
is arbitrary. Chrome looks for the first font that
defines a space character.
jdaggett: Safari and IE claim to support this, but their
implementation pulls down the whole font no matter what
so that's not close to spec. Does it make sense to do
this or is there a better way?
ChrisL: I agree it's arbitrary and it's more important that we
pick something. The space thing is as good as any.
TabAtkins: Ditto.
dbaron: I think it's fine. Some units do depend on a particular
character. The x unit can depend on characters, the ch
depends on 0. So maybe it should be a 0 character for the
ch and space for everything.
ChrisL: If we're doing something arbitrary, why not 0 for
everything?
TabAtkins: I doubt we thought this through much when we
implemented but if you have spaces, you have 0s likely.
fantasai: For ch, a consideration was wanting numbers to line up.
0 will always have the width of the number.
Numbers typically are things you want to line up so we
wanted to pick from there.
jdaggett: Within a font there are a set of non-glyph-specific
metrics. What I'm getting at is the only thing needed is
the general font metrics to pick up a font.
jdaggett: For fonts that depend on a measurement for a glyph it
should be more specific.
Bert: I'm hearing any character is fine.
ChrisL: Given that one thing requires a 0, I think we should use
that.
dbaron: But if you're doing a thing using actual font metrics, you
do this.
fantasai: We use the space to measure the length of tabs.
ChrisL: Okay. I withdraw that.
dbaron: I think it's not the question of if it has a space, but if
the unicode range for the @font includes a space.
dbaron: If you were looking for a space and the space was in the
unicode range and the font didn't have it you would
continue to fall back.
Bert: So does that give you enough information, jdaggett?
jdaggett: It seems we can use the space character to choose which
fonts to look up and I can post the wording change.
jdaggett: Second issue in that e-mail, in situations with
overlapping unicode-ranges, the spec needs to be more
specific about loading behavior where you don't want to
load all fonts in that family that have a code point.
You only want to load one at a time.
jdaggett: If there's some character in the unicode range of two
different fonts, you want to pull the first font and
test before pulling the second.
<ChrisL> I support the proposed restriction on one concurrent
download per font family
ChrisL: I was about to agree, but what if you have bold, italic
and roman?
jdaggett: No, no. If you look at the match algorithm where this
would go is set 5 where you've already matched to a
specific.
ChrisL: That's fine.
Bert: Thoughts on implementation? If you're serializing things may
slow down.
ChrisL: If you initiate a download of a larger font you'd have to
throw it away, so this is saving time.
jdaggett: In the example you've got a Latin and a fallback and you
don't want to load fallback unless you really have to.
Bert: Okay. Different opinions?
Bert: I see thumbs up.
RESOLVED: Only download a single font per family when
unicode-range values overlap
Font Download Timeouts
----------------------
jdaggett: Next issue is the proposal from Google.
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0434.html
<jdaggett> https://github.com/igrigorik/css-font-timeout/blob/patch-1/README.md
TabAtkins: Yes. I will link to...
Bert: jdaggett did.
jdaggett: That's the post and the proposal.
TabAtkins: Right now browsers do different things handling a font
download that's taking a long time. Firefox and Chrome
will display nothing for 3 seconds and use the fallback
until it comes in. Microsoft immediately does fallback,
Safari shows nothing until the font comes in.
TabAtkins: These are all geared to when text was the only thing.
This is for a font-rendering descriptor that lets
authors control font fallback behavior. These are all
variants on the mandatory requirement
TabAtkins: If you have a less necessary font and are okay with the
user seeing a fallback, you can use swap or optional
which only uses the font if it's downloaded.
jdaggett: What happens on re-flow?
jdaggett: Let's say you hover over an element that changes the
style, what happens? Do you continue to use the non-
downloaded font or...?
TabAtkins: For consistency, for optional or swap if you hit the
case where you're sticking with fallback for page
lifetime, you're staying with it.
fantasai: What about resize?
TabAtkins: Maybe you won't re-flow.
jdaggett: This font made it or didn't and then it's like a state
that's maintained? If I add elements what happens?
TabAtkins: The name resolves to a particular font at a particular
time.
jdaggett: So even if I download the font it'll never appear on
that page?
TabAtkins: Yes.
jdaggett: Why is this necessary?
TabAtkins: The proposed version isn't as necessary. It can be left
off. The property is if all you know is that a given
element is important and needs to be displayed you can
set that at the element level instead of tagging each
font face.
TabAtkins: It means that if some elements show up some times you
might not trigger the font download mandatorily.
jdaggett: So if I set one optional and one mandatory on a
different element, what happens to the other element?
TabAtkins: That don't declare rendering?
jdaggett: Or additional section. You're saving a piece of state
and I'm not sure which one.
TabAtkins: On a per element basis you would override a piece of
state. So you're okay with your header re-flowing, but
you don't care about using the fallback on small pieces
of text.
TabAtkins: In the example the header always gets the branding it
wants.
jdaggett: Why can't this be done with script?
florian: As a user I don't like the mandatory and I want the swap
and I'll put that in my user stylesheet and I can't do
that if it's script.
jdaggett: You want this in the user stylesheet?
florian: I do.
TabAtkins: The mandatory strategy is pretty easy to do, the others
are a more involved piece of code, especially the
optional value.
TabAtkins: Using the font loading API for the more optional ones
is more difficult than it might look.
jdaggett: What's the default?
TabAtkins: We're not sure.
TabAtkins: It would be UA defined.
fantasai: I think it should be auto. The UA should be able to come
up with other ideas. If we say the current mandatory of
3 seconds, it doesn't let them come up with something
that's not a timeout.
jdaggett: And Firefox isn't a straight 3 sec timeout. We check to
see if it's progressed after the first 3 seconds and if
it has we wait another 3 seconds before fallback. So you
have to be careful not to block.
TabAtkins: So that seems like it should be UA defined.
fantasai: Do you have another name besides auto?
TabAtkins: Yeah, sure auto then
TabAtkins: Sometimes we just say it's UA-defined
fantasai: Yeah, and that has to map to one of the other options.
Bert: Other opinions?
MaRakow: Is anyone asking for optional? When they never get the
right font?
TabAtkins: I'll have to ask for more examples.
jdaggett: I think the timeout needs to have a definition. Like
starting when?
TabAtkins: When the CSS is seen more or less.
jdaggett: One of the problems is download-able fonts have a lot of
content and we only look once layout starts we tend to
not get into a good position in the queue.
jdaggett: Optional will fail a lot of times.
florian: It fails on first load.
TabAtkins: Optional is for fonts that are nice to have but not
required.
jdaggett: I think some of the resource based is better than CSS
TabAtkins: I'd like examples.
jdaggett: It's like you're loading the resource here for use in
another page.
TabAtkins: Sure, yes.
fantasai: That doesn't make sense.
TabAtkins: You're loading for other pages in the domain.
fantasai: What happens with iframes?
TabAtkins: They're a new page. They're a weird element, separate.
Bert: So do we continue working, or think it's a bad idea?
jdaggett: I think there's useful stuff, but I'm not sure this
fine-grained stuff is useful to give to authors. The
timeout may be something a user wants to set. It's like
anti-aliasing, it's a preference. I think the swapping
in and out is, well, does the user want to see the text.
When I'm on mobile Safari, I don't really care about
loading the font for 60 seconds and I just want to see
the text.
jdaggett: You're making it an author preference.
TabAtkins: The property value exists to override that.
jdaggett: As a user I couldn't override.
TabAtkins: You could apply it to the user stylesheet and who
cares what the author says.
florian: And if your browser doesn't allow user stylesheets, get
another one.
bradk: Another case for mandatory is if you have icon fonts.
florian: Mandatory is relevant on icon fonts so it's useful to
have in the hands of authors. That's the reason why.
jdaggett: We created the font-loading API to give authors this
level of control. They should decide how they want to
introduce it or not. I don't think this has to be
encapsulated as a CSS property
TabAtkins: You can use font loading for loading behaviors you'd
want, but making the common cases simple, the non-
defaults and better for users. The defaults are hostile
because they're trying to be conservative.
fantasai: It's user preference.
TabAtkins: It's per font. You don't want icon fonts to show with
fallback.
fantasai: Are icon fonts the ones that change letters into
pictures?
TabAtkins: Yes. The default is tuned for that kind of usage
instead of fonts that render text. They don't show
anything until the font is loaded and is bad. We should
preserve that ability, but being able to do this is
better.
fantasai: How did we end up in this mess? We've optimized for the
stupidity. The people that want the right thing now have
to learn more CSS properties to make your page nice for
the user.
TabAtkins: You've described CSS, yes.
jdaggett: Instead of using icon fonts, if you use an icon image
and you have the same problem.
fantasai: Use emoji.
TabAtkins: Remember we didn't have emoji when we made this.
florian: I think this needs tweaking, but I think it's worth
pursuing.
Bert: I heard looking into resource hints should be looked into,
can it be done with API, though user stylesheets can't.
Other things to look into?
bradk: Defining when timeout starts.
Bert: I didn't hear full opposition or support so it needs further
study.
TabAtkins: If we're okay to continue on the mailing list.
fantasai: I say we call it font-loading instead.
jdaggett: font-rendering is a terrible name
Bert: There's one more issue on fonts?
jdaggett: Last thing I wanted approval on was I wanted a CSS4
fonts so that when people have new ideas we have a
placeholder.
<fantasai> +1
fantasai: +1
TabAtkins: Given my experience, I recommend we make this a delta
spec and whenever you want to publish it's much easier
to keep error from creeping in.
jdaggett: Hopefully everything will be fixed.
TabAtkins: I hoped that too.
Bert: So you can work on CSS4 Fonts.
RESOLVED: Start editor's draft of CSS4 Fonts
Agenda
======
Bert: Okay, back to plinss
jdaggett: I have to go.
fantasai: Can you be back?
jdaggett: After 5pm your time.
fantasai: We'll save it for you.
dino: If we're going to break soon, this (Animations) might take
an hour or more.
dino: We could briefly talk about while we have krit...the filters
proposal? Or is something more important?
dino: Scrolling and animations is all one thing.
plinss: So break and get back to that.
[15 min break]
Received on Friday, 2 January 2015 14:55:32 UTC