- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 19 Jul 2018 20:27:11 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Fonts 4
-----------
- RESOLVED: If the author specifies oblique, and synthesis is on, we
fall back to synthesized oblique. (Issue #514)
- RESOLVED: The fallback list for oblique is synthesized oblique,
italic, roman, next font. The synthesized step is
skipped if font-synthesis is turned off. (Issue #514)
- The group will ask the TYPO group to review the previous two
resolutions once they're in the spec to ensure they match author
expectations.
- RESOLVED: Close the issue no-change, fantasai to write a comment
for opentype spec authors (Issue #519: Italic & Oblique
benefit from not including a <number>)
- RESOLVED: "font-named-instance" descriptor in @font-face with
values 'none' or <string> and in the
font-variation-resolution between step 4 and step 5
(Issue #525)
- RESOLVED: Move this issue (Issue #2540: Content authors want to
modify style based on the presence of color fonts) to
be a more general issue [because there is a larger need
for properties to know if a resource downloaded properly
and this should be a part of that larger conversation].
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Scribe: heycam
[ A section of the group did a breakout on Transforms, Animations,
Transitions - all open issues (see previous minutes). They
rejoined the Fonts conversation after about an hour ]
CSS Fonts Level 4
=================
<fantasai> https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22Agenda%2B+F2F%22+label%3Acss-fonts-4
font matching should not favor italic as a fallback for oblique
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/514
myles: This is pretty straightforward
myles: I migrated this issue on behalf of jkew
myles: Currently the way the spec is worded, if you say you want an
italic font, the algorithm says UAs will try to match oblique
ones afterwards
myles: and vice versa
myles: Jonathan Kew says this isn't how it used to be
myles: Used to only go in one direction, fallback from italic to
oblique
chris: Correct, CSS 2.1 just went one way
florian: Did we change it bidirectional intentionally?
florian: or just felt like the right thing to do at some point?
myles: It was not intentional, don't think it was discussed in the WG
chris: Also has a variable fonts interaction, with the italic axis
myles: It's somewhat involved, but doesn't fundamentally
myles: There are italic and oblique fonts, can be expressed with
italic axis
myles: I don't have a particular thought about this
myles: Seems like there are some arguments to change it back
myles: no arguments from me to keep it as it is
astearns: Some people on the thread say it should stay as it is
astearns: to avoid synthesizing things
chris: But we also have a property to turn off synthesizing if you
want
fantasai: [reads jfkthame's position]
<fantasai> jfkthame's position:
https://github.com/w3c/csswg-drafts/issues/514#issuecomment-335582104
fantasai: I think it makes a good argument about making a
distinction between oblique and italic
fantasai: but there are two cases here
fantasai: If you don't have oblique, instead of falling back to
italic, use slanted normal
fantasai: but if we've turned off font synthesis for italics, you
can't have a slanted normal face
florian: Then what?
fantasai: Only choice for fallback then are use italic or normal
chris: Then you fall back to normal face
fantasai: Which risks losing the distinction between normal and
oblique
fantasai: More important than the distinction between oblique and
italic
chris: Risks both ways
chris: If someone explicitly wants oblique, it's probably in
contrast to italic, like in some math
florian: They may be
florian: probably? not sure
myles: I think it would be valuable to know which browsers do what
myles: In WebKit italic and oblique are the same
myles: Is that true in other browsers?
frremy: Edge does have a difference
frremy: and we can choose the angle
eae: Blink is the same
fantasai: If you have a family with italic and oblique and normal,
if they choose italic or oblique, they should get what
they requested
fantasai: We have syntax to distinguish them, implementations
should, too.
myles: Now the spec allows our behaviour
frremy: I recall in Firefox it's different
emilio: Since Jonathan filed the issue, I assume so
myles: So WebKit is the only one to treat them the same
fantasai: Going through Jonathan's logic, there's a preference if
you specify oblique, do that, then synthetic second, then
what comes third?
fantasai: If synthesis is disabled
fantasai: I argue fall back to italics at that point
[general hmms....]
chris: I'm slightly worried about that, it's a third option nobody
is asking for
fantasai: Nobody was asking about the case of synthesis disabled
frremy: Does anyone support disabling synthesis?
myles: Firefox and WebKit do
florian: What's the scope?
astearns: In the @font-face rule
florian: I think I will argue that if you disable fake italics, you
never disable fake oblique
myles: I don't believe there's any implementation that models fake
italics as anything other than fake oblique
florian: if you asked for oblique, and you've disabled font
synthesis, you should still get synthesized oblique
myles: No
chris: That's not true
chris: First, the definition of "fake"
chris: In variable fonts there's an axis called ital which is the
oblique axis
chris: That shouldn't be turned off by turning off fake oblique
florian: I'm saying you should never be able to disable fake oblique
myles: No
myles: Web authors mean it when they say disable synthesis of
everything
fantasai: If you have the font you use it no question
fantasai: There's a big difference between what the UA can do and
what the designer intended for italics.
fantasai: For obliques, the difference is much smaller
myles: I understand that distinction, every author I talked to [....]
astearns: I hear if synthesis is disabled, it means never change the
letterforms
astearns: They happen to know that this font family has an oblique
face, but the web font package forgot to download it, they
still don't want a synthesized oblique
florian: For italics I totally buy it
florian: less convinced for oblique
eae: Why not make it explicit, for oblique?
florian: Sure
florian: but people disabling synthesis in general, I think allowing
synthesizing oblique is ok
myles: font-synthesis talks about weight and style
astearns: Style should block both italic and oblique. If you want to
distinguish them, it would need a new value
florian: So then what do we display
fantasai: there are two proposals. Jonathan Kew's is, if you don't
have oblique, you fall back to synthesis
fantasai: Alternative is to fall back to italic if it exists
florian: It's arbitrary
florian: It's possibly true author is trying to contrast italic and
oblique
fantasai: Can't think of a case when you want to contrast with
oblique but not also contrast with roman
koji: Author is specifying oblique explicitly
koji: I don't think they care what it looks like if synthesis is
disabled
fantasai: If the author specifies oblique, and synthesis is on, do
we fall back to italics or synthesized oblique?
frremy: Synthesized oblique
chris: Agreed
RESOLVED: If the author specifies oblique, and synthesis is on, we
fall back to synthesized oblique.
myles: Now it's legal in the spec to alias oblique and italics
myles: I think this would make this impossible
astearns: We're reverting back to the CSS 2 definition
chris: So far
frremy: I think the spec is very broad
frremy: If you alias both of them, this section doesn't apply
frremy: since you don't have a font-style that's oblique
florian: Is this lack of distinction something you pro-actively want
to preserve?
myles: Haven't investigated how difficult it would be to get rid of
it
myles: Don't know how CoreText differentiates the two
myles: Given Chrome uses CoreText, I guess it's ok
<tantek> I feel like we need more typographer expert opinion to make
a more informed decision about these things. We should have
discussed this in April when we could have asked a bunch of
Typolabs people
skk: If oblique is specified, which direction?
myles: In horizontal it's well defined
skk: In vertical? There's no definition
florian: We have an issue open for that
dbaron: We spent half a day talking about it once
<dbaron> prior discussion of synthesis direction in vertical text
was I think
https://lists.w3.org/Archives/Public/www-style/2013Jul/0065.html
astearns: Other part is if font-synthesis for style is turned off
chris: If there is already an italic, do we use that in preference
to normal?
fantasai: I think we should
astearns: I think we should not
florian: My preference is synthesize anyway, but I've heard the
objections
frremy: Fall back to normal is my normal
chris: Me too
astearns: Turning something off makes a path available that wasn't
there before
fantasai: No, it just means you've got a list of four preferences
instead of three
fantasai: non-synthetic oblique, synthetic oblique, italics, normal
astearns: I'm saying when synthesis is on, you don't have a path to
get from oblique to italics
astearns: Weird to add that path when synthesis is turned off
fantasai: You have it by having oblique in the font selection
algorithm
frremy: There may be a case, if you have a font with a custom font
without a normal version, but does have an italic, you can't
synthesize ...
florian: Just put it in your fallback chain
fantasai: You can't
fantasai: I think François’ point is good
fantasai: There are fonts that only have italic
fantasai: So my pref is that we should have italics in that fallback
chain, either before or after normal
myles: [writes some options on the board]
florian: If there is no roman, do you choose italic as fallback
fantasai: We can also not decide this now
tantek: Yes
chris: They will say never synthesize!
florian: They typically don't know about fallback on the client side
tantek: I don't agree
tantek: Typo Labs people were very aware of web ecosystem and how
font loads fail
tantek: I think they understand the context
florian: Fair enough
myles: One other issue. Oblique is not the initial value of
font-style, so turning on oblique is an author saying "make
it not the normal way it looks"
myles: so probably shouldn't put normal before italic
chris: Good point
RESOLVED: The fallback list for oblique is synth oblique, italic,
roman, next font. The synth step is skipped if
font-synthesis is turned off.
astearns: Let's consult with typo experts to see if it matches
expectations
chris: Let's put it in the spec and then ask them
<skk> Last Tokyo F2F, people from DTP said no oblique exist in
Japanese vertical writing type setting. But recent ebook
related people want to use italic/oblique font style.
Italic & Oblique benefit from not including a <number>
------------------------------------------------------
Scribe: frremy
github: https://github.com/w3c/csswg-drafts/issues/519
chris: I read the entire issue, and didn't understand what the issue
was about
myles: I think the proposal is relative to variable fonts
myles: You started being able to say "oblique 30deg"
myles: Would prefer this not to be allowed
chris: Why? you can still not define it if you don't want
fantasai: Otherwise you get the value defined in the spec
fantasai: not a value taken from the font
myles: If you specify "oblique 0" you get roman
myles: but with variable fonts, but you could make a 0deg oblique
fantasai: Is there a field that says what the preferred oblique
angle is?
myles: There is the concept of named instances
myles: you can say then "oblique" is this set of values
chris: But the names are not standardized
myles: Right, this isn't formal enough for us to rely on
myles: There might be one in there with italic, but there might be
many
chris: And it could be localized
chris: so let's not do this
chris: Proposal is to close no action
myles: I agree
fantasai: And add a comment that if this is wanted the Opentype spec
adds some field for a value then we can consider using
that instead of 14
fantasai: otherwise we will not do anything
RESOLVED: Close the issue no-change, fantasai to write a comment for
opentype spec authors
Access to named instances in variable fonts
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/525
myles: This is one of the top requests I get from typographers
myles: Named instances are how you can associate a string with a
position in the variable axises space
myles: They want to be able to use them
myles: The only way I see would be a property taking that name, and
overrides every other property
myles: but that isn't great
heycam: Could we create a shorthand that would override these
properties?
myles: The problem is that the axes are not always linked to the css
axes
eae: And the axes might have similar names but be used for things
unrelated to what css means
chris: Another way for doing that is to add a new descriptor in
@font-face
florian: Does that turn-off all properties that would be used for
match
florian: We can ignore all the values specified elsewhere
fantasai: We could pull the named instance, apply CSS modifications
on top of it.
heycam: But what if you want to start from a point, the named
instance, then tweak one or two axes only?
florian: Can we add a new initial value "auto" that is ignored by
default but would override named instances otherwise?
fantasai: You pick a specific point in the space, and use that as an
@font-face directly
fantasai: and then you can say what it is even if this is not what
the font says it is
fantasai: You should be able to do this for axes
chris: The downside is that authors might use the named instances
and opt out of the axes
chris: First model is you ask one specific font and use it
chris: Second model is the css model, you create families and use
properties to change within the families
fantasai: We could also override the named instances's standard axes,
like the weight
fantasai: So we pull the named instance, set the various
non-standard axes according to the named instance's
settings
fantasai: but set the standard axes according to the CSS system
fantasai: which might override what the named instance would
otherwise be, but keeps the CSS system and the font
settings aligned
fantasai: E.g. if someone picks out an extra-black instance, but
doesn't set it to font-weight: 800, then we apply
font-weight: 400.
myles: I think there are two design requirements
myles: First is that fonts don't always download
myles: Content blockers can for instance drop fonts, so we need to
be resilient to font not being downloaded
myles: Second is that the nested cases, where a span needs to be
able to bold from its parent
myles: We know that because we allow "Arial Bold" for instance as a
font family
myles: but we do this in a smart way, so if you unbold, you get back
Arial
chris: So, we would have the same kind of game in this case, correct?
myles: Yes
chris: The advantage of having the named instance in the descriptor
is that you can use the properties on the child element the
normal way
chris: which might be in that font-family or not, but this is the
same as css from that point
florian: I'm wondering if we named instances control things that are
not css-y, then these values should be controllable by css
florian: but does a named instance need a value for all axes?
myles: Yes, it does have a value for every axis
myles: So your proposal is not possible, because there is no default
florian: We need a way of saying "this font-descriptor value is for
font-matching only" or "this value is a set value, ignore
css
chris: Basically, this is all because of variable fonts
chris: Before we defined a nice set of things and it worked out
chris: but with the ranges we have now, it would create many values
florian: If you set a named instance, and don't use descriptor for
weight, the range will continue to apply, override the
named instance
florian: but if your descriptor is explicitly set, then you would
stick to that value
florian: For instance "font-weight: <something>" and then you don't
use the value from the font instance
myles: In the spec right now, there are many places from which the
axes values can come from
myles: There is a specific order
myles: In this order, descriptor are early, css is after
myles: We could say that the named instance applies where exactly it
appears in the order
myles: then you continue to apply further rules as usual
[myles summarises the precedence rules from
https://drafts.csswg.org/css-fonts-4/#font-feature-variation-resolution ]
myles: My proposal is that we could add a new signal to this
algorithm
myles: that would be the named instance
myles: and it would be applied very early, other things come after
florian: What ordering are you proposing exactly?
<myles> https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence
myles: Between step 4 and step 5
myles: a new descriptor that is either auto or string
myles: If the value is a string, you look at the font, find that
value and apply the axes
chris: I like that
eae: That seems nice
eae: but if you fallback then these values don't apply
eae: You could have one single glyph that uses another font
fantasai: But then you have the issue that the axes might not be
what css thinks they are
myles: It's a little scary if we want to apply the axes of one font
file, figure out if you are bold, then use these values in
another font
myles: If the first font doesn't load, then you get a different
result
fantasai: Yes, I think if you want this, you should also set
font-weight: bold and that would fallback properly
eae: Authors might not do that
myles: They will need to, because the ordering I propose will have
font-weight win over the named instance
myles: With this proposal, the named instance will set bold, but the
font-weight will override this later
fantasai: So the values we use to render are the ones that are in
the computed styles
florian: And discoverability?
florian: Better devtools?
(general support for myles proposal)
PROPOSAL: descriptor in @font-face with values "auto" or "<string>"
and in the font-variation-resolution between step 4 and
step 5, we lookup the values of the named instance in the
font and apply them
frremy: Can we make it a list of names?
frremy: So that way you can handle fallback fonts kind of better
florian: Are you matching the lists? or just go through the whole
list per font in src?
myles: We can extend it later to do that, if needed
astearns: Let's not do this, we can do this later if we want
myles: It is backwards compatible to convert this to a list later
frremy: Ok, sounds good
dbaron: But what if you have different font files?
dbaron: What if you want different names per font file in the src
list
myles: You should only use src lists for cases when the browsers
support different formats
various: No, we don't want to do that
myles: Not different files
chris: myles: Let's do this later
dbaron: What if instead of a separate descriptor you have a function
that goes in the src: descriptor
astearns: If you want that, I think you want that at the "src" level
myles: If we want to extend this, we can come up with new ways later
(bikeshedding about the name)
(font- prefix because all of them have that)
(-named-instance because that is what this is called in the spec)
chris: I like font-named-instance, let's use that.
astearns: So we seem to be converging font-named-instance
florian: I'm not going to object
RESOLVED: "font-named-instance" descriptor in @font-face with values
"auto" or "<string>" and in the font-variation-resolution
between step 4 and step 5
(one more cycle of the bikeshedding, but the arguments are about the
same)
fantasai: We can rename things in spec, that's an editorial change
fantasai: When we expose terminology through syntax, can chose a
better name if we want
chris: Yes, but I still prefer what we resolved
heycam: Can we use "none" instead of "auto" though?
RESOLVED: s/auto/none in previous resolution
Content authors want to modify style based on the presence of color
fonts
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2540
myles: This one can probably fit in a few minutes
myles: The idea is that color fonts are so important to the design
of the website that you should be able to chose other styles
of the page depending on whether the browser supports colors
fonts
myles: like a media query
florian: Is that related to the media query for image types?
florian: Maybe you could load some font type, then you load another
font
leaverou: You can detect variable fonts with font-weight: 399
fantasai: Not entirely because the browser supports it but the os
could not support it
fantasai: font-loading could be turned off, or the download didn't
work
fantasai: So the relevant question is "did my font load"
fantasai: and we don't have the means to create this right now
florian: Custom media query?
myles: This should be in javascript
dbaron: We had a discussion a while ago, and we had resolved to add
a few @support things
dbaron: and TabAtkins and I didn't work them into the spec
dbaron: We should start with these easy features first
dbaron: and then we should think about more complex things, if we
need
heycam: We can maybe add @supports for the font descriptor values
fantasai: Yes, but the font might not have been loaded, so your
styles will still be wrong
chris: So whether or not you *can* load isn't good enough
myles: Which is why I recommend javascript
florian: Does the same argument apply for image formats?
astearns: Seems like to me
florian: Though an svg image, if you download it, you can maybe not
support one of its feature
TabAtkins: svg are very complex, but most images are pretty much the
same
florian: I still believe it's the same problem, it's a continuous
scale
fantasai: I think we are not going to solve this in fonts-4 either
way
fantasai: so let's discuss this maybe in conditionals-4
myles: So let's close the font spec issue, and redirect to a more
general issue
fantasai: We want to frame this as "did this resource download and
load properly"
RESOLVED: Move this issue to be a more general issue
<br>
Received on Friday, 20 July 2018 00:28:06 UTC