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

[CSSWG] Minutes Telecon 2018-05-23 [css-grid-2] [css-text-decor] [css-display] [css-text-3] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 May 2018 20:09:58 -0400
Message-ID: <CADhPm3tvFDv8VZGJDFag3jVjsBuOnMecH+9SXG8X-CFJ+yUtFQ@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.
=========================================


CSS Grid L2
------------

  - RESOLVED: Add fr unit support as min arg inside minmax for Grid
              L2. (Issue #2611)
  - Having a three value syntax for minmax (Example:
      minmax(5em, 2fr, 250px)) will be considered later and separately
      from the rest of Issue #2611.
  - RESOLVED: Accept the edits in
https://github.com/w3c/csswg-drafts/commit/f33560757fcb0c55b8b6b8e2308eb24a92f1e6dd
              around subgrid and grid-gap (Issue #2285)

Text Decor
----------

  - RESOLVED: Accept the proposed changes (to skip unicode punctuation
              characters for emphasis marks with a few exceptions)and
              follow up with unicode [on why there are exceptions]
              (Issue #839)
  - RESOLVED: updated publication of css-text-decor-3 CR

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

  - RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020
              (A block container that establishes a new block
              formatting context is considered to have a used display
              value of flow-root.)
  - RESOLVED: Defer to css-pseudo-4 to address [interaction between
              display:contents and ::first-line] as part of more
              rigorously defining ::first-line cascading/inheritance.
              (Issue #1310)
  - RESOLVED: Defer #1810 and #2365 to later.
  - There are only a few issues remaining for CSS Display so the
      editors plan to request CR possibly as early as next week.
      Anyone planning to do a spec review before that transition
      should do so soon.

CSS Text 3
----------

  - RESOLVED: Accept the proposal in Issue #2682 (make the existing
              word-wrap/overflow-wrap property affect intrinsic sizing)

CSS Contain
-----------

  - RESOLVED: Accept the edits:
https://github.com/w3c/csswg-drafts/commit/94982e838a558e6c66516b3b13e403eae32e27ad
             [to clarify various meanings of 'formatting context']
             (Issue #1457)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0035.html

Present:
  Rachel Andrew
  Rossen Atanassov
  David Baron
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Anton Prowse
  Liam Quin
  Melanie Richards
  Florian Rivoal
  Eric Willigers

Regrets:
  Tab Atkins
  Benjamin De Cock
  Manuel Rego
  François Remy
  Dirk Schulze
  Alan Stearns
  Lea Verou

Scribe: dael

CSS Grid L1 & L2
================

Applying 'justify-content' content distribution is in the wrong place
    in the overall grid sizing algo
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2557

  Rossen: I think Manuel sent regrets. fantasai can you take this?
  fantasai: There was a bunch of discussion on github since adding to
            agenda, so I need to go back over before I could describe
            where it's at.

  [agenda wrangling]
  [debate if can do agenda item #2 without leaverou]
  [we can't]

Allow fr units as min
---------------------
  github: https://github.com/w3c/csswg-drafts/issues/2611

  fantasai: Based on rachelandrew's comment I say we allow length or
            percent but not content based keywords
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2611#issuecomment-386469857
  fantasai: We limited what you can put in min position of minmax in
            L1 because the requests came late. One of the use cases
            was I want fr with a cap of 250px
  fantasai: We wanted that to work. Figured out it's straight forward
            if there's not content based keywords.
  fantasai: Open questions are 1) do we want to allow this, I think
            yes. 2) allow percent in max position and I think we
            should. 3) Should we allow content based keywords in max
            position- no clear use case and complex to impl so I think
            start with no
  fantasai: 4) Do we want to allow a 3 argument minmax where you have
            some kind of explicit min like a content keyword or a
            length and then an fr unit in the middle and a max in the
            top.

  Rossen: Let's go separate. fr unit as a part of minmax first and see
          if we can resolve. Then 3 value.
  Rossen: Are there additional comments or ideas about support of fr
          units?
  Rossen: Proposed addition of fr unit support inside minmax for Grid
          L2. Objections?

  RESOLVED: Add fr unit support as min arg inside minmax for Grid L2.
  <fantasai> minmax(1fr, 250px) is accepted

  Rossen: Secondary issue is should we allow an additional 3rd
          functional value in the middle of min and max used for
          flexing and how that behaves
  <fantasai> question is now minmax(5em, 2fr, 250px)
  Rossen: Additional comments?
  Rossen: What's the primary use case for 3 value?
  fantasai: Right now you can control min or max of fr unit, column
            has to be at least this, but I want 1fr. Or you can say
            1fr but cap. You can't do both. You might want a 0 minimum
            and you want 1fr and a cap of 250px
  Rossen: Basically you want...I see an example...min 5em, max 250px,
          and then 2fr in this case will...
  fantasai: We can come back to this.
  Rossen: Yeeeeeaaah...I'm not sure.

  Rossen: Why isn't that covered by min width?
  fantasai: In a sense it is. You can't do min width on column
  Rossen: Ah this is for columns
  fantasai: Yeah, since fr have implicit auto minimum if you set min
            width on any items we'll use that. So you can kind of get
            there.
  rachelandrew: I've had people ask for this. That's the advice I gave
                is put something on item.
  Rossen: It's achievable using items as a spacer and fr as the min.
  Rossen: I'd be happy to come back. I want to think a bit more on
          this.
  Rossen: If others are ready?
  [silence]
  Rossen: Should we come back to this?
  fantasai: We'll close this and consider the 3 value syntax in the
            future.

subgrid and grid-gap
--------------------
  github: https://github.com/w3c/csswg-drafts/issues/2285

  <Rossen> https://github.com/w3c/csswg-drafts/issues/2285#issuecomment-387255908
  fantasai: Initially when we created subgrid we said you can't
            control the gaps in the subgrid. Request was to be able to
            control. What we're doing is we added text to explain. If
            the subgrid's gap value is different then parent we add
            fake margins to the edges of the items adjacent to one of
            the gaps.
  fantasai: We're kind of doing this for outer edges of items on
            subgrid.
  fantasai: Using the same technique we're handling the differences in
            grid-gaps. afaict this is the behavior authors want.
            Allows gap control, simple from impl view.
  <fantasai> https://drafts.csswg.org/css-grid-2/#subgrid-gaps
  fantasai: It's checked in and you can read text here ^

  fantasai: This is a question of does it sound good to everyone?
  Rossen: I did read this ahead of the call. Doesn't seem difficult to
          impl. Valid use cases. I support.
  Rossen: Other opinions?
  Rossen: Objections to proposed edits?

  RESOLVED: Accept the edits.

  <Rossen> https://github.com/w3c/csswg-drafts/commit/f33560757fcb0c55b8b6b8e2308eb24a92f1e6dd
  Rossen: These the edits?
  fantasai: Yeah

Text Decor
==========

Characters to skip for emphasis marks (text-emphasis)
-----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/839

  fantasai: We discussed and resolved to skip punctuation for emphasis
            marks because that's default expected. There was
            discussion with i18n. I checked in edits to impl that
            decision.
  fantasai: We skip characters in punctuation from unicode with a
            handful of exceptions.
  fantasai: I asked florian to talk to typographers in Japanese
            community. florian recommended adding another character.
  fantasai: Definition is straight forward. There's symbols in unicode
            punctuation so we're effectively re-categorizing. Things
            like @ aren't really punctuation.
  <fantasai> https://drafts.csswg.org/css-text-decor-3/#text-emphasis-style-property
  fantasai: Definition at end of ^
  fantasai: That's where we're at.

  tantek: If we're going to diverge from unicode can we at least file
          a bug against unicode to say we think you made a mistake and
          we're patching it in CSS. To give them strong feedback.
          Elsewise seems bad to diverge.
  chris: Agree.
  tantek: I'm not saying it's wrong, I'm saying push the disagreement
          upstream.
  fantasai: Happy to explain, but because I think unicode general
            category is required to be stable I don't think unicode
            will be able to fix.
  tantek: Let's not assume failure. Let's try.
  Rossen: Okay. It's a valid point. Let's give them the feedback.
          Thanks tantek.
  <dbaron> Unicode has split categories in the past
  <liam> [the feedback may help Unicode in future too]

  florian: I'm in favor of this. As fantasai mentioned I reviewed. I
           reviewed and discussed details with Japanese people and
           according to them it's very subjective. The conclusions
           fantasai came to are in line with the rational they gave.
  Rossen: Great. Any other opinions?
  Rossen: Objections to accepting?

  RESOLVED: Accept the proposed changes and follow up with unicode

Request to update css-text-decor-3 CR
-------------------------------------

  Rossen: Objections?
  Rossen: What's in this update?
  fantasai: There's a DoC and changes list.
  Rossen: Awesome
  Rossen: People can go look
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013
  fantasai: DoC^
  fantasai: Quite a lot
  <fantasai> https://drafts.csswg.org/css-text-decor-3/#changes
  fantasai: Changes ^
  fantasai: DoC is colorful so may have questions, but everything
            should be accounted for
  chris: There's no objections. There's a few with no commenter
         response but as long as we made an effort.
  fantasai: Yeah
  Rossen: I'm not hearing objections to update css-text-decor-3 CR

  RESOLVED: updated publication of css-text-decor-3 CR

  chris: fantasai you'll raise an issue on transitions GH?
  fantasai: Yes.

  florian: fantasai do you want updated WD of L4 too? Or later?
  fantasai: I think L4 needs more work before it's publishable.

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

'flow' inner display type should never establish a BFC
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1550

  <fantasai> https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020
  fantasai: Comment ^
  fantasai: We made an edit "a block container that establishes a new
            block formatting context is considered to have a used
            display value of flow-root."
  fantasai: We believe this is editorial and we wanted to flag the WG
            to confirm it's editorial
  [everyone reads]
  <dbaron> I think this may be hard to know until somebody tries
           implementing this...

  Rossen: You're saying a block container establishing a new fc inner
          display is flow-root
  fantasai: Used inner display of flow-root
  Rossen: Unless multicol?
  fantasai: I don't think we have a display type for multicol. It
            would presumably have same. We're not changing computed
            value, just used. Currently that's just a concept. Only
            effect of flow root is it establishes a BFC.
  florian: I think multicol is described as establishing BFC and I
           think I filed a bug saying that's weird.
  Rossen: Editorial part seems fine.
  Rossen: I'll re-read the spec for multicol.
  Rossen: This particular one seems good.
  fantasai: Multicol is difficult because it's a new type of FC. It's
            not really BFC but there's no display that aligns to it.

  fantasai: I'm wondering what dbaron is concerned about.
  dbaron: I just think...I'm not aware of an impl and I think it's
          complicated and there will be side effects you discover once
          anybody tries to impl
  fantasai: At the moment I think no effect on impl. Only time it will
            start to have an effect is if we start to expose used
            values through OM
  Rossen: As it stands...
  fantasai: That's the intent. If there's a different effect on impl
            it's not editorial.
  Rossen: At the moment it's editorial because there's no impl.
  Rossen: Objections to accepting the proposal
https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020

  RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020

  <rachelandrew> ED of multicol says "A multi-column container
                 establishes a new block formatting context, as per
                 CSS 2.1 section 9.4.1."
  <Rossen> rachelandrew, right, the BFC part is understood, the inner
           display value is what will be interesting to define...
           since it's not really a flow-root
  <rachelandrew> there's no other mention - was trying to find the
                 issue florian mentioned - which I think is this one
                 https://github.com/w3c/csswg-drafts/pull/1588
  <florian> rachelandrew, I was not referring to that issue
  <florian> rachelandrew, I was thinking about this one:
            https://github.com/w3c/csswg-drafts/issues/2582

Interaction of 'display: contents' and ::first-line
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1310

  fantasai: Proposal is defer to pseudo spec.
  Rossen: I support it.
  dbaron: Flip is display: contents is new and ::first-line has been
          around since css 1
  Rossen: Then it's easier to spec in ::first-line
  dbaron: I don't think that's true. I proposed in the past removing
          ::first-line and first-letter...they're very complex
  fantasai: Part of the issue is inheritence and cascade of
            ::first-line and that's underspecified. I think solving
            here means we have to solve in pseudo first so it makes
            sense to solve together.
  fantasai: Either way both features are impl. It's a question of
            which spec do we tackle in.
  tantek: Impl with scare quotes. I'd be interested in seeing any
          interop tests
  fantasai: It's impl for other things, just not this combo of things.

  florian: Regardless of history, fantasai's point there's a
           dependency means we can push it there or be stuck. We can't
           just define in display. So I support the proposal.
  Rossen: Objections to defer to css-pseudo-4 to address as part of
          more rigorously defining ::first-line cascading/inheritance.

  ??: Which spec depends on which?
  fantasai: Defining interaction of display: contents and ::first-line
            is both. display:contents has no open issues. ::first-line
            has "someone please define inheritence" and defining how
            they combine requires that.
  fantasai: Proposal is defer the interaction definition to pseudo
            spec so that it can hold until inheritence is defined
            better.

  emilio: I would say claim ::first-line and display:contents is
          [missed] I think we need to define ::first-line earlier
          because if people want features that mess with layout modal
  emilio: I think if we want to start defining more complex features
          that mess with layout modal we should define these things
          earlier rather then later.
  Rossen: I sympathize. Only counter argument is that for the more
          complex features/layout systems it's not uncommon that we
          would push other horizontal features to the specific areas
          so that they define their own extension rather then trying
          to lump into one spec.
  Rossen: In this case I'm inclined to push complexity of
          display:contents to ::first-line into pseudo because it will
          take longer to define and no reason to hold back
          display:contents for ::first-line.
  emilio: Agree, but shouldn't defer defining infinitely.
  Rossen: Agree. If you have time to work on that people would support
          it.
  emilio: Fair enough.

  Rossen: Other opinions about this? If not we can try and resolve
  tantek: Only other thing...to make interaction a CR blocker. I'm
          fine with the proposal if we define that defining it blocks
          CR.
  fantasai: Not okay
  Rossen: Why is that the case?
  tantek: If you've impl ::first-line then the interaction is a new
          thing introduced by this spec and therefore must be defined
          or it's an outstanding issue which we're not to have when
          enter CR.
  florian: Assuming that other then display:content ::first-line was
           well defined I'd agree. But it's not so I don't.
  <fantasai> +1 to florian
  emilio: Yeah I think the...
  <emilio> I think the undefinedness is on ::first-line
  tantek: Whether or not it's well defined adding another thing makes
          it worse. We have to force resolution.
  fantasai: It'll be forced when trying to move pseudo to CR. It's on
            the to do list.
  Rossen: tantek your point is on the record. We're not close to CR.
          Once we're close we'll try and untangle.
  tantek: I'm worried about another semi-broken feature but I accept
          your approach
  <fantasai> tantek, it's already introduced, so putting it in CR is
             just doing our best to document reality

  Rossen: Objections?

  RESOLVED: Defer to css-pseudo-4 to address as part of more
            rigorously defining ::first-line cascading/inheritance.

Clarify element tree definition
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1810

  fantasai: Most information on how the DOM interaction is speced
            somewhere. It would be nice if we were more coherent and
            had an overview somewhere. But the interactions are
            defined so this is editorial issue
  fantasai: I'm not even sure what parts go into display spec. We have
            to figure out how to fit all the parts together to make
            understandable.
  fantasai: Proposal here is not to tackle that, but defer this and
            #2365 to later rather then block.
  Rossen: Reasonable.

  Rossen: Other opinions?
  Rossen: Objections?

  RESOLVED: Defer #1810 and #2365 to later

Publication
-----------

  fantasai: That's it for display. There's 3 more editorial issues. At
            that point we should be done with display unless we get
            more issues.
  fantasai: Planning to compile DoC and changes and ask for CR maybe
            next week. If you want to review spec now is a good time
            to do that.
  Rossen: Fantastic. I support fantasai CTA to please look at display
          spec. It's been a while since work started and it's so big
          for functionality we should have it done sooner rather then
          later.

CSS Text 3
==========

word-wrap/overflow-wrap: break-word should affect min-content
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2682

  fantasai: Issue is that...there's a number of cases where authors
            are frustrated with elements being bigger then they ought
            to be. Some are because they put overflow:scroll. Other
            set are related to I thought I told the text to be able to
            wrap if it needs to, why is element so big
  fantasai: That's the word-wrap/overflow-wrap:break-word which
            doesn't effect min-content.
  fantasai: There was discussion about word-break:break-word from
            webkit that does effect intrinsic size. We decided we
            wouldn't add that unless FF or Edge said they needed.
  fantasai: proposal is to solve several things. Give the authors the
            behavior that they're expecting so content can shrink down
            in the way they expect since right now if you're auto
            sizing the width is too big to break. It also means we can
            address reasons for the other syntax existing without
            adding the other syntax.
  fantasai: Having the syntactic mess is an awful situation to get in.

  florian: Canonical example is when there is a piece of text in a
           table cell with a long word and the put the
           overflow-wrap:break-word and the word stays long.
  fantasai: It's probably getting more frustrating because effects
            min-content in grid or flexbox. You put a URL in and say
            you can break, but it pushes out 1fr column for no good
            reason. It's not just in table cells. Flexbox and grid are
            relying on the min-content size.
  florian: Overall if we can do this it's a good idea. Can we or do we
           break compat with negative effects? I'm not too pessimistic
           but want to make sure.
  fantasai: It's a concern in general, but I think there's enough
            cases where changing behavior gets authors to where they
            want more then it breaks. Cases that will break is when
            you set overflow-wrap to a place where it allows breaking
            but then you're not expecting a break.
  fantasai: Most layouts aren't dependent on longest word. They asked
            for wrapping. I think more likely to fix then to break.
  ??: Seems fair

  Rossen: To be clear blink and webkit have this?
  fantasai: Under a different syntax. We've pushed back on adding that
            syntax. Only difference between them is how the effect
            intrinsic sizing. It's small but super confusing for
            authors. Even if they weren't syntactically similar it's
            still confusing to think in terms of intrinsic size
  Rossen: word-wrap:break-word you take all breaking content?
  fantasai: Just in min size
  florian: word-break controls other things as well, so with
           word-break:break-word you can't do that. With this approach
           you could.
  Rossen: Just wanted to clarify expectations.

  Rossen: Other opinions? Sounds reasonable way forward. Have to see
          what interop looks like
  Rossen: Or compat risk rather
  florian: Yeah
  fantasai: Yeah
  fantasai: Authors will be happy if we fix this. This is a major
            source of frustration with grid and flexbox. Sometimes
            allowing breaks...things get too big
  Rossen: I'm with you.
  Rossen: I'm mostly worried about older content in tables and whatnot
          out in the wild. All the sudden we introduce an adverse
          effect. But I'll let blink and webkit engineers spearhead
          since they have this behavior.

  Rossen: Objections?

  RESOLVED: Accept the proposal in Issue #2682

CSS Contain
===========

Establishing independent formatting contexts
--------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-380357179

  fantasai: There was an action to clarify what a formatting context
            is and how established.
  <fantasai> https://drafts.csswg.org/css-display-3/#formatting-context
  fantasai: re-wrote the definition ^ and added a definition for
            independent formatting context. Example ruby isn't really
            independent. Inline isn't independent of block.
  fantasai: Created the new term, did a lot of edits. Independent is
            what css-contain is trying to do.
  <fantasai> changeset is
https://github.com/w3c/csswg-drafts/commit/94982e838a558e6c66516b3b13e403eae32e27ad

  florian: I reviewed it, I like it.
  Rossen: Anyone else review?
  Rossen: Anyone want to review before resolving?
  [silence]
  Rossen: Objections to accepting the edits

  RESOLVED: Accept the edits

  Rossen: That's it for today. Have a great day, talk to you next week.
Received on Thursday, 24 May 2018 00:10:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 May 2018 00:10:56 UTC