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

[CSSWG] Minutes Telecon 2022-05-25 [css-text-decor] [css-text] [css-color-5] [css-images-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 May 2022 17:40:19 -0400
Message-ID: <CADhPm3siAuKj21VEWCanvuHmMJFNg8Eyz2TvtSiGLAPkLVZDNw@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

TPAC & Longform Meetings

  - The deadline for TPAC meeting requests is the end of May. Please send
       any preferences for meeting days to the private list.
  - Next week there will be an extended meeting to cover the Selectors
  - There have been some suggestions to have a hybrid in person/remote
       session over the summer. If there is interest please reach out
       to the private list.

Anchor Positioning

  - iank introduced the concept of CSS Anchor Positioning to allow
       positioning elements relative to other elements in the DOM.
  - There were some initial questions and positive feedback. Discussion
       will continue on the private github (
       until the proposal is formally moved into the working group's
       scope. Any substantial changes will also be noted in github
       issue #7282 (Introduce CSS Anchor Positioning).

CSS Text Decor

  - More examples will be added of the current unexpected behavior
      mentioned in issue #7251 (Composition of inset shadows). astearns
      will also do research into if there is already examples we can
      follow in the Adobe products.
  - RESOLVED: Leave text-shadow spread details undefined right now,
              with possibility of specification later after impl
              experience (Issue #7250: Text shadow spread corners)

CSS Text

  - RESOLVED: No change (Issue #7249: Make U+0000 invisible?)
  - Bugs will be filed with the browsers to see if they are willing to
      align to the spec on issue #6542 (text-align: match-parent on the
      root element with direction: rtl doesn't match browsers). If the
      browsers have specific reasons to not conform to the spec the
      group will consider changing the spec.

CSS Color 5 & Images 4

  - The features listed in issue #7310 (Are these features ready to
      ship?) are not ready to ship yet, but there is interest in
      prioritizing them to become ready to ship.


Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0008.html

  Rossen Atanassov
  Tab Atkins Bittner
  David Baron
  Oriol Brufau
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Mason Freed
  Chris Harrelson
  Daniel Holbert
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Ian Kilpatrick
  Daniel Libby
  Peter Linss
  Alison Maher
  Ben Mathwig
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

Scribe: TabAtkins

TPAC & Longform Meetings

  astearns: Administrivia, need to decide what times we're going to
            meet for TPAC
  astearns: Two options on the private list
  astearns: Have to give the meeting organizers a preference by end of
  astearns: If I don't hear strong opinions we'll probably default to
            our standard, two long days Mon-Tue
  astearns: If any prefs or other suggestions, please respond on the

  astearns: Second, our agenda is getting long again
  astearns: A bunch of interrelated issues in Selectors 4 that have
            been tagged
  astearns: Should probably have a breakout session on those issues,
            there's enough to fill a meeting
  astearns: I suggest next week we have the normal time meeting, and
            also have a Selectors 4 meeting at the European time
  astearns: If anyone has an objection to two meeting in a day, lmk,
            otherwise that's the plan
  <TabAtkins> Sounds good.
  <TabAtkins> I'm available next week, but *not* the week following, if
              timing is adjusted.
  plinss: I'm not available that time next week, and are interested in
          being present
  <plinss> you can do the selectors breakout without me...

  astearns: Third, some people have suggested before TPAC we should
            have a hybrid longform meeting that would include getting a
            few people together in person
  astearns: If anyone's interested in that, we should start a thread on
            the private list and/or the meeting planning pages on the
  astearns: Could probably meet somewhere in NA, anyone interested in
            traveling could meet, but we'd need a venue with very good
            remote capabilities.
  astearns: So if there's interest, let's please talk about it.
  astearns: Any other admin topics, or agenda changes?

Anchor Positioning
  scribe: fantasai

Introduce CSS Anchor Positioning
  github: https://github.com/w3c/csswg-drafts/issues/7282

  iank: Quite a lot of interest in positioning an element relative to
        another element in the DOM
  <astearns> explainer:
  iank: What we're proposing here isn't a new idea, people have had
        variants of this idea for over 10 years
  iank: a post on Tab's blog in 2012, etc.
  <TabAtkins> (the old post: https://www.xanthir.com/blog/b48H0)
  iank: This is basically an extension to absolute and fixed positioning
  iank: in that we can set the inset properties, left/right/top/bottom
  iank: and interpret that relative to another element
  iank: We've got a prototype of this, and found it to be pretty
  iank: you can create popups with this, all sorts of things
  iank: Tab's written up a basic spec for this, with details of how
        application works, how this modifies the abspos/fixedpos scheme
  iank: and how also the rectangles propagate
  iank: Couple of interesting point in that one thing we think is ?? is
        that when you propagate up the positions of the anchor elements
  iank: we think it should roughly follow the same propagation as
        static elements, in that it ignores transforms and ???
  iank: So that you can still have composited text and not affect
        layout (?)
  iank: I think that's roughly it
  TabAtkins: There's a limitation on which elements can be targeted
             with anchor
  iank: Roughly speaking, abspos/fixedpos happens right at the end of
        laying out a container, so you already know where all your
        in-flow children are
  iank: you get some really nice properties if you restrict it to
        elements within that containing block subtree
  iank: [missed]
  iank: When we get to abspos/fixedpos positioning, you can reference
        things that we already know where they are

  iank: The other thing is @position-set
  iank: When you examine the popup/anchor use-cases, necessary to be
        able to say "I don't fit in this position, I'd like to try an
        alternate position"
  iank: So you might want to be on the right of the anchor, but if
        there isn't space I"d like to be below, or the left. That's \
        what @position-set is for
  iank: @position-set lets you specify @try blocks setting top/left
        etc, and if those don't work (cause overflow) we advance to the
        next @try and use those instead.
  TabAtkins: Possibility of exponential explosion in layouts when you
             have chained anchors means we want to impose a strict
             limit on how many @try blocks can be used

  Rossen: Generally I'm favorable to the scenario and the overall
  Rossen: Couple of questions not clear to me, if I heard you right,
          you said that you can anchor yourself to any other element's
  iank: In the containing block subtree that's already being positioned
  iank: abspos/fixedpos has its containing block
  iank: Anything that has already been positioned within that
        containing block subtree
  iank: so you can't reference something further up the DOM
  <astearns> which is an *ancestor* in the containing block subtree
  <TabAtkins> See
for details
  Rossen: This was exactly my question here
  Rossen: and think it's really important in order to prevent some of
          the really circular dependencies
  Rossen: Question is still, is the assumption that such element will
          not contribute to the overall bounds of the containing block
  iank: Right, this will only apply to abspos/fixedpos elements
  iank: So they won't change the containing block size
  <TabAtkins> (but presumably would change scrollable overflow area)
  Rossen: This feature you describe is almost exactly the feature we
          proposed called "position: float" or something like that
  Rossen: except that you're anchoring to elements, not allowing the
          rest of the positioning constructs to apply
  Rossen: My question was answered, you're basically scoping the
          anchoring to the containing block, which makes a lot of sense
  Rossen: Only other question is, you can affect scroll bounds for your
          containing block still, even for those elements?
  iank: Yes
  Rossen: So behave like normal abspos
  iank: Yes
  iank: You're right that you need to make the scrollbars predictable,
        but this isn't a new problem
  Rossen: Not different than if just an abspos
  Rossen: Last bit, are you scoping only to anchoring, or anchoring
          plus... can I say anchor me next to the left border + some
  iank: These anchor queries you can use in a calculation expression
  iank: so you can do calc(this + this)
  iank: We had some fun with our happy prototype, where you could do
        minimum of this anchor's left and this other anchor's left

  smfr: Is there potential for circular references?
  iank: We want to avoid exactly that
  iank: so anchor-positioned things assigned to the same containing
        block can't reference each other
  <iank> https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element
  iank: Tab's got all the rules written down in the spec
  TabAtkins: Very certain not a problem
  <chrishtr> Anchoring can only apply *down* the containing block
             chain, which makes it clear that there are no cycles.
  smfr: Because constrained to something in the containing block, if
        authors want a global ability they'd have to anchor ...?
  iank: Have to use fixedpos or something like that
  TabAtkins: No need to reparent, because fixedpos containing block is
             the ICB
  smfr: ...
  iank: But then there's things where you want it to work more locally
  iank: There's also a proposal which is related to adjusting the
        scroll position
  iank: but that's separate from this

  dholbert: I was wondering, seems like it's ID-based right now, I
            wonder if that could be ... how do you imagine using this
            if you want to have multiple in a single page?
  TabAtkins: Where are you seeing this?
  dholbert: Looking at explainer
  TabAtkins: Ah, MS explainer is earlier draft
  TabAtkins: look at this spec
  TabAtkins: We use the anchor-name property, look for the first thing
             in tree space with that name
  <astearns> ah, I only read the explainer - not the spec yet :)
  dholbert: Okay
  iank: We've got some flexibility in how we do that
  iank: I personally like anchor-name solution
  iank: requirement is reference things within this containing block

  fantasai: Whatever scoping rules we use here we should be consistent
            with scroll animations, which has a similar named
            attachment method
  <fantasai> (and vice versa, they're both early proposals so we switch
             to whatever's the best method for both)

  astearns: Suggest to read the spec and fiddle with details in the spec
  iank: If anyone wants to play with the prototype lmk
  TabAtkins: We anticipate asking for ED soon-ish, not just yet
  TabAtkins: so keep informed
  astearns: I assume there'll be some discussion in your personal repo
            for awhile, but if significant changes or questions raised,
            might be good to update the issue we have on introducing
  astearns: so people can follow along without following your repo
  TabAtkins: Happy to track issues in both repos
  TabAtkins: and move issues later
  fantasai: Why not move it now?
  TabAtkins: No particular reason
  fantasai: better to move now then, your private repo isn't backed up
            by W3C
  astearns: Let's give people time to review

  <TabAtkins> The scoping rules for anchor-name are just "the subtree
              that is allowed to contribute an anchor due to the
              positioning rules", which may or may not match up with
              what scroll animations exactly want

CSS Text Decor 4

Composition of inset shadows
  github: https://github.com/w3c/csswg-drafts/issues/7251

  fantasai: I wanted to ask what we should do with inset shadows -
            what's their stacking order wrt stroke?
  fantasai: Expectation is probably that it's between fill and stroke
  fantasai: But then are we compositing the text decorations with their
            text before shadowing? If so we can't layer shadows between
  fantasai: You'd have to shadow each letter and decoration
            independently to do that

  smfr: Issue says Chrome and Firefox have somewhat surprising
        behavior, so [...missed]
  fantasai: Sebastian said "from author's perspective, expect inset
            between fill and stroke", but outsets should be below both,
            so that would require them to be treated differently.
  fantasai: If you have a semi-transparent shadow on text with spread/
            blur, don't think you'd expect it to be darker where
            letters are near each other - you'd want them to be
            shadowed as a whole. That requires compositing text *then*

  fantasai: We might not have an answer today, just wanted thoughts on
  astearns: If we don't have opinions from the surprising-behavior
            browsers, do we know who to ask? Is there a Blink engineer
            we could talk about?
  emilio: What's webkit behavior?
  fantasai: Less interested in current behavior, want to know what we
            actually want. Changing now isn't going to be a compat
            question, as we don't have inset shadows yet, and the
            behavior changes are subtle for outsets anyway (but real)
  fantasai: So question is what authors want, what's possible to
            implement, and what's the intersection of those two.
  astearns: So I suggest we come up with that definition so impls have
            something to chew on
  astearns: I think you have the outline of possibilities, but not yet
            a firm decision on what authors would prefer
  fantasai: Right, it's just me and sebastian

  smfr: Is there prior art in InDesign or similar?
  astearns: I could go take a look
  astearns: This is not anything I've looked at before tho, not sure if
            Photoshop/etc behavior is necessarily what we want. I'll
            take an action to go look.
  fantasai: Might be interesting to ask people on those teams, who have
            probably thought about it
  smfr: I'd like to see some more artistic examples rendered with
        Chrome and Firefox in the issue, to show the bad behavior more
  astearns: So let's take back to the issue and get more clarity on
            what we want to specify here.
  astearns: And I'll take an action to see if I can divine any intent
            from my company's tooling

Text shadow spread corners
  github: https://github.com/w3c/csswg-drafts/issues/7250

  smfr: Issue here is that when you specify spread on a text shadow,
        the only way UA can implement is by stroking a line with a
        wider width and shadowing the result.
  smfr: That has implications for corners and miters
  smfr: So we need impl experience, need to implement spread on text
        shadow and see if there are any problems, not sure if there are
        right now.
  astearns: I remember we specified increasing the padding of shapes to
            avoid these kind of spikes
  astearns: Do you think having a similar algo for shadows might make
  smfr: Would have to see what that algo is
  smfr: Concern is that the font might be the one to specify the miter
        limit, but I don't think it does
  smfr: If you have a path, maybe the UA can decide the miter limit
        when drawing the path. Just want confirmation that it's

  astearns: Anyone with opinions, or people we shoudl tag?
  <TabAtkins> Without examples of what's up, no opinion here since I
              don't have enough context.
  fantasai: I'm happy to leave it undefined, just want to know what to
            put in the spec.
  astearns: Lacking opinions, think we should leave it undefined
  smfr: Might be okay to specify you get rounded corners. If we find
        it's impossible we can come back to it
  fantasai: Might be opinions on better ways to do it, looking at
            miter-limit prop or whatever.
  fantasai: Think I specced it as rounded corners because, at the time,
            seemed easiest to implement.
  <astearns> shape-margin solution:
  astearns: So maybe see if that's an implementable thing for shadows.
  smfr: Think it might be a little more complex than that description.
        Prefer to have it specified the way impls would do it, which is
        to stroke a path with a wide stroke width and use that edge to
  astearns: I think there was an issue about shape-margin property too;
            if there's a better way to specify we can do it in both
  astearns: I was trying in that section to be slightly vague to not
            restrict the particular algo
  smfr: Briefly playing with it, sometimes in some fonts you'd get a
        hole due to winding rules.
  smfr: Reason for impl experience, fonts have weird data.
  fantasai: So maybe we just make it undefined for now, and can define
            it with more impl experience
  smfr: Fine with that.
  astearns: proposed resolution is to leave it undefined for now, open
            to specifying it with experience later

  RESOLVED: Leave text-shadow spread details undefined right now, with
            possibility of specification later after impl experience

CSS Text

Make U+0000 invisible?
  github: https://github.com/w3c/csswg-drafts/issues/7249

  fantasai: Do we have Myles and jfkthame on the call?
  astearns: Have jfkthame, not Myles
  smfr: Can probably speak for Myles
  astearns: So we had previous resolution to make all the CC characters
  smfr: We had an issue on one Apple website, the text had U+0000 bytes
        in it
  smfr: I'm guessing it's not *that* uncommon to have 0 bytes by
        mistake, due to server bugs? But we'd probably be okay with no
  astearns: So you're suggesting close no change, and continue to
            specify they're displayed?
  smfr: Think that's okay unless we have evidence the problem is more
  emilio: I don't recall seeing issues with this in Nightly/Beta and
          we've had it for a long time
  jfkthame: Also think we should ship it. Do occasionally see
            characters show up in Nightly that are invisible elsewhere,
            but it's rare.
  jfkthame: And in all cases the users are better served by sites
            fixing their broken data

  fantasai: We'd previously discussed doing a coordinated ship of this
            behavior - that was years ago, guess this didn't happen?
  florian: Think we prepped coordinating but didn't pull the trigger.
  florian: Firefox impl'd, Chrome impl'd partially (but leaves it to
           the font to render), Safari didn't impl.
  astearns: But I think we can agree to resolve on this issue.
  astearns: Any objections to no change on rendering of U+0000?

  RESOLVED: No change

  astearns: What can we do to coordinate making this part of the spec
  jfkthame: Think we need Blink to fix impl to not depend on the font's
  astearns: Do we know if there's a blink issue?
  jfkthame: There is, don't have it offhand
  <fantasai> Maybe send that issue link to chrishtr and he can
  <TabAtkins> Yes, chrishtr is the right contact for coordinating this
  astearns: Suggest we find the issue number and post it here, see if
            we can get a response from Blink engineers

  smfr: We might be in a similar situation to Blink where it depends on
        the font, not sure
  smfr: But this seems rare enough that I don't think coordinating
        shipping is necessary, seems hard to do for us in WebKit anyway
  fantasai: I think we should open a separate issue for the coordination
  astearns: So we can close this issue with the resolution we got, and
            continue coordination discussion later on.

text-align: match-parent on the root element with direction: rtl
    doesn't match browsers
  github: https://github.com/w3c/csswg-drafts/issues/6542

  florian: match-parent on text-align does as the name implies, matches
           the parent's alignment
  florian: Different form just inheriting, as the meaning of start and
           end might have switched if the direction switches. With
           match-parent it doesn't flip, it definitely matches the
  florian: So the question is what to do on the root. The spec has an
           answer that I think makes sense, but doesn't have interop.
  florian: But not sure I'm aware of significant real problems
           triggered by this, so if we have a sensible behavior in the
           spec that doesn't cause real issues I think it's okay to
           leave it as-is and consider non-compliance a bug, but
           zcorpan didn't see it that way
  fantasai: zcorpan wanted us to either change the spec to match impls,
            or get a commitment from browser engines that they want to
            fix this bug
  fantasai: My personal take is that this is a very low-priority fix,
            but it should be considered a bug so when someone is fixing
            that area of the code they could fix it too.
  fantasai: Don't think we should require anyone to prioritize fixing
            it. Super low priority, possibly lowest priority I've ever
            seen. But don't think we should change the spec, I think
            the spec is more correct.
  astearns: Assume there's not bugs filed on this?
  florian: Not sure.
  astearns: So part of zcorpan's request is to get bugs filed. I agree
            with him.
  fantasai: I can take an action to make sure bugs are filed.
  astearns: And once bugs are filed, we'll see if we can get evals from
            impls on the bugs themselves.
  astearns: But like fantasai said, don't think a timely fix is
            strictly required for this.

  fantasai: Well is it okay to close the bug, with the understanding
            that we have bugs filed and impls plan to fix it at some
  astearns: Right, let's file the bugs and get to the next part
  emilio: Gecko behavior here is intentional. I'd need to investigate
          why it's a special case, I didn't write the code.
  florian: That's relevant, if browsers have specific reasons for
           differing from the spec it would be good to report so we can
           see if the spec should reflect that. But if it's just
           accidental we should know that too, so we can be confident
           of keeping the current spec.
  astearns: So next step is writing bugs.

CSS Color 5 & Images 4

Color functions and RCS: Are these features ready to ship?
  github: https://github.com/w3c/csswg-drafts/issues/7310

  jensimmons: These are all part of Interop2022, are they ready to
              ship? Are specs good enough, or are they unstable?
  emilio: I'd love to ship some of these, but there's a lot of open
  emilio: I don't think there's any complete impl of these features.
  emilio: WebKit implements a bunch, but doesn't support currentColor
          at all. Gecko also has trouble with currentColor.
  emilio: There's some question about resolution timing that I filed
          last week.
  emilio: So don't think things are quite ready to ship yet.
  jensimmons: So question really is if the spec is gonna significantly
              change after shipping happens.

  jensimmons: I think your issue highlights that some things still need
              to be defined. Maybe we can make this a priority to
              finish the spec?
  emilio: Think that would be great. Haven't been working actively,
          been spending free time on it.
  emilio: I can tell from Firefox usage - we enabled color-mix() in
          trunk and it's used extensively, over a thousand uses
  emilio: So I think it would be great to prioritize.
  astearns: So we're at time, please put your thoughts in that issue.
  astearns: Agree I'd like to see one complete impl before making the
            decision that it's shippable.
  fantasai: Sounds like this isn't ready to ship *yet*, but we should
            try to get it there soon.
  emilio: What I'd love is to avoid interdependencies on these features.
  emilio: weinig commented that they'd prefer color-mix() to serialize
          with new color syntaxes unconditionally; I'm not opposed to
          that, but it requires us to have new colors to ship
          color-mix(). Makes me a little sad because it's more work to
          get this in the hands of authors, but they feel strongly
          about that.
  emilio: It'd be great to work out a way to minimize interdependencies
          so we can ship incrementally.
  <emilio> thanks for bringing this up jensimmons :)

  astearns: Please discuss on the list about the meeting next week.
Received on Wednesday, 25 May 2022 21:41:00 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 25 May 2022 21:41:01 UTC