- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Aug 2015 15:38:10 -0400
- To: www-style@w3.org
Fonts
-----
- It was clarified that the 'system' keyword will be in Fonts 4.
- jdaggett will work with TabAtkins and fantasai to put Fonts 3
into bikeshed working through the issues that jdaggett has had
in the past
- The proposal from Myles regarding introducing small-caps into
font-synthesis was discussed.
- There was concern that the use case was just theoretical,
not actual, though dauwhe said that he has to make sure
there is no use of synthetic small-caps in his work.
- Several members argued that they believed there needed to be
a fallback for when small-caps isn't available.
- RESOLVED: support small-caps in font-synthesis in Fonts 4
Specifying how keyframes interact
---------------------------------
- This topic will wait until the F2F in Paris to make sure that
Mozilla is okay with the change.
Unprefixing min/max-content
---------------------------
- RESOLVED: unprefix min/max-content
- gregwhitworth will work on building out a test suite.
Ruby Issues
-----------
- This discussion will also wait until the F2F.
max-content Contribution Not Defined for Flex Items
---------------------------------------------------
- Fantasai's proposal needs review, especially from TabAtkins and
dholbert, so it will also wait until the F2F.
===== FULL MINUTES BELOW ======
Present:
Tab Atkins
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
John Daggett
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Myles C. Maxfield
Anton Prowse
Simon Sapin
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Rossen Atanassov
David Baron
Daniel Glazman
Mike Miller
Edward O'Connor
Florian Rivoal
scribe: dael
Fonts
=====
bikeshedding Fonts 3
--------------------
plinss: Let's get started.
plinss: Does anyone have anything to add? I saw your note jdaggett.
plinss: Anything else?
jdaggett: On last week's call there was a discussion about the
system keyword and there was a resolution to accept that.
It wasn't clear to me from the minutes if that was
intended for 3 or 4.
jdaggett: It seemed to make more sense for me to be 4.
ChrisL: My recollection was for 4.
plinss: Mine as well.
jdaggett: That's fine.
jdaggett: There was also discussion of...There seemed to be a
discussion about putting the CSS Fonts 3 into bikeshed
and it wasn't clear how it got onto that, but it sounds
like there's a side issue where people are interested in
having the metadata associated with that's defined in
the fonts spec.
TabAtkins: Yeah.
jdaggett: I sent out a mail with a bunch of details on that. I
guess my only concern there is there were a lot of
troubles with Bert's processor dealing with specs that
have several descriptors with the same name as
properties. I'm a bit concerned about the risk of
introducing screwed up links, but I'm assuming TabAtkins
and I can figure this out. That was one concern I did
have.
<ChrisL> Tab, does bikeshed correctly separate descriptors from
properties?
* fantasai is in favor of resolving all of jdaggett's concerns wrt
processing
jdaggett: If there's no other comment, I'll go ahead and try and
do this with TabAtkins and fantasai and if there's an
issue I'll comeback.
ChrisL: I think the context was people wanted to put stuff in
Fonts 4 and TabAtkins had most of Fonts 3 bikeshedded and
we went on to think we should bikeshed it, but I don't
think we understood the complexity on the call.
jdaggett: Yeah. We'll try and work out those.
small-caps
----------
jdaggett: Do we want to talk about small-caps here or on the
mailing list?
ChrisL: I'd prefer here.
<jdaggett> https://lists.w3.org/Archives/Public/www-style/2015Jul/0463.html
<fantasai> https://drafts.csswg.org/css-fonts-3/#font-synthesis-prop
<ChrisL> http://www.w3.org/mid/7254728D-2325-4A22-A97A-461CBEAADD47@apple.com
jdaggett: This is Myles's issue.
myles: There are certain properties that browsers can synthesize,
like synthetic bold. If the font itself doesn't support it
the browser can do a hack. There's font-synthesis that says
don't do the hack.
myles: The proposal is to add a value for small-caps so the
behavior would be if I spec font variant small-caps and the
font doesn't support it, don't do it.
jdaggett: What was the motivation for this? Theoretical?
myles: Theoretical, yes. I'm working on supporting true small-caps
in WebKit since right now we always fake it and this seemed
like a reasonable thing.
<ChrisL> YES! to proper smallcaps in WebKit
jdaggett: My take is, synthetic bold and italics-we're not
synthesizing a property as the UA is synthesizing an
extra font. It's something browsers have always done and
it tends to trip-up authors. They might include a web
font and forgot to put in font-weight bold or whatever.
They get tripped up. I'm not sure I quite see here what
an author would to wrong to get small-caps or not.
jdaggett: If they're using a font that doesn't have small-caps
that's not a fault of an author. I see where you're
coming from with wanting an out, but I'm not sure I see
and extra use case.
astearns: Font synthesis isn't solving using bold when it's
missing, it's giving an author who cares about not
synthesizing a way to say don't do that. I'm not sure
about having a property that is opposed to having it
instead of doing synthesis for missing glyphs.
jdaggett: On a theoretical level yes, but the thing about
synthetic bold/italics-they're ubiquitous and we
couldn't say they're off by default. When you say small-
caps you're taking something that's not the default and
you want them.
astearns: It's not really opt-in. When you're authoring you can't
be sure the small-caps you're trying to use with the
font will be present. When font fallback happens you
might have a font without small-caps and it looks
terrible.
myles: The word terrible is apt. There's a distinct visual
difference between fake and true small-caps.
jdaggett: That goes without saying. I'm not clear on the
motivation why an author would...what's the problem an
author has.
astearns: Progressive enhancement. I want small-caps if and only
if the font I want to use small-caps with is present.
jdaggett: So astearns you think this is necessary?
astearns: I think more than turning off fake bold and italic. They
other...you need the smearing or slanting to show a
semantic difference. Small-caps I think would have a
better fallback to real capital glyphs.
plinss: I think it's interesting.
leaverou: I wanted to ask...if a small-caps variant isn't
available I think it's reasonable for the author to want
lower or upper as a fallback. Right now the only way I
can think of is to use text-transform. How do they say
if small-caps isn't available I want upper-case. How can
authors do this?
myles: All I can think of is @supports.
leaverou: That would test if it's present, not if there's a
variant.
<ChrisL> agree we need to look at easy fallbacks here
jdaggett: Most of the properties that deal with font features...it
goes with the assumption that you know the font you're
using. A lot of the fonts that are out there won't
support all the features. If you turn on annotations,
you may not hit a font with annotations so you get
unannotated.
leaverou: If you're depending on the user system you don't know.
jdaggett: That's my point. We don't provide a way of sniffing if
fonts have them.
leaverou: So you're saying authors shouldn't have that level of
control and it doesn't matter?
jdaggett: Authors should use these features with webfonts. Then
that's part of the page design. I'm using this feature
and I know it's there.
<tantek> you don't know that a webfont is there because it might
not load right? like JS?
<tantek> that's a key progressive enhancement case
jdaggett: We had a lot of discussions when working on font
features for CSS 3 Fonts. One of the keys is it's not
easy in terms of implementation to provide fallback.
leaverou: But for font-weight there's a whole algorithm.
jdaggett: That's a different thing.
jdaggett: A lot of these features are cumulative. You turn on A,
B, and C. Whether all of those are supported for all
glyphs will vary by character. Doing something
intelligent here gets very tricky.
leaverou: In most real world designs with small-caps the designers
would intend for uppercase not lowercase if small-caps
aren't available.
jdaggett: We don't have a mechanism for that.
myles: It seems like a conceptually different issue.
jdaggett: Definitely.
fantasai: I think using small-caps with system fonts is reasonable.
The same reasons that apply to turn off synthetic
italics or bold also apply for small-caps. There's
nothing different in the reasoning.
jdaggett: Font features and they way we've supported them they
have a definite fallback. In synthetic faces you're
running the same algorithm with faces that are synthetic.
It's apples and oranges
fantasai: You're making the apples and oranges because the
underlying technical implications.
fantasai: If we look back in time small-caps was a separate font
face like bold and italics. They were all different
fonts. If we look to the future there's potential for a
font face to have embedded the necessary information for
bold variants. From a user perspective it's still a
variation on that one font.
<astearns> +1 to fantasai's point. I don't see the distinction
myles: I agree with fantasai
jdaggett: I think there's a real distinction and I don't like the
idea of taking something that has special fallback
behavior and then creating opt-outs. Do we do the same
thing with super and subscript fonts? Would we add those?
ChrisL: Over time I would like to yes.
jdaggett: It's over-designed.
ChrisL: Could you justify that?
jdaggett: You're adding extra property values that are giving you
an opt-out for an opt-in feature. I'm applying
superscript.
ChrisL: So to opt-out you just don't ask. I can see that.
jdaggett: I see what people are saying for the theoretics, but
when I think about 'does someone need this', I think
we're starting to get to the point where we're adding
things with little value
fantasai: Why is it bold and italic are and small-caps isn't?
jdaggett: If the font has it then it's available.
astearns: You're eliding the question of fallback fonts where you
don't know which font will be used.
jdaggett: Historically synthetic bold and italic are special and
have caused all kinds of problems. The basis for the
font synthesis these are specific features where you can
opt out.
fantasai: I don't see any reason why small-caps should be any
different. All the reasoning that applied to one does to
the other.
<leaverou> +1 to fantasai from me too
jdaggett: Font weight and style are font selection property. Font
variants you're specifying font features. Within this
face I want to use these if they're available. We did
for specific reasons...
<leaverou> "if the font has it, then it is available" applies to
small-caps as well, no?
<fantasai> leaverou, wrt fallback stuf... I guess you could turn
font-variant-caps into a list
<ChrisL> petite caps if available, otherwise small-caps, otherwise
uppercase
astearns: Another way of getting to a solution would be to add
more font feature values. I don't think this is the way
to go. You have small-caps if available, this kind of
capitals if it's available. Have a way to say use small-
caps if available but I want all caps if small-caps
isn't available.
jdaggett: As originally specified, I said we should make this mean
it just uses the glyphs if they're there but there was
push back because of compat we have this fallback
behavior.
dauwhe: Synthetic small-caps are an abomination in my world.
dauwhe: I have to do everything I can to prevent them on my
projects.
<dauwhe> I could lose my job for using synthesized small-caps in a
book :)
<bradk> How about 'font-transform: small-caps' that uses
non-synthesized small-caps if available, even if there is
no @font?
plinss: I'm hearing a lot of people in favor of controlling if we
have synthetic small-caps.
jdaggett: So am I. I can live with it.
<tantek> +1 on author control of whether or not they get synthetic
small-caps
Bert: A question for dauwhe. I can understand avoiding synthetic
small-caps, but what do you do instead?
dauwhe: In that case you use actual caps perhaps.
jdaggett: That's difficult to do. There's no way to @supports this
font for this feature.
dauwhe: This is my use case. It's how I'd make decisions. If the
tech can support that is a different thing.
fantasai: You'd handle that...when you want the fallback to be
full caps that's what should have been in the source.
Your source code should have it in capital letters and
you use all small-caps to lowercase that and it will
fallback to nothing which is caps letters.
dauwhe: That's what we do. We'll text-transform lowercase.
fantasai: What's the fallback if you have small-caps but not all
of them. I presume we text transform.
jdaggett: That's part of the fallback.
fantasai: As long as the UA supports the all small-caps value...
there are cases where you're want it to fallback to
lowercase like if you have a header.
fantasai: So you have all the capabilities you've just requested.
You want to be able to turn off the synthetic.
leaverou: So is that what you want in the markup?
fantasai: Or a text transform.
leaverou: That would interact with small-caps.
fantasai: No, if the source...sometimes the capitalization is
because semantics. That would be in the source. If you
have a heading you can use the transform and font-
variant small-caps and if it doesn't have that it
fallsback. All the behavior is available, we just need
to turn off the synthetic.
<astearns> https://drafts.csswg.org/css-fonts/#all-small-caps
leaverou: ooookay....
plinss: I'm not sure if what you're saying gets you want you want.
You're not allowing a real small-caps situation.
jdaggett: There is an all small-caps feature that makes both upper
and lower to small-caps
plinss: But if you text transform you're using the mixed case.
fantasai: No...if the presentation you want is all capitals you
use text transform. If you want it to be small-caps and
fallback you use text-transform and then fallback. If
you want the fallback as mixed, we need the font
synthesis.
jdaggett: I think we should move on.
<tantek> I'd like to hear designer opinions of what would be good
fallback in the absence of "real" small-caps.
<tantek> Rather than hypothesizing by all of us other smart people
;)
* liam [can't call in, at a conference] would prefer a way to
select a font that had genuine small-caps in the first
place, if there's one available
* bradk agrees with Liam about selecting real small-caps, and have
a fallback if not available.
plinss: I'm hearing a lot of people in favor of adding control and
jdaggett, you said you can live with it?
jdaggett: Yep.
jdaggett: I think it should go into CSS 4
myles: Fine with me
RESOLVED: support small-caps in font-synthesis in Fonts 4
<fantasai> Actually, there's one case you can't get just with the
font-synthesis and text-transform: mixed-case small-
caps falling back to full caps
Specifying how keyframes interact
=================================
TabAtkins: dino said it was fine so I'd like to have a resolution
to put this in the animations draft, one of them.
ChrisL: You mean which version?
TabAtkins: Yeah.
TabAtkins: Since this is a basic resolution of a core feature it
should go into the first version of animations we have
plinss: Can you sum up in a sentence or two?
TabAtkins: It is a rigorous description of how a keyframes rule is
broken down and how different keyframe rules with the
same selector interact. This isn't well described now
and though I thought it was obvious, it wasn't. I wrote
an explicit set of how to break down keyframes rules.
It matches the web animations model
fantasai: Have you heard back from any moz devs?
TabAtkins: I have not. They were tasked with looking and
responding last week but no one has done so.
fantasai: I think dbaron is on vacation.
jdaggett: He's in meetings.
fantasai: We might want to wait for him. I'd like to hear back
from Mozilla.
TabAtkins: I'm not in a rush, I just don't want to lose track of
this.
plinss: So we loop back when we have dbaron.
* fantasai notes that this moves the topic to the F2F
* astearns fantasai: just added it to the ftf agenda
Unprefixing min/max-content
===========================
TabAtkins: fantasai I think you said we have already resolved and
need to get it done?
fantasai: I vaguely recall it, but I couldn't pull up the
information. Min and max we're 100% clear. 'fill' we
want to check in on.
TabAtkins: So for unprefixing it would be re-resolve here and put
a note into the sizing spec that implementors are
encouraged to use these unprefixed.
<gregwhitworth> do we have a test suite for these?
fantasai: That sounds good.
TabAtkins: Anyone object?
gregwhitworth: Do we have a test suite? It would be good to make
sure we got all the testing covered.
fantasai: Part of the reason the spec isn't done is we haven't
worked out the edge cases. We can do a basic test suite,
but a full test suite would be all the pieces.
gregwhitworth: So you don't have any reservations?
fantasai: Implementations have these pieces. As long as they have
the pieces that are consistent like if you put a float
in a 0 or a really big float. I guess we could put a
bunch of random content with a JS randomizer and say if
they're all identical we win.
gregwhitworth: I just wanted to bring it up. I don't think this
has to do with unprefixing, more an interop concern.
fantasai: You have a good point. We can pull in tests, like I'm
sure Mozilla has tests.
fantasai: The question is who is going to do that.
plinss: I'd like to see some tests. I don't see any linked to
sizing.
gregwhitworth: I'm supposed to be an editor so I can track down
some tests since I brought it up.
gregwhitworth: I'll ping dbaron and try to get them checked in. I
doubt before the F2F but I'll take care of that.
* ChrisL cheers for Greg
TabAtkins: If you do notice any holes, they should behave like
floats. So it's easy to do tests by doing a float.
fantasai: Float tests should be easy to write.
gregwhitworth: Okay, cool.
plinss: Let's resolve to unprefix min/max content.
RESOLVED: unprefix min/max-content
fantasai: Even if the behavior isn't defined yet or it's wrong, in
your implementation if it's equivalent to floats, it
should pass.
plinss: That's for getting tests gregwhitworth
Ruby Issues
===========
plinss: Who wants to talk about these?
plinss: Aaaaaaanyone?
myles: Perhaps we should defer.
plinss: I think so. To the F2F?
max-content Contribution Not Defined for Flex Items
===================================================
plinss: fantasai I think this was yours
TabAtkins: Has fantasai gone silent?
* fantasai is here, just pulling up the mail
<plinss> https://lists.w3.org/Archives/Public/www-style/2015Jul/0429.html
fantasai: This was me going through the case of max-content and
how it's defined in flex. I think the definition for
flex items is not quite correct, but I'd like TabAtkins
and dholbert to check it. I'm not sure it's useful to
talk about here until that happens.
<gregwhitworth> Can you please review this too:
https://lists.w3.org/Archives/Public/www-style/2015Aug/0058.html
plinss: Okay, do we want to action them to look?
gregwhitworth: I think this is a good one for F2F. I did work
closely with our developers for flexbox and I gave
the feedback. I think technically it would cover
what we expect. But at the same time we want to
wait for feedback from other people. I wanted to
make sure nothing was missed.
gregwhitworth: It ties in with Christian's e-mail....it hinges on
this.
<astearns> added ruby and max-content in flex to ftf agenda
fantasai: We'll just do a flexbox workshop in Paris.
<fantasai> (A technical one, not an editorial one)
<tantek> flexboxworkshop++
gregwhitworth: I agree. That would be great.
plinss: Okay. Defer to the F2F.
<fantasai> gregwhitworth, pick a night, we'll kidnap Tab
<gregwhitworth> fantasai: sounds good
<plinss> https://wiki.csswg.org/planning/paris-2015#proposed-agenda-topics
plinss: We have 2 weeks to the F2F. Please add topics and update
the wiki as you see fit. That's all I have for this week.
plinss: Alright. Thanks everyone and we'll talk next week.
Received on Wednesday, 12 August 2015 19:39:08 UTC