- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 29 Aug 2017 17:55:16 -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.
=========================================
Fonts
-----
- RESOLVED: @font-face rules without src descriptor should remain
in the om, but should not be used for font matching.
(Issue #1133) Likewise @counter-style rules.
- RESOLVED: Change font-synthesis to all pairs of keywords and
no-keywords. (Issue #1641)
- RESOLVED: Make default values: weight (off), style (off),
small-caps (on), make the initial value 'weight
style', and add keywords no-weight, no-style, and
no-small-caps. (Issue #1641)
- RESOLVED: Font variations will be both properties and
descriptors. (Issue #1652)
- Briefly discussed issue of variation axes that are font-specific
and the fallback problem (which for features is solved by
@font-feature-values)
- RESOLVED: Rollback to previous state with CSSStyleDeclaration
and unmerged interfaces, requiring get/set calls
(no .property interface) for @font-face rules in the OM.
(Issue #825)
- RESOLVED: font-weight is mapped to actual fonts as follows (Issue
#1579):
Split the weights into three categories:
1) light - < 400
2) medium - 400 <= x <= 500
3) bold - > 500
For light, first search from x => 0, then x => 1000
For medium, search x=>500, then x => 0, then x => 1000
For bold, first search from x => 1000, then x => 0
- RESOLVED: Font selection algorithm has different behavior during
animation than Fonts 3; we will add a note to that
affect in Fonts 4. (Issue #1579)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Scribe: fremy
Fonts
=====
Handling of @font-face rule which lacks font-family or src descriptor
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1133
myles: For a long time, @font-face without src is ignored
myles: which means it is a parse error and is not there anymore.
dbaron: I would argue ignored could mean it's there in the OM but
then does nothing.
myles: ok, I think it doesn't matter for what I want to think
about.
myles: In some cases, you can have @font-faces to alter font
properties
myles: and all browsers accept to do that.
myles: So I would like the text to be changed to say that the
font-face rule should not be used for font matching
myles: but should apply otherwise.
dbaron: I think that is the sensible way to "ignore" them.
TabAtkins: I have a follow-up question about whether we should
apply a similar reasoning to invalid counter styles.
dbaron: It would make sense to me.
myles: I cannot say that this matches browsers in that case, I
have not tested.
TabAtkins: Sounds good, but we could decide on a principle and
update if needed.
astearns: What is the proposition then?
myles: (repeats previous proposal)
RESOLVED: font-face rules should be in the om, but should not be
used for font matching.
We can't add new values to the font-synthesis property
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1641
myles: font-synthesis is a property that allows to turn on/off the
font synthesis.
myles: For example font-synthesis: weight allows to generate
bolder variants.
myles: By default you can synthesize everything.
myles: The issue is that if you want to turn one on, you turn off
all the other ones
myles: which means that new flags will be accidentally turned off
by older styles.
fantasai: We have a similar problem with text-decoration-skip.
fantasai: We decided to create lots of longhands properties.
Florian: We don't have quite resolved that but ok.
fantasai: The other option is to have foo/no-foo pairs and only
reset to false what you specify as off, but if you
don't specify things we use the default.
Florian: Wait, don't you want the reverse?
fantasai: If you omit them, they default to true if true is the
default, yes.
fantasai: There was a proposal from ChrisL that was similar but
used + and - in front of keywords
TabAtkins: text-decoration only allows to append new decoration
styles but not remove inherited ones
Florian: The reason we rejected the equivalent bold/no-bold for
text-decoration because it cascades poorly which is the
case for text decoration.
Florian: This is not quite the case for font-synthesis though--
you almost always want to set everything together rather
than cascading separately, so the option is still open now.
fantasai: Given that we already follow this pattern for
font-variant, I think we should use the bold|no-bold
pattern for font-synthesis as well
myles: This is my opinion as well.
myles: Plus some rule that explains what happens if you ask both.
Florian: Should we also also have no-everything?
myles: We can discuss this as part of another issue.
astearns: Is this ok to make this change?
myles: We added small-caps and didn't see a problem
myles: but the window is closing of course, the more we add the
more difficult it gets to change.
astearns: So, proposed resolution is to use pair-keywords values
for this property.
astearns: Any objection?
RESOLVED: Change font-synthesis to all pairs of keywords and
no-keywords.
fantasai: Do we need to change fonts level 3?
myles: Don't think so.
TAG Review of variable fonts
----------------------------
GitHub: https://github.com/w3ctag/design-reviews/issues/183
https://github.com/w3c/csswg-drafts/issues/1652
dbaron: drott asked for tag review
dbaron: The main feedback was how this should be font properties
or descriptors.
dbaron: The reasoning should be that some things should be whether
you would want the things to apply to fallback fonts or
not.
dbaron: Over time, system fonts are likely to get more variations.
<TabAtkins> Looks like the axises would be best done as an
open-ended set of properties, similar to custom
properties...
<TabAtkins> We can't guarantee that the axis names live in the CSS
ident space, so we can't do `font-axis-*` tho.
myles: There are two spaces for variation axes.
myles: One is for things that are defined for all fonts
myles: Other is things that are custom for your own font,
which are named in all caps.
TabAtkins: What is the ascii range for these names?
myles: Less than ascii for sure.
myles: No control char or anything, and casing does matter.
dbaron: Flip side is animation.
dbaron: If you want to animate them, they should be properties.
eae: There have been clear request to support that.
dbaron: I think it would make sense then to have both to support
both use cases
myles: This is what font-feature-settings is, minus some stories I
rather not start talking about.
TabAtkins: How about having a list of values in the axis?
TabAtkins: We still need to be able to control them independently.
TabAtkins: We can instead allocate a property namespace so that
you get a property for each axis.
fantasai: What if axis idents are outside ascii range in newer
formats?
TabAtkins: You can escape any char in identifiers in css.
myles: In our impl we would not want weird axis names anyway.
astearns: Use case where you have weight animated.
myles: You can animate pair by pair.
TabAtkins: But you still need to change all of them in same
declaration.
myles: Additive css would solve that.
TabAtkins: Yes.
myles: So, based on consensus we need a resolution to add
descriptor and keep property.
fantasai: Wrt font-specificness of certain axes; we have a similar
problem with various stylistic fonts tags you want to
turn on and off.
fantasai: What we did, we decided to tie them to an identifier
that is font-specific via @font-feature-values
fantasai: we could take the same approach here.
fantasai: This would allow to customize a font-specific thing in
particular without affecting other fonts.
myles: That works for stylistic alternates because the meaning of
"alternate #1" is arbitrary but it doesn't make sense for
axis names because the meaning of a value is supposed to be
consistent across fonts.
TabAtkins: The ranges could not mean the same thing for each
font even if the two axises do approximately the same
thing
astearns: Even the lower-case standardized names, do they have
identical ranges?
myles: No.
myles: Names are consistent between formats, but ranges are not.
myles: They are internally consistent per format though.
astearns: Could we map one to the other?
myles: Yes, we could map to a canonical form.
astearns: So could we define a css range?
myles: I don't want to get into that.
astearns: Anyway, I didn't hear any opposition to have things be
both font descriptors and properties as per tag review.
astearns: Can we get this resolved?
RESOLVED: Font variations will be both properties and descriptors.
astearns: Any other issue we should discuss from this review?
dbaron: Not really, the rest is mostly editorial.
We can't add new values to the font-synthesis property (cont.)
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1641
Bert: So font-synthesis: no-foo --> turns off foo but not bar,
right?
myles: Well, it resets bar to its default.
myles: Right now all the other values are on by default, but in
the future we could add new things that would be off by
default.
Bert: Then why should we not change the fonts spec.
myles: No, it would just do as today, the spec will still be
internally consistent.
fantasai: Well, new features will be off by default all the time
right? otherwise it will be breaking change.
Florian: Not really, because new features could be things that did
not exist at all before.
Florian: So there would be no possible backwards compat problem.
fantasai: And small-caps?
myles: It is not in level 3, so no revision to do/
fantasai: But with this we could backport to level 3
fantasai: Wouldn't you want that then?
myles: To prevent a browser that supports "small-caps" but
"no-smallcaps"?
fantasai: Yes.
fantasai: We could have small-caps be on in the initial value and
also be on if omitted
fantasai: The ability to do this is effectively why we are
considering having this foo/no-foo syntax.
dbaron: Well, I think there is still a change from level 3.
TabAtkins: This is not the same default we are talking about.
TabAtkins: Now we talk about "default if you omit it in the
declaration" not the "default if you omit the
declaration".
dbaron: Is this widely implemented?
myles: No.
[dbaron and tabatkins arguing about default vs initial]
<TabAtkins> [dbaron kept using "default" to mean "initial value",
when I and Myles were purposely using "default" to
mean a totally separate concept]
dbaron: I would want the default if omitted to be the same as the
initial.
fantasai: +1
fantasai: If we don't do what dbaron wants, yes, there is not
breaking change
fantasai: but if we accept to break stuff, we can do
default=initial, which makes more sense.
astearns: Seems like we want a new issue, and try to come up with
a new design for this, and discuss this in a smaller
group
astearns: then come back to this when the key people for this
issue agree all together.
fantasai: It is a breaking change, so we want to do it sooner
rather than later.
astearns: What is the proposal then?
dbaron: initial = default
TabAtkins: "font-synthesis: weight" also turns on "italic"
TabAtkins: That is confusing
myles: We could three set of keywords.
<TabAtkins> none | [ weight || style ] | [ [weight-on |
weight-off] || [style-on | style-off] || [smallcaps-on
| smallcaps-off] ... ]
Florian: Or we can also use the inheritance behavior.
Florian: The only case that would be broken would be
font-synthesis:initial.
myles: Probably not common.
dbaron: With this in mind, maybe I am fine with the previous
resolution.
dbaron: If we need to do something weird anyway, we might as well
do what we proposed before
dbaron: but keep this as exceptions only for weight and style, and
going forward we do default=initial.
astearns: So we have three proposals:
1. previous resolution
2. extended keyword set
3. inheritance for omitted values
fantasai: 3 would break the meaning for font-synthesis:weight
TabAtkins: No, it would not.
Florian: We change the initial to no
Florian: but the ua stylesheet sets to true on root.
astearns: What about small-caps?
myles: small-caps is on by default.
myles: So font-synthesis:weight allows small-caps.
astearns: Do you have a preference, myles?
myles: Not really
myles: the ua stylesheet case is the most simple and elegant
solution, probably.
* fantasai doesn't understand the difference between Florian's
suggestion and the current situation, other than
'initial' doesn't get you the default behavior
TabAtkins: I like florian proposal.
<TabAtkins> Florian's proposal: initial value is `font-synthesis:
no-weight no-style smallcaps`, UA style is `:root {
font-syntheses: weight style smallcaps;}`. Omitting a
keyword defaults it to the initial value for that
keyword.
<TabAtkins> So author saying `f-s: weight;` would get weight &
smallcaps syntheses, but not style.
dino: The only issue is we break all:initial, which people do in
shadow dom.
TabAtkins: Yes, true.
fantasai: If we were doing this from scratch, we would have
dbaron's behavior.
fantasai: How about we break existing content?
myles: Places that use it today would then never synthesize small
caps.
myles: I prefer the alternative.
fremy: Why would you do 'all: initial' and not 'all: unset'?
astearns: We reached the time limit
astearns: I would want to come to a conclusion.
dbaron: Two proposals: fixing previous resolution, or breaking
existing content
<dbaron> Proposed resolution: make default values: weight (off),
style (off), small-caps (on), make the initial value
'weight style', and add keywords no-weight, no-style, and
no-small-caps.
<dbaron> More breaking option: make default values: weight (on),
style (on), and small-caps (on), make the initial value
'new keyword to be determined', and add keywords
no-weight, no-style, and no-small-caps
<dbaron> (although there's actually the alternative option to not
have the non-default no-* variants)
<dbaron> (that alternative applies to both options)
astearns: we try to resolve on the the first one dbaron proposed
(no objection)
RESOLVED: Make default values: weight (off), style (off),
small-caps (on), make the initial value 'weight style',
and add keywords no-weight, no-style, and no-small-caps.
<dbaron> (at least for now, may discuss further)
CSSFontFaceRule isn't web-compatible
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/825
myles: cssom for the @font-face rule
myles: used to be CSSStyleDeclaration with the declarations inside
myles: rule.style.getPropertyValue("font-family").
myles: The spec was then changed
myles: instead of having a style, you would have a bunch of strings
myles: e.g. rule.family.
myles: No browser has made this change.
myles: There is existing code that use the old way.
myles: We don't want to break that code.
myles: Option 1: rollback to old spec text
myles: Option 2: get browsers to support the new spec text
myles: Option 3: get browsers to support both
myles: Option 4: make the "style" property return new type of
object that looks like CSSStyleDeclaration but is simpler
dbaron: In the old domstyle spec, cssstyledeclaration was simple
dbaron: The weird stuff was in css2properties, which had a
property for every property in css
dbaron: so you could implement both, and most things did.
dbaron: That was then changed, and the two were merged
dbaron: so now the merge made it more difficult to implement.
dbaron: Our implementation doesn't include all the other stuff in
@font-face rules, just the 6 original get/set methods.
dbaron: We never implemented this merge
dbaron: (in gecko).
dbaron: My preferred proposal would then to be unmerge things
dbaron: (and rollback to use cssstyledeclaration).
myles: We still need to explain what happens when we set
properties that do not exist in @font-face but do in
general style
myles: but I don't have a strong opinion in either ways
myles: but I would rather rollback the spec, and maybe we can
refine after.
astearns: So, instead of coming up with a perfect design, we
rollback and improve iteratively.
TabAtkins: We have copied the design in @font-face
TabAtkins: and we have "style" property there
TabAtkins: so we cannot be consistent and keep style as
CSSStyleDeclaration.
myles: Life is terrible, who names these things ;)
dbaron: If other implementations are willing to remove css2props
stuff, then it leaves less questions to be answered.
myles: I don't think we ever implemented these two interfaces.
astearns: Any other opinion?
TabAtkins: I suspect if gecko is doing it, I guess we could do it.
myles: Merge allows rule.style.fontFamily and unmerge does not.
dbaron: Yes.
myles: webkit does not support this either,
<gsnedders> I thought both of those were supported interoperably?
<dbaron> gsnedders: rule is CSSFontFaceRule
myles: Can we then try to resolve on rolling back to the unmerged
version?
[no objection]
RESOLVED: Rollback to previous state with CSSStyleDeclaration and
unmerged interfaces, requiring get/set calls (no
.property access) for @font-face rules in the OM.
<TabAtkins> I'm confused, why will .style.fontFamily not work?
That's one of the descriptors.
<dbaron> TabAtkins, we don't have an interface that has
.fontFamily and not .backgroundColor... and multiple
browsers have gotten away with not implementing either on
CSSFontFaceRule.style
<TabAtkins> Does that mean you can't change the name of a
@font-face via the OM?
<dbaron> nope, use setPropertyValue
<TabAtkins> Ah, no, it just means that you have to use the
getPropertyValue()/etc, not the getters.
Properties being reset by the font shorthand
--------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/1349
myles: I made an amazing table, let me paste the link.
<myles> https://github.com/w3c/csswg-drafts/issues/1636#issuecomment-317127312
myles: There seems to be consensus that the font shorthand resets
what is not specified in it
myles: but what the other things are doesn't seem interoperable.
dbaron: I think the test is wrong for font-language-override
myles: Let me check.
TabAtkins: There seems to be things we do support that this test
says we don't
TabAtkins: so we cannot trust this data.
<TabAtkins> font-size-adjust, at minimum - we def support it (it
causes the CSSWG blog to display brokenly on a
Chromebook >_<)
myles: ok, we will discuss this another day then.
Animating font weight
---------------------
github: https://github.com/w3c/csswg-drafts/issues/1579
myles projects lots of beautiful graphs from the spec
myles: Two things here
myles: 1. requested font weight
myles: 2. available options in the font
myles: Then algorithm match one to the others.
myles: For historical reasons, if you want 400 and it is not
possible
myles: search will be 500, then 300, then 200, then ...
myles: Variables fonts can have much more arbitrary values
myles: So I tried to come up with a solution for generalizing this.
myles: The generalization I came up with: 400, then 500, then any
value between 400 and 300, then any value between 400 and
600, etc
fantasai: Why not directly 400 -> 500 instead of 400 then
discretely 500
fantasai: doesn't seem very logical.
TabAtkins: The old model did that.
fantasai: But you could not express 430, it needed to be multiples
of 100.
fantasai: The goal of the algorithm was that 400 and 500 were very
common values for medium weights, so if you choose one
and don't have it, pick the other.
fantasai: but 300 is often considered lightweight.
fantasai: This proposal preserves the compat, but not the spirit.
fantasai: I would prefer to connect the 400 -> 500 range.
TabAtkins: Yes, it is less weird.
myles: If there is consensus, I am ok with this.
fantasai: This would evolve the old algorithm, not run some
algorithm after it.
fantasai: Proposal means if we did 400 then 500 then 300, now we
do 400 -> 500, then 500 -> 300, ...
fantasai: Obviously some values will not match.
fantasai: because they have been searched already
<fantasai> basically play "connect the dots" with the old search
points
<fantasai> which might go over some ranges multiple times, but of
course the UA would optimize those out.
(whiteboard discussion)
(the discussion seems to be about what fantasai's idea does if you
search for 450 not 400)
(and related cases like 250 or 550)
<TabAtkins> Split the weights into three categories:
<TabAtkins> light - < 400
<TabAtkins> medium - 400 <= x <= 500
<TabAtkins> bold - > 500
<TabAtkins> For light, first search from x => 0, then x => 1000
<TabAtkins> For bold, first search from x => 1000, then x => 0
<TabAtkins> For medium, several possibilities.
<TabAtkins> Never mind, bolder is better, so medium's category is:
search x=>500, then x => 0, then x => 1000
RESOLVED: font-weight matching described before
scribe: TabAtkins
myles: Previously you could animate font-weights, even though they
weren't numbers.
myles: You animated a number, then rounded to nearest 100, *then*
invoked the font selection algo.
myles: So at a particular value of time, say your animation was at
font-weight:540. You'd first round to 500, then run
font-selection.
myles: For variable fonts, you don't have to round. This is a good
thing.
myles: But rounding might change which case you fall into.
fantasai: And when animating between 401 and 450, rounding would
make you choose the 400 font, but our new thing would
choose the 500 font.
myles: So two options: undo what we just did and make it more
complicated...
myles: Or say that animating font-weights before variable fonts
wasn't often used, and just accept the behavior change.
fantasai: I think there's not much objection to computing
font-weight and its animation to be a general integer.
fantasai: But for impls that don't do variable fonts, do we want
them to accept any value, or should they still do the
rounding?
dbaron: There are fonts with more than just 100, 200, etc weights;
seems like it would be better to make that work.
dauwhe: I have a font with weights spaced every 5.
<dauwhe> https://www.typography.com/fonts/knockout/overview/
dbaron: So I think we should just make the change; we'll see if
there's any problem.
myles: I think we already have an old resolution to let weight
accept any integer, actually.
dbaron: Does the spec really mean <number> rather than <integer>?
myles: <number> is right; variables axises can accept any float in
the range.
fantasai: So Fonts 3 needs to be updated; do we want to allow it
at parse time too?
dbaron: I don't think Fonts 3 needs updating; this is a new
feature, the property just supports more values than it
used to.
fantasai: That's fair.
TabAtkins: We could probably use a note in Fonts 4 that the
animation behavior has changed.
myles: Yes.
astearns: Objections?
RESOLVED: Font selection algorithm has different behavior during
animation than Fonts 3; we will add a note to that
affect in Fonts 4.
topic: break
Received on Tuesday, 29 August 2017 21:56:11 UTC