[CSSWG] Minutes Telecon 2021-04-28 [snapshot-2021] [css-fonts] [css-inline] [css-ruby] [selectors] [css-images] [css-counter-styles] [css-contain]

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

CSS Snapshot 2021

  - Please start gathering thoughts and content for the 2021 snapshot
      on github in issue #6243.

CSS Fonts

  - RESOLVED: No change to name; stay with size-adjust (Issue #6114:
              bikeshedding name of size-adjust descriptor)
  - RESOLVED: Add from-font keyword to font-size-adjust [to Fonts 5]
              (Issue #5539: font-size-adjust: auto)
  - fantasai will add details to issue #4818 (oblique angle for
      vertical text with text-combine-upright) about the difference in
      visual presentation this would introduce between regular italics
      and this property. Discussion will continue on GitHub
  - The group will wait for more evidence of author demand before
      taking up issue #6104 (Consider 'extends' descriptor to reduce
      duplicate declarations)

CSS Inline

  - RESOLVED: Fonts with negative line gaps are clamp at 0 (Issue
              #5064: The web de-facto requires nonnegative line gap
              metrics in fonts)

CSS Ruby

  - RESOLVED: Undo previous resolution. Treat replaced elements with
              an internal ruby display value as if they were inline at
              used value time (Issue #6000: Replaced annotation
              containers and base containers are nonsensical)


  - RESOLVED: Close no change (Issue #6237: Add a :media pseudo-class,
              to match the set of elements matching the media
  - Issue #6250 was filed to better define if Seek returns as playing
      or paused.

CSS Images

  - RESOLVED: image-set should act like srcset attribute with applying
              resolution (Issue #6241: image-set() resolution should
              be applied on-top of, not instead-of the natural image


  - RESOLVED: Switch to using 25AA (Issue #6200: counter-style square
              symbol (0x25FE) is bad)


  - Issue #6175 (What is the migration path for Container Queries?) is
      reaching a conclusion to allow a user to test a container query
      property value pair. The final details will be worked out on


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Apr/0005.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  David Baron
  Tab Atkins-Bittner
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brian Kardell
  Jonathan Kew
  Peter Linss
  Rune Lillesveen
  Alison Maher
  Myles Maxfield
  Tess O'Connor
  Morgan Reschenberg
  Florian Rivoal
  Miriam Suzanne
  Lea Verou
  Greg Whitfield

Scribe: dael

  Rossen: Hi everyone. We are going to get going in a couple minutes
  florian: The thing on issue #13 is a followup on something we've
           discussed earlier so it would be nice if we could move it
           earlier. Easy followup if it's fresh in mind.
  Rossen: I was maybe have this after the fonts items. I wasn't sure
          if it was ready
  florian: We can timebox to short and if it's longer we can get back
           to it
  Rossen: Alright. Let's see if we can get through fonts first
  Rossen: It is 9:02 in PT. Time to start
  Rossen: As usual, I wanted to ask for any additional agenda changes.
          Noted the one from florian
  Rossen: Anything else?

CSS Snapshot 2021
  github: https://github.com/w3c/csswg-drafts/issues/6243

  florian: This is not for deep discussion now. Last year we said we'd
           do snapshot early, failed, and released in December. Wanted
           to bring attention we should start thinking about it so we
           can release before Dec. Suggested mid-year would be nice
  florian: Start thinking, filing issue. We'll get back to it soon
  Rossen: Thank you for not forgetting and drawing our attention to it
  Rossen: In light of agenda I propose we move forward and everyone is
          encouraged to add issues or ideas to that issue. I will
          bring it back once a month and we can check in until we

CSS Fonts

bikeshedding name of size-adjust descriptor
  github: https://github.com/w3c/csswg-drafts/issues/6114

  chrishtr: One option is keeping the name. I think fantasai prefers
  chrishtr: Another option is font-scaling or font-scaling-factor
  chrishtr: Opinions?
  fantasai: I prefer original name
  chrishtr: I'm okay with all of those
  chrishtr: jfkthame and myles weighed in
  jfkthame: I prefer name with scaling but can live
  leaverou: What about scaling-factor? font- is not needed if this is
            a descriptor in @font-face

  fantasai: Proposed name is size-adjust which ties into font adjust.
            Work a bit differently but do exactly the same thing
  fantasai: size-adjust description on @fontface gives you descriptor
            to adjust font size by that much. font-size-adjust
            property takes a number of how big to scale to match
  fantasai: Proposals to expand beyond x-height to try and get fonts
            to match and normalize on metrics you request.
  fantasai: Both scale used size instead of impacting computed
  fantasai: Other reason was I figured pretty accurately represents
            what you're trying to do when you spec a font and size
  Rossen: Way I read the thread most folks lean toward font-scale as
          rename. Proposal by jfkthame and okay by chrishtr and myles
  Rossen: In description you used, fantasai, you used 'scale' 80% of
          time and 'adjust' once. font-scale sounds like pretty
          awesome alternative. Should we try and resolve on that?
  plinss: If we have existing property that does same it makes sense
          to keep the name
  jfkthame: What troubles me is it does it in a different way and the
            value given has a different meaning. That's source of my
            unease with keeping names close
  fantasai: There's syntax valid in font-size-adjust and ones in
            font-adjust and don't overlap. If we add percent it should
            do the same. If we want a feature that's where it should
            go and size-adjust would be a subset of font-size-adjust
  <smfr> there’s also [-webkit-]text-size-adjust

  Rossen: We can do one of two things. Hearing a split. We can straw
          poll between size-adjust and font-scale and take the result
  <fantasai> ok with a straw poll, has opinions but not gonna block
  chrishtr: sgtm
  <jfkthame> likewise
  <Rossen> A - size-adjust
  <Rossen> B - font-scale
  Rossen: options ^
  Rossen: Please cast your opinions, A or B, or the order you prefer
  <fantasai> A
  <myles> abstain
  <plinss> a
  <jfkthame> B
  <Rossen> B A
  <rachelandrew> A
  <chrishtr> AB
  <dholbert> B
  <astearns> abstain
  <smfr> B
  <Morgan> abstain
  <futhark> abstain
  <florian> abstain
  <cbiesinger> abstain
  Rossen: I love that abstain has a and b

  Rossen: This is very non-conclusive
  chrishtr: A bit more B than A
  Rossen: 5 and 5. That's not enough for consensus
  Rossen: Since there's no consensus, I don't hear strong reason to
  chrishtr: Can I make suggestion? Is there anyone who would object to
            leaving it the way it is?
  Rossen: That was going to be my proposal too
  Rossen: And if needed this can be brought back
  Rossen: Proposal: No change to name, stay with size-adjust

  smfr: No objections but then we have size-adjust font-size-adjust
        and prefix text-size-adjust which is things with similar names
        doing different things
  myles: Very different things
  Rossen: Based on WG votes we don't see to want to change strongly.
          Forcing a resolution and if people have strong opinions we
          can bring it back
  Rossen: Are there objections?

  RESOLVED: No change to name; stay with size-adjust

  Rossen: Please engage in issue if want further discussion

CSS Inline

The web de-facto requires nonnegative line gap metrics in fonts
  github: https://github.com/w3c/csswg-drafts/issues/5064

  myles: Pretty straightforward. Browsers do it but not in spec.
  myles: If font says it has negative line-gap it's clamped at 0
  Rossen: Anyone with different opinion why this shouldn't be the case?
  Rossen: Objections to Fonts with negative line gaps are clamp at 0

  florian: Question, have you checked this is true of print formatter?
  myles: No, haven't checked. FF, Chrome, and WK do it
  florian: Sounds like a good idea, wondering if done in print and how
           we deal with compat. Maybe just suggest they do it as well
  Rossen: This is why we have standards

  RESOLVED: Fonts with negative line gaps are clamp at 0

  myles: I think metric is within inline spec so I think this issue
         should be parented under that spec
  Rossen: Sure

CSS Fonts (continued)

font-size-adjust: auto
  github: https://github.com/w3c/csswg-drafts/issues/5539

  myles: Right now font-size-adjust takes a number. Seems hostile to
         authors. Believe use case is I want my fallback text to match
         relative size of primary. If author doesn't know aspect-ratio
         of primary text they have to figure it out and hard code it
  myles: I think that's a problem. Don't have strong suggestion to
         fix. One would be add keyword like from-font or auto that's
         use aspect-ratio from primary font
  Rossen: Do you have a...seems like thread is leaning for from-font
          instead of auto. Should we resolve on from-font?
  Rossen: Objection to adding from-font keyword to font-size-adjust?

  RESOLVED: Add from-font keyword to font-size-adjust

  Rossen: This is fonts 4? or 5?
  myles: Probably 5. In general new should be 5
  <fantasai> +1

oblique angle for vertical text with text-combine-upright
  github: https://github.com/w3c/csswg-drafts/issues/4818

  Rossen: Fairly straightforward explanation. Proposed resolution is
          in case of vertical text layout when we use
          text-combine-upright which introduces horizontal text skew
          should be to combined characters
  fantasai: Complication, if you have oblique glyphs they won't go
            downwards, but to the side. I think a little tricky for
            that reason. Wanted to bring it for discussion. I think
            what probably makes sense is we need another property that
            explicitly does skewing on the line
  fantasai: Not sure which way to do. Could be consistent with real
            itals or fix stuff on line
  Rossen: Then my proposal is continue on GH there. It doesn't sound
          like what you mentioned was already discussed to point where
          we can resolve. Behavior is dependent on your prop for skew
          property I would prefer to have the discussion when ready
  fantasai: Not dependent but needs consider. Main thing is do we want
            to be consistent with italics or have real and fake
            italics be different
  Rossen: Important decision. Hope was in absence of this we could
          resolve but you bring up a good point. This will introduce a
          fairly apparent difference which will not have a way for
          authors to combat it
  Rossen: If this was the case I propose we wait on resolving until
          we've resolved skew and how it works
  Rossen: What do you think fantasai?
  fantasai: I don't think we're ready to resolve, but doesn't depend
            on skew. We can go back to issue, but can't just be me
            talking about it. Been out there for a while
  Rossen: Can I ask you to link the skew issue if it's not linked and
          we'll bring back when ready for more discussion?

Consider 'extends' descriptor to reduce duplicate declarations
  github: https://github.com/w3c/csswg-drafts/issues/6104

  fantasai: The @counter-style rules can get complicated. @extend lets
            you go off previous definition. As @font-face gets more
            complicated might be might to have same mechanism so a
            font-face rule can extend another one and add some
  myles: I think I agree with astearns comment where we should wait
         for things like Sass to come up with it. A bit early to add
         because don't know we need it
  astearns: And a lot of things we're adding to complicate rule are
            for specific fonts and not really shared. Don't want to
            get to state where someone uses a value they tested on one
            font on a lot where they don't know correct
  fantasai: Yeah. When have variable font you'll have a bunch of
            common stuff to core. might want to set some things to set
            named variants
  astearns: Agree probably useful for variation fonts, but should wait
            until we know it'll be used
  leaverou: May not have seen seen complaints because authors copy/
            paste generated @font-face rules. Duplication is there
  <fantasai> +1
  myles: I understand we're discussing this because adding rules. If
         we give them time to start using new things we'll hear noise
         about needing this. If not necessary we won't
  Rossen: Hearing folks leaning toward waiting to see how and when
          it's needed
  Rossen: We'll put this on pause until have stronger signals

CSS Ruby

Replaced annotation containers and base containers are nonsensical
  github: https://github.com/w3c/csswg-drafts/issues/6000

  Rossen: Let's timebox to 5m
  florian: We discussed that it didn't make a whole lot of sense for
           replace elements to have ruby-base or ruby-text. xidorn has
           pushed back
  florian: Would rather we treat as inline replaced elements. Invokes
           rest of box fixup. Anonymous parents still generated. This
           would be simpler and is what happens with tables already.
           Replaced elements in table only get to be inline and
           wrapped into table parts
  florian: I think emilio also argued for that.
  florian: Given the pushback and we do this for tables I think this
           is a good idea. Saying they're treated as inlines makes
  florian: If we do that I would also propose we move this into the
           display spec instead of being in tables and ruby. Display
           talks about layout internals and could say when you try and
           apply to replaced element it's treated as inline
  florian: Any problems with that?
  Rossen: Did anyone follow it?

  Rossen: florian since there's no issues or comments, proposal?
  florian: Proposal: Undo previous resolution. Treat replaced elements
           with an internal ruby display value as if they were inline
  florian: at used value time
  Rossen: Would this align closer with table?
  florian: Yes, closer with tables on Mozilla's current impl
  Rossen: If I have display:table on the replaced element it becomes
  florian: display: table-row or -cell they're inline. For outermost
           like display:table or ruby this is handled.
  florian: For internal you're treated as inline
  Rossen: Right. Awesome
  Rossen: Additional comments or objections?

  RESOLVED: Undo previous resolution. Treat replaced elements with an
            internal ruby display value as if they were inline at used
            value time

  Rossen: Did previous one make it into spec?
  florian: Not yet

CSS Images

image-set() resolution should be applied on-top of, not instead-of
    the natural image resolution
  github: https://github.com/w3c/csswg-drafts/issues/6241

  Rossen: Is emilio on?
  Rossen: I'll push this


Add a :media pseudo-class, to match the set of elements matching the
    media pseudo-classes
  github: https://github.com/w3c/csswg-drafts/issues/6237

  TabAtkins: As of a week or two ago had 2 pseudo classes that applied
             to media. playing and paused are mutually exclusive. All
             elements not playing are pause.
  TabAtkins: We agreed on edits from hober adding additional media
             pseudo-classes to match additional states. I realized
             this property that you could always select on one
             pseudo-class no longer applied. Example: muted. Select
             all not muted you can't use Not muted because selects
             everything on page
  TabAtkins: Suggestion to help authors with this which is
             pseudo-class to just select media elements
  TabAtkins: A few objections in issue. leaverou pointed out requests
             in the past to select MQ as selector so it mixes into
             selectors and name for that would be media
  TabAtkins: emilio pointed out we have audio and video and now that
             we have :is it's not hard to get the same effect as you
             had before is pseudo-class
  TabAtkins: Both are reasonable. Don't know if enough to sink it. I
             still think might be valuable to do something in this
             realm. What do others think? Not sure which way to go

  florian: Question. When you use pause it only gives you paused media
  TabAtkins: Yeah. Every single media elements is either playing or
             paused. But because no non-muted pseudo-class we no
             longer have that property
  florian: And can't solve by adding opposite of those introduced?
  TabAtkins: Could. Feels weird to add explicitly negated version when
             we have pseudo class negation
  florian: But not same meaning
  TabAtkins: Yeah.

  hober: I think TabAtkins is right it's a real problem. Sympathetic
         to emilio point that :is audio|video is enough. Worry it's
         not future proof. If we add another media feature sites will
         not match the new ones
  hober: Slightly prefer adding a new pseudo-class but could live with
         leaving it to :is
  hober: Don't care for adding negated pseudo-classes for all the new
         ones. Exploded number in a way that feels distasteful, but
         it's an aesthetic preference
  TabAtkins: I think at this point I'm okay going with emilio and if
             we introduce more media elements we can revisit this so
             we don't have to negotiate future-proofing with media

  leaverou: I wanted to ask if we have sufficient evidence that
            authors want to target all media elements in a way.
            Stylesheets trying to target non-muted media elements?
            Feel it would be all video or audio
  <fantasai> +1 leaverou
  hober: One use case is in user stylesheet. Looking at a website,
         something obnoxious happening and I can't find it to make it
  Rossen: Good use case.
  <bkardell> it would be useful in extensions too

  emilio: Wanted to mention there is precedent for explicit negation
          with readwrite and readonly. You could argue that for
          website authors having media pseudo-class...argument hober
          made makes sense but can flip. New media elements would have
          selectors that didn't match start matching. Can go both ways.
  emilio: I don't care either way, but there is precedent for negation
  TabAtkins: That precedent exists in same way as playing and paused.
             Explicit different states. If name is not-x is what feels
  TabAtkins: Think we're reasonably agreeing to close no change and
             rely on :is
  <fantasai> +1 to close no change for now
  emilio: Sounds good
  <leaverou> +1 to close

  Rossen: When seeking will one apply? both? none?
  TabAtkins: I think playing
  hober: Buffering and stalled playing still matches. I don't remember
         if new spec text says for seeking. Might be good followup
  TabAtkins: Yeah, could use clarification
  <tantek> possibly related: we have pseudo-classes for partially
           loaded images right? (that are still loading)
  <TabAtkins> OH wait lol, we just have a :seeking pseudo-class now
  <TabAtkins> So, uh, obviously that's the one that matches when
              you're seeking
  fantasai: On queue to agree with leaverou and emilio. Close no
            change. If we need clarification add resolution
  hober: Clarification shouldn't be always one or the other for
         seeking. Can used seeker to search playing or paused. Need to
         say unlike buffering or stalled you might be playing or
         paused when seeking
  Rossen: Seek has no change to the last known state of playing or
          paused. Fair?
  hober: I think so
  Rossen: Proposal: Close no change
  hober: Can we also add action to write clarification?
  ACTION hober add text for Seek has no change to the last known state
         of playing or paused
  <fantasai> filed issue for hober at

  RESOLVED: Close no change

CSS Images

image-set() resolution should be applied on-top of, not instead-of
    the natural image resolution
  github: https://github.com/w3c/csswg-drafts/issues/6241

  emilio: Matches existing impl. Basically spec says if you omit
          image-set resolution then you use natural image resolution
  emilio: If you spec image-set resolution it overrides whatever
          resolution image has
  emilio: Allows to figure out if image has native resolution. Not
          amazing. Chrome and WK apply image resolution and then
          image-set resolution. Seems reasonable and sensible
  emilio: So this should agree with existing impl
  TabAtkins: Happy to resolve on agree with existing impl. I'm not
             sure how this is supposed to work from reading thread. Do
             not understand multiplying resolution by exif resolution
             gives you something usable
  emilio: It's a cross-origin info leak
  TabAtkins: I suspect something more subtle is happening than I
             understand. Feels ridiculous. But we'll figure it out
  emilio: If you find out what it is that's great
  TabAtkins: I'd like us to match so happy to resolve
  TabAtkins: Proposal: image-set should act like srcset attribute with
             applying resolution
  Rossen: Objections?

  RESOLVED: image-set should act like srcset attribute with applying


counter-style square symbol (0x25FE) is bad
  github: https://github.com/w3c/csswg-drafts/issues/6200

  TabAtkins: One of the easy cases we need to resolve on
  TabAtkins: Count spec says build in square renders something like
             25FE codepoint. Problem is that has emoji presentation.
             Presents as an emoji rather than a character with text
  TabAtkins: Also apparently a little larger
  TabAtkins: Suggestion of better character
  TabAtkins: 25aa
  TabAtkins: Switch in spec to 25aa which is not emoji so renders more
             correct and better size
  TabAtkins: GH treats 25aa as an emoji which is not what borwsers do.
             Confusing but should be fine in practice.
  Rossen: Any other ideas of a character? If not, objections?

  RESOLVED: Switch to using 25AA

CSS Contain

What is the migration path for Container Queries?
  github: https://github.com/w3c/csswg-drafts/issues/6175

  miriam: Talked about this last week
  miriam: Went to thread.
  miriam: Proposal to add a container function to supports similar to
          selector in that you can test a container query property
          value pair
  miriam: Also it would be good to get consistency on how unknown
          functions or tests are handled
  miriam: Other proposal is unknown supports conditions evaluate as
  Rossen: Thank you
  Rossen: With that proposal, are there any other opinions where?
  TabAtkins: Sounds good
  miriam: Proposal 1: Any unknown supports conditions should evaluate
          as unsupported
  TabAtkins: Rephrase: unknown support conditions should work the same
             as unknown media conditions
  florian: Clarification, they don't evaluate to false which is a
           weird not bool
  TabAtkins: Evaluate to false at top value. Unknown property as
             unknown but it doesn't define top level unknown so
             becomes false
  emilio: Do we want @supports NOT [unknown] true or false?
  TabAtkins: Same as MQ for unknown things. NOT [unknown] is unknown
  miriam: Don't think that works well
  emilio: Right. Not great. Can't use @supports NOT container because
          will never match. Returns true for browsers without container
  miriam: Want it to evaluate true when negate it
  TabAtkins: There's unknown which is syntax we don't understand and
             syntax that's false because you don't impl the thing yet
  miriam: To be backwards compat we need unknown to evaluate true when
          you negate it so it works with browsers that don't
          understand container
  dbaron: Argument that @supports should be different for MQ. Unknown
          @supports is like an unsupported feature
  <dbaron> (And I think I was agreeing with miriam.)
  <miriam> Yes, @dbaron - that's exactly what I was trying to get at,

  Rossen: We have folks starting to drop off
  Rossen: Sounds like we want to take this back to the thread, flesh
          it out, and bring it as first topic this week
  TabAtkins: Thread got confused with impl doing weird things. We're
             past that, just need to discuss on this

  Rossen: We're a couple minutes overtime. Thanks for hanging around

Received on Wednesday, 28 April 2021 23:29:50 UTC