- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Oct 2021 18:35:47 -0400
- 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 Cascade
-----------
- RESOLVED: We will have 2 separate objects; one for rules without a
block and one for rules with a block (Issue #6576:
Cascade Layers need CSSOM support)
- RESOLVED: Reverse the prior resolution. Unlayered styles are
highest priority (Issue #6284: Reconsider placement of
unlayered styles, for better progressive enhancement?)
- While discussing issue #6284, the group agreed that the author
control of priority was necessary in the first level of the spec
since there are strong use cases for any order and therefore
authors needed to be able to override the default.
- RESOLVED: Leave the spec unchanged with dot syntax (Issue #5791:
What is the appropriate syntax for appending to nested
layers?)
- RESOLVED: Presentation hints into their own origin between user and
author in cascade (Issue #6659: Cascade priority of
presentation hints vs. tree scopes)
- RESOLVED: Keep "layers" and close issue no change (Issue #5840:
Layers terminology bikeshed)
CSS Contain
-----------
- RESOLVED: Use cq as the prefix (Issue #5888: "container width" and
"container height" units)
- There should be guidance created to determine when a unit should be
created in order to avoid an explosion of units.
- RESOLVED: Accept proposal in ED. Split range syntax and attributes
to new issue (Issue #6396: Define a syntax for
style-based container queries)
- RESOLVED: Add a matchContainer method as proposed in issue. Keep
issue open to decide if need new observer or if we can
reuse the existing (Issue #6205: Similar to
window.matchMedia(), Container Queries should have a
similar method)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Oct/0000.html
Present:
Tab Atkins
Rossen Atanassov
David Baron
Oriol Brufau
Tantek Çelik
Bo Cupp
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Daniel Libby
Peter Linss
Alison Maher
Eric Meyer
Cameron McCormack
Morgan Reschenberg
Jen Simmons
Alan Stearns
Miriam Suzanne
Fuqiao Xue
Regrets:
Rachel Andrew
Jonathan Kew
Chris Lilley
Lea Verou
Scribe: dael
CSS Cascade
===========
Cascade Layers need CSSOM support
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6576
miriam: A few options shown in the first comment on the issue.
Discussion about 2 objects or 1 single. If 2 objects, one is
for empty layer rules and the other for layer rules with
something
miriam: Don't have an opinion, if anyone does I'd love for them to
speak up
<oriol> present+
astearns: Looks like people in issue are saying whatever
miriam: Seems no strong preference. A little sense of it's not useful
but needed
astearns: That 2 objects are needed?
miriam: That some resolution is needed. But not particularly useful
either way
fremy: Maybe idea for simpler approach. @layer a with no rule and
@layer b with no rule and you don't need one or the other.
Then it's only one type of rule. I don't write these, but
maybe an idea?
<fremy> was suggesting maybe considering `@layer a, b, c` syntactic
sugar for `@layer a{} @layer b{} @layer c{}` then you only
have one type of rule
<@fantasai> note that @layer b {} is not valid before @import, but
@layer b; is
<fremy> @fantasai: ah, ok, then that doesn't work. except if we
change it to allow @layer {} before import but not allow it
to have rules in it?
heycam: With a single interface...perhaps issue with both
approaches...a bit weird if insert and remove rule can change
the type. Maybe argument for one interface
heycam: I see suggestion from Xiaochengh was throw exception when
insert called on rule without block. I guess need inverse as
well
astearns: Have not thought much but slightly more in favor of single
interface that could expect both and lets you go back and
forth between
heycam: Reasonable for author to say start with a layer that has no
block and then want to, in cssom, add children?
heycam: If we want to allow that I guess the single interface makes
more sense. Else no way to preserve object identity. Perhaps
that's not reasonable
fantasai: The @layer rule with a block that accepts style rules is
not allowed before @import but is allowed after
fantasai: There's several different syntax restrictions
fantasai: I do think heycam suggestion makes sense. Likely authors
will want to add and remove rules from @layer. If
converting from being a block or not I'm not sure, but
adding to an empty block I can imagine
fantasai: There's complication there about being before or after
@import
heycam: Semantically important to allow @layer block before @import?
fantasai: Yes because layered in order of appearance. If importing
rules that define appearance it matters. Layers with same
name combine.
fantasai: If you want rules before the @import you can add the layer
and have it appear before @import
TabAtkins: fantasai covered some of this, but more syntactic
mismatch. @layer that doesn't have block allows comma
separated list but with block is only 1 name.
TabAtkins: Closely related but syntax is difference. If allowing to
modify they need to be 2 objects
astearns: For blockless do we need object to represent that or
multiple blockless each with one name
TabAtkins: Don't have precedent for single rule expanding to
multiple. Not impossible, but prefer avoid
astearns: Sounds to me like need 2 objects, one for blockless and one
for block
astearns: Other comments on just that? Then figure out mutability and
errors. Single or 2 objects. Anyone continuing to argue for
single?
astearns: Proposal: We will have 2 separate objects; one for rules
without a block and one for rules with a block
astearns: Objections?
RESOLVED: We will have 2 separate objects; one for rules without a
block and one for rules with a block
astearns: Object with a block we should be able to add. For blockless
should we add an error or should it not have methods?
TabAtkins: Won't have methods. No child or insert rule
astearns: miriam anything else on this? Or should we go with
resolution and see what we need on future calls
miriam: Nothing else
Reconsider placement of unlayered styles, for better progressive
enhancement?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6284
miriam: Introducing, but fremy may want to jump in
miriam: In initial proposal had layers under default styles. At some
point I proposed we change to have them at bottom of stack.
Better matches user expectations. But does not match main use
cases as fremy points out
miriam: People may want some of both. Have separate issue for that.
Question is did we get the default right?
fantasai: I think somewhat useful to think about 2 positions as
innermost and outermost. Outermost is lowest priority rules
unless !important, in which case highest priority unless
!important in which case lowest priority. Innermost is
highest priority.
fremy: I reopened this because somebody that used to work at stripe
posted an example. At first I thought browser was wrong
because order seemed weird.
fremy: Idea is you have layers that are base and theme. Then you add
normal styles and declaration in the style was specific but
overwritten by base.
fremy: Main reason layers nice I thought is CSS resets where you
can't reset something because specificity of rule not easy to
have resets
fremy: If the reset is above style of site it doesn't work. That's
reason I think not right call. Most obvious example to me
would prefer styles to be lower than main styles of site.
fremy: It would be useful to see examples of other way
TabAtkins: I don't have a strong opinion on default. Important we
prioritize issue to let you put unlayered at a spot. If we
do that default doesn't matter as much
florian: Agree with prioritizing. I lean toward fremy because if we
keep new unlayered is just a fallback. Unlayered is legacy
and it feels weird that main way to write css is a fallback.
My intuition is same as fremy.
jensimmons: I agree. Sounds like we're mostly agreed. Unlayered
should be most specific. Be confusing to write code as we
have for 20 years and have it not work. Layered will be
most organized and messy will be more specific and need
to override
<@florian> +1 to jen
jensimmons: Agree with fremy
<@fantasai> +1
<jensimmons> and yes to having a way for Authors to change this
default!
fantasai: I wanted to note seems that for files layered that are
imported it definitely seems expected behavior is lower
priority
fantasai: Inline @layer blocks intuition might go other way where
making more specific. I think if we have to pick a default
I think fremy argument makes sense with jensimmons's
explaination of why
fantasai: Could go different with @import and @layer but might be
more confusing
fantasai: Would be useful to create one off roles and decide if it
goes above or below a layer
fremy: I think I agree. In the other issue about how to spec ordering
I made a similar proposal. This layer is priority and this is
normal. That's the other issue, though
miriam: Swayed by this. In terms of other issue we don't want to go
into details but do we want to keep it as defer to next level
or do we want to try and solve?
fantasai: Sounds like we want to solve
jensimmons: Agree
TabAtkins: Only thing that's difficult is figuring out what name it
should be
jensimmons: Useful in transition to let authors decide what happens.
Waiting for that tool could be painful
astearns: Proposal: Reverse the prior resolution. Unlayered styles
are highest priority
astearns: Objections?
RESOLVED: Reverse the prior resolution. Unlayered styles are highest
priority
What is the appropriate syntax for appending to nested layers?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5791
miriam: Allow to nest and then concatenate names and allow you to
access. If you put theme inside framework you get
framework.theme layer. What is syntax?
miriam: In spec we have dot between two. Other options are space or
other divider.
<@TabAtkins> @layer framework { @layer theme {...}} -> appendable via
@layer framework.theme {...} in current spec
miriam: We have this behind a flag in browsers. Change before we
release or is it okay?
astearns: Anyone with concerns about dot syntax?
astearns: Silence.
astearns: Proposal: Leave the spec unchanged
astearns: Objections?
RESOLVED: Leave the spec unchanged with dot syntax
<@fantasai> I used to be more in favor of spaces (but not strongly)
but thinking about how we might need to extend the
syntax, I think the dot syntax is better.
Cascade priority of presentation hints vs. tree scopes
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6659
miriam: Problem noted here is that as specced presentational hints do
sometimes override author styles. I think not the intent
miriam: Request is fix spec so presentational hints always
overwritten by author styles. Likely moving up in cascade so
immediately after origins
fantasai: I would make it it's own origin. Simplest fix
TabAtkins: I think so too
astearns: Make it its own origin and spec where it fits?
fantasai: Yeah. Answer to that is obvious. Don't want to change
behavior
miriam: Between user and author?
fantasai: Yep
astearns: Concerns?
florian: Why is this not in UA origin?
TabAtkins: Presentational hints come from author doing things.
Interpreted as author intent, just weaker
astearns: proposal: Presentation hints into their own origin between
user and author in cascade
astearns: Objections?
RESOLVED: Presentation hints into their own origin between user and
author in cascade
Layers terminology bikeshed
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/5840
miriam: Another one open since the beginning. bikeshedding what we
call layers.
miriam: No alternative people liked better when we discussed. Seemed
time to close or make a change
<@fantasai> +1 to layers
astearns: I think at this point there is a slight bit of reason not
to make a change. In part because implementation has
started and articles written using layers term
<@florian> keep it as is
<miriam> +1
astearns: I don't think it would keep us from changing, but would
need good arguments for another term
astearns: Anyone want to argue layers is not the right word?
astearns: Proposal: Keep "layers" and close issue no change
RESOLVED: Keep "layers" and close issue no change
astearns: Do ping Brian to make sure he's okay since he's not on the
call and he opened the issue
CSS Contain
===========
"container width" and "container height" units
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5888
miriam: Earlier resolved we wanted them and went back to give names.
Can't give 'c'. Best I saw was 'q' units. qw, qh, etc.
<@florian> I like "q*"
astearns: Some people in issue have concerns about mix with q
typographical, but I don't think we should worry
TabAtkins: same
astearns: was cq considered?
miriam: I don't remember seeing that
astearns: I don't know I'm going to argue in favor of it
jensimmons: We did have vh and now we have lvh. Don't know if that
leads us anywhere with this
<fantasai> not sure the c adds much
jensimmons: Kontainer :)
astearns: fantasai on irc says c doesn't add much
jensimmons: Something with q. Agree it's a little awkward but q just
as a letter is nice
astearns: Anyone that wants to argue against the spec approach of q?
<@fremy> I feel like qw is liked because people use QWERTY
keyboards ^_^
<@fremy> Doesn't feel as special on AZERTY ^_^
astearns: proposal: Go with specified approach using q
<heycam> "queried width" reads well
plinss: We do have q unit
astearns: We do. Was discussion in issue about possibility of
confusion. I think people that understand what q unit is
will not be confused. People who don't know won't know it
exists
plinss: Concern with future name collisions
emeyer: That was my concern with future names
astearns: Future that spawn their own units
plinss: Last time we went through I raised concern on explosion of
unit types
astearns: Do you have a solution? We seem to be proliferating unit
types. I agree 2 letter names are sometimes difficult
plinss: Function
fantasai: If people type function names in parentheses when they want
to use a unit they'll be unhappy. We have units for a
reason and abbreviate for a reason so we should continue.
Agree we should avoid collisions but at least following a
pattern
plinss: Want to make sure this really need to be a unit and not that
we're doing it because we did it before. Not saying that's
case here but need guidance for next one
<emeyer> I do want to advocate for cq. It’s more mnemonic.
astearns: emeyer advocates cq as the mnemonic. Does protect against
possible future query units.
<emeyer> It would set a precedent of being more mnemonic with any
future units.
<emeyer> That’s all from me.
astearns: Anyone that would object to using cq instead of merely q?
<@TabAtkins> cq fine with me
<@miriam> also ok with me
* fantasai prefers q but won't object
<@fremy> cqw cqh sound fine
astearns: plinss you're okay adding these units because see need for
them to be units but would like more guidelines of when
units are necessary?
plinss: I don't have opinion on if these should be units. Haven't
given much thought. I do want clear guidelines as to what
should be a unit and why.
astearns: I think we need units because will use in same way as
viewport units today.
astearns: I see comment from jensimmons on the issue?
jensimmons: I wanted to see what it looked like
astearns: And what do you think?
jensimmons: Dunno
astearns: I think cq looks weird but may be because I looked at q for
a while
<@florian> I like the shorter version, but not to the point of
blocking if we want to go the other way
astearns: I am swayed by future proofing to keep from future query
units. cq provides distance from q unit
astearns: Proposal: Use cq as the prefix
astearns: miriam okay with you?
miriam: Yeah
astearns: Objections to spec ch?
RESOLVED: Use cq as the prefix
astearns: Resolved, unless someone comes back with a strong opinion
later
Define a syntax for style-based container queries
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6396
miriam: Style based container queries are idea we can look at
container and check computed value of a property and query
that and change things for descendants for value of property
miriam: Mostly used for high level custom properties where have set
of values, check on parent, and based on query make changes
miriam: Other use cases, that's main
miriam: fantasai and I added proposed syntax to spec.
miriam: At this point it uses normal property syntax so : between.
Some issues about supporting range syntax or attribute
selector syntax
astearns: Opinions?
fantasai: We talked about potentially having range. Was hesitant
because if want to catch range of values for width you
would not be able to do with style query because can only
compare length but not auto or other keyword-based width
values
fantasai: Reason I didn't want to add range syntax for computed style
is because will add confusion. Some point in future may
have use cases to add but best for now to keep to equal or
not
fantasai: Mostly will do lengths and use container queries for things
with sizes
smfr: A bit confused. Understood container queries limited to
elements with certain values on contain property.
smfr: Feature here sounds like could be independent of contain
property. Features here apply when not using?
miriam: Resolved earlier to use syntax to establish containers. Then
browser establishes containment behind the scenes. This would
rely on container type that doesn't apply containment in
background
smfr: Makes sense
astearns: Other comments?
astearns: My understanding is we're looking for resolution to accept
what's in ED and leave range syntax and attributes to
future issues
miriam: wfm
astearns: fremy it was your comment about attributes. Okay to ask you
to open new issue?
fremy: Isn't it same issue but delay to new level? I can open a new
one if people prefer
fantasai: Yes please
<@fremy> fantasai: ok, will do
astearns: Proposal: Accept proposal in ED. Split range syntax and
attributes to new issue
RESOLVED: Accept proposal in ED. Split range syntax and attributes to
new issue
Similar to window.matchMedia(), Container Queries should have a similar
method
------------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6205
miriam: Idea is have something similar for container queries. Claire
has provided a few options. Would be great to resolve on one.
Or something else
astearns: 3 options: new method. new observer. reuse resize observer
fantasai: Possible use cases for both approaches. Could start with
defining matchContainer since that's easy
astearns: You're thinking we would need matchContainer and either new
observer or reuse resize?
fantasai: Yeah
astearns: Anyone with opinions about adding matchContainer?
TabAtkins: This would allow style queries in the matchContainer since
they're under container query umbrella?
fantasai: Yeah
TabAtkins: Nice. Good
astearns: Proposal: Add a matchContainer method as proposed in issue.
Keep issue open to decide if need new observer or if we can
reuse the existing
astearns: Objections?
RESOLVED: Add a matchContainer method as proposed in issue. Keep
issue open to decide if need new observer or if we can
reuse the existing
<break>
Received on Thursday, 7 October 2021 22:36:27 UTC