- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Feb 2022 19:29:21 -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 Container Queries Level 3
-----------------------------
- RESOLVED: When we select a container, we determine which container
by looking at the actual queries and finding an
appropriate container for the questions being asked
(Issue #6644: Determine container type automatically from
the query)
- RESOLVED: Remove the container-type syntax from the preamble of the
@container rule (Issue #6393: Provide a syntax to query a
specific container-type)
- RESOLVED: All queries in an @container rule are against the same
container, which can answer them all (Issue #6876:
Multiple <container-query>s with multiple containers)
- The group will continue discussing style containers in the draft
for now and revisit the question of deferral (Issue #7020: Defer
style queries to level 4?)
CSS Pseudo
----------
- RESOLVED: Accept what's in the draft (Draft:
https://github.com/w3c/csswg-drafts/commit/aee785be2c270b6f52de066825cb24b3e02c0c3e
)
(Issue #2040: Problems with styling ::first-letter with
punctuation)
CSS Text Decor 4
----------------
- RESOLVED: Negative spread values on text-shadow are invalid (Issue
#6971: Disallow negative spread values on text-shadow)
- RESOLVED: Add inset to text-shadow (Issue #6074: Add 'inset'
keyword to text-shadow)
- RESOLVED: Text shadows start at outer (for outset) or inner (for
inset) edge of stroke (Issue #6074)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Feb/0003.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins Bittner
Delan Azabani
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Chris Harrelson
Dean Jackson
Jonathan Kew
Una Kravets
Daniel Libby
Ting-Yu Lin
Peter Linss
Alison Maher
Eric Meyer
Morgan Reschenberg
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Lea Verou
Scribe: fantasai
Scribe's scribe: emeyer
CSS Container Queries Level 3
=============================
<astearns> Summary of first three agenda issues for Feb 9:
https://github.com/w3c/csswg-drafts/issues/6644#issuecomment-1033245188
Determine container type automatically from the query
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6644#issuecomment-1033245188
miriam: All three of these issues are around how we handle container
selection
miriam: which is, in a container query, we have to find a container
to ask the questions
miriam: and once we've selected a container can query against it
miriam: These are all issues around how we find that container
<miriam> Issues are 6644, 6393, 6876, and 7020 to defer
miriam: 3 issues being discussed, I think it all ties together in the
first one, so will start there
miriam: Current logic is any element with container-type is a
container
miriam: and always look to nearest container for querying
miriam: so quite easily to get false negatives if you ask a query
that that container type doesn't support
miriam: so looking at how to avoid that
miriam: Proposal here is to look at the different conditions being
asked
miriam: is it asking for inline-size, block-size, style
miriam: instead of looking for nearest container, can look for
nearest container of a type that can answer all the queries
miriam: This ties into earlier decision that all elements are style
containers
miriam: If all are style containers, then nearest container is always
the parent, so this exacerbates the problem
miriam: Most queries will want to look higher in the chain than the
parent
miriam: Even if we reverted that, though, we still have this issue
miriam: Fragile to assume that no container will be inserted between
you and what you're trying to query
miriam: so I think we want to solve this issue regardless
miriam: Una wanted to return to that decision
miriam: Could potentially punt on having style issues
miriam: Third issue is, if looking for inline-size container and
style query looking for style container
miriam: Can nest those
miriam: and then each query looks for its own container
miriam: Could also combine multiple queries in a single @container
rule
miriam: In this case, are we querying a single container or multiple
containers (per query)?
miriam: Proposal is in the issue:
https://github.com/w3c/csswg-drafts/issues/6644#issuecomment-1033245188
miriam: and then Jen Simmons was asking about deferring style queries
entirely
miriam: so that's the overall summary
chrishtr: What is the implementation complexity and runtime
implication of these changes?
miriam: I haven't gotten any pushback form engineers I've talked to
chrishtr: Anders and Rune think it's doable?
fantasai: Can't imagine there's any runtime complexity, just deriving
type from query, not looking at the document tree at all,
and then back to where you were when we had to have an
explicit type
astearns: I assume spec would need to be clear how the queries select
for container types?
astearns: but that seems simple enough to me
una: I want to add that it seems doable, you'd still have to specify
a container type whether explicitly or whether stating in
container query
una: I like the idea of determining type based on the query, only
writing in one place
una: I still dislike everything being a style query by default
una: In order to have 6644, we'd have to revert 6393
miriam: I don't understand why we would have to revert
una: Wouldn't having everything be a style container interfere?
miriam, fantasai: No
fantasai: Not making every query a style query, making every
container a style query container
astearns: Still means your style query looks up to the immediate
parent every time
miriam: Yes, but I don't think that's a problem
miriam: In my mind, we should be encouraging authors that if they are
relying on something that might move, might have a new
container in between, need to use a name
miriam: If you're looking for background-color ancestor, need to use
name to filter the ancestors, shouldn't rely on being nearest
style query container because might insert another style
query container in between for other purposes
astearns: Any other questions or comments about selecting the
container based on query characteristics?
jensimmons: I think it's a good idea to have sensible defaults so
that the browser chooses containers instead of defaulting
to something that doesn't work
jensimmons: In chatting with our engineers, sounds like we don't have
implementation concerns
astearns: Shall we make this resolution and move on?
<fantasai> +1
astearns: Proposed that when we select a container, we determine
which container by looking at the actual queries and
finding an appropriate container for the questions being
asked
RESOLVED: When we select a container, we determine which container by
looking at the actual queries and finding an appropriate
container for the questions being asked
Provide a syntax to query a specific container-type
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6393
miriam: Next, is there any reason to keep an explicit container type
argument in the preamble?
miriam: Since we're already automatically determining it
astearns: What else goes in preamble?
miriam: Name and type, would drop type but keep name and that
simplifies the syntax
<fantasai> +1
una: I'd prefer to write explicitly, but if not majority opinion ...
una: Interested in hearing others
una: I think default of style queries is unclear
<emilio> +1
una: Would prefer each time you specify the query type
una: I don't think this works in default case because of everything
being a style query
miriam: We're already looking for the right type of container
miriam: so I'm saying we can remove that type from the preamble from
the container rule, now that it's automated
una: Sounds good to me
jensimmons: What's the preamble?
miriam: @container starts with a preamble for selecting the right
container
miriam: right now allows choosing type of container and name of
container, before the query
miriam: suggesting we drop the type keyword, since we can
automatically determine that
<TabAtkins> The part between the at-keyword and the {} block.
<TabAtkins> (I call this "prelude" in Syntax.)
<TabAtkins> Ah no preamble is a subset if the prelude, I see
astearns: No use case for wanting to query a more limited set of
containers than the query needs?
fantasai: Better in that case to use a named container
astearns: Seems we could add it later if needed
astearns: Anyone else with concerns about removing container type
form the preamble?
RESOLVED: Remove the container-type syntax from the preamble of the
@container rule
<TabAtkins> Yeah I'm quite happy with this latest resolution
Multiple <container-query>s with multiple containers
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6876
miriam: This is where we could reconsider the style default, or delay
implementation of style queries to L4 and bring it back later
miriam: or we can discuss it now
miriam: whether a default of style container is good to have on every
element
astearns: I'm concerned that we will constrain ourselves if we push
this off
fantasai: I think we should take it up, style queries are not that
complicated
fantasai: and I support Miriam's take on this issue
astearns: That is?
miriam: The default style query type is very useful for a lot of
cases, particularly for inherited properties
miriam: e.g. query the font-style style of the parent and flip it
from italic to normal or vice versa
miriam: would replace the toggle() feature that had been proposed
miriam: It's helpful in many situations
miriam: and for cases where you're looking at a non-inherited
property, want to look for a specific container
miriam: and in that case should be looking for a named query, not
relying on the container type
miriam: So my argument is it's a good default, it helps some cases
though not all of them, and for cases where it doesn't should
be using a name anyway and we should encourage that
una: My thought on this is, it feels a bit brittle to me
una: If you add an additional element between the container you're
querying and the query, breaks your query
una: You have to go up the tree for many things, so looking at the
parent feels brittle to me
astearns: I'm also leaning Una's way, since we made this other change
to avoid the mistake of selecting the direct parent; odd to
leave that in place
fantasai: Two arguments. One, on the issue of being brittle and easy
to break, yeah. If you were relying on a container type
lookup, and some other type of query container gets in
between, that will break. If we're consistently looking at
the parent, things become very predictable for authors. It
becomes clear that naming is needed to break that
nearest-container behavior.
fantasai: The second thing is that there are a lot of cases where the
ability to just look at your parent is useful. I suspect
there will be a number of pages that want to set this on
every element on the page just to get that ability. If they
do that, then the entire tree has a non-default value and
that's not performant.
fantasai: I think it's going to be easier for authors to understand
what they're doing if we have the default be that every
element is a style query container. That gets us default
behavior of the parent being the initial thing to look at.
We've had multiple request for features to look at the
parent for something. This would deliver that very easily.
fantasai: So I think we should do this. It will be a useful feature
and cause less breakage rather than more.
astearns: Yes, we have a lot of requests for a parent selector thing,
but this is a container feature
astearns: Might be a source of confusion
astearns: You mentioned can get into bad state by adding another
explicit container to the hierarchy. If you add a
container, queries will respond, different than just adding
an element
miriam: That gets into what I was going to add to what fantasai was
saying
miriam: When you're dealing with inherited properties, and just want
to check the parent, adding any element will break it.
miriam: Let's use <strong>, I want it to respond to whether parent is
bold or not bold and do something based on that
miriam: If parent changes to something no longer container, and
changes whether we're in bold or not bold, then any element
breaks that use case
miriam: the inherited property use case is only useful if we assume
we can get the right answer from the parent
miriam: and I'm guessing we'll get a "best practice" where people set
style containment on every element
miriam: and as fantasai said, that will create a performance hit
jensimmons: I feel from an author's perspective, the proposal that
Miriam has put together is the best way to go
jensimmons: I understand what Una is saying that in big projects, it
doesn't give a lot of functionality. They want to create
components and style systems and have no idea what the
DOM is going to be
jensimmons: but I think that's true for a lot of CSS, where the
simple way, the default of CSS doesn't hold up in big
projects, and more powerful tools are needed
jensimmons: and that's what container names are for
jensimmons: But there really are many many projects that are not
multimillion dollar projects
jensimmons: and this simple querying that we're discussing, with the
font-style: italic query example, it's so nice and
expands what's possible
jensimmons: I don't think we should break that because the big
projects need something else
jensimmons: Philosophy in CSS should be to give simple defaults that
work for the small projects, and give more powerful tools
for the big projects
<TabAtkins> Miriam's point is that in that nested case you *can*
generally depend on the parent for style, because you
very likely want the inherited value. If you don't, then
you should be explicitly naming on both sides.
una: I don't see this a large or small project thing
una: My concern is that the DOM change so quickly, you have a
paragraph inside a list and link inside, so lots of layers
already
una: and not realize that you're not directly within a parent
una: 2nd question, example of font-style italic
una: what happens when you have an em that also has a span and then a
link inside of that?
una: This is where the uncertainty of the output comes to me
una: I don't see the direct parent, you don't know as a publisher
what the output DOM would be
una: So I see this getting murky
una: But there is room from dev perspective to get really clunky, and
generally expanding more into component queries it get less
useful
una: Is this going to introduce confusion if not fully aware of what
DOM looks like?
una: Is this going to be majority use case, worth a default?
astearns: One thing that made me possibly reconsider, you're talking
about clunkiness, for the cases that you're concerned with,
authors can use container names
astearns: but if we do not have the style container be the default
for all elements, then in order to serve that use case,
then there needs to be a reset with * { container-type:
style }
astearns: which seems even more clunky than using container names
una: So you'd need a container name?
miriam: Right. You'd need it to be always the parent for it to work.
una: Yeah, that's the strongest argument I've heard
miriam: And to me, brittle DOM is an argument for this. Or rather,
it's an argument for always using a container name when you
need the DOM not to be brittle.
una: Sounds like it would be a best practices / education point then
una: That last point really drove this home
astearns: I'm really concerned about the teachability of this
astearns: We've got explicit containers, and also implicitly style
queries.
astearns: But it does seem to be the best default to start with
astearns: So spec currently says that style containers are the
default?
miriam: I'm not sure that's in the spec yet, but it was resolved
astearns: What if we don't re-resolve, just leave things as they are
and give Una and whoever else some time to come up with
arguments for changing back?
una: Works for me
una: I definitely see both sides of this
una: Want consistency for the spec
astearns: Anything more on this issue?
miriam: Need to clarify when multiple queries in a container rule,
would they individually select different containers
miriam: I think we should resolve that for a given @container rule,
select a single container for all queries in it
miriam: not different containers for each query within the @container
<TabAtkins> Strong+ on this new resolution
astearns: We would have that with nested @container queries, right?
So this would just be about adding easier syntax
fantasai: I'm a strong +1 on this resolution
fantasai: If we want to do mixed in a single statement, that's an
argument for using @if/@when syntax that allows you to
flatten nesting.
astearns: Proposed that we check all queries against a single
container that can answer them all
RESOLVED: All queries in an @container rule are against the same
container, which can answer them all
Defer style queries to level 4?
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7020
astearns: Next question is whether to punt on style queries
astearns: Since we still have this open question of whether to make
all elements style containers, we should punt?
jensimmons: Yes, please
Decision: Continue discussing style containers in the draft for now
CSS Pseudo
==========
Problems with styling ::first-letter with punctuation
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2040#issuecomment-1001364249
<astearns> changes:
https://github.com/w3c/csswg-drafts/commit/aee785be2c270b6f52de066825cb24b3e02c0c3e
fantasai: Want to confirm with the WG that these edits are acceptable
fantasai: Resolved to add sub-pseudo-elements, didn't decide on names.
fantasai: Florian suggested ::prefix and ::postfix, which has
advantage of being usable on ::marker as well
fantasai: So wanted to confirm with WG
dbaron: How understandable would these terms to non-English speakers
/ other English speakers
astearns: ...
dbaron: prefix is much more common than postfix
plinss: Alternative would be suffix, but postfix has better symmetry
astearns: Anyone lining up to implement this?
astearns: Lacking that, I say we go with what's in the draft
<tantek> +1 to suffix. better known term than postfix. usability
trumps symmetry
RESOLVED: Accept what's in the draft
Text Decor 4
============
Disallow negative spread values on text-shadow
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6971
fantasai: Proposal is to disallow negative spread values on
text-shadow by making them invalid
<emeyer> +1 from me on making them invalid
astearns: Any objections?
<TabAtkins> +1
smfr: Minor surprise for authors, because box shadow and text shadow
have different behavior, but I'm OK with it
RESOLVED: Negative spread values on text-shadow are invalid
<TabAtkins> They *do* have different behavior, so the slightly
different syntax matches that.
Add 'inset' keyword to text-shadow
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6074
fantasai: Proposal is to add the 'inset' keyword and allow inset
shadows on text
smfr: For box-shadow, it interacts with border and is inside the
border
smfr: unsure if we have spec text on interaction with stroke
smfr: Still OK to add it, and figure out later on
fantasai: So should have text shadows start at the edge of the stroke
(both outset and inset)
smfr: Makes the most sense
fantasai: Outset shadows would start at outer edge of stroke, inset
shadows at inner edge of stroke
astearns: Any objections?
RESOLVED: Add inset to text-shadow
RESOLVED: Text shadows start at outer (for outset) or inner (for
inset) edge of stroke
Received on Thursday, 10 February 2022 00:31:03 UTC