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

[CSSWG] Minutes Telecon 2017-07-05 [motion] [css-flexbox] [css-text] [css-values] [css-align] [css-images-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 6 Jul 2017 20:11:40 -0400
Message-ID: <CADhPm3s1wZGoCuK2nmpBzToEsQQFe_N5L5iEam73104rFbb-KQ@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.

Request to Republish Motion Path

  - RESOLVED: New WD of Motion Path

Alias "nowrap" as "no-wrap"

  - Conversation started with the three options the topic had
      previously narrowed down to:
      1. No change at all
      2. Add dashed version as a parse-time alias
      3. Add dashed version as a new values that behaves the same as
  - The group was divided on if the change was a good idea so
      conversation mostly focused on option 1 vs either 2 or 3.
  - There was very little interest to implement the change quickly
      or at all from vendors so it was decided to close this for now
      and let the advocates see if they can convince anyone else of
      the need.
  - RESOLVED: No change for issue about adding no-wrap

Computed value of a negative calc unit that doesn't allow negative

  - The group did some on the call test cases that showed there
      wasn't currently any interop on this behavior.
  - birtles brought up some concerns around Animations that needed
      further consideration before a decision is reached.
  - Discussion will continue on github.

Trim whitespace around declarations?

  - RESOLVED: trim white space before / after property value in a

Values section shouldn't point wholesale to CSS Level 2

  - RESOLVED: New Values boilerplate

Gradients with a single color stop

  - There was no one strongly championing this proposal, so it will
      stay out of the spec until it finds an advocate.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jul/0001.html

  Tab Atkins
  David Baron
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Chris Lilley
  Myles Maxfield
  Rachel Nabors
  Theresa O'Connor
  Naina Raisinghani
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Rachel Andrew
  Rossen Atanassov
  Bert Bos
  Tantek Çelik
  Benjamin De Cock
  Tony Graham
  Vlad Levantovsky
  Rachel Nabors
  Anton Prowse
  Shane Stephens

Scribe: dael

  astearns: As always does anyone have any extra things to add to
            the agenda. With the caveat that the CSS 2 issue just
            raised should go to next week.
  fantasai: Right.
  astearns: Anything else?

  astearns: One thing to point out is we have a month before Paris
            meeting. If people can add agenda items and add yourself
            to the wiki that would be great.
  <dbaron> https://wiki.csswg.org/planning/paris-2017

Rec next steps

  astearns: Is anyone blocked or have progress not on ML?
  Florian: In terms of extra progress fantasai has done quite a bit
           of the review I asked for. I need to respond to her
           comments, but progress is made.

  Florian: ChrisL where are we on publication for CSS contain?
  ChrisL: I'm not sure. I'll get back to you after the call.
  fantasai: What are we publishing?
  Florian: CSS Contain to CR.
  fantasai: Ah. I just found some issues.
  Florian: That's good. Do you want to report them on CR or delay CR?
  fantasai: I don't know. It's possibly a major problem. It's about
            how the paint containment is defined. It says becoming a
            formatting context and that's not defined. It changes
            the display value at use time which you can't do because
            you have to construct the box tree first.
  fantasai: I don't know what you want to do for these things where
            you're defining in not defined behavior. We can figure
            out a definition or say contain doesn't apply to certain
  Florian: Not sure I want to fix that off the top of my head, but
           sounds like it needs to be addressed.
  <fantasai> Florian, https://github.com/w3c/csswg-drafts/issues/1457

  [missed some discussion due to scribe connectivity issues]

  <ChrisL> On CSS contain, I need to convince ralph that the
           security issue he raised is no existent

Request to Republish Motion Path
  Scribe: fantasai

  <astearns> https://lists.w3.org/Archives/Public/www-style/2017Jul/0000.html
  <astearns> request to publish motion path
  <ChrisL> +1 to republish motion path
  <fantasai> +1!!!!!!!!!!!!!!!!!!!!!!!!!!

  astearns: Just a regular WD.
  astearns: Lots of updates since last WD, so we should republish.
            Any comments?
  ChrisL: Might have to be done manually, since FXTF is nominally
          between two WGs. If so let me know, and I'll republish
  <birtles> I'm pretty sure I've been able to publish Web Animations
            (FXTF) automatically
  ChrisL: In practice, CSSWG has taken up FXTF work atm, but anyway,
          let me know if it fails publication automatically and I'll
          do it manually.
  astearns: Objections to new WD?

  RESOLVED: New WD of motion

Alias "nowrap" as "no-wrap"
  github topic: https://github.com/w3c/csswg-drafts/issues/1537

  astearns: Last time we discussed, had 3 alternatives
  astearns: 1 No change at all
  astearns: 2 Add dashed version as a parse-time alias
  astearns: 3 Add dashed version as a new values that behaves the
              same as nowrap
  astearns: There was some discussion on the issue since, but no

  hober: I'm mildly opposed, which is to say that I'm for option 1.
  hober: Alias has a cost, not sure that the benefit is more.
  <dbaron> This is CSS1: https://www.w3.org/TR/REC-CSS1/#white-space
  TabAtkins: I mistype this all the time, and I can't be the only
             person who does it. It's bad keyword.
  TabAtkins: We should have done it right the first time.
  TabAtkins: Would have preferred if we had no-wrap in flexbox and
             nowrap in white-space with additional white-space:
             no-wrap keyword.
  nainar: I'm with Tab, we have multiple people making this error
          within a week.
  TabAtkins: parse-time alias is low-cost. I'm fine with just doing
             it that way.
  astearns: Difference is in CSSOM?
  TabAtkins: yeah.
  TabAtkins: CSSOM will always return nowrap.
  TabAtkins: Benefit is that older tools will continue to work
  TabAtkins: downside is authors might be confused.
  TabAtkins: Full alias does incur more cost on engine
  TabAtkins: parse-time is trivial.

  Florian: Not a strongly held belief, but I think 2 is in-between,
           not really worth it.
  Florian: Doesn't really give a transition path to a better world.
  Florian: If we go with option 3, we can eventually forget nowrap
           ever existed.
  ChrisL: Agree with Florian.
  dbaron: Both option 2 and option 3 have a substantial cost to
  dbaron: If we go with option 2, then ppl who use dash need to know
          that OM doesn't use dash.
  dbaron: With option 3, then it depends on who wrote the CSS rather
          than just being the developers with a dash habit.
  astearns: Your JS has to check for both in option 3.
  dbaron: With option 3 we're imposing cost to developers for a long
  TabAtkins: So all three put cost on developers
  TabAtkins: None seem obviously better.
  hober: If it's a toss-up between all three, the correct choice is
         no change.

  jensimmons: I am always thinking where is CSS going to be in 30
  jensimmons: If we switch to option 3, 30 years from now everyone
              can forget this ever happened. No one will use nowrap.
  jensimmons: I'm into 3.
  TabAtkins: I'm 100% sure minifiers will remove the dash.

  TabAtkins: Option 1 puts mental load on everyone who uses CSS.
             Option 2 only puts it on ppl who deal with OM, which is
             a much smaller class.
  TabAtkins: I don't have an opinion on 2 vs 3
  TabAtkins: But do feel strongly about 1
  <jensimmons> +1 for what Tab just said. Most people writing CSS
               aren’t also writing JS handling that CSS
  Florian: This is also not a property value that is commonly
           manipulated through JS
  astearns: One person in favor of #1, anyone else?
  * hober thought dbaron made a good argument for no change :)
  smfr: I would vote for no change
  <gsnedders> I agree with TabAtkins.
  myles: Me too
  <Florian> Favors 3, not as strongly as Tab.
  <nainar> I'm with Tab on this one. (3 > 2)
  <dbaron> I think I lean towards no change; I don't think getting
           rid of the 'nowrap' value at some indefinite point in the
           future is realistic.

  astearns: So Apple against change, Google for some kind of change,
            and some arguments for change being #3 in order to make
            future of CSS make more sense.
  hober: My impression was also dbaron was arguing no change?
  dbaron: I lean towards no change, but I see both sides so not that
          strongly in that camp.
  dbaron: But pretty hesitant to agree to do it now
  <leaverou> I'll abstain from this poll, no strong opinion either
             way. I've never ever typed no-wrap personally, or seen
             any student who did, but it doesn't come up all that
  gregwhitworth: I'm with dbaron, no strong opinion. Do know that
                 authors run into it, e.g. postCSS plugin to fix
  gregwhitworth: I wouldn't be in a rush to implement.

  astearns: Sounds like we have no consensus to add no-wrap at this
            time, in either version.
  astearns: One engine interested, and others not so interested, so
            not something to bite off today.
  fantasai: I would add that if we have one engine add and others
            don't, we're in a really bad world, because authors
            using that engine will think it works and in other
            engines it won't.
  astearns: OK, so I'm saying we close this as no change, and the
            ppl who want it can try to convince the others.

  RESOLVED: No change for issue about adding no-wrap

Computed value of a negative calc unit that doesn't allow negative
  github topic:

  TabAtkins: Spec text previously said that you can put negative
             numbers into calc(), it's fine, because we can't in
             general tell if it's negative or not
  TabAtkins: we do a clamping at some point if it needs to clamp to
             a particular range.
  TabAtkins: Spec previously said that clamping happens at computed
             value time, but you can't always tell, e.g. width has
             to happen at used value time (and font-size has to
             happen at computed value time).
  TabAtkins: fantasai and I discussed and realized there are two
             possible interpretations of this conclusion:
  TabAtkins: for properties that clamp at computed value time
  TabAtkins: can clamp through at computed value time.
  TabAtkins: For properties that clamp at used value time, some
             things can clamp at computed value time.
  TabAtkins: So do those properties clamp both at used and computed
             value time, or just at used value time?

  <birtles> I think we want to clamp as late as possible -- since
            animation operates on computed values (more or less)

  Florian: So for multi-stage examples if you can't clamp, you keep
           a calc() expression, right?
  TabAtkins: If you're width is calc(5px-5%) it'll stay as that at
             computed value, clamps at used value.
  Florian: But if you clamp at calc(5px-5em) can clamp at computed
  TabAtkins: If we clamp only at used value time, we need a
             definition of which property is which kind of
  TabAtkins: And then, if we ever add a unit that does used value
             time computation to a property that currently clamps at
             computed value time, it would change behavior.
  TabAtkins: So I prefer clamp at all times behavior.

  dbaron: I was going to say I prefer the other one.
  dbaron: birtles said same thing on IRC, but was thinking about
  dbaron: I was thinking essentially of things like width:
          calc(-5px) vs width: (0%-5px) vs vs width: (10%-5px)
  TabAtkins: You can't add 0% to 1s, so while we technically can
             resolve zero immediately, we would treat it like any
             other percentage.
  dbaron: Still worth thinking about animations.
  <birtles> specifically my concern is you want to interpolate using
            the unclamped values and then clamp
  Florian: If we go that way, pretty important to go the way Tab
           says for 0%, otherwise discontinuity between 0% and

  TabAtkins: Don't understand animations issue.
  TabAtkins: font-size resolves everything at computed time already
  TabAtkins: So animations should see value of 0 for 0px, don't see
             why width should be different.
  dbaron: You can have a calc() that's a result of interpolation.
  dbaron: If one of the end points does different things than the
          intervening value..
  TabAtkins: If the values are different, then the middle value will
             always be a valid value anyway.
  TabAtkins: If it's a used value time unit involved, then it'll
             always stay as a calc()
  <dbaron> (bouncing meaning timing functions that go outside 0-1)
  <birtles> e.g. if you support calc() for opacity and interpolate
            between calc(-1) to calc(3) you'll get different results
            if you clamp the endpoints before interpolating

  Florian: None of these allow us to have results earlier, to get
           fully resolved value at computed value time ..?
  TabAtkins: Just feels nasty and weird if font-size can clamp its
             values at computed value time, but width can't even if
             it uses the exact same value.
  TabAtkins: And also, as I said before, if we add a used-value time
             unit to a computed-value-time-only property, it would
             change behavior
  TabAtkins: observable in animations as well as OM.
  TabAtkins: If we say that a property only has computed value time
             units, then it can never gain a used-value time unit.
  Florian: Why?
  TabAtkins: Because it will change from clamping at computed value
             time to clamping at used value time, seeing raw calc()
             value in the animation
  TabAtkins: Difference is e.g. animated from -1000px to 1000px,
             would stay at 0 for first half if doing used value
             time, and would animate from 0 to 1000px over full
             range if doing computed value clamping.

  dbaron: What do implementations currently do?
  [TabAtkins writes some tests]
  TabAtkins: Looks like in Chrome at least, appears to delay width
             clamping to used value time right now
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5256
  TabAtkins: Spends half of the animation sitting at zero
  TabAtkins: wait, this is inconsistent
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5257
  Myles: Safari does the other behavior. never sticks at zero.
  TabAtkins: Sounds like no interop.
  astearns: Think we should kick this back to github for testing,
            come back with animation data

  astearns: Anything else to bring up on this topic?

Trim whitespace around declarations?
  github topic: https://github.com/w3c/csswg-drafts/issues/774

  TabAtkins: This has impact on what custom property values are
  TabAtkins: Because custom properties capture tokens.
  TabAtkins: Currently the white space before first value token is
  TabAtkins: All of the normal properties serialize out from OM, so
             they get normalized white space output.
  TabAtkins: Some people brought up maybe we should trim the white
             space from beginning and end of a token stream.
  TabAtkins: This would be a tweak to the Syntax spec
  TabAtkins: to throw away this white space.
  TabAtkins: No consequence for ordinary CSS, they will continue to
             parse and serialize as usual.
  TabAtkins: It may or may not have an observable difference on
             serializing a rule of a style sheet... I think they
             generally reserialize from internal structures.
  <gregwhitworth> basically this saves authors from writing trim()
                  when manipulating custom props
  TabAtkins: Would have desired difference on serialization of
             custom property value when ppl write with typical
             whitespace after colon.
  TabAtkins: Saves authors from writing trim(), right, and also from
             forgetting to write trim() because they never have to
             write that for any other property.

  leaverou: Is there any use case where you want the white space?
  TabAtkins: If you're embedding an esoteric language...
  TabAtkins: If you're embedding another programming language into
             CSS you'll have consequences anyway.
  TabAtkins: Don't think any other issue.
  leaverou: So benefit to it, and not hurting any use case. So I'm
            hugely in favor.
  leaverou: Every time I use OM for custom properties, have to use
            trim(), it's really annoying.
  astearns: Proposal to trim whitespace on either side of all
            declarations. In favor / opposed?
  <ChrisL> +1 to trimming
  <fantasai> in favor

  RESOLVED: trim white space before / after property value in a

Values section shouldn't point wholesale to CSS Level 2
  github topic:

  TabAtkins: Issue raised by dbaron on css-align, the values section
             pointed straight to CSS2
  TabAtkins: better to point to more up-to-date specs.
  TabAtkins: This text shows up in many of our specs, so we went an
             updated all of them... we can revert or change as
  TabAtkins: Because it's a wide-ranging change, wanted to get WG
             approval before making part of spec boilerplate
  [New Text:
      This specification follows the <a
        CSS property definition conventions</a> from [[!CSS2]].
      Value types not defined in this specification are defined in
        CSS Values & Units [[!CSS-VALUES-3]].
      Other CSS modules may expand the definitions of these value
      In addition to the property-specific values listed in their
        definitions, all properties defined in this specification
        also accept the <a>CSS-wide keywords</a> keywords as their
        property value.
      For readability they have not been repeated explicitly.

  Florian: Seems to work for vast majority of specs. Have you
           checked it makes sense for specs that don't define
  Florian: Like MQ or Selectors?
  TabAtkins: Those either don't have values section or it worked.
  TabAtkins: One or two specs had an extra line of text, but
             everything that had a value section could take this
             without any addition.

  Florian: If put in bikeshed boilerplate?
  TabAtkins: Defer that question to later.

  TabAtkins: Just wanted to verify the text, and if ppl ok to me
             updating all the specs.
  dbaron: I'm okay with the replacement, but think it could use
          further improvement.
  dbaron: E.g. in Animations we define Animation line, CSSOM defines
          another line...
  fantasai: I think we should have an updated propdef explainer
            somewhere, e.g. snapshot.
  dbaron: Can just make everything hyperlinked.
  fantasai: Yeah, but should have more explanation than just a
  Florian: Did any of the sections to be replaced have anything
           about what dbaron mentioned? If not, it's a strict
           improvement and we can deal with that later.
  TabAtkins: It was definitely outdated, e.g. didn't link to
             CSS-wide keywords because that wasn't a thing.
  TabAtkins: Definitely better than what we have, could improve

  astearns: So you want approval of the changes.
  fantasai, Tab: Yes
  fantasai: And also if there are specific changes desired, resolve
            to have us propagate those or discuss further in GitHub.
  astearns: Proposed to accept this improvement, raise GitHub issues
            for further improvement.

  RESOLVED: New Values boilerplate accepted

Gradients with a single color stop
  github issue: https://github.com/w3c/csswg-drafts/issues/1576

  leaverou: Intended to be allowed in images 3, was prose in the
  fantasai: Actually, no, the CR of gradients did not include it in
            prose or grammar.
  leaverou: But anyway, would like to relax in Images 4.
  leaverou: Doesn't allow a lot of use cases, but it's simple case
            and improves debugging / preview.
  leaverou: Can quickly see the gradient.
  leaverou: Use case of single color image isn't great, because we
            have image() function for that.
  leaverou: I'm fine either way
  leaverou: But would allow it if it was up to me.
  leaverou: Thoughts?
  <dbaron> seems reasonable to me if there aren't compatibility
           issues -- and if implementations can update in a
           reasonably synchronized way

  Florian: Since it's a syntax you could easily accidentally write,
           hoping for it to do something, even though it currently
           does not, there's a non-trivial risk of web pages out
           there relying on it not working.
  Florian: Maybe not, but could be a case.
  leaverou: Could we get stats?
  ChrisL: People wanted to do solid colors and animate ...
  ChrisL: There were people who wanted to have a single color
  leaverou: We have image(<color>).
  ChrisL: Which way should we move people, towards image() or
  TabAtkins: Would prefer to move ppl to image(), much clearer and
  ChrisL: It's also unintuitive to get that effect.
  Florian: If you use it as a start point for an animation, though,
           then linear(blue, blue) is easily written.
  TabAtkins: For animations, you need to match up number of stops
  leaverou: So the main use case seems to be debugging / tooling.

  astearns: We are over time, not hearing any implementers lining up
            for this.
  astearns: Maybe solicit feedback directly from implementers, if
            anyone wants to champion then add back to agenda.
  astearns: If not, shouldn't go in spec

  astearns: Thanks everyone, we're done.
  Meeting closed.
Received on Friday, 7 July 2017 00:12:45 UTC

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