- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Mar 2021 19:31:33 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS 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:
https://slides.oddbird.net/csswg/f2f2102/#slide-26
- 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
refined.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0009.html
Present:
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
Regrets:
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
apply.
alisonmaher: Does that sound good or are there other options to look
at?
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
color
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
sense
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
ereader
<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
behavior
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
container?
-------------------------------------------------------------
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
area
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
them
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`
rule
--------------------------------------------------------------------
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
implemented.
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
boundaries.
<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
specificity
<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
block?
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
priority
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
here.
<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
overkill
leaverou: Layers are supposed to contain entire library, not every
component
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
light.
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
wins
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()`
https://css-tricks.com/weekly-platform-news-focus-rings-donut-scope-ditching-em-units-and-global-privacy-control/#the-enhanced-css-not-selector-enables-donut-scope
<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:
https://github.com/w3ctag/design-reviews/issues/593#issuecomment-769351277
<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
all.
++ 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
components.
<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
thought.)
<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
important.
<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):
https://twitter.com/mirisuzanne/status/1351247559738621952
<TabAtkins> miriam: What selectors are you thinking of that require
:scope?
<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
least.
<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
work.
<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
boundaries.)
<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