- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 19 Jul 2018 20:27:26 -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.
=========================================
Values & Units 4
----------------
- RESOLVED: Close this issue as no-change (Issue #2798: should ic
unit use 永 instead of 水?) (largely for process reason,
changing writing-modes atm is too much pain)
Text 3
------
- RESOLVED: revert the previous lone CR resolution, and treat it as
any control character
Fonts 4
-------
- RESOLVED: Adopt the mutli-value descriptor syntax for @font-face:
override-color: [ [ <string> | <integer> ] <color> ]#
(Issue #1125)
- RESOLVED: skew glyphs around their center for synthesis operations
(Issue #2869)
- RESOLVED: Do 5 and 6 from
https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0003/italics-vertical.png
for italic and obliques with positive angles (Issue
#2869)
- RESOLVED: A note should be added that UA should filter at the time
the user selects the font, or warn the user of the
consequences (Issue #2855: Restrict unicode range of
emoji generic family)
- RESOLVED: Closed no-change except if the filer wrote a test and UA
shows diverging behaviors (Issue #2537: Prioritizing
font-stretch over font-weight seems wrong)
- RESOLVED: Start searching for oblique starting from 11deg (Issue
#2539)
- RESOLVED: Close no-change, due to webcompat (Issue #1676:
font-display descriptor value names)
- RESOLVED: Move font-synthesis to long-hands, and simplify the
shorthand:
* font-synthesis: all | none | [weight || style]
* add font-synthesis-weight, -style, and -small-caps,
all with grammar "auto | none", initial "auto"
(Issue #1641)
- Resolutions on variation selectors exist in earlier F2F minutes:
https://lists.w3.org/Archives/Public/www-style/2011Jun/0325.html
- The proposal to allow a factor per font to address issue #2857
(font-size-adjust per font) seemed to be generally favored but
the group ran out of time to resolve
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Scribe: frremy
Values & Units
==============
ic unit character basis
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/2798
astearns: Who want to take the IC unit issue?
heycam: I don't think it's super important because IC isn't
implemented yet
florian: Not in any browser, but maybe some epub/print impl
heycam: The glyph should be Chinese as I understand
heycam: I propose the Yuan "eternity" character is more archetypical
than the one currently used
heycam: so I proposed to switch to this instead of the "water" char
fantasai: Why not, but we also need to change writing mode
fantasai: We just need to make sure it is always full-width, and
common to all cjk fonts
myles: How many fonts that support both of these chars support
different advances for them?
florian: That should be excessively rare
myles: I understand
xidorn: I don't think this will be a compat issue
fantasai: I agree there should be no compat
<dbaron> the unicode codepoints for these characters differ by 4,
fwiw :-)
Main concern is maturity of css-writing-modes-3
fantasai: Could be make one version of writing mode do one char,
then the next one switch to the other?
[no]
heycam: I am fine leaving the char as is
myles: Is it gonna be likely to have a font that supports one vs the
other?
heycam: Not if you don't artificially limit
florian: For newspaper, you could have a few glyphs just for the
name of the newspaper
florian: but any font for a normal text would include both
RESOLVED: closing this issue as no-change
fantasai: (largely for process reason, changing writing-modes is too
much pain)
CSS Text
========
form feeds and carriage returns
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/855
florian: In Berlin, we made two conflicting resolutions without
noticing
florian: frremy noticed after, and raised that
florian: One is that we should render control characters
florian: Two is that cr should not be rendered
florian: That is not very consistent, we didn't need to specialize
cr given the first resolution
florian: No strong opinion, but we could change this.
frremy: Edge already does render the CR block
frremy: I thought rendering of chars was not enabled, but Rossen
enabled it, but ...
frremy: I'm proposing to move to Edge behavior, consistent with
first resolution
myles: Is there a proposal?
florian: Proposal is discard resolution about treating CRs
specially, treat them just like any other control character
florian: Revert the resolution we made for lone CR
florian: then the resolution we made for control chars will apply
astearns: I like the consistent behavior
heycam: I'm fine with that
florian: is there anybody objecting?
(no objection)
RESOLVED: revert the previous lone cr resolution, and treat it as
any control character
dbaron: We don't think there is much content like this?
myles: No, because it would be auto-converted by the html parser
myles: So the only way would be a script injecting it directly
myles: I haven't seen it
florian: Does the javascript parser also does that?
frremy: You can't have line breaks in string
xidorn: But with backticks you can
florian: Nobody is going to be writing es6 code on a OS 8 mac
dbaron: OS 9 does something even different
(general agreement it should be rare enough)
Fonts Level 4
=============
Choosing palette and colors by predefined name in fonts
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1125
chris: Color fonts are required to use a palette, svg fonts can
chris: Initially, these were just indexes in an array
chris: but in the new version, you can name palettes
chris: You can even name specific values of a palette
chris: so authors would probably want to use these names in their css
chris: (it is localized so we will need to accept match for any of
the localizations)
chris: One good reason for this, is that if you upgrade to a new
version of the font, palettes might have another index, but
the palette names will remain the same
<dbaron> I wonder if there's a requirement that you can't use the
same name for English for palette 2 and for Spanish for
palette 4. (I'm reminded of Indonesia's timezone
abbreviations...)
astearns: So if you use the English name, it will match also on a
Chinese pc?
myles: Yes, that seems like a requirement
myles: We already do that for font-family
<chris> CPAL specification
https://docs.microsoft.com/en-us/typography/opentype/spec/cpal
florian: I agree
heycam: You could specify a set of names
heycam: What if the font use a same name for different languages for
different palettes?
myles: That seems like an error
myles: I propose to use the first one in the font file
myles: (there is an order in the font file, we can use that)
dbaron: [digression on Indonesian timezones]
astearns: Are these color palettes going to be descriptor only?
chris: Only needed when you override font-color-palette values
myles: There is no property, its only for the specific at rule
chris: How do we do this syntax change backward-compatible?
myles: We should ask TabAtkins [TabAtkins is currently away, will be
back shortly]
myles: but we could make this work
heycam: Do we have examples where we use identifiers instead of
strings other that font-family?
heycam: We could just accept strings only, maybe?
myles: There are two levels of name
chris: One for the palettes, and one for the names of values inside
the palette
myles: So we would need to restrict to some values
astearns: But fonts can do whatever, right?
myles: Right, but why would you?
heycam: But you can escape in css, so it's fine
astearns: Can descriptors be strings though?
myles: Maybe, sure wish TabAtkins was here
emilio: That seems annoying to implement
emilio: [missed]
emilio: Can we use a new at-rule?
heycam: Question about the example in the spec:
heycam: what if a palette was named "font-family"
myles: Yes that would be a problem
chris: That's why we proposed to use strings
myles: We could restrict to color-<ident>
dbaron: Which then doesn't require to change what is allowed to be
parsed
myles: How about `colors-"abc"`:?
dbaron: That seems to defeat the purpose of the previous resolution
myles: We can also resolve to remove this at-rule thing
heycam: I'm fine with strings or integer on the LHS of the colon in
theory
frremy: But why not use idents, you can type any code point
dbaron: The advantage of strings is that they are syntactically
different
emilio: If we allow arbitrary identifiers, then we cannot extend
that at-rule in the future
myles: Yes, I think strings are better
myles: but then why not do this for numbers too?
heycam: I didn't like the way we resolved this for svg glyphs, where
we have --color0 etc.
florian: Are we going to break preprocessors with this though?
fantasai: Preprocessors should follow the rules for error handling
of css, and leave things as-is
dbaron: Developers who started using font-family will be annoyed
that things will be different here
chris: Ah, tab is there, maybe he can prevent us from breaking css
astearns: (explain to tab the proposal "abc":"def")
<fantasai> https://drafts.csswg.org/css-fonts-4/#font-palette-values
myles: (continue to re-explain this further)
TabAtkins: That would require changes to the parser
TabAtkins: It's not a big change
TabAtkins: numbers however not, because "3" vs "3e1" etc
florian: What about preprocessors
TabAtkins: It could work
TabAtkins: If you really want to do this, I'm fine with it
myles: The alternative is something like "font-feature-settings"
chris: (jokingly) we could allow full json
myles: What do you think, what would be better?
myles: The "descriptor: "abc" "value"; descriptor: "def" "value";
myles: or "abc":"value"; "def":"value"
florian: That big string is annoying to deal with
TabAtkins: css typed om will fix that
TabAtkins: and since you don't need to cascade, I find that more
idiomatic
heycam: The only thing I don't like the with the repeat syntax is
that descriptors usually override each other
frremy: That wouldn't be the first time we want to change that
myles: But we wouldn't want to build this on additive css because we
want this sooner
frremy: Wasn't my proposal, just saying this change will happen
anyway at some point
myles: (repeats the two proposals)
TabAtkins: The latter is more idiomatic
florian: I like it better
frremy: Me too
heycam: What about the cssom argument?
TabAtkins: This is legacy
<TabAtkins> override-color: [ [ <string> | <integer> ] <color> ]#
astearns: I'm hearing consensus on that proposal
astearns: Any objection to that idea?
myles: We should bikeshed the name though
astearns: What if there is an invalid pair in the list?
myles: Same thing we would do for font-feature-settings
astearns: Happy with that
heycam: But doesn't font-feature-settings only allow a set of
predefined values?
myles: No, there are a few predefined ones but font authors can
define their own
fantasai: Let's use the same syntax as font-feature-settings
florian: That seems like the same to me
florian: except that the value is a color not a number
astearns: Ok, any objection?
myles: We would override the previous resolution about "colors-<int>"
RESOLVED: Adopt the mutli-value descriptor font font-face
Oblique angle for font-synthesis
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2869
fantasai: There has been a lot of comments in that discussion here
<fantasai> https://lists.w3.org/Archives/Public/www-archive/2018Jul/0003.html
astearns: Let's box this to twenty minutes
fantasai: When we are synthesizing oblique in vertical text, what
are we synthesizing
fantasai: we want to be consistent across UAs, at least
koji: The complex part is that Japanese is right slanting
koji: but that this doesn't work well for Roman fonts
myles: (draws on the board)
[Looking at https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0003/italics-vertical.png
]
koji: Japanese publishers do 3 or 4
koji: word processors do 5 or 6
koji: Japanese publishers think that this looks weird, but every word
processor does that
florian: There is also a different between italic and oblique
astearns: There are not italic fonts going in the backwards direction
fantasai: Plus sometimes roman text will be upright
fantasai: and if the font provides a value for italic, the
characters will have different slanting
fantasai: I don't think this makes a lot of sense for us to change
myles: If we want behaviors like 4, then font-style will have to be
"smart" depending on the glyphs
myles: That's not easy
florian: This is only for when we synthesize, right?
myles: Right, if the font says something, we will do what the font
says
<fantasai> https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0003/top-to-right-prohibited-chars.png
<fantasai> https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0003/top-to-right-em-dash.png
fantasai: (just pasted links about interactions)
myles: Authors can change the angle though
fantasai: Yes, but the axis is also something we could change
fantasai: see 7 or 8
fantasai: In these cases, the Japanese chars are slanted
horizontally, but the roman text is slanted vertically
fantasai: in respect to the glyph
florian: When you synthesize, do you this for everything?
myles: Yeah, we would do something like 3
koji: That seems wrong for roman though, right?
myles: Oh, right, I meant 5
florian: But that is wrong for Japanese
florian: For oblique we should do 3 or 5
florian: for italics, we should 4 or 6
astearns: What do browsers do?
fantasai: All over the place
florian: (explains some of the weird results some browsers exhibit)
PROPOSAL: when synthesizing oblique, the origin is the center of the
glyph
astearns: Any objection?
plinss: But that seems weird for roman, doesn't it?
florian: You get a bit of overlap on each side, instead on overlap
around only one side
plinss: I'm not sure this is an improvement
myles: It is, because there will be twice as less layout overlap,
there will be less visual overlap
fantasai: Also, when you center the text, it will look centered
astearns: Any objection?
RESOLVED: skew glyphs around their center
florian: (re-explains his proposal for the directionality of italic
vs oblique)
fantasai: The problem is that some text could have a mix of upright
and not-upright
fantasai: so specifying an angle will mess one or the other
florian: But roman will probably have its italic defined
koji: Are you saying we should change angle to content?
koji: That seems weird?
myles: We could also use transforms
florian: 3 seems what publishers want
koji: I think what publishers want could be achieved with an angle
florian: But for italics, this is gonna be a mess, because the
italic will come by default for roman text
koji: But really, what is usually done, is use the fullwidth chars,
and not use upright
florian: Upright italic isn't really a thing
fantasai: So the upright text will have the italic/oblique from the
cjk font
fantasai: So koji is right, it's probably fine not to do the right
thing, because fonts can do the right thing
astearns: Time's up
astearns: Can we resolve?
fantasai: 6, falling back to 5?
myles: Let's resolve on that, and we have two other issues we didn't
get to today
myles: which will be about upright etc
PROPOSAL: 5 and 6 for italic and obliques with positive angles
astearns: any objection?
RESOLVED: 5 and 6 for italic and obliques with positive angles
https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0003/italics-vertical.png
florian: This is what IE/Edge is doing
frremy: (yay!)
astearns: And negative angle goes the other way?
fantasai: Yes, that is how it usually works
ACTION fantasai: file issue about what does upright latin do, and
how to do other-axis obliques
Restrict unicode range of emoji generic family
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2855
myles: Generic font families sometimes map to more than one font
myles: to match all the languages and codepoints
myles: but should we restrict these fonts so that they cannot use
the emojis
fantasai: So if the emoji font can either use all of its glyphs some
might not be emojis
fantasai: you would then get regular text (Latin, CJK, whatever)
that use the emoji font, preventing any fonts further in
the fallback list from taking effect
myles: (restated the problem)
myles: Are there any implementation doing this?
koji: Not in blink
frremy: I really don't know
astearns: We could make it do what you want, but make the whole
thing at risk?
myles: If you implemented this, we would map it to the emoji font
myles: I think implementations will select one font, and we will
make sure this font doesn't include other chars
myles: so I'm leaning towards closing no-change
fantasai: But then if the user changes the font?
myles: Well, they get what they asked for, all the glyphs in the
emoji font will be emojis....
myles: Don't set a font that contains non-emojis chars in it as your
emoji font
fantasai: The proposal I read was to restrict to unicode emojis
myles: That doesn't work because our fonts include things that are
not unicode emojis
chris: There are pua for examples
astearns: If we set a particular range for the emoji font
astearns: and the font doesn't support something?
florian: You fallback as usual to the next font
fantasai: Right, that doesn't seem a concern
chris: The other problem is that there are combining sequences
chris: Some elements in the sequence might not be emojis
chris: You still don't want to change font
myles: Every year except one, the set has changed
florian: So it's more reasonable to provide ua filtering at the font
selection time
florian: and generate a font subset for the user
florian: based on what it thinks is an emoji at the time
fantasai: I'd be ok with a non-normative advice to warn the user or
generate a subset font of the font selected by the user
fantasai: "may wish to consider"
astearns: ok, any objection to a note saying that?
RESOLVED: a note should be added that ua should filter at the time
the user selects the font, or warn the user of the
consequences
Prioritizing font-stretch over font-weight seems wrong
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2537
fantasai: If you have font-family which "normal + wide" and has a
bold for "normal" but not "wide"
fantasai: If the author specifies "wide bold" what do you get?
fantasai: I think you want "bold"
fantasai: Right now, we specify "wide"
fantasai: I think "bold" is more likely to be making a semantic
distinction
chris: We have no test for that
chris: and I don't know if we can change implementations
myles: Every time I try to change how this selection happens, I get
tons of bugs
myles: so it might be a good idea, but I don't think this is very
doable
florian: You can synthesize bold but not font-stretch
florian: So it's better to pick "wide" and fake "bold"
florian: In the reverse case, we can't fake "wide" so the layout
ends up very different
RESOLVED: closed no-change except if the filer wrote a test and UA
shows diverging behaviors
Angle for oblique->normal threshold should be lower than 20
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2539
fantasai: In the font matching algorithm, we start searching from
20deg then go up from there
fantasai: 20deg is an average
fantasai: We should probably search from the minimum value
chris: If the minimum is 14 we should start searching at 7
fantasai: The spec says: "If no match is found, oblique values
greater than or equal to 20deg are checked in ascending
order followed by oblique values below -20deg in descending
order, until 0 is hit."
florian: 14 not 7?
myles: If you have 13deg and 80deg you want 13deg
fantasai: So we set 7deg
myles: But what about 6deg and 80deg?
florian: Binary search, we look in both directions?
myles: I don't want to change the algorithm
myles: I think we should set the value as 11deg
myles: because this seems better than 8deg
fantasai: 11 is a lower-bound of typical italics
fantasai: 8 would be pushing it
astearns: Alright, any objection to start searching at 11 and see
how it goes?
myles: (digression on the negative angle)
RESOLVED: Start searching for oblique starting from 11deg
font-display descriptor value names
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1676
fantasai: Filed last year by mozilla
myles: Everybody has shipped all these features, I don't think we
want to change this
TabAtkins: Yeah, let's fix the issue
eae: That ship has sailed
TabAtkins: The names are fine; some were a bit better but current
names are fine
RESOLVED: close no-change, due to webcompat
font-synthesis forwards-compat with new values
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1641
fantasai: At a f2f we resolved to change font-synthesis to invert
the behavior since we change from you have to specify what
you want to synthesize
fantasai: to specify instead what you don't want to synthesize
fantasai: Needed to clarify the resolution
myles: Not much thought, except I'd not want to break existing
content
astearns: But are you fine with TabAtkins' table?
TabAtkins: (discussion about what rule maps to the spec)
fantasai: The table doesn't help with forwards-compat
fantasai: The current behavior if you don't specify font-synthesis
which allows weight+style+font-caps
fantasai: If you say font-synthesis: weight you already
weight+font-caps
TabAtkins: The table is meant to ease the compat
TabAtkins: font-caps is not a legacy value
TabAtkins: Unspecified parts of the property default to on/off
depending on legacy requirements
florian: We had a similar discussion with font-...-skip and we had
settled on a shorthand
chris: We can keep adding long-hands as we see fit
florian: I think this is the only sane thing to do
myles: Then we can use Tab's table for the shorthand
myles: Ok, so the proposal is to have three properties
"font-synthesis-weight, font-synthesis-style, etc..."
myles: Three values, each should have default to "auto" and "none",
two first one are auto, last one is none
fantasai: I don't like font-synthesis: no-caps disabling everything
myles: Since nobody implemented small-caps, we get rid of them in
the shorthand
myles: so the problem just disappears
<TabAtkins> font-synthesis: all | none | [weight || style], with
effects as in my table
<myles> Proposal: 3 new properties: font-synthesis-weight,
font-synthesis-style, and font-synthesis-small-caps, all
with grammar "auto | none" with initial values "auto", all
inherited, and the "small-caps" "no-small-caps" and
"no-style" and "no-weight" values are removed from the
font-synthesis grammar
astearns: Any objection on the proposal as stated in irc
RESOLVED: Move font-synthesis to long-hands, and simplify the
shorthand per IRC above
Variation selectors are underspecified
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/854
myles: There isn't a proposal, it's more of a discussion topic
fantasai: The question is that there is a text
fantasai: and the main font supports the base char, not the
variation selector
fantasai: The fallback font supports both
fantasai: Do you fallback or not?
myles: There are two special ones that doesn't need font fallback
myles: but unicode doesn't support font-fallback
koji: It seems reasonable to make 15 and 16 specials
myles: They should affect fallback
myles: They should match together
fantasai: So you must match a font that supports both
myles: Correct
myles: The way we implemented this is that when you have a color
indicator
myles: we will only search color fonts
myles: If there is a font that supports the glyph but not the color
variations, we will skip it
myles: It's not that I'm proposing this, because each OS might do
this differently, but this is a reference to keep in mind
fantasai: For cjk, there is the option of doing a two-pass behavior
or a single-pass variant
fantasai: but there seems to be use cases for both
florian: For instance an ID name want to right char
fantasai: But as a designer in normal text, you want to stay with
the same font more, so dropping the variation is better
florian: I recall discussing this at the first meeting I ever
attended
florian: that was long ago
myles: I don't think we are going to make any progress on this issue
myles: We should probably switch
<florian> We have a resolution from Kyoto2011 F2F to do font
fallback all the way to the system then restart and match
the base only, and to add a property to switch:
https://lists.w3.org/Archives/Public/www-style/2011Jun/0325.html
font-size-adjust per font
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/2857
fantasai: font-size-adjust finds the ex-height ratio of the first
font, then transforms the fallback fonts to make their
ex-heights match, to make the effective size of lowercase
glyphs consistent across fallbacks
fantasai: That works great for Latin text, because it uses the
x-height
fantasai: but that doesn't help fonts that do not rely on x-height,
like cjk, where the glyph size will still vary
fantasai: Maybe we should allow authors to specify an explicit size
ratio for each font as a correction factor
fantasai: What do implementers think?
dbaron: The feature you describe seems better as a descriptor on the
font
myles: We have had some requests to provide new metrics for fonts
inside @font-face
<astearns> I've had people ask me to allow them to add their own
kern tables in @font-face rules
dbaron: font-size-adjustment was designed for bicameral scripts,
maybe we want to add default solutions for other script types
dbaron: That being said, font-size-adjust solves two problems;
dbaron: one is that sizes that don't match well without your list of
fallbacks
dbaron: but the other case is that you want to apply the metrics of
your font to any OS-based fallback
dbaron: An example is Verdana, which is very unique
dbaron: That specific case cannot be solved with specific numbers,
because you don't know the OS font
dbaron: I had a proposal to make this work
dbaron: but this feature has been around for 20 years and most
implementations aren't there
fantasai: I think the lack of uptake is because this is confusing to
use
fantasai: The monospace is an example use case
frremy: That one is super confusing
fantasai: So, since that was super difficult to use, people didn't
use it
fantasai: Finding the x-height is very difficult
fantasai: and in the end, it only works for bicameral scripts
fantasai: My proposal is a factor per font, so it's easy to
understand (and implement?)
fantasai: and easy for authors to guess
dbaron: Yes, that seems reasonable
dbaron: font-size-adjust currently you have to specify the value
relative to the font-size
fantasai: Because you need to inherit, and so you have to react to
changes in font-size
dbaron: If it were a functional notation in font-size, you would be
able to make this work
fantasai: Regardless, I propose we add a descriptor for size
multiplier named font-size-adjust, taking a percentage
dbaron: I agree on the idea but would not call it font-size-adjust,
that is confusing
astearns: Well, we are out of time
<br type=day>
Received on Friday, 20 July 2018 00:28:23 UTC