- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Nov 2015 20:38:15 -0500
- To: www-style@w3.org
font-weight-adjust
------------------
- There was conversation about the usefulness of having a property
to try and adjust the font weight of a fallback to make it
more consistent with the primary font.
- There were several arguments against this proposal:
- It wouldn't work well/at all across different scripts such
as Latin to CJK.
- Weight isn't consistent across fonts.
- This would only work well on Latin text.
- There was a lack of examples of where this was a real-world
problem.
- It was decided that was better addressed by using @font-face.
Box Alignment
-------------
- RESOLVED: All layout modes use "true" alignment by default for
the alignment properties.
- There was some bikeshedding on "true" as a keyword, and TabAtkins
will create a poll for a potential rename from the suggestions in
the minutes.
- Everyone was actioned to review the Alignment spec.
Dev Meetup in Sydney
--------------------
- It was suggested to hold a developer meetup in Sydney.
- Tentative schedule is the evening of Feb 3rd, hosted at Google,
happening around 6pm or 7pm.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: dbaron
font-weight-adjust
------------------
<astearns> http://www.w3.org/mid/F1E15038-FA2D-485D-B328-089293E691AC@rivoal.net
Florian: There's an ongoing thread about font-weight-adjust.
Florian: If you're trying to pair fonts in a document, and have a
font that looks the way you want, we can adjust when x-
heights don't match using font-size-adjust.
Florian: We have a similar problem with font-weight. You might
want to match 2 different fonts with different ways in
the document -- or especially with fallback (doesn't
load; Unicode ranges).
Florian: If the pairing of fonts is to your taste except font
weights don't match, then you have an issue.
Florian: Font weights have numeric value, but the number doesn't
have a meaning against some measurement.
Florian: We want a way to say 400 weight for main font but 600
weight for fallback.
Florian: John doesn't seem to agree on the problem or the solution.
Florian: I understand disagreeing about solution; more confused
about disagreeing about problem.
jdaggett: If you go across different scripts, e.g., Latin to CJK,
or Thai, Arabic, pairing typefaces is a classic design
problem for type design.
jdaggett: It's not a simple problem to solve. Type designers spend
a lot of time thinking about how to express the voice of
one typeface in a different script.
jdaggett: It's not just weight
jdaggett: What I don't agree with in the formulation of the
problem is the notion that you're using a single font
list for all languages
jdaggett: That's what people do, but it's not the right thing to
be doing. The right thing: if you have content in
Japanese, use appropriate Japanese typeface; content in
Greek, use appropriate Greek typeface.
jdaggett: Ideally those are all typefaces you selected that
support the specific script.
jdaggett: Making a design decision for each language...
jdaggett: You could make a universal font list work, but not ideal.
jdaggett: Matching on weight is difficult. A particular weight in
a typeface may be difficult to match with a different
typeface.
jdaggett: When you're talking about a fallback situation, not
providing a webfont, you're stuck with a tough problem.
The way the typeface is designed used a different set of
principles, so just matching weight won't get you much.
Florian: I agree just matching weight won't get you much. I don't
see why it's useful to have the size adjust and not have
this one.
jdaggett: Size is a linear scale; weight is not consistent across
fonts.
jdaggett: One family may have regular and bold; another family may
have broader range.
jdaggett: Size is consistent with a little tweak; font-size-adjust
gets you that. Weight is not consistent. Taking a font
designed one way, comparing to another family not
designed with same principles, won't get something that
matches.
jdaggett: The example I wanted to show:
http://typeproject.com/fonts/tpmincho
jdaggett: They've designed a range of font families. There's a
high-contrast face. Contrast is how thickness of
vertical stems compares to thickness of horizontal stems.
jdaggett: Can see similar construction of Latin typefaces.
jdaggett: Bottom one is a low contrast face. The verticals and
horizontals are roughly comparable.
jdaggett: Going from one face with a different contrast to a
family without that same contrast, no matter what the
weight is, you won't get something that's matching.
jdaggett: That weight value doesn't move well across families.
Florian: Isn't that also true about size adjustment?
jdaggett: The step function, the weights available, is going to be
different. With font-size-adjust, you can tweak the size
a tab and get something comparable. Though not a be-all-
and-end-all solution.
jdaggett: I don't think what you're proposing is going to work in
practice.
jdaggett: What Jonathan was saying on the list: if you want to do
something like this, pair a Latin face with faces from
different locales, you can do something like this
already using @font-face rules with local().
Florian: If you were to use a mechanism like that, you have to use
fonts side by side. For most random pairing of fonts,
no [...].Just like for size adjustment need to look side-
by-side and pick specific value.
zcorpan: As I understand it, the ability to use different fonts
for different languages is orthogonal; you can do that
with :lang() selector.
zcorpan: This is only the case where you want to fix font weights
between primary font and fallback font, then you only
have 2 fonts for one specific language to deal with.
zcorpan: I don't see that this is trying to fix everything with
one mechanism.
zcorpan: I think this is just fixing weight of primary font vs.
fallback font.
jdaggett: You think this mechanism makes sense?
zcorpan: It's not saying proven to be necessary, but I think the
argument that it won't fix everything and that you should
be doing language-specific instead is orthogonal.
jdaggett: If you're doing it language specific, you can say that
for bold you want a particular weight.
jdaggett: The only way to pair faces from different fonts is to
know those actual fonts.
jdaggett: So you can use @font-face with local().
jdaggett: To match what he's talking about, you have to know the
faces.
SteveZ: I wanted to say 2 things. font-size-adjust doesn't really
do all the adjustments you want; it doesn't deal with
Thai, which has small x-height on some letters due to
additions above and below, so matching a Latin face to
Thai using the same font size typically looks ugly; Arabic
has similar types of problems.
SteveZ: My concern overall is that all of these quick fixes work
well for Latin text but don't work well for international
text.
SteveZ: Trying to fix each problem means we end up with large
number of properties: then you'll want contrast, and then
how do they interact when they're all specified?
SteveZ: It makes more sense to put in a language map, where some
properties will allow you to pick specific things for the
language, rather than doing clever things that do matching
without understanding what's going on.
Florian: In that direction, John was saying in some cases use
language tagging and in some cases use @font-face.
Florian: What I didn't understand was for Web fonts (not local
fonts), does the fragment identifier thing work?
jdaggett: I don't understand why font packaging came up in that
thread. It's orthogonal to that issue.
jdaggett: It doesn't matter whether a font is packaged or separate
fonts. No current browser supports TrueType collections.
Florian: Your mechanism only works for local fonts.
dbaron: [explains about @font-face rules each being a single face
with a single weight]
jdaggett: TrueType collections is a simple format; just a bunch of
offsets for the fonts; effectively still loading
individual fonts
Florian: If we were to have @font-face rules that pointed to a
collection, then this would be a problem.
jdaggett: But this has little bearing on the original case.
jdaggett: But to be clear, there will never be a format where a
single @font-face rule points to a set of fonts rather
than a single face.
<ChrisL> we will have @font-face rules that point to a TTC. But
they will use fragids to point to individual faces, not
the collection as a whole.
dauwhe: Do you have examples of sites that are visually confusing
now because of problems matching weights on fallbacks?
dauwhe: I've been trying to construct examples with fonts on my
machine, but haven't been able to yet.
Florian: I have seen examples within Bloomberg, with requirement
to use Latin font for all Latin and digits even in other
languages; digits match badly against CJK font.
Florian: The correct answer may be to use digits in the CJK font.
jdaggett: Going between Latin and CJK generally you want a
different size altogether.
jdaggett: If you're going to support multiple locales on a site,
the decision about attribute and typeface to use is a
design decision.
Florian: As a design decision, you have Latin letters in the CJK
that you want to match... to adjust. You could say not to
use the Latin font, but their design decision is to use
the Latin font everywhere.
jdaggett: It's difficult to take 2 typefaces designed to different
principles together.
Florian: That specific example, the most glaring example was
weight; fixing weight wouldn't make it perfect, but
probably tolerable for most readers.
Florian: I think using @font-face is adequate for solving this.
<ChrisL> +1 @font-face suffices for this
jdaggett: Apple's UI font has an explicit cascade list set up. If
you are drawing in UI in the system font, and hit a
different script, there's a chain of postscript names
that identifies all the fonts that will be used as
fallbacks.
jdaggett: That's a controlled environment, they know the set of
fonts.
Florian: Apple is not the only case where there's a controlled
environment. Webfonts can also be controlled environment.
jdaggett: You can do the same thing using ...
Florian: I was unclear about collections (that's cleared up); I'm
still fuzzy about sizing part of it.
Florian: We can try to see if that works.
TabAtkins: I agree with John; unless using @font-face is really
bad or hard to work with, we should stick with @font-
face instead of duplicating functionality.
Myles: I also agree with that.
Scribe: TabAtkins
Box Alignment
-------------
fantasai: There's a lot of values in this spec.
fantasai: The ones we need to keep are positional alignment,
baseline value, and the distributed-alignment keywords.
fantasai: The major point where I'm pretty unsure is the
overflow-alignment keywords.
fantasai: If you try to use margins for alignment, you do "safe"
alignment - if you're bigger than the container, you
don't center or end-align, you always start align.
fantasai: In Flexbox/Grid, you're aligned absolutely, so you can
overflow off the start edge.
fantasai: Margins do that because you can't scroll to content that
overflows the start edge *of the viewport*.
fantasai: So margins might not always center, but it ensures it
won't overflow to the unscrollable area.
fantasai: So one issue is, what should the alignment properties do
on layout models other than Flexbox/Grid? Should they be
consistent, or use the margin behavior?
fantasai: Second issue is, whatever the default is, do we need a
switch to change, or do we need some other solution to
let the user reach the content in the unscrollable
region?
fantasai: So, what should the default behavior of the alignment
properties be?
TabAtkins: I'm for simplicity, so I'm okay with them all being
"true".
dbaron: I guess I'm okay with them all being "true" by default.
dbaron: Though, it's a little bit of a footgun, but it is easier
to understand.
TabAtkins: Agree - I've had authors ask me about centered Flexbox
overflowing off-screen, so I had to tell them to use
margins. But it's annoying to *not* do "true", too.
szilles: [question about center on text]
szilles: It's clear what overflowing off the flow direction, means.
szilles: But less sure about what overflowing means from a wrap
point of view.
fantasai: That's a different issue; these don't apply to text.
fantasai: Anyone object to making everything "true"?
[no objection]
dbaron: I'm okay with it, given that you can specify the "safe"
behavior.
RESOLVED: All layout modes use "true" alignment by default for the
alignment properties.
fantasai: Now, is the current safe/true switch what we want, or do
we want something even smarter?
fantasai: Or is there some other solution to the problem of
centered things overflowing into the unscrollable region?
TabAtkins: I doubt we'll be able to come up with a general
solution to unscrollable areas.
TabAtkins: But I'm fine with the current switch. A little
footgunny, but probably fine.
fantasai: So is everyone fine with the current switch syntax? Or
just have the "safe" keyword, and make unspecified be
"true"?
dbaron: We might eventually want to apply this to text-align,
which defaults to "safe".
szilles: I think it's better to have authors specify what they mean.
fantasai: Too late for that unfortunately - the properties already
allow it to be omitted in implementations.
fantasai: [discusses serialization]
fantasai: If you write "true center", it'll serialize back to just
"center", since omitted defaults to "true".
TabAtkins: So per dbaron's argument, I think it's fine to leave
"true" here. We don't need it yet, but it'll simplify
merging in more alignment properties later.
szilles: +1
fantasai: Anyone want to bikeshed the keywords?
dbaron: true looks like a boolean ...
[bikeshedding "true"]
[literal, exact, always, dwim, honored]
<fantasai> force?
<TabAtkins> even-if-overflow
<dbaron> unsafe?
ACTION TabAtkins to write poll about naming of "true" keyword,
using suggestions in the minutes.
<trackbot> Created ACTION-727
fantasai: I remember why we had it vary per el - we wanted to do
<center>/etc through these properties, and they needed
to be "safe".
fantasai: But maybe we can key that to "legacy".
TabAtkins: Or just drop it, like we discussed, and handle <center>
somehow else, or not at all.
fantasai: Yeah, so we'll discuss that with dbaron later.
fantasai: So really we're just blocked on review.
ACTION everyone to provide feedback for the Align spec.
Bert: There's two kinds of "true" centering for text - overflow to
the left, and ignoring floats - center text while ignoring
images on the side.
fantasai: That's tricky, because currently text-align only
distributes extra space on the line after line breaking
fantasai: But this would affect text-wrapping.
TabAtkins: Maybe that's a separate ability, then - the ability to
ignore floats for line-length determination. Then you
can still just safe-align or something.
Dev Meetup in Sydney
--------------------
Bert: Sydney has John Allsopp, the Web Directions conference guy,
and he can organize something if we want.
Bert: So do we want to attend that, or speak at it?
[discussing Sydney meeting timing]
Rossen: So this meetup will happen one of the SVG meeting days?
Rossen: And this is somewhere in Sydney, tbd.
Bert: Yeah, depending on how big we want it to be. John Allsopp
has some space...
dino: It's tiny.
shane: We can probably offer a venue for this.
Rossen: Do you have a big enough space?
shane: It can hold 150 people.
shane: I'll need to confirm it, but it should be fine.
Rossen: So what day is it?
shane: Feb 3rd is FXTF. Maybe best overlap?
astearns: Then, people who need to leave might still be able to
make it.
Rossen: So idea is that, on Wednesday (Feb 3), we'll have the
biggest mass of standards people. All SVG, CSS, and maybe
some Houdini.
shane: Except CSS people who have to leave that night, but it
doesn't sound likely.
shane: And I think most US flights leave in the morning, anyway.
Rossen: Sounds good. Who's organizing?
Bert: I can coordinate.
shane: Email me so I have a permanent record.
TabAtkins: I'm giving a <20min Houdini talk next month, I can
re-give it.
Rossen: Is this meant to be CSS-only? Or SVG too, etc.
Bert: I wasn't thinking about it yet. All 3 would work.
shane: I agree.
Rossen: Okay, sounds great. Let's organize that. Tentative
schedule is the evening of Feb 3rd, Wednesday, hosted at
Google around 6pm or 7pm.
shane: Worst case, if Google can't host, Someone else probably can.
<br type=lunch duration=1h>
Received on Thursday, 19 November 2015 01:39:16 UTC