- From: Nick Dugger <notifications@github.com>
- Date: Sat, 06 Jan 2018 17:28:30 +0000 (UTC)
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/723@github.com>
This idea is definitely jumping the gun a little bit, but... As I've been working on a project that uses a react-like library that uses native web components, I've found that when I'm using them with flexbox, often times I just want the parent custom element to simply act as a shell for the children without having its own box model so it doesn't hijack the flexbox context. I did some searching today, and apparently [`display: contents`](https://www.w3.org/TR/css-display-3/#box-generation) does exactly this; it makes sense for this to be default behaviour, because if a custom element has a `shadowRoot`, you generally expect the contents to define the makeup of the element. However, at the moment, in both Chrome and Firefox, `display: contents` is usable only behind a flag, and Edge probably doesn't even have it on their radar. ### Example: ```html <flex-container> <custom-element> <flex-item/> <flex-item/> </custom-element> </flex-container> ``` In this example, you would have to reapply `display: flex` to the `custom-element` in order for the `flex-item`s to actually be flex-items. However, if `custom-element`'s default was `display: contents`, the flexbox context would pass through it, allowing the `flex-item`s to actually be flex-items automatically. Make sense? Thoughts? I saw one closed issue that suggested them to be `display: block` by default, but this makes more sense, in my opinion. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/723
Received on Saturday, 6 January 2018 17:28:58 UTC