Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shadow dom: use css containment features by default #355

Closed
ebidel opened this issue Dec 7, 2015 · 14 comments
Closed

Shadow dom: use css containment features by default #355

ebidel opened this issue Dec 7, 2015 · 14 comments

Comments

@ebidel
Copy link

ebidel commented Dec 7, 2015

Shadow Roots would benefit from the UA performance features introduced in the CSS containment spec (https://drafts.csswg.org/css-containment/). Has there be consideration on how this could work well with shadow shadow?

@ebidel ebidel changed the title Shadow dom: use css containment feature by default Shadow dom: use css containment features by default Dec 7, 2015
@hayatoito
Copy link
Contributor

Has there be consideration on how this could work well with shadow shadow?

AFAIK, we haven't considered it yet. I've never seen a discussion. Thank you for filing an issue!

Let's discuss how Shadow DOM could benefit from the CSS containment spec here.
Does someone has a rough idea?

@ojanvafai
Copy link
Member

contain:style paint; might make sense for shadows as a default, but I think contain:layout is probably too restrictive as it requires you to have a definite height/width, i.e. you can't size to your children.

contain:paint is pretty restrictive, but it might be OK. It would mean that a position:absolute or position:fixed inside that container would be clipped by the container. I'm not sure how much extra optimization we could do there without contain:layout though.

We could in theory split contain:layout into two pieces. One that requires definite dimensions and another that gets the other properties (e.g. formatting context). That could be a compelling default. Then, any shadow that the author put a definite width/height on could magically get all the contain:strict benefits without the author needing to know to opt-in to contain:strict.

@tabatkins @esprehn @leviw

@tabatkins
Copy link

Can you clarify what the second piece would be? If it's just formatting context, that's fairly easy - implement the Display spec, then default custom elements to display: flow-root; (that's display:block + formatting context). Authors can change it back to display:block if they want. (Or use flex or grid, which are formatting contexts automatically.)

In other words, having the UA stylesheet apply a display: flow-root; contain: paint; should be a fairly unobjectionable set of defaults.

@hayatoito hayatoito added the v2 label Jan 13, 2016
@annevk
Copy link
Collaborator

annevk commented Mar 28, 2016

Given #426 it seems this is fairly objectionable to some. We should instead provide hooks (pseudo-classes) to make this easy, but not have defaults. Anyone object to duping this?

@leviw
Copy link

leviw commented Mar 28, 2016

FWIW, the sizing part of contain: layout should be[1] getting split out into another keyword. This would make contain: layout a pretty safe default.

https://readable-email.org/list/www-style/topic/css-containment-splitting-the-sizing-part-from-layout-containment

@tabatkins
Copy link

Yeah, I'm much more in favor of contain: contents; by default, once size is split out of layout. The effects are much more benign now.

@rniwa
Copy link
Collaborator

rniwa commented Mar 29, 2016

How can these CSS properties be set by default but not in v1? There is no way we can change the default stylesheet on ShadowRoot once it ships.

@tabatkins
Copy link

Ah, yeah, that v2 label was definitely wrong. This is a thing that needs a decision in v1, one way or another.

@hayatoito
Copy link
Contributor

Could someone summarize why we can restrict shadow trees by default by these css containment features? It's still unclear to me.

It sounds like authors' has to "opt-opt" (by overriding UA stylesheet) if authors are not satisfied these restrictions.

Because it is expected that authors are unlikely to use these features, we are using "opt-out" model, instead of "opt-in", right?

@hayatoito
Copy link
Contributor

If we are to have UA style, we need to resolve #426 because we do not have any way to style a shadow host.

@domenic
Copy link
Collaborator

domenic commented Apr 5, 2016

It sounds like the concrete proposal here is something like adding the following to the UA style sheet

:magic-shadow-host-selector-that-even-looks-inside-closed-shadow-trees {
  contain: contents;
}

Is that right? Earlier @tabatkins mentioned display: flow-root; contain: paint;, but in his latest comment it became contain: contents;?

@annevk
Copy link
Collaborator

annevk commented Apr 5, 2016

:magic-shadow-host-selector-that-even-looks-inside-closed-shadow-trees does probably not need to be that complicated as presumably all user agent style sheets also apply inside shadow trees. Otherwise we have a big problem.

@domenic
Copy link
Collaborator

domenic commented Apr 5, 2016

Good point, thanks for correcting me!

@rniwa
Copy link
Collaborator

rniwa commented Apr 5, 2016

Telecom Agreement: nobody seems to be strongly interested in this feature anymore so WONTFIX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants