Minutes Berlin F2F 2018-04-11 Part I:CSS Contain, CSS Scoping, CSS Pseudo Elements [css-contain] [css-scoping] [css-pseudo-elements]

  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 Contain

  - RESOLVED: Align 'contain:paint' to 'overflow:clip' behavior.
              (Issue #2223)
  - RESOLVED: Size layout and paint containment don't apply to
              internal ruby elements. (Issue #2512)
  - RESOLVED: Size containment does not apply to non-atomic inlines.
              (Issue #2510)
  - RESOLVED: Layout and paint containment does not apply to
              non-atomic inlines. (Issue #1457)
  - RESOLVED: Clarify the definition of what and how an FC is created.
              (Issue #1457)
  - RESOLVED: No change to spec, but add examples and improve wording
              to clarify desired behavior. (Issue #2483)
  - RESOLVED: Add this clarification to the spec. (Issue #2349)
  - There's only one open issue left to resolve (Issue #2527: How do
      layout and size containment interact with column/page
      fragmentation?). After that is closed the spec can be

CSS Scoping

  - RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2158
             (keep ::slotted and :host to a single argument)
  - RESOLVED: Account for the specificity of the selector item and
              change the spec to say pseudo elements have same
              specificity of pseudo classes. (Issue #1915)

CSS Pseudo Elements

  - RESOLVED: ::selection is cleared for shipping unprefixed even
              though multiple implementations do not (yet) follow
              the spec. (Issue #2474)
  - RESOLVED: Switch to using inheritance instead of cascade (to
              describe ::selection of a child). (Issue #2474)


Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Christian Biesinger, Google, observer
  Brian Birtles, Mozilla
  Oriol Brufau, Observer
  Tantek Çelik, Mozilla
  Monica Dinculescu, Google
  Elika Etemad, Invited Expert
  Rob Flack, Google
  Simon Fraser, Apple
  Jihye Hong, LGE
  Koji Ishii, Google
  Dael Jackson, Invited Expert
  Ian Kilpatrick, Google
  Rune Lillesveen, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Naina Raisinghani, Google
  Manuel Rego, Igalia
  Florian Rivoal, Invited Expert
  Richard Rutter, Clearleft
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Shane Stephens, Google
  Surma, Google
  Majid Valipour, Google
  Lea Verou, Invited Expert
  Eric Willigers, Google

Scribe: dael

CSS Containment

contain:paint should use padding box instead of content box
  github: https://github.com/w3c/csswg-drafts/issues/2223

  florian: Currently contain:paint clips to the content box, which is
           different from overflow. We should probably use padding box
           as well.
  florian: We should be clipping to the shaped padding box like
  fantasai: Can't you just invoke 'overflow: clip'?
  florian: At some point we defined paint containment to be at
           computed value time, but we do want the same effect. How
           it's described doesn't matter.
  fantasai: I'd say used value time.

  dbaron: Shaped padding box?
  florian: Padding box with border radius applied.
  dbaron: Sounded related to shapes.
  florian: No, it's just a piece of terminology we resolved to add.
  [questions about what we resolved]
  florian: We resolved to add a term, I proposed shaped-padding-box
           but I'm open to other names.
  <astearns> yesterday:
  dbaron: Not crazy about that because it sounds like shapes.
  florian: So the padding box with rounding corners applied and if
           there's ever other types of corners those as well.

  florian: Resolve to align to overflow:clip behavior?
  Rossen: Objections?

  RESOLVED: Align to overflow:clip behavior.

Applicability to internal ruby elements
  github: https://github.com/w3c/csswg-drafts/issues/2512

  florian: Size containment, layout containment and paint containment
           don't apply to internal layout parts. But we don't say
           anything about internal ruby elements. We should exclude
           those as well.
  koji: What's internal ruby elements?
  florian: Things like ruby-base container and ruby-text container.
           Layout containment on these things doesn't make a whole lot
           of sense.

  koji: It would apply ruby element
  florian: Yes.
  dbaron: I'm fine with that.
  Rossen: Any reasons we should be applying containment?

  RESOLVED: Size layout and paint don't apply to internal ruby

Applicability of size containment to non atomic inlines
  github: https://github.com/w3c/csswg-drafts/issues/2510

  florian: Having size containment apply to elements where the width
           and height do not apply doesn't sound useful. So it should
           not apply to non-atomic inlines.
  dbaron: Do all the other forms of containment work?
  fantasai: You also probably can't do layout containment.
  florian: There's another issue on that.
  Rossen: Objections?
  florian: I think non-atomic inlines is the right word.

  RESOLVED: It should not apply to non-atomic inlines.

Becoming a formatting context
  github: https://github.com/w3c/csswg-drafts/issues/1457

  <florian> https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-379156461
  florian: Start reading here ^

  florian: We've been discussing for a while, there's something in
           contain saying things must become a formatting context
           root. We've been deciding if this is the generic thing that
           should go in and if yes does it apply to inlines or ruby.
  florian: fantasai has been pushing back for combined reasons. 1)
           does it make sense to layout and paint containment apply to
           non-atomic inlines. If yes we have to FC them. If not we
           shouldn't apply that. I'm reasonably convinced they
           shouldn't apply to inlines. This is a radically different
           thing and if you want that layout ask for it explicitly.
  florian: I agree there is no need for containment to apply on these
  TabAtkins: Yeah.
  florian: Maybe we can resolve on that?

  Rossen: Proposal: Layout containment and paint containment do not
          apply to non-atomic inlines.
  smfr: Things with more then one box?
  florian: Principle box.
  dbaron: smfr means more then one fragment. I think they would apply
          to something inside a multicol over many columns. So what
          that means might be a problem. But if you have layout and
          size containment for a thing split over multiple columns you
          have to decide how to paginate and that gets interesting.
  TabAtkins: It's either 0 or fixed height.
  dbaron: Do you split arbitrarily or it has to be one piece? You
          can't use middle line breaks because it's not containing.
  florian: I think containing and fragmenting is a separate discussion
           we should look at.
  dbaron: File an issue?
  florian: Yes.
  <dbaron> I filed https://github.com/w3c/csswg-drafts/issues/2527 on
           the fragmentation and contain issue

  RESOLVED: Layout and paint containment does not apply to non-atomic

  florian: Do we need a term for this? There's a bunch of specs that
           talk about establishing a BFC. In flex it says that you
           establish a FC and it means blah blah. However in overflow
           spec when you set it to non-visible it must establish a
           formatting context. Same with multi column spanners. It's
           not a new type of FC, we just say you need to get one of
  florian: In this case when you need to be a FC everything is already
           one except blocks and blocks become BFCs. We can just say
  florian: What I'd like to have is... have an anchor term that is
           establish a formatting context because then it says what
           type of FC it is. We've many times said BFC and that's not
           what we meant.
  florian: To try and stop from BFC-izing things having a term that
           does that sounds nice to me.
  florian: fantasai was pushing back against this.
  fantasai: I think it's "establishes a formatting context" and
            there's a definition for that.
  florian: For what a FC is, but not when you establish one.

  fantasai: Okay. We can add one to display.
  florian: That definition should include that if you invoke that on
           non-atomic inlines you wrote your spec wrong because you
           need to blockify them first.
  florian: I've got suggested text.
  fantasai: There's a definition for a new formatting context but it
            doesn't say type.
  florian: But you made the mistake of the wrong kind so if we get it
           repeatedly wrong.
  fantasai: Some specs have said BFC when they meant FC. We have an
            anchoring term, if you have a problem with the definition
            we can adjust.
  fantasai: Specs like multicol were written before flex and grid so
            writers weren't thinking about things that aren't blocks.

  Rossen: The definition you're referring so, can you paste a link?
  Rossen: florian if the definition is not enough, then where is your
          proposed text?
  florian: Toward the bottom of the comment
  florian: [reads]
  [Text from issue:
    Specifications may call for an element or box to <dfn export>
      establish a formatting context</dfn> without further precision
      as to the type of formatting context or how to do so.
    This operation is not applicable to non-atomic inline-level boxes
      nor to boxes with a layout-internal display-type. Specifications
      that invoke this must either exclude such boxes, or to blockify
      them first.
    If the box is a block container that does not establish a BFC, it
      is made to establish a BFC. Otherwise, the box already
      establishes a formatting context, and this operation is a no-op.

    Note: This has no effect on the computed value of the display

    Note: If a specification defines a new type of box which are
      neither non atomic inline level, layout-internal, block
      containers, or some other display type that establishes a FC,
      then that specification must define the meaning of this
      operation for that type of box.
  fantasai: It's not true. If you try and establish on a table row.
  florian: It doesn't invoke on internal display types.
  TabAtkins: If you're trying to FC [missed]
  TabAtkins: This'll go in the guidance, like "don't blockify and
             inlinify the same element".

  florian: I won't block on this, but it seems reasonable to me given
           that we've made the mistake multiple times after creation
           of flexbox and grid.
  fantasai: I'd like to put effort into merging the wording properly.
  Rossen: Let's resolve on clarifying the definition of what and how a
          FC is created.
  Rossen: Objections?

  RESOLVED: Clarify the definition of what and how a FC is created.

Scoping of the content property unclear
  github: https://github.com/w3c/csswg-drafts/issues/2483

  Loirooriol: If you have style containment and then it says that the
              content property goes to the subtree.
  Loirooriol: It says for the purpose of open quotes etc. It's not
              clear what that means. You can use counter() function to
              read counters without defining any. It's not completely
              scoped. The element behaves like at the root of the tree,
              but if you can read contents from elsewhere it's not
              clear what happens.
  dbaron: I would have thought you create new counter scopes.
  Loirooriol: In another issue it was resolved that the counters are
  florian: We said it's a new counter, but not a new counter scope.
  Loirooriol: Counter is created, for example, but you can't link all
              the counters with a name from outside the tree.

  dbaron: What does the spec say reasons for style containment are.
  TabAtkins: Whenever properties change the style outside of the
             containing element is unchanged and doesn't need to be
             recalculated. When you increment a counter it's not going
             to affect counters.
  florian: So satisfied if you make a new counter scope but you don't
           need to go that far. Chrome ignores what's going on in the
           parent, but I don't believe that's what we resolved. We
           could clarify the previous resolution a bit more.
  Rossen: What would the clarification be?
  florian: I proposed to replace 'etc' with details of the effects of
           the content properties list with the depth of the nesting
           in the tree starts at 0. Wait... we're missing something.
           Counter set and counter increment must be scope to the
           elements of the tree is last item. For open and close quote
           we're not clear what we do.

  florian: Detailing this, [reads text from the issue]
  florian: That's not the point Loirooriol raised. It was also what
           does the counter inside the property do. That's the other
           issue we have left.
  TabAtkins: When you use counter and there isn't one of that name it
             creates a new counter. What happens when it does exist
             outside the style scope. Style containment doesn't
             prevent flowing into, but not flowing out. You should
             still see the outside world's counter. You should see
             that name.
  TabAtkins: Counter set have special behavior because they would
             alter the value outside the tree. But the read doesn't
             cause alteration so it should work as normal.

  florian: This bug and #2349 are both covering this topic.
  florian: If we go piece by piece... for counters do we stick with
           the idea that counter-set and -increment do. But what
           you're saying TabAtkins isn't what chrome does.
  TabAtkins: Given the example in #2483 Chrome behavior seems fine.
             What behavior to you expect?
  florian: 1 and 1.2 because the counter outside exists.
  TabAtkins: The only counter is n on the div.
  florian: But style containment is scoping to element sub tree.
  TabAtkins: True, correct. Yes. Chrome is wrong.
  Rossen: File a bug and leave the spec?
  TabAtkins: It should be 1 and 1.2 So the :before sees a single
             counter and the :after sees two counters. Yes. 1 and 1.2
             is the correct rendering.
  florian: If chrome is okay to align we should clarify the spec but
           not change behavior.
  TabAtkins: Yes.

  florian: So resolve no change to spec, but add examples and improve
           wording to clarify desired behavior.
  Rossen: Obj?
  koji: How do others browsers do it.
  florian: Others don't impl.

  RESOLVED: No change to spec, but add examples and improve wording to
            clarify desired behavior.

  Rossen: Please file browsers bug for everyone that impl this.

  florian: While we clarify I'm suggesting we clarify the exact effect
           on open and close quotes.
  TabAtkins: Why resetting nesting depth?
  florian: That seemed simpler.
  TabAtkins: Nesting depth stays what you inherit from outside.
  florian: Okay, so not what I wrote.
  florian: Changes from must be scoped to sub tree to it starts at
           what it was but changes to the depth of nesting and do not
           effect outside the subtree.
  Rossen: This is clarification part?
  florian: I don't know if you want to resolve separately?
  Rossen: We can resolve on this, but the resolution says we need to
  Rossen: Resolution covers it

Clarify style containment property scoping
  github: https://github.com/w3c/csswg-drafts/issues/2349

  florian: Remaining item is, definition to scoping to a sub tree is
  florian: [reads]
  [Current Spec:
      A scoped property has its effects scoped to a particular element
        or subtree. It must act as if the scoping element was the root
        of the document for the purpose of evaluating the property’s
        effects: any uses of the property outside the scoping element
        must have no effect on the uses of the property on or in the
        scoping element, and vice versa.

  florian: The confusing part is when you're scoping to a sub tree the
           thing that would be the root is outside the sub tree you're
           considering. If you have an element with 2 descendants does
           it mean 2 disconnected roots? I think you mean the element
           is the root for the purposes of styling.
  TabAtkins: That was my intention.
  florian: I think we should resolve this is our intention and we
           should improve the wording.
  florian: [reads proposed text from issue] [Commit with changes:
  TabAtkins: Yep.
  Rossen: Good TabAtkins?
  TabAtkins: Yes.
  Rossen: Objections to adding this clarification to the spec?

  RESOLVED: Add this clarification to the spec.


  florian: We were almost at 0 comments, but just opened one. We're CR
           so let's look at fragmentation some other day and then
  fantasai: You can do CR and say that this is open and we'll fix it
            in the next update.
  florian: I don't think we're in a rush. We'll keep the open issue
           open and when we close talk CR.
  florian: That's it for contain.


Consider making ::slotted and :host take a single argument
  github: https://github.com/w3c/csswg-drafts/issues/2158

  emilio: Single argument prevents discussion about specificity and
          it's simpler to organize.
  rune: Is this the same as matches?
  emilio: Right.
  rune: I don't know how much sense it makes to have this implicit
        matches thing.

  TabAtkins: Spec was clear. People have problems reading work like
  emilio: Spec was clear but impl are shipping with something else.
  TabAtkins: I don't care if we do 0 spec or spec to an argument.  You
             can always nest a matches in there.
  Rossen: I'm hearing people in favor. Objections?

  RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2158

Specificity of :host, ::slotted, and :host-context
  github: https://github.com/w3c/csswg-drafts/issues/1915

  emilio: Also if we want to keep it. Per spec this has specificity of
          normal pseudo class, but there's a request to affect
          specificity of selector. I implemented the spec, but blink
          and webkit don't touch ::slotted. ... whatever we decide I'm
  TabAtkins: Should be consistent.
  Rossen: Anyone have a preference?
  rune: I can't see why we would do it differently.

  dbaron: pseudo class vs pseudo element?
  TabAtkins: No, a selector with a pseudo element adds specificity.
  dbaron: No, it just matches different things.
  emilio: ::slotted does that.
  dbaron: Add pseudo elements to specificity.
  TabAtkins: Like pseudo class when you can opt in to special
  TabAtkins: Should change selectors to ask specificity of pseudo
             element defaulting to none at all.
  TabAtkins: Servo asked for it explicitly with a similar example.
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/2271
  TabAtkins: I'm okay resolving that we make all these pseudo classes
             have the specificity of their elements and clarify pseudo
             elements can have the specificity.
  dbaron: The reason pseudo elements don't have specificity--if you
          have a ::before nothing before can match so there's no point
          in changing specificity when you have exactly one. You can
          change pseudo elements to have a class level specificity.
  TabAtkins: Seems fine.

  Rossen: Proposal?
  emilio: Accounting for the specificity of the selector item and
          change the spec to say pseudo elements have same specificity
          of pseudo classes.
  emilio: If you have ::slotted div the spec would be the class?
  TabAtkins: It would be the same.
  emilio: Override it.
  Rossen: Objections?

  RESOLVED: Account for the specificity of the selector item and
            change the spec to say pseudo elements have same
            specificity of pseudo classes.

CSS Pseudo Elements

::selection style propagation
  github: https://github.com/w3c/csswg-drafts/issues/2474

  emilio: No one does what spec says. So I think we should change the
          spec or all implementations.
  rune: This has been a topic for multiple F2F. I think we covered it
        in 2010.
  rune: dbaron has best overview.
  dbaron: Selection was specified in selectors 3, but didn't say what
          it meant. A bunch of browsers implemented something, then we
          tried to look at what people wanted and expected and I made
          a list of requirements of what it should do. I think we
          picked one but no one adjusted.
  rune: I'm not sure we picked one.
  dbaron: I don't know. Maybe we didn't. Way selection works in most
          browsers isn't useful.
  florian: I think based on the background fantasai specified a thing
           that makes sense and is useful, but it's not what browsers
           do today.

  dbaron: Other question is is the thing spec compat with what's on
          the web today.
  florian: I think underlying is should we try and make it useful. If
           we establish that's the goal by applying to qualifying
           selectors we accept we're willing to go into that level of
           complexity. If we don't accept the premise let's not
           bother. Current spec had the assumption that we wanted to
           bother. Is that true?
  dbaron: The thing in the spec attempts to do useful things for
          selections and styles. Also there were features we wanted to
          build on top of ::selection so we can do things like styling
          spell check region that are on top of this feature.
  fantasai: We added ::grammar-error and ::spelling-error.

  emilio: Annoying part of how it's spec is you need to start
          resolving status to the top.
  fantasai: There's different ways of getting same result. There was
            an alternative way to have selection inherit from itself
            in a separate tree.
  emilio: You have to resolve the entire tree which is different then
          what browsers do. I could say that, but I care about browser
  emilio: Whoever changes the impl first needs to be aware they might
  florian: I don't know. It will do it wrong if you try and use it
           outside unqualified '::selection'.

  tantek: I'd rather see data on actual use.
  TabAtkins: Argument is any current usage that would be affected is
             almost certainly broken.
  tantek: You'd be fine with blink changing ::selection?
  TabAtkins: I would be fine with our impl to change, it would be
             better for users. Only global ::selection is useful right
             now and that wouldn't change.

  emilio: Seems like it would make select-all sort of slow. You need
          to style whole page again.
  TabAtkins: Recascade
  emilio: You pay the cost of selecting the whole page.
  fantasai: Don't have to recascade.
  TabAtkins: Track a full cascade.
  fantasai: ::selection has 4 properties.
  TabAtkins: True.
  emilio: But then special casing that.
  fantasai: Then you just... instead of using cascading you can use
            inheritence through selection tree.
  rune: That's what presto used to do.
  emilio: Somewhat like blink and webkit do for visible
  rune: Works for limited number of properties.
  fantasai: Properties that apply have to be limited because they
            must be non-layout affecting.
  TabAtkins: Most are already inherited. Others can be shifted.
  <fantasai> https://drafts.csswg.org/css-pseudo/#highlight-cascade
  fantasai: And I think there's an open issue about describing it to
            use inheritence.
  fantasai: We can do it either as cascade or inheritance but you get
            same behavior. Main difference is if you use 'inherit'.
  fantasai: Most of the time authors are not setting the inherit
            keyword. Behavior between cascading and inheritance is
            that the inherit keyword behaves differently.
  emilio: Synthetic properties that are usually reset but are not
          inherited for purpose of selection... I don't know.
  TabAtkins: Happy to describe like that.
  emilio: Seems hard.
  TabAtkins: Spec text should be fine.

  tantek: ::first-line has similar issues.
  TabAtkins: Not a great example.
  tantek: Older and has more tests.
  florian: Less constrained because compat. Can effect layout.
  tantek: If you look at the ::selection and apply them to first-line
          you can come up with a reasonable list.
  florian: That the set of properties for ::selection is more
           constrained means you can use more mechanisms.
  tantek: But from user/author it's not clear it should be different
          then ::first-line
  fantasai: I think ::first-line is not related because it's trying to
            solve different constraints.
  <tantek> ::selection is only trying to solve a subset of the
           constraints of ::first-line, which is why it is related and
           worth looking at

  TabAtkins: Pretend everything is inherited make sense?
  emilio: Will people change?
  TabAtkins: We should try.
  florian: Is it priority or disagreement? If browsers agree but don't
           prioritize there are people that have fixing browsers as a
           bug. If the browsers will accept that behavior that's
           different then we would not want to do this.
  emilio: If there's no commitment to impl.
  florian: I'm saying that there might be and a patch might be written.

  dbaron: Other option is put a note in a spec saying it hasn't been
          impl and we want feedback to see if it would work out and
          describe the other thing.
  florian: Other thing being only global is useful?
  dbaron: Yeah.
  fantasai: It's easy to describe current implementation. That's easy
            to describe in 2 sentences and add another for why it
            doesn't work well.
  fantasai: I'm with TabAtkins we should try and make it more useful
            and if that's in terms of inheritence that's fine. I'm
            with TabAtkins that implementing correctly is unlikely to
            break anybody.
  fantasai: I would say if you implement in a way that makes it work
            no one will be mad at Mozilla doing it right.
  fantasai: You have a problem that it's prefixed in your
            implementation. You've got compat on the basic case that
            works so you should unprefix. Separately then make it
  tantek: Reasonable approach. We heard existing unprefix
          implementations are willing to change so that adds weight to
          Mozilla can unprefix assuming we're willing to change.

  fantasai: Prop: Mozilla should unprefix ::selection impl and the
            spec should describe how ::selection of a child gets its
            parent's styles via an inheritance based mechanism.
  florian: Our process prevents Mozilla from unprefixing and we need
           to allow.
  fantasai: We generally recommend you only ship if you're reasonably
            spec-compliant and impls are not and we're saying it's okay
  fantasai: ::selection is cleared for shipping unprefixed even though
            multiple impl do not (yet) follow the spec.
  Rossen: Obj?

  RESOLVED: ::selection is cleared for shipping unprefixed even though
            multiple implementations do not (yet) follow the spec.

  fantasai: Currently ::selection of a child is described with
            cascade. There are edge cases that will behave different
            with inherit.
  fantasai: Proposal is switch to describing using the inheritence
            rather then the cascade.
  Rossen: Current resolution is about cleared for shipping so we need
          the second resolution to change the spec.
  Rossen: Objections?

  RESOLVED: Switch to using inheritance instead of cascade for
            propagating ::selection styles to descendants.

  <br type="15 min">

Received on Thursday, 17 May 2018 07:32:22 UTC