- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 21:27:34 -0500
- 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.
=========================================
Variation fonts in OpenType
---------------------------
- behdad showed a demo of variation fonts in OpenType 1.8.
- There is a desire to map the variation axes to CSS controls.
To do this, there are three types of mapping that need to be done:
1) Add an extra value to font selection that would allow the
point values associated with weight, width, slant
2) Add axises that aren't associated with font selection
3) Create the ability to set arbitrary axises
- These should be able to animate in order to avoid flickering.
- There were concerns that the APIs for this weren't complete
enough to add this to Fonts 4 - it could slow down other parts
of the spec.
- Suggestions to alleviate this concern were:
- Move it to WICG
- Put this into Fonts 5 and add the more unstable parts of
Font 4 there as well so that the new Fonts 4 moves
quickly.
- Lots of people wanted to keep it in the CSSWG instead of
moving it to WICG.
- RESOLVED: We will work on font variations.
- RESOLVED: Font variance is part of Fonts Level 4
Motion Path
-----------
- A ray() function in offset-path was introduced to cancel the
<angle> ambiguity.
- jihye will change offset shorthand to use || instead of &&
- RESOLVED: Switch the polar-positioning part of offset-path to be
a ray() function.
- RESOLVED: Position before path before distance and anchor
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda
Scribe: TabAtkins
CSS Fonts: OpenType Variations
==============================
Overview of technology
----------------------
<behdad> astearns: jdaggett:
https://twitter.com/abrax5/status/776708619043762176
<behdad> jdaggett: plus the other two things I demoed at atypi
<behdad> jdaggett: full video here:
https://www.youtube.com/watch?v=6kizDePhcFU
<behdad> Demos start at about 1:11:00
<jdaggett> github issue for font variations support
<jdaggett> https://github.com/w3c/csswg-drafts/issues/498
<jdaggett> John Hudson blog post on variable fonts
<jdaggett> https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369#.u93slo7n5
behdad: Last week at atypi we announced, with Apple, Google,
Microsoft, Adobe, we announced opentype 1.8, the biggest
change since it first happened.
behdad: Biggest addition is variation fonts. I'll show a demo,
then Myles and John will discuss the implications for CSS.
behdad: Our current fonts are scalable in size. Variation fonts
bring that same scaling to other aspects.
[shows a width variation, then a weight]
behdad: Look at dollar sign, it changes to a difference design
based on the weight.
(applause)
behdad: Similar demo of Arabic script. The ligature and combining
marks just work.
behdad: This isn't new, it's based on Apple tech from the 90s.
Adobe multiple masters is very similar as well.
<ChrisL> (Apple TrueType GX)
behdad: But for the first time it's in OpenType, and extended to
handle OT layout.
behdad: Designers have already been designing with interpolation,
they just export to flat/individual instances. We're
bringing it to runtime.
behdad: While we bless the most common interpolation axises,
the tech supports arbitrary axises as well.
behdad: Here's a western font with axises that change several
aspects of the font.
[behdad shows example of font with circular holes, the extra axis
changes the holes from round circles to squares]
[changes the buttons, the joints, the way the serifs look]
<jdaggett> Example of a family using different axes
<jdaggett> weight and contrast
<jdaggett> http://typeproject.com/fonts/tpmincho
behdad: So in CSS we need to hook up weight, width, and other
"standard" axises. Then arbitrary axises.
behdad: And really interesting applications is responsive design.
Like adjusting the params to fit text into a space.
(applause)
<behdad> Side comment I forgot to mention: variation fonts have
significant size saving for webfonts.
Integration into CSS
--------------------
myles: Two reasons this is valuable to add to CSS.
myles: First is you get super-great typography.
myles: Likely the axises will affect weight and stretch. Currently
very common for websites to have the same font in multiple
weights/stretches. Now they can just have one font.
myles: Current thinking for how to plug this into font selection
breaks down into three pieces.
myles: These variations are not OT features - that's something
different. They interact, but reusing font-feature-settings
would be a mistake.
myles: These sliders are called axises.
myles: The current thinking of how to map these to CSS is to break
down the sliders into three pieces.
myles: First is axises that affect font selection - weight, width,
slant.
myles: These are important because we already have properties that
affect font selection.
myles: So all three of them don't have a concept of floating point
values.
myles: So presumably some value would be assigned, so if you say
"give me a bold font", a variation font could be selected,
and then made bold.
myles: So an extra stage in font selection.
myles: Those three are expected to be the most common axises.
myles: Set 2 is common axises that don't affect font selection.
myles: One example is optical sizing.
myles: No existing properties, we'll likely add new ones with
associated syntax.
myles: Set 3 is low-level arbitrary axises.
myles: Where author can specify whatever name.
myles: This is important, because in OT, if you make a font you
can respond to any axis, even if it's not registered in a
spec.
myles: So conceptually this is similar to font-feature-settings,
but this is meant for variations, and will take a
floating-point rather than an int.
myles: So that's basic thinking for mapping.
myles: I've written a draft spec which isn't in the repo yet.
myles: Rather than merging draft text into Fonts 4, there are a
fair number of high-level issues to resolve (like how to
make @font-face respond to this)
myles: We'd discuss this in github in issue trackers, and when it
dies down then I'd write some text and start adding it to
level 4.
myles: There's one piece I forgot to mention
myles: With the font selection I mentioned - if you're on an old
browser that doesn't support variations, and you tell it to
use this variation font,
myles: You'll say "apply bold", the browser doesn't know how to,
so you'll get a normal version.
myles: So maybe need an addition to the format specifier so an older
browser doesn't even download them if it doesn't know how
to use them.
<ChrisL> https://github.com/w3c/csswg-drafts/issues/498
<ChrisL> draft spec (fork of css fonts 3, but intended for
fonts 4)
https://github.com/litherum/csswg-drafts/commits/variationfonts
glazou: First, congrats.
glazou: As I understand, this is going to be useful for responsive
design.
glazou: One of the thing I'd like to avoid is flickering when the
font changes at a boundary in your responsive design.
glazou: One way of doing that is to do transitions on the font
axises.
glazou: If you can make that property animatable in CSS, that
would be really awesome.
myles: Being able to animate is a stated design goal in this.
glazou: Good. I wanted to mention because it has deep implications.
<dbaron> It doesn't seem to me that responsive design would be a
use case for animation. While people like demoing how
responsive designs respond to resizing, the point is that
it is a good design at any particular static size.
<gsnedders> dbaron: and indeed things frequently get confusing
when resizing due to movement of content
<dbaron> certainly may be other use cases, though
<glazou> dbaron: imagine a emoji font where the smile/grin mouth
is set by a font axis ; transitioning that would be
awesome
Florian: Also this is great.
Florian: I wanted to clarify - how would font selection work?
Florian: Would you be able to declare a range of weights to use
this font, like 100-600, but for 800 use this
old-fashioned one?
myles: There are at least 2 models for how this would work.
myles: Many different parties with different ideas.
myles: Web authors that are font designers, and like TypeKit
serving fonts.
myles: We have not reached consensus, in short.
Vlad: Variation fonts would likely have named instances.
Vlad: In the scale, there will be certain points in the axis with
a name assigned. You say "bold", the browser may not know
the variation scale, but there will be a value known as
"bold".
Vlad: But I'm not sure there's a mechanism to query a font for
that.
myles: Axis discovery is related but somewhat distinct.
myles: Font features are similar. And there's no mechanism for
discovering those features.
myles: It might be possible to go down that road. I'd like to
consider them as related but separate topics.
Vlad: I think variation is a little bit trickier.
behdad: The CSS shorthand routes into the font, and there is
@font-face for the name instances, same as for
@font-feature-settings.
<eae> I think he meant the font provider's CSS generator
generating @font-face rules rather than the CSS shorthand
parser.
Vlad: Question: related to responsive typography.
Vlad: You have a font with width variation, and idea is that when
you resize the window or column, you apply a smooth width
variation.
Vlad: Reflows can be very objectionable when text jumps.
Vlad: But what I didn't see in the spec is the mechanism that
connects window information back to font variations.
ChrisL: I'd like to reiterate that animations/transition will be
great for this.
ChrisL: One thing not mentioned yet is that system fonts will have
variations.
ChrisL: So you'll set a fallback font and set its width/weight/
etc, so less of a "jump" when your downloaded font loads
in.
astearns: Doesn't that depend on the system fonts being quite
similar?
ChrisL: Right, it's the same problem as having Arial vs Helvetica.
astearns: Right, wondering if we need a way of setting up system
fonts *per system*, so it's known to match.
myles: There's a GH issue for that.
ChrisL: There's a detailed proposal in the GH for that.
<eae> myles: do you have a link to that issue handy?
<myles> eae: let me see
<jdaggett> https://github.com/w3c/csswg-drafts/issues/498
<myles> eae: https://github.com/w3c/csswg-drafts/issues/126
<eae> myles: thanks!
ChrisL: This is just gonna change things so much.
ChrisL: Instead of downloading 4 fonts and wishing there were more
weights, you just do one and get 7 weights, etc.
Process & Schedule Considerations
---------------------------------
ChrisL: What we really want is to get approval from the group to
move into Fonts 4.
astearns: Proposed resolution is to take what's written and move
into CSS4 Fonts.
dbaron: Are there other substantial features in Fonts 4?
fantasai: Yes.
dbaron: How likely is this to progress relative to those?
ChrisL: Similar. Chromatic fonts there right now. Gonna run on
similar timescale.
fantasai: Small set of simple features that have been added, then
palette colors and whatnot.
astearns: And when we find that things progress slower, we'll move
them around.
jdaggett: I think the underlying tech here hasn't been implemented
on platforms yet.
jdaggett: I think it's complex enough that issues will come up in
the spec itself. Relative to other Fonts 4 features,
this...
ChrisL: I agree it hasn't quite shipped, but at the announcement
last week there were OS companies and font foundries
saying they were adding it. Adobe added a rasterizer to
FreeType.
ChrisL: Much more ready than one would expect.
behdad: OS 10.12 shipped San Francisco as a variation font.
astearns: Things will shift, but do you think we should keep it
out of Fonts 4?
jdaggett: My concern is that the APIs for supporting them haven't
been laid out completely.
jdaggett: I think there are issues of how impls will be able to
support this.
jdaggett: I think it's fine for Fonts 4, but there could be, it
could take longer than other features.
ChrisL: We have things where we want to freeze a particular spec
where a delta is hard to read, and this is effectively
that.
ChrisL: Like, Fonts 3 needs to have been shipped yesterday.
ChrisL: Only definition of @font-face, and way past due.
astearns: I don't think it slows down Fonts 4?
ChrisL: But then you need to track changes.
myles: I'm willing to do that.
scribe: fantasai
TabAtkins: Given this is a brand new feature under heavy changes,
this seems like a great thing to work out in the WICG.
TabAtkins: Prefer to move new ideas into WICG instead of putting
them into a spec with their features
TabAtkins: Want to talk it out on a lower-volume list.
astearns: Lower volume list, but also a different list that needs
for people to subscribe to it.
ChrisL: What's the benefit here? We have the font people here, and
CSS people here.
TabAtkins: Didn't want to mix up this feature with unrelated
features like font palettes.
TabAtkins: The point here is to have smaller groups that are more
focused.
leaverou: If everyone in the CSSWG joins WICG group, how is that
smaller?
TabAtkins: Not everybody would join.
Rossen: WICG is a separate topic.
Rossen: Discussion is on Fonts 4.
<jdaggett> I think this feature will affect some fairly
fundamental CSS features
<jdaggett> font properties and @font-face rule
<ChrisL> I mentioned the size savings earlier
Bert: I think good idea to put this into the draft.
Bert: But should make the draft official draft for the WG.
fantasai: I thought we had an outstanding resolution to publish?
Vlad: I'm not concerned about people in this room, concerned about
people who are not in this room but are subscribed to the
list.
<jdaggett> list? www-style?
Vlad: I would be concerned that people would not be following.
Vlad: Concerned about independent font designers, who have a lot
of work on their main job to do.
<jdaggett> agree with vlad
Vlad: We have a lot of good participation on www-style from John
Hudson, etc.
<jdaggett> how to include type designers is critical
<ChrisL> agree with vlad too
astearns: We would notify the list, obviously.
fantasai: In regards to whether Fonts 4 or WICG, something we can
do for shorter-term features is just... rename the
current draft to Fonts 5, merge in the small features to
the current Fonts 3, make that Fonts 4.
fantasai: Then we can just take like min-font-size, and system-ui
font. They can go to CR as soon as editing is done.
ChrisL: I feel that one of the benefits of having WOFF going, is
having type experts like John Hudson contribute to this.
ChrisL: I don't want to dilute things by moving off to another
group.
TabAtkins: If they want to follow all of CSS--fonts plus
non-fonts-- then they should be okay to follow fonts
plus non-fonts in split groups.
astearns: It's not a new module. It's just adding stuff to a
module we already have, and it's pretty well integrated
with the text we have in Fonts L3.
astearns: So keeping it in our module system seems easier for the
editors.
astearns: And everyone working on it has expressed an interest in
keeping it in github.
astearns: Tab, you're free to object, but in this case I think we
should keep it in house.
astearns: As a different argument, we were talking about koji's
proposal for step-sizing, and taking that to incubation.
astearns: I think it would be appropriate there.
astearns: I would like to decide now to keep it in the group, will
you object?
TabAtkins: I object.
ChrisL: Then we have to recharter.
ChrisL: The charter says, that for each new deliverable we have to
have consensus to add it. If there is a sustained
objection, we're required to recharter.
TabAtkins: I'm not saying it doesn't go into fonts, I'm saying it
goes to WICG first, and then we put it into fonts.
TabAtkins: I'm not objecting to a new deliverable.
Florian: Current practice of the WG hasn't been to use the WICG.
Florian: If we want to...
Florian: If we want to do this, we should have a discussion about
this topic, not about Fonts specifically.
<leaverou> +100 to Florian
Florian: Until we have that discussion, then we should follow the
usual process that we have in this group.
Florian: If we need to pause everything and have that discussion
now, fine.
<tantek> I'm going to point to this related proposed break out
session for tomorrow:
https://www.w3.org/wiki/TPAC2016/SessionIdeas#Incubation_as_the_New_Normal
TabAtkins: I don't think we should take up time during the F2F for
this discussion.
astearns: We have no more time to this. We had a proposal. We had
an objection. We are going to do nothing.
myles: Nobody likes this. Nobody in the whole world thinks this is
a good idea.
leaverou: So Google is stalling progress until we change the
process to be the way Google wants.
Florian: And moving to a process where consensus doesn't apply.
Vlad: So we have a procedural objection, but no substantive
objection.
RESOLVED: We will work on font variations.
<dbaron> I believe Vlad (or someone else) also said something like
"there's consensus to work on it, but not consensus on
where to work on it"
Font Variations Revisited (Excerpted from Afternoon Session)
------------------------------------------------------------
Rossen: Wanted to revisit the font variations discussion
Rossen: My proposal is to continue this work in Fonts Level 4. Any
objections?
Rossen: I really don't want this to be the precedent for the chair
override feature...
hober: I support this proposal.
* fantasai too
TabAtkins: I'll tell you later, for now proceed
RESOLVED: Font variance is part of Fonts Level 4
Motion Path
===========
scribe: TabAtkins
Offset Shorthand
----------------
<ericwilligers> https://drafts.fxtf.org/motion-1/
jihye: [missed some intro]
jihye: There are two new properties - offset-position and
offset-anchor.
jihye: offset-position defines where the path starts in the
container.
jihye: offset-anchor defines where on the element starts on the
path.
<astearns> (shane draws)
<shane> https://usercontent.irccloud-cdn.com/file/NnZEDgV4/IMG_20160920_114516.jpg
jihye: There's a problem when we put these into the shorthand.
<jihye> https://drafts.fxtf.org/motion-1/#offset-shorthand
jihye: The shorthand is now ambiguous.
jihye: Both offset-rotation and offset-path have an <angle>, and
offset-position and offset-anchor have <position>.
jihye: So they're ambiguous.
jihye: Shane proposed to use a ray() function in offset-path.
TabAtkins: ray(<angle> && <size>? && contain? )
jihye: With this, it cancels the <angle> ambiguity.
ACTION jihye change offset shorthand to use || instead of &&
<trackbot> Created ACTION-793
RESOLVED: Switch the polar-positioning part of offset-path to be a
ray() function.
<dbaron> offset-distance also has conflicts with the position
values, no?
<position> ambiguity
--------------------
jihye: Next is <position> ambiguity.
jihye: One solution is getting rid of offset-position/anchor in
the shorthand (it resets, but can't be set).
jihye: Another is use to slashes to separate.
TabAtkins: 1st option is drop -position and -anchor from
shorthand, so get reset but can't get set.
TabAtkins: Other option is to use slashes.
fantasai: There's another issue - the offset property should be
resetting top/left/bottom/right.
TabAtkins: This is a name collisions, they're not actually
interacting.
shane: offset-path feeds into Transforms.
fantasai: Okay, we might need to rethink the naming of one or both.
shane: We had shipped when it was named motion-path.
<dbaron> https://drafts.csswg.org/css-logical-props/#propdef-offset-block-start
is a bit of a naming collision
shane: We just put thru a rename, as early as we thought we could.
shane: We'd be increasingly concerned about changes to the names.
TabAtkins: While the logical t/r/b/l isn't implemented by anyone.
TabAtkins: I'm in favor of just taking out of the shorthand; most
of the time defaults work just fine.
shane: I got some impl feedback from Eric Willigers, Chrome
implementor.
shane: He did some demos. He said most of them, he has to
manipulate top/left (because we don't have offset-position
implemented yet).
shane: So that suggests offset-position is frequently used.
shane: And it suggests the ordering - offset-position first, then
offset-anchor?
TabAtkins: Makes sense to me.
astearns: If we're introducing a slash for position, might as well
do it for anchor.
TabAtkins: Oh yeah, once we've paid the cost, we should go all the
way.
astearns: Any objections?
<tantek> is there a GH issue on this? with history?
<tantek> I'm having trouble following :/
<tantek> I'd like to see a proposal in a GH issue if possible
<ericwilligers> https://github.com/w3c/fxtf-drafts/issues/24
<tantek> thanks ericwilligers
<shane> tantek: also https://github.com/w3c/fxtf-drafts/issues/42
* tantek reads GH threads
<tantek> I'm a little concerned about a mixture of spaces and '/'s
for separation
<tantek> sounds confusing, like the 'font' shorthand (which I
still can't remember reliably enough to use :p)
<TabAtkins> tantek, this is most similar to the border-image
shorthand. But yeah, font and transition/animation all
use it too.
<tantek> thanks TabAtkins. Commented on
https://github.com/w3c/fxtf-drafts/issues/24
dbaron: This is getting to be a complicated microsyntax.
<TabAtkins> offset: <offset-path> || <offset-rotation> ||
<offset-distance> [ / <offset-position> [ /
<offset-anchor> ]? ]?
<TabAtkins> offset: [ <offset-path> || <offset-rotation> ||
<offset-distance> ] [ / <offset-position> [ /
<offset-anchor> ]? ]?
fantasai: What if you just want to do an offset-position?
TabAtkins: That's the same as just doing a translate.
fantasai: Hmm, that doesn't match my recollection.
<jihye> https://drafts.csswg.org/css-fonts-3/#propdef-font
<dbaron> shans, you haven't shipped the shorthand, have you?
<dbaron> I'm not convinced the syntax that Tab wrote above is even
unambiguous
<dbaron> since offset-path has bits that conflict with the other
two (or at least one of them)
fantasai: From what I recall discussing, if everything else was
set to its initial value, offset-position would be
setting the absolute position of the box with respect to
the containing block.
fantasai: This makes it a useful positioning system, independent
of the other values
fantasai: And so the shorthand should be able to accept only a
position, to allow for it to be used as such.
TabAtkins: You can't just use translate for that?
fantasai: Translate can't reference the size and position of the
containing block.
fantasai: It's not the same thing at all.
fantasai: We integrated a proposal that could do many things.
fantasai: We were expecting to use certain parts together.
fantasai: It would be less common that using just path, etc.
fantasai: So what we need for the shorthand is look at what people
actually want to specify, and make those easy.
fantasai: So setting just position looks common.
fantasai: And setting a path with distance + rotation.
shane: That will usually require a position, too.
shane: If the path is an SVG path, you can get similar effect by
using a M command. But the other path types can't do that.
shane: And using the keywords for positioning, you can't be
relative to the containing block.
<jihye> https://drafts.fxtf.org/motion-1/#propdef-offset-path
<jihye> offset-path changes to => <url> | ray(<angle> <size>?
&& contain?) | [ <basic-shape> | <path()> ] ||
<geometry-box> | none
fantasai: So we can use positioning information rather than
slashes everywhere.
fantasai: So like start with offset-position first. Then path/
rotation. Then distance.
fantasai: Then after you can have the anchor.
shane: You still have anchor, so we can leave it out or use a
slash.
fantasai: I guess you'd put a slash before anchor.
shane: jihye could speak to common polar positioning uses.
fantasai: location, direction, distance along the ray.
shane: jihye, how common is it to set anchor in polar positioning
cases?
jihye: I think center is the common thing.
jihye: Default value for anchor is "auto". When I described some
use-cases, I found center is more useful than "auto".
fantasai: We made it auto so the position would function the same
way as for backgrounds.
jihye: That's useful when path is specified with angle; but when
you're using the other value types, like circle(), you have
to adjust every element which is on the circle path.
<dbaron> incorrectly thought that ray() discussion was about
changing something just for the shorthand, rather than
for the offset-path longhand-
<dbaron> Am I understanding correctly that 'offset-position: auto'
is like relative positioning and 'offset-position:
<position>' is like absolute positioning?
<fantasai> yes, exactly dbaron
<dbaron> I think that section of the spec could be a bit clearer,
then.
<dbaron> I still don't understand what offset-anchor: auto
combined with offset-position: auto does
astearns: So this sounds like we do still need anchor with a slash.
astearns: So it sounds like we can put position first, use ray(),
then the rest, then / with anchor.
TabAtkins: I might say leave anchor out entirely - it's like
transform-origin, and that's a separate property.
fantasai: Yes, but it seems that switching between auto and center
would be reasonably common.
TabAtkins: That suggests that "auto" can just do the
background-position thing when path is "none", and
otherwise be center. Then you rarely need to touch it
at all.
shane: Almost all examples use offset-anchor:center. It's by far
the most common thing to do when you position on a path,
sounds most common when it's polar as well.
shane: It's okay to make this work okay for positioning as well,
but all the rest requires center as the default anchor.
fantasai: So "center" as the initial value? That's fine.
fantasai: I think switching it when path is none vs other is
confusing.
fantasai: We can do something like have it default to
background-like when you don't have a path in the
shorthand, center otherwise. But not base it on the
actual value of path.
TabAtkins: I think we generally dislike magic in the shorthands;
we've used it before, but usually want to handle it at
the value level.
astearns: Running out of time. Let's fix up resolutions.
TabAtkins: <offset-position>? [ <offset-path> [ <offset-rotation>
|| <offset-distance> ] [ / <offset-anchor> ]? ]
RESOLVED: Position before path before distance and anchor
<dbaron> I filed https://github.com/w3c/fxtf-drafts/issues/45 and
https://github.com/w3c/fxtf-drafts/issues/46 on my issues.
Received on Wednesday, 16 November 2016 02:28:38 UTC