- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 10 Mar 2022 07:17:37 -0500
- 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 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:
https://github.com/w3c/csswg-drafts/issues/6773#issuecomment-1062008116
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.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0002.html
Present:
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
Administrative
==============
astearns: W3C is surveying wrt TPAC, whether to engage the venue or
cancel
astearns: Seems that 2/3 said they would consider attending in-person
meeting
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
meeting
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
edits
astearns: Anyone with concerns?
[silence]
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
bug
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
difference
fantasai: What are we currently proposing to do with regards to this
case?
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
confused
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,
though
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
*is*
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
anyway.
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
monkey-patching
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/
states
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
straightforward
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
notice
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
something
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
here.
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
ecosystem
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
now
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
this
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
speakers
<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!)
https://www.npmjs.com/package/postcss-conditionals
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
web
<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
concerns.
<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:
https://w3ctag.github.io/design-principles/#third-party-tools
<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
decisions,"
<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