- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 19:00:46 -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 Grid
--------
- RESOLVED: Static position does not depend on an abspos' containing
block (Issue #7661: Application of grid-positioning
properties to static position of grid children is
inconsistent)
- A strawpoll to decide if the spec should say to ignore or honor the
grid-positioning properties when finding staticpos of grid
children came out approximately even between the two options.
Discussion will return to github issue #7661 to discuss examples
and try and reach consensus.
CSS Conditional
---------------
- There wasn't clear consensus on Sebastian's suggestion
( https://github.com/w3c/csswg-drafts/issues/3559#issuecomment-1114545949
)
for issue #3559 (Testing support of properties and values with
partial implementations) so discussion will continue on github.
- The proposed resolution for issue #6966 (Add ability to test for
at-rule preludes) was to allow testing at-rule preludes, but to
exclude @media, @supports, and @container from this form of the
test; using them will invalidate the @supports rule.
The group ran out of time to resolve all the outstanding
questions, though, so discussion will continue on github after
TabAtkins adds a summary of his proposal.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/32
Scribe: fremy
Scribe's scribe: fantasai
CSS Grid
========
Application of grid-positioning properties to static position
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7661
fantasai: The static position of a child of a grid container ignores
the grid positioning properties, unless its grid parent is
also its containing block, in which case we honor the grid
positioning properties
fantasai: Normally, the static position of an abspos does not depend
on which element is its containing block
fantasai: so I think it's weird and inconsistent that here we make a
check for the parent being a containing block to pull more
information
fantasai: I would rather us be consistent
fantasai: we either always pull more info, or never
fantasai: and I have the impression that doing it always sounds a bit
more useful in some cases
iank: One thing to keep in mind
iank: is that if we consider the properties all the times
iank: it would allow out-of-flow elements to be positioned in the grid
iank: I don't have a strong opinion, but it's strange
TabAtkins: If the grid placement properties talk about different
grids, it's indeed confusing
TabAtkins: applying never is ok for me
TabAtkins: but applying all the time is strange, because you can end
up targeting multiple grids, which is weird
fantasai: If your containing block is a grid, and you are not
statically positioned, we do use the grid positioning
properties to modify the containing block to which you are
positioned
fantasai: The case TabAtkins mentioned is when your parent is a grid,
its grand parent is a grid, and you apply the positioning
in one axis, that will be applied, but in the axes that are
auto, then you would position relative to the parent
fantasai: so this is indeed two different grids in this case
fantasai: but I don't see why this is a problem, this sounds
interesting
astearns: But it sounds like TabAtkins might object?
astearns: Would you consider objecting to never applying?
fantasai: No, I would not object
fantasai: Static position of a grid child does not depend on the grid
placement properties
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10728
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10729
dholbert: Where does it go then?
fantasai: The padding box of the grid container
fantasai: not one of the areas
iank: I think Blink might implement the double position thing
iank: I pasted an example above
fantasai: I think that's cool!
astearns: But isn't it good in few cases and wrong in many cases?
fantasai: Not clear that it's the case
<fantasai> I don't think it's ever wrong. Tab just thinks it's scary
iank: I can clarify
iank: You have two nested grids
iank: the positioned element is inside the inner grid
iank: it uses the static position of the inner grid if you don't to
anything
iank: but if you use an inset properties, you are positioned based on
the other grid
fantasai: The static position is normally "where you would go if you
are not absolute element"
fantasai: so, I think we should probably use the values always
fantasai: and, really, I think it makes sense
fantasai: If you set the inset properties, you don't get the static
position
fantasai: so, yes, this will be relative to the containing block
fantasai: If you do it in just one axis, you are combining the two
behaviors
TabAtkins: The issue I have it that the names
TabAtkins: what if both grids define the same names, but different
purposes?
TabAtkins: I think the grid properties should only apply to the grid
you are in
TabAtkins: applying the same property to the another grid seems
nonsensical
fantasai: It's because we use a shorthand
fantasai: but you can use one longhand for one axis
fantasai: and another longhand for the other axis
fantasai: and do it on purpose
TabAtkins: No, I would rather object
emilio: Is the current behavior interoperable?
dholbert: In Firefox we seems to use the properties never in that case
<fantasai> we have zero interop on this btw
<fantasai> all three engines differ
iank: And if you use the inner grid for the containing block?
iank: it seems Gecko follows the spec
emilio: ok, I think I'm convinced that the current Blink behavior is
pretty weird
emilio: and Webkit?
fantasai: Totally different
dholbert: I have another concern
dholbert: In the end example, if you specify one of the inset of the
properties, it could not be a grid
fantasai: I don't understand
fantasai: You can change the value per axis, so if you want to
position against your ancestor grid, you would not set the
auto value
fantasai: if you opt in into it, you can target one grid or the other
dholbert: But ok, it's only weird because there is only one single
property
dholbert: depending on another property
emilio: webkit seems to honor the middle grid like firefox
emilio: so that seems interoperable
emilio: so all browsers do it
emilio: I would rather keep the spec as is
astearns: Ok, so the options are "keep the spec as is" (and Blink
fixes) or just remove the fact it applies anywhere
fremy: If it's interoperable, why change
fantasai: It's not interoperable
fremy: I have the impression that case where you're using the parent
directly, it's interoperable
fremy: so probably websites rely on that
iank: Static positioning is very rarely used
iank: I don't think websites rely on that
Rossen: I am all for consistency in general
Rossen: but not applying the properties is a bit clinical here
Rossen: Why did we decide that the properties apply in the first
place?
Rossen: There was maybe a good reason
Rossen: Also, we need to think about subgrids
Rossen: if we decide something that doesn't make sense for subgrids,
we will have to revert
Rossen: Static position is odd in general, so I don't think the
oddness noticed by that is that strange
Rossen: just using inline parents and different writing modes would
probably also get you very strange cases
Rossen: and I don't see why this particular case is more weird than
they are in general
Rossen: So, to sum up, if we want to change the spec, can we weigh
our "weirdness" against the initial decision
TabAtkins: Subgrid should not be conflicting with this
TabAtkins: The reasoning we hand for supporting the properties was
that we should pretend the element was positioned normally
TabAtkins: but it doesn't serve the same purpose as in block layout
because there are variations anyway
TabAtkins: so I don't think the reasoning is not strongly valid, and
I would be happy to drop that, and make things as simple
as possible
iank: If you do this change, I don't expect a compat issue
iank: but positioning the abspos in the containing block in an area
is very useful
iank: this not as much
fantasai: I think positioning where the item would have been
fantasai: it's what static position is for
<dholbert> here's an example of us placing the item "close to where
it would have been" when it's not the direct parent:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/10734
<dholbert> (I think)
TabAtkins: The reason for the current spec is that we did not want
the two grids use the same shorthand
fantasai: Ok, possibly
fantasai: but I still value the initial reasoning
fantasai: and in the rest of CSS, the static position logic is never
conditional on which element is the abspos containing
block, and we should keep that invariant
fantasai: and if we allow this, it gives new possibilities to the
author
fantasai: The reverse is removing options for the author
Rossen: I agree with what fantasai said on the initial reasoning value
fantasai: For this aspect of grid, it's possible to make it work in
an author
fantasai: if you don't want the grid positioning properties have
effect on staticpos, don't set them
TabAtkins: Or you can use anchor positioning ;)
iank: To return to the subgrid case
iank: for subgrids, static positioning should be what?
fantasai: Very similar for subgrids to the nested grid case
iank: So, the axes don't apply to the subgrid directly, all is on the
layout grid, correct?
fantasai: Yes
dholbert: We can sort of do that by using a wrapper
dholbert: so, if we remove the ability to respect the properties
dholbert: you can use the wrapper
Rossen: Sure, you can always use a wrapper
Rossen: but the intent of the property was to do that by default
dholbert: But the wrapper makes the intent clear
dholbert: and it forces the consistency
dholbert: so I am not against that "clarifying" wrapper
Rossen: And don't like that complexity, but I agree it exists in
multiple places
fantasai: I think we should resolve on whether we want to use the
properties at all
fantasai: then we work in the details
TabAtkins: No, I disagree with that framing
TabAtkins: we have two constraints
TabAtkins: and only never applying fits both constraints
<emilio> +1 to Tab
TabAtkins: So, can we handle everything together, and just specify
what we want
astearns: Ok, first resolution
fantasai: Proposed resolution: static position does not depend on the
abspos containing block
dholbert: Well, some properties do affect this
iank: We will discuss this just after, this is the next issue
fantasai: The parent will affect things
fantasai: But the containing block not
dholbert: Ok, yes, I think you are right
astearns: Ok, can we agree on that proposed resolution?
astearns: Any objection?
RESOLVED: static position does not depend on an abspos' containing
block
fantasai: So, now, does the static position of a grid child depends
on the grid properties, or do we ignore them
astearns: And if we choose not to ignore them, then we have the weird
case
iank: Considering this further, I don't care
iank: My only issue was the current spec
fantasai: We can do a strawpoll
<fantasai> 1. Ignore grid-positioning properties when finding
staticpos of grid children
<fantasai> 2. Honor grid-positioning properties when finding
staticpos of grid children
<TabAtkins> 1
<fantasai> 2
<dholbert> 1
<Rossen> 2
<astearns> 1
<rego> 1
<fremy> 2 (I have wanted that in the past, I am pretty sure)
<emilio> 1
<emeyer> 2
<iank> 3
<TabAtkins> (Remember that anchor positioning gives a strictly more
powerful ability than static pos, if you do want that
functionality.)
<rachelandrew> 1
<hober> abstain
fremy: I'm fairly sure I wanted that when authoring stuff
fremy: this is what's implemented today, why we would we change that
if I wanted it?
fremy: for at least the normal level, I still want to use the
properties there
fremy: nobody really cares about the weird nesting
fantasai: You can just not use static positioning if your parent is
also the abspos
iank: I want to hear from rachelandrew and emeyer
rachelandrew: Would be good to request use cases. I can't think off
the top of my head, but doesn't mean there aren't any
emeyer: To me, I'm with rachelandrew on this. It wasn't a strong
opinion, and I think it would be beneficial to come up with
use cases
emeyer: and see what authors think
emeyer: I voted opposite in part because it feels slightly more
intuitive that if you're looking at grid children, you should
look at grid positioning properties. You're in grid context.
emeyer: not strong opinion, but feels right
emeyer: would be interested to see use cases that depend on one or
other behavior
emeyer: that would help a great deal
astearns: My opinion is that having unexpected behavior and then
deciding what one might use it for is probably not the best
way of collecting use cases
fantasai: I want to add some other points
fantasai: If we make it work, you can always disable it
fantasai: Because you can not set them if you don't want
fantasai: Also, right now we focus on the case of two nested grids
fantasai: but in general, the containing block does not have to be
a grid
fantasai: it could be a block or a flex
fantasai: but you might want to have the control in those cases
fantasai: Yes, if you have two grids, it can be a bit confusing
fantasai: but let's not forget the general case, where the properties
are ignored just because the containing block is not a grid
fantasai: that would not change
fantasai: and I think we should focus about, are there use cases
where your parent is a grid
<Rossen> +1 to the above reasoning. The two nested grids is an edge
case that sways the decision artificially
emeyer: it's difficult to say on the spot
emeyer: if we want to ask for opinions, we need examples
<TabAtkins> Also important: whether these use-cases are better served
by anchor positioning, because they generalize to
"positioned containing block is elsewhere, but I want to
align in some way to different element". Static position
usage is *almost always* a funky hack attempting to
achieve anchor positioning.
astearns: Ok, we will take this back to the issue, and decide based
on these examples
<break type=lunch>
CSS Conditional
===============
scribe: fantasai
scribe's scribe: heycam
Testing support of properties and values with partial implementations
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3559
astearns: Sebastien added some comments, unable to join in person
astearns: he has a specific suggestion ...
<astearns> this comment
https://github.com/w3c/csswg-drafts/issues/3559#issuecomment-1114545949
<dbaron> I think fantasai's suggestion might be the same as the two
that I implemented
rachelandrew: This came up originally because of the gap property
rachelandrew: originally defined for grid layout, later expanded to
flexbox
rachelandrew: but can't test within @supports
rachelandrew: so can't e.g. provide a fallback margin
rachelandrew: unsure where it will come up in future, but for specs
like alignment which applies to lots of things could
come up
rachelandrew: so that's why opened the issue, for testing whether
property X works in context Y
rachelandrew: Idk how likely it is to appear in the future
fantasai: Another context is alignment properties applying to abspos
or block containers
fantasai: and fremy had suggested gap applying to tables, so that's
another place
astearns: We have general issue of interactions that are difficult
to test
astearns: Sebastian had specific suggestion of allowing custom
support rules
astearns: that would run author JS to check for a particular thing
they wanted to test
astearns: Sebastian asked whether this is a reasonable way forward,
is it possible in browsers
heycam: No real obvious time to run that script
heycam: would want to run it only once
heycam: maybe at the time the stylesheet is loaded could run it?
heycam: It feels weird to have some script run at some point for that
heycam: I do feel like you do want a traditional feature-testing way
of checking this
heycam: e.g. test whether gap on table, checking whether it has some
effect on the size of the element
heycam: but idk what's a concise way to run that in a query string
fantasai: So far most of these are dependent on your formatting
context or box type
fantasai: so it's not that you want to check interactions with other
properties, but specifically whether properties apply to
specific types of boxes
TabAtkins: On subject of well-defined time to run, this is the same
problem as wanting custom MQ
TabAtkins: so we could just run it on that
TabAtkins: no difference between writing @media --flex-gap
TabAtkins: which you set at page load
TabAtkins: vs in supports
TabAtkins: if we feel it's needed for usability, maybe separate
registry
TabAtkins: but run script once and run well-defined time, already
have proposal to solve
fantasai: For the usability aspect of it, there's been proposals of a
generic @if statement
fantasai: rather than having custom MQs, you could have a more
generic syntax in an @if statement
fantasai: so you could do it in a MQ, or in an if
astearns: Maybe this is enough feedback to satisfy for now?
astearns: anyone else to weigh in?
dholbert: Curious what DOM these queries run in
dholbert: does it persist
TabAtkins: Answer is, depends on what you are talking about
TabAtkins: If you're doing custom MQ, it's whatever you want. You're
just running JS and updating a map
TabAtkins: that's attached to the document object
TabAtkins: that'll be available to any stylesheets attached to that
page
TabAtkins: if doing something else, depends on specifics
astearns: Let's leave this issue here, and see if we make more
progress in issue itself
Add ability to test for at-rule preludes
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6966
TabAtkins: Earlier we defined testing for at-rules and descriptors,
which we can do generically by throwing it at a parser
TabAtkins: we don't have ability to check if prelude of at-rule is
valid or not
TabAtkins: this should follow the same "throw at parser and see", but
not possible atm
TabAtkins: especially important for at-rules that don't have blocks,
e.g. @layer statement form
TabAtkins: you can test @layer at all, but not specifically for @rule
statements
TabAtkins: Suggest we take the first form of the at-rule syntax and
allow it to take more
TabAtkins: parse all of that as the prelude
TabAtkins: as long as it passes your parser check, it's OK
miriam: I think this is also required for testing whether style
queries are supported
heycam: I'm wondering if there's any benefit from having this called
"rule" rather than "at-rule", can we match any kind of rule
not just at-rules?
TabAtkins: Unless you know the context you're parsing in, there's
only one type of rule and it's style rule
heycam: For those rules you can rely on selectors and individual
properties
fantasai: To summarize, three parsing forms for at-rule function
fantasai: One just takes the name
fantasai: one takes the entirety of the rule, and if anything is
dropped, then it returns false
fantasai: and the third is the existing descriptor, `@foo;
descriptor:value`
<fantasai> https://github.com/w3c/csswg-drafts/issues/6966
<TabAtkins> at-rule(@foo bar {baz: qux}),
fantasai: That would let you do complicated nesting structures as well
TabAtkins: If feed into parser, is the top-level rule kept or not.
Ignoring inside things.
fantasai: I think that would not be helpful
TabAtkins: More specific, would require more specific plumbing in
browsers
TabAtkins: to report pass or failure
TabAtkins: and also it's more powerful than you necessarily wanted
fantasai: I think if we want to add a full whole thing kind of
syntax, then we should be parsing everything in there and
if anything is dropped, you fail
fantasai: if you want it more limited
fantasai: if you want to check statement vs block, then add curly
braces
fantasai: as soon as you put something in there, authors will expect
it's testing everything in there
fantasai: if we ignore invalid things inside, authors will be
confused, and we won't have an extension mechanism in the
future
fantasai: Authors are going to expect that when you put a test in
@supports it's everything you put in there that you're
checking
fantasai: Fine to add more specific syntaxes, but authors are going
to expect if you add in @supports, it's checking the full
thing is understood
miriam: I agree
chris: Yes
TabAtkins: That is something that was specifically called out, that
bubbling up invalidity is problematic
TabAtkins: That was specifically called out as problematic in an
earlier discussion
fantasai: So limit the syntax
TabAtkins: Then do nested structures
fantasai: if you want to do nested structures, do it properly;
otherwise don't do nested structures
florian: We don't want @supports to be smart. Want to use the actual
parser
florian: If we start to maintain some degree of logic, then that
logic can get out of sync with reality
florian: Usefulness of at-supports will decrease if we try to be
smart about it, because will be less reliable
fantasai: I think it's more important that anything we allow in
@supports, the author can rely it's testing the whole thing
fantasai: I think that's more important than the concern that it
might get out of sync
TabAtkins: I disagree. author confusion is substantially better than
UA lying.
fantasai: The UA is effectively lying from the perspective of the
author
fantasai: if you let it ignore stuff that is inside @supports check
astearns: This is an issue about preludes, so how about we just add
preludes and not address nesting
TabAtkins: So we would just take the prelude, not semicolon
emilio: I agree with TabAtkins, it's weird to suddenly pass e.g.
@font-face rule, and you read the descriptors and the ones
you care about you keep and the others you ignore
emilio: it would require this special mode, then you have to find the
places
<TabAtkins> Authors being confused means the author can fix this, by
doing it right. UAs lying means the author can't fix
this; they're just screwed. UA lying is *meaningfully
different* from author confusion.
fantasai: I'm not arguing with you on this point
fantasai: if you're going to allow the syntax in @supports, then you
must check all of it
fantasai: if you don't want that, don't allow it in the syntax
astearns: So proposed resolution is allow @rule preludes in the
syntax, and check them for validity
fremy: You have at-rule in the prelude, what if at-rule is only valid
inside another at-rule?
TabAtkins: This should still be fine, you won't be able to do any
parent-child checking
TabAtkins: but this sub-at-rule gets parsed somehow
TabAtkins: Only problem is if you have two different at-rules that
have different children with same names
fantasai: If I say @at-rule(@media foo), will that parse as
supporting querying against foo?
fantasai: that's not going to cause the media rule to be invalidate,
I'm asking whether you support that media rule
fantasai: if it's going to return true for anything that appears
after @media, that's not useful, and it is confusing and
unexpected to the author
TabAtkins: [missed]
emilio: We have custom parsing for unforgiving selectors, right?
TabAtkins: Still, I suspect that this is a distinctly different thing
because switching between selector lists isn't
straightforward
emilio: But there is some amount of precedent, not that I love it
florian: For fantasai's example about media queries, it's undecidable
florian: because, telling the difference between whether you support
querying whether running on 3D printer vs asking, you can't
distinguish as an author
florian: you'll get a "no", which is the correct answer
fantasai: Let's take a better example
fantasai: Consider the touchscreen MQ
fantasai: If the author asks do you support querying whether this is
a touchscreen, and you say sure, I support every media
query ever
fantasai: then the author will assume you support the media query
TabAtkins: They'll get a no when they actually use the MQ
fantasai: Maybe they want to figure out some other heuristics?
fantasai: Maybe I'll change my layout if you don't support this MQ,
and cannot know from the MQ whether you support a
touchscreen
fantasai: but you don't have the ability to check that
fantasai: Not saying you necessarily don't need this feature, I am
saying if you put it in an @supports query, the author will
reasonably expect the browser will check if it understands
that MQ, and we should not violate that expectation
TabAtkins: Anything that requires custom parsing
fantasai: Then don't allow it
TabAtkins: Either you can never test for preludes, or for some
extremely forgiving syntaxes, this query is not going to
be maximally useful
TabAtkins: and we can introduce a new query later
TabAtkins: either we don't allow preludes at all, or we accept that
@media is confusing
TabAtkins: And we fix it in the future with a `media-feature()` query
astearns: Is that going to be acceptable, to allow testing for
preludes with this possibly workaroundable thing?
fantasai: Depends what other people think? I'm only one member of
this WG
miriam: I agree with both of you.
miriam: so that's helpful!
florian: I'm lost about the overall discussion, but I think @supports
testing of media queries is not useful given current form of
media query
fantasai: How forgiving is parsing on CQs?
miriam: So the problem is specific to media queries, we don't have
the problem with container queries right?
emilio: It's same
emilio: also have same problem with @supports itself
florian: Well people won't use @supports @supports
florian: nobody will do that one so it doesn't matter
<TabAtkins> Anything with `<general-enclosed>` in the grammar is
forgiving in this way, and won't be good to test.
<fantasai> TabAtkins, yeah, but authors can't figure that out
<fantasai> TabAtkins, it's totally opaque to them
<TabAtkins> yeah, I'm just answering the question
miriam: People do want to know whether @supports of selectors works
miriam: So what's the solution that gets us there?
florian: MQ was designed to work around the problem. When browser
doesn't know how to answer it doesn't know how
florian: [...]
fremy: You can design the query so you get the support you want
florian: If you want a third design where you don't know whether your
design can hover, this is tricky
TabAtkins: We can let author solve that with custom MQ
TabAtkins: because that's what they do today
miriam: Does @else help? Means you can just attach a negation to the
query itself
TabAtkins: top-level query is always true or false, unknown is not a
response
<miriam> @try/@catch
emilio: For @media, can't you do that? Ask for a logical combination
of your query and not your query
emilio: e.g. @media hover and not hover, and that should be true on
all browsers that support hover and not on ones that don't
emilio: I mean 'or'
emilio: so can do that with CSS already, though not beautiful
<TabAtkins> (true or false) is true, (unknown or unknown) is unknown
(and thus false)
<TabAtkins> so yeah that works
florian: For media features yes, but not media types
TabAtkins: I think we have multiple ways to address the media being
restrictive
TabAtkins: I would be very sad if, though we have ways to address it,
we lost ability to do anything else that doesn't have
forgiving this nature
TabAtkins: fantasai, can you let us do this as specified, if other
features can let you figure out media queries
fantasai: I can live with it, but I really do want to hear from
others in the room
astearns: Proposed resolution is to allow testing of at-rule preludes
in supports, using the prelude syntax and no nesting as yet
florian: I suggest we include a note that things that have forgiving
parsing will say yes, and it doesn't mean that they are
support
fantasai: I think it will confuse a lot of people, but I understand
we do want to do this for other things for which it does
make sense
fantasai: my concern for CQs is that if we have to invent a new
function for say state queries, they'll ask if that's
supported, and we'll say yes
miriam: This doesn't work for the things I want it to work for
miriam: and I agree it'll confuse people
miriam: I wonder if we can restrict it to just the things that it's
useful for?
TabAtkins: We could maybe do that, say it doesn't do anything on
@media/@supports/@container
emeyer: I think Tab addressed my concern.
emeyer: I'm concerned we're starting to cross into territory.... I
agree with Elika's point that this will be confusing in these
cases
emeyer: if we restrict from those cases, then it's ok with me
emeyer: @supports is already a bit confusing, e.g. @supports
(text-decoration: blink)
emeyer: I was concerned that we would introduce a class of problems
that authors would be *much* more confused about
emeyer: but I believe the syntax restrictions would address my
concerns
astearns: What would it address?
fantasai: Anything with forgiving syntax
TabAtkins: we have 20-something at-rules ...
florian: Anything with <general-enclosed>
florian: Alternative is if you hit <general-enclosed>, return false
TabAtkins: That's specialized parsing
heycam: So it's that the condition, if you use an at-rule(@media ...)
it's not invalid, it's just false?
florian: Would prefer invalid, so if we figure out how to solve we
can make it work
astearns: I've lost state of proposed resolution
<TabAtkins> Proposed resolution: allow testing at-rule preludes.
Exclude @media, @supports, and @container from this form
for the test; they're invalid to use.
<TabAtkins> (Generally, anything using <general-enclosed>, but for
now it's those three.)
florian: Can you clarify, they're invalid, does that mean they return
false or they fail to parse?
TabAtkins: They make the rule invalid
florian: What do you mean by "the rule"
fantasai: It's as if you wrote foobar() instead of at-rule()
TabAtkins: foobar() is a false query
astearns: We will work out what the remaining proposal is in the
future for specific syntax and behavior in a summary
comment from TabAtkins
TabAtkins: I gave the proposed resolution, ignoring that bit about
clarifying invalid
astearns: Let's get it written out, and then come back to it
astearns: because I've had several people ask that we get to Toggles!
<florian> "@support at-rule(@media foo) or (display:block) { :root{
color: blue ) }" What does that do, blue or not blue?
Received on Tuesday, 25 October 2022 23:01:29 UTC