[CSSWG] Minutes Telecon 2018-11-14 [selectors] [filter-effects] [css-overflow]

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


  - RESOLVED: Rename :matches() to :is() and deprecate :matches() in
              Safari and anywhere else using it (Issue #3258)
  - There is a use counter running to :blank (Issue #1967). The group
      will look at this in ~2 months once there's data. If there's no
      compat risk, Chrome is willing to change.
  - RESOLVED: Add a Sensitive 's' flag (Issue #2101)
  - :valid-within / :invalid-within pseudo-classes may need to move
      into Selectors 5 (Issue #3072).  There's also interest in
      investigating :has-child to see if that solves enough use cases
      to be worth doing.

Filter Effects

  - There was disagreement on where backdrop filter should be able to
      be set (FXTF Issue #53: Backdrop filters should not use
      BackgroundImage). Isolating it would reduce likelihood that this
      is an expensive property to implement, but also reduces the
      potential functionality of the property. Discussion will
      continue in the github issue around potential use cases and this
      will be added to the next APAC agenda when dino can attend.
  - RESOLVED: Publish a new WD of Filter Effects L1

CSS Overflow

  - majidvp is working on trying to implement the propose change in
      issue #2988 ('overflow' 2-value syntax is in wrong order). In
      addition to this specific problem there's a need to address the
      larger issue of logical and physical properties interacting with


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Nov/0016.html

  Rachel Andrew
  Tab Atkins
  Daid Baron
  Emilio Cobos Álvarez
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Thierry Michel
  Michael Miller
  Ian Pouncey
  Florian Rivoal
  Jen Simmons
  Markus Stange
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Tantek Çelik
  Dave Cramer
  Tony Graham
  Nigel Megitt
  François Remy

Scribe: dael

  astearns: Let's get started. We'll skip the first 2 items until we
            have TabAtkins or chrishtr on
  astearns: Is there anybody that would like changes/additions to


Rename :matches() to :is()
  github: https://github.com/w3c/csswg-drafts/issues/3258

  astearns: Added a while back.
  fantasai: One of the side discussions during discussion about
            :where() was maybe :is() is better name than :matches. We
            have :not and the opposite is :matches. It being a clear
            pairing would be useful, especially in contrast with
            :where(). Also to make it shorter.
  fantasai: I filed this as a separate issue. We didn't conclude on
            that tangential discussion. Seems excitement in issue.
  fantasai: We do have Safari shipping :matches() If not that this
            would be obvious to switch. But there is that. What does
            WG think?
  leaverou: Given it's only Safari there's no web compat. Nobody is
            using this. Personally I'd strongly support. :is() is a
            far better name. It makes a lot of sense. It's the logical
            opposite of :not()

  <bkardell> does this mean :where() should be :matches() then?
  <fantasai> no

  astearns: One thing to avoid is having both :matches() and :is() if
            it's something where Safari doesn't feel they can rename
            and have to support both. Both would be a bad result
  smfr: We talked about deprecation path for :matches() previously.
        I'm not sure I'm okay with just switching to :is(). I'm sure
        there will be somewhere using it. But I'm okay with a
        deprecation path for :matches()
  fantasai: Then I propose we rename in spec and Safari sets up a
            deprecation path. Since you're only impl we'll all have to
            impl :is(). We can note :matches() as obsolete and
            browsers don't have to impl. Then Safari removes at point
            it makes sense for them
  fantasai: Given it's not in other impl and we don't have web compat
            clamor to impl matches that seems sensible path
  * leaverou wonders since when is the bar for web compat problems
             "someone, somewhere is using it"?
  astearns: Other concerns?
  Ben: I agree no one is using it now but many people have heard of it
       and there's documentation everywhere. I would piggy back on
       that instead of renaming it

  <bkardell> does it feel unfortunate that we have a dom method called
             .matches() that kinda does what :matches() does and those
             won't have symmetry anymore?
  astearns: bkardell mentioned in IRC there's the DOM method called
  fantasai: Sort of. DOM takes a string. DOM doesn't deal with
            specificity. One of the key distinctions we want and want
            to make obvious is between :where() and this. Calling it
            :matches() doesn't help this distinction. Calling it
            something not matches means it's not paired to DOM.
  fantasai: Using :is pairs it more closely with :not, which has the
            same specificity behavior, in contrast with :where
  chrisl: I agree with rename to :is(). The polyfill argument you can
          do either way where when polyfills change it will change for
  leaverou: The polyfills spit out current CSS so no compat issue
  leaverou: Internal compat within CSS is more important than external
            compat with JS.
  astearns: How one could evaluate is more important. I tend to agree
            with renaming.

  astearns: Not hearing objections against rename. I propose: Rename
            :matches() to :is() and deprecate :matches() in Safari and
            anywhere else using it

  RESOLVED: Rename :matches() to :is() and deprecate :matches() in
            Safari and anywhere else using it

  bkardell: I wanted to get clear in my head- That means we're set on
            :where() for 0 specificity thing.
  fantasai: Yeah. We considered that option and rejected it.
  bkardell: Okay
  astearns: Anything else on this?

Filter Effects

Backdrop filters should not use BackgroundImage
  github: https://github.com/w3c/fxtf-drafts/issues/53

  chrishtr: We talked at TPAC. Advantages of performance and
            implementation simplicity raised
  chrishtr: Also good because consistent with things like
            mix-blend-mode. Objection was mix-blend-mode doesn't
            respect isolation. Turns out that was typo in example
  chrishtr: Reasons we should have BackdropFilter in the isolated
            group are performance, ease of implementation, consistency
            with other modes
  chrishtr: Since TPAC Mason Freed(sp?) has done research in HTTP
            Archive and we couldn't find any site that had an effect
            not easily achievable by parenting BackgroundFilter under
            root stacking context

  smfr: I think when mix-blend-mode was impl I thought it was a
        mistake. Point of backdrop filters you blur everything behind
        your element. Trivial to create test cases where you couldn't
        get the desired effect. Happens to be used like fixed position
        because it's less intense. The effect designers haven't tried
        they can't get. We need to give designers wide scope rather
        then force to fudge with page
  TabAtkins: Agree it's trivial to create test cases, we haven't found
             any realistic cases where we can't achieve without moving
             element within the DOM. It's not just a matter of free
             choice. Lots of more difficult technical issue if allowed
             inside various filters and stacking context.
  TabAtkins: If entire content is blurred, in a blur filter container
             and blur backdrop filter does it have 1 or 2 blurs?
  TabAtkins: Hard question to answer if you can do arbitrary blending
             with whatever is behind you. If it's stacking context
             based it's much simpler
  smfr: Agree there are issues to be resolved if element with
        background filter has other effects.
  smfr: If there aren't anything behind the elements that's not
        ambiguous on order. Impl is similar in 2 cases except one you
        have to get the bitmap to apply to and the other you render
        from stacking context
  smfr: It's hard and expensive which we know, but you get a nice
        graphic property. I think it supplies more use case.
  smfr: It would be hard for webkit to impl any other way because we
        rely on system set backdrop
  TabAtkins: We've got the opposite problem

  TabAtkins: You glossed over difficulty of resolving double filter.
             Example: container with blur. 2 pieces of content, an
             element and a backdrop blur that's on top of first
  TabAtkins: Blur on container is understood, but does that mean
             backdrop filter does a blur of what's behind me sees a
             blurred child and does a blur or does it see the
             unblurred child? There isn't a simple answer and your
             decision will have strict implications on how to impl.
             Following strict stacking gives you a clear answer
  TabAtkins: Even if you say we do it because how platform does, I
             don't know how your platform would handle this case.
  TabAtkins: I'm concerned about this as generally all pixels
             underneath. That's hard to define
  smfr: Easy to define of appendix of CSS2.2 You render everything up
        to the element with backdrop filter. It's different the
        mix-blend-mode and different to SVG filters. I think in
        blurring we should clarify with test cases.
  smfr: If saying element behind has blur you blur and then apply
        background filter
  TabAtkins: Container has the blur. That's unclear if before or after
  smfr: I think you blur the thing with backdrop additionally
  TabAtkins: Blur entire contents then do background filter blur?
  smfr: If blur is on a container of the backdrop...[thinks]

  <dbaron> I think in some cases (e.g., backdrop filter inside
           something with opacity) the right thing to do "visually"
           may be to *invert* the opacity (which can be seen as one
           case of a filter)
  <dbaron> but not all filters are invertible

  chrishtr: Have to drop content underneath, apply blur, backdrop
            filter, draw under, and blur it all again.
  chrishtr: It can be done, but it's quite strange. Also a big
            performance cliff. Drawing everything a second time and
            applying effects doubles the display list. Also what if
            there's a scroller or a video back there. Or multiple
            nested backdrop filters. Run time will be exponential
  astearns: Given that you have said the use case for not isolating
            can be achieved by changing where things are in DOM, that
            performance cliff is around anyway as far as I understand.
            It just depends on arranging
  TabAtkins: Under our preference it wouldn't work if you nest weird
             or it's up high in the hierarchy and the effect works
             fine. So it's cheap or works differently in a visible
             way. Either way it's cheap-ish
  chrishtr: Also if you define to isolated group you don't get
            exponential with backdrop filter. Each is a stacking
            context so only goes up to containing thing.
  chrishtr: General concern about introducing something with large,
            possibly exponential, to the platform without a known
            effect that justified

  smfr: Would like to do this on a call with dino. Can we bring this
        to next APAC call?
  astearns: Also useful to continue adding cases to this issue. We can
            do this async and provide better clarity.
  TabAtkins: Do both.
  chrishtr: smfr could you reach out to dino?
  smfr: Yep.
  astearns: That's probably enough on this issue.

  github: https://github.com/w3c/fxtf-drafts/issues/310

  chrishtr: L2 spec specifies the enclosing isolated group behavior. I
            think that's only thing in L2. Does ti make sense to
            publish without that?
  astearns: And that's only thing in L2?
  chrishtr: I believe so. No objections to publishing L1
  astearns: L1 is a WD?
  chris: Agree if we have 2 impl and neither agrees with spec we
         should fix before FPWD. L1 we should update. I think we have
         editorship change and I'd like to get that in.
  chrishtr: I was added as editor. krit at TPAC was committed to
            finishing L1
  astearns: Let me see. krit can be committed but others can work
  chrishtr: Yes, point was he's still involved

  astearns: Editorship aside; krit is still in. I think we can resolve
            on a new WD of L1
  <chris> +1 to new WD of L1
  astearns: Objections to publish a new WD of filter-effects L1?

  RESOLVED: Publish a new WD of filter-effects L1

  astearns: I'll talk to krit about adding chrishtr as an editor.
            Great if you both can work.

Selectors (continued)

Decide on :blank
  github: https://github.com/w3c/csswg-drafts/issues/1967

  astearns: Discussed this a number of times
  astearns: Incl deferring from last week
  astearns: It was if anyone was volunteering to be first impl
  TabAtkins: We've added a use counter to check if change is web
             compat. We're happy to change to include whitespace if
             won't break. [missed] added a use counter last week. Will
             be several weeks for data. Assuming it's fine we're
             amenable to it. Might want to look in 2 months once we
             have data
  astearns: Everyone else okay waiting for data?
  astearns: Great.
  <TabAtkins> use counter

Case-sensitive attribute selectors
  github: https://github.com/w3c/csswg-drafts/issues/2101

  TabAtkins: Turns out there's a couple of HTML attributes that must
             be matched case insensitive in selectors.
  TabAtkins: We let UAs or Authors match case insensitive for UA
             stylesheet. Type attribute requires this.
  TabAtkins: <ol> uses type in way that requires case sensitivity
  TabAtkins: Because type elsewhere requires case insensitive it would
             be weird and bad if some were sensitive and some not.
             Just like we added i tag to allow authors to opt in, we
             can do opposite to force case sensitive.
  TabAtkins: Put in a UA style sheet and in a few places where author
             needs to match against case sensitive they use that.

  fantasai: I don't have objections to adding the flag. Confused as to
            why type attribute it's inherently case sensitive on <ol>
  dbaron: It's per attribute, not attribute+element. attribute+element
          is a lot more complicated and this is only use case
  TabAtkins: I like s as the flag. Insensitive = i, Sensitive = s
  <florian> +1 to "s"
  fantasai: Agreed
  astearns: Objections to adding a Sensitive 's' flag?

  RESOLVED: Add a Sensitive 's' flag

Shadow Parts

confirm browser support

  astearns: Is fergal on?
  TabAtkins: He just wanted a publication request. He wasn't able to
             be on last week, but we resolved anyway.
  astearns: I thought might be about idl changes

  chris: It's queue for publication tomorrow so it's good
  TabAtkins: How recently did you generate fpwd? He's made changes in
             last 2 days
  chris: Did it yesterday. Has to be queued 24h before
  TabAtkins: That's good. Cool.

Selectors (continued)

:valid-within / :invalid-within pseudo-classes
  github: https://github.com/w3c/csswg-drafts/issues/3072

  astearns: Anything anyone knows we can resolve on? We were
            discussing in issue
  fantasai: Flag this for selectors 5? Don't see anything
  bkardell: I think I would support Selectors 5.

  bkardell: I know raised on issue, but how far do we want to care
            within thing? We have :target-within and :focus-within,
            but that was before :focus-visible so now we need
            :focus-visible-within. Also ask for :valid-within,
            :invalid-within. Valid use cases, but why just those?
  bkardell: Other requests for empty/blank within. Just ways of
            scooting around can't do :has
  TabAtkins: Reason we have a small list is we can't do :has because
             it's dramatically expensive. Can do a small number of
             carefully controlled state-based, everything we add is
             substantial additional cost. There will always be a small
             list of what we allow. Larger list of what we want, but
             can't do all. Everything has a good argument, but need to
             be selective on what include
  bkardell: Suggesting see if create something reasonable that avoids
            some of that. Maybe impossible or unlikely that we'll have
            has. I don't know that there's not something we can do
            that's acceptable and not prone to a lot of withins and
            explaining why some are and some aren't. Something clearly
  TabAtkins: There is no clear articulation. It's the most high value
             and worth spending impl and perf penalties. It's
             arbitrary. No clear reason for cut off. It's we don't
             feel we should add more. What's left isn't worth

  TabAtkins: Boris has argued a simple :has-child might be something
             impl are amenable too. It's a simple case of how much you
             need to check. :has-child is only up one level, more
             limited in cost. Might be okay for cost. Will cover a lot
             of what people need. Won't be everything and can't allow
             chaining. If we feel a lot of use cases can be addressed
             by parent caring about children that's a direction - we
             should check use cases
  bkardell: That's what I mean. I know Boris had interesting ideas.
            I've had similar convos with number of impl. A lot of
            thoughts as what we could do. Instead of doing lots of
            withins let's see what we can do to take a big chunk of
  TabAtkins: Might be good to look at lots of cases to see if it's
             just parent/child or more. If it's mostly parent/child
             it's worth looking at has-child. That's a study that
             should be done. I recommend if you're interested in
             pursuing this

  <bradk> :has(:focus|:target|:focus-visible|:valid|:invalid)
  <fantasai> bradk++
  <gregwhitworth> I can't imagine the use cases only being has-child()
                  as there are still needs for wrapper divs/spans, etc
  <florian> +1 to greg.
  <gregwhitworth> you'll need something that penetrates further down
  <bkardell> that is also part of what I mean, that is maybe worth
             articulating as a criteria we use for determining whether
             we'd consider a thing and why

  emilio: Slight difference between within selectors and has. Within
          work on flat tree and can cross shadow boundaries. Worth
  TabAtkins: Forgot about that. That is interesting

  astearns: All this will go into issue. Sounds like we should
            continue there and look at figuring out if this goes into
            selectors 5.

  <fantasai> majidvp, any update on
https://github.com/w3c/csswg-drafts/issues/2988 ?
  <majidvp> fantasai: no new update. I have not had a chance to work
            on this since last update. My next step was to look at the
            mobile data from httparchive. Pending that does not raise
            a red flag we can try to fix this in Blink.

CSS Overflow

'overflow' 2-value syntax is in wrong order
  github: https://github.com/w3c/csswg-drafts/issues/2988

  astearns: IRC chat above about it
  fantasai: Looks like waiting on majidvp making change in Blink which
            requires him doing some research
  florian: What are we blocked on majidvp for?
  TabAtkins: He's an interested impl who understand problem and wants
             to fix.
  florian: He's attempting to do what we spec and if he succeeds that
           overrules the concerns?
  TabAtkins: I believe so. I think only concern is compat so us being
             happy avoids that
  emilio: Compat concern, but also shorthands that expand to multiple
          longhands. Don't know if Blink plans to impl, but need to do
          more off spec work.
  TabAtkins: Yes, that's discussion from TPAC. That's a larger issue
             that needs to be resolved in sensible way.
  TabAtkins: We already have a number of properties with this problem,
             so we need to solve for all

  emilio: Cannot fix this without figuring out whole thing
  TabAtkins: We've already got margin-start and margin-left
  emilio: margin shorthand is only physical
  TabAtkins: Yes, but need to worry about shorthand interaction with
             both. Same thing you've got here.
  emilio: It's another level of interaction.
  TabAtkins: I don't understand how different.
  florian: Same as having the extra keyword on shorthands to say. We
           don't have that.
  TabAtkins: If you set margin and margin-inline-start and ask for
             margin, we don't know what it should return
  emilio: We do
  florian: Margin is shorthand of physical only.
  fantasai: It's impl that way. If you replace margin with physical
            shorthands you get correct. gCS it's mapped across both
  emilio: gCS is different because knows writing mode. Issue is
          specified style. This would be a case where there is no
  TabAtkins: If overflow 2 value is logical and margin is physical
             it's congruent
  emilio: When you spec overflow it maps to 4 properties. Overflow
          shorthand can take different prop
  florian: Shorthand to longhand is parse time, but need to parse on
           computed value
  TabAtkins: Way we're talking is it's parse time. Overflow 2 value
             expands to logical long hands.
  emilio: But only when in 2 value
  TabAtkins: When in 1 doesn't matter
  emilio: Does matter because then you need to return something for
          physical for compat
  TabAtkins: Same problem as margin. Set margin-start and margin below
             it blows away margin-start
  emilio: It's about setting, not getting.
  emilio: I filed a bunch of issues about serialization not round
          tripping. I'm pretty sure a shorthand that expands to
          multiple prop is a new problem

  dbaron: Example of something where behavior now isn't specified: If
          we assume that we haven't intro logical. If stylesheet says
          overflow-x:visible and overflow-y:visible if you call
          getPropertyValue on overflow you get visible
  dbaron: If you have overflow-x:visible and overflow-y:visible and
          overflow-block:visible and overflow-start:visible what do
          you get?
  <emilio> dbaron++
  dbaron: Point isn't what answers are it's that answers aren't
          obvious in spec now
  TabAtkins: So it's legacy behavior running into this. I missed that.
  dbaron: I don't think it's legacy. I don't know any impl that has
          impl both logical and physical shorthands.
  TabAtkins: Blink has logical of block
  dbaron: Longhands, but shorthands aren't mapped. I think that's
          because there's so many spec issues in OM
  emilio: Have logical long hands and shorthands, but they only map to
          logical long hands
  TabAtkins: In cases right now where single property has both logical
             and physical underneath it only maps...I think we wanted
             the logical longhand to be ignored from shorthand after
  TabAtkins: While there are legacy issues with overflow in
             particular, the issue in general applies to all of our
             logical and physical properties.
  TabAtkins: I completely agree let's define that.
  florian: majidvp experiment may provide feedback

  astearns: Thanks everyone for calling in, we'll talk next week

Received on Thursday, 15 November 2018 00:52:21 UTC