- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 18:38:07 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS 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