W3C home > Mailing lists > Public > www-style@w3.org > July 2018

Minutes Telecon 2018-07-18 [css-fonts-4] [css-display] [cssom-1] [css-overflow] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 19 Jul 2018 05:01:13 -0400
Message-ID: <CADhPm3sZtMhO-XvgM06FwfvOfmwmQ-M8kQ72YY1jUPHqHKuc6Q@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Fonts 4

  - RESOLVED: Add Chris Lilley as editor to fonts 4

CSS Display

  - RESOLVED: Keep it that blockification and establishing formatting
              context are independent (Issue #2673)
  - As a part of the discussion for issue #2673 it was raised that
      part of the reason blockification and establishing a formatting
      context were requested to be linked is the earlier resolution to
      make inline flow-root and inline block the same. Over the next
      week people will re-look at that decision (
https://github.com/w3c/csswg-drafts/issues/1246 )
      and re-open it if necessary.
  - Unless there is a new issue opened, next week there will be a CR
      publication request.


  - RESOLVED: Have the PR https://github.com/w3c/csswg-drafts/pull/2924
              as the start of a set of constraints with Gecko
              algorithm as an example in a note

CSS Overflow

  - RESOLVED: Keep current definition such that we could all lines in
              overflow:clip descendant (Issue #2421)

CSS Text

  - RESOLVED: Handle percent text-indent in intrinsic size box same as
              percent in padding and margin (Issue #1597)
  - RESOLVED: Defer this issue (#2390: Implement or unship
              word-break:break-word) for now [to Level 4]


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jul/0014.html

  Rossen Atanasso
  Tab Atkins
  David Baron
  Garrett Berg
  Oriol Brufau (IRC Only)
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Peter Linss
  Thierry Michel
  Anton Prowse
  Liam Quin
  Manuel Rego Casasnovas
  Florian Rivoal
  Jen Simmons
  Alan Stearns

  Rachel Andrew
  Benjamin De Cock
  Chris Harrelson
  Chris Lilley
  Michael Miller
  Melanie Richards
  Lea Verou
  Greg Whitworth

Scribe: dael

Fonts 4

  astearns: Let's start
  astearns: Does anyone have any last minute changes/additions?
  fantasai: Resolution for chrisl to be editor of fonts 4? Editing
            fonts 3 and not fonts 4 seems like an oversight
  astearns: We didn't get one, but I'm happy to now. Is myles on?
  <myles> yes
  astearns: myles is this okay with you?
  myles: Yes

  RESOLVED: Add Chris Lilley as editor to fonts 4

  astearns: I believe that's in the draft already so it's now official

CSS Display

Blockifications should establish BFC in block containers
  github: https://github.com/w3c/csswg-drafts/issues/2673

  TabAtkins: Oriol has been asking for if blockification should auto
             establish bfc rather then occasionally explicit. fantasai
             and I disagreeing because they don't happen every time
  TabAtkins: If anyone disagrees and things blockification should auto
             be a BFC, great let's talk. If not looking for resolution
             of support

  Rossen: You saying that blocification doens't force BFC?
  TabAtkins: Not intrinsically.
  Rossen: Example?
  TabAtkins: Have to look.
  TabAtkins: Any time we blockify and inline-block does not cause it
             to become a FC it just goes to block
  fantasai: That's true in that it does not change the display
            computation. That's required by backwards compat.
  fantasai: We could change to not change display and also make it a
            formatting context. We do that for float abspos and others
  fantasai: Right now when we do blockification in cases where new
            element will establish new FC anyway. If we apply
            blockification in flow blocks I don't think we'd want new
            FC. Grid items currently blockify and a subgrid isn't a
            new FC
  Rossen: does subgrid blockify?
  fantasai: If we did we'd need an exception. It has to blockify
            because if it's an inline grid it becomes not an inline.
            When it's a grid item...if you have an item inside a grid
            that element is blockified. Blockification if it says
            display inline it becomes block. inline-table become
            block, inline-grid becomes block. But a subgrid isn't a
            new FC because it intertwines with grid outside. Can't say
            it's a new FC, but it is blockified
  fantasai: I don't think we can tie these two concepts together.
            block makes it a block. They almost always coincide but I
            don't think the concepts are intrinsically bound and
            shouldn't be tied in spec
  * emilio agrees with fantasai
  florian: Exception of subgrid this is an editorial twist as to if
           you describe separately or together. So it's editorial.
  <Oriol> But I think a BFC is desired if you have `display: inline
          flow-root`. CSS DIsplay says it becomes `flock flow`, and a
          future feature might blockify without forcing BFC. Then the
          flow-rootness will be lost

  dbaron: I think one other point in the issue from Oriol. I think
          Oriol trying to put in IRC too
  dbaron: Current blockification remove flow-root nature. If
          blockification always makes things FC it's fine. If it
          doesn't then maybe blockification rules need to be fixed so
          if you say flow-root you don't lose that
  fantasai: So far cases where lose flow-root is converting inline
            flow-root or a run-in flow-root. In case of inline-block
            we can't change how display is computed due to backwards
  fantasai: Every other case where flow-root is blockified it
            establishes a new FC anyway.
  fantasai: We're flowing it, we're abspos it, putting it in a grid or
            flexbox. These are cases where element that is a block
            container it establishes a new FC
  dbaron: So in subgrid it's not possible to be a new FC?
  fantasai: Matter of terminology, but fundamental idea of a new FC is
            there's no intertwining between new and old FC. If there's
            info passed through the boundaries when you do something
            like whitespace collapsing it's porous. Same is true for
            display:block, margins collapse through boundary. The
            contents inside and outside participate
  fantasai: New FC creates a barrier without that bleedthrough. The
            justification and alignment doesn't pass through the
            inline-block boundary. Same as a block element with new FC.
  fantasai: For a grid, if you nest a grid inside a grid same thing
            applies. No interactions between grid tracks inside a
            nested grid. Subgrid you do have negotiation between inner
            subgrid context and outer parents and siblings. They
            participate together in sizing algo
  fantasai: The size declarations and names of lines on parent pass to
            subgrid. There is fundamental bleeding through of the
            content and the layout calc. To say it's a new FC doesn't
            make sense.
  dbaron: Makes sense to me. Some point earlier I thought you said
          that...something about how these were still block formatting
  fantasai: Grid items are considered grid level, not block. They
            participate in grid FC. But there is blockificaiton
            process that changes display values to make them
            block-like. We convert anything with a non-block outer
            display to a block
  dbaron: And one of the blockified things can be a subgrid?
  fantasai: You run blockification on every grid item. You run it
            through blockification Might be a no-op, but you run
  fantasai: Was we decided to do subgrid with a new type the
            display-type of a subgrid needs to be declared. If you say
            grid or inline grid doesn't really matter.
  fantasai: Blockification process turns inline on subgrid to grid.
  dbaron: I worried you said display: block could be subgrid
  fantasai: No, you can't
  florian: Blockification is really dis-inline-ification
  fantasai: In a sense. We have outer display type which says how your
            behavior is when in flow layout. Outside of flow layout
            distinction between inline and block has no meaning and is
            ignored. Each display value corresponds to a state.
  fantasai: If I take subgrid and put it in a bfc it will not behave
            as subgrid, but it'll be the fallback behavior.
  <TabAtkins> Core point tho: grid items are blockified, subgrids are
              grid items (by definition) but aren't FCs (by
              definition), so blockification *cannot* imply
              FCification in general.
  fantasai: Whether declared inline or block grid it'll make a
            difference in participation once in block container

  astearns: Back to original issue: We have a choice of keeping things
            as we are where blockification and formatting context are
            discussed separate. Or we changes that blockification
            implies a FC but it can be overwritten in places like
  astearns: Argument that 2 things are separate is compelling to me
            because having both explicit sounds easier to comprehend.
            I like that it's explicit
  astearns: Argument to tie together is that there may be situations
            in the future where we might forget about forcing FC in
            blockification case where we need it to happen. Benefit
            for the explicit call outweighs danger of forgetting to
            make that call in the future.
  <florian> since this makes no behavior difference, this is
            editorial, and I like to leave it up to the editors to
            describe it the way they want. That helps the whole prose
            be coherent
  <AmeliaBR> Is there any consequence of blockification that *is*
             necessary for subgrid? Or can it just be that "grid-items
             are blockified (and create a formatting context),
             *except* for those with `display: subgrid`"?
  <fantasai> AmeliaBR, inline-grid needs to be converted to grid
  <fantasai> ('display' value)
  dbaron: Blockification without FCification doesn't work in a block
          context. In grid it's fine, but in block context it removes
          the things that are supposed to be FC. I think that's a
          piece Oriol doesn't like. Maybe it's that we never will use
          and so it's okay. Might be worth noting.
  astearns: Make sense to call that out in all current cases you need
            the 2 in a block context
  <Oriol> Yes, the problem is with flow layout
  <fantasai> dbaron, I missed exactly the sense of what you said, and
             the first sentence of the minutes doesn't make sense...
  * dbaron thinks the minutes are right
  <fantasai> ... ok, I think I understand. Disagree somewhat, though.
  <myles> are we discussing a behavior change, or just wording in the
  <astearns> myles just wording, afaik

  Rossen: fwiw, from impl experience we've had this model inside our
          engine since IE9. During style computation we independently
          decide inner layout type, outside layout placement (where
          you will be placed), and 2 auxiliary ones, based on the
          layout placement and type we compute if you're a BFC and if
          you require a stacking context.
  Rossen: What I can tell you is they're all independent. But I don't
          see why we should unless from inline-block PoV we have to.

  fantasai: Address point from Oriol and dbaron where if you happen to
            use blockification for block level items
            question...example is an inline-block when blockifies
            turns into display:block which is porous. Argument is
            inline-block should be a block flow-root and a new FC. Not
            convinced of that being the expectation.
  fantasai: I think that's part of why it's not in CSS
            2.1...distinction between block, block layout, and bfc is
            not huge. inline-block vs a block do form a pair.
  fantasai: Formatting context establishment is a side effect because
            they just want this as a block to be a FC, not something
            they specifically needed.
  <Oriol> I think it may be OK if inline-block doesn't become a
          flow-root, but if you explicitly specify flow-root, you
          shouldn't lose it
  fantasai: I'm not sure what you would expect, but becoming
            display:block isn't necessarily unexpected. If you said
            inline flow-root it's clear you wanted that but we're
            getting into fiddly cases and we decided inline-block and
            flow-root are identical
  dbaron: I think this is a negative side effect of that. Prob fine
          for inline-block, but weird if flow-root.

  dbaron: I think I'm okay just concluding here
  astearns: And close no change dbaron ?
  dbaron: I think no change and a note pointing out that it isn't
          great if if you do blockification without FC and people used
          flow-root explicitly
  astearns: Need to ask Oriol if he's okay closing with a note.
  <Oriol> OK, but note that if a future feature allows blockification
          without BFC, then it will be more difficult to change
  astearns: And would anyone else objects to resolve no change except
            adding a note
  fantasai: 3 ways forward, to be clear.
  fantasai: 1) close no change FC and blockification are independent
  fantasai: 2) blockification implies FCificiation so inline-block
            converts to block flow-root and we will need an exception
            for subgrid
  fantasai: 3) revert resolution where we said inline-block and inline
            flow are identical and say they're independent and have
            same behavior except if you blockify.
  fantasai: That lets you when you blockify inline flow-root it
            becomes display: flow-root
  <dbaron> I'd be fine with (3) based on this discussion but I don't
           know why we made that resolution to begin with.
  astearns: We're 30 minutes on this issue. My preference would be
            close no change and raise a new issue on inline-block and
            inline flow-root
  fantasai: We had an issue and resolved on the current. Only reason
            to re-open is if people want option 3 which gets you
            independence for blockification and FCification but also
            clarifies the inline flow-root.
  astearns: Reopening that with this in mind makes sense and doesn't
            change how we'd resolve here.
  fantasai: Fair enough

  astearns: I'd like to close this.
  astearns: Let's resolve that blockification and establishing FC are
            independent and we will add a note on the flow-root issue
            which can become a github issue to change our previous
  <Oriol> Works for me
  fantasai: This is last open issue before CR so we need to open the
            issue or go to CR
  astearns: Objections to keep blockification and establishing FC are

  RESOLVED: Keep it that blockification and establishing FC are

  astearns: Anyone think we should take up an issue about inline-block
            and inline flow-root?
  florian: Rather not
  dbaron: Don't know context of original decision so hard to know
  <fantasai> dbaron, discussion at
  astearns: Let's leave at that this week. Those in the discussion
            please decide if open new issue.

  Rossen: Should we resolve on to CR?
  astearns: Let's give another week and go to CR next week.


Replace steps of set a CSS declaration with some constraints
  github: https://github.com/w3c/csswg-drafts/pull/2924

  emilio: Issue is that the latest resolution on how set property
          behaved: it always appends to end of declaration so it's
          sane with logical prop. It's a nightmare of webcompat and
          perf for Gecko and Blink
  emilio: We turned it off in Gecko and backed out in Blink. xidorn
          had this proposal to let a set of properties in a logical
          group and in a UA dependent way that's in same logical group
          it need to appear after so setProperty behaves correct
  emilio: I think frremy...what xidorn did in gecko which we haven't
          landed is that if you get to the case where a prop and
          there's another from the group that defers we append the new
  emilio: xidorn proposes to define in terms of constraints which I'm
          okay, but prefer define properly. Only reason not to do is
          proposal from frremy. We need to decide if we're fine
          resolving like this or if fine to say it's constraints and
          UA can do what they want or define algorithm in spec

  frremy: From what I recall my proposal was pretty in line with
          constraints. I'm fine with them as defined. Good to have UA
          experiment. If it's fine we can refine further. Fine to go
          with xidorn proposal for now. It makes a lot of sense.
  emilio: Okay
  astearns: I agree, emilio. It's good to have things properly defined
            once we have impl experience and can determine the
            constraints. Happy starting with the PR and adding

  emilio: People fine with gecko algorithm as an example?
  florian: Sounds okay
  astearns: As a note?
  emilio: Pretty much.
  astearns: Objections to having the PR
            as the start of a set of constraints with gecko algo as an
            example in a note?
  frremy: Sounds good

  RESOLVED: Have the PR https://github.com/w3c/csswg-drafts/pull/2924
            as the start of a set of constraints with Gecko algorithm
            as an example in a note

  astearns: Anything else on this?

CSS Overflow

How does max-lines interact with hidden content?
  github: https://github.com/w3c/csswg-drafts/issues/2421

  florian: This started much broader and we're almost done. Just a
           corner case we haven't decided explicitly.
  florian: The broad topic is which lines do we count when we have
           max-lines and a decedent or BFCs or a child also with
           max-lines. We resolved we skip when you nest max-lines.
           Resolved for most of overflow. Remaining bit is
  florian: overflow:clip is not a BFC so it implies you could the
           lines inline overflow:clip. I think close this with no more
           changes needed.

  Rossen: Is the issue different if overflow:clip is applied to
          max-lines container?
  florian: This is on descendant
  Rossen: How is it different then when on max-line container?
  florian: On container it doesn't do anything special and overflow
           not terribly relevant.
  Rossen: But then you can extract same thing happens with child.
  florian: So you're okay no change?
  Rossen: Yes
  astearns: We could lines in descendant with overflow:clip, but only
            not overflowing?
  florian: Count all the lines
  Rossen: Overflow:clip doesn't effect count of lines
  florian: Right
  astearns: Gotcha

  astearns: Objections to keep current definition such that we could
            all lines in overflow:clip descendant?
  fantasai: I think this is correct. Might be initially confusing but
            it's the right model

  RESOLVED: Keep current definition such that we could all lines in
            overflow:clip descendant

CSS Text

Percentage of 'text-indent' against intrinsically sized box?
  github: https://github.com/w3c/csswg-drafts/issues/1597

  florian: Had previous discussion about text-indent and % and we
           resolved which element to resolve % against. Not that
           discussion. This is what do we do when intrinsic sizing. If
           indent grows the size and depends on the size we've got a
  florian: I think we got close to consensus but ran out of time. I
           remember that no one had a use case for % text-indent on an
           intrinsic size thing so easiest is to say % resolves to 0
           and there's no loop.
  florian: Alt is min-content. That works for me too. I don't think
           this is use case driven.
  florian: Only thing to push us toward not-0 is people might want
           large negative % to hide stuff. Dunno if done much with
           text-indent. So I'd go with 0, but min-content is okay
  <Rossen> +1 to 0-
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%3B%20text-indent%3A%2050%25%22%3EThis%20is%20a%20test

  dbaron: I think normal thing in these cases is we resolve to 0
          during intrinsic-width computation and then resolve width
          during layout. Is that what you mean with 0?
  dbaron: I think that's how we treat % padding and % margin.
  <Rossen> what David said ^
  florian: I think that's fine

  astearns: Prop: Handle % text-indent in intrinsic size box same as %
            in padding and margin
  Rossen: This is current behavior as well, we resolve % against
          containing block so we can't resolve them during intrinsic
  astearns: Other opinions?
  <dbaron> (I think this is also what Mats was asking for in the
  <tantek> what Rossen said
  astearns: Obj?

  RESOLVED: Handle % text-indent in intrinsic size box same as % in
            padding and margin

  fantasai: % padding and margin on a child of the element
  dbaron: I think it's the same as on that element
  fantasai: No if you set explicit width resolves correct
  Rossen: Not really. Element is being intrinsically size. That's the
          same so text-indent can't resolve just like you can't do
          min-width etc.
  fantasai: But when you do resolve it's the size of the element, not
            the size of the parent. Which is different then margins
            and padding which look at parent
  Rossen: Don't see how child comes into play. But let's move on.
          We're on same page

Implement or unship word-break:break-word
  github: https://github.com/w3c/csswg-drafts/issues/2390

  fantasai: I think it's that we have issue open about adding
            non-standard word-break:break-word to CSS. Not
            word-break:break-all. This allows you to wrap if you run
            out of room. Should have a property with same behavior
            where word-wrap:break-word effects intrinsic size of
  <tantek> can we get intent to unship by whoever supports it if it's
           not a compat problem?
  fantasai: We were asked to add new value word-break:break-word for
            web compat and we pushed back because it's confusing. We
            said we'd add value if FF and Edge found themselves
            compelled for web compat to impl. They have not so far. To
            not go down that path we made word-wrap:break-word have
            the same behavior that they would have gotten from
  * myles is not following
  <tantek> myles does Safari/Webkit support word-break:break-word? And
           if so, can you unship?
  fantasai: I recommend close no change for the moment. If our
            attempts to stem the webcompat problem is not successful
            we'll assume Edge or FF will file an issue saying we need

  astearns: tantek asked on IRC [reads]
  fantasai: For the moment I don't think we should ask. We should give
            time for impl to catch up with word-wrap:break-word
            behavior change so authors can use that in place of
  fantasai: I think we need to give a year or 2 before we ask blink
            and webkit to unship so the web can adapt to standards
            compliant way.
  florian: Also a chance this transition will be less painful since in
           browsers that don't have it, the least bad fallback is to
           use the property we recommend.
  florian: But we can't unship until we ship alternative.
  <emilio> Gecko just implemented, fwiw
  <dbaron> emilio, implemented what?
  <tantek> emilio: oh well, sounds like we're screwed then
  <fantasai> dbaron, https://bugzilla.mozilla.org/show_bug.cgi?id=1472386
  <emilio> tantek: dbaron: The new behavior, I mean, sorry:

  tantek: I wanted to comment that the process that we should wait on
          compat is orthogonal because compat has nothing to do with
          what authors want. Compat is are we screwed by what's in the
          past. If we're screwed waiting won't change it. If we're not
          waiting can make it worse. If you're serious about dropping
          you need to do it asap regardless of if the authors have an
          equivalent feature. You won't avoid compat in the future by
          introducing a future feature. The reasoning is poor
  <astearns> +1 to tantek
  florian: We're inbetween. This is sufficiently used...
  tantek: Is it on the record? I want blink and webkit to say here's
          why we can't unship. Let's not presume unshippability
  florian: I think we have it. Need to find it
  frremy: It was discussed at a F2F and Google said won't unship.
  tantek: Do we have a % number to justify not unshipping?
  frremy: I think they did.
  tantek: If they did did they give us a % for if it drop below
          they'll unship? That's what we need for this to be numbers
  <Rossen> +1 to tantek
  fantasai: Blink contacted site owners asking them to change. Site
            owners didn't want to change because they needed specific
            property behavior. We need time for that.
  <tantek> emilio can you link the FF impl bug or FF intent to ship?
  <emilio> tantek: https://bugzilla.mozilla.org/show_bug.cgi?id=1472386
  fantasai: florian was saying that we're in-between. Usage is not
            high enough that Edge and FF need to impl, but too high
            for chrome and blink to unship. Gecko has implemented new
            property behavior and not non-standard thing
  fantasai: We need to wait for that change to deploy across browsers
            so site authors will change and then reduce web compat
            impact and then let them unship
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2390#issuecomment-380422690
  <tantek> where is the commitment to implement the new property/value
           behavior from others?
  <tantek> is FF the only implementation?

  astearns: We're overtime. Whether or not we can get unship for
            non-standard...Well, this issue is impl or unship so I
            think we can resolve not to add non-standard property but
            unship question is in the air.
  fantasai: My recommendation is we close or defer this issue so it's
            not sitting
  tantek: Let's defer
  frremy: Defer to next level. I like this
  florian: Defer good
  astearns: Objection to defer this issue for now?

  RESOLVED: defer this issue for now
Received on Thursday, 19 July 2018 09:02:13 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:08 UTC