W3C home > Mailing lists > Public > www-style@w3.org > November 2015

Minutes Sapporo F2F 2015-10-26 Part II: font-weight-adjust, Box Alignment, Dev Meetup in Sydney [css-fonts] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Nov 2015 20:38:15 -0500
Message-ID: <CADhPm3stjxjZYp=pNS8pKvxwL4_1A4p2dyawW5XVBAz9rVeE+w@mail.gmail.com>
To: www-style@w3.org
font-weight-adjust
------------------

  - There was conversation about the usefulness of having a property
      to try and adjust the font weight of a fallback to make it
      more consistent with the primary font.
  - There were several arguments against this proposal:
      - It wouldn't work well/at all across different scripts such
          as Latin to CJK.
      - Weight isn't consistent across fonts.
      - This would only work well on Latin text.
      - There was a lack of examples of where this was a real-world
          problem.
  - It was decided that was better addressed by using @font-face.

Box Alignment
-------------

  - RESOLVED: All layout modes use "true" alignment by default for
              the alignment properties.
  - There was some bikeshedding on "true" as a keyword, and TabAtkins
    will create a poll for a potential rename from the suggestions in
    the minutes.
  - Everyone was actioned to review the Alignment spec.

Dev Meetup in Sydney
--------------------

  - It was suggested to hold a developer meetup in Sydney.
  - Tentative schedule is the evening of Feb 3rd, hosted at Google,
    happening around 6pm or 7pm.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: dbaron

font-weight-adjust
------------------

  <astearns> http://www.w3.org/mid/F1E15038-FA2D-485D-B328-089293E691AC@rivoal.net
  Florian: There's an ongoing thread about font-weight-adjust.
  Florian: If you're trying to pair fonts in a document, and have a
           font that looks the way you want, we can adjust when x-
           heights don't match using font-size-adjust.
  Florian: We have a similar problem with font-weight. You might
           want to match 2 different fonts with different ways in
           the document -- or especially with fallback (doesn't
           load; Unicode ranges).
  Florian: If the pairing of fonts is to your taste except font
           weights don't match, then you have an issue.
  Florian: Font weights have numeric value, but the number doesn't
           have a meaning against some measurement.
  Florian: We want a way to say 400 weight for main font but 600
           weight for fallback.
  Florian: John doesn't seem to agree on the problem or the solution.
  Florian: I understand disagreeing about solution; more confused
           about disagreeing about problem.

  jdaggett: If you go across different scripts, e.g., Latin to CJK,
            or Thai, Arabic, pairing typefaces is a classic design
            problem for type design.
  jdaggett: It's not a simple problem to solve. Type designers spend
            a lot of time thinking about how to express the voice of
            one typeface in a different script.
  jdaggett: It's not just weight
  jdaggett: What I don't agree with in the formulation of the
            problem is the notion that you're using a single font
            list for all languages
  jdaggett: That's what people do, but it's not the right thing to
            be doing. The right thing: if you have content in
            Japanese, use appropriate Japanese typeface; content in
            Greek, use appropriate Greek typeface.
  jdaggett: Ideally those are all typefaces you selected that
            support the specific script.
  jdaggett: Making a design decision for each language...
  jdaggett: You could make a universal font list work, but not ideal.

  jdaggett: Matching on weight is difficult. A particular weight in
            a typeface may be difficult to match with a different
            typeface.
  jdaggett: When you're talking about a fallback situation, not
            providing a webfont, you're stuck with a tough problem.
            The way the typeface is designed used a different set of
            principles, so just matching weight won't get you much.
  Florian: I agree just matching weight won't get you much. I don't
           see why it's useful to have the size adjust and not have
           this one.
  jdaggett: Size is a linear scale; weight is not consistent across
            fonts.
  jdaggett: One family may have regular and bold; another family may
            have broader range.
  jdaggett: Size is consistent with a little tweak; font-size-adjust
            gets you that. Weight is not consistent. Taking a font
            designed one way, comparing to another family not
            designed with same principles, won't get something that
            matches.

  jdaggett: The example I wanted to show:
            http://typeproject.com/fonts/tpmincho
  jdaggett: They've designed a range of font families. There's a
            high-contrast face. Contrast is how thickness of
            vertical stems compares to thickness of horizontal stems.
  jdaggett: Can see similar construction of Latin typefaces.
  jdaggett: Bottom one is a low contrast face. The verticals and
            horizontals are roughly comparable.
  jdaggett: Going from one face with a different contrast to a
            family without that same contrast, no matter what the
            weight is, you won't get something that's matching.
  jdaggett: That weight value doesn't move well across families.

  Florian: Isn't that also true about size adjustment?
  jdaggett: The step function, the weights available, is going to be
            different. With font-size-adjust, you can tweak the size
            a tab and get something comparable. Though not a be-all-
            and-end-all solution.
  jdaggett: I don't think what you're proposing is going to work in
            practice.
  jdaggett: What Jonathan was saying on the list: if you want to do
            something like this, pair a Latin face with faces from
            different locales, you can do something like this
            already using @font-face rules with local().
  Florian: If you were to use a mechanism like that, you have to use
           fonts side by side. For most random pairing of fonts,
           no [...].Just like for size adjustment need to look side-
           by-side and pick specific value.

  zcorpan: As I understand it, the ability to use different fonts
           for different languages is orthogonal; you can do that
           with :lang() selector.
  zcorpan: This is only the case where you want to fix font weights
           between primary font and fallback font, then you only
           have 2 fonts for one specific language to deal with.
  zcorpan: I don't see that this is trying to fix everything with
           one mechanism.
  zcorpan: I think this is just fixing weight of primary font vs.
           fallback font.
  jdaggett: You think this mechanism makes sense?
  zcorpan: It's not saying proven to be necessary, but I think the
           argument that it won't fix everything and that you should
           be doing language-specific instead is orthogonal.
  jdaggett: If you're doing it language specific, you can say that
            for bold you want a particular weight.
  jdaggett: The only way to pair faces from different fonts is to
            know those actual fonts.
  jdaggett: So you can use @font-face with local().
  jdaggett: To match what he's talking about, you have to know the
            faces.

  SteveZ: I wanted to say 2 things. font-size-adjust doesn't really
          do all the adjustments you want; it doesn't deal with
          Thai, which has small x-height on some letters due to
          additions above and below, so matching a Latin face to
          Thai using the same font size typically looks ugly; Arabic
          has similar types of problems.
  SteveZ: My concern overall is that all of these quick fixes work
          well for Latin text but don't work well for international
          text.
  SteveZ: Trying to fix each problem means we end up with large
          number of properties: then you'll want contrast, and then
          how do they interact when they're all specified?
  SteveZ: It makes more sense to put in a language map, where some
          properties will allow you to pick specific things for the
          language, rather than doing clever things that do matching
          without understanding what's going on.

  Florian: In that direction, John was saying in some cases use
           language tagging and in some cases use @font-face.
  Florian: What I didn't understand was for Web fonts (not local
           fonts), does the fragment identifier thing work?
  jdaggett: I don't understand why font packaging came up in that
            thread. It's orthogonal to that issue.
  jdaggett: It doesn't matter whether a font is packaged or separate
            fonts. No current browser supports TrueType collections.
  Florian: Your mechanism only works for local fonts.
  dbaron: [explains about @font-face rules each being a single face
          with a single weight]
  jdaggett: TrueType collections is a simple format; just a bunch of
            offsets for the fonts; effectively still loading
            individual fonts
  Florian: If we were to have @font-face rules that pointed to a
           collection, then this would be a problem.
  jdaggett: But this has little bearing on the original case.
  jdaggett: But to be clear, there will never be a format where a
            single @font-face rule points to a set of fonts rather
            than a single face.
  <ChrisL> we will have @font-face rules that point to a TTC. But
           they will use fragids to point to individual faces, not
           the collection as a whole.

  dauwhe: Do you have examples of sites that are visually confusing
          now because of problems matching weights on fallbacks?
  dauwhe: I've been trying to construct examples with fonts on my
          machine, but haven't been able to yet.
  Florian: I have seen examples within Bloomberg, with requirement
           to use Latin font for all Latin and digits even in other
           languages; digits match badly against CJK font.
  Florian: The correct answer may be to use digits in the CJK font.
  jdaggett: Going between Latin and CJK generally you want a
            different size altogether.
  jdaggett: If you're going to support multiple locales on a site,
            the decision about attribute and typeface to use is a
            design decision.
  Florian: As a design decision, you have Latin letters in the CJK
           that you want to match... to adjust. You could say not to
           use the Latin font, but their design decision is to use
           the Latin font everywhere.
  jdaggett: It's difficult to take 2 typefaces designed to different
            principles together.
  Florian: That specific example, the most glaring example was
           weight; fixing weight wouldn't make it perfect, but
           probably tolerable for most readers.

  Florian: I think using @font-face is adequate for solving this.
  <ChrisL> +1 @font-face suffices for this

  jdaggett: Apple's UI font has an explicit cascade list set up. If
            you are drawing in UI in the system font, and hit a
            different script, there's a chain of postscript names
            that identifies all the fonts that will be used as
            fallbacks.
  jdaggett: That's a controlled environment, they know the set of
            fonts.
  Florian: Apple is not the only case where there's a controlled
           environment. Webfonts can also be controlled environment.
  jdaggett: You can do the same thing using ...

  Florian: I was unclear about collections (that's cleared up); I'm
           still fuzzy about sizing part of it.
  Florian: We can try to see if that works.
  TabAtkins: I agree with John; unless using @font-face is really
             bad or hard to work with, we should stick with @font-
             face instead of duplicating functionality.
  Myles: I also agree with that.

Scribe: TabAtkins

Box Alignment
-------------

  fantasai: There's a lot of values in this spec.
  fantasai: The ones we need to keep are positional alignment,
            baseline value, and the distributed-alignment keywords.
  fantasai: The major point where I'm pretty unsure is the
            overflow-alignment keywords.
  fantasai: If you try to use margins for alignment, you do "safe"
            alignment - if you're bigger than the container, you
            don't center or end-align, you always start align.
  fantasai: In Flexbox/Grid, you're aligned absolutely, so you can
            overflow off the start edge.
  fantasai: Margins do that because you can't scroll to content that
            overflows the start edge *of the viewport*.
  fantasai: So margins might not always center, but it ensures it
            won't overflow to the unscrollable area.
  fantasai: So one issue is, what should the alignment properties do
            on layout models other than Flexbox/Grid? Should they be
            consistent, or use the margin behavior?
  fantasai: Second issue is, whatever the default is, do we need a
            switch to change, or do we need some other solution to
            let the user reach the content in the unscrollable
            region?

  fantasai: So, what should the default behavior of the alignment
            properties be?
  TabAtkins: I'm for simplicity, so I'm okay with them all being
             "true".
  dbaron: I guess I'm okay with them all being "true" by default.
  dbaron: Though, it's a little bit of a footgun, but it is easier
          to understand.
  TabAtkins: Agree - I've had authors ask me about centered Flexbox
             overflowing off-screen, so I had to tell them to use
             margins. But it's annoying to *not* do "true", too.

  szilles: [question about center on text]
  szilles: It's clear what overflowing off the flow direction, means.
  szilles: But less sure about what overflowing means from a wrap
           point of view.
  fantasai: That's a different issue; these don't apply to text.

  fantasai: Anyone object to making everything "true"?
  [no objection]
  dbaron: I'm okay with it, given that you can specify the "safe"
          behavior.

  RESOLVED: All layout modes use "true" alignment by default for the
            alignment properties.

  fantasai: Now, is the current safe/true switch what we want, or do
            we want something even smarter?
  fantasai: Or is there some other solution to the problem of
            centered things overflowing into the unscrollable region?
  TabAtkins: I doubt we'll be able to come up with a general
             solution to unscrollable areas.
  TabAtkins: But I'm fine with the current switch. A little
             footgunny, but probably fine.

  fantasai: So is everyone fine with the current switch syntax? Or
            just have the "safe" keyword, and make unspecified be
            "true"?
  dbaron: We might eventually want to apply this to text-align,
          which defaults to "safe".

  szilles: I think it's better to have authors specify what they mean.
  fantasai: Too late for that unfortunately - the properties already
            allow it to be omitted in implementations.
  fantasai: [discusses serialization]
  fantasai: If you write "true center", it'll serialize back to just
            "center", since omitted defaults to "true".
  TabAtkins: So per dbaron's argument, I think it's fine to leave
             "true" here. We don't need it yet, but it'll simplify
             merging in more alignment properties later.
  szilles: +1

  fantasai: Anyone want to bikeshed the keywords?
  dbaron: true looks like a boolean ...
  [bikeshedding "true"]
  [literal, exact, always, dwim, honored]
  <fantasai> force?
  <TabAtkins> even-if-overflow
  <dbaron> unsafe?

  ACTION TabAtkins to write poll about naming of "true" keyword,
         using suggestions in the minutes.
  <trackbot> Created ACTION-727

  fantasai: I remember why we had it vary per el - we wanted to do
            <center>/etc through these properties, and they needed
            to be "safe".
  fantasai: But maybe we can key that to "legacy".
  TabAtkins: Or just drop it, like we discussed, and handle <center>
             somehow else, or not at all.
  fantasai: Yeah, so we'll discuss that with dbaron later.
  fantasai: So really we're just blocked on review.

  ACTION everyone to provide feedback for the Align spec.

  Bert: There's two kinds of "true" centering for text - overflow to
        the left, and ignoring floats - center text while ignoring
        images on the side.
  fantasai: That's tricky, because currently text-align only
            distributes extra space on the line after line breaking
  fantasai: But this would affect text-wrapping.
  TabAtkins: Maybe that's a separate ability, then - the ability to
             ignore floats for line-length determination. Then you
             can still just safe-align or something.

Dev Meetup in Sydney
--------------------

  Bert: Sydney has John Allsopp, the Web Directions conference guy,
        and he can organize something if we want.
  Bert: So do we want to attend that, or speak at it?
  [discussing Sydney meeting timing]
  Rossen: So this meetup will happen one of the SVG meeting days?
  Rossen: And this is somewhere in Sydney, tbd.

  Bert: Yeah, depending on how big we want it to be. John Allsopp
        has some space...
  dino: It's tiny.
  shane: We can probably offer a venue for this.
  Rossen: Do you have a big enough space?
  shane: It can hold 150 people.
  shane: I'll need to confirm it, but it should be fine.

  Rossen: So what day is it?
  shane: Feb 3rd is FXTF. Maybe best overlap?
  astearns: Then, people who need to leave might still be able to
            make it.
  Rossen: So idea is that, on Wednesday (Feb 3), we'll have the
          biggest mass of standards people. All SVG, CSS, and maybe
          some Houdini.
  shane: Except CSS people who have to leave that night, but it
         doesn't sound likely.
  shane: And I think most US flights leave in the morning, anyway.

  Rossen: Sounds good. Who's organizing?
  Bert: I can coordinate.
  shane: Email me so I have a permanent record.
  TabAtkins: I'm giving a <20min Houdini talk next month, I can
             re-give it.
  Rossen: Is this meant to be CSS-only? Or SVG too, etc.
  Bert: I wasn't thinking about it yet. All 3 would work.
  shane: I agree.
  Rossen: Okay, sounds great. Let's organize that. Tentative
          schedule is the evening of Feb 3rd, Wednesday, hosted at
          Google around 6pm or 7pm.
  shane: Worst case, if Google can't host, Someone else probably can.

<br type=lunch duration=1h>
Received on Thursday, 19 November 2015 01:39:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC