[CSSWG] Minutes TPAC/Vancouver 2022-09-16 Part V: Font Loading, CSS Overflow, Scroll Animations, Selectors, CSS Backgrounds [css-font-loading] [css-overflow] [scroll-animations] [css-selectors] [css-backgrounds]

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

Font Loading

  - Webkit is behaving according to the spec intent in issue #7680
      (FontFaceSet.load() promise rejections). Only changes necessary
      would be editorial clarifications.
  - RESOLVED: Republish css-font-loading-3 as a WD once the Changes
              section is up to date (Issue #7065: Lots of edits since
              2014 /TR, republish?)

CSS Overflow

  - The proposal in issue #7708 (Is continue: discard working in the
      fragment tree useful?) is implement line-clamp by making extra
      lines invisible and shortening their containing block accordingly
  - There was discussion about if the changes would lose useful clarity
      that is currently in place from the tie in to fragmentation model
  - There were many questions on the detailed consequences, so the issue
      will return to Github.

Scroll Animations

  - The proposal to give authors the ability to attach a timeline to
      any sibling/descendant (Issues #7047 (Scope of Named Timelines) &
      #7759 (Broader Scope of Named Timelines)) seemed to be the best
      approach, but probably not necessary in this level so it will be


  - The group didn't want to make any change unless the breakage was
      bad for issue #7676 (The forgiving nature of :has breaks jQuery
      when used with a complex :has selector). If the breakage is bad,
      the lean was to make only :is() and :where() forgiving

CSS Backgrounds

  - The demo for issue #7103 (The shape of box-shadow should be a
      circle for a box with border-radius:50% and big spread) still
      needs some additional examples before the group will be ready to


Agenda: https://github.com/w3c/csswg-drafts/projects/32

Scribe: heycam

Font Loading

FontFaceSet.load() promise rejections
github: https://github.com/w3c/csswg-drafts/issues/7680

  myles: I was debugging some stuff
  myles: The question is, when you call FontFaceSet.load(), under which
         circumstances will that promise be rejected?
  myles: Right now the only circumstance is if the input to the
         function is a syntax error
  myles: this is not what any browser does, according to my testing
  myles: If there were network errors, all browsers will reject that
  myles: that's the extent of my testing in other browsers
  myles: In WebKit, our behavior is: if any of the network loads
         triggered by this call fail, we'll reject the promise
  myles: the important part is, in the situation where all the fonts
         fail to load, there's interop there
  myles: the spec should match

  JakeA: It's a misreading of the spec
  JakeA: although the spec says it should resolve, resolve is not the
         opposite of reject, fulfill is the opposite
  JakeA: you can resolve it by rejecting it
  JakeA: the language the spec uses to wait for a series of promises,
         it's using the same method as Promise.all()
  JakeA: so it'll reject as soon as any of the input promises reject,
         or it will fulfill if all of them were fulfilled
  myles: Sounds great, it's editorial then

  TabAtkins: During the break, I was linking us to the WebIDL terms now
             they exist
  TabAtkins: This was one of the first W3C specs to use promises
  TabAtkins: but now we have definitions to link to
  TabAtkins: WebKit is already following the spec as intended

Lots of edits since 2014 /TR, republish?
github: https://github.com/w3c/csswg-drafts/issues/7065

  chris: The changes section in this spec bears no relation to the
         edits that have been made
  chris: there has been no attempt to keep that up to date
  chris: but it's 2014, probably time for an update?
  chris: Been a bunch of changes
  TabAtkins: I say wait for a round decade
  TabAtkins: Definitely does need to be updated
  TabAtkins: needs a moderate amount of admin work to do that
  TabAtkins: I should spend time on this next I have a free moment
  chris: The changes predate when we moved to GitHub
  chris: Need to trawl through the mailing list to find all the changes
  astearns: Should we keep this issue open for getting the changes
            section up to date?
  TabAtkins: I think so
  chris: We can have a conditional resolution that once the changes
         section is up to date, we republish
  astearns: Sounds good to me

  RESOLVED: Republish css-font-loading-3 WD after Changes section is

CSS Overflow
Scribe: TabAtkins
Scribe's scribe: fantasai

Is continue: discard working in the fragment tree useful?
github: https://github.com/w3c/csswg-drafts/issues/7708

  emilio: Making line-clamp work using continue:discard has some side
  emilio: Based on fragmentation implies the boxes you clamp don't
          exist, so OM APIs return 0 sizes, etc
  emilio: And implies that like border-bottom disappears due to
  emilio: I think it would be both easier and more useful to impl
          line-clamp by clamping both content-height, as it does now,
          and the scrollable overflow, and hiding the clamped lines
          rather than discarding fragments
  emilio: There's been some discussion - I think in general it's a lot
          easier to implement but similarly useful
  emilio: So easier to reach unprefixed line-clamp
  emilio: We could decide to ship line-clamp as a longhand for now and
          decide what to do about shorthands later

  andreubotella: It's not clear how line-clamp would work with editing
  andreubotella: Not clear where carat would go if you move past the
                 clamped line
  andreubotella: Would be less of an issue with emilio's model

  florian: We'd also need to define how padding/etc will work. using
           fragmentation gets us that, it defines those
  florian: One of the goals is to avoid reinventing all that
  florian: It's true that the discarded part, we have incomplete
           answers about what to do with abspos in there, what happens
           to the caret, etc
  florian: So maybe we do use fragmentation, but rather than discard
           the post-fragmentation is invisible
  florian: but saying that it's easier to do it visually is in conflict
           with the existing knowledge that it's in conflict with
           visual stuff
  florian: like bidi content
  florian: In the fragment model, in document order, when we have
           enough content to place the ellipsis; that's different from
           hiding characters at the end of the line
  florian: Another complaint about visual aspect is you have no control
           over what gets elided and whether it happens at sensible
           line-break points
  florian: If using fragmentation, the line breaking properties work
  florian: Another thing which is useful under the current model (and
           maybe usable under your new model), a lot of people want to
           clamp at 3 lines, but a lot want to clamp at 100px
  iank: Still possible
  florian: Not impossible, but undefined. Defined with fragmentation,
           but not defined without.
  florian: Don't want to display a half-line, for example
  florian: So I think we can find ways to define things in terms of
           fragmentation that are less mysterious
  florian: And also make some statements about "allowable
  florian: But I think entirely discard fragmentation would be

  iank: Clarification, the visual model is purely about subsequent lines
  iank: Still do layout placement of ellipsis, etc
  iank: So not necessarily in conflict with what you want to achieve
  iank: I don't wanna have a spec where all the impls do emilio's
        model, and there's a bunch of soft wording about how it's
  florian: Yeah point is not to write fiction, it's just that if we do
           emilio's model because it's more useful, we shouldn't omit
           the useful properties of the current spec

  florian: If we treat it as something like a multicol where additional
           cols aren't painted, you can have an answer to all the API
  iank: There's still subtle diffs
  iank: in emilio's model it's actually desirable that you don't
        fragment the borders
  emilio: Say you clamp in a nested block with border/padding
  emilio: it has five lines, you clamp at 3, per fragmentation you're
          supposed to hide the border padding at the bottom
  fantasai: Which element has line-clamp here?
  emilio: The bfc
  fantasai: So inside the bfc you have a text with 5 text lines
  fantasai: the bfc says line-clamp:3
  fantasai: so you clamp after three lines, then what's after is clamped
  emilio: No
  iank: You're just clamping the content box. You set the content box
        to the size after clamping and then layout as normal.
  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10735

  [retreading the previous example]
  emilio: The auto height of the inner box is 3 lines tall (plus mbp)
  florian: So you're reinventing fragmentation...
  emilio: No fragment would crop the border
  florian: Yeah we have box-decoration-break that lets you control it
  iank: Well they're not repeated, because this *isn't* fragmentation
  florian: If we do it with fragmentation you can choose whether to
           clip those borders or not
  iank: You can here, with border:0
  florian: No you can't, you can't predict whether the clamp activates
           or not
  florian: Fragmentation already solved this, dunno why we're
  iank: I think this is a small edge case and most people would expect
        the behavior from emilio's model
  astearns: Agree this is probably small, but there are tons of
            decisions in this space about what to do after a fragment
            break, and we'd have to reinvent all of these
  emilio: Don't think it's reinventing, we just do what we do if you
          clamp the auto size and visually hide the overlap
  iank: Very similar to empty-cells on tables, or similar to
        visibility:hidden but not quite
  astearns: there's a long queue

  heycam: It's probably more like visibility:collapse on those
          additional lines at the end, they take up no space and aren't
  iank: a little diff because collapse applies to a container, and it
        often gets smushed in size and there's some other effects, but
  iank: The way we'd implement is exactly like empty-cells

  heycam: At a high level in wk, I think we support getting to the full
          fragmentation model
  heycam: But we'll need an interim solution, maybe emilio's or similar
  heycam: think it would be useful to enumerate the diff between this
          and the full fragment solution so we can see what it's most
          similar to
  heycam: and how likely it is we run into compat issue in the future
  heycam: like gBCR() effects, etc
  heycam: If that would change between the two solutions, that might
          be risky

  iank: Broadly I'm supportive of emilio's suggestion
  iank: webdevs strongly desire an unprefixed line-clamp
  iank: We, Blink, are probably the closest to having a fragmentation
        solution, but still a ways away
  iank: emilio's suggestion means all engines can ship something highly
        interoperable fairly quickly that will satisfy webdev demands
  iank: don't want fiction, so if we do emilio's, want it in the spec
  iank: emilio's gets us there very quickly
  iank: I don't think emilio's and fragmentation are exclusive

  astearns: If we come up with a list of things that are going to be
            different, how can we move from one to the other?
  iank: I don't think that we will
  iank: I think we'll be shipping whichever we start with
  iank: So like, I don't believe we'll be able to straight unprefix
        -webkit-line-clamp even with emilio's solution, because devs
        are already depending on scrollable overflow returning a
        particular value to tell if clamping applied
  iank: I suspect we'll get something similar
  iank: with abspos at the end, for example
  heycam: So what I'm hearing is that if we come to the full solution
          it will need a switch
  iank: I think that's ok; they're related problems but not necessarily
        the same
  iank: When we want to truncate content and continue it in a different
        fragmentainer, I wouldn't be sad if that was a different set
        of fragmentation properties
  iank: People are today using prefixed line-clamp and unhappy about
        it, we can all ship an unprefixed line-clamp with emilio's
  astearns: but it's still different than emilio's?
  iank: Pretty sure we can translate most of it over, only big compat
        change will be the scrollable overflow size change

  florian: I don't want fiction either, so I'm happy to make
           accommodations so we can match impls
  florian: but I wanted to circle back to one potential difference,
           because I didn't understand an earlier answer
  florian: with emilio's, is it possible to "clamp after however many
           lines it takes to reach 300px"?
  emilio: Could be feasible, define that instead of "hide lines after
          the third" you'd hide all lines whose block-end edge is after
  florian: So you'd size the container to 300px, fill it in, start
           filling in content, then remove after...
  emilio: Not remove
  florian: You said you'd draw the mbp of children at the bottom, so
           you'll need to make room to insert those back
  florian: Note it's not the container border I'm talking about, it's
           the content element's border
  florian: before counting lines you don't know how many lines you'll
  fremy: You add both top and bottom mbp as you add it, then fill in
         lines until you hit the limit
  iank: Yup
  iank: Our -webkit-line-clamp will already abort and retry for
        complicated reasons. this is fine
  florian: What troubles me is not that it's undoable, clearly it is
           and is even simpler, but it will have something *very
           similar* to fragmentation which isn't quite fragmentation.
  astearns: Which makes you uneasy
  florian: Yeah
  florian: The bidi part I'm not sure how you solve
  florian: We don't control what chunk of text on the last line is okay
           to remove
  florian: this is a known problem of the existing paint-based ellipsis

  emilio: I think blink does layout-time ellipsis
  emilio: presumably they have to reshape arbitrary content when
          inserting it to avoid clipping
  florian: And it can push content around?
  iank: I'll have to double check, but I think we'll reshape, like if
        you land on a bad ligature we'll go back and split it
  florian: It's not just painting a ligature, it's about dropping
           letters or a whole word
  florian: similar for an abspos in the content, the static position
           changes depending on whether it's pushed to the next line or
  iank: I think abspos are break opposite in our impl for this reason

  fantasai: There's a number of directions people have wanted to extend
            this in, and starting from fragmentation model gets you to
            a bunch of different places that we want to end up
  fantasai: while starting from a visual model doesn't
  <fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10738
  fantasai: I also pasted a funny test case
  fantasai: it's pretty weird
  fantasai: This is the model we *want*?

  andreubotella: Regarding ellipsis, in current fragmentation there's
                 block-ellipsis where you can replace the final lines
                 with something
  andreubotella: How would this work?
  andreubotella: If the string has rtl and ltr characters?
  florian: It's specified, I don't recall the details. I think we
           insert the string as a string without wrapping opposite and
           with bidi isolation

  <break, duration 10min>

  <TabAtkins> I do think the "keep the bottom mbp of the children"
              thing is the big difference between fragmentation and
              this that is important to authors
  <TabAtkins> And this is not something you can do *at all* in
              fragmentation currently, b-d-break only controls the
              fragmentainer itself
  [editors note, Tab is wrong: box-decoration-break controls the borders
   of the broken box's fragments, not the fragmentainer]

Scroll Animations

Broader Scope of Named Timelines
githubs: https://github.com/w3c/csswg-drafts/issues/7047 and

  <fantasai> https://github.com/w3c/csswg-drafts/issues/7047#issuecomment-1239820755
  fantasai: We talked about the scope and came up with a default answer
  fantasai: also what we might do to give power to people who want to
            do something more far-ranging than just "prev sibling" or
  fantasai: so I came up with a suggestion to declare a timeline name
            but not attach it to a scroll container, and then attach it
            to one in the sibling/descendants
  fantasai: Suggestion is a property called scroll-timeline-attachment
  <TabAtkins> 'local' is the default, binds to the element you're on
  <TabAtkins> 'defer' will declare the name, but attach it to something
  fantasai: And another element can say "attach me to the timeline" of
            a given name
  fantasai: so if I want a global scope
  fantasai: can set scroll-timeline-name:foo on the root , and
            scroll-timeline-attachment:defer then on something else in
            the tree set scroll-timeline-name:foo and
            scroll-timeline-attachment: ancestor
  fantasai: and it'll attach to that timeline scoped to the root
  fantasai: I'm ambivalent about putting this in current spec, but
            wanted opinions on idea

  flackr: Two thoughts
  flackr: If you can name a timeline that's deferred, I don't think
          there's any need for the ancestor selection anymore, because
          you could just name that timeline?
  fantasai: 'defer; says you're planning to attach the name to
            something else
  fantasai: but if the element is also a scroll container
  fantasai: it doesn't actually bind the timeline to its own scroller
  flackr: Okay so I misunderstood, 'ancestor' is the name lookup
  flackr: Yeah I proposed something similar earlier
  flackr: So two, we haven't explored this idea too far yet, to see if
          there's a need for it
  flackr: I guess it solves every use-case since you can do global
  flackr: but I'm interested to see in practice how often people need
          these other scopes
  flackr: Anyway if we do need this power, I think this is a reasonable
  astearns: Maybe this could be an open issue to put in the next level
            if needed?
  fantasai: Yup
  astearns: unless it would be good to put in the current draft to get
            more eyes on it, and punt if needed later
  fantasai: I defer that judgement to flackr
  flackr: I think we can add this later


Forgiving :has() breaks jQuery when used with a complex :has selector
github: https://github.com/w3c/csswg-drafts/issues/7676

  TabAtkins: I think we've lost enough people that are relevant to this
  emilio: I have an opinion, but...
  emilio: tldr is Chrome shipped :has() with forgiving parsing, because
          jQuery calls querySelector() and if it throws, use their
          custom selector parser
  emilio: I filed an issue a while ago about making @support selector()
          not be forgiving, which lets jQuery do the right thing here,
          but that doesn't fix existing usage
  <emilio> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235773031
  emilio: 1) rename :has(), which isn't great
  emilio: 2) give up on forgiving-selector-list, which also isn't
          great. is()/:where() already shipped with it
  emilio: 2.5) spec the webkit bug, which is unforgiving if *all* of
          the selectors fail
  emilio: 3) leave it; if breakage isn't too big, oh well
  fremy: Another idea is to explicitly check the jquery pseudo classes
         and poison them
  <fantasai> -1 to special-casing jquery
  emilio: There's a lot, plus jquery just has some different parsing
          for the matching stuff of us, too
  fantasai: I'm okay with saying :has() is unforgiving, you can nest an
            :is() if you want
  fantasai: lets authors be strict if they want
  TabAtkins: We're not entirely consistent. :not() is unforgiving, for

  dbaron: Two thoughts, both weak preferences
  dbaron: One is, I have mixed feelings about forgiving-selector-list
  dbaron: Even if the group thinks the old selector parsing is a
          mistake, having two models used in different places is worse
          than having just the bad one
  dbaron: in terms of author confusion
  dbaron: The other proposal is that :is() is different from :has() in
          now two ways
  TabAtkins: You're confusing it with :where. :has() is completely
  dbaron: I'm not a fan of these names
  dbaron: no strong suggestions for what to do about it
  TabAtkins: Regardless of our opinions on :where(), that's not the
             current issue
  dbaron: I do think it compounds the problem though

  fantasai: What if we just restricted forgivingness to :is() and
            :where() and nowhere else. If you really want it you can
            get it, and these two are basically just syntactic sugar
            for expanding things out anyway.
  TabAtkins: If breakage is enough to worry about, and I think it
             might be
  TabAtkins: then that's my preferred solution of all of them
  florian: So if that's the path we go, if you want forgiving-ness, you
           just do :has(:is()) ?
  TabAtkins: Yeah
  TabAtkins: given that some people who know about badness of breakage
             aren't here
  TabAtkins: I suggest we defer this, and say that if breakage is bad
             enough, we go with forgivingness only in :is() and
  TabAtkins: We basically narrow to 2 options here
  astearns: Or switch it to unforgiving regardless
  heycam: How do we decide if it's bad enough?
  TabAtkins: Been awhile since I looked
  iank: I think it was bad enough that we need to make a change
  dbaron: I think the breakage came from jquery's test suite, not real
  dbaron: but not sure
  fantasai: That said, we still have you concerns

  <astearns> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235441907
  astearns: This comment says even if we make it unforgiving, :is() is
            still forgiving so it's a problem
  TabAtkins: I made that comment, and response was that because :is()
             isn't part of jquery, much much less likely to trigger a
  TabAtkins: It relies on code writing new standards-based selectors
             using :is() in old versions of jquery, which while it can
             happen is much less likely than new pages
  TabAtkins: than old pages using jQuery's :has() and breaking due to
             the new standard :has()
  astearns: So collect more info, provisionally conclude that making
            :has() unforgiving may be the path to fix if breakage is

CSS Backgrounds

box-shadow of border-radius: 50% should be an ellipse
github: https://github.com/w3c/csswg-drafts/issues/7103

  dbaron: A few weeks ago Oriol prepared a bunch of demos for this
  dbaron: Underlying issue is that in 2013 we changed the spec so
          expansion of rounded borders, which happens primarily for
          box-shadow spread, was not discontinuous
  dbaron: prior it was discontinuous from 0 to non-zero border-radius
  dbaron: we introduced this cubic formula
  dbaron: So normally a 5px border-radius and 3px of spread means an
          8px spread corner
  dbaron: so they're concentric
  dbaron: nobody shipped it until earlier this year
  dbaron: Chromium got bug reports now about circles expanded to
  dbaron: So we want circles to stay circles
  dbaron: Oriol had proposals, group was unhappy with all of them
  dbaron: Since then I came up with two additional proposals, fantasai
          had a third I attempted to put into Oriol's demo
  dbaron: so we can look at these additional options

  dbaron: So first option is the existing formula
  astearns: Skip to demos, we can go back to math
  <fantasai> ->
  dbaron: This third example is a circle, that's important, and there
          are some other pretty round cases
  dbaron: this is the spec currently, you'll see the circle is no
          longer circle at all, other round examples have flattened ends
  dbaron: My first option is based on the ratio of the rounded part of
          an edge to the total length of the edge, using that as a cap
          on the cubic formula
  dbaron: One puts the cap on before, one after the cubing, so one is
          linear and the other is cubic
  fantasai: In the very last, there's a sharp corner, but it gets quite
            rounded in both of yours
  fantasai: but your other squares aren't particularly rounded
  dbaron: Elika's is capping based on --- using oriol's "% of max axis"
          but not all the time, switches between it and current spec
  fantasai: Each side has a straight and a curved piece. if it's all
            curve, it uses % formula, if it's at least the length of
            the box side it uses the spec formula, and between those it

  dbaron: The other things that's different is I did the capping based
          on the ratio of rounded vs total side length, Elika did ratio
          of rounded to straight part of the side
  dbaron: not sure which is better
  dbaron: but weird thing about Elika's is it requires a max because it
          hits the cap in the middle rather than the end

  astearns: The old spec is super round for the square with 1px round
  fantasai: Yeah, that's why we change the spec
  astearns: Wonder if we'll get people wanting that, though
  fantasai: Depends on what you're trying to do
  fantasai: Goal was to get something continuous
  fantasai: For squarish things I think current spec is better, but for
            circle-ish it's broken

  astearns: Sounds like we need some more options in the demo?

Received on Tuesday, 25 October 2022 23:02:26 UTC