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

[CSSWG] Minutes Virtual F2F 2020-05-07 Part II: CSS Values, CSS Contain, CSS Parser [css-values] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 16 May 2020 06:41:52 -0400
Message-ID: <CADhPm3sRmGAsBhGKRvyJMF4rCRPH9Fs4PUdsNUQtMox8kDrqQg@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 Values
----------

  - In order to create a shorter syntax for conditional values (Issue
      #5009) TabAtkins proposed creating a switch property which
      allows authors to set an integer to toggle between values
  - There was a desire to see if this can be combined with the other
      switch property proposed earlier in the F2F
      ( https://gist.github.com/bkardell/e5d702b15c7bcf2de2d60b80b916e53c )
      in order to avoid two properties doing similar things. There was
      a concern about when these switches run being different, though.
  - Though this syntax is more terse there was a concern that it's not
      easy to read for authors and may not work for every way large
      teams set up stylesheets.
  - It was suggested that a conversation should be had with
      preprocessors to see how they've approached this problem.
  - TabAtkins will add to the github issue a more fleshed out version
      of his proposal for further discussion and review.

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

  - RESOLVED: Add ink-skip-clip-margin property (name tbd) with
              non-negative values (Issue #4934: Add
              contain-paint-margin CSS property), applying to
              boxes with 'overflow: clip' or equivalent.

CSS Parser
----------

  - The proposal to allow trailing commas (Issue #4968: Allow trailing
      comma in gradient functions (and probably others)) is to alter
      the section of the parser for consuming a declaration or
      function to accept an optional comma before the final semicolon
      or closing parenthesis.
  - Concern with doing this broad approach is that it could block in
      any future changes and that it doesn't make sense to allow it on
      a single value property.
  - On the other hand, going property by property was thought to be
      bad for authors, because of the likelihood of inconsistencies.
  - TabAktins will write up more details for the original proposal and
      myles and emilio will look at creating a counter proposal with
      more limited effect.

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

Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-four-time-slot-3b

Scribe: dael

CSS Values
==========

Express conditional values in a more terse way
----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5009

  TabAtkins: Right now if you want to change styles with MQ it's
             stable for a long time. As long as you're doing a
             complete rewrite or tweak small bits it's fine.
             Substantial touches like change colors for dark mode it's
             awkward. Have to repeat all selectors and if you make
             edits to one spot have to do same across all media blocks.
  TabAtkins: Jonathan asked for way to better keep conditional things
             close together and require less repetition when you need
             to modify
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620766100
  TabAtkins: Suggestions in thread. One I liked is a bit down in the
             issue. It's a switch function that takes int as first
             argument and then ; separated arguments that are
             properties. Returns nth of those depending on first
             argument
  TabAtkins: Intention is if setting up colors for high/low contrast
             you can set the MQ to init using switch to call one of
             those and the specific properties. Let's you call them
             without repeating MQ or selectors. When you need an edit
             it's all there
  TabAtkins: If adding more cases you go across switches and add stuff
  TabAtkins: I think I'm super happy with this. No reason to write it
             literally. If you write with a variable as first arg I
             like it a lot to push it to values space rather than keep
             at rules space

  hober: Relationship between this and bkardell's switch() function?
  TabAtkins: No direct relation. Functionality feels similar but
             selecting on an integer vs container size data are
             different. We'll use similar...
  TabAtkins: Similar values handling where they're var-like but
             there's no direct connection
  AmeliaBR: Disagree with that. I don't think there should be two
            distinct switch constructs. Original use case of making it
            easier to condense parallel declarations for MQ I thought
            TabAtkins original proposal looked nicest: to be able to
            nest @media conditions in a declaration block.
  AmeliaBR: Especially with being able to declare custom keywords,
            that's compact and readable.
  AmeliaBR: And integer that's a toggle is not something I see as
            readable. Could be used for the purpose if a generic
            switch function is available. Might be okay because I do
            think a generic switch is useful in CSS. But if talking
            about generic switch it should be in a generic way.
  AmeliaBR: If we're talking about generic switch function it should
            be all use cases, including container query use case. Can
            we break the proposals into constituent parts we can
            combine up?
  AmeliaBR: Proposal in container queries a key part is you can access
            dimension from layout. If a generic way to access that as
            a variable that's resolved at layout or used value time
            and a generic case switch function that's not resolved
            until layout we can put it together and get bkardell
            proposal from last week.
  AmeliaBR: But it could also be used with a regular variable.
  AmeliaBR: I think by separating the 2 feature requests we can
            address both at same time

  florian: In the thread I think I see 2 variants of switch. One
           that's off the integer with ; separator which looks terse
           for short and confusing for long ones. Other is more
           explicit that looks more like a select case where you list
  florian: If you're listing you switch out a variable and also use
           keywords. If you make that explicit you don't have to limit
           to integers. Could go the way where you can use tokens and
           move into other switch function.

  emilio: I had same comment as with switch. I agree it's a good idea
          but don't know why different from calc min() and max()
  emilio: bkardell proposal becomes an optional value in how it's
          resolved later. That way both proposals make sense
  emilio: A weight to conditionals in calc has been proposed before.
          switch can be that.
  emilio: I just don't think we should invent another var-like thing

  <bkardell> for reference
https://gist.github.com/bkardell/e5d702b15c7bcf2de2d60b80b916e53c
  bkardell: Pasted in a link to last week's proposal. Wanted to point
            out the opening and lots of words in there point that it's
            not simply about a point size. It's a single generic
            function that introduces the ability into the css
            lifecycle.
  bkardell: Maybe something to what emilio said but there's value in
            centralizing it. I don't know if he's done it yet but
            original poster said my comments would satisfy use cases.
  bkardell: I'll add that lajava has been doing concrete impl and we
            think from that standpoint it makes sense to do these
            things together

  <AmeliaBR> the nested media query example proposal:
             https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620726494

  jensimmons: I think this is an interesting problem. I understand
              some frontend teams put your mobile styles in one file
              and desktop in another or in a whole other section. Then
              this problems is at its worst
  jensimmons: Another way to do it is it's one stylesheet and throw a
              MQ at one rule. That way you've got the original idea
              with a class of files. Nesting selectors is something
              sass has done for a long time. It's thrown people when
              they move back to css. I'd advocate for something more
              universal like nesting selectors and than you could
              write more efficient code. Any of these solutions
              require switching from different files.
  jensimmons: Teams can do that today and switch their thinking.
              Question becomes if we had something like nested
              selectors and teams thought of it as one set of styles
              with conditionals what else would they need
  jensimmons: Agree there's a danger this makes it too complicated
              where elegance of MQ is lost. Some teams are really into
              math and variables and calculations, which is great but
              I don't know if we want central idea of how you do css
              to becomes something that is that complicated
  jensimmons: Other idea I've seen some teams believe and the web is
              neutral on and should stay that way to do it correctly
              you should define all the breakpoints and every number
              should be those breakpoints. Variables make that more
              efficient.
  jensimmons: I don't believe that's necessarily the right way and I
              don't think we should add anything to css to make it
              harder to do any way.

  myles: 10 days ago leaverou made a comment why we can't make
         variables stronger. I didn't see it addressed. I'd like to
         ask same question here.
  <TabAtkins> where was this comment?
  <myles> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620424568
  AmeliaBR: [reads]
  AmeliaBR: I interpret it as putting onus on author to do calc rather
            than having it be a css syntax thing
  florian: Doable today but not readable. If you have a MQ at the top
           of your sheet and then you have 50 numbers. Then you have
           border-top-width: size17.
  AmeliaBR: And things you're switching might not be numbers. Might be
            grid areas or colors

  <bkardell> jon's (the OPs) comments are on the issue now btw

  TabAtkins: Accumulating responses
  TabAtkins: Not in order. myles and leaverou comment. That's exactly
             what I proposed switch would do as long as I'm
             interpreting her correctly. She may instead think it's
             math formula and I don't think that's always possible. If
             just saying use variables to do this that's what switch
             function does

  TabAtkins: Earlier, I think florian, about nested vs switch. I think
             being able to nest MQ into style rules is necessary. If
             any changes you want to make based on a MQ are more than
             a single properties you want nested MQ. Gives you same
             benefit of cluster but lets you link together
  <bkardell> +1 to "nesting would also be good"
  TabAtkins: When doing single property value for something like
             colors it's still more overkill in syntax. I like switch
             to be as terse as possible

  TabAtkins: Earlier comment about this akin to layout-based switch
             from bkardell. This really isn't. Anything based on
             layout has to be late in pipeline and limited in what it
             can adjust. You cannot adjust display based on layout.
             Fox is in the henhouse. But no reason you can't adjust
             display based on this. MQ can shift display but changing
             where it's assigned.
  TabAtkins: Similar conceptually but different in practice. We
             shouldn't try and merge them into one thing
  TabAtkins: Moving on to this being requested by conditionals in
             calc, I kind of agree. Could do via calc conditionals.
             var = 1 var = 2 type. People can do move complex things.
             That works for me.
  TabAtkins: If this is a great additional reason to support
             conditionals in calc I can spec that out, it's fine.
  <bkardell> if it becomes something that is not called switch, but
             fits in calc, I am ok with that too

  drousso: One thing I want to point out is this is not the only
           situation with a problem but anytime it has to do with
           newlines or whitespace it doesn't work well with things
           built into browser. Anything that relying on newlines will
           not play nice in browser dev tools. Should be considered
  TabAtkins: Syntactically no reason, but larger issue is all comma
             separated lists. I put bg on separate lines to make it
             more readable.
  drousso: Agree but devs use the tools to write these things so some
           consideration for what the editing experience should be.
           Not saying they can't be fixed, but they've been this way
           for a long time and we shouldn't make it worse.
  <jensimmons> +1 to thinking through what the debugging experience
               is. Separate from the specific DevTools concern, I
               agree that making this natively quite-complicated needs
               to be only done while thinking through the debugging
               experience.
  <Rossen> +1 on tool working well with CSS!

  florian: Continuing on my earlier comment. Conditionals in calc has
           been asked. In calc you can express a number of calc, but
           we need to express things that resolve to a bool if we do
           this. Feels slippery slope and we end up with a new
           language in calc since people want complexity. Lisp with a
           clumsier syntax isn't something we should do. It's powerful
           but let's not jump in accidentally
  faceless2: Agree with florian. If you put in calc you restrict to
             calc. Conditionals in css is a great idea. Not sure calc
             is best place.
  faceless2: This must have come up in a preprocessor surely, should
             we link to one of them?
  TabAtkins: I know multiple have nested MQ, don't know if at value
             level

  <jensimmons> and reach out to Sass to ask them why they haven't done
               this yet. See if they can — to get author experience
  <TabAtkins> @jensimmons I'd ask you to do some examples on your own
              with light/dark/high-contrast/low-contrast MQs, and see
              if you're happy with the amount of MQ repetition you need
  <jensimmons> @ TabAtkins — I have written a lot of CSS.
  <TabAtkins> jensimmons, yeah, I know ^_^ but i'm asking you to write
              out nested-MQs vs switch(), as I think the verbosity
              issue for nested-MQs is *not* trivial
  <AmeliaBR> Sass has `@if` and `@else` rules:
             https://sass-lang.com/documentation/at-rules/control/if

  bkardell: Jon works on preprocessor stuff, the original poster. One
            of the points has to do with parsing. There's a difficult
            parser scenario where like URLs there's a spec but what
            people impl in not-browsers is not entirely accurate.
  bkardell: Worry about forward harm that can be done if we add new
            syntax.

  <lajava> TabAtkins, I don't think switch should be restricted to
           layout related conditions; I think from the implementation
           we can resolve the switch conditions during CSS parsing as
           well

  Rossen: I don't think we can get to a resolution here.
  Rossen: TabAtkins since you brought this topic anything you want to
          see going forward?
  TabAtkins: Right now happy to go ahead and table. I'll write up a
             more fleshed out proposal for my idea and we'll bring it
             up in a future call
  Rossen: Similar to 2 issues ago seems highly desired functionality
          and will take some ironing before we can resolve

  <br type=10min>
  Rossen: We've got less than an hour so if you have must issues let
          me know

  <fantasai> TabAtkins, Not arguing that we necessarily don't want
             switch, but would it make sense to add nested MQ to CSS
             first?
  <fantasai> TabAtkins, it's just syntactic sugar, so, relatively easy
  <TabAtkins> I think we should do both of them at once, yes.
  <fantasai> TabAtkins, I'm not convinced we should both of them at
             once. I think it's fine if we do nested MQ now
  <fantasai> TabAtkins, and continue to work on switch() proposals.
  <TabAtkins> I don't think we should do nested MQs, then wait to see
              that reception to decide whether we want something
              terser.
  <TabAtkins> I'm writing a comment expounding on this exact thing
              right now ^_^
  <jensimmons> I think we should do nested selectors in general,
               first. Nested MQs, and nested selectors.
  <jensimmons> It'd be a HUGE improvement in code organization
  <fantasai> Proposal: css-nesting-1 to include nested MQ and
             @supports only, and get that done quickly because it's
             just syntax we already support in the core syntax
  <fantasai> keep working on the rest
  <TabAtkins> Strong agree with nesting being an important thing to go
              forward with.
  <TabAtkins> switch() wouldn't be a Nesting topic anyway, it would be
              V&U ^_^
  <TabAtkins> btw, Sass defines *both* `@if`/`@else` at-rules, *and*
              an `if(bool, val1, val2)` function, so yeah, it's got
              conditionals on both rule-level and value-level.

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

Add contain-paint-margin CSS property
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4934

  chrishtr: Purpose is to apply a clip so the ink overflow does not
            exceed it. Allows UA to detect that it's offscreen so
            don't have to paint. This property allows dev to have a
            margin to expand the clip. In case devs have certain
            amount of ink overflow b/c useful for layout like shadows
            or flourishes
  florian: Additional use case is outline and accessibility purposes.
           If the outline would be in screen and rest wouldn't you
           might want to see. Optimizations can work if you just
           expand boundary of rectangle a bit. If it works, why not

  fantasai: Is contain:paint containing paint of element or contents?
  florian: Both
  fantasai: Seems weird. Mostly contain is about contents. Why would
            you clip box shadows?
  TabAtkins: Containing layout is one thing because elements own
             layout won't extend but children can so it's fine. But
             box shadows can be arbitrarily far away so if you only
             clip children you still have to look at element, compute
             styles, and care about paint.
  fantasai: For ? anyway so you know where it is
  florian: Element yes, but the paint. If you have containment you can
           say it's offscreen so stop. not check if there's a shadow
           and maybe compute that
  AmeliaBR: Also when having element on its own layer how big is it an
            reserving memory for animations and whatnot

  smfr: I think I would understand better if describes how data goes
        into compositor. Is it knowing when overlap?
  chrishtr: Reducing size of textures is an optimization. Motivation
            is allow dev to benefit without being strict about
            clipping to size of element.
  <TabAtkins> This is basically exactly analogous to the filter margin
              concept for SVG filters
  florian: fantasai's point about just for children doesn't change
           problem. Could have 0 padding 0 border div around something
           with a shadow and same problem
  * fantasai does not understand florian's comment

  dholbert: Similar to shape-margin property but that rounds at
            corners. Is that what we're intending?
  TabAtkins: Shouldn't be necessary. Just extending rectangular box

  fantasai: I'm still skeptical about definition. Would it make sense
            to have 'auto' to calc things like default outline width
            or outset of border image or (possibly ignoring blur
            radius) box shadow distance
  florian: Possibly. We have a bunch of cases where win of
           optimization is real but small. If you have a bunch of
           checks before it defeats optimization
  fantasai: It's auto. You don't do every time you paint. You
            look at 3 properties and calc outsets once.
  AmeliaBR: Animating shadow
  fantasai: If you have auto on contain paint that's animated.
  chrishtr: But has to be cached and that's a cost. It also doesn't
            solve content in subtree issue
  florian: If you do width of outline you wouldn't on child of element
           that's adjacent so only partly helping.
  fantasai: Having arbitrary clip of box doing containment is weird
  AmeliaBR: Is the concern default is too strict? Could give a default
            of something like margin 16px. Default you assume a little
            overflow.
  fantasai: Maybe. Having a typical box shadow or border image get
            clipped when you 'contain: paint' seems weird
  fantasai: Understand about clipping children. But clip box itself is
            weird
  dholbert: That's not what happens in FF or Chrome. We clip
            descendants to padding box
  TabAtkins: You should clip box-shadow, not border
  florian: I misspoke earlier. Spec says content of element including
           paint of descendants must be clipped. Border is not content
           so what fantasai wants is what spec says. If it should is
           another question, but we're not spec you must clip
  fantasai: sgtm

  <dholbert> I tested box-shadow, and indeed it's not clipped.
  <dholbert> My testcase (shadow isn't clipped in Firefox or in
             Chrome): data:text/html,<div style="border: 3px solid
             black; box-shadow: 50px 50px black; contain:paint;
             height: 10px; ">abc
  <dholbert> shape-margin definition, for reference:
             https://drafts.csswg.org/css-shapes-1/#propdef-shape-margin

  Rossen: Would adding this property address the issues you're aware
          of chrishtr?
  chrishtr: yes. Adding contain-paint-margin is
  florian: You still want this in light of me misunderstanding?
  chrishtr: Yeah, I came into it with that believe
  fantasai: I'm okay with it, given it only affects content

  Rossen: Objections to adding contain-paint margin property to
          contain paint?
  florian: No objection. We looked at non-0 initial value so with this
           understanding lets have default be 0
  chrishtr: Can set to non-0
  smfr: Can you set negative?
  chrishtr: Good question. Not sure there's a purpose
  smfr: Should it clamp?
  florian: Yeah...
  Rossen: When we discussed in context of shape outside resolution was
          easy that you want to have shape margin be non-clamped so
          you can pull content under
  florian: Yes, but this is a lot weirder.
  Rossen: Should we clip to non-negative
  florian: I think so
  fantasai: Start with non-negative and expand to negative if needed
            later
  cbiesinger: I think you want negative values invalid, not clamped
  <astearns> +1 to fantasai
  fantasai: Yeah

  florian: One number or one or two or three or four numbers?
  smfr: Same as margin t/r/b/l
  smfr: Do adjacent paint margins collapse?
  fantasai: no
  smfr: It has margin in the name and it makes me concerned
  florian: adjacent margin collapsing has no meaning
  smfr: Should it have margin in name or call it outset?
  fantasai: We already have scroll-snap-margin so there's precedent
  smfr: Okay
  TabAtkins: and filter-margin in svg

  Rossen: Objections to adding?
  fantasai: Scope question
  fantasai: Makes sense to have it work with overflow:clip?
  fantasai: Why not operate on overflow:clip? So maybe more generic
            name.
  dholbert: Then same behavior as overflow:scroll...
  fantasai: hidden, auto, and scroll are different, create a scroll
            container. overflow:clip is different.
  dholbert: Yeah, if defined in terms of overflow:clip it would have to
  chrishtr: If it's a paint thing that's fine
  fantasai: And useful if people don't want full containment
  florian: clip-margin?
  dholbert: Don't love the name. Clips to a margin is what it sounds
            like
  AmeliaBR: Or related to clip-path, Yeah. Name to be bikeshed?
  AmeliaBR: Need to look more details about complications from
            overflow:clip
  fantasai: I think it's worth looking at things that clip and which
            should hook in
  Rossen: ink-margin?
  fantasai: I don't think that's how people think about it
  <fantasai> overflow-margin?
  florian: Doesn't add margin to ink. Visible ink overflow it doesn't
           do anything. It's an ink-clip-margin-ish
  florian: Bikeshedding to be done

  Rossen: Objections Adding ink-skip-clip-margin property (name tbd)
          with non-negative values

  RESOLVED: Add ink-skip-clip-margin property (name tbd) with
            non-negative values

  <florian> should it have longhands? logical ones as well?

CSS Syntax
==========

Allow trailing comma in gradient functions (and probably others)
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4968

  TabAtkins: I think we're good. Previous hour was great and now we
             have a solid proposal.
  TabAtkins: I won't go over the whole thing, just look at issue
  TabAtkins: One concern from emilio during conversation is, WG in
             general supported trailing commas. Question was how.
             emilio concern was wanted it at low level, prefer at
             parser so we didn't have to rely on impl remembering to
             put it in every place
  TabAtkins: At first thought it was weird and my first idea of a
             function without a comma was attr() and then I remembered
             it has a comma now. My idea of comma-less functions
             that get upgraded has happened.
  TabAtkins: Same for properties, we've upgraded to be list-valued.
             Some like color probably won't change, but we've done
             this in the past. My original objection is invalid, I
             support em
  TabAtkins: I propose we adjust consume a declaration, a function,
             and a comma separated so in addition to dropping
             whitespace they can drop a single comma token from the
             end.
  <leaverou> +1, this will also make it easier to generate CSS
  TabAtkins: If you have a parse close to syntax this allows it
             anywhere without much effort
  TabAtkins: Syntax points: consume a declaration, consume a function,
             and new consume a comma sep list. All have an amendment
             to consume a single comma token

  florian: Do you want to include conditional lists and selector lists?
  TabAtkins: Yes. the comma separated list thing was for those cases.
             I'd then redefine those to use that parsing algorithm.
  florian: I suspect compat issues for selectors but let's see
  florian: Properties that have comma separated list space and than a
           value do we have those?
  TabAtkins: Don't as far as I know but they wouldn't be covered by
             this change
  TabAtkins: Trailing comma is at the end of the entire property
             declaration. The algorithm isn't invoked for properties.
  florian: Do we have property with comma separated list / other comma
           separated list?
  TabAtkins: I don't think...
  fantasai: / is a more binding operator. If there are properties that
            have inverted the order of operation that's really bad.
            Comma is usually lowest.

  <faceless2> So "display: block,;" is valid?
  <fantasai> yes, that's Tab's proposal

  myles: Seems reasonable for us to have a single value property today
         that turns space separated tomorrow with 2 values where we
         wouldn't have a comma in the middle. If we allow comma in all
         today couldn't do that
  myles: Larger comment is commas make sense on lists not single value
  TabAtkins: If we change syntax from one value to two space separated
             a comma wouldn't interfere. We wouldn't do something like
             counter reset, that was a mistake
  myles: We use spaces and commas intentionally. Blanket stating for
         all doesn't seem forward-looking
  TabAtkins: Looks forward compat. If it was a,; and than we accept
             a b a, is fine a b is fine
  myles: Not about ambiguity, we design properties and want a comma or
         not a comma
  TabAtkins: Okay. objection to that, across css comma has been
             consistently separator between repetitions of a list.
  fantasai: Not true
  fantasai: A lot of our functions, it's not a list of thing.
  TabAtkins: That's why I said properties.
  TabAtkins: Because consistent meaning there and trailing comma fine
             at end of one element list and not going to give comma
             another meaning when in a trailing position I don't think
             it's a forward compat issue

  plinss: In favor but one concern.
  plinss: If you say 'foo," and nothing. If we define the second thing
          gets default value and it's important there are 2 things
          that's broken.
  TabAtkins: We would not define a repetition can be completely empty.
             We don't do that today. A value and a trailing comma is
             single value.
  plinss: This forces us into never allowing that. Never allow blank
          after comma is set in stone.
  TabAtkins: Agree

  AmeliaBR: How effect parsing of custom properties? When do we drop
            the comma? Could be meaningful at end.
  TabAtkins: Dropped during parsing. I can see it being confusing but
             I'm of the opinion that if you're putting structural
             stuff like that in your variable I think you'd in a world
             of pain.
  AmeliaBR: Real use cases where want custom property to be a list of
            repetitions or a blank. In that case don't want comma
            where you use custom property because invalid if it's a
            blank.
  florian: Can we make an exception?
  TabAtkins: Doable. A bit weird but not out of question
  florian: Since it's a list of tokens it's a natural exception
  AmeliaBR: Have an exception where a blank is meaningful
  TabAtkins: That's not parser lever

  emilio: Not sure initial answer was correct. Parsing at property
          consumes all tokens regardless of which.
  TabAtkins: Depends on definition. I don't care what declaration's
             name is while I'm consuming so parse the same and then
             apply grammar. I know browsers do grammar as you go but
             it's must simpler mental. That's why I'm okay adding a
             check for it it's parsed.

  Rossen: Time check, this will take us to the end. We have a queue
          and then let's see if we can end

  fantasai: Wanted to ask if we weren't going to do this for
            everything, the alternative is only where there is a list.
            If we drew that up what would it look like and should we
            compare?
  TabAtkins: Complicated. Simplest is # multiplier allows trailing
             comma. But anything that does commas explicitly, which
             is a lot of places, would not work.
  TabAtkins: Have to go into every property that uses commas and make
             sure their grammar expresses it.
  myles: I think that makes sense. Property by property is right
  <faceless2> +1 to myles
  drousso: I agree
  <astearns> terrible to do things property by property for authors
  TabAtkins: Disagree because it's fine and reasonable to do commas at
             end of single in JS. Having to distinguish for a way to
             write it easily seems unnecessary burden on authors
  florian: I don't like it for rollout, if this is central it is fixed
           once. If it's property by property a fix would end up going
           out in some places but not all
  myles: Difference between css and js is parsing rule isn't different
         by property in js. I don't understand argument that js has it
         in function calls so we have it everywhere
  TabAtkins: Not strict, but reasoning is similar

  oriol: Ask about trailing comma. In case there's an ! and if it's
         before the !important or if at very end
  TabAtkins: Before the !important. End of value space and ! flag is
             after that

  <tantek> ES also allows it in arrays e.g. test =[1,2,]
  <TabAtkins> ES allows it *everywhere* now, yeah. [1,2,], {foo,bar,},
              and foo(a,b,)
  <tantek> Thanks TabAtkins
  <drousso> that's not true TabAtkins something like `let x = 2,;` is
            not valid
  <drousso> it's only allowed in places where a sequence/
            list/"multitude" is expected
  <TabAtkins> drousso: Hm, time for a new ES proposal
  <drousso> strong disagreee

  TabAtkins: I'd like to propose a resolution and see if objections.
  <florian> +1
  TabAtkins: Proposal: I make the syntax spec changes to allow
             trailing commas in general module small changes around
             things like !important
  Rossen: Objections?
  myles: I'm not going to object but seems wrong direction
  <tantek> not just functions, as a correction to myles's assertion
           that it's only functions

  fantasai: Alternative way forward is TabAtkins has his proposal and
            myles if you think there's a better way you can draft a
            proposal and we compare
  emilio: Would myles agree on functions only and decide declarations
          at another time?
  myles: Yes. Commas at end of lists is valuable
  Rossen: TabAtkins?
  TabAtkins: I think myles wants opposite of emilio

  emilio: Can we defer deciding if we add trailing commas for all
          declarations and agree we do it for comma separated list and
          function arguments?
  florian: I think I would object property by property

  fantasai: I propose that TabAtkins drafts a more specific proposal
            and myles and emilio discuss and draft a different proposal
  TabAtkins: myles are you okay with trailing commas on functions?
  myles: No opinions
  TabAtkins: Let's resolve on that
  smfr: Lists first

  fantasai: Let's come back with something written specifically
  Rossen: I think that's be best path forward. Let's not resolve by
          exhaustion. TabAtkins write your proposal. emilio and myles
          if you want a shot at your proposal go ahead and draft that.

  <emilio> myles: TabAtkins: florian: My reading of the original
           proposal from tab was that it also needed some kind of hook
           to define for all "comma-separated lists", in a way that's
           not property-specific
  <TabAtkins> Specifically, I want to amend
              https://drafts.csswg.org/css-syntax/#parse-comma-list
              https://drafts.csswg.org/css-syntax/#consume-declaration
              and https://drafts.csswg.org/css-syntax/#consume-function

  Rossen: That's the end of out first virtual F2F
  Rossen: I enjoyed seeing all your faces. We should do this virtual
          thing more often.
  Rossen: Thank you very much for dialing in and getting up early or
          staying up late or whatever you had to do to join. Stay safe
          and happy and healthy and hopefully the next one will be a
          F2F.
  Rossen: We'll have a call next week.
  <Rossen> I forgot to thank our virtual hosts - Thank you Google for
           hosting us on Meets!!
Received on Saturday, 16 May 2020 10:42:40 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 16 May 2020 10:42:40 UTC