Minutes Berlin F2F 2018-04-12 Thu Part III: FXTF spec-editing, Subgrids, Box Model [css-grid-2][css-display]

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


FX specs location
-----------------

   - When there are FXTF issues that need WG review, editors will flag
     as Needs Review. Chairs will make sure Needs Review issues are
     added to telecon agenda (in an appendix as things that need review
     or input, but won't be discussed on the call).

   - FXTF editors may send email summarizing spec or issue statuses
     to the CSSWG mailing list to bring attention to them as needed.

Publications and Editors
------------------------

   - RESOLVED: New WD for Filter Effects.
   - krit will create a DoC for Masking so that it can be republished.
   - RESOLVED: Add ChrisL and smfr as editors to Compositing and
               Blending
   - RESOLVED: Editors for Geometry are krit and TabAtkins

CSS Grid 2
----------

   - RESOLVED: Remove the dual-axis proposal in favor of per-axis. (Issue #2280)
   - RESOLVED: Publish a new WD of Grid L2 with the removed dual-axis
               proposal.

CSS Display
-----------

   - RESOLVED: ::marker exists on all elements, on ::before and on
               ::after but no box unless it's display: list-item.
               (Issue #1793)
   - RESOLVED: In a block-in-inline split, the block is inside the
               inline in the box tree, and is a sibling of the two
               fragments of the inline in the fragment tree. (Issue
               #1477)
   - RESOLVED: A multicolumn spanner that splits and inline is inside
               of the inline box tree and a sibling to the fragment in
               the fragment tree. (Issue #1477)

===== FULL MINUTES BELOW ======

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

Scribe: dael

FX specs location
=================

   krit: There's a lack of response from CSS WG right now since these
         specs are in the FXTF repo. Especially when they're mentioned.
   krit: Is there anything we can do to make this more visible to CSSWG
         members?
   krit: Many of our issues don't need WG or a proposal can be made
         before WG review. If there's anything editors can do to let
         CSSWG members know their attention is needed. Elsewise please
         keep and eye on that repo.
   Rossen: astearns and I scrub issues with Agenda+ on telecons
   astearns: But krit said some might not need telecon if it gets
             attention in github
   fremy: Should we add a tag that's agenda+ for review so it's sent
          with the agenda but for review?
   Rossen: Agenda+ items get attention because astearns and I are
           getting those regularly. Request is for 'hey FXTF is between
           CSS & SVG can we get more people to actively work on issues
           so they can make it to agenda+'
   florian: There's 2 levels. One is everyone remembering. Then there's
            a review+ tag that you scrub with the agenda+ but you just
            list those in the call agenda.
   Rossen: We have a tag for Needs Review.
   astearns: We only look for agenda+ and needs csswg review. If you
             use the Needs Review for non agenda+ items individuals
             could look at the repo and then Rossen and I can look and
             mention in telecon.
   florian: Just list them in the agenda of things we won't talk about
            but please look. And do that across all repos.

   <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Feb/0009.html
   <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Mar/0039.html
   fantasai: I'll often post a summary status like ^ and I'll say here's the
             status, here's what needs feedback. I don't know how useful,
             but I try and do that to bring attention to issues that need it.
             Maybe this is a useful thing to try.
   krit: FXTF has its own ML, is it okay if I send it to CSSWG as well?
   fantasai: Yeah.
   krit: I don't want to annoy anyone.
   fantasai: Right now it's low traffic because we use github.
   krit: Yes, those suggestions are good.

Publications and Editors
========================

New WD for Filter Effects and CSS Masking
-----------------------------------------

   astearns: What's changed?
   krit: A lot.
   krit: Last publication was 2014 for both.
   astearns: Yes, let's republish.
   ChrisL: Is there an up to date changes section?
   krit: Yes for both.
   ChrisL: Okay.
   <ChrisL> https://drafts.fxtf.org/filter-effects/#changes

   RESOLVED: New WD for Filter Effects

   Rossen: What's the status for Masking?
   krit: Both specs have 12-14 issues, about half can be solved by SVG.
   ChrisL: So Filters isn't a transition. Masking needs a DoC since
           it's in CR as well as a changes section.
   ChrisL: So let's not resolve to publish if we're not there.
   krit: What is needed before I can ask for publication?
   ChrisL: A DoC ready
   fantasai: And we get to review it as well.
   Rossen: So we need to do this before we call for resolution?
   fantasai: Yes.
   krit: There are open issue for masking.
   ChrisL: That's fine. And we don't have to go back to WD.
   astearns: The opens are called out in DoC.

   ACTION krit compile DoC for Masking and bring it back for CR
          publication resolution
   <trackbot> Created ACTION-873

Assigning Editors
-----------------

   Rossen: Compositing and Blending
   ChrisL: I volunteer as tribute.
   eae: I haven't quite managed to convinced people to do it yet.
   Rossen: You can lead by example. :)
   Rossen: We have smfr and ChrisL to edit.

   RESOLVED: Add ChrisL and smfr as editors to Compositing and Blending

   krit: Geometry - it would be nice to have someone familiar with JS in
         general.
   Rossen: Who possesses those powers?
   astearns: It's in CR. Impl status?
   krit: Most UA shipping already. So impl status is pretty good. Have
         to check in detail.
   astearns: People with impl experience would be best editors for spec.
   Rossen: I agree.
   Rossen: For people who are impl this...?

   krit: I said to astearns I'd volunteer but if I do it alone it would
         take longer. It would be preferable if someone with more
         experience.
   TabAtkins: I have the skills but not the time.
   Rossen: Can you teach someone?
   TabAtkins: I can help.
   astearns: Anyone at Google you can delegate?
   TabAtkins: Possibly?
   Rossen: Mozilla? Anyone good with webIDL?
   Rossen: So we have krit.
   emilio: Cameron has the right experience.
   Rossen: TabAtkins should we put you there for now and you transfer?
   Rossen: Editors for Geometry are krit and TabAtkins
   krit: In general editors are always welcome. ameliaBR would be
         willing but needs funding.

   RESOLVED: Editors for Geometry are krit and TabAtkins

CSS Grid 2
==========

Dual-axis vs. Per-axis Subgrids
-------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2280

   <tantek> Note also that Mozilla (mats) now has a public intent to
            implement on subgrid (on dev-platform)
   Rossen: We took time to review and there's impl feedback from Mats
           that per-axis makes sense and is implementable. So we either
           can discuss more or resolve.
   Rossen: Anything remaining to discuss in this issue before we move
           to adopt this?
   Rossen: Objections to publishing Grid L2 with the per-axis subgrid
           model?

   ChrisL: Is that fpwd?
   Rossen: It is.
   Rossen: Is it?
   Rossen: Did we not publish the original fork?
   fantasai: We did.
   <dbaron> https://www.w3.org/TR/css-grid-2/
   Rossen: So it's an updated WD.
   Rossen: Are there objections to adopt the per-axis model and publish
           a WD?

   rego: There are clear use cases and mats has a working sample. He is
         asking to remove a section and add that the dual axis is
         included.
   Rossen: I'd like to publish as is and then open individual issues
           against it.
   Rossen: Other comments?
   tantek: You don't want to make Mats' changes before publishing?
   Rossen: We open them as separate issues.
   fantasai: Mats is asking to loosen restrictions a bit; and for some
             of it I don't actually understand what he's asking yet.
   fantasai: We need a resolution to remove the dual-axis proposal.
   Rossen: Objections to removing the dual-axis proposal?

   RESOLVED: Remove the dual-axis proposal

   Rossen: The second issues, removing g,h, and i from subgrid should
           that be a separate issue?
   fantasai: I'm happy to remove i. Removing g and h I don't understand.
   Rossen: That's why I suggested a separate issue.
   fantasai: I don't have a problem discussing and republishing in 2
             weeks.
   Rossen: Objections to publishing a new WD of Grid L2 with the
           removed dual-axis proposal?

   RESOLVED: Publish a new WD of Grid L2 with the removed dual-axis
             proposal

   Rossen: Please someone open the g and h as a new issue.

CSS Display
===========

Is ::marker created by display:list-item or does it always exist?
-----------------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1793

   TabAtkins: We all agree on overall behavior. More a question what
              model we want. ::marker pseudo element. Original question
              is decided. It was what things in theory can have
              ::marker pseudo elements. It's only created by thing with
              display:list-item. Theoretical model of the element tree,
              which things have 'display: list-item'.
   TabAtkins: We wanted approval that ::marker elements always existing
              the box tree on elements before or after and they're auto
              suppressed.
   TabAtkins: Other options are if they exist in the tree depends on
              style or say they always exist but not on elements but
              not on pseudo elements ::before or ::after which breaks
              the current behavior for FF and Chrome.
   TabAtkins: Final option is ::marker elements always exist and can be
              on any tree abiding elements. This could mean that
              ::marker pseudos contain ::marker pseudos. Because you
              can't set display on them, though, you'll never see them.
   TabAtkins: Depends on the theoretical model you want.

   emilio: Is that required? Except for ::slotted I think most browsers
           reject multiple pseudo elements at parsing time.
   TabAtkins: Does not require that.
   TabAtkins: That would be good if you actual style nested ::marker.
   emilio: It would mean you can set content before.
   TabAtkins: Ideally you should be able to, but right now you have an
              unstylable marker.

   dbaron: Auto-suppressed?
   TabAtkins: Like how ::before doesn't create a box unless it's
              non-none. ::marker wouldn't have a box unless it's
              contents had display.
   dbaron: Is there a distinction between exists and suppressed and not
           existing?
   TabAtkins: One is a layer violation. It requires us to not
              completely build on the tree until we resolve the styles.
              Right now we can build the element tree fully. This is
              theoretical design and has no practical considerations.

   TabAtkins: We suggest they always exist on elements, ::before and
              ::after
   fremy: Is that all browsers do?
   TabAtkins: Those are all that browsers have always there. If we add
              more we can categorize properly.
   TabAtkins: Objections to my preferred option that ::marker exists on
              all elements, on ::before and on ::after but no box
              unless it's display: list-item.
   florian: If you display: list-item...the initial value of content is
            normal then you get it but if you don't display list item
            is it like a ::before?
   TabAtkins: It does not show up.
   Rossen: Objections?
   <dbaron> sounds good to me

   RESOLVED: ::marker exists on all elements, on ::before and on
             ::after, but no box unless it's display: list-item

   <fantasai> Possible practical implication might be getComputedStyle
              on ::marker?

How does block inside inline affect the box tree, exactly?
----------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1477

   TabAtkins: I recommend looking at the first comment because
              Loirooriol has a great markup example.
   TabAtkins: Basic idea, in the box tree there's a span and a div list
              inside it is it an inline box with a block box inside and
              during fragmentation we split that or does the splitting
              happen at box tree time?
   florian: Observable?
   TabAtkins: Affects how other properties are defined so yes in
              theory. I don't think any property could be used as a
              probe of it. No one uses exact box tree for spec.
   Loirooriol: Saying splitting happens in the box tree is more
               consistent because operations happen in the order. If
               splitting is in box tree we need some kind of exception.
               CSS 2.1 doesn't distinguish between when it happens so
               it's like it happens between boxes.
   TabAtkins: Impl information in FF eq they split and special case
              text-decoration so it propagates down.
   koji: We split spans, wrap it in anonymous box, and for the box we
         split. That last part is same as Gecko.
   <fantasai> https://www.w3.org/TR/css-break-3/#break-decoration might
              need an update
   TabAtkins: Our layout structure doesn't distinguish boxes and
              fragments either. Hard to argue we have one behavior or
              the other.

   fremy: Not sure why we need to know.
   TabAtkins: Affects how we write specs.
   iank: Anything we do with block behavior should stay.
   TabAtkins: Impl details don't matter, it's the theoretical model.
              Being closer to impl matters. We can live with either
              model. We just need to decide.
   florian: Which makes spec writing easier?
   TabAtkins: Split not until fragment time is easier I believe. Makes
              text-decoration easy. Other cases that treat them as a
              single thing work fine in that model.

   dbaron: I worry a bit about making something trivial to define if
           it's actually more complex then implemented. I think it's
           better if the things easy in implementation are easy in spec
           and hard in implementation are hard in spec.
   TabAtkins: Agree.
   florian: That's say split boxes not fragments.
   fantasai: Shows up for box-decoration-break.

   Loirooriol: If splitting happens in box tree, inline assumes if you
               general boxes in that case it uses the box. If one of
               the two inline boxes are chosen it's strange.
   TabAtkins: And both are the principal box because both get all
              properties.

   fantasai: I'd prefer at fragment tree time, and if we want to change
             the parentage maybe that's sensible. I don't think spliting
             in the box tree makes as much sense. I think of this as
             fragmentation so it makes sense to say that that's what's
             happening.
   fantasai: Also, box-decoration-break should be controlling behavior at
             these breaks. We're slicing by default but may want to
             switch to clone. This is how we define how the sides of a
             box that has been split are drawn and if we define them as
             separate boxes we have to define that they behave as
             fragments for this case. If it is a fragment it's not a
             special case.
   florian: Split at fragment level makes a lot more sense. Seems to be
            a difference with impl that don't distinguish, but dbaron
            point earlier that this makes it easier to define hard to
            impl...
   fantasai: Does it? There's a reason why we try to discuss and get
             review and it's to point out where model doesn't make
             sense. I see some reasons for define as fragments and only
             theoretical worries for the other.

   Rossen: The model in fragmentation spec makes a lot of sense to me.
           Early stages of writing draft there was back and forth for
           what is a fragment and what's a principal box. As an impl it
           was a time somewhat odd to map and refer to things not in
           our impl. There's not a principal box in the impl nor do we
           call anything a fragment, but the model matched well.
   Rossen: If the model in the fragmentation spec doesn't make sense
           what do you propose to change?
   fantasai: Didn't say it doesn't make sense? Issue is about block in
             inline splits. Is inline fragmented or of many boxes? A
             lot of impl has a structure that's not one or the other.
             We need the theoretical set up here.
   iank: Eventually we want to move to a model where we use fragment so
         I'm fine that way.
   iank: We don't want to do inline splitting at the box tree level
         eventually.
   florian: I think so long as we have a conceptual model where boxes
            and fragments are different this should be at the box
            level. If we only want to talk about boxes because matches
            impl that's a different conversation.

   dbaron: I think there's another view to it then not having both
           concepts which is that you can keep boxes and fragments as
           terms but view the fragments as what you get when you split
           boxes rather then a later process stage.
   florian: It's a processed box?
   fantasai: Isn't that what fragments are?
   dbaron: That's what I thought until a few weeks ago. However people
           have said things that have made me think differently,
           including this issue.
   florian: I don't think fragments are boxes that have been processed
            in a particular way.
   TabAtkins: As per spec you are right. Fragment tree is the result of
              layout on boxes. You get a different tree out of that.
   florian: Fragments is not a short term to mean a box piece. It's not
            a whole bunch of boxes some of which are fragments.
   fantasai: A box is composed of one or more fragments.
   florian: But later in the process we don't have boxes and fragments.
   dbaron: You have a box tree and you go to a fragment tree by
           splitting things up.
   dbaron: A box corresponds to one or more fragments. If the box has
           children those are in one or more of the children.
   fantasai: This is the case where it's not clear that's happening.
   TabAtkins: In multicol even children might fragment. Putting some
              children in one fragment and one in the next is fair.

   dbaron: If box A is parent of box B then any fragment of box B will
           have a parent of fragment A.
   fantasai: How we lay this out, they don't act like their the child of
             the parent. Layout wise it behaves like a sibling and lays
             out that way. Same is true of block. It lays out as if
             it's a sibling of the anonymous block before and after.
   florian: It changes the variant but it doesn't change that you can
            consider the fragment tree as a processed version of the
            box tree. There's a little re-parenting but not a lot.

   Rossen: I'm trying to get to a model that makes sense. What's the
           model we define in the fragmentation spec in your mind?
   dbaron: I didn't see the fragmentation spec as contradicting my
           model.
   fantasai: It doesn't because it doesn't talk about block-in-inline
             splits and column spanners.
   TabAtkins: It's fragmenting easy cases.
   Rossen: Is it easy? If you have a whole bunch of open inline
           elements, open spans, and text inside that generates some
           line effects and then a block element that breaks this line
           flow. At that moment what do you have?
   dbaron: In my mental model? One of the things about the blocks
           inside is that some ways they act like not a child like
           backgrounds but for relpos they act like they are.
   Rossen: If an inline element was an anchor open before and close
           after the block.
   dbaron: I think it's not related to DOM event propagation.
   Rossen: But it's type of hit test.

   florian: When you say some aspects siblings and some not, it's that
            the same as in box tree descendants and in fragments its
            siblings?
   dbaron: If you have it as though there's a thing there is some ways
           and not others it's easier to have the object there and
           disable features then not have it there and re-conjure it
           when you need it.
   fremy: If you have regions it's in 2 elements and your model can't
          have regions. They're in different places of the tree and
          they'll have fragments that aren't related.
   dbaron: It was a model describing how fragmentations worked and I
           didn't mean you have to follow it always. Still feels weird
           to me and I didn't know the spec was different until recently
   florian: For Gecko these are siblings or one child? The block that
            interrupts inlines.
   dbaron: Child of the inline but it is a child of the block fragment
           of the inline and those are kind of special.
   florian: But that's not a conflict. You have a single data structure
            that represents both box and fragment tree. In that single
            data structure there's a thing that keeps the parenting
            relationship. In box tree they're parented in fragment
            node. The object is present in one of the two trees. You're
            just overlapping the two so it's difficult to talk about
            one concept without the other.

   Rossen: Is there a model we can agree on?
   dbaron: I'm fine resolving on it. I just want to recognize it's
           pretty substantive decision.
   Rossen: With that warning. What do people think? Ready to resolve?
   TabAtkins: If people agree, yeah?
   Rossen: Objections?
   TabAtkins: Prop: A block inside an inline is a descendant in the box
              tree and a sibling in the fragment tree.
   fantasai: And the inline is a single box that has been fragmented.
   Rossen: You're agreeing
   fantasai: They're two things, both need to be considered.
   astearns: It's not just the box that the block is a sibling.
   florian: You're agreeing, there's wordsmithing.
   fantasai: I want it clear that there's a single inline that has been
             fragmented. It's saying the block is a sibling that's a
             fragment which is a fragment and there's a following
             fragment doesn't say it's the same box.
   Rossen: Prop: Blocks inside of...
   Rossen: Objections to what fremy is typing?
   <TabAtkins> <inline>foo<block>bar</block>baz</inline> <== 'block' is
               a child of 'inline' in the box tree; 'block' is a
               sibling of two fragments of 'inline' in the fragment
               tree.
   <fantasai> proposed resolution: In a block-in-inline split, the
              block is inside the inline in the box tree, and is a
              sibling of the two fragments of the inline in the
              fragment tree
   <fremy> Proposal: There is one inline box containing one block box
           (in the box tree). In the fragment tree, there are two
           inline fragments, sibling on each side of the block fragment.
   Rossen: What fantasai said is the same. Objections to: "In a
           block-in-inline split, the block is inside the inline in the
           box tree, and is a sibling of the two fragments of the
           inline in the fragment tree"

   RESOLVED: In a block-in-inline split, the block is inside the inline
             in the box tree, and is a sibling of the two fragments of
             the inline in the fragment tree.

   fantasai: One more. Same applies to column spanners splitting a box.
             Same logic applies.
   florian: Same problem but column spanner may break multi levels of
            parents.
   Rossen: They can already have multiple, for inlines.
   Rossen: Agreed?
   Rossen: Proposal: A multicolumn spanner that splits and inline is
           inside of the inline box tree and a sibling to the fragment
           in the fragment tree

   RESOLVED: A multicolumn spanner that splits and inline is inside of
             the inline box tree and a sibling to the fragment in the
             fragment tree.

   fantasai: We forgot anonymous boxes.

   <br type="lunch">

   <fantasai> The block in a block-in-inline split is actually a
              sibling of the anonymous block boxes on either side, not
              of the inline box fragments.
   <fantasai> And in the column case, the spanner is siblings with the
              column boxes

Received on Tuesday, 29 May 2018 20:00:45 UTC