[CSSWG] Minutes Telecom 2015-08-12


  - 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.


  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

  Rossen Atanassov
  David Baron
  Daniel Glazman
  Mike Miller
  Edward O'Connor
  Florian Rivoal

  scribe: dael


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
  <ChrisL> Tab, does bikeshed correctly separate descriptors from
  * fantasai is in favor of resolving all of jdaggett's concerns wrt
  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.


  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
  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
  <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
  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
  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

  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

  dauwhe: Synthetic small-caps are an abomination in my world.
  dauwhe: I have to do everything I can to prevent them on my
  <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

  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
  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
  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
  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:

  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
  <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