[CSSWG] Minutes Telecon 2020-09-16 [css-logical] [css-text] [css-fonts]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Upcoming Joint Meetings

  - In addition to the planned meetings with the Internationalization
      and ACR/Accessibility groups there is a desire to meet with the
      Open UI community group. Rossen, gregwhitworth, and astearns
      will coordinate on a time.

CSS Logical

  - RESOLVED: Have the logical value of resize be that of the element
              itself (Issue #3281: Mapping of logical values in

CSS Text

  - RESOLVED: Treat CR as an ordinary space (Issue #5410: Reconsider
              the resolution on #855)

CSS Fonts

  - RESOLVED: Add ascent, descent, and line-gap override as fontface
              descriptors that take percentages (Issue #4792:
              Interoperable font metrics)
  - New issues need to be opened for some of the other descriptors
      raised in issue #4792. One would be to further explore the
      proposal for advance-override and the other would be to evaluate
      handling the superscript and subscript values with a similar
  - Before issue #4430 (Proposal to extend CSS font-optical-sizing)
      can reach a resolution there needs to be more discussion and
      research into how the various pixel and point conversions are
      handled when moving between print and digital displays.


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0014.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Xiaocheng Hu
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Una Kravets
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  Myles Maxfield
  Anton Prowse
  Manuel Rego Casasnovas
  Florian Rivoal
  Devin Rousso
  Jen Simmons
  Miriam Suzanne
  Greg Whitworth

  Tantek Çelik
  Lea Verou

Scribe: dael

  Rossen: Let's get going
  Rossen: First, sorry I made a typo in the subject line. The call is
          indeed today.
  Rossen: I must have looked at the MathML call. That is happening
  Rossen: As a reminder part 2 is happening tomorrow starting at 9:15PT
  Rossen: Details are sent by astearns to the private list

  Rossen: Extra agenda items. One we'll take when we get going but I
          wanted to hear if there are any other items to discuss
          before we get going

  fantasai: Process 2020 is in effect now
  <florian> If anyone's not up to date, change section here:
  <gregwhitworth> woohoo - congrats fantasai and florian
  Rossen: Woo! Congratulations, I know this was a big effort
  <chris> bikeshed already supports it
  Rossen: Huge thank you to you and florian from this forum for
          supporting it
  <fantasai> Process 2020 for spec editors:

Upcoming Joint Meetings

  Rossen: If this was a normal time we'd be meeting together for TPAC
          F2F. That's virtual.
  Rossen: As part of this we reached out to some of the more frequent
          joint meeting WGs.
  Rossen: So far we have joint meeting with i18n group and APA/A11y
  Rossen: One more proposed by gregwhitworth is if interest to have
          Open UI. gregwhitworth can you brief us?

  gregwhitworth: It's a community group. Most things on the list we
                 could do in CSSWG. Goal is we keep talking about form
                 controls and styling and things that the group is
                 talking about in a holistic view.
  gregwhitworth: I provided items to see if there was interest. Wanted
                 to know if there was interest in getting together to
                 talk about form control styling, possible
                 improvements to built in controls with OpenUI and
  [email with possible topics:
https://lists.w3.org/Archives/Public/www-style/2020Sep/0005.html ]
  Rossen: Thoughts?
  <TabAtkins> +1
  <astearns> +1 to meet with OpenUI
  <miriam> +1
  <jensimmons> +1
  <dandclark> +1
  gregwhitworth: Seeing stuff on IRC
  Rossen: That's what I was expecting for interest
  Rossen: Let's call this one that we'll have a joint meeting. You
          astearns and I will work out details offline

CSS Logical

Mapping of logical values in 'resize'
  github: https://github.com/w3c/csswg-drafts/issues/3281

  oriol: The thing is that in CSS logical spec added logical values
         for existing properties. For each there's a question of if
         they should resolve using writing mode of element or its
         containing block
  oriol: Some past resolutions on this. text-align we resolved we
         should use writing mode of element. Float and clear which
         effect element we use writing mode of containing block.
  oriol: Question is on resize property.
  oriol: Implementations don't agree on this.
  oriol: Firefox doesn't obey previous resolutions. For float, clear,
         and resize they use writing mode of element.
  oriol: They shipped
  oriol: In Chromium I used containing block for these three
         properties but it's behind a flag
  oriol: In issue fantasai provided some points to consider. Resizing
         can effect size of box but also available space for contents.
         You can see it both ways and it's not clear which we pick
  oriol: No strong opinion, just want to decide on something

  Rossen: Don't know if folks have read through 3 points from
          fantasai. Wanted to hear if there are strong opinions
  florian: Weak opinion to favor element
  TabAtkins: Same
  smfr: Any version where those are physical?
  florian: Yeah, you can. Question is when you say inline.
  Rossen: Also more inclined to element

  Rossen: Anyone who prefers to have inline refer to containing block?
  Rossen: Some of fantasai's points are that layout and resize of
          element usually effect containing block and might make sense
          to have this as function of containing block. That's why
          other option is considered
  <fantasai> I think I have a mild preference to containing block.
  <fantasai> Use cases are things like sidebars and textarea
  Rossen: Still hear if we resize based on element's inline for same
          purpose I think that although this is layout effecting it
          makes sense to be element itself

  smfr: Are there logical versions of overflow-x and -y? I can't find
  florian: I think so.
  <fantasai> https://www.w3.org/TR/css-overflow-3/#logical
  smfr: Was thinking resize should match overflow.
  oriol: Overflow uses element writing mode
  smfr: That's an argument for resize to do same

  emilio: Did we decide...for float and clear computed value needs to
          be logical. What Firefox impl is these logical properties
          where logical value is computed to physical at computed time
          which doesn't work for containing block. Where we use
          writing mode of containing block computed value needs to be
          logical value
  fantasai: Yeah. Value is always itself and never computes physical
  emilio: Makes sense. Could effect inheritance, but most of these
          don't inherit
  Rossen: Objections to have the logical value of resize that of the
          element itself?

  RESOLVED: Have the logical value of resize that of the element itself

  <oriol> emilio: Logical values computing as-is was resolved in
  <emilio> oriol: great, just wanted to make sure that there was a
           resolution on that, thanks!
  <emilio> oriol: a bit odd that it behaves differently from logical
           props but maybe not too much :)
  <fantasai> emilio, it would have been necessary for text-align to
             actually work as expected :)
  <emilio> fantasai: fair enough :)

CSS Text

Reconsider the resolution on #855
  github: https://github.com/w3c/csswg-drafts/issues/5410

  florian: We resolved control characters are displayed visually. As
           part of that the CR character, carriage return, is supposed
           to be the same. Most of the time you can't notice because
           handled by HTML parser. But if you inject it you should see
           it. No one does it.
  florian: Mostly can't see, Chrome sometimes replaces with ordinary
           space. Did testing to see what kind of invisible people do.
           It's all over the place. Everyone does a weird variant
  florian: Suggestion is treat as ordinary space. Depending on
           whitespace property it may be collapsible. Partially
           matches Chrome. When whitespace is normal Chrome does that.
           When whitespace is not normal Chrome does different things.
  florian: Suggestion is from fantasai and I think it's good. This is
           kind of an error case

  emilio: I filed it because wikipedia was complaining. Not sure about
          nobody uses it
  florian: Do they want it to do something?
  emilio: No, Gecko was doing something more weird. I fixed that more
          weird but when I looked how to handle it was all over the
          place as you said.
  florian: So I thank you for the opportunity to write fun tests. Now
           that I've had my fun how about we change to a space and
           move on
  emilio: Okay with that but a change for all engines
  florian: Yeah. In main case it's what Chrome does

  chrishtr: Is the proposal #2 on your option list always?
  florian: Yes. It behaves as any space on whitespace:pre
  chrishtr: So Chrome just needs whitespace:pre to change?
  florian: Yeah, maybe other non-normal. I don't recall.
  <fantasai> proposed resolution is "treat as U+0020"

  smfr: Makes me a little nervous because they're more common in mac.
  florian: Yeah. Probably not showing because actual carriage return
           is handled. It's an explicit escape
  smfr: Worried files converted to user entities.
  florian: Could. But what happens now is everybody is different

  Rossen: I see soft agreement by koji on the issue. Sounds like
          emilio is fine for Gecko to try.
  smfr: I won't object. I think we'd have to try it and see what
  Rossen: Let's try and resolve. If we see a lot more information
          saying this is causing crazy breaks we'll discuss again
  florian: I think behavior in Safari and Firefox isn't crazy but I
           could find so many ways to make something visual that this
           seemed a lot simpler

  florian: Proposal: Treat CR as an ordinary space
  florian: I'll be more exact in spec.
  Rossen: Objections?

  RESOLVED: Treat CR as an ordinary space

CSS Fonts

Interoperable font metrics
  github: https://github.com/w3c/csswg-drafts/issues/4792

  myles: There's this problem. Problem is font files have a bunch of
         different metrics and many conflict.
  myles: Most egregious is there are 3 different ascending and
         descending metrics in open type font files. All different
         numbers. Some browsers use some, others use others.
  myles: Some use metrics not even in the file. It's the wild west
  myles: This is an interesting problem because all text is rendered
         with whatever metrics the browser happens to use. Any
         solution that's browser Y should switch is a pretty scary
         change. It changes all text on the web. So I think it's not a
         good solution.
  myles: Looked for better. A few design principles I wanted to abide
         by. All text should not be changes. Browsers should not have
         to parse font files themselves, they should be able to
         delegate to lower level libraries.
  myles: Last is that we don't want to have different metrics for some
         properties than others. If we do that you end up with
         inconsistent typography and poor design
  myles: Given those requirements I think best way to solve is for CSS
         authors in CSS to override metrics inside font file. The
         mechanism for doing this is a new descriptor or set of
         descriptors in font-face block. A CSS author can override the
         font file metrics and say please instead use 80%em for
  myles: Satisfies constraints and gives consistency if authors use
         this. And if browser doesn't understand it falls back to font
  myles: For problem at hand I think this is a fairly good design.
         Interested to hear thoughts.

  chris: Reading thread I'm puzzled. I see people from Chrome saying
         they don't want descriptors and existing ones should be
         removed. See others from Chrome proposing descriptors. I
         appreciate opinions can change but would like to know their
         current opinion.
  xiaochengh: From Chrome side we do want descriptors. Earlier comment
              opposing was mostly from implementation side. We've
              prototyped the descriptors behind a flag so
              implementation isn't an issue.
  chris: Does that only apply to these descriptors or also to previous
  chrishtr: Which did you have in mind?
  chris: Dominic pointed to other issues saying removed font-variant
         and would like to remove other overrides. Basically, are you
         now happy with these or still look at removing?
  xiaochengh: Others aren't covered, should look independently
  chrishtr: In favor of adding the ones xiaochengh mentioned as well
            as ascent one from myles

  myles: Talk directly about descriptor vs property. Descriptors are a
         direct natural fit to way metrics are handled by browsers.
         When you use a font face you have a font associated. Way to
         implement this is when you pull out metrics remove that and
         slot in from the rule.
  <fantasai> strong +1 to using descriptors, strong -1 to using
             properties for this
  <chris> I agree that descriptors seem like a good fit here, better
          than properties as Myles said. I just didn't want a solution
          that had been argued against in the past.
  <florian> agreed, descriptors are a much better fit indeed.
  myles: If we wanted to move to property not against it but tricky
         problems like how does font fallback work if you have nested
         element with different font family. Multiplier on font size?
         A bunch of questions. If we can answer that's fine but
         descriptor approach means we don't have to.
  chris: Agree they're a better fit

  myles: I can also talk about the 2 additional descriptors from
         xiaochengh. Line-gap-override makes a lot of sense.
         Advance-override I'm not against but unanswered questions
         about how interacts with letter-spacing. Letter-spacing is
         not a simple property.
  myles: Would be unfortunate if we had 2 ways of effecting
         letter-spacing and they worked differently. So there's still
         some design work for that one. line-gap-override makes sense
  TabAtkins: There is 2 separate mechanically things to do that are
             letter-spacing like. Advance-override solves making sure
             monospace isn't screwed up with fallback. You want to
             effect advance of a letter to make sure they have exact
             width of primary font.
  TabAtkins: Nothing to do with variable width fonts. That wants to be
             more like letter-spacing so you don't have awkward
             spaces. Have to be different and separate.
             advance-override which is make monospace work with
             fallback is straightforward
  myles: Yeah, proposal from 8 days ago says it adds additional space.
         I don't think it satisfies the use case
  TabAtkins: Would for monospace
  myles: Not for font fallback
  TabAtkins: Yes, if you know width of primary and fallback you add
             the space. Using 'override' is unfortunate name
  xiaochengh: Proposal is add a constant to advance of glyph. I agree
              we should rename the descriptor.
  xiaochengh: At this moment problem with variable width font is value
              of this descriptor has to be tried manually. Agree
              there's a design issue but we do want this descriptor
  myles: We can open up a few issues
  fantasai: I strongly want advance-override to be in a separate
            issue. Needs to be discussed in more detail. Monospace
            case also has a bunch of considerations. Not sure why
            adding a fixed value is right because ratio of advance
            widths for different letters changes depending on the
            exact font. It's a crude fixup.
  <myles> +1 to fantasai re:advance-override
  <florian> +1
  fantasai: On main proposal for ascent and descent it's fine. Had
            discussed similar for super and subscript metrics
  <jfkthame> +1 here too
  chrishtr: Agree we should split advance-override. I think this is
            appropriate to 2nd use case from xiaochengh more than the
            original one brought by myles. Split and continue to

  Rossen: Other comments? If not are we coming to resolution?
  fantasai: Proposal: Add ascent and descent and line-gap-override as
            fontface descriptors
  myles: and they take percentages
  Rossen: Objections?
  chrishtr: sgtm

  RESOLVED: Add ascent, descent, and line-gap override as fontface
            descriptors that take percentages

  fantasai: While we're on topic should we add the super and subscript
  <faceless2> +1 from me on @fantasai's additions
  chrishtr: Sound interesting, want to look more
  <myles> fantasai: what about text-decoration-position and
          text-decoration-thickness? Those properties accept
          from-font, and this would affect that value
  fantasai: Briefly, font has metrics on amount to shift up/down for
            super/subscript and says what size as function of font
            size. If font provides a glyph it's supposed to provide
            ones that match. If you don't have glyph UA can synthesize
            by resizing. In order to get that to match you need
            metrics and a lot of fonts don't have
  chrishtr: Is there difference between OS and browsers?
  fantasai: No, font metrics are frequently wrong
  <fantasai> chrishtr, see example in
  Rossen: This is very much related but I would prefer we open a new
          issue where more thought can be given. fantasai can you open
  fantasai: Yep

Proposal to extend CSS font-optical-sizing
  github: https://github.com/w3c/csswg-drafts/issues/4430

  Rossen: A rather large issue
  myles: This font-optical-sizing property takes 2 values, auto and
  myles: Optical sizing is a way for letters to effect shape of
         outlines. On large sizes letter shapes are more delicate for
         visual beauty and when small serifs are elongated. Fonts can
         morph shape
  myles: Implemented with a variable feature. Inside the fonts the
         variable axis is set to the font size.
  myles: Webkit sets to CSS pixel size. I think all browsers do, but
         not sure.
  chris: They do not which is the problem
  myles: Okay
  myles: Another piece of information is open type spec which defines
         that axis says that this is supposed to be set to font size
         in points. Not CSS points, but points. Relevant to MacOS and
  myles: Actual proposal is to extend syntax to not just be none and
         auto but add a number that's more expressive so authors can
         say if they want font size to be CSS pixels, CSS points, or
         something else.
  myles: I have opinions but want to let others speak.
  myles: I guess I can mention why I think it's bad. There is a right
         answer which is what open type spec says. On MacOS and iOS
         the OSs have a coordinate system. Designed such that 72
         typographic points = 1 physical pixel.
  myles: In webkit we want integral sized pixel blanks on physical
         pixel boundaries. We have 1 CSS pixel = 1 typographic point.
         Gives crisp backgrounds. 1 CSS inch = 4/3 typographic inches.
  myles: Means if you want length supplied in typographic points the
         way you get that on webkit is you supply CSS pixels. That's
         how we've defined it. It's correct though not intuitive. The
         spec...no reason to increase flexibility because we're doing
         it correctly.

  chris: Backing myles up. He's explained how it comes to correct way.
         Others have seen that webkit sets in CSS pixels but don't
         have the rest so it comes out wrong. It's a problem. Easiest
         solution is for other browsers to fix it which is as simple
         has multiplying by 4/3.
  chris: I think the proposal which is on this thread and on opentype
         list they assume browsers won't change so they need to fix it
         in the spec. I would prefer the other browsers did it so they
         get correct size and then we don't need anything else.
  * fantasai wonders if jfkthame is on the call
  chris: jfkthame did point out the way the others browser do it. I
         hope he's on.

  fantasai: Question. If I write a document in MS Word and say font
            size is 12 pt and have optical sizing enabled, print it.
            Export to HTML. Print that. Sizes are 12pt in both cases.
            Do I get different results?
  chris: Interesting. Size in both prints and size on screen. I don't
  fantasai: Authors would expect to render the same.
  chris: Yes
  fantasai: Can we make sure that happens? I'm confused as to what is
            happening but I think that should be a constraint.
  <faceless2> There is no support in PDF or PostScript for variable
              fonts. So any optical-sizing axis adjustments are done
              before the print layer, in the application.

  myles: Relevant piece here is the scale...on MacOS and iOS we have 1
         typographic point = 1 CSS pixel. When you print that may not
         be true. Could come out same even if you see on screen
         different for OS.
  fantasai: Suppose I have a doc I'm looking at on screen. Optical
            sizing axis has significant differences. Will I get
            different shape text when print? Should I?
  myles: You could, yes. CSS units to typographic units is different
         when printing. Could be because we've picked this scale
         because of screens. When printing don't have that.
  fantasai: Optical sizing is change in glyph shape. What does it have
            to do with crispness of glyph?
  myles: Sorry. We've scaled entire CSS coordinate system by 1/3.
         That's because in web today authors say 4px for things like
         border and margins. All over the place. If we made it such
         that 1 CSS inch = 1 typographic inch the px length would not
         map to a physical pixel. Solved by scaling the entire CSS
         coordinate system by 1/3 so things lie on pixel boundaries
         more often.
  fantasai: ...okay
  chris: True of original Mac. Seems like high dpi devices there are
         more options. I guess these are micro-pixels?
  myles: I'd like to not talk retina.
  chris: I would because they're relevant
  <bradk> Not every iPhone has a Retina display
  myles: There's a 3rd system. There's physical if you measure crystal
         size. Not relevant because impacts by manufacturing process.
         More relevant is typographic because that's what OS is
         designed with.
  myles: If I want something 1 inch big on an app I'll use pixels.
         Assumption is that because OS is designed with a coordinate
         system if you make something a certain number of points in
         the coordinate system it'll look close on the physical screen.

  Rossen: At the hour and need to wrap. We're in the middle of the
          conversation. I see chris and fantasai on the queue so I
          encourage them to continue discussing on the issue and we
          can resume next week.
  fantasai: Summary- What I'm understanding is on the OS system level
            in different apps. Non web browser 1pt = 1px. Within CSS 1
            pt and 1 px and not same. So 1 CSS pt is different. When
            you print the points are equivalent to each other. We have
            inconsistent matchups. Issue is that WK choose to go along
            one set of equivalent lines and the people filing the
            issue picked a different set.
  Rossen: Let's resume in issue. myles when you feel it's ready please
          bring it back

  Rossen: Reminder there's a MathML call tomorrow.

Received on Wednesday, 16 September 2020 23:27:21 UTC