[CSSWG] Minutes Telecon 2021-01-13 [css-cascade-5] [selectors] [css-pseudo-4] [css-sizing-4] [css-contain-2]

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

  - RESOLVED: Rename @layers to @layer (Issue #5855: Rename @layers to


  - RESOLVED: Convert at parse time (Issue #5847: Define how "legacy
              aliases" work on selectors)

CSS Pseudo

  - RESOLVED: Drop caret-color and cursor (Issue #4100: Painting of
              the cursor and the caret with highlight pseudos)
  - RESOLVED: Exclude word break and no break spaces on either side of
              the letter (Issue #5830: Fine-tuning ::first-letter
              punctuation pattern matching)
  - RESOLVED: Exclude dashes and opening punctuation (ps and pd in
              unicode) from following (Issue #5830)
  - RESOLVED: Include symbols when looking for first-letter (Issue
              #5099: ::first-letter should include currency)
  - RESOLVED: Align with chromium behavior for ::first-line and
              line-height (Issue #2282: ::first-line and line-height)
  - RESOLVED: ::first-letter pseudo element is closed at the end of
              the line even if the content that would otherwise be
              part of it is wrapped to the next line (Issue #2254:
              Multi-line ::first-letter)

Sizing & Contain

  - RESOLVED: Align the behavior of auto sizing for size-containment
              with that of ResizeObserver (Issue #5668: Revisiting
              auto-sizing when size-containment applies)

CSS Contain

  - The next step for content-visibility: hidden-matchable property
      (Issue #5595) will be TAG review to evaluate the group's
      questions about if matchable will work with browser settings
      like reader-mode and if matchable belongs in CSS or in markup.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jan/0003.html

  Adam Argyle
  Rossen Atanassov
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brad Kemper
  Johnathan Kew
  Una Kravets
  Vladimir Levin
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Myles Maxfield
  Morgan Reschenberg
  Florian Rivoal
  Cassondra Roberts
  Jen Simmons
  Miriam Suzanne
  Lea Verou

Scribe: dael

  Rossen: Let's get started
  Rossen: We have a full agenda. As usual I wanted to ask if people
          have any extra agenda items.
  Rossen: Only reminder to give is about the upcoming F2F in February.
  Rossen: We have started to add the milestones to open issues. Feel
          free to mark agenda+ F2F for anything you want for the F2F.
  Rossen: Other details are in the private list

CSS Cascade 5

Rename @layers to @layer
  github: https://github.com/w3c/csswg-drafts/issues/5855

  Rossen: Topic explains it. fantasai anything to add?
  fantasai: Nope
  <florian> Seems fine
  Rossen: Any feedback or objections to renaming @layers to @layer?
  <miriam> I'm in favor
  <leaverou> in favor
  Rossen: Hearing no objects and seeing IRC support

  RESOLVED: rename @layers to @layer


Define how "legacy aliases" work on selectors
  github: https://github.com/w3c/csswg-drafts/issues/5847

  emilio: Have a couple places where we define a selector where for
          legacy reason it can be implemented as alias but no
          definition of that.
  emilio: Came up as I did compat work on other pseudo classes.
  emilio: Compat can change what needs to be done but seems as if we
          should have guidance on how this should work
  emilio: afaict two options are keep zeroizing the non-standard or
          convert them at parse time
  emilio: Some inconsistencies in Blink. Gecko should always turn it
          into the standard at parse time. I think that's what we do
          for properties in general

  Rossen: Proposal is align more closely with converting at parse time
  Rossen: Questions or should we resolve on that?
  Rossen: I'll take silence as no
  Rossen: No comments or objections?
  Rossen: I see support in GH from TabAtkins

  RESOLVED: convert at parse time

Math & CSS Fonts

Solution to mixing text and math fonts in a document
  github: https://github.com/w3c/csswg-drafts/issues/5534

  Rossen: Do we have folks to discuss these MathML issues?
  Rossen: fantasai you added this to agenda a while back
  Rossen: Silence I will take as not ready.
  Rossen: We'll backlog at this point and remove agenda+

CSS Display

  github: https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-745563829

  Rossen: Is this something we can resolve now and move forward and if
          anyone has issues we can reopen
  fantasai: Mats proposed that display:math outside of MathML should
            make element behave as an em row. I agree with Mats but
            Fred thinks more complex to implement. Mats had
            implemented and didn't think it was complicated
  Rossen: Who was pushing back on complexity?
  fantasai: Fred

  emilio: Also issue of display:math doing magical things depending on
          which element. Is there a different issue on that? That's
          the other concern Mats had
  fantasai: Should be a different issue on that one
  emilio: I don't mind filing it, no need to discuss right now in
          order to discuss right now

  Rossen: Doesn't sound like we're ready to discuss
  fantasai: I can't present Fred's PoV. I can point you to the
            comments. I agree with Mats so could represent that.
  Rossen: Let's push this on back to the backlog as well
  Rossen: Perhaps these can be F2F topics
  fantasai: You need to schedule them when the people you want to show
            up will show up. It's been end of agenda so no one knows
            to call in
  astearns: I pinged everyone involved and didn't get a response
  Rossen: Likewise. It's not for lack of trying
  Rossen: There are going on the back burner and those that care can
          bring them back

CSS Pseudo

Painting of the cursor and the caret with highlight pseudos
  github: https://github.com/w3c/csswg-drafts/issues/4100

  fantasai: florian asked what happened with multi highlights and
            different caret values. Which one wins. Top or top
            non-auto. Top most non-auto makes more sense I think but I
            don't know. Is anyone planning to implement these
  Rossen: Regardless of plan to implement we should be able to define
          expected behavior. If top-most non-auto makes most sense we
          can resolve and when people impl if it's not the right
          choice we can discuss again then
  florian: Alternative could be if no one thinks this is good to
           implement we could drop from list of elements that apply to
           this pseudo element. These were added because not layout
           effecting. But if there's no interest we could drop them.
  Rossen: Choices are drop it or top-most non-auto

  GameMaker: I wasn't on the call earlier but I recall reading notes
             about issues with this and grammar and auto-spell check
             because loading resources could be a security issue
  GameMaker: Maybe didn't understand discussion, but thinking that
             could be a reason to drop. In my implementation I haven't
             looked at doing cursor or caret. Definitely would be more
             complicated to do. I'm in favor of just dropping cursor
             and caret
  <tantek> +1 to dropping. seems to add complexity for theoretical
  Rossen: Anyone want to keep those?
  florian: Not a strong want but it seems security only applied to one
           of the two. Caret color won't load resources
  fantasai: But if no one wants to implement and there's no strong
            usecase we should drop
  <tantek> I'd be in favor of only reconsidering them if an
           implementor felt compelled to try implementing it (for
           whatever reason)
  Rossen: Objections to dropping caret-color and cursor?

  RESOLVED: drop caret-color and cursor

CSS Sizing & Contain

Revisiting auto-sizing when size-containment applies
  github: https://github.com/w3c/csswg-drafts/issues/5668

  vmpstr: A little background. We have content-visibility:auto Way it
          works is when element goes offscreen we add size containment
          and when it's on screen we remove. Can change the scrollbar
          size which is undesired. Added constrain-intrinsic-size to
          manage this. Works great as a placeholder because gives some
          size even when size containment applies.
  vmpstr: Problem is it's hard to know the right size so scrollbar can
          still jump. When element is on screen as it rolls offscreen
          browser knows size that would cause scrollbar not to jump.
          There is a value it could take. Browser knows but it's not
  vmpstr: I think script can get an estimate
  vmpstr: Proposal is add an auto qualification to
          contain-intrinsic-size which is when size containment is
          first applied and when content has been previously rendered
          remember that size and use it as the value. Else use
  vmpstr: Daniel and Christian raised some points that it adds
          dependency on sequence of steps.
  vmpstr: Wanted to bring to group. Hoping there's a solution that
          doesn't involve script. Maybe not this exact proposal, but
          this is what I have

  TabAtkins: Point about non-determinism about exactly when size is
             recorded, while technically true it's a cost we eaten
             with animations. Style depends on exactly when it started
             so you know how far in animation you are. Since we've
             eaten that cost for animations I don't see why not here
             unless we think that was unavoidably broken
  TabAtkins: We should think about this the same as animation start
  smfr: Slightly different proposal is specify this exactly same as
        ResizeObserver. Timing is well defined. Write the spec so you
        get the same behavior as if you registered a resize on it and
        that's the same size as you'd get with snapshot
  <TabAtkins> smfr's idea makes sense to me as well
  <TabAtkins> it's what you'd get if you did this by hand anyway
  vmpstr: Good idea. Question is when do we snapshot. If you add size
          containment and change another style I guess you first
          process size containment and snapshot at that time?
  smfr: I think you would use size from the most recent event loop
        steps where your resize observer would have fired and given an
        answer. Might be loop before a style change that effects
  smfr: That's the last thing you saw on screen
  vmpstr: Makes sense

  chrishtr: ResizeObserver is when content-visibility content is
            unskipped, right?
  vmpstr: On the contents of the element. On the element itself the
          observer would still fire
  chrishtr: So a polyfill would put it on the element and when it
            fires set contain intrinsic size on that. And smfr
            proposal is do that without any script
  vmpstr: Pretty much. I've seen a polyfill that does that. I'm not
          sure what to do with padding and margins.
  chrishtr: ResizeObserver allows you to observe different boxes
  vmpstr: Then yeah
  chrishtr: What if it was independent of content visibility. It
            restricts to the contain-intrinsic-size property
  vmpstr: Content visibility was motivation. Proposal is change to
          contain-intrinsic-size to save off the value
  chrishtr: Only do when size containment wasn't present
  vmpstr: Right. And just snapshot at the time size containment starts
          being applied
  chrishtr: So if size containment isn't present that size is
            automatically reflected into contain-intrinsic-size used

  Rossen: Hearing alignment on proposal from smfr to align with
          ResizeObserver. Are we happy with that and then will work on
          additional details in the issue?
  Rossen: Objections to align the behavior of auto sizing for
          size-containment with that of ResizeObserver

  RESOLVED: Align the behavior of auto sizing for size-containment
            with that of ResizeObserver

CSS Contain

Proposal: content-visibility: hidden-matchable
  github: https://github.com/w3c/csswg-drafts/issues/5595

  Rossen: This issue can take a lot of time. Let's try to spend no
          more than 10 minutes on this.
  jarhar: Hello everyone. Proposed content-visibility:
          hidden-matchable property. I added responses on GH to the
          questions from last time. Wanted to know if there are
          additional issues and if responses on GH suffice

  fantasai: Once concern is if the control should be in css or in
            markup. Might be good to ask TAG about that.
  fantasai: Other than that, main question is defining details of what
            operations can and can't trigger matching
  <tantek> +1 to fantasai's concern, "matchability" feels like an
           expression of more semantically relevant content and thus
           may belong more in markup rather than in styling.

  smfr: I think chris's last comment is a good summary of my
        discomfort. I think TAG feedback would be good. There are
        features in UAs that vary and this proposal has impact on
        those features. TAG level discussion would be great
  <tantek> agreed with the reader-mode and screenreader semantics
           concerns comments in the issue
  Rossen: I'm scrolling through open TAG issues. I see the match event
          open from jarhar. Is there another active one with TAG?
  jarhar: I believe I do have a TAG review open.
  jarhar: Issue #511 on TAG
  <Rossen> https://github.com/w3ctag/design-reviews/issues/511
  Rossen: I believe that's scheduled to discuss during TAG F2F in a
          couple weeks
  chrishtr: And the concern from smfr has not been yet discussed in
            TAG correct?
  jarhar: Not that I know of
  Rossen: We have this issue cross-linked to TAG review. As the review
          with TAG we'll have the CSS issue as well for more context

  Rossen: What I'm hearing right now is a pause on this issue until we
          have TAG review
  Rossen: Then bring it back here
  Rossen: Also heard concerns from smfr. That's the summary. Is that
  chrishtr: smfr you said you have discomfort. I guess not swayed by
            our arguments. But if TAG doesn't think it's a big problem
            you're okay?
  smfr: If TAG is okay I'm okay. For example, I got pinged by devs
        about what are a11y considerations for hidden-matchable. There
        is ambiguity around a11y and reader-mode. Prefer to resolve
        but understand why it exists
  chrishtr: It's potential for dev confusion?
  smfr: Dev and user. They ctrl-f in reader mode but spotlight doesn't
        find it and that's confusing
  <tantek> +1 smfr
  chrishtr: So we'll take it to TAG
  chrishtr: Your comments, fantasai, are good to consider. We should
            work that out once we have consensus on smfr's issue
  Rossen: Cool. With that let's move forward
  <jensimmons> We definitely don't want to create new CSS where the
               a11y best-practice is confusing and unknown. There
               should be clarity.
  <tantek> +1 jensimmons. agreed that's a good general methodology

CSS Pseudo

Fine-tuning ::first-letter punctuation pattern matching
  github: https://github.com/w3c/csswg-drafts/issues/5830

  fantasai: Problems raised in terms of matching ::first-letter.
            Example in an issue a " b". When we added ability to
            include whitespace we chose to include word spaces
  fantasai: Problem is we aren't considering what's on other side of
            punctuation. If spec only used to separate makes sense,
            but not always. We're picking up punctuation that should
            be attached to word following. That's a problem.
  fantasai: I think exclude word and no-break spaces on following side
            of letter. Maybe leading side but definitely following
  Rossen: Feedback on this one?
  Rossen: No feedback on it, I guess
  <tantek> +1 reasoning makes sense

  fantasai: Objections to making word and no break spaces not included?
  jfkthame: No objection but thinking it should be same both before
            and after letter since that's less confusing. If they want
            a word space they need to use a different character no
            matter what
  fantasai: Happy to exclude from both sides for consistency. word
            space isn't the correct character to use typographically
  Rossen: Prop: Exclude word break and no break spaces on either side
          of the letter
  Rossen: Objections?

  RESOLVED: Exclude word break and no break spaces on either side of
            the letter

  fantasai: There are several classes of punctuation. One we don't
            want to include is opening punctuation after first letter.
            first-letter than { doesn't make sense to include. In
            European language there's spaces so it doesn't matter
            much. For other languages there is no such thing and we're
            trying to get first letter. We have opening punctuation
            class and that should be excluded
  fantasai: Two ambiguous classes that are common where I don't know
            how to handle cleanly. Least we can do is exclude the
            opening punctuation
  Rossen: Any feedback?
  <tantek> +1 on excluding opening punctuations
  bradk: Sounds reasonable

  fantasai: Similar case with dashes. Not quite sure the conventions
            for dash after first letter. I suspect we want to exclude
            on following side, but I'm not entirely familiar. On
            leading side long dashes mark quotations. Not sure on
            following. Inclination is also exclude dashes from
            following punctuation
  <bradk> I don’t have opinion about dashes
  Rossen: One resolution here?
  fantasai: Sure
  fantasai: Proposal: Exclude dashes and opening punctuation (ps and
            pd in unicode) from following

  RESOLVED: Exclude dashes and opening punctuation (ps and pd in
            unicode) from following

  fantasai: I think that's if for now on this issue. Will need to come
            back, I think

::first-letter should include currency
  github: https://github.com/w3c/csswg-drafts/issues/5099

  Rossen: Has a test case in it
  fantasai: Proposal is we include symbols along with letters and
            numbers when looking for first-letter
  fantasai: Makes sense and we should do it. Otherwise if you start
            paragraph with a symbol there isn't a first-letter. Blink
            and WK do this
  Rossen: Any reasons why we shouldn't do it?
  <tantek> should we include # also in case you start your paragraph
           with a hashtag?
  <bradk> +1
  Rossen: Objections to include symbols when looking for first-letter?

  RESOLVED: Include symbols when looking for first-letter

::first-line and line-height
  github: https://github.com/w3c/csswg-drafts/issues/2282

  fantasai: Is ::first-line about to affect root inline element
            fragment. Then an issue about if line-height can be
            changed about first-line. Same question.
  fantasai: Seems to me letter it affecting makes sense. Proposal:
            root inline fragment on the first line is inside the
            ::first-line and therefore is effected by changes in size

  oriol: Clarify, it's not just being able to change line-height, but
         also set smaller than line-height in the block container or
         is block container the min value
  Rossen: Currently block container is the min and the proposal here
          allow it to be smaller
  oriol: Depends on impl. In FF block container is a min but in
         chromium you can reduce to smaller
  Rossen: Which are we proposing to change to? chromium or FF?
  oriol: I think fantasai proposed chromium
  Rossen: So ability to set sizes smaller than block container
  Rossen: Additional comments or feedback?

  RESOLVED: Align with chromium behavior for ::first-line and

Multi-line ::first-letter
  github: https://github.com/w3c/csswg-drafts/issues/2254

  oriol: Problem is theoretically first-letter should be in
         first-line. If block container is narrow enough it can happen
         that first-letter will span multiple lines.
  oriol: I had a proposal to try to define how this should behave.
  oriol: Some parts to this proposal
  oriol: First would be to standardize what FF, old Edge, and WK do
         which is that if you don't have a typographic letter unit
         then the first-letter is allowed to match the punctuation.
  oriol: If you have both punctuation and letter you include both. If
         you don't it's allowed to only have punctuation.
  oriol: Second would be if first-letter could span multi-line we
         restrict it to first-line so it can inherit.
  oriol: Browser that does both parts of this proposal is FF
  Rossen: Feedback? Any reason why we shouldn't adopt FF behavior?
  * fantasai doesn't have a strong opinion
  Rossen: Objections to adopt the FF behavior which allows us
          to...want to make sure we have right resolution
  fantasai: Summary: first-letter pseudo element is closed at the end
            of the line even if the content that would otherwise be
            part of it is wrapped to the next line
  <tantek> +1 that's a good summary fantasai
  Rossen: Objections?

  RESOLVED: ::first-letter pseudo element is closed at the end of the
            line even if the content that would otherwise be part of
            it is wrapped to the next line

  Rossen: That's the end of the agenda. We can break 5 minutes early
          unless there's any other topics for discussion
  Rossen: Going once, going twice...let's get 5 minutes back
  Rossen: Thanks everyone, we'll chat next week

Received on Thursday, 14 January 2021 00:33:02 UTC