W3C home > Mailing lists > Public > www-style@w3.org > March 2021

[CSSWG] Minutes Telecon 2021-03-10 [css-ruby] [css-color-adjust] [css-scroll-snap] [css-scoping]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 10 Mar 2021 19:31:33 -0500
Message-ID: <CADhPm3sC=jSqFojro9xJMGZF9kKnv6mtEO7g6mDz1LuT59_+qA@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 Ruby

  - RESOLVED: Publish updated WD
  - RESOLVED: Add this defined hiding behavior to spec and ping
              engines to implement it (Issue #5927:
              visibility:collapse on ruby annotations)

CSS Color Adjust

  - RESOLVED: Add accent-color to list of properties adjusted and have
              it adjusted to auto (Issue #5987: accent-color in Forced
              Colors Mode)

Scroll Snap

  - There's a need for real world examples and author feedback for
      issue #5911 (Scroll snap areas for fragmented boxes (like in
      css-multicol)). rachelandrew and fantasai will work together to
      create a blog post with examples to get author feedback.

CSS Scoping

  - miriam presented the proposal for light-dom scoping (Issue #5809:
      Proposal for light-dom scoping/namespacing with re-designed
      `@scope` rule) which is explained in this slide deck:
  - This approach creates a scope which is designed to prevent things
      from leaking out of the scope but allows the regular styles to
      go in.
  - There were a lot of different opinions as to if the proposed
      handling for prioritization was robust enough to handle author
      need or if its simplicity paired well with newer models such as
      layers to cover more needs.
  - The next step is for miriam to write up the proposal using more
      spec-like language and start creating separate issues for the
      concerns being raised so that this proposal can begin being


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0009.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Emilio Cobos Álvarez
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Dael Jackson
  Sankit Joshi
  Jonathan Kew
  Ian Kilpatrick
  Una Kravets
  Peter Linss
  Alison Maher
  Tess O'Connor
  François Remy
  Morgan Reschenberg
  Florian Rivoal
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Nicole Sullivan
  Miriam Suzanne
  Lea Verou

  Tantek Çelik
  Chris Lilley

Scribe: dael

  astearns: We can get going.
  astearns: We are going to skip items 2-4 on the agenda because chris
            can't make it today
  astearns: Any other changes people would like to make?

CSS Ruby review + republication

  Changes: https://drafts.csswg.org/css-ruby-1/#changes
  Details: https://lists.w3.org/Archives/Public/www-style/2021Mar/0007.html

  fantasai: Sent an email with summary of changes. We re-wrote layout
            section and incorporated resolutions. Also gave it a
            layout model for inter character Ruby. Based on layout you
            would get for an inline block with orthogonal writing
            mode. Some differences with alignment and sizing
  <fantasai> https://drafts.csswg.org/css-ruby-1/#inter-character-layout
  fantasai: That's all defined in ^
  fantasai: Defined interaction of ruby-align more closely. Lots of
            changes around alignment and positioning
  fantasai: Lots of open issues, but would like update WD with this to
            get wider review and snapshot progress
  florian: In terms of text it's changed a bit, but not radical. Based
           on resolutions, editorial re-writes, and disambiguation.
           Things to discuss, but not a radical change
  astearns: Proposal: Publish updated WD

  RESOLVED: Publish updated WD

  astearns: Please take a look.
  astearns: Will you ask for review outside WG?
  fantasai: Not quite yet. Lots of open issues. Will look and see if
            particular groups can look now

CSS Color Adjust

accent-color in Forced Colors Mode
  github: https://github.com/w3c/csswg-drafts/issues/5987

  alisonmaher: This is around adding accent-color to prop adjusted in
               forced color mode. Similar to scrollbar where force to
               auto. Question is what should happen with forced color
               adjust. Rest of control isn't adjustable. fremy makes
               sense, though. Should be honored but up to UA how to
  alisonmaher: Does that sound good or are there other options to look
  fantasai: If it's none we shouldn't force colors. Main question is
            do we force it to auto or do we allow it to be a system
  astearns: Other opinions?
  fantasai: I lean toward force to auto. Author doesn't know what
            system color will be and since trying to make page match
            colors user is comfortable with pushing to auto makes more

  astearns: fremy's comment in the issue seems to imply if adjustment
            is set to none other colors are reset?
  fremy: Not the case. If adjust is none we should not touch property.
         But maybe we don't need to do anything. UA isn't forced to do
         anything with it. Saying it does not really matter. We can
         switch to auto, but easier to impl that we do nothing
  fantasai: Could add a note UA could do that
  fremy: Yeah
  fantasai: Proposal would be add a note what UA can ignore accent
            color in forced colors mode where it wouldn't otherwise
  astearns: Add to the list but then say not really?
  fantasai: Property value would stay at what set at. UA if and how it
            uses an accent color...well...we do define if there is an
            accent color you have to change. So I think force to auto.
            This is used value time operation
  fantasai: We do require if you have something described as an accent
            color then the property does change it
  astearns: fremy you okay force to auto?
  fremy: Yeah. Doesn't matter since can't observe as a user. Whatever
         is easier
  <nicole> what would happen with say a black and white display on an
  <fantasai> nicole, that e-reader wouldn't have an accent-color, so
             accent-color would not have any effect
  <nicole> fantasai thanks, makes sense
  astearns: Proposal: Add accent color to list of properties adjusted
            and have it adjusted to auto
  alisonmaher: Sounds right
  astearns: Objections?

  RESOLVED: Add accent-color to list of properties adjusted and have
            it adjusted to auto

CSS Ruby

visibility:collapse on ruby annotations
  github: https://github.com/w3c/csswg-drafts/issues/5927

  florian: When you have ruby and base is identical to annotation we
           have auto-hiding behavior. This needs to be impl
  florian: What's not nice is it's only auto-applied. No way to
           manually invoke that hiding behavior. Only auto
  florian: There are use cases to do it
  florian: Since we have behavior, use cases, and syntax that would
           match to the behavior- proposal is map the syntax to the
  astearns: I brought up if this can interact with real world markup,
            but I'm not that concerned. Happy to go with the proposal
  astearns: Other opinions?
  astearns: We could resolve to spec this up and see how it goes
  florian: Spec is easy. Behavior is specified, just need to say this
           syntax matches the behavior
  <fremy> I really like that the behavior in a browser that does not
          implement this is decently good
  <fremy> So
  <fremy> I don't see harm in adding this, worst case we remove later
  fantasai: It gives you control over the hiding. You can hide things
            that wouldn't be auto-hidden
  astearns: Any idea if any engine is interested in impl this?
  fantasai: Seems like easy to do in FF because they already impl
            auto-hiding. Wouldn't require a lot to make it work
  florian: And we're not at CR yet. If we were close maybe, but at
           that point I don't think it's worth adding that noise
  astearns: Worth adding bugs to systems to please try to impl?
  florian: Sure
  astearns: Proposal: Add this defined hiding behavior to spec and
            ping engines to impl it

  RESOLVED: Add this defined hiding behavior to spec and ping engines
            to impl it

CSS Align

What is supposed to happen to abspos in an end-aligned scroll
  github: https://github.com/w3c/csswg-drafts/issues/4957

  iank: I think we didn't have information previously. Perhaps we
        forgot to agenda- it
  fantasai: This needs more discussion in GH. It is one of the main
            open issues against alignment spec. Which model do we want
            for handling alignment in a scroll container
  astearns: Been 20 days since comment on this issue, maybe because
            waiting on it on the call. Can one of you summarize what's
            left to do on this issue on GH?
  fantasai: Yeah, TabAtkins and I can
  astearns: We'll discuss more in the issue

Scroll Snap

Scroll snap areas for fragmented boxes (like in css-multicol)
  github: https://github.com/w3c/csswg-drafts/issues/5911

  fantasai: Basically this is a question of how do we want to address
            it. We didn't specify handling for fragmented boxes.
            Basically 2 concepts. Draw a bounding box around all
            fragments and snap or each fragment is independent snap
  fantasai: When they line up nicely it works fine. But a box split
            across multiple columns and half is the bottom of a column
            and half is the top, how do you handle? Snap to the middle
            might not see well.
  fantasai: I don't have a good answer. Wanted to ask the WG

  florian: For multicol specifically drawing a big box could work.
           Fragmentation in general it wouldn't. Scroll and paginate
           could exist in the same device. If that's the case pieces
           might be on different canvases.
  fantasai: If on separate pages you have to snap within page. No
            other possible interpretation. Multiple fragments on same
            page, how to handle?
  fantasai: Scroll snap does apply to inline boxes. That's a case
            where snap to bounding box makes sense. For block may be
            snap to each fragment makes sense
  astearns: Other ideas?
  astearns: Looks like we have 2 behaviors implemented and we're not
            sure either is what we want to spec

  smfr: Examples of pages that show different behavior? Any real world
        ones? Basically, does it matter?
  fantasai: Yeah. Let's say I have phrases with an ID; terms and
            definitions. It wraps 2 lines. When you click on a link to
            the definition, where do we snap? If we ask to center it.
  florian: In spec we don't turn on snapping for these things. What
           would be a document where we would turn on snapping? If we
           know why it's on might be able to reason what's preferable
  Rossen: Instead of trying to come up with examples here, I think
          this needs to go back to GH. I think it's a good prompt to
          add real world motivating examples

  smfr: My suggestion would be to ask if anyone objects to bounding
        box solution
  TabAtkins: In particular if FF objects because that's a change for
  fantasai: I will note the original person who raised issue was
            looking for per fragment
  TabAtkins: They wanted to snap to columns
  fantasai: Yes, particular use case can be done in other ways
  TabAtkins: Because they're asking for something different we
             shouldn't worry about satisfying their case
  fantasai: I think it would be good to get author feedback
  astearns: One way of getting feedback is specify bounding box and
            ask for examples of how we're getting it wrong
  fantasai: We have both implementation so they can compare. We need
            people to pay attention
  Rossen: Will bounding box be compat with multicol?
  fantasai: If you ask for center snap position you snap to center of
            all columns the element belongs to. Not sure if that's
            what you wanted
  <Rossen> sounds like we're trying to force a resolution to force
           further discussion?

  florian: Earlier point that for inlines bounding box is good but
           block it might not makes sense. Multicol is one example.
           The further apart the pieces can be the less sense it makes
           for bounding box. Okay to say inline is bounding box, else
           per fragment?
  jfkthame: Even inline element could run cross fragments in a
            multicol, couldn't it?
  florian: Yeah. Double fragmented

  iank: I was going to ask same question fantasai asked, what do
        webdev expect here
  fantasai: We should try and reach out to dev community. Maybe
            jensimmons or rachelandrew
  rachelandrew: If we ask webdev might get confused with the snap to
                column boxes. Trying to think how to separate
  fantasai: Need a diagram. One of a multicol with a hot pink box
            starting near the bottom of the first column or something
  rachelandrew: Happy to have a go at writing a blog post. Need to
                make sure we're getting feedback for the thing we want
  fantasai: How about you and I work on that?
  rachelandrew: Sure
  astearns: Alright, I'll take the tag off this and we'll get feedback

CSS Scoping

Proposal for light-dom scoping/namespacing with re-designed `@scope`
  github: https://github.com/w3c/csswg-drafts/issues/5809

  miriam: I have slides, but perhaps I should talk through without?
  <miriam> https://slides.oddbird.net/csswg/f2f2102/#slide-26
  miriam: Link ^
  [trying to see if miriam can present]
  miriam: I'll talk through them without displaying.

  miriam: There has been several threads open about having a scoping
          in CSS
  miriam: There was even attempt in 2014 to specify it. It was not
  miriam: Looking into it I found differences with shadow dom.
          Proposal is what is see is missing from shadow dom.
  miriam: Main goals are avoiding naming conflicts and expressing
          membership in a scope. Similar to what shadow dom does which
          gives us scope and slots. Different from ancestor because
          lower boundaries. It actually belongs to the component
  miriam: A lot of tools out there try and do this manually. Putting
          together special selectors
  miriam: Other part is trying to capture sense of proximity. A light
          and dark theme and I need to style links in those. If I use
          descendant selector the second definition take precedence
          when selected. What I want is the one that is closer.
  <fantasai> [slide 32]
  <fantasai> [slide 33]
  miriam: Why not shadow dom? Basic answer is shadow dom encapsulation
          is high impact and dom centered. Element itself is the scope
          and that's hard boundaries in the dom. Strong isolation of
  <fantasai> [slide 34]
  miriam: High power in the cascade as well. It overrides specificities
  <fantasai> [slide 35]
  miriam: Interesting proposals to improve, but don't resolve central
          issues. I think declarative shadow dom is interesting. But
          not the same thing as we're trying to solve with views etc.
  miriam: I sometimes want lower bounds, outer bounds. But I want to
          do that and it's a presentational decision, not semantic. I
          don't want it tied to dom elements. I want overlap. I want
          to say what's in or out
  <fantasai> [slide 38]
  miriam: All these tools do it lower impact. It's reused across
          elements. Priority is handled through ownership rather then
  <fantasai> [slide 40]
  <fantasai> [slide 41]

  <miriam> https://www.irccloud.com/pastebin/MtGSIIPT/
  miriam: Proposal bringing back scope rule and scope pseudo class.
          Proposal is a syntax like ^
  miriam: We get @scope and add a selector for outer bounds.
          Optionally add a to() with any number of lower boundaries.
          Anything within the rule would scope between selectors
  miriam: Scope selector is the root. It's implied when not used
  <fantasai> [slide 42]
  <fantasai> [slide 43]
  miriam: I have more details about exactly how I see boundary and
          selector matching working. Gone through TAG review on how it
          would work. Final piece is this triggers proximity as part
          of cascade. When 2 scopes overlap inner scope is the
          fallback to specificity. When they're equal internal scope
          takes precedence.
  miriam: Some talk about being able to scope to a donut. Idea from
          leaverou. Is it useful to have it as a selector in it's own
          right. Interesting and could look more

  TabAtkins: I'm very happy to see this. Was happy to work with miriam
             early on. We tried to do light dom scoping earlier but
             that was substantially different. It was trying to
             interact similar level of intrusiveness as shadow dom
  TabAtkins: This being a low thing is a really great and useful tool
             that compliments shadow dom and what we're doing. I'm a
             big fan of it

  leaverou: I would like to agree with TabAtkins this is highly
            needed. I support it
  leaverou: Elaborating on my point that miriam mentioned, I think
            proposal consists of 2 parts. Name spacing use cases which
            are nesting within this new scope rule and the proximity
            prioritization. And then there's the donut scope syntax.
            Anything related to selection logic is better in
            selectors. That gives it a JS API which gives you access
            to frequently needed queries
  leaverou: Worth exploring how the donut scope could be done through
            selectors syntax so @scoping can just have the scoping and
            not the selection
  leaverou: Does that make sense?
  fantasai: You're proposing selector in addition to @scope where
            selector is a limit on what's selected, but doesn't affect
            the cascade?
  leaverou: Yes
  <argyle> like `@scope .tabs - .panel {}` like this? where the dash
           is showing a range?
  fremy: Makes a lot of sense to me
  florian: Seems worth exploring. Since interested in both parts, I'd
           like to first express support for the whole thing. We'll
           take everything here and then as we take this possibly try
           to do donut in selectors on top. Don't insist on the donut
           thing to take this
  leaverou: Both problems need solving
  <TabAtkins> Hm, I'm not sure how we would work a lower-boundary into
              the normal selector syntax

  fantasai: Question I have is, I want to understand impact on
            specificity. Previous @scope proposal which didn't have
            lower bound. Other difference is specificity, if you have
            more specific selector outside it overrides in the scope.
            In previous proposal if you're inside a scope it overrides
            everything outside.
  miriam: That's right
  <TabAtkins> Currently, @scope basically *is* just a selector
              (allowing nesting)
  fantasai: Can you explain the reasoning behind why this is the
            appropriate choice?
  miriam: One thing, going back a ways as I teach CSS people expect
          this to be the default fallback. People are surprised by
          source order being the fallback. That was in my mind
  miriam: Also this is how all the tools currently work. Feels like it
          works well to me. Not trying to isolate strongly, trying to
          keep things from getting out, not from getting in
  miriam: Tools do it with an added attribute now, but that only
          increases spec by a small amount
  fantasai: This has less impact. Concerned it would cause...not give
            same results in a lot of cases. Not convinced. When you
            add a class, you'd have to add more specificity.
  <leaverou> +1 to fantasai's concerns. If it can be overridden by
             rules outside the scope, it becomes very similar to
             nesting which we know doesn't solve these problems
  miriam: Except that the proposal has the scope root selector being
          added to all selector in scope so it's same as single
          attribute in most cases, but could be more powerful. Set
          root selector to ID you're adding the id to selector to
          everything inside. Can create higher weight but you have
          more control. Only proximity part is lower
  fantasai: Spec of selector in @scope condition is added to all
            selectors within scoped block
  miriam: Right
  fantasai: That wasn't clear. I don't think that's a good design. The
            way you select element you want to be scoped shouldn't
            have effect on how specific selector in scope are. If you
            switch class to ID it can completely destroy relationship
            between selectors.
  fantasai: Where this fits in cascade I'm interested to think about.
            I don't think choice of selector in @scope should have
            effect on cascade
  TabAtkins: What I like about miriam's design is it is virtually
             identical to specificity landscape, including with
             nesting. That means that it's as familiar as specificity
             in existing css including the scope inheriting into
             nested selectors
  TabAtkins: You can override it with no specificity selector. That
             would achieve same effect without specificity. By default
             you get today's behavior. That has problems, of course,
             but because we're in today's model anything we do in the
             future doesn't have more to worry about. It's the
             existing model and will inter-operate

  florian: I don't have a strong view on issue we've been discussion,
           but not that concerned. Compared to last time we tried this
           it's easier because less problems. We have cascade layers
           and shadow dom. As miriam pointed out main goal is prevent
           styles from leaking out. We need to resolve conflicts, but
           primary goal is leaking out
  florian: If you want strong isolation maybe you should use shadow
           dom. If you want to make sure you win you have cascade
           layers. We need to solve the discussion, but unlike last
           time since we're not trying to solve all the problems it
           doesn't concern me as much
  <TabAtkins> Yup, recognizing that we're already solving the "figure
              out which large set of styles wins" in other ways means
              we can focus this one on the much simpler problem of
              "lower bound protection" (and, for giggles, letting us
              give a weak notion of proximity to specificity).

  fantasai: I have strong reservations about the proposal
  astearns: Are they about the specificity for the rules inside the
  fantasai: Basically, everything except syntax. Where it fits into
            cascade. Feel strongly spec of root selector should not be
            a factor in cascade. Not convinced way defined to interact
            with specificity is what we want. Possible it is and I
            don't understand use cases, but based on what I know, I
            don't think this is right.
  <TabAtkins> Contra fantasai, I feel *strongly* that the root
              selector needs to be figured into the nested styles,
              because otherwise the selectors will *often* be too
              weak. Keeping those selectors weak *when they would
              auto-win anyway* (as our earlier @scope attempt did) is
              fine, but if we're working within the standard \
              specificity wars, letting the container's selector add
              in is necessary.

  nicole: Speaking to use in design systems. You would end up with
          simple selector in root selector
  nicole: I would have expected that as a part of specificity because
          how nesting works in sass
  nicole: Case on more complex selector in root would be more rare. I
          would expect they want something specific and fremy said
          that would be better achieved with layers. The interaction
          of the 2 makes sense

  leaverou: Separate nesting spec that's supposed to do same as
            nesting in sass. If they do similar things with slight
            differences it will be confusing. I agree with some of
            fantasai's concerns. We know nesting doesn't solve scoping
            use cases. If things outside scope can leak in worried it
            won't address cases
  fantasai: I think you want things to leak in, but leak in at a lower
  leaverou: That's what I meant
  fantasai: Proposal here fusses with specificity and scoping is a
            fallback. Previous scoping said it was higher than
            specificity so inner scope would win if there and outer
            would take effect. Shadow dom the outer scope wins.
  fantasai: Both cases are different. Question is how does scoping
            interact with specificity
  TabAtkins: We're solving problem of how to worry about larger scale
             conflicts with layers so we don't have to care as much
  <fremy> I agree with TabAtkins here
  fantasai: I think layers helps a lot, but not quite the same. But
            yeah, can create a layer for every component. Seems
  leaverou: Layers are supposed to contain entire library, not every
  TabAtkins: I don't think you'll be worrying at that level
  fantasai: Example: I have a sidebar in my page and want it to have a
            different color. Inverse contrast color. I have rules
            setting link color heading color etc. Need to override
            them all in my sidebar. I override the link and say it's
  fantasai: Overall outer page has slightly different colors for links
            in a list. Because that's higher specificity it overrides
            the sidebar.
  fantasai: So it doesn't solve the scoping problem because specificity
  TabAtkins: You're right it does not solve. You solve it using
             standard specificity mechanisms or if this is a page
             specific modification that's what layers is designed to
             do. Let you separate general styles from specific styles
             that need to win at all costs. We've solved that
  fantasai: It's not necessarily page specific. It could be for my
            whole site
  florian: What's wrong with a layer
  fantasai: Rest of page could have layers and now they're sibling
            layers, and ordering matters. It's not about the loading,
            it's about am I in a sidebar because if I am they need to
            be more important. That's hierarchy, not which stylesheet
  TabAtkins: I don't agree entirely. In some cases yes, but in many
             cases it's not. Complexifying this by adding another
             strong kind of scoping will add a ton of complications.
             Solving in this weak way that melds cleanly and goes with
             the general approach is better

  <argyle> Sime Vidas showing donut scoping with complex `:not()`
  <leaverou> argyle: I've made this point too, but this fails with
             nested structures
  <leaverou> argyle: I've written more about how it fails with nested
             structures here:
  <TabAtkins> leaverou, argyle: Yeah, current selectors are definitely
              just too weak to handle lower bounds.

  astearns: miriam I think you should take the strong opinions as
            encouragement. That everyone is digging in and has strong
            opinions and expressing concerns is an indication we
            should continue work.
  astearns: I don't think we'll be able to resolve to officially work
            on this right now, but I think we can get there
  miriam: Yes, and I was expecting this to be contentious because
          there are use cases all along the spectrum. That's been a
          challenge with scope. I went weak intentionally. There are
          strong pieces out there so I thought I'd go the other
          direction to balance out the use cases.
  astearns: I think that's all the time we can give to this today
  astearns: I don't know how much time you can spend on this miriam
            but feel free to create something in spec form and make
            separate issues for the separate concerns.

  astearns: We're done for the day and we'll talk next week. Thanks

++ After call chat ++

  <fantasai> TabAtkins, this is adding something that's "almost the
             same as nesting but not quite in small ways", as Lea
             noted. That's more confusing than adding strong scoping
             that works the opposite of shadow DOM.
  <TabAtkins> I actually didn't understand that - leaverou, how is it
              not like Nesting? The sole difference from nesting (
              modulo some syntax concerns that I still need to raise)
              is that scoping adds the weak "proximity" layer between
              specificity and source order.
  <nicole> It seems like we might need to back up and decide which
           use-cases this particular feature is trying to solve
  <fantasai> +1 nicole
  <nicole> But that said, I see it as similar to nesting syntactically
           but the donut is a key part that is different. For design
           systems, you don't want component styles to flow into child
  <TabAtkins> But otherwise, `@scope (.foo) { .bar { color: red; } }`
              and `.foo { & .bar { color: red; } }` are identical in
              every way.
  <TabAtkins> (The syntax issue is just that I'm still not 100% sure
              we don't want to make indicating the scoping element
              mandatory, exactly like nesting, and whether or not we
              want to just use Nesting *directly* and have the &
              selector work there.)
  <nicole> Yeah @tabatkins I wondered the same thing, but thought
           there are use-cases for nesting that are about code
           organization where you wouldn't really want scope.
  <TabAtkins> (But I'm not sure about either of those issues, and the
              current spec might be okay, just need to give it more
  <TabAtkins> nicole: Right, I wasn't suggesting dropping @scope and
              just having Nesting auto-apply scoping, I just meant
              spelling it like `@scope (.foo) { & .bar { ... } }`
  <nicole> ahhh
  <nicole> gotcha
  <miriam> `&` refers to an entire selector list, where `:scope`
           refers to the specific element that is one instance of a
           selector-match. I think that distinction might end up being
  <TabAtkins> Right, that's the issue that I need put more thought
              into to decide whether it's important or not. It's a
              muddle in my head currently.
  <TabAtkins> Ah right, yes, okay, so like `.foo { & > & { ...} }` is
              valid and meaningful currently, but `@scope (.foo) {
              :scope > :scope { ... } }` isn't, that's the big
              difference driving it.
  <miriam> right
  <TabAtkins> Okay so I think I'm fine with continuing to spell it
              :scope, I'm just still left on whether we want to
              *require* the :scope or rely on the absolutizing rules
              <https://drafts.csswg.org/selectors/#absolutizing> to
              fill it in when it's missing
  <nicole> ooh, that spec is breaking my brain a bit. Gotta read it
           more throughly.
  <TabAtkins> Requiring the :scope (or rather, just not filling it in
              automatically) does mean you can avoid adding in the
              container's specificity when you don't want it. You'll
              still get scoped (the @scope rule still filters the
              results of any contained selectors), you just won't get
              magic specificity added.
  <TabAtkins> So like `@scope (#foo) { .bar { /* 0,1,0 */ } }`, but
              `@scope (#foo) { :scope .bar { /* 1,1,0 */ } }` would
              select the exact same elements but with (hopefully) more
              obvious specificity
  <miriam> oh, that's an interesting take. Does it make sense that the
           certain selectors which would require `:scope` (any
           relating to external context) should always get the added
           specificity of `:scope` while some selectors can avoid it?
           I'm not totally convinced.
  <miriam> Regarding relationship to specificity, I did also talk to a
           number of authors, and ran a twitter poll (for whatever
           that's worth):
  <TabAtkins> miriam: What selectors are you thinking of that require
  <TabAtkins> (Not saying they don't exist, just making sure I"m
              thinking of the same thigns you are)
  <miriam> Any that want to reference external context, where `:scope`
           is no longer the "front" of the selector: `@scope
           (.dark-mode) { .sidebar :scope a { ... } }`
  <TabAtkins> Okay, cool. You can use `.sidebar :where(:scope) a
              {...}` if you don't need the container's specificity, at
  <miriam> That's true
  <TabAtkins> I lean towards the idea that specificity being
              *predictable* from looking at the selector is a little
              better for authors than trying to keep the specificity
              *consistent* in ways that might be slightly magical.
  <miriam> I did also consider `:scope` always having the specificity
           of a pseudo-selector. Which would match exactly to current
           tooling that uses generated-attributes
  <TabAtkins> That breaks further from Nesting and current CSS that
              just writes out the selectors entirely, so I'd be
              lightly against that. ^_^
  <miriam> Yeah, in conversations, that seemed a bit less expected to
           people than the nesting approach
  <TabAtkins> fantasai: Check the above poll from Miriam tho - the
              strong Nesting we worked on before prevents the outside
              page from *ever* overriding a scoped declaration (it
              would need to use another scoped block anchored at the
              same or descendant element). Having it just slot into
              existing specificity lets you poke thru the membrane
              when you want to, and all the other controls we have for
              adding stronger protection (layers, shadow DOM) still
  <miriam> Exactly - my feeling was that this approach gives me much
           more control as an author to set the boundary where I want
           it with existing specificity. If scope is more powerful, I
           have very few options to penetrate from the global scope.
  <miriam> And in the use-cases I looked at, it seemed to me that use
           cases (like light-mode/dark-mode) which rely on proximity
           _also_ have matching specificity.
  <miriam> (Worth noting that the existing tools have _no_ proximity
           rules, but authors achieve the same impact by adding lower
  <TabAtkins> Notably Shadow DOM's behavior preserves the "outer page
              can poke in when it feels it's important", for exactly
              this reason. Previous @scope behavior was at least
              partially because, lacking a lower bound, we needed
              strong proximity to give better behavior for sub-scopes.
Received on Thursday, 11 March 2021 00:32:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 11 March 2021 00:32:16 UTC