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

[CSSWG] Minutes Telecon 2018-08-22 [css-grid] [css-logical] [css-contain] [selectors-3] [css-break] [css-text-decor-4] [css-overflow] [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 22 Aug 2018 15:21:56 -0400
Message-ID: <CADhPm3uP5zbo0_BJijDnBoeoBFg22KJHDDhZjKWCeXqmzFAVAA@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

  - RESOLVED: Align grid layout static position as content box rather
              than padding (Issue #3020)

Logical Properties

  - RESOLVED: Drop section 5, backgrounds and borders, from logical
              properties. (Issue #3028)
  - RESOLVED: Accept proposal [Have values that affect alignment
              compute in containing block. Values that affect
              alignment of content of a box of an element are computed
              in writing mode of element itself]. (Issue #3013)
  - RESOLVED: The flow relative keyword values compute to themselves,
              not to physical equivalents. (Issue #2821)
  - RESOLVED: Publish a new WD of logical properties.

CSS Containment

  - RESOLVED: Layout containment censors baselines and size
              containment does not (Issue #2995)

Selectors 3

  - RESOLVED: Publish Selectors 3 as PR


  - RESOLVED: Accept the changeset:
              [Change from an allow list to a disallow list for
              break-inside] (Issue #1904)
  - RESOLVED: Specify 0 size elements are positioned as early as
              possible in the fragmentation flow (Issue #1529)

CSS Text Decor

  - The people on the call leaned toward browsers defaulting to on by
      default for text-decoration-skip-ink (Issue #2818), however some
      individuals that had previously been against on by default
      weren't available for the call so discussion will continue on
      Github and this can be discussed on the next APAC timed call (5

CSS Overflow

  - RESOLVED: Rename overflow to block-ellipsis. Rename auto to none.
              Rename ellipsis behavior to auto. (Issue #2561)

CSS Fonts

  - RESOLVED: No change to spec, leave piece of text out (Issue #2430)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Aug/0021.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Dave Baron
  Garrett Berg
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Melanie Richards
  Jen Simmons
  Alan Stearns
  Lea Verou
  Eric Willigers
  Jeff Xu

  Chris Harrelson
  Florian Rivoal
  Sean Voisen

CSS Grid

Static position should use content-box, not padding-box
  github: https://github.com/w3c/csswg-drafts/issues/3020

  Rossen: TabAtkins and fantasai noticed this while reviewing Grid and
          they asked if we should s tick to this or align to
          everything else. Opinions?
  Rossen: TabAtkins is calling in
  fantasai: I imagine he's in favor since we submitted this together.
  <TabAtkins> ^_^
  <dbaron> makes sense to me
  Rossen: We can resolve to align grid layout static position as
          content box rather then padding. Objections?

  RESOLVED: Align grid layout static position as content box rather
            than padding

Logical Properties

Drop / defer border/background logical transforms
  github: https://github.com/w3c/csswg-drafts/issues/3028

  fantasai: This is to drop or defer border and background section.
            There's a bunch of issues against it which we can handle
            but these were put in and sketched out on how to handle
            it. Parts critical for implementing writing modes are not
  fantasai: We propose to defer this section so we can stabilize the
  fantasai: And address these in L2 if we think approach is good
  <fantasai> https://drafts.csswg.org/css-logical/#background-and-borders
  fantasai: Dropping all of section 5^

  Rossen: In favor, but want to hear if others have opinions.
  <dbaron> sounds good to me
  <bradk> +1
  Rossen: Objections to dropping section 5 from logical properties?

  RESOLVED: Drop section 5, backgrounds and borders, from logical

Should the mapping for logical values depend on the element or
    containing block?
  github: https://github.com/w3c/csswg-drafts/issues/3013

  fantasai: Question was about should the mapping for logical values
            depend on element or containing block. Not about logical
            properties, but values like float: inline-start or
            text-align: start
  fantasai: First thing is currently the spec...it was stated values
            compute to themselves. That's first question. Second is do
            you map against containing block or element.
  fantasai: Supposed to depend on kind of element. text:align-start
            needs to map against element. For alignment we use
            containing block so makes sense to do same for float
            because you don't want element to move based on content,
            but rather context
  fantasai: Proposed is no change to spec but clarify the values map
            to themselves.
  fantasai: I copied that in. Does anyone else have comment?

  Rossen: Question. There are...all properties in box model, are they
          defined to resolve against own writing mode?
  fantasai: Yes own. It was sometimes correct and because you have to
            do computation of writing mode with cascade it's much
            easier computation.
  fantasai: It's unfortunate that's the case because there's a lot of
            cases to use containing block writing mode for something
            like margins but we did element's own writing mode for
  fantasai: Don't have same problem for values as they resolve at
            layout time
  fantasai: We should have done issue #2821 first as it talks about

  Rossen: Other opinions?
  Rossen: I asked about box model properties because they are used for
          aligning box and sometimes used to align content inside.
          Align-self and content align properties and values are very
          similar in layout impact so one doing self and the other
          containing block is weird.
  fantasai: align-self:start you use containing block,
            align-self:self-start you use your own writing mode
  fantasai: text-align:start your children is what's being aligned.
  Rossen: Get it. Not making case against it. In same virtue you can
          say position left and right can be used to align-self and
          padding start and end can align content box. From that PoV
          they are similar.
  Rossen: For box model all properties and values compute to writing
          mode of element itself
  Rossen: There is discontinuity here.
  Rossen: Can live with it.

  Rossen: Other opinions or resolve on proposal to have values that
          affect alignment compute in containing block. Values that
          affect alignment of content of a box of an element are
          computed in writing mode of element itself
  fantasai: That's what's spec in grid, flexbox, and alignment
  <bradk> +1

  RESOLVED: Accept proposal

flow-relative values should say what their computed values are
  github: https://github.com/w3c/csswg-drafts/issues/2821

  fantasai: This is that the values we spoke about compute to self,
            not left or right.
  fantasai: This is necessary for text-align property so for
            consistency we should do that for all properties and if we
            don't do that CSSOM physical coordinates won't align
  dbaron: Flip side is that it means anybody looking at computed
          values to act on them has to do something more complicated.
          If a web page looks at computed value they need to consider
          2x possibilities. They might not and therefore have bugs
  fantasai: Yeah but you have to do for inherited properties why treat
            non-inherited differently?
  fantasai: You have to do that on inherited.
  dbaron: Not as strong a case for not inherited ones
  dbaron: and I think there are more of them, or maybe not
  fantasai: Consistency and so author can work in logical coordinates
            if they want to. Make these computed values be what they
            are and if browser needs to worry it should add
            convenience to its code before reporting to the user
  dbaron: What about the CSSOM
  Rossen: I think giving them all the values and having them make the
          choice what to use would be better then the result of calc
          that will mask what value ended up computed and trying to
          piece that back to the value's origin. Especially for
  Rossen: I agree with dbaron it will require a bit more handling on
          user side but probably not that much.
  Rossen: We can always simplify later.
  dbaron: Okay

  Rossen: Other opinions or try to resolve?
  fantasai: Also necessary if keeping previous resolution
  Rossen: Yes, but we could revert.

  Rossen: Objections to CSSOM exposes both logical and physical values
          and the resulting values are that of the cascade?
  Rossen: Is that the summary?
  fantasai: What?...no. Resolution is that the flow relative keyword
            values compute to themselves, not to physical equivalents
  Rossen: Objections to this?

  RESOLVED: The flow relative keyword values compute to themselves,
            not to physical equivalents


  Rossen: This was last logical issue
  fantasai: There's 2 more, but that's what we wanted to resolve
            before publishing
  fantasai: Other 2 significant issues are marked in draft. #3030 and
            #3029. I think those need more time to discuss and
            publishing a draft with them marked as such is good way to
            go forward
  Rossen: Agree. Objections to publishing a new CR for Logical
  fantasai: We're on WD.

  RESOLVED: Publish a new WD of logical properties

  Rossen: We'll try for CR soon

CSS Containment

containment vs baseline alignment
  github: https://github.com/w3c/csswg-drafts/issues/2995

  Rossen: TabAtkins can you do without florian? Or do we punt?
  TabAtkins: We concluded and wanted to see if there are objections.
  TabAtkins: Spec wasn't clear what effect containments have on
             baseline. florian convinced me. Layout containment should
             censor the baseline because it acts like there's nothing
             going on inside
  TabAtkins: Don't have to do layout on contents to layout parent.
             Baseline requires you to know what's inside
  TabAtkins: Size containment does not censor. Baseline doesn't affect
             that size in any way. Sizing works fine and you can
             baseline align
  TabAtkins: Only potential weird is an overflow:visible element it
             can shrink to 0 but still have a baseline.  That can
             happen today, though.
  TabAtkins: Conclusion: layout containment censors baselines and size
             containment no change. Other containments don't matter
  TabAtkins: Sound good?

  Rossen: So this proposal only changes layout containment?
  TabAtkins: Yes.
  TabAtkins: Turns out in Chrome we don't pay attention to size but do
             for layout. We should be able to change. Per spec this
             only changes layout containment.
  Rossen: Okay. Rest is clarification
  Rossen: Reasonable. Seems florian agrees. Other comments?
  <fantasai> +1
  <fantasai> I think this is the correct resolution
  Rossen: Objections to layout containment censors baselines and size
          containment does not

  RESOLVED: Layout containment censors baselines and size containment
            does not

Selectors 3

Selectors PR

  chris: Selectors 3 was...we produced new CR and we have 1 test of
         the 1 errata. CR was just mandatory for patent policy. That
         time has passed and there's no open exclusion. So can resolve
         for PR.
  chris: I see gsnedders asked about test suite. He's got a pull
         request about build system not working for WPT. I don't see
         relevance. This CR is one errata and making it normative. I
         don't see this holds up PR and then REC. Selectors 4 is
         current spec.
  Rossen: Is gsnedders on?
  Rossen: I didn't see regrets from him.
  [seems like no]

  chris: Do we move forward?
  Rossen: I'm in favor. Want to hear from group.
  fantasai: Makes sense
  <astearns> +1 to PR from me
  <tantek> +1
  Rossen: Objections to publish Selectors 3 as PR?

  RESOLVED: Publish Selectors 3 as PR

  Rossen: chris do you need help?
  chris: Fine. Done transition request except for resolution.
  <chris> transition request here https://github.com/w3c/transitions/issues/83


Define behavior for replaced elements
  github: https://github.com/w3c/csswg-drafts/issues/1904

  Rossen: Way replaced elements affected by break-inside properties
  Rossen: Change we made with fantasai to go from a white list to a
          black list of elements
  Rossen: Currently break-inside is spec that it applies to elements
          in normal flow that establish FC or are [list from changeset]
  <fantasai> Changeset is
  Rossen: Currently excludes flexbox, grid, etc. Changed that to be a
  Rossen: Proposal is break-inside applies to all elements except
          [list from issue]
  Rossen: While we did this we noticed break-before and break-after
          weren't applied to grid and flex so we fixed that too
  Rossen: That's the summary. Want to hear from WG if we missed
          anything or if we can resolve.

  plinss: Can we stop using term black list and white list?
  <TabAtkins> +1, blocklist and allowlist
  Rossen: disallow list and allow list
  * dauwhe plinss: +1

  Rossen: Objections to accept the change:
  <bradk> Abspos includes fixed?
  Rossen: Yes bradk it includes fixed
  <bradk> Ok

  RESOLVED: Accept the changeset:

Empty fragment at fragmentainer boundary
  github: https://github.com/w3c/csswg-drafts/issues/1529

  fantasai: About an empty fragment at a fragmentainer boundary.  If
            you have a 0 height block or 0 width inline etc and the
            previous item that if they filled the whole line does the
            0 size element stay on the page?
  fantasai: Specs don't say anything now about where required to break
            so UA can be intelligent.
  fantasai: For 0 size might make sense to spec explicitly
  fantasai: Question is do we want to spec that for fragmentation in
            general or just for flexbox?
  fantasai: flexbox is only place we define that precisely right now.
  <fantasai> because flexbox requires consistency more than
             quality-of-implementation, so its breaking rules are

  Rossen: I believe we discussed in the past. Don't remember if
  Rossen: As far as I recall reason is the empty elements are
          exhausted opportunistically as much as possible. If there
          are empty boxes at the end of fragment we assume they fit.
          Done so you can reduce subsequent fragments.
  Rossen: That makes sense.
  Rossen: Other side is such elements or boxes are used for
          positioning or to create containing blocks or abspos items
          that go in and out for UI
  Rossen: For those cases harder to argue it's better that such items
          are consumed asap or pushed. Again, counter is there are
          avoid break-inside and break-after properties where you can
          use such and control correctly
  Rossen: In both cases makes sense to position and consume empty
          boxes as early as possible on fragmentation where they are
          encountered rather then pushing
  Rossen: That's how I remember previous
  Rossen: Curious if there are other arguments or if we can resolve on
          that and spec it so we don't forget again.

  Rossen: Objections to Spec 0 size elements are positioned as early
          as possible in the fragmentation flow?
  <bradk> +1

  RESOLVED: Specify 0 size elements are positioned as early as
            possible in the fragmentation flow.


  fantasai: Need to do DoC first
  fantasai: Look next week?
  Rossen: Fine.

CSS Text Decor

Consider adding a third value (skip?) for text-decoration-skip-ink
  github: https://github.com/w3c/csswg-drafts/issues/2818

  Rossen: astearns you added this from the F2F. I wanted to hear from
          Emilio or myles or anyone involved
  myles: This is asking for a distinction between off/on/do what
         platform does. For us on and do platform is the same.
         Proposal asks for explicit on. I wanted to know what other
         vendors thought about skipping on by default
  fantasai: I don't think it's by default. Request is a value, doesn't
            mean we change initial. Initial is auto.
  Rossen: Do we need auto?
  fantasai: Yes. Wanted to allow UA to do what it felt like.
  myles: Cool if all browsers decided default was do skipping so we
         could have 2.

  Rossen: Our position is we just finished re-writing inline layout.
          ink-skipping was on my shortlist, but that shortlist wasn't
          short so we didn't get to it. As a targeted behavior we'd
          want on by default once we have it. Just like we enable
          kerning by default. Doable, not super concerning for
  myles: Sounds like you're okay with 2 values
  Rossen: Yes
  myles: We are also happy with 2

  Rossen: Having said that there's no way to force it. If platform
          supports but if it decides on that device it disables you
          can't force it.
  myles: When you produce a product that can have that behavior we can
  Rossen: Fine.
  Rossen: Is Emilio on?

  dbaron: I don't think xidorn wanted it on for all
  myles: Do you remember reasons?
  dbaron: I think some was related to what he saw as default on
          platform. Maybe windows primarily.
  dbaron: Don't remember that well. Underlying was xidorn wasn't
          comfortable with on by default for all.

  myles: Maybe let this go into issue and ask him to comment in issue?
  fantasai: Yeah. Can also take up on Sept 5 call.
  myles: Sounds good
  Rossen: Sounds reasonable.
  Rossen: Let's stop here and move on.

CSS Overflow

'overflow-block' and 'block-overflow' are too similar
  github: https://github.com/w3c/csswg-drafts/issues/2561

  Rossen: florian is not here. Dunno if heycam or rachelandrew are here
  fantasai: I'm in favor of accepting proposal in last comment fwiw
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2561#issuecomment-413144634

  Rossen: Other opinions?
  rachelandrew: I'd agree
  Rossen: Rename overflow to block-ellipsis. Rename auto to none.
          Rename ellipsis behavior to  auto
  <astearns> +1 to block-ellipsis
  rachelandrew: Yes I agree [missed]
  rachelandrew: I agree and as I mentioned in comments I wrote docs
                for MDN and this seemed sensible way to explain it.
  Rossen: We can try and resolve. Objections to rename overflow to
          block-ellipsis. Rename auto to none. Rename ellipsis
          behavior to auto

  RESOLVED: Rename overflow to block-ellipsis. Rename auto to none.
            Rename ellipsis behavior to auto.

CSS Fonts

font-size: 'medium' value is the user's preferred font size
  github: https://github.com/w3c/csswg-drafts/issues/2430

  chris: It seems...I thought this affected implementations and
         rereading it looks like this should be the user's default.
         Apparently it already does impact medium. It's restoring
         language that was in the spec and was removed. Thought it was
         a change, but I no longer object. We can put the language
         back. I'd like to hear if other vendors see a problem.
         Otherwise trivial change.
  myles: One thought. Proposal has changed through issue. In Apr 25
         post from Amelia it says [reads
         I think that's more specific than original text. Helps me
         understand what text trying to say. If we make a change,
         should be one Amelia proposed.
  Rossen: You're okay with changes?
  myles: Yeah.

  dbaron: One thing we've found in past is if you change the meaning
          of medium and default font size meaning many web pages
          break. Turns out to not be a good thing rather then zooming.
          Maybe that's changing as web changes
  myles: One detail, we don't support changing meaning of medium, but
         do support bumping every font size by a percentage. No way to
         affect keywords without affecting font-sizes and that works
  chris: I think that was the basis for my original reluctance. We
         seemed to hope that would work in CSS 1 and 2, but now you
         can zoom entire page and that seems more robust and what
         people do. didn't want to restore on basis of it was in CSS2.

  myles: Question for dbaron. You said if you change definition of
         medium to other then 16 web pages break, but someone in the
         issue said chrome and firefox allow changing definition of
  dbaron: We do have a setting and over time it has gotten more
          hidden, but haven't removed. It's not a great idea to set.
  <astearns> I have changed that setting and have had pages break
  <chris> so we shouldn't really encourage changing it, then

  Rossen: What does that leave for this issue?
  myles: This is a natural pull between browsers custom a11y that they
         do without spec changes vs something normative the spec can
         say about how to improve font sizes. dbaron's comment on how
         browsers evolved their solution and maybe normative spec text
         isn't necessary makes sense. Could go either way
  chris: Could go either as well. Don't want to encourage people to do
         a bad practice
  Rossen: Leaning resolve no change?
  <tantek> I don't think we have enough data to justify a specific
           change on this
  <chris> fine with no change here if WG so resolves
  Rossen: Going to take silence as agree

  Rossen: Objections to no change to spec, leave piece of text out
  <tantek> +1
  <chris> +1

  RESOLVED: No change to spec, leave piece of text out.

  Rossen: We're at top of hour, one more font issue from fantasai
  Rossen: Happy to push if can't resolve in a minute.
  Rossen: Okay, we are done
  Rossen: We'll chat next week. Bye!
Received on Wednesday, 22 August 2018 19:22:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 22 August 2018 19:22:55 UTC