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

[CSSWG] Minutes Telecon 2022-06-29 [css-images-4] [css-contain] [cssom-view] [css-backgrounds] [css-variables] [css-selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 29 Jun 2022 19:29:01 -0400
Message-ID: <CADhPm3sy-c9rnwB4a-UvkSFnh7eJxFC-jvqq7gzBm4hf5QhtnA@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.

August F2F

  - Reminder to put on the wiki if you're attending, especially if
      planning to be in person

Images 4

  - RESOLVED: Publish new WD of Images 4 (Issue #7043: Long overdue for

CSS Contain

  - RESOLVED: Change initial value of 'container-type' to "normal"
              (Issue #7402: Rename container-type: none to normal)
  - A new issue will be opened to discuss if there should be a blanket
      restriction none/normal/auto in custom idents


  - RESOLVED: Rename to checkVisibility() (Issue #7317: Rename
              Element.isVisible to Element.isHidden?)

CSS Backgrounds

  - Oriol will add specific cases to consider on issue #7103 (The shape
      of box-shadow should be a circle for a box with border-radius:50%
      and big spread) and then the group will take up the conversation
      at the F2F where there's more time to spend.

CSS Variables

  - RESOLVED: Start new draft of variables-2 and add custom units as
              described here (Issue #7379: Custom units as simple
              variable desugaring)


  - masonf will discuss with the OpenUI group if the proposal in issue
      #7319 (Add `:top-layer` pseudo class) should be a pseudo-class or


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0017.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins Bittner
  David Baron
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Mason Freed
  Megan Gardner
  Chris Harrelson
  Brian Kardell
  Brad Kemper
  Jonatha Kew
  Vladimir Levin
  Chris Lilley
  Peter Linss
  Ben Mathwig
  Khushal Sagar
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou

Scribe: fantasai

F2F in August

  astearns: Reminder f2f in about 4 weeks, please put your details into
            the wiki
  <fantasai> https://wiki.csswg.org/planning/nyc-2022
  TabAtkins: It's very important that you let us know if you're
             attending in-person
  TabAtkins: We need to plan for food and stuff
  <lea> Chris and I may not know if we can come until days before :(
  <fantasai> Lea, that's okay. As long as not everyone does that ;)

Images 4
  Scribe: TabAtkins
  Scribe's scribe: fantasai

Long overdue for republishing
  github: https://github.com/w3c/csswg-drafts/issues/7043

  fantasai: I haven't had time to review, but I'm happy to publish for
            now and have any trouble brought up later
  astearns: Objection to publishing WD?

  RESOLVED: Publish new WD of Images 4

CSS Contain

Rename container-type: none to normal
  github: https://github.com/w3c/csswg-drafts/issues/7402

  fantasai: Since we made style containment the default on every
            element, the initial value of container-type is "none".
  fantasai: Was wondering if we wanted to name that as "normal", which
            would possibly let us shut off style containment later if
  fantasai: No strong opinion.
  TabAtkins: I agree that renaming to normal works
  miriam: Agree and also don't have strong opinion

  astearns: In the issue antti said they weren't opposed to the change
  astearns: But I think they were considering the case where we add
            names to style containers
  astearns: So we could put into the issue that we're okay with
            considering it?
  smfr: If there's more context, I can ping antti and get his response
  astearns: My take is that it's not that container-type has nothing to
            do with style containers, it's just that everything is a
            style container, and the only thing container-type *is*
            doing for style-only containers is letting you set a named
            style container.
  astearns: I think antti is thinking we've broken the connection to
            the property entirely
  astearns: Would be good to find out
  astearns: Simon, do you want to ping antti and we resolve next week?
  smfr: Believe he's on vacation so might not get a response by next
  astearns: Alternately we could resolve now and let them bring up an
            objection later if it's still there?
  smfr: I think I'd prefer that this issue have enough context that
        antti can read it and be sure he understands the issue
  smfr: But with that, I think I'm okay with resolving and letting him
        bring up an issue

  fantasai: The two reasons are: 1) because style is a type of
            container, saying "none" is disingenuous
  fantasai: 2) we might want a way to turn off style container on an
            element, and using "none no-style" is somewhat awkward.
            "normal no-style" is more neutral
  fantasai: We're also not allowed to use container-names of "none" and
            we should keep that restriction, and also exclude "normal".

  astearns: So proposed resolution is to change container-type's
            initial value to "normal" ,but still resolve "none" as a
            future value
  <fantasai> +1
  ntim: How about 'auto' instead of 'normal'?
  fantasai: Could work, but 'auto' usually implies more magic
  astearns: I slightly prefer normal over auto, but no great argument
            either way
  <TabAtkins> I'm lightly for "normal" for the reason fantasai gave
  ntim: No strong preference, just a thought
  astearns: So any objections to normal?

  RESOLVED: Change initial value of 'container-type' to "normal"

  fantasai: Tab suggested in IRC that we just blanket restrict none/
            normal/auto in custom idents and I propose we do that.
  astearns: Makes sense, but do we have those allowed in the past that
            would cause compat issues?
  fantasai: Possible but seems unlikely.
  chrishtr: What does that mean?
  TabAtkins: A custom-ident can never be keyword 'initial'; all global
             keywords are restricted.
  TabAtkins: we'd just add this to the list of keywords
  <lea> +1
  chrishtr: Could it break content?
  TabAtkins: if people are currently using those names, yes
  TabAtkins: but they are very generic, so it seems unlikely
  TabAtkins: but we can check
  astearns: We should open a new issue
  <fantasai> -> https://github.com/w3c/csswg-drafts/issues/7431 for
             custom-ident restriction


Rename Element.isVisible to Element.isHidden?
  github: https://github.com/w3c/csswg-drafts/issues/7317

  chrishtr: I think we're ready for the name. We had a vote up for the
            last week
  <vmpstr> +1
  chrishtr: 9 votes for checkVisibility() and only a few on anything
            else, suggest we resolve on that
  astearns: Small number of votes but it was the clear winner

  bkardell: Don't want to block, but all feel like less-bad rather than
  bkardell: I gave some ideas in the thread but it doesn't seem to have
            gone anywhere
  bkardell: Seems worth to take at least one more beat to be sure we
            consider that
  astearns: That said, we've gone over this several times and solicited
            better names several times
  astearns: Your suggestions in particular I'm not fond of due to
  astearns: Would think we'd've found a better term in the previous
            discussions if one existed

  bramus: If checkVisibility() is the name, what does it return?
  chrishtr: Still true/false, true if visible

  fantasai: Agree with bkardell that this name isn't amazing, but think
            it's the best we have, and it doesn't have quite as much
            confusing downside as isVisible/Hidden. Fine with going for
            it since we don't have a better option and it's not too
            overloaded of a term.
  astearns: Suppose we could resolve this as "best of everything we
            have so far", leaving it open for new suggestions but
            closing it to all the ones we've considered.
  chrishtr: I think we can just resolve.
  <TabAtkins> +1 to just resolving, fine with this name
  florian: Also not huge fan of the name but found others problematic.
  florian: This one might not be lovely but it doesn't cause problems
  astearns: brian did you want to block?
  bkardell: Do not, it just didn't get much discussion.
  bkardell: Like you said, we need to make progress. If people think we
            won't do better, I support that.
  astearns: So proposed resolution is checkVisibility()

  RESOLVED: Rename to checkVisibility()

CSS Backgrounds

The shape of box-shadow should be a circle for a box with
    border-radius:50% and big spread
  github: https://github.com/w3c/csswg-drafts/issues/7103

  oriol: When you specify border-radius, the length is the corner
         radius of the outer border edge
  oriol: For inner edge we subtract the border width from that
  oriol: Spread is the opposite
  oriol: Initial value of spread is 0 tho, so this would make an
         elliptical border radius have corners
  oriol: Firefox has special case for spread radius of 0, keeping it
         sharp. But 0.1 makes rounded corners
  oriol: Suggest adding a correction term that gives sharp corners at 0
         and continuously transforms to round.
  oriol: So the issue: if you say border-radius:50% you get an ellipse.
  oriol: If you have a shadow you probably also expect it will be an
  oriol: Blink changed impl to match the spec, and people complained
         their shadows were no longer circles.
  oriol: Proposal in the issue is, instead of adding the spread
         distance and subtracting a correction term, we could express
         the border-radius as a % and then, for the shadow, we use the
         same % but resolved agaisnt the size of the shadow
  oriol: This seems to improve various cases, we have posted images in
         the thread
  oriol: Shadows look better, stay circular
  <astearns> images in this comment:
  oriol: Downside is if you specify a length, and elemnet has circular
         corners, shadow will have circular corners. New change will
         instead make them elliptical if the box isn't square

  oriol: Vlad suggested a variant where we only resolve to a % in one
         axis, then keep the same aspect ratio for the corner
  <vmpstr> it's kind of, sort of like nine-patching the border radius
  <astearns> problem ellipse images in this comment:
  oriol: Problem is if the element is a full ellipse, you won't get an
         ellipse shadow. Circles stay circles but in an ellipse you'll
         get flat edges on the short axis.
  oriol: I proposed another idea - we could say that for the shadow we
         just add spread-distance to the border-radius
  oriol: This would imply that for 0px you'd have rounded corners
  oriol: But we'd also change the initial value for border-radius is
         "none", which would stay sharp. Unsure about compat tho.
  oriol: fantasai proposed interpolating between some radius formulas.
  oriol: Various options, not sure which is best.

  fantasai: Two ideas. One is the problem is largely around circular/
            oval shapes. Many of those are done with %s.
  fantasai: So we could say if the radius is a % we maintain it as a %
            in the spread shape.
  fantasai: Dunno if that really works since the other way to do a
            circle is to do a huge px length and we scale it down.
  fantasai: So it depends on how authors are specifying things.
  fantasai: Another possibility is to interpolate based on how much of
            a straight side we have.
  fantasai: So if the straight side is longer than the radius, we use
            existing formula which is good for rectangular shapes
  fantasai: If straight side is 0 we use the % formula
  fantasai: And between we can interpolate.

  TabAtkins: I hadn't gone this deep before, I suspect I have opinions,
             but would like to take up at a later call, maybe at F2F
  fantasai: F2F sounds good, can draw stuff
  astearns: Leading up to F2F, we should have a set of things to test
  astearns: We absolutely need to fix the spec
  astearns: I'm not sure that we need to have a fix that is good enough
            for all the edge cases yet
  fantasai: We have a bunch of examples currently, both working and not.
  <TabAtkins> I suspect we might need to address this semantically at
              the border-radius side with a keyword that does ellipse.

  astearns: Can I ask Oriol to list out the cases to consider?
  astearns: Summarizing them in the issue, and people can respond in
            the issue.
  astearns: We'll tag this for F2F and come back to it
  <fantasai> https://drafts.csswg.org/css-backgrounds-3/spread-radius
  fantasai: We also have this which we can update

CSS Variables
  scribe: fantasai
  scribe's scribe: TabAtkins

Custom units as simple variable desugaring
  github: https://github.com/w3c/csswg-drafts/issues/7379

  TabAtkins: A week or two ago Jonathan Neal had a suggestion in
             Twitter, just doing on pre-processor side, about a way to
             finally address custom units
  TabAtkins: where you want to set some length and use multiples of it
  TabAtkins: Used all over design systems, but doing today with
             variables is awkward
  TabAtkins: have to explicitly use a calc and multiply, quite a lot of
             writing for what is ~3ch for pre-defined units
  TabAtkins: Suggestion is to treat custom units just as variables
  TabAtkins: so if have number with --unit, this is a variable reference
  TabAtkins: triggers same stuff, but resolve it into the appropriate
  TabAtkins: so 3--unit would become calc(3 * var(--unit))
  TabAtkins: can set up lengths with @property rule
  TabAtkins: can have some control about whether absolute links are
             resolved as time of use or ?? by setting as <length> or not
  TabAtkins: Seems to solve most problems of custom units
  TabAtkins: but doesn't prevent us from doing something more
             complicated using registration
  TabAtkins: later
  TabAtkins: This allows more readable usage for design systems, not
             complicated on implementation side
  TabAtkins: One of our implementers was looking for implementations
             problems and couldn't find any
  TabAtkins: Thoughts?
  <dbaron> +1, sounds simple and valuable
  <florian> haven't spent much time thinking about it, but seems
            reasonable (and terse)

  astearns: faceless comment that they didn't find it particularly
  astearns: and hides complexity that maybe should be expressed
  faceless: [...]
  faceless: but no objection

  bramus: Would allow ability to polyfill new units as well, e.g.
          define --brm and use your new custom unit code to polyfill it
  bramus: seems really nice
  astearns: For browsers that do not support the new unit, what happens
            when you use the custom property
  bramus: Browser would support the real unit, which you have just made
          your custom unit as an alias, and for browsers that don't
          support it you can give them the fallback
  TabAtkins: If we had ability to do parse-time rejection of declared
             properties... but need JS for that

  miriam: I think this would help solve cases where we would need to
          remove units from a value, e.g. viewport width people want to
          use them in a unitless place like line-height, but this
          wouldn't help with that case, right?
  TabAtkins: Right, that wouldn't help. What you need is the unit math
             in the spec to be implemented.

  jensimmons: I really love this, just wish the -- doesn't need to be
  jensimmons: I do think it would be helpful to get some feedback, can
              think of 2-3 people working on responsive typography be
              good to get their feedback
  jensimmons: they're using mix of absolute and relative sizing in
              setting type sizes etc.
  jensimmons: could be very powerful
  TabAtkins: That's one of the major use cases, so would be great to
             get their feedback
  <lea> I love how general this is, +1 from me too

  astearns: Sounds like this is something we should pursue
  TabAtkins: Where to put it? Variables 1 is fairly mature, so suggest
             starting Variables 2
  astearns: Makes sense to me
  <lea> +1 for variables-2
  <fantasai> +1

  astearns: Proposed resolution is to start variables-2, with this as
            the feature to add
  astearns: Any objections?

  RESOLVED: Start new draft of variables-2 and add custom units as
            described here

  astearns: Let's keep this issue open for a little bit, so Jen you can
            get some additional people to give feedback


Add `:top-layer` pseudo class
  github: https://github.com/w3c/csswg-drafts/issues/7319

  masonf: I've been working on [missed]
  masonf: We resolved to create :modal, for all things that are modal,
          starting with modal dialog
  masonf: Raised this issue for what's the pseudo-class for things in
          the top layer
  masonf: We need this so that pop-up can have different styling/
          animations when it's in the top layer
  masonf: There's a bit of a nuance, when animating in or out, will be
          in top layer but not match the pseudo-class
  masonf: so maybe need a pseudo-class that is more specific
  masonf: but the question is whether to have such a pseudo-class, and
          what should it be called
  masonf: An alternative is to create a top-layer element in HTML, and
          allow using structural pseudos
  masonf: I'm relatively agnostic, thing any of these can work with
          popup API

  ntim: I'm quite against the :top-layer pseudo-class, as I mentioned
        in the issue, I think it doesn't speak to what developers
        generally want
  ntim: For :modal, can describe what :modal is
  ntim: But for :top-layer, can't really describe top-layer, doesn't
        really speak to developer perspective, more of implementer
  ntim: I think ?? helps a bit more, but concept of top layer itself is
        very specific to browser engine worldview
  ntim: I don't think it should exist in the current proposed way
  ntim: It's also hard to describe what's the relation with the popup
  ntim: Why open popup in the top layer ... it's not straightforward
        for developers
  masonf: You said you're against the whole thing, but your complaint
          seems to be about the name, is your complaint the name or the
  ntim: It's the name, but
  ntim: the concept itself is also a hack
  ntim: it's a hack by itself
  masonf: Can you clarify?
  masonf: top-layer is well-defined for fullscreen and modal, how is it
          a hack?
  ntim: In a way it's a well-defined concept, sure, but it only exists
        because there's no way to display everything on top with z-index
  ntim: that's the only reason it exists
  ntim: it's a hack in that sense, it's a concept that only exists for
        a certain thing

  dbaron: Is your objection that you'd rather see separate
          pseudo-classes for things that put things in the top layer,
          if there's need for those pseudo-classes?
  ntim: yes
  astearns: We've had discussion about scoping things to particular UI
            elements, and wanting to prefer more generic pseudos
  ntim: If you want generic pseudo-classes, I think something that
        speaks more to web developers, something like :open vs
  ntim: Idk
  masonf: Open is also very very overloaded, and can be confusing
  masonf: top-layer is very descriptive, it's either in the top layer
          or not
  masonf: Agree it's a hack to get around z-index, but it's
          well-defined whether it's in top layer or not
  masonf: Could also create something specific like :open-popup, but if
          we want to be more generic ...

  chrishtr: Following pattern of :modal class, we want to describe
            well-defined behaviors, what is the underlying UI state
            that this is matching against?
  chrishtr: In :modal, it's the modalness, can't interact with other
  chrishtr: just need to come up with other names
  chrishtr: Maybe make specific to the element?

  astearns: It's a push me pull you
  astearns: making something generic to the property that we're trying
            to select
  astearns: Works really well until we really need to distinguish
            between the two different things that have this property
            that never want to be styled together
  astearns: unfortunately we go back and forth quite a bit
  chrishtr: If developer wants to do that, they could combine attribute
            selector with pseudo-classes, to distinguish between
            different types of the element in the popup state
  astearns: That's true

  fantasai: Not trying to select the topmost item in the top layer, but
            all of them, right?
  masonf: Yes
  fantasai: So if you have multiple dialogs and a popup in there,
            they're all matched
  masonf: Yeah, they're all in there. Suggestion by bramus for a
          ::top-layer pseudo-element that would let you select the
          top-most one, but as a pseudo-class it gets them all
  <bradk> :nth-layer(n) maybe?
  fantasai: Okay also there was something about animation state and
            popups, making this not match? Not sure what that is about.
  masonf: It's somewhat peripheral, but for popups you can animate it
          to show or hide. There's two stages - it gets put into the
          top layer, and need a way to select when it's being shown,
          and reverse when hidden.
  masonf: Think that's very specific to the popup api
  fantasai: Wouldn't you want to do that with the fullscreen or dialog
            as well?
  masonf: Yeah might be more general. Let's talk about top-layer first
          though, if there's a transitional state we can discuss that
  fantasai: So it sounds like you want to select top-layer and
  masonf: I think it's needed for top layer, but I have heard requests
          for topmost.
  fantasai: Okay. I agree top layer isn't ideal term since it's
            confuse-able with other things, but we can come up with
  fantasai: First question is just whether we want to add the pseudo at
  TabAtkins: I might have raised that
  TabAtkins: Big deal is things that UA puts in top layer, and things
             that CSS puts in top layer, still want to be distinct
  TabAtkins: Need to have a discussion about it
  TabAtkins: it's a complicated issue to get the UI right

  ntim: Are there things CSS can put in the top layer? I think it's
        just APIs like fullscreen right now
  <masonf> https://open-ui.org/components/popup.proposal.alternatives#alternative-css-property

  astearns: We are at time
  astearns: Has OpenUI discussed pseudo-class vs pseudo-element?
  masonf: We resolved on pseudo-class :top-layer
  astearns: What about pseudo-element?
  masonf: Can take it back to Open UI
  astearns: ok, going to close for today, but can bring it back soon
Received on Wednesday, 29 June 2022 23:29:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 29 June 2022 23:29:44 UTC