[CSSWG] Minutes TPAC/Vancouver 2022-09-16 Part III: CSS Grid, CSS Conditional [css-grid] [css-conditional]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS 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
  - 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.


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
  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
  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
  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
  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
  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
  TabAtkins: The issue I have it that the names
  TabAtkins: what if both grids define the same names, but different
  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
  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
  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
  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:
  <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
  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

  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
  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
  <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
  <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
  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
  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
  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
  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

  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;
  <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
  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
  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
  fantasai: Authors are going to expect that when you put a test in
            @supports it's everything you put in there that you're
  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
  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
  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
  <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
  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
  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
  <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
  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
  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

  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
  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
  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