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

[CSSWG] Minutes Telecon 2018-08-29 [css-fonts-4] [css-align] [css-break] [css-contain] [selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 29 Aug 2018 15:38:36 -0400
Message-ID: <CADhPm3veKxMFuedOhPk5iYJ9hY4MTbvdZ10F6Vfz1Ad-d85BsQ@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 Fonts 4

  - RESOLVED: Have computed value always be a percentage and have
              serialization always show a percentage [for
              font-stretch]. Neither deal with keywords (Issue #1671)

CSS Alignment

  - RESOLVED: Take this approach [github:
              and file separate issues for wording issues
  - RESOLVED: Static position alignment keys off of justify-self on
              the abspos, not justify-content on the static position
              CB (Issue #1432)
  - RESOLVED: Publish updated WD for CSS Align

CSS Fragmentation

  - RESOLVED: Have 0 sized fragments pushed to next fragmentainer if
              content before has overflows its fragmentainer (Issue

CSS Contain

  - RESOLVED: Accept change in
              to clarify ink overflow bit only applies to visible,
              clip or a combination
  - RESOLVED: Close with an explanation note in the spec and no change
              ['contain-size' will continue to apply to
              display:table-caption] (Issue #2952)


  - RESOLVED: Accept the proposed change [anything with ::-webkit-*
              prefix is valid at parse time] and add a note to the
              spec explaining why this was necessary to add for web
              compat reasons. (Issue #3051)

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

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

  Rossen Atanasov
  Tab Atkins
  David Baron
  Garrett Berg
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Nigel Megitt
  Thierry Michel
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Sean Voisen
  Fuqiao Xue

  Rachel Andrew
  Jen Simmons
  Jeff Xu

Scribe: dael

  astearns: Anything extra to add or change?

CSS Fonts 4

Computed value for shorthand font: should describe serialization for
    font-variant-css21 and font-stretch-css3
  github: https://github.com/w3c/csswg-drafts/issues/1671#issuecomment-400863224

  myles: There's...the issue here recently has migrated. The thing
         discussed now is the font-stretch
  myles: In L3 font-stretch took keywords. In L4 they're percent
         number so you can animate. That's for variable fonts.
  myles: Issue is about how the computed style of this property should
         be a number of percent rather then keyword or a number
  myles: If you're trying to animated from 'condensed' to 139% if
         computed is percent or keyword you can't animate. Solution is
         always a number and getComputedStyle() function returns
         strings if the computed style is a magic number we define
  <florian> the explanation did make sense
  astearns: Are magic number specified or implementation dependent?
  myles: There's a table
  <chris> its the magic numbers that correspond to the keywords

  myles: Not much of an issue, it's do you want to animate from
         keyword to number. If yes, and I think it's yes, we need
         backwards compat
  florian: Makes total sense to me
  <chris> +1 this seems good to me
  astearns: me too

  emilio: Serialize as number?
  myles: We're discussing now if computed style of font-stretch should
         be a number or as specified.
  emilio: Gecko and blink ship as number so web compat not problem.
  myles: Backwards compat concern is getComputedStyle(). If you set
         font-stretch to a value that used to be a keyword do you get
         number or keyword
  emilio: Number.
  chris: It's serialization of getComputedStyle() and I think there's
         web compat concern on that.
  myles: I guess there isn't much web compat risk if blink and gecko
         give number.
  florian: We can start with that and if there is web compat revisit.

  astearns: Perhaps a note in the draft saying may be web compat with
            always serialize as number and may need magic conversion
            at some point.
  florian: Reasonable.
  <fremy> +1
  astearns: Anyone with evidence that we need magic number to string
            conversion in getComputedStyle()?

  astearns: Proposal: Have computed value always be a percentage and
            have serialization always show a percentage. Neither deal
            with keywords
  astearns: Objections?

  RESOLVED: Have computed value always be a percentage and have
            serialization always show a percentage. Neither deal with

CSS Alignment

Fully specify the "Overflow and Scroll Positions" section
  github: https://github.com/w3c/csswg-drafts/issues/1425#issuecomment-413375688

  astearns: fantasai and TabAtkins made edits. Are you asking for
            dbaron approval?
  fantasai: It looks like we discussed but didn't resolve. Need to
            resolve and get dbaron review
  fantasai: We were trying to spec the behavior of the content
            alignment properties on scroll containers. Content
            alignment when applied to element it adjusts content
            inside it
  fantasai: dbaron asked to tighten. We noticed what we were doing
            fundamentally for a scroll container instead of align by
            layout and then clipping the alignment instead you're
            doing safe alignment and then scroll so you get effected
  fantasai: If you said align-content:end and the content overflows we
            start align and then scroll container so you get same
            effect as if not a scroll container
  fantasai: Tricky thing is scrollable overflow doesn't include
            padding at bottom. Well, might or might not depending on
            UA...open issue on overflow 3. When you scroll to the end
            the bottom of the visible content that overflows lines up
            with the padding edge of scroll container. Needs to be
            content edge for proper behavior.
  fantasai: To get that alignment effect we're going for so switch
            between scrollable and not alignment is same we had to
            spec we extend scrollable overflow area by that amount of
            padding. We extend from edge of inflow content
  fantasai: Authors have asked us to add this.
  fantasai: We have a 'normal' value for alignment that lets us do
            whatever weird things needed for compat. We trigger this
            extra space for scrollable overflow when you have a not
            normal value of align or justify content. That's new in
            spec because didn't look at implications of padding
  fantasai: Asking WG if this is okay and ask for review

  fantasai: Questions or need explanation?
  astearns: Little weird we trigger this on non-normal but I see why
            it's necessary
  astearns: dbaron comments? Want more time?
  dbaron: Need more time to review.
  astearns: Fair enough.
  astearns: Other comments?
  fremy: Like the global idea. Haven't checked details.
  fantasai: Resolve on global idea and check wording later?
  fantasai: Then we have WG resolved this is behavior we want.
            Problems with wording can file a specific issue
  florian: If we could do away with odd compat it would be great. Not
           realistic. This approach does seem to work all but a bit
  florian: Can't think of anything simpler that works and respects
  astearns: Objections to resolve to take this approach and filed
            separate issues for wording issues?

  RESOLVED: Take this approach and file separate issues for wording

  <fantasai> issue about including padding in scrollable overflow area
             -- 12 upvotes, more than pretty much any other issue I've
             seen, + 18 on a comment further down the line supporting
             it https://github.com/w3c/csswg-drafts/issues/129

CSS Fragmentation

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

  fantasai: I added text to spec but realized we said a 0 size
            fragment stays with previous page. Doesn't seem to be
            always because if whatever came before overflows
  fantasai: If I've got an unbreakable box that overflows and a 0
            height after it moves to the next column.
  fantasai: Wanted to check that's what we want.
  fantasai: If anyone wants to look more.
  astearns: Makes sense to me. In your note say can be pushed. Perhaps
            must be pushed?
  fantasai: Makes sense. Change from can to will
  astearns: Okay

  bradk: Should it still be pushed if not content after 0 height thing?
  fantasai: Yeah
  bradk: Create a new column with nothing in it
  fantasai: Might have something in it.
  bradk: That's a useful thing?
  fantasai: It is what happens currently. If something is visible
            generally don't want it below fragmentainer height.
  bradk: Alright, you've convinced me

  astearns: Other concerns?
  <Rossen> Are we still preserving the model of minimizing the number
           of empty boxes due to 0 size fragments
  astearns: Rossen on IRC asks [reads]
  astearns: I think that's restating bradk concern...
  fantasai: We're not. Making sure no element starts below end of
            fragmentainer. Which is good because sometimes can't see
            below end of fragmentainer it gets clipped
  <astearns> Rossen, OK with that?
  <fantasai> see also Tab's note about how this is how Flexbox works
  <Rossen> OK, that's fine. My question was - once an element is to be
           positioned (margins are consumed) and is 0 size - it gets
           placed on the current fragment right?
  <fantasai> If we haven't already overflowed the current
             fragmentainer, yes
  <fantasai> If we've already overflowed, no, it moves to the next one
  <Rossen> OK, that makes more sense, thanks
  astearns: Any other questions or concerns?
  astearns: Objections to have 0 sized fragments pushed to next
            fragmentainer if content before has overflows its

  RESOLVED: Have 0 sized fragments pushed to next fragmentainer if
            content before has overflows its fragmentainer

CSS Contain

Clarify spec text about contain:layout so that its ink-overflow
    effect on a scrollable element is clearer
  github: https://github.com/w3c/csswg-drafts/issues/3023#issuecomment-415885325

  florian: I think this is sort of an editorial mistake. Makes a
           normative difference.
  florian: Layout containment when on spec says overflow is treated as
           ink. Meant if overflow is visible it's treated as ink so if
           content escapes it doesn't trigger scrollbars on an
           ancestor. But if there is scroll we don't have a problem
           triggering scroll so if all is ink we never get scrollbars
  florian: I think this is clarifying, but it is affectively a
           normative change. Are we okay with it?
  astearns: Concerns?
  dbaron: Think I'm okay. Gecko implemented what it said now so we'd
          have to change.
  florian: He's [the Gecko implementor] the one that raised it with a
           comment that what Chrome does is more useful
  florian: Some tests will need fixing too, but I'll do that.
  astearns: Objections?

  RESOLVED: Accept change in
            to clarify ink overflow bit only applies to visible, clip
            or a combination

Maybe 'contain-size' shouldn't apply to display:table-caption?
  github: https://github.com/w3c/csswg-drafts/issues/2952#issuecomment-415890334

  florian: This was raised by dbaron because size containment is
           described as not applying to table parts. Table-caption is
           not a table part. It is intentional.
  florian: Table cells and the like need no size containment because
           general table layout you can't make it smaller than inflow
           content. Trying to do so through containment wouldn't work
           unless we define how it works in terms of layout.
           Table-captions do not have that limitation. No strong
           reason for it to have size containment not work
  florian: Therefore I propose close no change.
  astearns: Even if your reasoning is accepted I think there should be
            a note.
  florian: Perfectly reasonable, yes. Thanks.

  astearns: dbaron does it make sense to you?
  dbaron: I guess...I'm still not convinced table-captions are that
          different in characteristics that matter
  florian: If you take a table cell with some content with width:0 it
           won't have a 0 width. For a caption it will. That's what
           matters here
  dbaron: Table cell with div inside div can be 0.
  florian: On table cell yes
  dbaron: Interesting thing is how sizes interact rather than how
          sizes interact with content
  florian: Size containment changes how you find the size. How it
           influences things around doesn't change.
  dbaron: In both cases you compute the size in a larger process.
          You're saying contain size means contents don't influence
  florian: Yes, you size as if empty, then layout content without
           changing that resolved size.
  florian: It is an undefined operation on table cells, defined on
  dbaron: I'm okay with that.
  astearns: Objections to close with an explanation note in the spec
            and no change?

  RESOLVED: Close with an explanation note in the spec and no change

CSS Alignment

Rules for align/justify-self on static position of
    absolutely-positioned boxes need more detail
  github: https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-415854208

  fantasai: This is a discussion we're hoping to close with 1429
  fantasai: We made a mistake when figuring out effect of alignment
            property on static position. In css2.1 there are rules in
            static position as to which edge you care about. Keys off
            direction of static position containing block of abspos
  fantasai: Since the point of alignment is to replace this model what
            we do for in flow elements we use justify-self to
            determine which side to align to rather then direction
            property of containing block
  fantasai: Initial value being start does do that
  fantasai: For abspos elements we presented rules for how to behave
            and to key off justify-content. Should have been
            justify-self on abspos element
  fantasai: Want to resolve to make that clear.
  fantasai: Proposal: Static position alignment keys off of
            justify-self on the abspos, not justify-content on the
            static position CB

  astearns: Concerns? Questions?
  astearns: Anyone need time or shall we resolve?
  astearns: Objections to static position alignment keys off of
            justify-self on the abspos, not justify-content on the
            static position CB

  RESOLVED: Static position alignment keys off of justify-self on the
            abspos, not justify-content on the static position CB

  astearns: There have been quite a few edits. Good for people to


  fantasai: We'd like to publish updated WD. I understand some people
            want time to review so happy to hold until people review

  fantasai: This resolution [of issue #1432] also closes #1429
  fantasai: Summary- 1429 is now answered yes. The model is that you
            place the element...you take static position offsets and
            use the space between static position containing block
            edge and abspos containing block edge. Set of edges is
            based on justify property
  <fantasai> https://drafts.csswg.org/css-align-3/#abspos-sizing
  fantasai: That's where you size into. Sizing and alignment match up.

  fantasai: Normal WD. Want to publish update. If anyone wants to
            review first, fine. Later is also fine.
  fantasai: This'll bring TR WD in line with recent resolutions
  astearns: Would anyone like time to review before publish?
  <dbaron> I'm fine with publishing a new WD and then reviewing later.
  astearns: Objections to publish updated WD for CSS Align

  RESOLVED: Publish updated WD for CSS Align


Specify the "all ::-webkit-* pseudos are valid" behavior
  github: https://github.com/w3c/csswg-drafts/issues/3051

  TabAtkins: For a long time webkit based browsers had a quirk where
             they accept any pseudo element with ::-webkit-* at parse
             time. Won't match, but it's a valid selector.
  TabAtkins: Firefox found this is causing compat problems for them
             because people had used webkit pseudos in the past to
             select browsers. Firefox realized they had to match the
             rules because people doing browser selection.
  TabAtkins: Proposed we spec that quirk that anything with
             ::-webkit-* prefix is valid at parse time
  TabAtkins: Put that in an appendix of required but obsolete things.
  <TabAtkins> https://drafts.csswg.org/selectors-4/#compat
  emilio: For what it's worth I think most of this isn't even
          intentional. They do ::-webkit-scrollbar something that they
          intend to work and it doesn't in Firefox.

  emilio: If someone knows why webkit has this I'd be curious to know
  TabAtkins: I suspect it was dumb early parsing code and now we can't
             remove. If it looks like one of our pseudos let it be
  florian: Maybe also because there's a bunch of webkit pseudos that
           only exist on some elements. Maybe checking if valid
           sometimes was too complex.
  TabAtkins: No, validity of selector can't depend on anything in DOM
  florian: Right, because you can't person didn't want to check
           anything because can't check some valid.
  dbaron: I think in the past unknown pseudos were just accepted.
          Might have been incomplete fix for that.
  plinss: True.
  plinss: That was why double colon was to allow user defined pseudo
          elements for templating system.
  TabAtkins: Regardless of history, it's here. Appears to be necessary
             for compat. Need to spec.

  florian: ::-webkit-*-whatever is an ident or start functional
           notation there?
  TabAtkins: No idea. I think start functional notation, have to check.
  emilio: Doesn't work with functional stuff. In Firefox we only do
  florian: Okay, good. Less insanity is better.
  TabAtkins: Confirmed. Just ident. I'll have to clarify spec text on

  astearns: Concerns with this change?
  astearns: Anyone against it?
  tantek: I'm not against doing it.
  tantek: In light of unproductive comment on github, might be worth
          doing a blog post from chairs about this. Seems like a big
          compat thing to put out there.
  tantek: I figure it's indicative of emotional output. Rather than
          people discover it and think we're doing crazy stuff an
          upfront blog post might defuse it. Say this sucks but here's
          why we have to do it.
  astearns: We can put a post on CSSWG blog.
  astearns: I'll wait until TabAtkins does clarification

  astearns: Other concerns about this?
  <dbaron> It might make more sense to put something clarifying in the
           issue itself rather than having it prominently in the blog?
  astearns: dbaron you're concerned about a blog post because you'd
            rather not call attention?
  dbaron: Don't know if it's worth making that big of a deal. Don't
          feel strong
  fantasai: Agree not make a big deal. If direct concerns we can put
            comments in issue or add expository notes in the section.
            People don't need to know about this in general and I
            don't want to take attention from things that matter. A
            blog post might get in front of some people but it's more
            likely to make more people mad because they know and a
            vast majority of people that don't care just read a blog
  florian: I suggest FAQ of wiki with an entry of why did you spec
           this and web compat with details
  tantek: It's perceived differently if we do this. They'll appreciate
          if we're up front. Much worse if someone says look at this
          crap and puts it on reddit. I agree more people will learn
          in passing but seeing it from WG it's just ho-hum as opposed
          to a 3rd party in another context with exaggeration.
  tantek: Hiding or not bringing something up causes things to blow up
  fantasai: With webkit prefix we had a blog post. It blew up before
            we could post. Secondly a blog post puts the explanation
            in a separate place. If you want in front of people you
            put in spec.
  tantek: Spec bigger is worse.
  <bkardell_> is it not reasonable to do both?
  astearns: I'm convinced by argument that explanation will be in
            spec. You're concerned people will stumble across this and
            make a big deal. People will stumble across spec and blog
            is somewhere else.
  tantek: I'm okay with the FAQ having a long explanation and link to
          that on blog and spec. Don't like polluting spec with
          historical drama. Not what they're for
  fantasai: Don't think it's complex enough for that much text
  fremy: Not sure it's worthy of a blog post. It's minor. I'm pretty
         sure Edge has this already and no one said anything. This is
         weird and no one should use it. Not worth calling attention.
         Few are using.
  <fantasai> +1 to fremy
  astearns: Concern about spec bigger I don't think is founded. I'm a
            fan of bigger specs with reason why decisions get in.
  <dauwhe> +1 to astearns
  TabAtkins: Also why we have stying support for details class=note so
             you can add lots of details without space

  <TabAtkins> Spec is updated
  <TabAtkins> I also folded in a clarification about how to serialize
              them, since annevk brought up that it was technically

  bradk: Blog would get it in front of eyes to get feedback.
  astearns: Don't think we're looking for feedback. There's a known
            compat problems. Fixing because we need to do it - not
            because it's good.
  fremy: It's a terrible idea. I don't want people to know this exists.
  bradk: There's probably people using it as a hack. Curious how big
         of a problem that will be.
  * bkardell_ kind of agrees that proactive seems better.. I'm not
              even sure it has to be official csswg, just a member who
              writes a post we all share is probably ok?
  <TabAtkins> I'm happy to write a quick explanatory note into the
  tantek: astearns I leave it to your judgment. Still think it's a
          good idea to put something out. If you don't think necessary
          I trust your judgment

  astearns: TabAtkins has been mentioning changes. TabAtkins I would
            like a note in the spec explaining and apologizing why
            it's there.
  TabAtkins: Spec is live now, writing explanatory note
  astearns: Objections to change?

  RESOLVED: Accept the proposed change

  astearns: Thanks everyone for calling in.  We'll talk next week on
            APAC time
Received on Wednesday, 29 August 2018 19:39:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:11 UTC