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

[CSSWG] Minutes Telecon 2018-10-10 [css-flexbox] [css-break] [css-contain] [css-transitions] [css-animations] [web-animations] [css-values] [css-text-4] [snapshot]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 10 Oct 2018 19:20:55 -0400
Message-ID: <CADhPm3u+h8HuxYpyK+UZY3BS_H_b3q+Ha96AMNKD73DdG=h7hw@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.


  - RESOLVED: Publish CR Update for CSS Flexbox L1.
  - RESOLVED: Publish CR Update for CSS Fragmentation Level 3.
  - RESOLVED: Republish CR of CSS Contain.
  - RESOLVED: Republish WD for Transitions L1.
  - RESOLVED: Republish Animations WD.
  - RESOLVED: Republish Web Animations WD.
  - RESOLVED: Republish Values & Units L4 WD.

Values & Units 3

  - RESOLVED: Redefine <'property-name'> to strip off top-level #
              multiplier. (Issue #3146)
  - RESOLVED: Update publication of CSS Values & Units L3.

CSS Text

  - RESOLVED: Add text-transform: full-size-kana to Text L3 marked
              at-risk. (Issue #3143)

CSS Animations

  - RESOLVED: Serialize all keyframes as identifiers. (Issue #2435)

CSS Snapshot

  - RESOLVED: Push boilerplate to the end of documents. (Issue #1867)
  - RESOLVED: Canonical propdef should go to OM and applies to propdef
              should go to cascade. (Issue #1139)
  - The snapshot will continue having different short names every year


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Oct/0004.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Garrett Berg
  Tantek Çelik
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Sean Voisen
  Greg Whitworth

  Manuel Rego Casasnovas
  Angelo Cano
  Chris Lilley
  Nigel Megitt
  Melanie Richards
  Lea Verou

Scribe: dael

  Rossen: Let's get started
  Rossen: As usual I'd like to call for any additional items besides
           ones from florian
  Rossen: There's also a publication request for CSS Contain that's
          not on the agenda
  Rossen: Anything else?


Flexbox CR

  <Rossen> https://drafts.csswg.org/css-flexbox-1/#changes
  <Rossen> https://drafts.csswg.org/css-flexbox-1/issues-cr-2017
  Rossen: Changes & DoC links ^
  <astearns> tests for everything in the changes section?
  Rossen: Request for CR republication

  fantasai: 2 open issues but they need more investigation. There has
            been a ton of bug fixes so we should issue an update and
            continue working on those two issues
  Rossen: Agree. With all the fixes made to content distribution
          algorithm they need to be in published version since there's
          implementors shipping
  florian: There is ongoing discussion in AB for what is criteria to
           update CR with open issues. I'm pushing this should be
  fantasai: In this case the open issues are very specific. One it's
            not clear edits are needed and the other is a change of
            behavior request that needs web compat investigation
  florian: Looks good to me

  Rossen: Objections?
  astearns: Tests for everything in changes?
  fantasai: No idea
  Rossen: Good point. If there's no tests we must have issues tagged
          with PRs to updated changes.
  fantasai: I can make sure all issues have needs testcase flag
  Rossen: Okay. Great point astearns.
  Rossen: Other comments or objections?

  RESOLVED: Publish CR Update for CSS Flexbox L1


  Rossen: Same deal. There have been a number of changes made since
          last publication
  <Rossen> https://drafts.csswg.org/css-break-3/#changes
  <Rossen> https://drafts.csswg.org/css-break-3/issues-cr-2016
  Rossen: Changes & DoC links ^

  Rossen: Anything to draw attention to fantasai?
  fantasai: I think most changes were straightforward. One open issue
            I haven't thought about what spec should say. I don't
            think it's difficult, but it's specific and tightly scoped.
  florian: Not opposing, but since list of changes isn't as large as
           flexbox, why not fix the issue before publish?
  fantasai: We could if anyone has feedback on issue. Issue is in
            general you can only break between sibling boxes. I can
            break between pair of paragraphs, but not between first
            <p> and margins, border, padding
  fantasai: However if parent has fixed height so there's a gap, some
            space between margin of last and the parent you might
            break there. In general not ambiguous but for multi col it
            becomes a question of where is the bottom
  dbaron: Broader issue is when the breaking behavior says height
          disappears in some context it makes column balancing weird.

  Rossen: I know this needs to be discussed. I'd prefer we do it as a
          separate issue. Back to publishing and florian's comment.
  florian: I got my answer. We have a bunch of tightly done issues and
           the issue left is gnarly and would delay good fixes from
           being published
  Rossen: And some of the changes were really fundamental. Like if
          something establishes a monolithic box. There's merit to
          republish CR
  fantasai: I'm happy to issue transition request next week so if we
            end up with a solution in the next few days we can fix it
            before the transition happens
  Rossen: If this was enough to spur interest that would be great.

  Rossen: Same comment about testing. We need to flag issues if we
          don't have coverage.
  florian: We have at least one change tested.
  Rossen: Good to hear
  astearns: Note that flagging the issues isn't sufficient. We said we
            wouldn't publish CRs until there are tests to make sure
            that changes were reviewed. I won't die on the hill for
            these because they'll need more CRs, but we should be more
            serious about tests before updates
  fantasai: I think it comes down to who will do the work to write
            tests and no one is willing to. TabAtkins and I were
            against this because we felt it would come to us on tests.
  astearns: It's not just me that wants this, it's the process.
  astearns: I won't die on this hill today, I won't object. But I
            think we should have had the tests in place before we
  florian: Don't disagree. fantasai point is valid too
  Rossen: I think they're both valid. For flexbox we have tests and
          feedback from impl. For specs early in impl that's not the
          case. Fragmentation is in between.
  Rossen: As astearns won't hold us from publishing we will continue
          to encourage tests for all CR or later changes.
  Rossen: By no means is this intended to say that by having this
          process the onus is on the spec editors only. That is not
          the intent. fantasai and TabAtkins should not be responsible
          to make these test changes.
  <astearns> right - the intent is to have someone separate from the
             editors check the changes

  Rossen: Objections to Publish CR Update for CSS Fragmentation Level

  RESOLVED: Publish CR Update for CSS Fragmentation Level 3


  florian: It is a CR update
  <florian> * zero open issues:
  <florian> * DoC: https://drafts.csswg.org/css-contain/issues-2018-cr.html
  <florian> * Change section:
  <florian> * Test suite:
  <florian> * WIP transition request:
  florian: Links ^
  florian: Have test suite for entire spec and delta.
  Rossen: Anything specific to draw attention to for changes put
  florian: Not really. All discussed in group.
  florian: I don't think there's anything controversial. Large part of
           changes were driven in para. with fixing in Blink.
  Rossen: Opinions or objections?

  RESOLVED: Republish CR of CSS Contain

  florian: I want to thank Gerard for writing missing part of test

CSS Transitions

  <Rossen> Changes:
  <Rossen> https://drafts.csswg.org/css-transitions-1/#changes
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Oct/0001.html
  <dbaron> and https://lists.w3.org/Archives/Public/www-style/2018Oct/0003.html

  Rossen: Can anyone take this?
  Rossen: dbaron anything to highlight? Or just republish?
  dbaron: Not familiar with changes so nothing to highlight

  Rossen: Objections to publish WD for Transitions L1?

  RESOLVED: Republish WD for Transitions L1


  <tantek> note:
  Rossen: Let's republish all 3 remaining requests

  RESOLVED: Republish Animations WD

Web Animations

  RESOLVED: Republish Web Animations WD

Values & Units L4

  RESOLVED: Republish V&U L4 WD

  fantasai: birtles and I pulled out computed value of propdef to V&U
            L4 and simplified down. Possible values are 'not
            animatable', 'discrete', 'per computed value', or you can
            give details
  fantasai: It's a generic logic for all various animation lines. I
            took computed value lines and made them more tightly
  fantasai: Nothing special that's different about computed value
            lines, we just need to know how it animates as well as

  <fantasai> https://github.com/w3c/csswg-drafts/pull/3198
  fantasai: I changed most specs, there's a PR TabAtkins pulled for
            the last remaining specs ^
  fantasai: If you're editing one of those specs please look at those.
  fantasai: I'll probably do second pass through computed values
  Rossen: Thanks

  <fantasai> https://drafts.csswg.org/web-animations-1/#animating-properties
  <fantasai> https://drafts.csswg.org/css-values-4/#combining-values
  <dbaron> fantasai, does that handle stuff like repeating lists?
  <fantasai> dbaron, yes

Values and Units 3

Define <'property-name'> notation to exclude listification
  github: https://github.com/w3c/csswg-drafts/issues/3146

  fantasai: This is an issue about our notation syntax.
  fantasai: In CSS 2 we didn't have list valued properties of
            font-family. There was a convenience location where you
            could do name of property in quotes and a angle bracket
            and it meant use this whole property over there.
  fantasai: There's a ton of specs where in CSS2 we could use that
            notation. We have to create non-terminal terms that are
            identical to another property except they're not comma sep
  fantasai: Means property definitions are more obscure. When you look
            at table rather then listing color and then repeating
            there's a new type
  fantasai: I think it would be nice to use this notation. We have to
            unlistify it in order to use it.
  fantasai: I was thinking it might make sense to redefine as the
            property's value space but if it has a top level hash
            multiplier we remove it and take the value space within
            each item
  fremy: Makes a lot of sense. Reasonable
  fantasai: Notation change so it's editorial
  florian: Makes sense to me as well
  Rossen: Other opinions?
  Rossen: Objections?
  <tantek> +1

  RESOLVED: Redefine <'property-name'> to strip off top-level #


  fantasai: Need resolution to update V&U L3
  Rossen: Objections?
  RESOLVED: Update CSS Values & Units L3

CSS Text 4

text-transform: full-size-kana
  github: https://github.com/w3c/csswg-drafts/issues/3143

  florian: We discussed this a long time ago. I was opposed
           originally, but I regret that. Had in spec this value. It
           is meant to be used within Ruby. Because characters in Ruby
           are very small there is a typographical process where you
           use different characters in very small font sizes [gives
  <myles> U+3084 HIRAGANA LETTER YA
  florian: If people do that using the wrong letter in markup speech
           synthesis reads it wrong. So this was proposed to do the
           typographical thing without using a different character.
  florian: Original objection was this is niche and instead of doing
           this we should allow authors to make custom text
           transforms. Wrote a spec for custom, but no one paid
           attention and there have been no additional use cases. So
           there is no slippery slope.
  florian: Another thing is there is an open type feature that can be
           turned on for Ruby and allow fonts to do this. That would
           only work if font you're using has that. But it's not clear
           that it's meant for this effect in Ruby. And as far as I
           know actual fonts don't do that.

  myles: I think the general idea here is good. One thought and
         question. Thought is I don't think font-variant is right. It
         is a unicode transformation. Font features weren't designed
         for this. We should model this as a text-transform. Is there
         ever a situation where Ruby wouldn't want this? Can it be on
         by default?
  florian: I don't think on by default. Semantically it reads
           different. If the font size isn't so small it's unreadable
           you might not want this.
  fantasai: Agree with florian and myles that we should add. This is
            important for a11y. It keeps the underlying text data the
            same while allowing authors to do the style they want. And
            I agree font-variant Ruby is not right. That's about
            changing shape, not changing one letter to another.
  florian: Some authors might not want it because they argue it's not
           a legibility issue, people just got into the habit of doing
           it. If people want to do it is something that's disagreed
           on so it would not work as a default.

  Rossen: I hear support to add this. I also hear we should add this
          to transforms and not variants
  Rossen: Do we have other opinions?

  fantasai: Do we add to L3 or L4 of text? Originally in L3 but was
  Rossen: Reason not to put it in L4?
  fantasai: I think it's simple enough we won't get issues
  florian: at-risk in L3?

  myles: Will spec include list of mappings?
  fantasai: Definitely.

  Rossen: L3 still has quite a bit of open issues. Adding this to L3
          won't delay. Let's add there and not mark at-risk
  florian: I would mark at-risk. We're getting closer to CR
  Rossen: Looking at number of open issues I don't think we're close
  florian: Really?
  Rossen: Please prove me wrong.

  fantasai: We can adjust at-risk later.
  Rossen: Objections to adding text-transform: full-size-kana to Text
          L3 marked at-risk

  RESOLVED: Add text-transform: full-size-kana to Text L3 marked

CSS Animations

Serialize all keyframe names as strings
  github: https://github.com/w3c/csswg-drafts/issues/2435

  fantasai: Question about...as we were going through computed values
            do we need to preserve a distinction between animation
            names that are strings and ones that are identifies
  fantasai: You can use either for keyframes
  fantasai: Main issue afaict is we can't serialize things as strings.
            They have to fundamentally be identifiers. One case we
            can't treat them to compute as the same there's CSS-wide
            identifiers like 'none' where if you wanted to name your
            animation that you can't refer to it in the property
  fantasai: I don't think it's an issue.
  fantasai: Nice if we didn't have to maintain the difference.

  myles: Web compat risk?
  fantasai: If someone relies on web animation name as 'initial'
            'inherit' or 'none' yes. Otherwise no.
  <Rossen> 'auto'

  Rossen: Any other concerns, comments, suggestions?
  Rossen: Objections?
  fantasai: Proposal is serialize all keyframes as identifiers
  Rossen: Objections?

  RESOLVED: Serialize all keyframes as identifiers.

  dbaron: Somethings wouldn't round trip?
  fantasai: CSS wide things. I propose we make them invalid and that's
            why they don't round trip.

  dbaron: Is someone volunteering to change first?
  Rossen: I don't hear any. Are you dbaron?
  dbaron: Not particularly
  fantasai: I believe current behavior was a recent change. 2016.
  fantasai: Before 2016 you could not have a keyframe name that is a
            string. That was a webcompat problem because webkit
            supported a string in that position as animation name. We
            changed to allow strings or idents but decided to keep
            them distinct. Only reason is if you have 'initial' or one
            of those values.
  fantasai: It's really about will we maintain that if you put in a
            string or an ident both end up as an ident
  fremy: We still don't support strings in Edge. If someone is using
         'none' they're doubly failing. I don't feel like making the
         change is end of the world

  dbaron: Other question; are you proposing this for values of
          properties, @keyframes or both
  fantasai: Anywhere accepting a string as an animation name.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/118
  fantasai: Proposal is everywhere issue #118 says we can accept a
            string we treat it at parse time as an ident
  myles: Do we need a rule for idents that aren't 'auto' and the list?
  fantasai: Have that rule already.
  <fantasai> https://www.w3.org/TR/css-values-3/#custom-idents
  fremy: Yes, because you need it for font-family
  <dbaron> font-family is extra-weird

  Rossen: Still not hearing reason to change resolution

CSS Snapshot

Copy document conventions (and conformance?) from 2.1
  github: https://github.com/w3c/csswg-drafts/issues/1867#issuecomment-424755198

  florian: This and next are related.
  florian: This one is there is on the bottom of every spec a section
           about conformance criteria. At some point we moved that to
           snapshot and removed from other specs. I don't think it's a
           good idea because snapshot is a note and normative text in
           a note is not possible. And if snapshot is a WD it wouldn't
           work because it's not intended to be a REC.
  florian: If we want that text normatively referred to we can do
           that, I just don't think snapshot is a good place to do it.
           Also because we have a practice of changing snapshot
           shortname every time we update.
  florian: I would like to not do that.

  Rossen: Reasonable. What do others think?
  fantasai: I like the idea of pulling boilerplate from end of specs.
            We didn't do it because there were issues about
  florian: Snapshot won't get to rec so even if normative we don't
           solve it. Let's put it into something that is stable.
  florian: chrisL agreed in github
  Rossen: Objections?
  <tantek> that sounds like a reasonable solution

  RESOLVED: Push boilerplate to the end of documents

What defines the various fields in the property definition blocks?
  github: https://github.com/w3c/csswg-drafts/issues/1139#issuecomment-424751081

  florian: Next is that at some point we said various entries in
           propdef aren't anywhere and we said we should do in
           snapshot. Now they're mostly not in snapshot. Canonical
           order and applies to line are all that's left. Canonical
           should go to OM and applies to should go to cascade.
  fantasai: Sounds great
  <dbaron> yes, sounds good
  florian: Once we do that there's no reason to have them in snapshot.
  Rossen: Other opinions?
  Rossen: Objections?

  RESOLVED: Canonical propdef should go to OM and applies to propdef
            should go to cascade.


  florian: We got into the habit of having a different shortname every
           time we publish snapshot. I think we should switch to
           having a shortname and republish and let usual process of
           dated drafts.
  florian: There were +1s on GH
  fantasai: We did it as separate so it was a replacement for levels
            of CSS. So it would be possible to refer to a set of CSS
            specs published as a snapshot. So you could go back and
            fix that doc. If it's single stream you can't do that
            because updating changes date.
  florian: What updates did you envision?
  fantasai: Generally we find problems with a draft and we should fix.
            Be it typos or bad wording. We could fix it.
  fantasai: Or we added a propdef table of all properties in a
            snapshot you could regenerate all of them and go back and
            see what properties were in each snapshot
  fantasai: But if we're doing dated we can never add it to older.
  florian: That sounds true.

  florian: Flip side I don't think we've ever done that and this makes
           it harder to update.
  fantasai: If issue is about doing publication process, I can take it
            over. It only takes an hour.
  florian: I'm okay with either, but if it took 3 minutes we'd do it
           more often.
  fantasai: I think the hold up is there's edits that aren't done.
            Publication is pretty straight forward.
  florian: I'm okay with dropping this request. I can try and convince
           you later, but no need today
  florian: I've got the resolutions I wanted

  Rossen: Thanks for joining. We'll pick up remaining items next week.
          Please add TPAC topics if you haven't.
Received on Wednesday, 10 October 2018 23:21:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 October 2018 23:21:49 UTC