[CSSWG] Minutes Telecon 2021-12-08 Part II [css-cascade] [css-fonts] [css-contain] [css-sizing] [css-pseudo]

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

CSS Cascade

  - RESOLVED: FPWD Cascade 6 (Issue #6865: FPWD of Scope)

CSS Fonts

  - RESOLVED: font-tech() and tech() (Issue #6791: Naming

CSS Contain

  - RESOLVED: Accept draft text (Issue #6426: Ancestor Layout Loops
              with Single-Axis Containment)
  - RESOLVED: FPWD Contain 3

CSS Sizing

  - RESOLVED: Use HTML mechanism (either attributes or meta) to express
              the intrinsic size of the child (Issue #1771: Auto-resize
              iframes based on content)
  - RESOLVED: Add `contain-intrinsic-size: from-element` with a note
              that it needs further discussion on the name (Issue #1771)

CSS Pseudo

  - The group began discussion on what should be returned from
      'getComputedStyle(element, "::selection").color' (Issue #6818:
      highlights and color:currentColor) and the value of simplicity vs
      special casing. Time on the call ran out so discussion will
      continue on issue #6818 next week.


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

Scribe: fantasai

CSS Cascade

FPWD of Scope
  github: https://github.com/w3c/csswg-drafts/issues/6865

  miriam: Brought a scope proposal a few times
  miriam: Last time I brought it up for FPWD, fantasai wanted to review
          with me
  miriam: We spent some time in September, and published ED with some
  miriam: We're both happy with the rough direction, still a lot more
          to do
  miriam: but wanted to get to FPWD and work on it from there
  astearns: any concerns about taking on as FPWD?
  <TabAtkins> +1

  RESOLVED: FPWD Cascade 6

  <miriam> 🥳

CSS Fonts

Naming font-technology()
  github: https://github.com/w3c/csswg-drafts/issues/6791

  drott: font-technology() supports function, issue created to bikeshed
         the name
  drott: A few comments discussing, no real consensus for any change of
         the name
  drott: So Chris is proposing to go with font-technology() and close
         with no name change
  astearns: There is the suggestion to make it shorter and be
  chris: I'm fine with that, though we do tend to avoid abbreviations
  <lea> To everyone: when considering names, please consider both
        syntaxes: @supports font-technology(); and src: url(foo.ttf)
  fantasai: [reads Lea's comment]
  fantasai: I'm okay with font-tech() and tech()
  fantasai: I think technology is a little too long, and "tech" is a
            well-accepted abbreviation, used as a word already. We
            should shorten it
  fantasai: There's a comment from a Chinese user on the issue saying
            that for non-native English speakers, the shorter "tech" is
  <drott> no objections from me
  astearns: proposed resolution is to go with font-tech() and tech()
  astearns: any objections?
  <lea> no objection
  <jensimmons> tech is better than technology — and is a word in it's
               own right, not just an abbreviation

  RESOLVED: font-tech() and tech()

  astearns: publications?
  chris: was planning to ask for publication next week of fonts 4 /
         conditional 4
  fantasai: wanted to split conditional 4 actually, existing feature
            should be in CR (REC possibly)

CSS Contain

Ancestor Layout Loops with Single-Axis Containment
  github: https://github.com/w3c/csswg-drafts/issues/6426

  miriam: This has been the main blocking issue for Container Queries
  miriam: defining exactly how single-axis containment should work
  miriam: I think at this point narrowing that down to the [audio cut]
  miriam: inline axis
  miriam: Potential worried about changes to block size impacting
          available inline size, creating a loop
  miriam: iank proposed that these are not new issues, and we have
          existing solutions in CSS, and showed that some of these
          problems already exist
  miriam: We wrote a draft spec

  florian: dbaron reviewed earlier version, did he re-review the
           updated version?
  dbaron: Don't hold up on me
  dbaron: I'll get to it
  <chrishtr> (the updated version is basically the same as the previous
  florian: As far as I'm concerned, if dbaron's OK with it OK with me

  astearns: So are we proposing to resolve on the draft text?
  miriam: yes
  fantasai: And also to publish FPWD
  astearns: Anyone with concerns about resolving to accept the draft
  astearns: Anyone need more time to review?

  RESOLVED: Accept draft text


  astearns: Since this was the last big issue that we wanted to solve
            before FPWD, next is proposed FPWD of CSS Contain 3
  <fantasai> +1
  jensimmons: +1 to FPWD, keep seeing situations where not having a WD
              of this spec is creating problems
  <chrishtr> +1
  astearns: anyone with the opposite view?
  florian: I was pushing back against this one until this issue was
           addressed, because unclear if we should publish FPWD without
           it, but with that cleared I'm good now

  RESOLVED: FPWD Contain 3

  <miriam> 🥳

  <jensimmons> yay miriam and everyone who worked on it!
  <chrishtr> congratulations everyone, especially miriam!
  <chrishtr> This is an awesome feature, and a huge milestone for the
  <astearns> +1, very happy to get into FPWD

  <br until="??:07">

CSS Sizing
  scribe: emilio

Auto-resize iframes based on content
  github: https://github.com/w3c/csswg-drafts/issues/1771

  <Domenic> https://github.com/domenic/cooperatively-sized-iframes
  Domenic: This is a widely-desired feature for devs, I've worked with
           tab, iank and chrishtr on how a solution could look like
  Domenic: I've got the explainer (^) but basically content inside
           iframe requests content size, and the page can use css to
           decide to honor it
  Domenic: which resizes the iframe element and in turn the viewport in
           the inner iframe and so on
  Domenic: You can restrict it to honor only height / width, or using
           max/min-width to constraint
  Domenic: There's also some discussion to try avoiding shifts
  Domenic: What devs really want is auto-sizing
  Domenic: and the iframe will auto-resize its content
  Domenic: We were not able to figure out how to best do this
  Domenic: Biggest problem is resize loops
  Domenic: Like 100vh inside the iframe which would change the element
           size, which would change the viewport, etc...
  Domenic: so MVP is just allowing devs to request exact sizes
  Domenic: There's also some ideas about snapshotting stuff at the load
  Domenic: or special layout modes that make vh behave differently to
           avoid the loops
  Domenic: but the discussions about it are on the issue tracker
  Domenic: There's some discussion of the alternatives and so on
  Domenic: I think from the CSSWG we should get some expertise...
           Should the sizes be communicated via css? should we use
           contain-intrinsic-size to opt-into this from the iframe?
  <bkardell> is there something here we could borrow from how image
             sizing works maybe?
  <bkardell> like, you could set px values or fit-like things?
  <bkardell> feels like those two options would cover most kinds of
             cases I can think of

  chrishtr: It seems the main thing we should focus on is the mechanism
            for communicating the intrinsic sizing
  chrishtr: so the specific proposal is that it'd be a keyword on the
            `contain-intrinsic-size` property
  <Domenic> `contain-intrinsic-size: from-element 500px 500px`where
             500px 500px is the initial/fallback size
  chrishtr: I think that one makes sense
  chrishtr: The other bit is whether on the child we should use a css
            property vs. attributes
  chrishtr: and whether it could be `contain-intrinsic-size` or other

  scribe: fantasai

  emilio: Wanted to ask why is 'contain-intrinsic-size' the right
          property for this
  emilio: I thought it mostly only worked on contained stuff
  emilio: It communicates a size, but...
  iank: It could work a lot of different ways, but
        contain-intrinsic-size allows ...
  iank: It's the mechanism at the moment that we have for changing the
        intrinsic size of an element
  iank: Did you have something else in mind?
  emilio: I wasn't aware of that overriding replaced element intrinsic
          size already
  iank: If you set contain-intrinsic-size: 100px 100px on an image
        element, it will override the image's size
  iank: we could explore a different mechanism, but as a first shot
        seems reasonable
  emilio: With this proposal, would you need to use 'contain: size' on
          the iframe?
  iank: I believe that is true
  iank: I may be wrong
  iank: Other nice thing about this is that it provides a fallback size
  iank: if you can't get that size, it'll back
  emilio: OK
  emilio: Didn't want to use for something totally unrelated
  <chrishtr> (we could also define replaced elements to be implicitly
  <Domenic> Interesting, I did not know that. I kind of assumed
            replaced elements were size-contained by default.
  <fantasai> Domenic, that might be a reasonable thing to do
  <fantasai> Maybe should be considered
  <Domenic> https://github.com/domenic/cooperatively-sized-iframes/issues/6
            to track updating the explainer
  <Domenic> Oh cool, thanks fantasai

  chrishtr: probably not right? Otherwise you break intrinsic-sizing of
            images by default
  astearns: Borrow something from image sizing, e.g. setting px values
            or fit-like things?

 scribe: emilio
 scribe's scribe: fantasai

  iank: like to get letterboxing?
  <bkardell> yes right iank
  iank: We've discussed this previously
  iank: there's an argument to be made about object-fit applying to
  iank: but I think that's orthogonal to this issue
  Domenic: It's orthogonal in the sense that the size would be used as
           the viewport but on the parent document it'd be letterboxed
  iank: There's another issue about an iframe not wanting to change
        size but not wanting to overflow either but it's orthogonal to
  Domenic: I think it layers well with this proposal
  astearns: Is there an issue already on object-fit for iframes? if not
            may be worth filing one bkardell

  florian: So contain-intrinsic-size is conditional on contain:size but
           afaict that's a no-op on `<iframe>`
  florian: Should we add it by default on a UA sheet?
  <Domenic> +1 if possible
  iank: I'd have to try the existing behavior
  florian: Spec says contain-intrinsic-size applies to elements with
           size containment so it doesn't kick in automatically
  iank: Right, so adding it to iframes in the ua sheet might make stuff
        suddenly kick in
  iank: I need to refresh my memory on how iframe intrinsic sizing works
  iank: because if we make contain:size by default on element we might
        stop respecting width/height
  florian: I suspect it would work but there might be a reason it
  iank: Makes sense

  chrishtr: So sounds like contain-intrinsic-size is fine but need to
            make sure ergonomics are fine
  chrishtr: What about the child document sizes?
  <dholbert> We'd need to be sure this is well-defined for <iframe
             style="contain:initial"> (presumably then
             contain-intrinsic-size would be ignored?)
  <dholbert> (Even in the presence of UA stylesheet `contain:size`
             defaults for iframe)
  Domenic: Currently from the outside you can do this by combining
           max-width / height with 'contain-intrinsic-size:
  Domenic: with the current proposal that's not really possible from
           the child iframe
  Domenic: It'd be nice to allow doing this for the child, and I feel
           CSS has a lot more tools
  iank: The initial reaction I had about css vs. attribute is that this
        only applies to one element (the `<html>` element)
  iank: there are already some things we use the CSS parser for on
  iank: the min() / max() functions can't have 'auto'
  iank: so we'd need separate syntax
  smfr: Is this about the iframe content expressing its desired for
        sizing on a given range?
  iank: Yeah, so the iframe would say "size me as 500x500" but the
        additional layer on top would be something like...
  iank: This is more interesting on the snapshotting approach where
        it'd read the offsetHeight/offsetWidth of the document
  iank: and the additional layer would be to limit that size
  iank: so not go below 100px or above 1000px
  iank: Not so useful when we set a single size but it's more useful
        when setting multiple
  iank: So you'd send a message to the parent and so on...
  <Domenic> The additional layer on top would be something like: "if
            the parent is currently set to anything between 400px-600px
            height, then don't resize me. Otherwise, resize me to
  <Domenic> E.g. `min-requested-height: 400px; max-requested-height:
            600px; if-outside-requested-size-range: 432px;`???
  <Domenic> But you could also do `requestedheight="432 if not in 400
            to 600"` or some other new microsyntax... or even just
            three separate HTML attributes.
  smfr: Seems similar to viewport meta tag / @viewport for iframe
  smfr: It's nice if these features could work with JS disabled
  iank: These things are only needed if we go for the one-shot behavior
  smfr: Would that be default or an opt-in?
  iank: It'd be an opt-in, you'd do a 'requested-intrinsic-size: auto'
  iank: can't auto-opt-in
  iank: So on the load event that'd read the scroll width/height and
        send it
  iank: So if you want to add floor/ceil to that how would that work?
  iank: As an html attribute?
  <bkardell> are there popular libraries using some postMessage concept
             to negotiate this already somehow
  <Domenic> bkardell: yes, see
  <bkardell> Domenic thx
  <chrishtr> Yes there are libraries, but it requires postMessage stuff
             and JS on both ends, and there is also the issue of both
             frames having to use the same protocol
  <fantasai> Domenic, I feel like it's unlikely to have "432 unless I'm
             between 400 and 600", seems more likely to request "make
             me between 400 and 600, I prefer 432"
  <fantasai> Domenic: If we did end up creating a microsyntax, might be
             more natural that way
  <Domenic> fantasai: yes, that is exactly right, I phrased it very
            confusingly. Thanks.

  emilio: Has a meta tag been considered? it may be more flexible than
  iank: We'd need to find a new CSS syntax for this anyway because
        min()/max()/clamp() doesn't support auto, so if we go to the
        CSS property we'd need to invent a new syntax anyways
  iank: So for this use-case we'd need to define a new syntax for a
        one-line attribute or property
  Domenic: I was thinking multiple css properties like
  Domenic: though that may be another argument for less properties than
           apply to one element
  <TabAtkins> I'm fine with element-specific CSS properties when
              warranted, fwiw...
  <lea> Is supporting auto in min()/max()/clamp() out of the question?
        That would be very useful in general
  <Domenic> https://developer.mozilla.org/en-US/docs/Web/CSS/@viewport

  fantasai: tantek was wondering whether we'd want to implement a new
            variant of @viewport for this
  iank and fantasai: [explain @viewport]
  <tantek> found it
  <tantek> point being, the problem/use-case is *very* similar to what
           @viewport was trying to solve, so there's at least some
           syntax there that could be re-used
  iank: Could you nest @viewport inside @media?
  iank: That could be bad
  smfr: We deprecated @viewport because making viewport depending on
        CSS loading was pretty bad behavior
  Domenic: You need to allow adjusting it but I agree that meta /
           attributes get the info to the browser as soon as possible
  futhark: You could nest @viewport inside @media but it'd cause a
           circular dependencies so it was specified to resolve against
           the initial viewport when you collected viewport rules

  astearns: It seems there's more consensus towards expressing these
            sizes on HTML rather than CSS
  <tantek> seems reasonable to experiment with attributes in HTML
  smfr: Either attribute or meta tag right?
  astearns: Yeah
  Domenic: Can we read the temperature on that?
  Domenic: Seems like leaning towards meta-tag if we need a micro-syntax
  Domenic: but I don't know how complicated that would end up being
  astearns: I expect we won't have a strong opinion on it...
  emilio: Attributes can trigger restyling, but not if they don't
          trigger changes in styles
  smfr: but you'd have to write code to detect that ...
  Domenic: Can't you write rules against the meta?
  iank: I think we can leave the attributes vs. meta as an open
        question for now
  <TabAtkins> Due to the particulars of HTML, it's not very targetable;
              it shows up in the <head> but you want to style things in
  <TabAtkins> But that is an accidental restriction.

  RESOLVED: Use HTML mechanism (either attributes or meta) to express
            the intrinsic size of the child

  emilio: I'd expect contain-intrinsic-size:from-element to do stuff on
          other replaced elements
  emilio: like undoing what `contain:size` does
  astearns: Putting it into an ED doesn't mean we're fully behind on it
  fantasai: We can add some placeholder-name on it
  chrishtr: what about putting from-element in an ED committing that
            we're not shipping it yet
  fantasai: yeah... please do from-iframe? :-)
  Domenic: what about `<object>` / `<embed>`?
  chrishtr: we can put from-element as a placeholder and bikeshed with
            the editors
  <fantasai> Domenic, intentionally, it's bad and needs renaming
  <tantek> the object element is more interesting because you're also
           styling the fallback content inside
  <Domenic> Not sure if I'm serious about object/embed, I kinda want
            those elements to die in a fire and so starving them of new
            features might be my preference...

  RESOLVED: Add `contain-intrinsic-size: from-element` with a note that
            it needs further discussion on the name

  <Domenic> Thanks all!

CSS Pseudo

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

  delan: Setting color to currentColor is always a special-case, it
         normally means the same thing as `inherit` but for highlights
         we have a new meaning where according to the spec it means
         "the next highlight layered below"
  delan: There's two questions about it, first one is, when we say the
         next below, are we considering just the highlights that
         highlight that piece of text?
  delan: so for example if you have `::target-text { color: red }
         ::selection { color: currentcolor }`, should it always be red?
         Or only if the selected text is also `::target-text`
  fantasai: Only reasonable behavior is the later
  delan: Agreed, it's mostly ok impl-wise except for e.g.
  delan: If you ask for the `getComputedStyle(element,
         "::selection").color`, then what is the color? It could be
         many different colors depending on what you're looking at
  astearns: Maybe return just the keyword in this particular case?
  delan: getComptuedStyle() is explicitly using the resolved value
  delan: which turns it into an actual color

  florian: Do we have precedent for this kind of problem?
  delan: Not aware of it
  florian: We might have a similar problem with fragmentation if you
           allow different fragments to be styled differently
  florian: I believe we have answered that except exceptions we'd
           answer the first one
  florian: I think that means that if the entire selection crosses the
           entire element then that makes sense but then you look at
           the first chunk of the element and answer based on that one
  delan: So answering based on the first highlight for the first
         element or so?
  florian: That seems similar to other questions on the past

  emilio: Right now, getComptuedStyle() with selection does return the
          actual selection colors, regardless of whether anything is
  emilio: would be bad if it involved resolving style of all the layers
  emilio: Also, color: initial and color: currentColor do different
          things here, is weird
  emilio: I'm not sure I agree with behavior of currentColor here,
          would be nice if not so weirdly
  emilio: Do we know reason for currentColor being different here?
  delan: My understanding, the intuitive intent of 'color:
         currentColor' is same for highlights and not-highlights
  delan: it means don't change the color
  delan: But in case of highlight, have a different inheritance tree,
         inheriting from parent's highlight styles
  delan: so it means "don't change the color compared to if you didn't
         highlight with this highlight"
  delan: If selection says currentColor, says use color I would use if
         text was not selected
  delan: but that's not inherit, can't be
  emilio: Maybe selection styles shouldn't ...
  emilio: idk
  emilio: Seems very weird to special case currentColor and bunch of
          other stuff that could be special cased
  delan: Highlights are a lot of special cases. Maybe too many
  emilio: Adding all this complexity, we have a lot of use cases for
          this for this particular way
  emilio: currentColor behaves the same everywhere else
  emilio: Could argue the same for ::first-line and that kind of thing
  emilio: In fact, don't we solve this for ::first-line in some other
          interesting way?
  emilio: If you have a span with 'color :currentColor'
  <emilio> `div { color: green } div::first-line { color: red } span
           { color: currentColor }` then `<div><span>First
  delan: Is it not well-defined for these in the same way, they add
         boxes to the box tree
  delan: There's a well-defined inheritance in the one tree?
  delan: whereas there's a separate inheritance tree for each

  florian: It is well-behaved in browsers, i.e. does the thing delan
  emilio: Making the span inherit from first line, can we make
          selection inherit from whatever special style we're taking
          the color from instead, and there's *an* answer for this?

  astearns: We are out of time, so take this back to the issue
  astearns: Can come back to it next week along with the other pseudo
            issues... though we are going to start with length units
            and video MQ
  astearns: so thanks for putting all these issues up
  astearns: Can you join next week?
  delan: Yes

  <oriol> ::first-line inheritance was discussed in
  <florian> "pick the first fragment" was discussed in

  astearns: out of time
  astearns: so done for this week

Received on Thursday, 9 December 2021 12:13:06 UTC