W3C home > Mailing lists > Public > www-style@w3.org > May 2018

Minutes Berlin F2F 2018-04-11 Part V: Fonts, CSS Text / Text Decoration, Ruby [css-fonts] [css-text] [css-text-decor] [css-ruby]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 17 May 2018 03:33:26 -0400
Message-ID: <CADhPm3uoGr9Y437-9rEuAxRs4Nr6RCMd=bbNoHO22nkDtiMyHg@mail.gmail.com>
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.


  - RESOLVED: Parse the value of src throwing out invalid parts like
              media queries and not like selectors. aka You split on
              the commas and throw out the pieces you don't understand
              not the whole thing. (Issue #633)
  - RESOLVED: Use this: format(<string> [supports <feature-name>#]?)
              where <feature-name> is a CSS-defined identifier.
              (Issue #633)
  - An issue will be opened to determine if @supports for color fonts
      is necessary.
  - RESOLVED: Add an auto keyword to the appropriate font descriptors
              that has the effect of the following: 1) for font
              selection purposes the font is selected as if the
              appropriate initial value is chosen. 2) for variation
              axis clamping, clamping does not occur. (Issue #2485)
  - RESOLVED: Leave font-style computed values as-is; change
              font-style animation behavior so that 'normal' can
              animate with 'oblique <num>' (Issue #2505)
  - RESOLVED: Use 14 degrees as the angle for undefined oblique.
              (Issue #2295)
  - RESOLVED: Defer font-variant descriptor to L4. (Issue #2531)

CSS Text / Text Decoration

  - RESOLVED: Use from-font [for text decoration metrics] (Issue #2376)
  - RESOLVED: Add this value [text-spacing:space-first], suggest it's
              the default in epubs and add a open issue wondering if
              should be in the web in general. (Issue #2462)
  - There was general consensus that the property for paragraph-level
      line breaking should be a modifier on wrap not a separate
      keyword, but the name still needs to be bikesheded. (Issue #672)


  - Florian gave a brief introduction to the document of Ruby
      recommendations from Kobayashi-sensei. The document is available
      here: https://florian.rivoal.net/ruby/ and would be a good guide
      to Ruby editors.


Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael


Fonts L4 super-format()
  github: https://github.com/w3c/csswg-drafts/issues/633

  myles: There has been much movement in typography industry in the
         last several years. There are many features fonts can opt
         into now. One of the tenets of this new world where fonts
         can have technology inside is browsers that don't support a
         technology should not trigger downloading a font with that
  myles: In @font-face rules in the past this was done with the
         format() function in the src descriptor.
  myles: Inside the format() function it accepts a string. Now that we
         have 3 optional technology we probably shouldn't generate a
         bunch of strings with tokens. There should be a way for an
         @font-face to associate a URL with a set of requirements
         where only if browser fits requirements they should use this.
  myles: That's the issue. We don't have an opinion as to which
         proposal to do this should be picked. There's one we seem to
         be zeroing in on in the issue
  ChrisL: We have the format specifier and we don't want the
          combinatorial thing where we add more things and it
          explodes. So we expand the format specifier to that it has a
          string of what it requires. So existing browser can reject
          that font. That seems to be where the thread is ending.
  myles: Proposal is do we extend format to extend this.
  <ChrisL> so for example `format("opentype", requires variations,
           requires color)`

  Vlad: Hypothetical. Open type font that supports regular + color
        glyphs + variations. If you can't use color the font provides
        you the downgrade.
  myles: Yes. All of these technologies are created such that they are
         opt in and the browser can still use the font file. That's
         great for backwards compat but these new tech can add
         significant space in the font file.
  myles: In the case of color glyphs it's a lot. It would be great if
         browsers didn't have to download more data then needed.
  florian: Is this also avoid the case of a browser choosing to
           download a variable font when they don't support that
           instead of downloading other fonts.
  astearns: I thought that was correct. Browsers that don't support
            variable fonts will not download a font with that tag.
            Doesn't matter if the font in the declaration supports
            variables, but it's a tag for only if the browser supports
  florian: So fold variable into the rest.
  myles: yes.

  fremy: We shipped variables and color fonts so if we add this our
         existing impl will not recognize the new required flags
         because it doesn't think we know the font. Would have better
         to think of this before.
  ChrisL: That is why the thread started in 2016.
  myles: We've got the same problem.

  myles: There is a proposal. Is there feedback on it?
  fantasai: Which proposal?
  ChrisL: It's in IRC.
  ChrisL: So for that example: `format("opentype", requires
          variations, requires color)` you have to support both.

  fantasai: ameliaBR suggested using the names of the tables of the
  myles: One feature can have many tables so you need one
         representative table
  fantasai: We do that for @supports already: you have to pick a
            representative value when checking support for a property.
  ChrisL: For variable fonts there's one table for every table that
          exists so you have to list a ton
  fantasai: You use one as a proxy for the rest.  You use @supports
            (display:grid) and assume the rest of L1 is supported.
  jpamental: Font tables aren't something that users commonly know.
  jpamental: I think the concern would be that people who know about
             font format technology might know the tables exist but
             most font users don't. If we're going to pick a table we
             might as well pick a keyword as the thing which is more
             understandable to users of fonts.
  ChrisL: Think so, yes.
  myles: There are 4 popular color font formats and they're all
         competing. Some browsers support some. Edge does all. It
         kinda matters.
  myles: That's a situation where the table matters. Variations is
         different. I think keywords is a good pick so you can say I
         support variations.
  eae: You don't want to download the font 4 times that has the same
  ChrisL: It's all openType.
  fantasai: There's a few situations where you need more then does it

  Vlad: Can you describe an example where this functionality is needed?
  myles: I don't want to download font files....
  Vlad: You're a user and you want color glyphs or nothing at all. Is
        that the case?
  astearns: Author intent is I want to display color glyphs in this
            font if I'm in a browser that supports it. If I'm in a
            browser that doesn't support it I want to download only
            the smaller font so I get it faster.
  ChrisL: These are subsetted fonts. You've got one that does svg, one
          that does spix.
  myles: It's up the the author but yes.
  Rick: Same thing happens with variable fonts. I could have a bold
        weight and a light weight and I want to sort them out.
  astearns: I prefer the keywords. Since there are 4 color font
            flavors do we need four keywords
  many: yes.
  myles: And there will be variations and features
  TabAtkins: If a color wins we'll add 'color' as an alias to it.

  fantasai: You might want references to open type tables for the
            future. Let's say there's an open type table where support
            is necessary to use this crazy script.
  fantasai: We can have keywords for the most common things, but might
            also want to support the more specific cases.
  <TabAtkins> `requires variations, requires table "YOLO"
  <TabAtkins> `requires variations, requires table "YOLO"
  <astearns> `supports`: keyword | "XXXX"
  <TabAtkins> `requires variations, requires table "YOLO"`
  astearns: You mean ^?
  astearns: Arbitrary 4 letter strings which you can put for supports
            and you check if browser does anything?
  myles: We can have a feature keyed off a specific table but we
         shouldn't have that many variations. We can have both.
  ChrisL: Should use it for open type features?
  fantasai: Interesting point.

  astearns: Since this issue has been open for years can we do
            keywords for now and extend later as we find use cases?
            Particularly if there's a language thing with shaping
            tables where if a table to load a font in some browsers is
            the useful thing.
  fantasai: One of the reasons you don't want to defer is if you add
            it later the browsers will throw out the entire
            declaration. So you either define a subset and say we may
            extend in the future.
  ChrisL: It's important to not throw out the whole declaration.
  fremy: Can't we use string and say we split by slash?
  myles: A micro syntax? It's not good for OMs.
  ChrisL: You said it was backwards compat if you use slash?
  myles: Browsers would look at the format string and parse.
  fantasai: Micro syntax is more complicated if we extend.
  fremy: If we do this it still works in previous browsers. They'll
         still parse it. If we require something we'll remove all the
         fonts in src because if you do something inside the string we
         don't know.
  TabAtkins: Download source twice. Source for simplest and second for

  fantasai: Shouldn't we use "supports" insead of "requires" to be
            consistent with @supports?
  myles: browser-support font-files

  fremy: Can't you check if the browser supports font variants?
  myles: It doesn't work for color fonts because the css support for
         palettes is across types of formats

  TabAtkins: Should we be careful with how we define to add more
             features. If we say it supports custom ident.
  myles: Syntax isn't a | b | c it's just custom ident?
  TabAtkins: We'll say these are defined custom idents and if you see
             one you don't know you don't support it.
  fantasai: I think more general and the values are comma separater
            but if you don't understand any part of it it throws that
            part out. It's a change to parsing that opens the whole
            realm of possibilities in the future.
  TabAtkins: Yeah. Only possible backwards compat is if people add
             nonsense in their source and expect it not to download
             this will just throw away the nonsense.
  astearns: Does that exist?
  TabAtkins: No.
  fantasai: I'd say we resolve on that.

  fantasai: Prop: Parsing values of the src descriptor, the entire
            declaration is not thrown out if any comma separated
            section is invalid
  myles: Parsing is chop it into commas, run parse on each piece, and
         if that piece doesn't parse throw it out.
  fantasai: Still have to match brackets and stuff.
  fantasai: Parse like MQ not like selectors.
  TabAtkins: The grammar would have to be like custom properties,
             that's less good.

  astearns: Objections to not throwing out a source descriptor if a
            comma separated piece does not parse
  fremy: Inside a function we can extend, right?
  fantasai: This is broader.
  TabAtkins: So I'll need to put together some prose to handle that in
             the grammar.

  RESOLVED: Parse the value of src throwing out invalid parts like
            media queries and not like selectors. aka You split on the
            commas and throw out the pieces you don't understand not
            the whole thing.

  <fantasai> Like Media Queries, not like Selectors
  <TabAtkins> (unfortunately) not like Selectors
  <astearns> (fortunately) not like (unfortunate) Selectors

  fantasai: Now people can impl that while we figure out the rest.
  myles: Now we have that we don't need the string thing. We can just
         use keywords.
  fantasai: That's a different problem. If you just have keywords that
            are predefined, then you can only query predefined things.
  myles: got it
  <myles> format("opentype", [requires custom-ident]#)
  myles: Proposal #2 is ^
  <myles> format(DOMString, [requires custom-ident]#)
  <fantasai> format(<string>, [requires <custom-ident>#)
  <ChrisL> almost
  myles: You missed the square bracket
  <fantasai> format(<string>, [requires <custom-ident>]#)

  astearns: Extending source descriptor to a comma separated list
            requires custom ident
  TabAtkins: not requires
  ChrisL: When I type that out I'll have commas?
  myles: Yes.
  TabAtkins: No requires is no commas.

  TabAtkins: With the resolution we don't need the custom-ident
  ChrisL: So I can put inherit and stuff in there?
  myles: It's all inside the one format string...I guess that's okay.
  TabAtkins: With the resolution if we mint a brand new requires
             keyword tomorrow and someone uses it for browsers that
             don't know it that chunk of the source will be thrown out.
  astearns: If you put in "requires color-something"...oh!
  myles: It goes on to the next source.
  astearns: You break up things between commas which reduces to the
            things you know.
  <ChrisL> so there is an implicit AND, on the requires
  TabAtkins: Source splits on commas and only checks individual pieces
  astearns: Got it.
  myles: I think we're okay.

  fantasai: Do you need requires word?
  astearns: I like an indication of what this is about. I liked
            supports better.
  TabAtkins: Open type is written as a string. We can't restrict it
             because it's an external source. That's why tables as a
             string. If we define it, it's an ident.
  myles: Authors won't understand.
  myles: I think I'm with astearns that having a keyword would be
  fantasai: Put with many things you have to write it many times.
  astearns: Ties in the supports.
  fantasai: Prefer if you don't have to repeat it.
  myles: Can you write the grammar so that we don't have to repeat?
  <fantasai> format(<string> supports <custom-ident>#)
  fantasai: There ^
  myles: Looks like supports is required, though.
  <fantasai> format(<string> [supports <custom-ident>#]?)
  fantasai: there ^
  myles: And a comma.
  fantasai: Getting rid of the comma.
  TabAtkins: If we're removing supports no commas.
  myles: Okay.

  [everyone argues about commas]
  <astearns> (which is a recurring theme)
  ChrisL: The longest github thread ever was about using commas in the
          color function.
  [This is only because we recently switched to github, though;
   much longer threads exist on www-style.]

  <myles> astearns: proposal: format(<string> [supports
  astearns: We have a proposed syntax. Anything more to change/fix or
            shall we resolve?
  <TabAtkins> (It's not gonna be <custom-ident> now.)
  TabAtkins: Custom-ident can be a normal grammar thing.
  ChrisL: So we give an explicit list and if we extend in the future
          that's fine.
  fantasai: Yes.

  astearns: Objections to format(<string> [supports (list from

  RESOLVED: Use this: format(<string> [supports (list from spec)#]?)

  <fantasai> format(<string> [supports <feature-name>#]?)
  <fantasai> where <feature-name> is a keyword

  <Joel> Btw we think a @supports for color fonts will be needed,
         especially at the beginning. ie: If you want to use a color
         font only if it's supported and style it differently.
  <astearns> Joel: that's what we just resolved on
  <Joel> Great!
  astearns: Someone on irc mentioned @support for color fonts will be
            needed. Do we have an @support?
  myles: No. I think that should be an issue and we should discuss it.
  <astearns> Joel: sorry, I was wrong. we'll still need to figure it
  <Joel> Ok :)
  <astearns> we'll file an issue
  fantasai: For @supports you can re-use the same function as is here.
  myles: We should do use case research

  <Joel> myles: About opening the issue for @supports, should I create
         it on https://github.com/w3c/csswg-drafts? (I'm not familiar
         with this repo and guidelines though)
  <astearns> Joel yes, and please put [css-fonts] in the title

font property descriptors for variable fonts
  github: https://github.com/w3c/csswg-drafts/issues/2485

  dbaron: The way @font-face works is what you're doing is you're
          adding a font face to library of fonts browser can consider.
          Has descriptors, one is src, and the rest describe the
          thing at the end of the src. Many cases they have default
          values. Better to spec a font-family. If you don't do either
          it's 400, style defaults to normal etc.
  dbaron: Useful because means the UA can decide if to download based
          on these things. Then we introduced variable fonts which
          have maybe more then one font-weight. The interesting part
          is that they can have variation axes that correspond to
          these descriptors.
  dbaron: Spec says you're defining variable font with @font-face rule
          and you don't spec a weight your font is only used for 400
          according to the spec.

  florian: Other fonts for other weights?
  dbaron: I don't want to get into that part.
  dbaron: You can write 4 @font-face rule and now your variation font
          is limited to 4 weights.
  myles: Context: key problematic pieces is descriptors are defined to
         take on initial value. You covered that. Other pieces is that
         whatever is inside those descriptors clamps the effective
         range and in the initial value says you clamp to a range of
         size 0 which is not what you want.
  <ChrisL> @font-face {
               font-family: MyVariableFont;
               src: url(fonts/MyVar.ttf);
               font-weight: 65 490;
  myles: When I impl this in webkit I discovered this is a problem
         because if it was selected and doesn't have a descriptor
         you're forced to default value. I impl that if there's no
         descriptor the clamping would not occur.
  myles: Spec doesn't say to do that and we're the only browser that
  dbaron: FF doesn't ship, would like to soon, and recognizes this
          isn't good. But from Jonathan's understanding of webkit is
          that it makes it hard to figure out what to download. His
          impression is it interferes with the decision on what to

  ChrisL: In Fonts 4 this is changed and you can give a range. But we
          don't want to force 1-999 because there's a weight axis.
          That's why I proposed an auto value which gives you range
          for variable and single for traditional.
  myles: If the goal is I have multiple fonts and want to download the
         right one, they're distinguished between by descriptors. If
         they both have the descriptors then they'll know it as the
         right font. So I think the problem you described isn't.
  dbaron: Are there cases where font-fallback says this weight isn't
          close enough I'll fallback?
  TabAtkins: No. You might synthesize off of it but you'll stay. If
             you have the bold variation use that first regardless of
             the weight it was declared for.
  myles: Distinction webkit drawn between not present and taking
         initial is only relevant for when there's 1 rule that shares
         a family. If there's 2 rules the descriptors will be there.

  TabAtkins: You put 2 font faces to construct a family. One is weight
             400, the other 700. You tell it to use 500 and it'll
             select 400 font. Will variations happen at that point?
  myles: In your case bad things would happen, we'd select one of them
         and then we'd clamp to a 500:500 range.
  myles: But if author writes a font-face rule they wouldn't write
  dbaron: You can use fontface rules to provide part of what a font
          provides. E.g. you can restrict to only use a certain
          unicode range.
  myles: That's reason for clamping
  ChrisL: You can say I only want to use a restricted range of what it
          can do. But if you don't put one in, it can do what it can

  florian: Question. When you're doing this clamping etc. can you also
           have within the variability I was to use 200-400 but map to
  myles: Different discussion. There's a different open issue.

  TabAtkins: On the situation I described, a variant font with not
             @font-face declaration and another with a weight. You say
             select the 450 does selection occur there?
  myles: Yes.

  dbaron: Other meta point is this is a feature we've done a good job
          on coordinating on shipping at the same time, which is good.
          But that makes this high priority.
  florian: Variable fonts don't have a descriptor and you have another
           on 700 and you say 450. Instead you say 699 and you still
           get the first one.
  TabAtkins: We should switch to auto where it means the same as the
             initial values but it does not cause any clamping.
  florian: When you ask for 699 it's not a range. The variable would
           not be matched because it's default to 400. If you drop the
           400 you do the same thing. But if you're close to 400 that
           you would get the font you get it and draw it at the
           requested weight.
  fantasai: If you wanted 699 off this font?
  florian: You draw the range.
  myles: The descriptor that covers everything is a better match.

  dbaron: What TabAtkins said made sense. Does myles agree?
  myles: I think that's acceptable.
  dbaron: Is it what safari does?
  myles: Almost. Close. With TabAtkins proposal an @font-face block
         could say font-weight: auto. In my impl that's a parse error.
  fantasai: I still think it's a little weird that you say font range
            is auto which means everything and it's able to do weight
            699 and we use the 700 font.
  TabAtkins: We don't know it can do 699 so we don't download it and
             and won't know it can do 699 until we download.
  myles: Most fonts on the web don't have variations.
  ChrisL: If you say auto you should know that it's variable since
          nothing is tagged as auto.
  myles: Maybe they should write 0-999.
  ChrisL: I'd rather an opt in keyword and not have to write the whole
  dbaron: It's better to write 0-999 because you know it's a
          variation. I think auto where it means 400 but don't clamp
          is a good way to transition to the world with variable fonts.
  myles: Should authors be able to write font-weight:auto
  dbaron: It'll be possible but we shouldn't suggest it.
  fantasai: I agree with ChrisL it's not nice to make authors write
            0-999. Give an all keyword.
  myles: Most variable fonts don't support 0-999.
  fantasai: But if authors don't want to think about it and just write
            0-999 it's awkward.
  ChrisL: It's like for unicode where they don't write the range.

  Rick: As a font user it's hard to determine range.
  jpamental: The fonts as they're developing have quite different
             ranges. We're only dealing with weight because it's the
             only variable range that maps to CSS. Maybe with
             font-weight we want people to put in the effort to put in
             the low and high because it also supports wanting to
             subset the range.
  fantasai: But the browser gets a request for 100 and the range is
            200-800 I'm still going to get the font. Unless there's
            another font that supports 100 I'm still going to get that
            font and I'll use the lowest number. In terms of which
            file will I download it doesn't matter. Only time it
            matters is if there's another font that covers the range.

  myles: Let's say there's an auto and you can say font-weight:auto
         and it has the same value if the descriptor is missing
         without the clamp
  TabAtkins: For matching it acts like the values we spec.
  majidvp: And no clamping.

  myles: prop: Add an auto keyword to the appropriate font descriptors
         that has the effect of the following: 1) for font selection
         purposes the font is selected as if the appropriate initial
         value is chosen. 2) for variation axis clamping, clamping
         does not occur
  astearns: Obj?

  RESOLVED: Add an auto keyword to the appropriate font descriptors
            that has the effect of the following: 1) for font
            selection purposes the font is selected as if the
            appropriate initial value is chosen. 2) for variation axis
            clamping, clamping does not occur.

  <ChrisL> apropriate means weight, style, stretch

'oblique 0deg' vs 'normal' for font-style
  github: https://github.com/w3c/csswg-drafts/issues/2505

  dbaron: The spec for font styles says normal represents an oblique
          value of 0.
  dbaron: Jonathan writes it's not clear to him what this means [reads
          from issue "Does normal count as oblique 0deg for this
          purpose, such that font-style could be animated as an
          <angle> from normal to oblique 15deg or not?"]. His test
          shows chrome and edge disagrees.
  jpamental: There's two variations.
  ChrisL: It's the slant one. His point is valid is if it's the same
          as 0 you have the endpoints of the animation. I think
          oblique:0 should match.
  myles: ChrisL is right. We impl that it's just a number because we
         treat italic and oblique the same. So normal = oblique 0deg.

  fantasai: Computed value?
  myles: Probably the keyword? Don't know.
  fantasai: Matters for animations.
  myles: Sure then we make computed values always the oblique.
         Question is what is the computed value of the font style
         property. If computed value is normal for ital you can't
  TabAtkins: You can animate from oblique 0.
  myles: Computed value of normal should be oblique 0. Computed value
         of oblique with nothing...
  fantasai: I don't think it's backwards compat.
  fantasai: Computed value should stay the same.
  TabAtkins: We can also make the animation value handle that.
  myles: Is there precedent for that?
  TabAtkins: Sure we can make it work. We have special behavior for
             transforms from none.
  myles: This is the same.
  myles: So we'll punt.

  TabAtkins: Change animation so that normal can animate with oblique
             as if normal is 0.
  fremy: And if you put 0 in your style sheet computed value is 0.
  TabAtkins: Some UA map italic to oblique and if they do so they
             should be able to animate between italic and oblique.
  fantasai: Suppose a variable font with both italic and oblique axis
            and I specify font-style: italic
  myles: We keep a float for the oblique angle and we keep a bit to
         know if that came from oblique or italic axis.
  fantasai: Isn't it 2d space?
  myles: It's just not a variable thing.
  fantasai: Can variable fonts have variable italic?
  ChrisL: No.
  jpamental: Intent was italic to be on or off.
  florian: If you want a font to have steps between you have a custom
  ChrisL: Yes.
  fantasai: So you have parallel tracks.
  ChrisL: You can have a custom axis and then it doesn't intersect
          with CSS properties.
  myles: Mechanically it's possible to have fonts that do that but
         many experts have not seen a variable angle of italic.
  jpamental: Italic is either italic or not, it's not a degree of
  fantasai: All writing systems?
  ChrisL: Most don't have ital.

  <TabAtkins> Proposed Resolution: leave font-style computed values
              as-is; change font-style animation behavior so that
              'normal' can animate with 'oblique <num>'; if the UA
              treats 'italic' as an oblique value, also allow it to
              animate with 'oblique <num>'.

  dbaron: Trying to understand in font matching algorithm of 5.2
          bullet 4 sub bullet 2.
  <dbaron> If the value of font-style is oblique and the requested
           angle is greater than or equal to 0deg and less than 20deg,
  dbaron: It's about font style. The 3rd unnumbered sub clause.
          Sentence starts with ^
  dbaron: This includes an oblique font 0deg. This is separate from
          normal clause and it's not clear to me if sub point 2
          includes normal fonts.
  dbaron: It says if it's oblique and the angle is >=0 and <20 if you
          have an exact match use that but if you have smaller look
          down to 0. It doesn't say if it include 0 and, if it does,
          if it's normal 0.
  myles: Do we need a resolution to make it more clear?
  dbaron: I think it's fine if you just clear the spec up.

  astearns: We've got the proposed resolution that TabAtkins put:
            leave font-style computed values as-is; change font-style
            animation behavior so that 'normal' can animate with
            'oblique <num>'; if the UA treats 'italic' as an oblique
            value, also allow it to animate with 'oblique <num>'.
  astearns: Objections or issues with it?
  ChrisL: sgtm
  myles: cool.

  fantasai: We have UA defined behavior in the resolution and I don't
            like it.
  astearns: It's reiterating behavior we have
  fantasai: Changes to be detectable if you can animate it.
  fantasai: I'm not sure what's going on with the ones that can
            animate and not.
  myles: I think it's if you are a browser that treats oblique and
         italic as the same you should be able to animate between. If
         not you can't.
  florian: I'm not sure about that. The author chooses italic, why
  TabAtkins: Some browsers don't distinguish.
  fantasai: But then they can't tell which they should download. Seems
            like a problem. If I said italic I should get italic first.
  many: not how it works.
  fantasai: As an author I'll never get italic?
  florian: In some browsers, yes.
  myles: There's one signal.
  myles: You'll get something consistent if they're both there.
  fantasai: I load a font with an ital variant and an oblique variant
            and I can only get one. Why is this good?
  myles: It's how it's always been.
  fremy: This was in css 2.
  astearns: We can choose not to extend.
  ChrisL: Do browsers do this? Treat them as identical?
  myles: The bit doesn't effect font selection, it's only to have the
         right axis.
  <fantasai> https://www.w3.org/TR/CSS2/fonts.html#font-styling
  <fantasai> “A value of 'italic' selects a font that is labeled
             'italic', or, ****if that is not available****, one
             labeled 'oblique'.”

  astearns: I suggest we take the proposal and strike the UA part
  Prop: leave font-style computed values as-is; change font-style
        animation behavior so that 'normal' can animate with 'oblique
  astearns: Objections?

  RESOLVED: Leave font-style computed values as-is; change font-style
            animation behavior so that 'normal' can animate with
            'oblique <num>'

default angle for font-style: oblique
  github: https://github.com/w3c/csswg-drafts/issues/2295

  myles: When css content says font-style:oblique in a non variation
         world a font is oblique or not. In a variations world that
         need to be mapped to an angle. Variation axis can go between
         0 and 90 degrees. When you say font-style:oblique and you
         don't have an angle where should it go.
  myles: When I wrote the spec I printed paper with representative
         fonts and I measure the angle and it looked like 20 deg.
  ChrisL: Based on Jonathan's data the mid-point is 14deg and that's
          what OSX uses I think that's reasonable.
  florian: Issue had more details about it being platform dependent.
  myles: Spec says it's not and impl made it dependent.
  florian: FF made it dependent because it is outside the browser.

  myles: So options are 1) 20deg, 2)14deg 3) make impl pick something.
  ChrisL: The algorithm has a whole set of if it's below this pick this
  fantasai: I think that algorithm should change to lower than 14. It
            should be a lower end to what's considered typical.
  florian: That would go against leaving it up to UA because we can't
           do one that's always lower.
  ChrisL: Yes.
  myles: There's 2 pieces. This issue is what should we pick with no
         angle and it should be 14.
  astearns: Objections to using 14 as the oblique angle?
  dbaron: 14 or 14.036? I mention it because Gecko was storing the tan
          of the angle so we stored 0.25 and the arctan is 14.036
  <dbaron> 14.036deg is atan(0.25)
  astearns: Objections to 14 degrees?

  RESOLVED: Use 14 degrees as the angle for undefined oblique.

  myles: fantasai should open an issue as to where to put the
  fantasai: I suggest 10 for now and then we investigate.
  myles: We should figure out the answer
  myles: Can we pick 14?
  fantasai: We want it less.
  astearns: I suggest as a part of the resolution edits you say
            there's an issue and then we can edit in the appropriate

font-variant @font-face descriptor
  github: https://github.com/w3c/csswg-drafts/issues/2531

  myles: Is the commenter in the room?
  ChrisL: It's Mike Gramford (sp?) and I don't know whose
          implementation it refers to. They did contribute some tests
          so there's a test and that's where it was discovered the
          font-variant descriptor was under impl.
  myles: It's mostly in the issue. Similar to the @font-face
         descriptors there's one that lets you turn on/off features.
         Nothing to do with font selection. I thought webkit was only
         impl, but there's some other behind a flag.
  <ChrisL> test case for font-variant descriptor
  myles: Webkit is only shipping and our impl has architectural
         problems and there's bifurcation of text code paths and we
         make that before we inspect @font-face. we need to know if
         there are features to turn on before we decide. If you're on
         the wrong path it might or might not work.
  myles: I'd like to remove it.

  astearns: Does anyone claim Mike?
  TabAtkins: I think it's a pdf renderer
  astearns: We could defer.

  ChrisL: I posted this on www-style.  This is one of the non-passing
          tests. Do we defer? Do we delete? It's holding us from rec
  astearns: This ability seems useful.
  ChrisL: I thought so too but myles talked about how it can conflict
          with cascade and if you put this in @font-face you have
          fixed positions.
  fantasai: Property overrides descriptor so no cascade problem.
  myles: Philosophically features should be applied to everything in
         the cascade.
  fantasai: There are fonts out there that are always small caps
  myles: But turning it on on small case will be fine.
  fantasai: But there are other features where e.g. if I have this font
            I want historical ligatures but not on this one because
            it's ugly in that font. It's an even bigger issue for
            stylistic alternates.

  astearns: We have a spec we want to push and a feature we don't have
            2 impl. I think we should defer and not remove until we
  astearns: Objections to defer font variant descriptor to L4?

  RESOLVED: Defer font-variant descriptor to L4.

CSS Text Decoration

Bikeshed font underline value names
  github: https://github.com/w3c/csswg-drafts/issues/2376

  myles: There's 2 properties to describe the geometry of text
         decoration. Move up and move down. Increase size. Fonts also
         include information about where font designer thinks
         decorations should be. We resolved to add keywords to say use
         what's in the font file. We have not found names.
  myles: One is from-font and one is use-font
  fantasai: Also match-font.
  TabAtkins: We have a from-image keyword.
  fantasai: Anyone impl?
  TabAtkins: Dunno.
  fantasai: I like your point that they should be consistent.
  astearns: Objections to from-font?

  RESOLVED: Use from-font


Rules for Simple Placement of Ruby
  link: https://lists.w3.org/Archives/Public/www-style/2018Apr/0006.html
  document: https://florian.rivoal.net/ruby/

  florian: I don't want to spend too much time to introduce that it
  florian: Kobayashi-sensei from JLReq fame wrote a new recommendation
           about ruby that I translated to English. JLReq describes
           what they are but doesn't try to address when you might
           want to choose something. This doc takes a recommendation.
  florian: If you want to handle ruby well do these things. It doesn't
           handle all possible variants, but here's a set of rules you
           can follow.
  florian: I will not read this live, but there's a bunch of figures
           and it handles mono, group, overhand, longer ruby base,
           line breaking. I think people editing and reviewing ruby or
           are impl ruby spec should review this with ruby spec in
           parallel to find places where maybe we got it wrong or
           where we said let's leave this to UA defined because most
           impl don't know what they should do.
  florian: If we can recommend a good base default from this. Maybe we
           have in ruby spec all desirable variants but we might lack
           some smartness about picking the right one. I know we have
           some logic for handling ruby with Latin and ruby with
           Japanese. This document exists on my personal repo.
           Probably submitted by i18n.

  astearns: Can you send it to www-style archive?
  florian: It's a link that won't expire.
  astearns: Thanks for doing this translation.
  astearns: It might be good to have a time where ruby editors can go
            through spec and look line by line against this.
  fantasai: Sound great, but I have other things to wrap up first.

  florian: Addendum is similar documents will come from
           Kobayashi-sensei and the WG in Japan where JLReq lists and
           these documents recommend.

CSS Text L4

text-spacing: space-first
  github: https://github.com/w3c/csswg-drafts/issues/2462

  florian: Kindle does this (shows image from github). Interesting
           thing to note is the opening corner bracket. These glyphs
           have whitespace in them and it's been trimmed. We have a
           property that allows this to be one or odd. But Kindle
           decided to just trim.
  florian: Some amount of trimming is typically wanted by Japanese
           typographers and publishers which is likely why the
           default. But what it doesn't isn't want Japanese people
  florian: Kinoppy does much closer. Inline in the middle of a
           paragraph trim, but at the beginning set full-width.
  florian: This is what people in Japan mostly want.

  Rossen: What's the significance?
  fantasai: Indentation.
  florian: Way we spec things if you want this effect you need to a
           1em text intent and you want to hang opening punctuation.
           That would give you this but that's not how they do it.
  florian: The brackets are a quotation mark.
  myles: Not just a full width character?
  florian: They're not using text indent, they're putting a space
           character at the beginning of the line. Brackets at the end
           are not trim but the one in the middle is trim. How they do
           it is dirty but the effect is what they want.

  florian: Murakami-san suggests we add a value to text-space, I think
           called space-first. We have trim-start and space-start and
           he suggests a value that's space on the first line trim on
           the rest.
  florian: It would allow being compat on this type of content. It's
           regrettable they do it this way but it might as well be
           compat. Even if you don't consider hacky-layouts this is
           probably a good default for Japanese in general.
  florian: Because trimming at the start of lines except the first is
           really a good thing.
  astearns: Otherwise you assume it's a paragraph.
  florian: Trimming at the start of lines is good, but at the first
           line content...some paragraphs are visible because the
           first line has an indent.
  astearns: Why not solve this by having you use trim-start and
            text-indent and hanging punctuation correct for
            Japanese...ah, because then the mid paragraph would hang.
  fantasai: It wouldn't.
  astearns: Why not use text-indent and trim-start?
  fantasai: We can't by default.
  florian: Right, he's suggesting this exist and be on by default.

  florian: This ideal cannot be on by default because it's not
           backwards compat. That's kind of redundant, but it can be
           on by default which is nice.
  astearns: And he goes through why my suggestion is wrong in the
            issue. He says you can't apply this to current Japanese
            ebooks because the epub guidelines.
  florian: It's a combination of defaults and legacy and having this
           value would work okay for all of these.
  fantasai: Reasonable to me. Big issue is we have a standard for how
            ebooks are written which is incompat with... This would
            make them look good and not doing this would not.
  florian: epubs would look better and the web as it is would start
           looking better as well. We can do this by default.
  astearns: And the current default is bad.
  florian: Right.

  koji: No strong opinion. This is about...the paragraph starts with
        one ideographic space?
  florian: If you look at the example with an ideographic space
           instead of an indent or an opening punct. If there's one
           that happens to wrap in the middle of the line that should
           be trimmed. That's what epub authors assume. If we don't do
           it epub looks bad. It will help the web too. Only slightly
           for the web at the first punct but given that trim-start
           isn't done currently it's bad.
  koji: space-first has nothing to do with space?
  florian: Name is strange it means trim on non-first-lines. Why it's
           called space-first we have trim-start and space-start and
           space-start means don't trim. This is "space first trim the
           rest". That's a bit long so it's called space-first

  fantasai: I'm not convinced this is the right thing for the Web in
            general. For flush paragraphs why would you have a space
            only if it begins with a bracket. But epub needs this so
            we should add.
  florian: In general you want trimming on the web. Not trimming the
           first isn't desirable, it's just safer.
  fantasai: If you're not using indentation of any form...?
  florian: Maybe you're not.
  florian: You only do this on your block quotes. The argument is that
           it isn't always desired it's the removing the space is
           always bad.
  fantasai: I think we should add the value. I think the correct
            default is trim everything but is there content that would
  astearns: Murakami-san says it would. Many will improve visually but
            some will break.
  koji: Apart from the default I understand the desire. But that makes
        me think maybe we can use first-line and we're done.
  florian: It's only interesting if it's the default. If it's not
           default we have other opt-in ways.
  fantasai: It needs to be the default in epubs. If it's the initial
            or it's in their default stylesheet I'm not sure of the
            answer. It seems clear it's needed
  astearns: Prop: Add this value, suggest it's the default in epubs
            and add a open issue wondering if should be in the web in

  RESOLVED: Add this value, suggest it's the default in epubs and add
            a open issue wondering if should be in the web in general.

  fantasai: Does guide tell people to lang tag?
  florian: We can check. So you apply based on lang tag.

Allow for paragraph-level line breaking
  github: https://github.com/w3c/csswg-drafts/issues/672#issuecomment-379723234

  fantasai: astearns added a new feature and there was limited
            discussion. I feel we should have more check in with the
  astearns: Issue is pretty long.
  <astearns> https://drafts.csswg.org/css-text-4/#text-wrap
  fantasai: Discussion was from myles asking to opt into more
            expensive line breaking algo with better results.
            Discussion landing on adding a switch. text-wrap property
            in L4 is a longhand of white space that only controls
            wrapping. Has values to say wrap, don't wrap, try to
            balance lines for same length. Proposal was add a value
            called multi-line that does one of these more expensive
  fantasai: We've talked about fancy wrapping algorithms before.
  eae: It's not that we don't want to impl, it's not a priority.
  astearns: I added it to the spec as a this would be nice to have.

  fantasai: Alternative is you do it anyways and you don't need an opt
  eae: Opt in is nice since it's quite a bit more costly.
  myles: You can't have this on by default.
  myles: This will be way slower.
  fantasai: If concern is about performance we might want a note to
            say if someone impl and discovers no performance issues.
  florian: If you want to do it and have made it fast you can apply to

  astearns: When I added the value the default says you may consider
            multi lines and the UA may optimize for speed. And for
            multiline algo should consider multiple lines and should
            bias for layout over speed.
  Rick: UA could decide this is giant and we won't do it anyway?
  myles: Yes. There's 100 criteria for a beautiful paragraph and it's
         impossible to do all. Browsers should be free to pick and
  fantasai: Sounds like what you want is text-wrap:expensive
  fantasai: If that's what it's conveying let's convey that. There are
            lots of other things to consider.
  myles: But balance is also expensive. Different algo for different
  fantasai: Wrap and multiline are trying for the same effect.
  florian: You're not asking for slow. You're asking for pretty even
           if it's slow.
  <dbaron> high-quality-wrap?
  myles: It isn't one spectrum, there are different algo with
         different purpose.

  jpamental: As a designer there's many things to optimize on. I'd
             like the pretty to have everything laid out, but I also
             recognize that's hard. Maybe target which things you want
             to prioritize but that's a different solution. Assigning
             priority to the thing you want to address.
  myles: We could make it more complicated but there's 0 impl so
         simple would be good.
  astearns: Concerns with leaving this prospective value in?
  fantasai: If it's not clear what we're aiming at I don't know if it
            makes sense to have a keyword. If someone wants to impl a
            fancy line wrapping algo they can come back and ask for a
            switch and what they optimize for and then we can discuss
            what switch we want.
  astearns: I think it's a case that a shared characteristic is that
            it considers more then one line at a time. A multiline
            value that can encompass a range of strategies is
            appropriate. I feel that deciding on this is the pretty
            strategy for the web and getting everyone to agree on a
            algo won't happen. I wanted to leave it a little open so
            people can experiment with what they'd trade.
  fantasai: I think multiline isn't clear.
  myles: Let's call it pretty
  fantasai: Sure.

  florian: We started with paragraph and we shifted to multiline
           because it doesn't always consider the whole paragraph.
  myles: Maybe not pretty because titles don't want this.
  astearns: I'm happy to bikeshed on name. multiline is pretty well
            known by the breed of people that use indesign.

  florian: There was a thing for a switch...for editing purposes you
           don't want an unstable algo.
  astearns: Separate issue for that.
  fantasai: In that case you want stable and something else.
  astearns: And there's a note at the end of the section on that
  myles: If we were to impl we prob would make multiline same as wrap.

  florian: We're pretty much repeating this issue and the issue says
           we don't want a separate property from wrap but wrap-stable
           and wrap-pretty.
  fantasai: I like it as a modifier.
  dbaron: Agree wrap should be in the same.

  myles: Should balance also have wrap?
  Rick: multi-line line breaks would be just fine
  florian: If you say wrap UA must not consider multiple lines. If you
           call for stable and you don't want re-jiggle you shouldn't
           consider. If you turn of the editing you want stable.

  astearns: We're at time. I've got some of this discussed. Do you
            want a resolution fantasai?
  fantasai: I think we agree it's a modifier on wrap not a separate
  astearns: I believe there is a separate issue on editing and
  astearns: Resolution that we should change value to wrap-nice,
  astearns: Issue is open we can bikeshed there.
  fantasai: We can make it a modified on wrap.
  koji: If multiline is modifier balance should be one too.
  astearns: We're at time. I don't hear consensus and I would object
            to putting wrap as a modifier on all of the values.

  astearns: We're done for the day.
Received on Thursday, 17 May 2018 07:34:23 UTC

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