[CSSWG] Minutes Telecon 2022-03-09 [css-multicol] [css-color] [css-color-adjust] [css-conditional]

  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 Multicol

  - RESOLVED: Accept proposal that elements which establish fixedpos
              containing block also block descendant spanners (Issue
              #6805: Should column-span:all inside a transform really
              become a spanner?)

CSS Color & Color Adjust

  - There is a several part proposal to handle issue #6773 (Should
      column-span:all inside a transform really become a spanner?).
      There was a request for more time to consider the proposal so a
      resolution will be called for next week. Proposal:

Modular/distributed grammar definitions

  - There was broad agreement on the spec maintenance problem described
      in issue #6744, but no specific proposal for a solution yet. In
      github the group is going to continue to work toward a specific
      proposal for how to handle the grammar and/or a way to have
      tooling assist in maintaining the definitions.

CSS Conditional

  - There is strong disagreement about naming the property @if or
      @when (Issue #6684: Rename @when vs @if). Those arguing for @if
      believe the name would be clearer for authors. Those arguing for
      @when believe that the breakage that would happen to SASS is not
      worthwhile since @when would also be clear for authors.
      Discussion will continue on the thread and TabAtkins will reach
      out to the lead developer of SASS to participate on the issue.


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0002.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins Bittner
  David Baron
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Daniel Libby
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  Ben Mathwig
  Morgan Reschenberg
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Scribe: fantasai
Scribe's Scribe: dholbert


  astearns: W3C is surveying wrt TPAC, whether to engage the venue or
  astearns: Seems that 2/3 said they would consider attending in-person
  astearns: so I sent that feedback to W3C saying that if TPAC is
            in-person, we're likely to want to do an in-person meeting
            with a substantial remote component
  astearns: So we will see if circumstances will allow for an in-person
  astearns: And W3C will take feedback from all groups into account, to
            decide whether to keep the venue
  astearns: They need to decide by the end of this month
  astearns: So wanted to let you all know that in-person meeting at
            TPAC seems *plausible* as of this point

CSS MultiCol

Should column-span:all inside a transform really become a spanner?
  github: https://github.com/w3c/csswg-drafts/issues/6805

  alisonmaher: Criteria of becoming a spanner, specifically in case of
               a transform
  alisonmaher: According to spec, can become a spanner if in the same
               formatting context
  alisonmaher: even if inside a transformed ancestor
  alisonmaher: even though transforms trap fixed pos descendants
  alisonmaher: Proposal is that anything that establishes a fixedpos
               containing block also prevents descendants from becoming
               a spanner
  <TabAtkins> +1
  dbaron: Sgtm
  rachelandrew: It seems like a sensible proposal, happy to make the
  astearns: Anyone with concerns?
  astearns: Any objections?

  RESOLVED: Accept proposal that elements which establish fixedpos
            containing block also block descendant spanners

CSS Color & Color Adjust

Making system colors fully resolve (but flag they were system
    colors) thus reversing the resolution of #3847)
  github: https://github.com/w3c/csswg-drafts/issues/6773

  <chris> https://github.com/w3c/csswg-drafts/issues/6773#issuecomment-1062008116

  alisonmaher: Proposal is for both issue 3747 and 4915, which resolved
               to make system colors resolve to themselves and resolve
               at used value time
  alisonmaher: Proposal is to resolve the colors, but flag them as
               being system colors, so that we don't force them when
               they're used in forced colors mode
  alisonmaher: This would also allow to revert 6310, which added a
               special value for SVGs
  alisonmaher: I'm not sure if there are specific color scheme
               resolutions that need to be checked

  emilio: I need to check wrt retain that they were system colors bit,
          but the rest seems fine
  chris: I asked whether you need to ask which system color, and they
         said not, it's just a single bit so that you know not to force
         the color
  emilio: Ah, ok, that makes sense

  fantasai: There was a comment a while back which is why we went in
            this direction...
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4915#issuecomment-707969753
  fantasai: This comment... I wonder if we're handling that somehow or
            if we have a problem
  alisonmaher: I think we wouldn't be handle that case, we'd be
               inheriting the forced colors rather than
               author-specified values
  alisonmaher: We originally shipped in Edge with forcing colors at
               computed value time, but ended up switching to used
               value time
  alisonmaher: and we only got the opposite problem in SVG, in terms of
  alisonmaher: I think it could be a good change, but maybe some cases
               where authors don't expect the behavior
  TabAtkins: We solve either this one or the other one where an
             author-specified color naturally inherits into something
             with a forced background
  TabAtkins: so I think our reverting resolution solves the more
             important of the issues
  chris: I agree

  emilio: I agree with what Tab just said
  emilio: Also, at this point, what is the difference between forcing
          at used value time and computed value time
  alisonmaher: Difference is if authors sets 'forced-color-adjust:
               none', if at used-value time
  alisonmaher: inherits color as if never forced
  alisonmaher: [gives example]
  alisonmaher: then would inherit the color that the author expected,
               but if at computed value time it would inherit the
               forced color that author doesn't expect
  emilio: I wonder which behavior is better, but understand the

  fantasai: What are we currently proposing to do with regards to this
  chris: What alisonmaher proposed on that last issue
  fantasai: Particular to emilio's question: are we computing and then
            inheriting, or vice versa?
  alisonmaher: Currently we inherit and then force the colors, and
               proposal is to force at computed value time so that you
               would inherit the forced colors instead
  alisonmaher: since it's at used-value time, we're inheriting and then
               forcing the colors [...]
  * fantasai doesn't like that but is confused which issue is which at
             this point

  astearns: Seems like several issues
  astearns: 3847, proposal is to revert the resolution. What was it?
  chris: I see a lot of people being in agreement and fantasai being
  astearns: fantasai, you're concerned that this set of resolutions
            would result in page getting a mix of forced colors and
            author colors that will result in bad color design
  fantasai: Yes
  astearns: Should we explore that bad color design problem before
            making this set of resolutions, or should we make the
            resolutions and see how applying the resolutions turns out
  chris: I suggest we try out and see if there's an issue
  chris: I think it's the right way forward
  chris: As Tab said, it solves the more important problem
  <emilio> I agree
  *fantasai has no idea
  fantasai: Not sure, I'm not really up to date with what's going on,
            and there's a lot going on in this issue
  fantasai: How about we take them as tentative resolutions for 24
            hours, and TabAtkins will explain them to me :)
  astearns: How about we postpone making the resolutions until next week
  fantasai: Sounds good, but let's outline what we're resolving
  astearns: That's alisonmaher's comment. She outlines a 5-step process
  astearns: Take a look at her comment this week, and then next week we
            can resolve on all 5 items

  astearns: Any concerns about waiting another week?
  chris: I'd prefer to get spec text drafted, but we can wait another
         week. I can still hash out some proposed spec text.
  astearns: Proposed text would probably make it easier to review in
            the meantime
  astearns: emilio, please look at the proposed resolutions too
  emilio: Sounds good
  astearns: Everyone else who's concerned/interested, please also look,
            and we'll come back to this next week and resolve
  astearns: Thanks alisonmaher for the proposal

Modular/distributed grammar definitions
  github: https://github.com/w3c/csswg-drafts/issues/6744

  lea: This is about cases where certain tokens are defined as union of
       other tokens
  lea: In some cases we want to expand these tokens in different specs
  lea: and right now it gets quite difficult to maintain
  lea: Happened multiple times in color-4 and color-5
  lea: Don't imagine we'll keep adding color spaces, but when lab and
       lch were added, were added in some places and not others
  lea: some happened also in some of the color colorspaces
  lea: basically every time we added colorspace, it was added in some
       places and not others
  lea: because right now we don't have a DRY way to do it
  lea: Multiple different places need to be updated to ad a colorspace
  lea: I was wondering if we could define some new grammar operators
  lea: that extends a token with whatever it already has from other
       specs plus these tokens
  lea: They could be in different specs, different modules
  lea: Argument against this is that it adds clarity to have a
       centralized definition
  lea: In usability we say if humans keep making the same error with
       your interface, then it's a problem with your interface

  chris: I agree with lea that this problem does occur
  chris: e.g. we added <number> | <percentage> | none
  chris: and we have out of sync with prose
  chris: which assumed percent
  chris: I don't want to see too much indirection in the actual spec,
  chris: but we already have this indirection because we have bikeshed
         source and generated HTML
  chris: so if editors have partial addition like this, if Bikeshed to
         expand that out and have the complete list in each spec
  chris: that would let us see everything in one place
  chris: but then I don't know if that's complicated to implement
  astearns: Bikeshed automatically expanding makes it *more* likely to
            have mismatch between grammar and prose

  dbaron: I sympathize with the problem here
  dbaron: there are multiple possible results depending on tooling to
          fix this
  dbaron: One possible result that I would be very unhappy with is that
          you end up in situation where readers of the spec can't
          figure out what a production expands to
  dbaron: because other specs are extending it from other places, and
          you can't figure out what the list of things that extend it
  dbaron: bzbarsky used to call those "come from" statements instead of
          'goto' statements, and they're worse
  dbaron: If we solve through better tooling, great, but I don't want
          to end up in a situation where you can't figure out what a
          production means by looking at a spec

  TabAtkins: Few points
  TabAtkins: Earlier, chris had given an example of prose falling out
             of sync with grammar
  TabAtkins: Alan pointed out if distributed, easier for that to happen
  TabAtkins: In general, prose falling out of sync has nothing to do
             with grammar definitions. Has to be manually maintained
  TabAtkins: If you have to keep prose in sync, might as well keep
             grammar in sync
  TabAtkins: I agree with Lea's usability principle, but we mostly get
             it right
  TabAtkins: .... automatically tooled
  TabAtkins: Chris asked if this was done in Bikeshed, would this be
             simple or complicated to implement
  TabAtkins: Answer is, substantially more complicated
  TabAtkins: You might have noticed that you can see what a production
             expands to by hovering
  TabAtkins: Process is not very smart, it goes through the database
             and links things together with vars
  TabAtkins: it doesn't read text, it reads the definitions
  TabAtkins: To make it work smarter, it would be a brand-new project
             to parse our grammar definitions
  <chris> Yeah I saw that give bad results (complete list of color
          keywords, for example)
  TabAtkins: I do want to do that at some point to link our
             definitions, to help catch mistakes
  TabAtkins: but it's not done now, and would be a major project
  TabAtkins: so definitely not in the near future
  TabAtkins: If having tooling is necessary, we can't do it now
  TabAtkins: Finally, just generally, I agree with dbaron and
             bzbarsky's older points, that having this sort of
             come-from definition where you can look at the canonical
             definition of something and not know that something else
             is modifying it
  TabAtkins: we do do this sometimes, in WebIDL and partial propdefs,
             but we don't do it very often
  TabAtkins: So absent tooling that can indicate to readers that there
             is more to this definition that listed here
  TabAtkins: I'm opposed to this

  <dbaron> I have proposed (in the TAG) that `partial` should be
           considered a bad practice for mature specs, although I
           couldn't quite get consensus on the point.

  lea: Originally was going to respond to Chris, that better solved by
       tooling than humans for centralization
  lea: Agree that without tooling, could introduce more problems than
       it solves
  lea: In this discussion seems to be a confusion of extensibility vs
  lea: That wouldn't fix prose that's inconsistent to grammar, but
       implementer can more easily spot that error
  lea: Whereas if the grammar and prose are consistent with each other,
       but not with another spec or another part of the spec
  lea: That's more likely to create incompatibility

  fantasai: I wanted to comment on the automated tooling aspect
  fantasai: We have lots of specs in different states of being finished
  fantasai: If we had a single spec and this was it, and we split it
            across multiple modules and automated tooling copied things
            from here to there, that'd be fine
  fantasai: If we have things in rec that automatically expanded into
            people's editor's drafts [...]
  fantasai: I think having an automated approach would modify things
            that we don't expect to modify
  fantasai: e.g. if someone fixes a typo, it might cause changes to
            other specs
  astearns: the automation would have to deal with that concern
  lea: The fact that there are different specs at different maturity
        levels extending the token is actually a motivation for it
  lea: Do I include this early-stage draft, or not?
  lea: The grammars that tooling generate, could have different levels/
  fantasai: Let me put it this way; I'm fine with us having centralized
            definitions and needing to update them manually
  fantasai: If we want to have a new or-equals operator that extends an
            existing token, that's also fine since it's relatively
  fantasai: If you combine specs, you get the union of those tokens
  <lea> +1 to fantasai
  fantasai: I'm not fine with having an automated system that *decides
            for you* whether this thing gets extended or not
  fantasai: If it's automated, it happens magically and you might not
  fantasai: Don't want the tooling to change the prose of the spec such
            that something gets magically expanded. That'll happen in
            unexpected ways
  <tantek> +1 fantasai, keep things more manual until there’s
           experience with it, rather than "automate all the things"

  astearns: Anything more to discuss on this?
  astearns: I see 2 ways of going forward with this
  astearns: that don't necessarily conflict
  astearns: 1. Come up with a distributed scheme that we can agree is
            the right way to develop specs with these issues
  astearns: 2. Work on tooling that isn't going to create more problems
            than it solves
  <TabAtkins> (Note that the "random ideas are automatically merged
              into the definition" happens today with the production
              title="" attribute, but it's also a less-obvious and
              less-official source of data.)
  <lea> That sounds like a huge undertaking for what was essentially a
        proposal for |=
  astearns: Tab, you mentioned tooling from you would take a long time.
  astearns: Would you be OK with someone taking a branch of bikeshed
            source and fiddling around it?
  TabAtkins: Yeah, that's fine
  chris: It also doesn't have to be bikeshed at all. We have a database
         of properties and values, potentially a separate tool could
         run over that and identify problems
  astearns: That tool could be something spec authors could use to
            figure out what they need to put in their source
  astearns: instead of an automated expansion

  lea: This makes it sound like a huge undertaking of coming up with an
       extension something
  lea: whereas the main thing that's needed here is |= or &= or
  lea: I've seen this thing being done manually, but can't remember
       which specs
  lea: but I've basically seen prose that's done this, so would be good
       to have a formalized way to do it
  TabAtkins: We do do it sometimes, but I think it's good that it's
             clumsy and awkward, because encourages people to update
             the centralized definition
  lea: If awkward, fix it
  TabAtkins: Sometimes it makes sense to make the bad thing hard, so
             that people avoid doing it
  lea: I think calling it a bad thing is a value judgement
  lea: it's a spectrum
  lea: sometimes centralized definitions are a worse thing

  astearns: I think we've spent enough time for today
  astearns: We can go back to the issue and come up with specific
            proposals on grammar productions and what they would solves
            and possible tools for spec authors to make things easier
  <lea> (+1 that we've spent too long on this today)
  astearns: let's come up with things
  fantasai: Because we need a canonical order for things, the *only*
            operator that we can do in this manner is the "or" operator
  <lea> fantasai: && doesn't impose a specific order either, does it?
  astearns: ok, next issue

CSS Conditional

Rename @when vs @if
  github: https://github.com/w3c/csswg-drafts/issues/6684

  lea: We all know that we have at-rule to unify all our conditionals:
       @media, @supports, new things
  lea: Right now called @when, only because @if conflicts with SASS
  lea: I don't think that's sufficient reason to go against the
       convention of almost all computer languages
  lea: Almost everything uses "if"
  lea: We are going against any precedent that CSS authors are likely
       to be familiar with
  lea: Even spreadsheets use IF
  lea: Whereas @when would need to be used specifically for CSS, and it
       seems really weird
  lea: 10 years down the line will be a weirdness in CSS
  lea: and we might not even remember that SASS was using it
  lea: There are ways for SASS to get around it
  lea: Not the same as when conflicts with libraries that are actively
       running on websites
  lea: e.g. when TC39 decided on a different name with prototype
  lea: but SASS is a preprocessor. It's much easier to migrate syntax
       when preprocessing before website is deployed
  lea: when you run website using SASS you're not running SASS, you're
       running the generated CSS
  lea: The only conflict is when SASS itself runs
  lea: easier to get around
  lea: I don't think we should do something that decreases usability
       for the core language, for millions of CSS authors, because of
       this 3rd party tool that uses @if
  lea: If it was the same usability, then why not be nice and use @when
  lea: but I think it's significantly less usable to use @when, and I
       don't think the tradeoff is worth it
  <Rossen> +1
  <bmathwig> +1
  <tantek> +1 Lea
  <bradk> +1 Lea

  TabAtkins: I very strongly disagree with the argument Lea just made
  TabAtkins: In general, I don't.
  TabAtkins: Generally CSS should make the best decision for its
             future, and everything else is secondary
  TabAtkins: That said, it's not absolute
  TabAtkins: We do sometimes make decisions based on the impact on the
  TabAtkins: Authors are more important than purity
  TabAtkins: We have to consider how bad it is for authors generally,
             vs authors using the tool
  TabAtkins: we made that decision e.g. in grid line names, switching
             from parens to square brackets
  TabAtkins: here the impact on SASS far outweighs the impact on future
             CSS authors
  <chris> +1 Lea (and +1 the original resolution, which specified @if)
  <lea> all of you plus-one-ing maybe could also q-plus yourselves and
        speak up? :)
  <bkardell> fwiw i do not feel that it is worse. If we took sass off
             the table entirely I'm not sure I have very strong feels
             on if/when - both feel very learnable and not quite
             exactly comparable to other things
  TabAtkins: I've talked with Natalie Weizenbaum main developer of SASS
  TabAtkins: her thought is that if CSS adopts @if with different
             semantics than SASS's @if, would be a major problem
  TabAtkins: have problems upgrading SASS for much more minor issues
             than this
  TabAtkins: If 'if' was the only reasonable name, different case.
  TabAtkins: But "when" is used in various places, e.g. the new JS
             proposal (use of when predates me)
  TabAtkins: used in Ruby and common LISP as variant on "if"
  TabAtkins: It's easy enough to understand, perfectly serviceable
             word, makes sense in English
  TabAtkins: so harm to significant section of authors using SASS right
  TabAtkins: vastly outweighs harm to future by using if
  TabAtkins: I would formally object to using @if
  TabAtkins: this would be extraordinarily bad
  <iank> Is it possible to get Natalie on the call?
  <Rossen> TabAtkins, there's nothing wrong going down the FO path for

  lea: CSS has an extension mechanism, prefixes, and any software that
       wants to extend the language can use prefixes
  lea: SASS didn't do that. They could have done @-if or things
  lea: How far are we going to go to avoid clashing with SASS? if we
       add loops do we avoid using "for"?
  lea: I disagree strongly that "if" and "when" are roughly equivalent
       in usability
  lea: even if they were equivalent in English
  <tantek> +1 Lea
  <bradk> Isn’t sass @if different in that it doesn’t normally have the
          parentheses that we would require?
  lea: "if" has much stronger consistency
  lea: Also in English, when implies something is time-based, whereas
       'if' does not
  lea: many people in the thread, including native and non-native
  <tantek> +1 very much sold that "when" also implies time-semantic
           which is inappropriate here.
  lea: expressed [confusion?]
  lea: We have accommodated SASS in the past, but in cases where both
       options have equal usability
  <chris> PostCSS also has @if (and also @else!)
  lea: I'm not sure how widely-used SASS is at this point anyway,
       community seems to be shifting to PostCSS
  lea: I'm not going to make threats about objections, but I also feel
       very strongly about this

  miriam: Want to re-iterate Tab's suggestion that this would be pretty
          devastating to SASS if we made this change
  miriam: and SASS is one of the largest, most used tools in CSS
  miriam: just went through adding "slashes", which was a massive hit
  miriam: I can't claim to be unbiased, part of the SASS team
  miriam: but I think causing that much disruption to such a
          widely-used tool isn't worth the few characters
  miriam: I hope we can avoid doing that much damage
  <Rossen> the great thing about tools is... they are tools - change
           them ones, re-run your payload and you'll never hear about
           it again.
  <lea> +1 Rossen
  chris: PostCSS also has @else. Are we going to rename @else to @elif
         or @elsewhen or something else?
  astearns: Out of time, Tab can you ask Natalie to comment?
  astearns: scope of the damage has been assigned adjectives, but it
            would be nice to go through the details of what SASS would
            do if we chose @if

  astearns: Thanks everyone for calling in

After Meeting IRC Conversation

  <dbaron> If we can't agree on English terms to use... at what point
           do we start using terms from other languages?
  <bkardell> dbaron, when we cant agree?
  <tantek> I have a problem with allowing the design of CSS to be
           hamstrung or "made weird" by any legacy frameworks
           decisions, especially by frameworks that are pre-processing
           only and are thus not a part of any archived content on the
  <TabAtkins> Chris, note that PostCSS's @else is grammatically
              distinct - their version has to appear after an @if,
              which ours wouldn't.
  <lea> +1 tantek, absolutely this
  <lea> tantek, please post your thoughts in the issue, you are making
        some excellent points
  <fantasai> lea, yes, && imposes an order
  <fantasai> for serialization
  <fantasai> anything that isn't exclusive or has this problem
  <lea> fantasai: ah ok
  <TabAtkins> tantek, we have made decisions to accommodate
              preprocessor issues in the past. We've also said "too
              bad" and *not* accommodated them when they raised issues.
              We do not have a standing policy one way or the other,
              and I would object to any such policy being made. Doing
              so would be elevating theoretical purity over all other
  <fantasai> +1 to taking case by case
  <tantek> that being said, if we acknowledge that SASS "shouldn't have
           done this" that is, they should have used some prefix or
           some extension mechanism, can we provide such positive
           guidance instead so that we can stop further / future
           instances of frameworks squatting on CSS syntax?
  <lea> Relevant TAG design principle:
  <TabAtkins> lea: Yes, the TAG principle is accurate and matches my
              beliefs as well.
  <tantek> TabAtakins, author ux is *not* theoretical purity
  <TabAtkins> tantek, preprocessor users are also authors
  <tantek> TabAtkins, yes, which is why I said it is an authors vs
           authors debate, not authors vs purity
  <TabAtkins> Right, *this issue* is an authors vs authors debate.
              "Never consider third-party tools" is a
              theoretical-purity vs authors debate.
  <tantek> sure, except no one ever said "Never consider third-party
           tools" in an absolute sense. this was specifically about
           harming the design of CSS (author ux), "making it weird",
           due to tools squatting on syntax
  <tantek> and my question stands, how do we discourage further /
           future tools squatting on syntax?
  <TabAtkins> tantek: Quoting you from just a few minutes ago, "> I
              have a problem with object to allowing the design of CSS
              to be hamstrung or "made weird" by any legacy frameworks
  <TabAtkins> If this is not a general objection, it's sure lacking in
              details about the specific tradeoffs.
  <tantek> Tabatkins, I removed the "object to" in an edit
  <TabAtkins> I'm on IRC, there is no edit ^_^
  <tantek> TabAtkins, I presume you personally parse out the same
           commands RRSAgent does :)
  <TabAtkins> regardless, i parsed your sentence english-wise in that
              way. those words are not germane to my or your point.

Received on Thursday, 10 March 2022 12:18:19 UTC