W3C home > Mailing lists > Public > www-style@w3.org > December 2021

[CSSWG] Minutes Telecon 2021-12-15 [mediaqueries] [css-pseudo] [css-conditional] [css-fonts] [css-compositing] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 16 Dec 2021 06:42:17 -0500
Message-ID: <CADhPm3uO8KCMFnf6XyDXyRhmbHg6RGMFP34+OR3q-Am1NpcTqQ@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.

Media Queries

  - RESOLVED: Drop video-width/height/resolution media queries (Issue
              #5044: MediaQueries length units in video-*)
  - RESOLVED: dynamic-range: standard also matches when dynamic-range:
              high matches (Issue #6793: dynamic-range media queries)
  - RESOLVED: Accept change to allow empty functional notations in
              <general-enclosed> (Issue #6803: Allow empty functions in

CSS Pseudo

  - RESOLVED: 'color: currentColor' on a highlight takes the next
              *active* highlight color, so that text is drawn as if
              highlight weren't taking effect (Issue #6818: Highlights
              and color:currentColor)
  - RESOLVED: getComptuedStyle() with a highlight pseudo takes color as
              if that highlight applied and no other highlight applied
              (Issue #6818)
  - RESOLVED: Author origin rules, and not user-origin rules, trigger
              paired cascade fallback (Issue #6386: Clarify
              paired-cascading behavior)
  - There was general agreement that the testcase mentioned in issue
      #6774 (Compat risk for ::selection defaulting one color from
      originating element) should continue to pass, but discussion will
      continue in the issue about the best way to achieve that.


  - RESOLVED: Publish Conditional 3 as CR
  - RESOLVED: Publish a CR of Conditional 4, adding just the selector()
  - RESOLVED: Publish fpwd of Conditional 5 with remaining features
  - RESOLVED: Publish new versions of Fonts 4 and 5
  - RESOLVED: Republish MQ4 and MQ5

CSS Compositing

  - RESOLVED: Add plus-lighter and plus-darker to mix-blend-mode in
              Compositing 2.
  - A request for FPWD of Compositing 2 will be made early next year.

CSS Values

  - RESOLVED: Writing-mode sensitive viewport units (and analogous
              units) use the writing mode of the element they're used
              on. (Issue #6873: Logical viewport units (vi, vb, etc)
              and writing-mode propagation)


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

  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Delan Azabani
  Oriol Brufau
  Tantek Çelik
  Dan Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Brian Kardell
  Jonathan Kew
  Vladimir Levin
  Daniel Libby
  Chris Lilley
  Peter Linss
  Alison Maher
  Manuel Rego Casasnovas
  Morgan Reschenberg
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

Scribe: fantasai
Scribe's scribe: TabAtkins

Media Queries

MediaQueries length units in video-*
  github: https://github.com/w3c/csswg-drafts/issues/5044

  florian: Issue has evolved since opened
  florian: Reminder, we specified video-width/height/resolution
  florian: Video prefix is about video playing that some devices like
           TVs have, where they superimpose a special canvas with
           different characteristics for playing video
  florian: About a year ago we were talking about this and thinking
           that actually, maybe MQ isn't what's wanted
  florian: The typical query of width is about whether bigger or
           smaller than some value
  florian: but not used for that
  florian: Use cases were that people wanted to ask "what is the size
           of the screen, in physical pixels"
  florian: The only way to do via MQ is via binary search in MQ, which
           is not great
  florian: So conclusion of discussion is not to have an MQ, and
           instead have some extension to CSSOM where you can query for
           the pixel ratio of the video playing of the device
  florian: Since can already know size of viewport, can get the size of
           the whole screen
  florian: or if interested in size of an element, can go from the size
           of that element
  florian: So the suggested resolution for MQ is to remove video-width/
           height/resolution MQ
  florian: and another resolution would be for CSSOM to add

  Rossen: Opinions on this?
  smfr: I'm a little concerned about multi-screen systems
  smfr: Window is associated with a single screen
  smfr: if showing video, is it on the same screen/window?
  smfr: idk how to know that
  smfr: imagine you have two screens, right hand is dedicated to video
  smfr: somehow magically when you present video, it shows up on the
  smfr: but window object is associated with the left hand screen
  smfr: so would be weird if it reported characteristics of right hand
  chcunningham: Is this possible today?
  smfr: UA thing, UA could decide to send fullscreen video to a
        particular screen
  florian: I think as far as TVs are concerned, and things with this
           multiplane rendering, it doesn't behave the way you described
  florian: more general browsers/setups, could be other setups
  florian: The window object is probably not designed for that, but
           this is a more generic problem than video specifically
  florian: 2nd Screen effort is trying to deal with that
  florian: but for the TV use case, I don't believe that's how they work

  Rossen: To go one step further, in conjunction with some of the newer
          foldables and dual-screen efforts
  Rossen: I know of at least one effort that is work happening on ???
          that have to do with dividing up the window into multiple
  Rossen: multiple screen divided by segments or hinge
  Rossen: Here we have one window spanning two surfaces
  Rossen: Video having controls on one different screen is very typical
  florian: Does this device have a multiplane rendering thing?
  florian: Typically TVs do this, typical screens don't have two planes
           that can be queried separately
  Rossen: We have one window object that will be present on both
          physical screens
  Rossen: Is expectation that devicePixelRatio returns ...
  florian: I think the question is legit, if you have this multiplane
           thing with two resolutions on one screen, we have this
           problem for the window object in general
  florian: This is a good problem to address if such devices exist, but
           there's nothing specific to video about it
  Rossen: There are some laptops that have a pane over the keyboard, so
          you can present into those
  Rossen: but might be represented by two different screen objects

  fantasai: Don't smfr's concern apply to the regular to the regular
            device pixel ratio as well?
  fantasai: If so, we need to address it there as well
  smfr: devicePixelRatio doesn't have this same issue
  smfr: If I drag window over, devicePixelRatio will change
  fantasai: I understand the concern. We need to address the
            multi-resolutions for devicePR and other API. Adding a
            parallel API for these is what makes most sense.
  smfr: Issue with video one is that video presentation is special, and
        UA chooses that it will be displayed in magic extra plane with
        different properties
  florian: We're not talking about picture in picture or displaying
           window in other places
  florian: but for TVs, they have two framebuffers layered over each
           other in the same spot
  florian: They have the normal layer transparent, punch video through
           to underlying layer
  florian: which has different resolution
  florian: In current devices, this would be on the same screen
  florian: a browser could have two different videos on different
           screens, but that's a very different setup than here
  smfr: I understand, I just don't want us to design a problem for

  florian: Let's just resolve to remove the MQ for now
  florian: and maybe we can open an issue for the deviceVideoPixelRatio
  florian: I don't quite see the problem, because whatever problem
           you're describing seems to apply equally to devicePixelRatio
  Rossen: Anyone from the video group want both resolutions?

  fantasai: smfr, why does your concern apply to deviceVideoPixelRatio
            and not devicePixelRatio?
  smfr: Because it applies to fullscreen, which is more likely to be on
        a different screen
  florian: This isn't necessarily about fullscreen video.
  florian: If you have youtube playing in the middle of your web page,
           you would apply this ratio within the video
  smfr: No, I don't think so, I think it only applies to fullscreen
  Rossen: If presentation spans multiple screens, e.g. projector, very
          different characteristics than PC, wouldn't problem apply to
          that as well?
  florian: And doesn't necessarily apply to fullscreen only, that's up
           to the author
  florian: Yes, youtube or hulu or whatever video service can be played
           fullscreen sometimes
  florian: but might also want to query in normal rendering mode
  florian: and since hardware accelerated, would still go into special
  smfr: Wouldn't be the case in Apple devices
  smfr: I think we should ask experts for feedback
  smfr: I think it would be very confusing for author

  Rossen: Let's go with resolving to drop the MQ
  Rossen: it's clear we need to work more on the rest of the API
  Rossen: Any objections to dropping MQ?
  smfr: I support that

  RESOLVED: Drop video-width/height/resolution media queries

  Rossen: Send rest of conversation back to the issue
  florian: Should I re-title the issue, or file a new one?
  Rossen: New issue might be helpful to have clear slate, but history
          etc. might be useful

dynamic-range media queries
  github: https://github.com/w3c/csswg-drafts/issues/6793

  florian: Had a discussion awhile ago, explored idea that
           dynamic-range was a complicated concept
  florian: because maybe some devices have modes where high dynamic
           range is active or not
  florian: and maybe UA supports for videos, but not CSS, or for images
           but not canvas
  florian: Could say the same thing in theory about other things like
           color depth, but we didn't expose this per element or
  florian: Idea is to clarify and fix the spec to match what Safari is
           currently shipping
  florian: One difference is that we have standard and high as values,
           and want to align this media feature to the same sort of
           behavior we have with color-gamut
  florian: Where the smaller one matches when larger one is matched
  florian: so that modes nest
  florian: so that if more extended values exist in the future,
           compatible with content now
  florian: Wrt querying device or UA
  florian: Text puts more emphasis that needs to be the combination of
           UA and device
  florian: but no particular need to draw attention to that here, since
           true of all MQ
  florian: tldr is spec what Safari does, because that's what we want

  Rossen: Proposal is?
  florian: Currently spec doesn't say that standard and high can match
           simultaneously, it's either-or
  florian: change it that if match high also match standard
  florian: Everything else is editorial
  Rossen: We have other MQ like that
  <smfr> I agree
  <fantasai> +1

  RESOLVED: dynamic-range: standard also matches when dynamic-range:
            high matches

Allow empty functions in <general-enclosed>
  github: https://github.com/w3c/csswg-drafts/issues/6803

  TabAtkins: We had some leftover grammar from a previous change that
             accidentally implied that if you had a <general-enclosed>
             in functional form it had to have something inside the
  TabAtkins: previously could be empty
  TabAtkins: Small change to make the value optional, so that foo()
             would be valid
  <TabAtkins> @media fn() {...}
  <TabAtkins> @media fn(foo) {...}
  TabAtkins: Wanted to make sure this counts as <general-enclosed> with
             unknown value rather than syntax error
  florian: asking for approval because spec is in CR

  RESOLVED: Accept change to allow empty functional notations in

CSS Pseudo

Highlights and color:currentColor
  github: https://github.com/w3c/csswg-drafts/issues/6818

  delan: Started discussing this issue last week, but only got partway
  delan: about special case of setting 'color: currentColor'
  delan: Outside of highlights, it means 'color: inherit'
  delan: for highlights, actually means something else
  delan: There were 2 questions originally, now 3

  delan: 1st question, double-checking, spec says when setting to
         currentColor, do we want to grab color from next highlight
         layer below regardless, or only active highlight layers
  delan: fantasai said it only makes sense to use active highlight
         layer, and I think everyone agrees on that
  florian: I'm a little unsure, agree with that assessment, but
           discussion last time suggested maybe there was a whole
           different way to think about this
  delan: That's the 3rd question, whether this is the right way to
         solve the problem that it solves
  delan: 2nd question is, if it is the next active highlight
         specifically, then what happens when you getComputedStyle?
  delan: getComputedStyle needs to return resolved colors, so has to
         return an actual color
  delan: if you have an element with multiple underlying colors, what
         do you do
  delan: Currently a few ideas on how to address that
  delan: 3rd question, which emilio brought up, this exceptional
         behavior of currentColor for highlights is odd and complicated
  delan: Wondering if this was the right way to solve the problem, or
         if better way to solve the problem
  delan: To clarify, best example of a use case for this, is the
         spelling and grammar error pseudo-elements
  delan: A typical styling for that would be to add a red or green
         squiggly line to the text
  delan: but you're just adding the decoration, you don't want to
         change the color of the text
  delan: If you spell a word, still want to have the same text color
  delan: but given way highlight painting works, if we didn't have this
         rule for currentColor, then there would be no way to highlight
         something without changing the color to 'initial' (black)
  delan: It's complicated and an odd exception, but we need some
         solution to this problem

  florian: One extra bit, suggestion last time is that this might be
           similar to ::first-line
  florian: We don't redefine how currentColor works, we redefine what
           inherits from what
  florian: If you set currentColor on first line, it'll get its color
           from ::first line
  TabAtkins: I'm not certain about best way to handle property itself,
             but for purpose of getComputedStyle I think it's
             reasonable to say "pretend it's not selected at all", so
             just get underlying style
  TabAtkins: That seems the most straightforward, and doesn't leak info
             about spelling/grammar errors
  fantasai: We also have to consider that when you set the - we have
            paired cascading, and it sets to "the color it would have
            already been" it sets the background, so this behavior
            needs to represent that as well

  emilio: Does this really only apply to currentColor? Seems applies to
          inherited properties applied to highlights
  emilio: Maybe color is the only one atm
  emilio: Seems you'd have the same problem with text-fill and other
  emilio: So, in general, I think the right fix would be inheritance,
          but that might be annoying to implement
  delan: Tab, is it true that you mean same thing as emilio, wrt Q2, my
         understanding is that if you ask for getComputedStyle for
         ::selection, we pretend everything is selected and no other
         highlights apply
  TabAtkins: No opinion on pretending selected or pretending not
selected, defer to impl on that question
  TabAtkins: but ignoring any other highlights is the important bit
  delan: Sounds like a straightforward solution to that, I agree

  delan: With regards to Q3, inheritance and possible parallels with
  delan: I'm not that fresh on ::first-line and ::first-letter
  delan: Can someone explain how it would work for us to sometimes
         inherit from another highlight (grab color from ancestor
         highlight) while still inheriting within this inheritance tree
         for ???
  emilio: I think that's the hard part
  emilio: My selection styles inherit from my parent selection styles
  emilio: E.g. selection style inherits from other highlight which
          inherits from regular text which inherits from parent
          selection style
  delan: ...
  delan: ::target-text inherits from ::selection style??
  emilio: whichever order we decide on...
  emilio: For simplicity, say we have ::selection and ::spelling-error
  emilio: Say ::selection inherits from ::spelling-error, and
          ::spelling-error inherits from parent ::spelling-error
  emilio: I think that would get you the right behavior
  fantasai: It would not, because if ::selection inherits from
            ::spelling-error, and that inherits from parent
            ::spelling-error, it'll never inherit from the parent
  emilio: ::spelling-error inherits from ::selection
  fantasai: Why would spelling-error inherit from selection?
  emilio: ::spelling-error inherits from ::selection
  fantasai: That doesn't work
  fantasai: can you give me an example of the zigzag?
  fantasai: there's two pseudos - selection paints over spelling-error
            - what's the inheritance chain?
  delan: So you go in a zigzag, our ::selection inherits from our
         ::spelling error, and our ::spelling-error inherits from our
         parent's ::selection, which inherits from parent's
         ::spelling-error, etc.
  <TabAtkins> child selection -> child spelling error -> parent
              selection -> parent spelling-error
  fantasai: Why would it make sense for ::spelling-error to inherit
            from parent's ::selection?
  emilio: I guess it doesn't quite...
  delan: When you jump back in the zigzag, you have a lower layer
         inheriting from a higher layer
  delan: It's hard for me to imagine this
  fantasai: Imagine spelling was red, selection was blue
  fantasai: you highlight some things
  fantasai: The zigzag means you'll get red text when you highlight, if
            the parent has an spelling error
  fantasai: Seems weird
  <tantek> This (special inheritance across pseudo-elements) seems
           confusing enough to the WG that I can't imagine authors
           actually coming up with a predictive mental model for what
           is going on.
  Rossen: Seems work to do here, need to decide if we are going to
          rethink through inheritance or to tweak existing model

  delan: This is a valid conversation, about solving via other mechanism
  delan: but wondering if we can resolve Q1 and Q2, based on assumption
         that things work the way specified now using currentColor
  delan: and later if we want to solve a different way, we can do that?
  Rossen: Makes sense to me

  <dbaron> I *think* one of the goals here is that which of
           grammar-error/spelling-error/target-text/selection's styles
           wins does *not* depend on which elements are associated with
           the selectors (and how they nest), but rather on a
           spec-defined order of the pseudos.

  florian: I support doing this. Earlier Tab suggested that you put
           either everything selected or nothing is, suggest assuming
           everything because otherwise no point in querying ::selection
  delan: I thought question was between nothing or pretending that just
         the pseudo you asked for
  florian: That's the one
  florian: Answering that just the pseudo you asked for is everywhere
           and nothing else
  florian: It's not useful to assume no highlights at all
  emilio: I think that's the current behavior
  emilio: I'm moderately sure that querying ::selection will get you
          the ::selection styles
  delan: Pretending everything else not selected also solves, what
         happens if ::selection leaks a color from ::spelling-error or
         ::grammar-error, which we made it forbidden for privacy
         reasons so this solves that problem
  emilio: It's also simpler, fixes privacy leak
  florian: Alternative we mentioned last time was to fragment things,
           and answer question about first one, but overkill for no
           good reason
  delan: Don't think anyone needs that answer
  florian: If we really needed that answer, we'd need an API to reply
           on each individual fragment
  delan: For Q1, proposing that we say that when you say
         'color: currentColor' on a highlight pseudo, you grab the next
         active highlight's color
  delan: so that color is as if this highlight wasn't applying
  emilio: ...
  fantasai: currentColor computes to itself
  emilio: except in 'color' property
  emilio: I'll double-check
  emilio: Anyway, seems fine

  RESOLVED: 'color: currentColor' on a highlight takes the next
            *active* highlight color, so that text is drawn as if
            highlight weren't taking effect

  delan: For Q2, when you call getComputedStyle() with a highlight
         pseudo, the color of the result should behave as if the pseudo
         you passed in is highlighted, but all other highlight pseudos
         are not highlighting
  delan: we pretend
  <florian> +1

  RESOLVED: getComptuedStyle() with a highlight pseudo takes color as
            if that highlight applied and no other highlight applied

  Rossen: we'll take Q3 back to the issue

  <br until="??:12">

  <emilio> fantasai everyone implements `color: currentColor` like I
           mentioned, actually computing it to a non-currentColor value
  <fantasai> do you mean for inheritance or getComputedStyle?
  <emilio> fantasai I mean in the actual computed stage, not resolved
  <fantasai> that gives bad results on inherited properties other than
             color, and we had clear resolutions to not do that
  <emilio> fantasai yeah, only `color` does this
  <fantasai> oh, I see
  <emilio> otherwise you'd need to do a whole style tree walk to
           resolve all colors, which is not something you want to do

Clarify paired-cascading behavior
  github: https://github.com/w3c/csswg-drafts/issues/6386

  delan: For compat reasons, highlights have a "paired cascade", at
         least for ::selection (but we decided to apply to all)
  delan: For background-color and color
  delan: if you have some browser default colors for ::selection, e.g.
         white on blue
  delan: if you then go and set one of those two properties, then both
         of the defaults get suppressed
  <delan> ::selection { background: yellow; }
  delan: defaulting to their initial value
  delan: e.g. if you set selection's background to yellow, then the
         default foreground color at used value time is no longer going
         to be white
  delan: This issue was pretty big, I asked 7 questions about it in the
  delan: Pretty much none of the questions have disagreement in the

  delan: The main open question is, which origins should this apply to?
  delan: Original spec text says that when author sets one of these two
         properties, then we suppress highlight color
  delan: but there's also animation and transition origins, and also
         user origin
  delan: Will talk about animation and transition first
  delan: I think it doesn't matter whether animation or transition is
         included in this rule or not
  delan: We used to think it mattered for consistency with
         'appearance', but I realized it doesn't matter because the
         animation and transition properties are not applicable for
  delan: So as far as I'm aware, can't use them in highlights
  emilio: I think ?? you should be able to
  emilio: Don't know if properly supported, though

  dholbert: Can a property that is inherited be animated or
  delan: Wondering if it is allowed by the spec right now
  delan: If not allowed, then doesn't matter whether those origins
         included in this rule
  delan: at least until they become allowed
  florian: I believe delan is right, not part of the list of allowed
  delan: No way for some way for them to sneak in, despite not being
         applicable properties?
  florian: I don't think we designed one
  emilio: if animate color of parent, and it inherits through?
  fantasai: That wouldn't be in the animation or transition origin on
            the highlight itself
  delan: If not possible to come into highlight overlay, and it doesn't
  florian: I think we should talk some other day whether they should,
           but until they do...

  delan: For the user origin, I did some playing around with user style
  delan: As far as I can tell, the question here about user origin and
         paired cascade comes down to
  delan: if the user sets one of the two properties (bg color or color)
         in their user style sheet
  delan: do we want that to suppress the UA default for the other
         property or do we want it to not suppress it and leave the
         other property as UA-default
  florian: Can implementations guide us? This rule was just for compat
  emilio: I don't think there's any compat requirements on user origin
  emilio: User origins don't disable appearance, so let's follow that
  fantasai: My reading is that we really don't care, so we should do
            whatever is easiest
  delan: Works out
  delan: Even if you go with compat angle, it doesn't suppress default
         UA colors in Firefox
  Rossen: Other opinions?

  RESOLVED: Author origin rules, and not user-origin rules, trigger
            paired cascade fallback

  delan: In the issue, we all agree on the other 7 questions
  delan: Do we need resolutions?
  fantasai: IIRC they're minor enough that I'd close them under Editor

Compat risk for ::selection defaulting one color from originating
  github: https://github.com/w3c/csswg-drafts/issues/6774

  <delan> https://github.com/w3c/csswg-drafts/issues/2474
  delan: The highlight inheritance and cascade in the spec is a pretty
         big change compared to processing model in implementations
         right now
  delan: Previously our position was that we consider the compat risk
         of this big change to be acceptable
  delan: because the old model that exists in old browsers is kind of
         useless and broken
  delan: The styles don't inherit so you have the set them everywhere,
         unless writing a really awkward selector
  delan: While implementing in Blink, we found a WPT that broke as a
         result of turning on highlight inheritance
  delan: Unclear if aware of that breakage, are we still happy with the
         compat risk?
  <delan> span { background-color: red; color: fuchsia; }
  <delan> span::selection { background-color: green; }
  delan: What the test did is essentially it has the originating
         element with colors of fuchsia on red
  delan: There's a selection rule that just sets a green background
  delan: paired cascade from earlier means that because one of the two
         highlight properties
  delan: There is no UA default for 'color', so we use whatever color
         we get normally
  delan: Existing model in browsers has ::selection inherit styles from
         originating element
  delan: so test expects color to be fuchsia
  delan: but now the test fails
  delan: because under new rules, we don't inherit color, it's black

  fantasai: I think the test is correct, actually, and paired cascading
            is also correct
  fantasai: Inheriting all the way up, should get currentColor, not
  fantasai: though I'm not sure the spec is clear about that
  emilio: Goes back to currentColor discussion
  emilio: All implementations resolve 'color: currentColor' to an
          actual color
  emilio: so I think we need to solve the problem of 'initial' and
          'currentColor' being different
  emilio: and we need a resolved color
  emilio: I think the computed value is wrong, and it uses a computed
  emilio: Nobody implements that, it has terrible perf implications

  florian: Delan, can you point out to which bit of the spec made you
           think that you would go to black rather than originating
  florian: Wondering if it's ambiguous or wrong
  delan: ... value found by inheritance ... do we say what happens when
         we get to the top?
  delan: I don't think it says what to do if you get all the way to the
  delan: was it wrong to assume it would work the same way as in the
         the normal tree?
  emilio: I think the spec is right
  emilio: but if everything worked by spec, color is initial which is
          currentColor and it would work
  emilio: but that's not how it works right now
  delan: So we'd change spec so that for highlights, we get to root,
         and have a value we get essentially what currentColor does now
  emilio: Per spec should get currentColor as computed value
  emilio: so I think the spec for the color property is wrong
  delan: If we did that for all properties ...
  emilio: I think the only issue is with the color property
  emilio: All current impls store as computed color
  emilio: Otherwise need to go figure it out every time resolving a
          color for a given style
  emilio: I think the spec doesn't reflect that
  emilio: Didn't make a difference until now, that we want currentColor
          to behave specially

  Rossen: So do we need to move this discussion back to GH?
  delan: I suppose these questions are useful and interesting, but I'm
         not sure they necessarily change the original question, which
         was do we still want to move to new cascading and inheritance
  emilio: I think we want the testcase to continue to pass
  emilio: Depending on how we resolve the issue
  delan: So can take to GH
  emilio: This seems complex enough discussion
  emilio: per spec everything works magically and it's great
  emilio: but I don't think that's reasonable
  emilio: so we should figure out the solution that works as we want
  delan: ok sounds good

  Scribe: TabAtkins
  Topic: Publications

Conditionals publication

  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2021OctDec/0116.html
  fantasai: I wanna publish another level 3 CR. A couple of minor fixes
            we'd agreed to.
  fantasai: Very close to REC, just a few bugs in impls, and one
            interop issue to review.
  fantasai: So first ask for repub as CR
  Rossen: Objections?

  RESOLVED: Publish Conditionals 3 as CR

  fantasai: Next is Conditionals 4, published as fpwd in march 2020
  fantasai: Only contains new selector() function, been shipping in
            browsers for a while.
  fantasai: We resolved to add a bunch of features to conditional, but
            since this feature is CR-ready, I propose we defer the rest
            and take this to CR.
  TabAtkins: If this is CR-ready, why not fold into 3?
  fantasai: 3 is Rec-ready, it'll pull us back
  chris: Agree, this sounds like a good plan
  Rossen: Opinions or objections?

  RESOLVED: Publish a CR of Conditional 4, adding just the selector()

  fantasai: For level 5 we proposed font-format(), font-tech(), @when,
  fantasai: Propose we publish as fpwd
  chris: So this seems easy since it's basically copying the current 4
         ED and changing it to 5
  Rossen: objections?

  RESOLVED: Publish fpwd of Conditional 5 with remaining features


  chris: Fonts 4 and 5 have new bits, like tech()
  chris: I wanted to make sure Conditional 5 and Fonts get published
         together, since the font stuff links between each other
  Rossen: Opinions?

  RESOLVED: Publish new versions of Fonts 4 and 5

Media Queries

  florian: Neither MQ 4 nor 5 are free of issues, but the EDs are ahead
           of the TR copies, and I don't think there's issues with
           what's in there right now. More to do, but nothing
  florian: level 4 will be CRD, level 5 will be WD
  Rossen: Objections?
  <fantasai> +1 to republishing

  RESOLVED: Republish MQ4 and MQ5


Add lighter composite operator to mix-blend-mode
  github: https://github.com/w3c/fxtf-drafts/issues/445

  vmpstr: We'd like to add a plus-lighter to mix-blend-mode, and smfr
          says WebKit already supports plus-lighter and plus-darker
  vmpstr: They're comp operations, not blend, so they'd work in the
          same way that canvas works, where if you set a blend mode the
          comp op is src-over; if you set a comp op the blend mode is
  smfr: Issue says lighter, but you're asking for plus-lighter?
  vmpstr: I think the difference is just whether the color is clamped
          to 1
  vmpstr: Okay for our use-case either way
  smfr: Preferable to me, because our graphics framework doesn't
        support lighter. plus-lighter is fine
  vmpstr: That's fine for us, yes.
  chris: Good to see the alignment between CSS and Canvas as well.

  chris: This'll be in Compositing 2? Have we had FPWD?
  Rossen: Don't think so
  chris: Okay to request that?
  Rossen: Resolve on this issue first.
  Rossen: Objections to adding plus-lighter and plus-darker?

  RESOLVED: Add plus-lighter and plus-darker to mix-blend-mode in
            Compositing 2.

  fantasai: Might want to give a chance to review, so fpwd next year.
  Rossen: Yeah, let's call for it next year.

CSS Values

Logical viewport units (vi, vb, etc) and writing-mode propagation
  github: https://github.com/w3c/csswg-drafts/issues/6873

  fantasai: Issue was raised to simplify some edge cases around body
            propagation and writing modes and viewport units
  fantasai: Also brought up the question - I think we got the issue
            wrong, as it says to resolve against the root element's
            writing mode, but I think generally you want the element's
            writing mode.
  fantasai: So proposed resolution is to use the element's writing mode
            to resolve vi/vb, rather than the root element.
  TabAtkins: I agree

  smfr: Does that make inheritance complicated?
  fantasai: No, they compute to lengths before inheritance
  florian: Yeah, I think I remember that being what I wanted. If you're
           doing a font-size in viewport units, you want the logical
           axis you're using.
  miriam: Might be confusing with container queries which have to be
          set up to be inline or block
  miriam: So you set up a container with "inline", this might not match
          the container you've established.
  emilio: What do we resolve our units against, the container or the
  fantasai: So this is about the container-relative units.
  emilio: We added a way to resolve against different containers. It
          would be very bad if we resolved relative units against
          different axises for each property.
  emilio: So think we should resolve them against the element's writing
  miriam: So when you use the "cq inline unit" it looks for the nearest
          container with inline containment.
  miriam: Could potentially be confusing if the inline unit doesn't
          resolve against a container declaring "inline"
  TabAtkins: I agree that the potential of inline not matching inline
             is a general problem with mismatched writing modes, and
             agree that within an element you want inline to match what
             that element thinks its inline axis is

  fantasai: So proposed resolution is that viewport units (and
            analogues) use the writing mode of the element they're used
  Rossen: objections?

  RESOLVED: Writing-mode sensitive viewport units (and analogous units)
            use the writing mode of the element they're used on.

  fantasai: Just realized we should probably add Color Adjust to the
            rough interop section of the snapshot.
  Rossen: We'll take it over email.
Received on Thursday, 16 December 2021 11:44:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:19 UTC