W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes TPAC/Vancouver 2022-09-15 Part IV: CSS Cascade [css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 18:38:07 -0400
Message-ID: <CADhPm3v2xFra5ufuE+gArrthGp-BWUWFme6WYHjGFpfb4xnq5A@mail.gmail.com>
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: No change to the previous resolution (for now, more
              discussion is needed) (Issue #7002: Add a R/W
              `CSSStyleSheet.layer` attribute for the layer name)
  - RESOLVED: Remove scoping from selectors (Issue #7709: Can we
              replace the selector scoping notation with a new
              parameter in `querySelector()`?)
  - RESOLVED: Add scope() to @import syntax (Issue #7348: Add ability
              to scope rules from an imported stylesheet)
  - RESOLVED: ~~ is a sibling combinator that prefers closer siblings
              (Issue #7233: Is it possible to account for proximity of
              sibling elements?)
  - RESOLVED: @scope without selector scopes to the parent of the owner
              node, or the containing tree if there's no owner node
              (Issue #7349: Add a :stylesheet selector to match the
              current stylesheet)
  - RESOLVED: Make exclusive lower boundaries the default and add an
              example to the spec on how to do inclusive (Issue #6577:
              Inclusive vs exclusive lower boundary)
  - Miriam asks everyone to review effect of scope proximity in the
      cascade: https://github.com/w3c/csswg-drafts/issues/6790

====== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/31

Scribe: emilio
Scribe's scribe: heycam

CSS Cascade
===========

Add a R/W `CSSStyleSheet.layer` attribute for the layer name
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7002

  miriam: We resolved on the main question, a CSStyleSheet.layer
  miriam: another question came up that fantasai and me weren't sure
          how to answer
  miriam: Can the same sheet be imported in different layers
  miriam: is it guaranteed that different imports end up with different
          sheets or do we need to track all the different names?
  emilio: The CSSOM guarantees each @import rule should be a different
          style sheet
  emilio: so I think we're good

  RESOLVED: No change to the previous resolution

  emilio: Xiaocheng is talking about CSS Imports, not @import
  emilio: I don't know how CSS Modules behave, if they always create
          the same style sheet object, or multiple
  emilio: I was talking about @import rules
  emilio: Presumably if Xiaocheng is asking, they must only create a
          single object
  chrishtr: We should continue to research then get back to the issue
  dbaron: I have some memory of a discussion in a TAG review about
          whether they create separate objects, can't remember the
          conclusion
  <dbaron> https://github.com/w3ctag/design-reviews/issues/405
  <dbaron> not sure if
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md
           is still accurate
  Rossen: let's re-discuss when Xiaocheng is back
  <zcorpan> (I found
https://html.spec.whatwg.org/multipage/webappapis.html#creating-a-css-module-script
)

Replacing selector scoping notation with a new parameter in
    `querySelector()`?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7709

  miriam: In the @scope spec we tried to provide the at rule and also
          tried to provide notation for Selectors
  miriam: the reason was to use querySelector to return scoped results
  miriam: that ended up being difficult and raised many different issues
  miriam: syntax is easy to solve in @scope and harder in selector
          notations
  miriam: is it worth to pursue that or can we add a second argument
          to qSA
  miriam: and get rid of the selector notation

  TabAtkins: I think we should switch the second arg to an options bag
  <TabAtkins> querySelector(".foo", {upper: Element, lower: Element} )

  emilio: I assume the way this would be implemented would be basically
          a post-processing of sorts
  emilio: you'd first match the selector, then if it matches, you check
          the scope. do we really need a querySelector API for that?
  emilio: It's like a filter on the querySelectorAll results
  miriam: I'm not sure I understand your proposal Tab
  emilio: I understand the proposal, but do we need to build this into
          qSA? can't you process the qSA results?
  miriam: If I'm reading Tab's proposal right, you're looking for a
          selector within a scope
  miriam: I'm trying to return a scoped fragment of tree
  miriam: which is a bit different from scoped selector
  miriam: so when you grab an element you get its descendants
  miriam: potentially with cutting off some lower boundaries
  TabAtkins: That's what you'd get if your selector was a star
  miriam: No, we're trying to return not a selector within a scope, but
          the scope
  TabAtkins: That sounds like a completely different thing
  miriam: Doesn't qSA return the tree of elements?
  fantasai: No, only the list of matched elements
  fremy: Are you trying to get something like get all the images inside
         a div but not inside a p
  TabAtkins: You can't do it with selectors reliably, you need upper
             and lower boundaries
  fremy: Yeah but your proposal takes an element, it should ideally
         take selectors right?
  TabAtkins: It should take a list of elements
  fantasai: Should accept a selector representing such elements
  emilio: I'm moderately sure qSA doesn't take a second argument
  TabAtkins: yes it does
  TabAtkins: but it's the this value
  <miriam> sorry for confusing it, yes - I'm on the same page now

  TabAtkins: Regardless of design discussions, question is is it ok to
             drop the scoping from selectors because we'll address the
             use case in some way by modifying querySelector?
  emilio: I think we should drop the selector syntax
  emilio: I'm pretty convinced you can achieve the scoping stuff with
          script right now
  emilio: even if it needs multiple querySelector calls
  emilio: but if we need to add a more convenient way to do that, we
          can do that
  emilio: but I don't think we should force scoping into selectors just
          for this use case
  <TabAtkins> Doing it in small amounts of code, correctly, is
              non-trivial.
  <TabAtkins> Need to make sure the forbidden ancestor is between the
              element and the root (upper boundary); if it's *above*
              the root it doesn't matter.
  fremy: The only thing would be performance
  fremy: you can filter in JS but you can create wrappers for lots of
         nodes
  emilio: If you use closest, you don't create [...]
  TabAtkins: You can't use closest, it's non-trivial to do in script
  emilio: but I'm sure we can figure out a convenient way to do this if
          we need it
  <zcorpan> https://dom.spec.whatwg.org/#dom-parentnode-queryselector

  TabAtkins: Proposal is removing scoping from selectors, opening an
             issue in DOM for adding scoping API to qSA

  RESOLVED: Remove scoping from selectors

Add ability to scope rules from an imported stylesheet
------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/7348

  miriam: Similar to layer() in @import
  miriam: and upcoming layer in <link>
  miriam: there's a proposal to add scoping to a sheet when it's scoped
  miriam: Proposal is to put the scoping condition in @scope
  miriam: and put it inside of a function
  miriam: so @import "url" scope(<root> to <lower>);
  miriam: we might want the same for html
  miriam: If you're only using scope you need double parens
  miriam: which is a bit ackward
  miriam: but proposal is to add the scope() function and maybe a
          shorthand for that awkward case

  emilio: This feels a bit more similar to @container or such, than
          @layer
  emilio: I feel it's a bit awkward. when would you want to scope a
          whole style sheet?
  miriam: This would be particularly useful for systems that are
          currently modular / separate style sheets per component
  miriam: we could take those separate sheets, apply a scope as
          importing them
  emilio: Could use shadow DOM
  miriam: Other way is to wrap it in a file
  emilio: Seems like a weird thing to have a shorthand for
  emilio: but if you say it's useful
  emilio: It feels weird in the sense it's depends on the DOM you're
          styling, rather than layer or media, where it's more about
          the style sheet itself and the environment

  miriam: I'll say people are going to do this. They have other methods
          to do it. I don't feel strongly we need this one, but it will
          keep coming up
  miriam: do we want to provide it as a shorthand?
  emilio: Should we encourage it?
  emilio: If you want this kind of scoping for your whole style sheet,
          you may just want to use shadow DOM and drop the style sheet
          there
  miriam: Scope is fairly different from shadow DOM
  miriam: You could make a fair argument that if the style sheet is
          meant to be scoped then it should be inside the style sheet
  ydaniv: It might not be your style sheet
  emilio: I get wanting to use the style sheet only when I'm printing,
          or to put it in this layer, but I want to scope this whole
          style sheet, since it depends on what selectors you're
          scoping it to

  chrishtr: Seems like it's the same as @scope
  chrishtr: it's just for a whole file
  chrishtr: that could be convenient
  chrishtr: If we accept the general usefulness of scoping, which I
            think it is, we should provide primitives to make that
            easier
  chrishtr: this seems like a natural extension to that
  emilio: You could make the same argument for container
  emilio: To me, @scope and @container are more similar than @scope and
          @media
  ydaniv: It's more like @layer
  emilio: Do you think so?
  emilio: @layer doesn't change whether something matches or not
  chrishtr: It's scoping to different subtrees
  emilio: Not objecting

  RESOLVED: Add scope() to @import syntax

Is it possible to account for proximity of sibling elements?
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7233

  miriam: Original request framed it as sibling scopes
  miriam: but when we dug they cared about proximity of siblings in the
          cascade
  miriam: We have this for descendants where proximity affects the
          weight in the cascade
  miriam: this wanted to account for siblings
  miriam: seems we could do something like that with different syntax
  TabAtkins: I don't know how we'd account for this in `@scope`
  TabAtkins: But the use case is great and the combinator syntax is
             great
  TabAtkins: doesn't matter which syntax

  zcorpan: Proposals are ~~ or ++
  <zcorpan> h1 ~~ p or h1 ++ p
  <ydaniv> +1 for snakes
  <tantek> +1 for snakes
  <tantek> since ++ already means something in other languages :)
  <fantasai> +1 tantek
  TabAtkins: I don't care about which one but we should make it work in
             @scope
  emilio: I argue for snakes
  emilio: Snake already involves all the siblings
  emilio: while plus doesn't
  emilio: so it feels more logical
  TabAtkins: Currently child one is based on child rather than
             descendant combo, so would be more consistent with +
  fantasai: I agree with tab that ++ is more analogous but I also
            prefer the snakes
  <TabAtkins> Hm, thinking using `to sibling` keyword in @scope would
              work
  miriam: Proposal is adding ~~ as a sibling combinator that prefers
          closer siblings
  emilio: After Tab's argument I prefer the pluses, but I don't mind
          either way

  RESOLVED: ~~ is a sibling combinator that prefers closer siblings

Add a :stylesheet selector to match the current stylesheet
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7349

  miriam: This is about stylesheets in the dom and scoping
  miriam: idea is to use `:stylesheet` / `:stylesheet-parent` to select
          stuff inside this scope
  miriam: that would allow you to scope the stylesheet
  miriam: most usecases prefer the stylesheet parent
  <fremy> huge +1

  fantasai: Is there any use case other than implementing
            <style scoped>?
  miriam: No
  fantasai: Then how about doing that?
  miriam: Problem is backwards compat
  miriam: if scope is not recognized it's applied unscoped
  fantasai: Can we use empty @scope rule for this?
  miriam: I like it
  miriam: we'd be setting aside being able to select the stylesheet's
          sibling

  heycam: 2 things, does @scope nest? What would it mean if you would
          use @scope without a selector, would it be sensible?
  emilio: It would have sensible behavior
  emilio: The rule wouldn't apply, you would apply both filters
  heycam: Second point is that there are stylesheets without nodes
          (constructable stylesheets)
  heycam: so we'd need to decide what the stylesheet does
  emilio: It could also do nothing. just not match.
  fremy: This is in @scope
  emilio: So it would always match

  emilio: is <style scoped> really not possible?
  emilio: layers have the same issue
  emilio: you use layers
  miriam: If we get the media attribute extended to support supports(),
          then the media attribute can fail, and stop the style sheet
          from being applied
  miriam: you could use that along with the new attribute
  miriam: That's the proposal for layers and scope attributes

  emilio: I don't think any engine keeps around the DOM node deep
          enough, it could be done
  miriam: It has a bit less flexibility than what Tab was suggesting,
          where you could still apply a lower boundary
  miriam: while letting the upper boundary be applied by the position
          of the style sheet
  miriam: since lower boundaries is a bit part of what scoping
          provides, that might be a reason to go with the change to the
          @scope rule
  emilio: If I had to choose between :stylesheet and @scope, I'd go for
          @scope
  chrishtr: For the bottom or the top of the scope?
  miriam: The top, if you use no selector it'd use the parent of the
          <style> / <style> element as the scope root
  fantasai: If your <link> is in your <head> it doesn't accomplish very
            much

  chrishtr: What about constructable stylesheets?
  heycam: You need to define it but I think it logically shouldn't
          scope to anything
  chrishtr: Could you add a `scope` property to the stylesheet to be
            able to scope a constructable stylesheet?
  heycam: Yeah that should be doable
  miriam: Do we want links in <head> to also style the whole doc?
  fantasai: I don't think you want to use their parent, it'd just end
            up not styling much of anything

  RESOLVED: @scope without selector scopes to the parent of the owner
            node, or the containing tree if there's no owner node

Inclusive vs exclusive lower boundary
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6577

  miriam: With the lower boundary selector as part of the scope,
          there's a question of whether they're part or not of the scope
  miriam: there's use cases for both, initially we spec'd as inclusive
  miriam: so lower boundaries are part of the scope
  miriam: exclusive allows to include explicitly with `> *`
  miriam: We want to add a keyword to `@scope`
  miriam: to say whether you want the boundaries included
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6577#issuecomment-1021035991

  TabAtkins: I'm fine with the keyword
  TabAtkins: but I think exclusive is better default
  TabAtkins: also it's trivial to turn exclusive into inclusive
  flackr: Tab covered what I was going to say
  flackr: exclusive is a little bit more ergonomic

  florian: Does `> *` work if there's no child?
  TabAtkins: If no element matches the lower bound nothing gets
             excluded which is what you want
  miriam: I guess main argument to have it a keyword is readability, is
          it clear?
  TabAtkins: I think it does what it says and says what it does
  TabAtkins: inclusive / exclusive ranges are a perennial source of
             confusion in every context
  fantasai: We can always add a keyword if we want to

  miriam: So proposal is make exclusive the default and add an example
          to the spec on how to do inclusive right?
  fantasai: Yes, is default for upper bound inclusive?
  <TabAtkins> they're both inclusive, the lower bound just includes
              elements in the forbid list ^_^
  miriam: Yeah, and no use cases for exclusive

  RESOLVED: Make exclusive lower boundaries the default and add an
            example to the spec on how to do inclusive

Priority of Scope Proximity in the Cascade
------------------------------------------

  miriam: Aside, I want people to look at how proximity affects cascade
          priority
  miriam: not to discuss today
  <miriam> https://github.com/w3c/csswg-drafts/issues/6790

<break>
Received on Tuesday, 25 October 2022 22:38:48 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC