[CSSWG] Minutes San Francisco F2F 2019-02-26 Part II: Shadow Parts, CSS Contain, CSS Scoping [css-shadow-parts] [css-contain] [css-scoping]

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

Shadow Parts

  - RESOLVED: Add such a note -- no exposing parts of form controls
              without standardization (Issue #3674: Make clear that
              Shadow Parts for built-in elements should not be
              supported without standardization)

CSS Contain

  - RESOLVED: Remove style containment from keywords that aren't
              'style' (Issue #3280: contain: style doesn't seem very
  - RESOLVED: Mark 'style' at risk (Issue #3280: contain: style
              doesn't seem very useful)
  - RESOLVED: Republish CR of css-contain once edits are in (Issue
              #3280: contain: style doesn't seem very useful)

CSS Scoping

  - Usage data will be gathered for :host-context. If the counter
      reveals low/no usage it will be dropped. (Issue #1915:
      Specificity of :host, ::slotted, and :host-context doesn't seem
      to be defined?)


Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: fantasai

Shadow Parts

Standardization of Shadow Parts for built-in elements
  github: https://github.com/w3c/csswg-drafts/issues/3674

  heycam: This is a small request, we had a request internally to make
          it clear that the ::part() pseudo-element is not a kind of
          free-for-all extension point for engines to expose parts of
          built-in form control elements
  heycam: There was some concern in the past that engines were happy
          to expose parts of form controls through pseudo-elements,
          and of course that's a big compat problem for us, maybe
  heycam: We don't want to repeat with env(), which also takes an
          ident, and we ended up with things being implemented that we
          then had to implement and then spec afterwards, which is the
          reverse of the standards process.
  heycam: I like that the spec doesn't talk about built-in file
  heycam: But it's an attractive bit of syntax for exposing this
          stuff, so we'd appreciate a note in the spec that this isn't
          to be used to expose parts of standard form controls until
          we go through the normal standards process
  <florian> I fully agree with heycam
  TabAtkins: I accept the change on behalf of fergal
  heycam: Unless ppl have plans to start exposing things through
  <tantek> +1

  AmeliaBR: Questions from authoring side. One of big complaints with
            all of the custom pseudo-elements was that it messed up
            your selector and you had to have separate rules for every
  AmeliaBR: Is the invalidity rule such that ::part() is always valid
            regardless of arg?
  TabAtkins: As long as syntax matches what's syntactically allowed
             it's valid
  AmeliaBR: So if someone wanted to test out a prefixed part, it'll be
            a nicer flow for authors to build on
  AmeliaBR: Agree that ppl shouldn't ship experimental things until
            there's a standardization discussion
  AmeliaBR: In some cases maybe we'll say, your datepicker is so
            specialized that you should have a prefixed part?
  TabAtkins: Yeah, fine to do, because syntax space is wide open

  RESOLVED: Add such a note -- no exposing parts of form controls
            without standardization

CSS Contain

contain: style doesn't seem very useful
  github: https://github.com/w3c/csswg-drafts/issues/3280

  emilio: Very confused what use case contain: style is supposed to
  emilio: It's hard to implement. Very broken in the only
          implementation that's shipping.
  emilio: I can't see any potential advantage except *maybe* update
          counters faster in the page?
  emilio: But that's usually not a perf issue.
  TabAtkins: My answer in the issue was that the 'contain' properties
             in general are to help isolate parts of your document
  TabAtkins: perf wins are a benefit, especially layout
  TabAtkins: But also helps you isolate parts of your document to make
             it easier to think about
  TabAtkins: It covered the remaining thing that would leak out of a
  TabAtkins: Was a completion exercise in making an isolated component

  emilio: Did we decide how counters work in CSS? Are they off DOM
          tree or flat tree?
  TabAtkins: CSS works on flat tree as its "element tree"
  TabAtkins: So counters are defined to work on flat tree
  emilio: Tests?
  TabAtkins: Had some in past, lost them. Before wpt
  TabAtkins: Might pick up again when working on Lists
  dbaron: Counters are part of generated content, thus box tree
  TabAtkins: Mental model is that everything is elements, then we turn
             things into boxes, then we turn things into fragments
  fantasai: If we had counters working on the not flat tree, then I
            don't know that list numbering would make much sense, if
            part of your component was reordering items in a list
  fantasai: so I think they do need to work on the flat tree
  TabAtkins: If you take an ol, give it a shadow tree, rearrange
             items, numbering should reflect final display, not
             original ol.
  fantasai: Right.
  <dbaron> At the time we implemented ::before and ::after as part of
           the box tree, the specs were still pushing towards allowing
           multiple CSS presentations of a single document.

  futhark: I agree with emilio that there is not much to do with
           optimization for contain: style
  futhark: One useful thing would be if we said that inheritance
           doesn't happen from 'contain: style' down
  futhark: Then we can optimize for ?
  futhark: If 'contain: style' meant that 'all: initial', then we
           could optimize getComputedStyle
  futhark: Then it wouldn't rely on layout (???)
  futhark: Then can do display locking
  emilio: ...
  TabAtkins: Contain property doesn't block things going into the
             subtree. It blocks things leaking out.
  florian: It's the contain property, not the isolate property

  TabAtkins: If it ends up being that we don't want to implement
             'contain: style' across browsers, we can drop it. It
             just, it's part of my vision for what 'contain' was
             about. Last piece necessary to create a seal around the
  TabAtkins: There's also a bunch of parts of CSS where we have global
             names etc.
  TabAtkins: Maybe we just rely on shadow DOM.

  florian: Wanted to ask rego's pov, since he fixed a lot of bugs on
           'contain: style'
  <rego> there are a few bugs

  Rossen: So what's your ask, Emilio?
  emilio: It's very broken to the point that 'contain: style' toggling
          doesn't do anything dynamically
  emilio: Implementing it in Gecko is really hard, and I'd rather not
          ship something that's broken.
  emilio: My ask is drop it.
  Rossen: So proposal here is to drop 'contain: style' from css-contain

  AmeliaBR: Is there any reason this couldn't be added back later, if
            it turns out to be useful?
  florian: Yes and no. It's easy to add stuff. But there's 'contain:
           strict' which is all of the contains. If we add a new one,
           then it wouldn't just be an addition but a change.
  florian: So we'd have to add a new keyword for all of the contains
           that includes the new type of containment

  chrishtr: If property changes on an element on 'contain: style', and
            we don't have 'contain: style', is it possible to dirty
            something else?
  TabAtkins: Counters and quote property
  emilio: The computed style doesn't change.
  emilio: The counter values are not stored in computed styles
  chrishtr: Does contain: layout say that counters...?
  emilio: Style is a bit of misnomer
  chrishtr: Regardless of name, need to have this functionality to
            have complete perf
  emilio: My point is that changing counters is not something that is
          typically a perf bottleneck. Not like changing height, which
          has lots of effects throughout the doc
  emilio: Not something I've seen in a perf profile at all

  chrishtr: But if you want to do things like async rendering or
            display locking
  chrishtr: You'd need this, just in case the content changed a counter
  chrishtr: Whether it should be its own thing, idk
  emilio: It's not something that happens frequently. It can have a
          layout effect across the page.
  chrishtr: But unless you lock it, has an effect
  emilio: It's same as changing content property
  florian: But that doesn't affect outside the element
  emilio: ... counter-reset can change stuff across document
  chrishtr: Point of containment is that you can reason about the
            relationship of work between stuff in the contained
            subtree vs rest of document
  chrishtr: It's small but a real footgun?
  emilio: That's fair, but we still don't have a great model for
  emilio: Makes it seem like counters work in the style tree.
  emilio: Which isn't true
  emilio: We need tests for like shadow DOM, need tests for display:
          contents, for all these edge cases which change how counters
          are affected by style containment
  chrishtr: Agree we need tests
  emilio: and a proper spec

  dbaron: We had an interim agreement to add 'counter-set'
  dbaron: we never added
  TabAtkins: It's in a spec, it's in Lists
  TabAtkins: Just never past WD
  emilio: ... spec, not in implementations
  emilio: Even in Blink, renumbering lists
  emilio: If element is display: contents; contain: strict; if you add
          a list item inside of it?
  emilio: You have a <ol><div style="contain: strict"><li></div></ol>
  emilio: Right now if you change the div's display, it is buggy
  TabAtkins: Our entire counters implementation has issues
  eae: Spec is correct, but our impl is incorrect
  emilio: Given state of impls, implementing 'contain: style' is not
          worth it
  TabAtkins: Fact that built-in lists might be magical is a separate
  emilio: If lists are magical, then we have another leak
  dbaron: We have a patch to Gecko to use counters for lists, so might
          fix that

  chrishtr: Sounds like all the browsers are sad, and I think we agree
            that there is a real footgun even if a small one
  * fantasai would not describe this as a "footgun"
  chrishtr: So I think we should add proper tests and fix things to
            not be sad
  chrishtr: Then if that's the case, come back to you about this.

  dholbert: Sounds like use case is lazily rendering the subtree
  dholbert: If counters and quotes are the only things that would have
            an effect, maybe implementations can just add checks for
            those properties
  dholbert: They're quite rarely used
  dholbert: Might be easier to just disable perf optimizations in
            cases where they're used rather than implementing
            'contain: style'

  futhark: I think Chris you had some thoughts... I'm confused about
           isolation vs containment
  futhark: For perf, you probably want isolation
  futhark: If you modify DOM outside something that's contained
  futhark: It can affect sibling selectors that affect the contained
  emilio: Which can set 'contain'
  TabAtkins: Nothing about contain is about isolation
  TabAtkins: You can't have layout isolation
  TabAtkins: You can't use percentage or auto or anything. It has to
             be 100% manually-specified or nothing.
  TabAtkins: You have a subtree that you can ignore when changes
             happen inside it. That's the use case we're designing for
  chrishtr: Points about % sizing and isolation vs something else is a
            complicated subject, and the more you go towards one end
            the more you lose use cases or perf
  chrishtr: Needs investigation
  chrishtr: Not only is 'contain: style' poorly implemented, the other
            contain modes while implemented correctly don't actually
            improve perf
  * cbiesinger notes that some of the other contain modes do help with
               performance under some circumstances
  * cbiesinger (in blink)

  emilio: Even though containment is designed to ignore a subtree, you
          can still have e.g. :empty { contain: strict } and that
          div's contained but you insert a child in that div, and you
          are no longer contained
  emilio: Contain can be dependent on DOM contents of an element
  emilio: There are selectors already that depend on contents of the
  chrishtr: ...
  TabAtkins: You cannot have selectors that depend on style
  TabAtkins: Filing an issue won't solve it.
  TabAtkins: We can't do that.

  florian: Mentioned about testing and things, at the moment we have
           reasonably extensive testing of normal counters
  florian: If lists are fake counters, that's not tested separately
  florian: I couldn't find tests for shadow DOM and display: contents
  florian: But for normal counters, should be well-covered
  TabAtkins: Given large number of inconsistencies in lists from when
             I was testing them awhile back....
  florian: Checking for what it's supposed to do to counters.
  florian: If you toggle contain on/off, we don't have tests for that.
  florian: But effect of contain on counters, we do have tests
  TabAtkins: Thanks for test suites
  florian: Thank gtalbot

  Rossen: Hearing pushback from Mozilla
  Rossen: Not hearing much from other vendors
  Rossen: What do we want to do next?
  fantasai: Rename it, obviously.
  Rossen: Or we can drop it
  emilio: Can we drop contain: style and if we decide it's a thing we
  TabAtkins: Drop style now, figure it out later, decide what to do
             about 'strict' and whether to make it stricter or add a
             stricter value?
  fantasai: Might be able to slip it into strict later, because content
            is unlikely to be dependent on leaking counters/quotes
  TabAtkins: Quotes definitely rare. Unsure about counters.
  emilio: ...
  Rossen: We could try dropping style now, and see if counters surface
          as a prominent use case, then deal with it
  TabAtkins: What do you think, Chris?
  chrishtr: Drop it from the spec, but leave it implemented in one
  TabAtkins: No, that'd be a spec violation
  gregwhitworth: It's implemented and shipping in a browser, but it
                 doesn't work
  TabAtkins: It does for real counters, if you have no dynamic changes
  hober: It's up to them what they ship in their browser. It's up to
         us what we have in the spec.

  Rossen: So would there be an objection to dropping 'contain: style'?
  emilio: My point for dropping it now is that it's the same kind of
          risky change to change Blink's lists to use real counters as
          it would be to drop 'style' / implement later
  emilio: The case of having 'contain: style' that spans across a list
  emilio: or counters inside a 'contain: style' subtree
  emilio: Until Lists work that way, you're going to break something
  TabAtkins: If our counter impl is already broken and weird, so it
             probably doesn't matter if we leave the code in?
  chrishtr: What would likely happen is that we wouldn't remove the
            feature, we'd fix it
  chrishtr: I'd rather fix it in Chrome and work through the spec
            issues than drop it
  chrishtr: What we do with the spec in the meantime
  eae: It's something we really want to do in Blink, and we do realize
       that the current state of thing where e.g. Lists don't work
       that way
  eae: So it might make sense to drop it for now
  florian: If we drop now and add back later gets us to strict +
  florian: I'm not bikeshedding the stricter
  * fantasai still thinks making strict stricter would be unnoticeable

  emilio: We also want to ship containment
  emilio: But we really don't want to implement 'contain: style' under
          the current state of affairs
  emilio: Given it needs more work in specs and implementations
  emilio: It would make sense not to block shipping containment on
          'contain: style'
  chrishtr: Was there a compat issue?
  emilio: No, but we don't want to willfully violate the spec.
  emilio: We don't want to parse a value and then not implement it
  TabAtkins: Is it just about built-in lists or all counters?
  emilio: It's generally hard to implement in our counters

  TabAtkins: I'm wondering how difficult it is from doing a
             counter-reset on all possible counters?
  dbaron: I think in our counters implementation, the right thing to
          do is just create a new counter-manager for an element that
          has 'contain: style'
  dbaron: And then it's reasonable
  emilio: And then dynamic changes, you'd have to reframe
  dbaron: You'd have to reframe anyway
  TabAtkins: You can make it as slow as you want to change 'contain'.
             It's not a use case to flip it dynamically.

  florian: Unless I missed something, counters have a definition
           problem. CSS 'contain: style' doesn't.
  florian: There's a dependency, but I think implementation and spec
           being wrong is an overstatement
  TabAtkins: Lists spec having bugs is adequate to say there's a spec
  florian: My point is, if there's a problem with the contain spec
           there needs to be an issue so I can fix it. But there isn't.
  TabAtkins: ...

  emilio: What would be the best way for Mozilla to ship contain:
  florian: Could just not ship strict yet, then ...
  TabAtkins: People are reasonably encouraged to turn on strict, so
             technically the right way to do it, but don't think it's
             good advice
  <rego> neither contain:strict neither contain:content (as both
         include style)

  fantasai: I think the right way to go is to ship everything except
            the style value itself
  fantasai: and then at some future point, incorporate that into strict
  fantasai: In the majority of cases it's not going to have an effect,
            so I don't think it's something to be too worried about
  emilio: It would be nice if Blink didn't parse 'style' either, and
          we could do that change together later
  florian: When you say don't do style, did you also mean change
           behavior of strict later when we add it?
  fantasai: Yeah, we will eventually change the behavior
  fantasai: Yes
  chrishtr: You said it's not so easy to implement 'contain: style'
  chrishtr: How hard is it?
  emilio: How hard is it?
  chrishtr: Couple months of work?
  emilio: It's work, that somebody needs to do

  TabAtkins: Given that I do have a direction for naming in the future
  TabAtkins: I'm OK with dropping style for now
  TabAtkins: Dropping from definition of strict, dropping as a value
  TabAtkins: And then we add 'all' later, that does all 4
  TabAtkins: Do that once our implementation is good enough to be
             meaningful for style
  TabAtkins: And Mozilla can also fix
  emilio: And add a bunch of tests :)
  chrishtr: So what you're suggesting is to refactor spec so that
            easier to incrementally add in the future
  TabAtkins: Right, drop 'style' and add it back in a future level of
             the spec
  chrishtr: What if we do the other things you mention and leave style?
  TabAtkins: Drop style containment from strict and content?
  dholbert: That would make us reject 'contain: style' but...
  chrishtr: CSS parsers can ignore keywords they don't understand?
  florian: If you as an author writes 'contain: style size" it'll be
  florian: but if you write 'contain: size; contain: style size' then
           you just lose the second declaration keep the first
  TabAtkins: Most of the time we recommend strict anyway
  florian: Seems like least harmful way to do this
  chrishtr: And then we'll fix our bugs and allow ppl to opt in
  Rossen: Any objections?

  RESOLVED: remove style containment from keywords that aren't 'style'
  RESOLVED: mark 'style' at risk
  RESOLVED: Republish CR of css-contain once edits are in

  chris: Ping me when you have a DoC and file a transition request

CSS Scoping

  github: https://github.com/w3c/csswg-drafts/issues/1915

  emilio: When looking into this stuff, what I didn't implement which
          Apple also doesn't, is because it's really slow
  emilio: Reason why it's really slow is that for every class change,
          you either need to store everything for the whole document,
          or you need to look at every shadow root that has a host
          context selector, and go through all the shadow roots inside
          your subtree to check if they have a relevant host-context
  emilio: Handling DOM changes when host-context selectors are involved
  emilio: Blink solves this by doing subtree restyles?
  futhark: So in Blink we aggregate style info at the document scope
           for everything
  futhark: We don't use subtree calc
  futhark: We invalidate inside the shadow root
  futhark: We use a flag for it
  emilio: One of the nice things in our impl is that the style info
          inside the shadow root is contained
  emilio: Blink wants to make such a change, too
  emilio: So effectively it's similarly slow as /deep/
  emilio: Since I haven't seen anything in Bugzilla requesting it
  emilio: And WebKit also hasn't implemented
  emilio: So would like to drop

  futhark: I don't have the usage numbers...
  TabAtkins: We should see if it's used
  TabAtkins: It offers a useful functionality but if ppl aren't using
             it, I'm fine with dropping it
  Rossen: So, collect data, come back and based on this we can move
  fantasai: So maybe flag for next F2F so we don't forget
  Rossen: Hope to get to it before

<br type=lunch>

Received on Thursday, 4 April 2019 23:08:17 UTC