- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Apr 2019 19:07:22 -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.
=========================================
Shadow Parts
------------
- RESOLVED: Add such a note -- no exposing parts of form controls
without standardization (Issue #3674: Make clear that
Shadow Parts for built-in elements should not be
supported without standardization)
CSS Contain
-----------
- RESOLVED: Remove style containment from keywords that aren't
'style' (Issue #3280: contain: style doesn't seem very
useful)
- RESOLVED: Mark 'style' at risk (Issue #3280: contain: style
doesn't seem very useful)
- RESOLVED: Republish CR of css-contain once edits are in (Issue
#3280: contain: style doesn't seem very useful)
CSS Scoping
-----------
- Usage data will be gathered for :host-context. If the counter
reveals low/no usage it will be dropped. (Issue #1915:
Specificity of :host, ::slotted, and :host-context doesn't seem
to be defined?)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sf-2019
Scribe: fantasai
Shadow Parts
============
Standardization of Shadow Parts for built-in elements
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3674
heycam: This is a small request, we had a request internally to make
it clear that the ::part() pseudo-element is not a kind of
free-for-all extension point for engines to expose parts of
built-in form control elements
heycam: There was some concern in the past that engines were happy
to expose parts of form controls through pseudo-elements,
and of course that's a big compat problem for us, maybe
others
heycam: We don't want to repeat with env(), which also takes an
ident, and we ended up with things being implemented that we
then had to implement and then spec afterwards, which is the
reverse of the standards process.
heycam: I like that the spec doesn't talk about built-in file
controls
heycam: But it's an attractive bit of syntax for exposing this
stuff, so we'd appreciate a note in the spec that this isn't
to be used to expose parts of standard form controls until
we go through the normal standards process
<florian> I fully agree with heycam
TabAtkins: I accept the change on behalf of fergal
heycam: Unless ppl have plans to start exposing things through
::part()...?
<tantek> +1
AmeliaBR: Questions from authoring side. One of big complaints with
all of the custom pseudo-elements was that it messed up
your selector and you had to have separate rules for every
browser
AmeliaBR: Is the invalidity rule such that ::part() is always valid
regardless of arg?
TabAtkins: As long as syntax matches what's syntactically allowed
it's valid
AmeliaBR: So if someone wanted to test out a prefixed part, it'll be
a nicer flow for authors to build on
AmeliaBR: Agree that ppl shouldn't ship experimental things until
there's a standardization discussion
AmeliaBR: In some cases maybe we'll say, your datepicker is so
specialized that you should have a prefixed part?
TabAtkins: Yeah, fine to do, because syntax space is wide open
RESOLVED: Add such a note -- no exposing parts of form controls
without standardization
CSS Contain
===========
contain: style doesn't seem very useful
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3280
emilio: Very confused what use case contain: style is supposed to
solve.
emilio: It's hard to implement. Very broken in the only
implementation that's shipping.
emilio: I can't see any potential advantage except *maybe* update
counters faster in the page?
emilio: But that's usually not a perf issue.
TabAtkins: My answer in the issue was that the 'contain' properties
in general are to help isolate parts of your document
TabAtkins: perf wins are a benefit, especially layout
TabAtkins: But also helps you isolate parts of your document to make
it easier to think about
TabAtkins: It covered the remaining thing that would leak out of a
component
TabAtkins: Was a completion exercise in making an isolated component
emilio: Did we decide how counters work in CSS? Are they off DOM
tree or flat tree?
TabAtkins: CSS works on flat tree as its "element tree"
TabAtkins: So counters are defined to work on flat tree
TabAtkins:...
emilio: Tests?
TabAtkins: Had some in past, lost them. Before wpt
TabAtkins: Might pick up again when working on Lists
dbaron: Counters are part of generated content, thus box tree
TabAtkins: Mental model is that everything is elements, then we turn
things into boxes, then we turn things into fragments
fantasai: If we had counters working on the not flat tree, then I
don't know that list numbering would make much sense, if
part of your component was reordering items in a list
fantasai: so I think they do need to work on the flat tree
TabAtkins: If you take an ol, give it a shadow tree, rearrange
items, numbering should reflect final display, not
original ol.
fantasai: Right.
<dbaron> At the time we implemented ::before and ::after as part of
the box tree, the specs were still pushing towards allowing
multiple CSS presentations of a single document.
futhark: I agree with emilio that there is not much to do with
optimization for contain: style
futhark: One useful thing would be if we said that inheritance
doesn't happen from 'contain: style' down
futhark: Then we can optimize for ?
futhark: If 'contain: style' meant that 'all: initial', then we
could optimize getComputedStyle
futhark: Then it wouldn't rely on layout (???)
futhark: Then can do display locking
emilio: ...
TabAtkins: Contain property doesn't block things going into the
subtree. It blocks things leaking out.
florian: It's the contain property, not the isolate property
TabAtkins: If it ends up being that we don't want to implement
'contain: style' across browsers, we can drop it. It
just, it's part of my vision for what 'contain' was
about. Last piece necessary to create a seal around the
subtree
TabAtkins: There's also a bunch of parts of CSS where we have global
names etc.
TabAtkins: Maybe we just rely on shadow DOM.
florian: Wanted to ask rego's pov, since he fixed a lot of bugs on
'contain: style'
<rego> there are a few bugs
https://github.com/w3c/csswg-drafts/issues/3280#issuecomment-452580469
Rossen: So what's your ask, Emilio?
emilio: It's very broken to the point that 'contain: style' toggling
doesn't do anything dynamically
emilio: Implementing it in Gecko is really hard, and I'd rather not
ship something that's broken.
emilio: My ask is drop it.
Rossen: So proposal here is to drop 'contain: style' from css-contain
AmeliaBR: Is there any reason this couldn't be added back later, if
it turns out to be useful?
florian: Yes and no. It's easy to add stuff. But there's 'contain:
strict' which is all of the contains. If we add a new one,
then it wouldn't just be an addition but a change.
florian: So we'd have to add a new keyword for all of the contains
that includes the new type of containment
chrishtr: If property changes on an element on 'contain: style', and
we don't have 'contain: style', is it possible to dirty
something else?
TabAtkins: Counters and quote property
emilio: The computed style doesn't change.
emilio: The counter values are not stored in computed styles
chrishtr: Does contain: layout say that counters...?
emilio: Style is a bit of misnomer
chrishtr: Regardless of name, need to have this functionality to
have complete perf
emilio: My point is that changing counters is not something that is
typically a perf bottleneck. Not like changing height, which
has lots of effects throughout the doc
emilio: Not something I've seen in a perf profile at all
chrishtr: But if you want to do things like async rendering or
display locking
chrishtr: You'd need this, just in case the content changed a counter
chrishtr: Whether it should be its own thing, idk
emilio: It's not something that happens frequently. It can have a
layout effect across the page.
chrishtr: But unless you lock it, has an effect
emilio: It's same as changing content property
florian: But that doesn't affect outside the element
emilio: ... counter-reset can change stuff across document
chrishtr: Point of containment is that you can reason about the
relationship of work between stuff in the contained
subtree vs rest of document
chrishtr: It's small but a real footgun?
emilio: That's fair, but we still don't have a great model for
counters
emilio: Makes it seem like counters work in the style tree.
emilio: Which isn't true
emilio: We need tests for like shadow DOM, need tests for display:
contents, for all these edge cases which change how counters
are affected by style containment
chrishtr: Agree we need tests
emilio: and a proper spec
dbaron: We had an interim agreement to add 'counter-set'
dbaron: we never added
TabAtkins: It's in a spec, it's in Lists
TabAtkins: Just never past WD
emilio: ... spec, not in implementations
emilio: Even in Blink, renumbering lists
emilio: If element is display: contents; contain: strict; if you add
a list item inside of it?
emilio: You have a <ol><div style="contain: strict"><li></div></ol>
emilio: Right now if you change the div's display, it is buggy
TabAtkins: Our entire counters implementation has issues
eae: Spec is correct, but our impl is incorrect
emilio: Given state of impls, implementing 'contain: style' is not
worth it
TabAtkins: Fact that built-in lists might be magical is a separate
issues
emilio: If lists are magical, then we have another leak
dbaron: We have a patch to Gecko to use counters for lists, so might
fix that
chrishtr: Sounds like all the browsers are sad, and I think we agree
that there is a real footgun even if a small one
* fantasai would not describe this as a "footgun"
chrishtr: So I think we should add proper tests and fix things to
not be sad
chrishtr: Then if that's the case, come back to you about this.
dholbert: Sounds like use case is lazily rendering the subtree
dholbert: If counters and quotes are the only things that would have
an effect, maybe implementations can just add checks for
those properties
dholbert: They're quite rarely used
dholbert: Might be easier to just disable perf optimizations in
cases where they're used rather than implementing
'contain: style'
futhark: I think Chris you had some thoughts... I'm confused about
isolation vs containment
futhark: For perf, you probably want isolation
futhark: If you modify DOM outside something that's contained
futhark: It can affect sibling selectors that affect the contained
subtree
emilio: Which can set 'contain'
TabAtkins: Nothing about contain is about isolation
TabAtkins: You can't have layout isolation
TabAtkins: You can't use percentage or auto or anything. It has to
be 100% manually-specified or nothing.
TabAtkins: You have a subtree that you can ignore when changes
happen inside it. That's the use case we're designing for
chrishtr: Points about % sizing and isolation vs something else is a
complicated subject, and the more you go towards one end
the more you lose use cases or perf
chrishtr: Needs investigation
chrishtr: Not only is 'contain: style' poorly implemented, the other
contain modes while implemented correctly don't actually
improve perf
* cbiesinger notes that some of the other contain modes do help with
performance under some circumstances
* cbiesinger (in blink)
emilio: Even though containment is designed to ignore a subtree, you
can still have e.g. :empty { contain: strict } and that
div's contained but you insert a child in that div, and you
are no longer contained
emilio: Contain can be dependent on DOM contents of an element
emilio: There are selectors already that depend on contents of the
element
chrishtr: ...
TabAtkins: You cannot have selectors that depend on style
TabAtkins: Filing an issue won't solve it.
TabAtkins: We can't do that.
florian: Mentioned about testing and things, at the moment we have
reasonably extensive testing of normal counters
florian: If lists are fake counters, that's not tested separately
florian: I couldn't find tests for shadow DOM and display: contents
florian: But for normal counters, should be well-covered
TabAtkins: Given large number of inconsistencies in lists from when
I was testing them awhile back....
florian: Checking for what it's supposed to do to counters.
florian: If you toggle contain on/off, we don't have tests for that.
florian: But effect of contain on counters, we do have tests
TabAtkins: Thanks for test suites
florian: Thank gtalbot
Rossen: Hearing pushback from Mozilla
Rossen: Not hearing much from other vendors
Rossen: What do we want to do next?
fantasai: Rename it, obviously.
Rossen: Or we can drop it
emilio: Can we drop contain: style and if we decide it's a thing we
want
TabAtkins: Drop style now, figure it out later, decide what to do
about 'strict' and whether to make it stricter or add a
stricter value?
fantasai: Might be able to slip it into strict later, because content
is unlikely to be dependent on leaking counters/quotes
TabAtkins: Quotes definitely rare. Unsure about counters.
emilio: ...
Rossen: We could try dropping style now, and see if counters surface
as a prominent use case, then deal with it
TabAtkins: What do you think, Chris?
chrishtr: Drop it from the spec, but leave it implemented in one
browser?
TabAtkins: No, that'd be a spec violation
gregwhitworth: It's implemented and shipping in a browser, but it
doesn't work
TabAtkins: It does for real counters, if you have no dynamic changes
hober: It's up to them what they ship in their browser. It's up to
us what we have in the spec.
Rossen: So would there be an objection to dropping 'contain: style'?
emilio: My point for dropping it now is that it's the same kind of
risky change to change Blink's lists to use real counters as
it would be to drop 'style' / implement later
emilio: The case of having 'contain: style' that spans across a list
emilio: or counters inside a 'contain: style' subtree
emilio: Until Lists work that way, you're going to break something
TabAtkins: If our counter impl is already broken and weird, so it
probably doesn't matter if we leave the code in?
chrishtr: What would likely happen is that we wouldn't remove the
feature, we'd fix it
chrishtr: I'd rather fix it in Chrome and work through the spec
issues than drop it
chrishtr: What we do with the spec in the meantime
eae: It's something we really want to do in Blink, and we do realize
that the current state of thing where e.g. Lists don't work
that way
eae: So it might make sense to drop it for now
florian: If we drop now and add back later gets us to strict +
stricter
florian: I'm not bikeshedding the stricter
* fantasai still thinks making strict stricter would be unnoticeable
emilio: We also want to ship containment
emilio: But we really don't want to implement 'contain: style' under
the current state of affairs
emilio: Given it needs more work in specs and implementations
emilio: It would make sense not to block shipping containment on
'contain: style'
chrishtr: Was there a compat issue?
emilio: No, but we don't want to willfully violate the spec.
emilio: We don't want to parse a value and then not implement it
TabAtkins: Is it just about built-in lists or all counters?
emilio: It's generally hard to implement in our counters
implementation
TabAtkins: I'm wondering how difficult it is from doing a
counter-reset on all possible counters?
dbaron: I think in our counters implementation, the right thing to
do is just create a new counter-manager for an element that
has 'contain: style'
dbaron: And then it's reasonable
emilio: And then dynamic changes, you'd have to reframe
dbaron: You'd have to reframe anyway
TabAtkins: You can make it as slow as you want to change 'contain'.
It's not a use case to flip it dynamically.
florian: Unless I missed something, counters have a definition
problem. CSS 'contain: style' doesn't.
florian: There's a dependency, but I think implementation and spec
being wrong is an overstatement
TabAtkins: Lists spec having bugs is adequate to say there's a spec
problem.
florian: My point is, if there's a problem with the contain spec
there needs to be an issue so I can fix it. But there isn't.
TabAtkins: ...
emilio: What would be the best way for Mozilla to ship contain:
layout?
florian: Could just not ship strict yet, then ...
TabAtkins: People are reasonably encouraged to turn on strict, so
technically the right way to do it, but don't think it's
good advice
<rego> neither contain:strict neither contain:content (as both
include style)
fantasai: I think the right way to go is to ship everything except
the style value itself
fantasai: and then at some future point, incorporate that into strict
fantasai: In the majority of cases it's not going to have an effect,
so I don't think it's something to be too worried about
emilio: It would be nice if Blink didn't parse 'style' either, and
we could do that change together later
florian: When you say don't do style, did you also mean change
behavior of strict later when we add it?
fantasai: Yeah, we will eventually change the behavior
fantasai: Yes
chrishtr: You said it's not so easy to implement 'contain: style'
chrishtr: How hard is it?
emilio: How hard is it?
chrishtr: Couple months of work?
emilio: It's work, that somebody needs to do
TabAtkins: Given that I do have a direction for naming in the future
TabAtkins: I'm OK with dropping style for now
TabAtkins: Dropping from definition of strict, dropping as a value
TabAtkins: And then we add 'all' later, that does all 4
TabAtkins: Do that once our implementation is good enough to be
meaningful for style
TabAtkins: And Mozilla can also fix
emilio: And add a bunch of tests :)
chrishtr: So what you're suggesting is to refactor spec so that
easier to incrementally add in the future
TabAtkins: Right, drop 'style' and add it back in a future level of
the spec
chrishtr: What if we do the other things you mention and leave style?
TabAtkins: Drop style containment from strict and content?
dholbert: That would make us reject 'contain: style' but...
chrishtr: CSS parsers can ignore keywords they don't understand?
florian: If you as an author writes 'contain: style size" it'll be
lost
florian: but if you write 'contain: size; contain: style size' then
you just lose the second declaration keep the first
TabAtkins: Most of the time we recommend strict anyway
florian: Seems like least harmful way to do this
chrishtr: And then we'll fix our bugs and allow ppl to opt in
Rossen: Any objections?
RESOLVED: remove style containment from keywords that aren't 'style'
RESOLVED: mark 'style' at risk
RESOLVED: Republish CR of css-contain once edits are in
chris: Ping me when you have a DoC and file a transition request
CSS Scoping
===========
:host-context
-------------
github: https://github.com/w3c/csswg-drafts/issues/1915
emilio: When looking into this stuff, what I didn't implement which
Apple also doesn't, is because it's really slow
emilio: Reason why it's really slow is that for every class change,
you either need to store everything for the whole document,
or you need to look at every shadow root that has a host
context selector, and go through all the shadow roots inside
your subtree to check if they have a relevant host-context
rule...
emilio: Handling DOM changes when host-context selectors are involved
emilio: Blink solves this by doing subtree restyles?
futhark: So in Blink we aggregate style info at the document scope
for everything
futhark: We don't use subtree calc
futhark: We invalidate inside the shadow root
futhark: We use a flag for it
emilio: One of the nice things in our impl is that the style info
inside the shadow root is contained
emilio: Blink wants to make such a change, too
emilio: So effectively it's similarly slow as /deep/
emilio: Since I haven't seen anything in Bugzilla requesting it
emilio: And WebKit also hasn't implemented
emilio: So would like to drop
futhark: I don't have the usage numbers...
TabAtkins: We should see if it's used
TabAtkins: It offers a useful functionality but if ppl aren't using
it, I'm fine with dropping it
Rossen: So, collect data, come back and based on this we can move
forward
fantasai: So maybe flag for next F2F so we don't forget
Rossen: Hope to get to it before
<br type=lunch>
Received on Thursday, 4 April 2019 23:08:17 UTC